把“AI工程”和“From Scratch”放在一起，可能很多人第一反应是“又一个人工智能入门教程”。但我在这个行业摸爬滚打了这些年，见过太多看似勤奋的上手者栽在同一个坑里：模型训练得像模像样，一部署到生产环境就全线崩溃。所谓的AI工程，恰恰不是调包调参那点事，而是从零开始搭建一套能稳定运行的系统能力。这篇文章不讲大道理，就从一个真实从业者的视角，把你从“会跑通 Notebook”带到“能搞定线上系统”这条路上，每一个关键环节、每一个要避开的暗坑，都给你拆开揉碎讲清楚。
1. 关于“从零开始”这件事，我到底在说什么
1.1 先厘清一个误解：你不是要把算法重新发明一遍
很多人一听“From Scratch”，就以为要自己手写反向传播、从空数组开始实现一个Transformer。这种理解不能说错，但对绝大多数从事AI工程的人来说，它的指导意义几乎为零。真正的工程意义上的“从零开始”，指的是你不依赖任何已经封装好的端到端解决方案，而是从一个原始的业务需求出发，靠自己的判断力去选型、去设计、去落地、去运维。
我见过不少简历上写着“熟悉TensorFlow/PyTorch”的人，你让他把现有模型部署成一个高可用的API服务，他会愣住。你问他线上模型效果变差了怎么排查，他更是一头雾水。这其实就是“会跑实验”和“会做工程”之间的巨大鸿沟。
1.2 为什么现在重新强调“从零”反而更重要了
现在这个阶段，AI开发的门槛已经被工具链压得很低了——AutoML、低代码平台、现成的预训练模型，几乎把一个刚入行的人能遇到的技术障碍全部抹平了。但事情很反直觉：门槛越低，反而越需要你理解底层逻辑。
为什么？因为当你遇到线上模型效果突然下降、推理延迟莫名升高、数据分布发生漂移这些问题的时候，现成工具不会告诉你答案。你只能靠对系统全链路的理解，一层层剥开去找根因。这种能力，只有在你亲手从零搭建过完整系统之后才有可能获得，不踩过那些坑，光靠看文档是记不住的。
1.3 一条明确的主线：从模型思维到系统思维
从零开始做AI工程，核心要完成的是一个思维转变。模型思维关心的是“我这个模型在验证集上准不准”，而系统思维关心的是“我这个含模型的系统在真实环境里稳不稳”。前者是研究者的视角，后者才是工程师的职责。
举个简单例子，一个图像分类模型离线测试准确率98%，上线之后因为真实图片的拍摄角度、光线分布和训练集有差异，准确率掉到80%。如果没有系统化地考虑数据分布、监控反馈、模型更新这些工程问题，你连它为什么掉到80%都很难搞清楚，更别提把它拉回正常水平。所以在整个“AI工程从零开始”的路线里，我始终把“构建对系统全链路的掌控力”作为最高优先级的目标。
2. 地基没打好，后面全是补不完的漏
2.1 数学基础真的需要学到“劝退”那个程度吗
我知道看到“数学基础”四个字，很多人已经开始头疼了。我直说我的看法：对于一个目标明确、要做AI工程落地的人来说，数学不需要学到数学系学生的深度，但有几块内容不能含糊。
线性代数是第一块。尤其是矩阵乘法、特征值分解、奇异值分解这些概念，它们不仅是模型内部计算的基石，更是你理解推理性能、显存占用、高维数据变换的工具。你不需要手推每一个公式，但你得知道一个矩阵乘法的计算复杂度是O(n^3)，这样才能理解为什么输入序列变长以后，Transformer的推理会越来越慢。
概率统计是第二块。极大似然估计、贝叶斯定理、正态分布、采样方法，这些直接影响你对模型损失函数设计的理解，也直接决定你能不能看懂数据分析的结果。到了做模型监控和A/B实验的时候，假设检验、置信区间这些知识是天天要用的。
微积分排在第三位。核心就是导数和链式法则。这并不是要求你能手动求出复杂函数的导数，而是为了让你在看到反向传播算法的实现时，脑子里能浮现出一幅清晰的梯度流动图。当梯度爆炸、梯度消失这些问题出现的时候，你知道它们发生在哪个环节，跟什么参数有关。
2.2 编程能力不是会写脚本，而是会写“能上线”的脚本
在实际做AI工程的时候，Python永远是你的第一语言。但“会用Python写模型训练脚本”和“能用Python写出高质量工程代码”之间，差了不止一个量级。
我觉得有几个点必须具备。第一个是代码的模块化能力。训练、验证、推理、数据加载、配置管理，这些部分必须能拆开，否则后期任何一点改动都会引发连锁故障。第二个是异常处理。真实的数据永远是脏的，真实的环境永远会出意外，你写的脚本要能在磁盘满了、数据字段缺失、网络超时的情况下给出明确报错，而不是直接崩掉或者更糟糕地静默产出错误结果。第三个是性能意识。Python有它的快，但也有它致命的慢。学会用向量化运算替代循环、用多进程处理IO密集任务、用缓存减少重复计算，这些基本功在模型规模上来之后，会成百倍地体现在效率差距上。
2.3 把基础阶段的学习节奏理顺，不焦虑也不拖延
我遇到过很多半途而废的人，他们放弃的原因几乎都是同一个：想做的事情太远，而每天面对的基础知识太枯燥，看不到直接成果。所以我要特别建议大家，在基础阶段就要建立一个“不断能用起来”的正反馈循环。
比如你在学线性代数，不妨同时去查一查PCA（主成分分析）的实现代码，把数学概念和代码对应起来；你在学概率统计，也不妨去跑一个简单的贝叶斯分类器在iris数据集上的实验。让每一块基础理论都立刻有一个“可触碰的产出”，这个学习过程就不会那么难坚持。时间安排上，我个人的建议是给自己两到三个月的高强度周期，每天至少投入三个小时，把数学基础和编程基础集中打完。拖太久，前面学的忘了，后面又推进不下去，反而更伤。
3. 机器学习与深度学习的真正分水岭不是模型复杂度
3.1 传统机器学习：工程化的基本功训练场
很多人一上来就扑向深度学习，觉得传统机器学习不够酷。但我必须说，逻辑回归、决策树、随机森林、GBDT这些传统模型，恰恰是你建立AI工程直觉的最佳素材。
为什么这么说？因为它们足够简单，简单到你能清清楚楚地看到数据的流转过程：特征工程怎么做、缺失值怎么填、类别变量怎么编码、样本不平衡怎么处理。这些问题在传统机器学习里处理起来是透明的，你能真真切切地感受到每一步操作对结果的影响。而到了深度学习中，很多操作被封装进了层和模块里，反而不容易建立起这种体感。
我在实际项目中体会很深的一点就是，做推荐系统、做风控模型的时候，GBDT类模型至今仍然占据着极其重要的地位。原因很简单：它们对表格数据的拟合能力极强，训练高效，推理极快，而且具备很强的可解释性。一个AI工程师如果只懂深度学习而对传统模型一窍不通，等于战场上只带了一把狙击枪，近身搏斗的时候会很尴尬。
3.2 深度学习：从“搭积木”到“看得穿积木的内部”
到了深度学习阶段，很多人就觉得简单了——无非是调用PyTorch或者TensorFlow搭一个Sequential模型，加几个卷积层、几个全连接层，然后跑起来看loss。这种“搭积木”式的使用方式，直接导致了一大批“伪AI工程师”的出现。
我的建议是，在初期一定要亲手实现一次基础网络的前向传播和反向传播，不调用任何深度学习框架。哪怕只是在MNIST数据集上实现一个两层的全连接网络，这个过程带给你的收益也远超你的想象。你会真切地理解张量是什么形状在各层之间流动的，梯度是怎么一层层传回去的，学习率对参数更新幅度到底有多大影响。这些体感，会成为你后面排查各种神秘问题时候最可靠的直觉来源。
等到你用框架的时候，就重点去理解框架的抽象逻辑：Module是什么、自动求导是怎么实现的、数据加载器为什么设计成那样。这个阶段还有一个关键任务，就是学会看论文并复现模型。我认为能够独立复现一篇论文里的模型，是区分“会用框架”和“理解模型”的一个重要标志。
3.3 架构选型的工程视角：不是什么都上Transformer
在实际工程项目里，选型极少“因为某个模型精度最高”就定下来。真实的决策过程常常是一个多目标权衡：精度、推理速度、显存占用、可解释性、上线运维成本、团队熟悉程度，全都要在同一个桌面上被比较。
举一个我经历过的典型例子，做一个短文本分类任务。用BERT类模型效果确实好，但推理延迟在CPU环境下可能要几百毫秒，而且模型体积大，上线后运维压力不小。而一个经过良好调优的TextCNN或者一个轻量级的高速文本分类器，在精度只损失两个点的情况下，延迟能降到十几毫秒。对于业务来说，这两个点的精度差异可能远没有响应速度的提升来得有价值。
这个道理放在图像、语音、生成式模型领域同样成立。我给自己的选型原则很简单：能用简单模型满足需求，绝不上复杂模型；复杂模型的收益如果不能显著覆盖它带来的工程代价，就坚决不选它。这就是从工程角度做AI的一个重要判断力。
4. 核心关键：你真的把训练这件事搞懂了吗
4.1 数据准备是90%的工程，不是那10%的边角料
把数据准备放在训练前面讲，我觉得再怎么强调都不为过。一个残酷的事实是，在几乎所有的工业级AI项目中，数据准备所花的时间远远大于模型训练本身。很多刚上手的人不愿意承认这一点，宁愿花时间调模型结构，也不愿意仔细清洗数据，结果就是模型效果差，但根本不知道差在数据上。
数据准备的第一步是采集链路。你要弄清楚数据从哪里来、通过什么方式收集、收集频率是多少、存储在哪、格式是什么。上游的数据源一旦有变动，你的模型效果就会跟着变动，如果没有一个清晰的链路认知，出了问题你甚至连该找哪个团队对接都不知道。
第二步是数据清洗。去重、去异常值、处理缺失、纠正标签错误，这些工作枯燥但无比关键。我踩过最典型的坑是标签噪声问题——训练集里有一部分样本标签是错的，模型为了拟合这些错误标签，性能被明显拖累。排查这个问题花了我整整一周，最后才发现是标注工具的一个过滤条件配置错了。所以我也养成了一个习惯：任何拿到的数据集，第一件事不是建模，而是做一轮彻底的统计和抽样检查，从分布、缺失率、异常值、标签均衡性各个维度去摸清它的底细。
4.2 特征工程的隐形力量
深度学习时代有一个流行观点认为，模型可以自动学习特征，所以不需要做特征工程。这句话对图像、语音这类原始信号数据大体成立，但放到表格数据、时序数据、点击行为数据这些场景里，就是一个严重的误导。
我举一个例子。在用户留存预测这个任务里，简单的用户基本属性特征加一些统计特征，可能模型AUC在0.72左右。但如果你能构造出“用户最近7天登录频次的变化斜率”“用户上一次活跃距离今天的天数”这类带有强业务含义的衍生特征，AUC可能直接拉到0.80以上。这种提升，远不是调整模型结构能够轻易获得的。
所以我的建议是，在动手建模之前，必须花足够时间去理解业务逻辑，然后把业务理解转化为特征设计。这里面的核心技巧是：把“用户做了什么”转化为“用户在这个指标上的趋势变化”，把“静态属性”转化为“和群体平均水平相比的偏差”。好的特征工程不是堆砌大量特征，而是用少量高信息量的特征精准切入问题的本质。
4.3 模型训练：从“能跑通”到“高质量地跑通”
训练环节的工程细节，往往是经验丰富与否的分水岭。首先是优化器的选择，很多人就是一个Adam走天下，但Adam并不是所有场景的最佳选择，尤其是在一些泛化性要求较高的任务里，SGD配合合适的学习率调度反而表现更稳。我自己的经验是，对于复杂模型做精细调优的时候，会尝试先用Adam快速跑到一个不错的位置，然后切到SGD继续打磨。
学习率调度经常被忽略，但它对最终效果的影响非常巨大。从常数的学习率、到步进式衰减、到余弦退火，再到带有warmup的调度策略，各自适合不同的场景。通常预训练模型做微调任务，warmup几乎是必须的，因为模型加载预训练权重之后，一开始的学习率过大会破坏已经学好的参数分布。
正则化手段同样重要。L2正则化、Dropout、Early Stopping、数据增强、Label Smoothing，这些技术单独使用的时候效果有限，但组合使用起来能显著提升模型的泛化性能。我见过太多过拟合严重却不知道怎么处理的案例，其实核心就是在这些手段里找到组合搭配。
最后是关于实验管理的体会。训练过程中一定要记录足够完整的实验日志——包括数据版本、代码版本、超参配置、每个epoch的损失和验证指标、随机种子。否则你复现不出自己的结果，做任何调优都像是在黑夜中盲目飞行。实践经验是，严谨的实验记录能力，是区分专业人士和业余玩家的明显标志之一。
4.4 模型评估：准确率只是个开始
工业界的模型评估，视角和学术界的精度指标有明显差异。准确率、精确率、召回率、F1值、AUC这些是最基础的，但仅有这些远远不够。
你还需要关注不同群体之下的性能差异。模型在整体上表现不错，但可能在某个特定的性别、年龄段、地区群体上效果明显偏差，这种偏差如果不主动去测，线上出了问题才来排查，成本高昂。
还需要关注模型的鲁棒性。对输入做一些微小扰动，模型输出会不会剧烈变化？对图像加一点肉眼不可见的噪声，分类结果会不会直接翻转？这些都是真实世界里会发生的情况，需要在离线评估阶段就充分测试。
还有就是置信度校准。模型的输出概率值是否真的反映了真实可能性？比如模型对一百个样本给出0.9的置信度，实际大约九十个个是正确的吗？如果模型过度自信或过度保守，你的下游决策系统就会做出错误判断。
5. 工程化落地：从模型到产品之间隔着一整条河
5.1 模型部署不是什么黑魔法，但确实有门槛
模型部署的第一个问题是用什么方案。现在主流的选择有这几种：把模型集成到Web服务框架里，比如用FastAPI包一层推理接口；用专门的推理服务框架，比如Triton或TorchServe来进行更精细化的资源管理和并发优化；或者把模型转换为更轻量的格式，比如ONNX，再配合推理引擎如ONNX Runtime使用。如果你的目标是移动端或边缘设备，还需要考虑量化、剪枝、蒸馏这些模型压缩技术。
输入输出的接口设计是一个常常被忽视的细节。模型的输入往往需要经过复杂的预处理，比如文本需要分词、图像需要缩放归一化。这些预处理逻辑如果和模型本身没有清晰地封装在一起，部署之后很容易出现线上输入格式和离线训练不一致的问题。我见过太多线上效果差甚至报错的例子，根因就是特征处理逻辑和模型分家了。
我在部署时最重要的是确立一条原则：模型和它的预处理、后处理逻辑必须作为一个整体被打包发布，版本完全绑定。这样你才能保证线上运行的，确实是你离线验证过的同一个系统。
5.2 MLOps是一整套工程文化，不是买一个工具回来就能解决
MLOps这个概念已经被讲得很泛滥了，各大厂商都在推自己的平台。但真正落地MLOps，核心不是工具而是流程。那我理解的MLOps要解决什么问题呢？其实是三个字——可重复。你的模型训练过程可重复，你的部署发布过程可重复，你的监控告警过程可重复。
CI/CD和CT（Continuous Training）就是一个很典型的流程问题。代码更新要能自动触发完整的测试流程，模型训练完要能自动评估、自动决定是否发布。数据发生变化时，要能触发重新训练的流程。这些链路一旦用自动化方式串起来，AI系统才算是真正从“一次性研究”变成了“可持续演进的工程系统”。
但我要泼一盆冷水，这些流程并不是靠买一个MLOps平台就能自动长出来的。工具只是辅助，如果团队的工程规范本身混乱，再贵的平台也救不了。我见过太多的团队先把平台搭起来，再倒推流程规范，最后平台变成摆设，大家还是各干各的。正确的顺序应该是，先建立清晰的手工流程规范，然后把其中稳定可靠的部分逐步自动化。
5.3 监控与告警：这是线上AI系统的心脏和神经
模型部署上线只是万里长征走了一半，真正考验功力的是上线之后的持续运维。模型监控和传统软件监控有一个显著差异：软件监控主要看系统是否报错、是否挂掉，而模型监控还要时刻关注模型预测效果是否在悄悄变差。
数据漂移是线上AI系统最隐蔽也最致命的威胁之一。真实世界的数据分布一直在变化，用户的兴趣会变、商品的属性会变、图片的拍摄风格会变，所有这些变化都会让模型赖以成立的数据分布发生偏移。所以你要监控线上输入数据的分布特征，比如均值、方差、类别分布、特别重要的特征分布，发现显著的偏移就要及时告警。
效果监控也很关键。在很多场景下，模型预测的“真值”不会立即得到，比如推荐系统中用户会不会点击，必须要等用户产生实际行为之后才知道。所以你要设计一套延迟反馈的追踪机制，用各种代理指标来近似监控模型效果。这个领域没有放之四海而皆准的药方，必须结合业务场景设计合适的指标。
我自己的经验是，告警规则的设置是一门平衡艺术。阈值设得太松，问题发生了你没有感知；阈值设得太紧，告警铺天盖地，团队会产生告警疲劳，真正重要的问题反而被淹没在噪音里。我的方法是分层告警，严重问题用电话和短信等强触达渠道，一般问题只在工作群推送，不重要的只记录在日报里。
5.4 从离线到在线，跨越推理性能这道坎
深度学习模型的推理性能如果处理不好，再好的算法思路也落不了地。推理性能的核心指标是延迟和吞吐。延迟关心的是单个请求从进来到一个结果返回要多长时间，吞吐关心的是系统在单位时间内能处理多少个请求。这两者常常互相制约，你要根据业务场景确定优先级。比如线上实时风控，延迟的优先级高于吞吐，而离线批处理任务则反过来。
推理优化的常见手段我整理一下，从架构设计层面，可以用批处理把多个请求合并成一个批次处理，充分利用GPU并行能力。从计算优化层面，可以用TensorRT或ONNX Runtime做算子融合和精度校准，有时候能带来几倍的加速。从工程调度层面，可以用缓存把重复计算的结果直接命中，用异步化把高延迟的下游调用从关键路径上剥离。
这里面还有一个很实际的建议：先分析瓶颈，再优化方案，不然很容易白忙。用Profiling工具看看时间到底耗在哪个环节，是数据预处理？还是模型推理？还是后处理？还是网络传输？定位到瓶颈再去精准优化，远比凭感觉改配置有效率得多。
6. 我踩过的坑，希望你不用再踩一遍
6.1 线下验证集和线上数据分布脱节的惨痛教训
有一次做一个文本分类项目，离线F1值做到0.91，上线之后一周内就掉到了0.78。当时整个团队都很紧张，第一时间怀疑是模型代码部署错了。排查到最后才发现，问题出在数据预处理环节——线下训练时分词用的词典和线上推理时分词用的词典版本不一致，导致线上很多样本的输入被切得乱七八糟。预处理的逻辑和模型分属两个团队维护，中间一脱节，后果就立刻反映到了线上。
从那以后我给自己立了一条规矩：特征处理和模型必须是同一个发布单元，任何一方改动都必须同时测试同时上线。这条规矩救过我很多次，我也很想分享给你们。
6.2 别把所有的宝压在“加数据”上
我见过不少团队，线上模型效果不好，第一反应就是“多收集一些数据”。数据多了确实可能有效，但前提是数据质量有保障。我经历过一个项目，我们花了很大的代价标注了几十万条新数据，加进去之后效果不升反降。排查了大半天才发现，新数据来源渠道和原有数据的分布逻辑不同，标注口径也有偏差，引入了大量噪声。
正确的做法是，在决定“加数据”之前，先仔细分析当前模型的错误案例。看看到底是哪些样本在出错，为什么出错，然后有针对性地补充相关的数据或修正已有数据。盲目标数据是对算力和时间的巨大浪费，这个坑我不希望你再踩。
6.3 更新模型的流程如果没有设计好，就是新的故障源
模型需要更新迭代，这是常态。但模型更新这个操作本身是一个高风险的变更，如果流程设计不够严密，很容易引入新的故障。我见过因为模型切换没有设置灰度策略，导致新模型一上线就出现大规模效果下降，影响核心业务指标的事件。
所以我强烈建议大家建立一个模型发布的标准流程。新模型训练完成之后，不能直接全量替换旧模型，先进行离线交叉验证，然后在线上环境做小流量灰度，逐步扩大流量比例，同时密切监控核心指标和告警，确定没有问题之后再全量发布。同时保留一键回滚的能力，旧模型始终保持热备，随时可以切换回去。
6.4 依赖别人的“最佳实践”前，先确认它的适用条件
网上关于AI工程的文章多如牛毛，各种“最佳实践”满天飞。我并不是要大家不看这些文章，但我要强调一个关键点：每一篇最佳实践背后都有它对应的前提条件，硬件环境、数据特点、业务场景、团队规模不一样，同一个方案效果会完全不同。
我看到很多人不加思考地把别人针对超大流量场景设计的架构方案，套用到日请求量只有几千的小应用上，最终引入了不必要的复杂度，系统更难维护。我的建议是先充分理解自己的问题边界，再去参考别人的经验，把可行的方法做本地化适配。任何技术方案脱离了具体情境，都会失真。
7. 面对大模型时代，AI工程的底座能力反而更吃香了
7.1 大模型没有改变工程本质，只是把复杂度转移了
随着大模型和生成式AI的爆发，很多人开始焦虑，觉得传统AI工程的知识是不是要过时了。我的观点恰好相反：大模型时代，AI工程的底层能力反而变得更重要了。原因很简单，系统本身的复杂度并没有消失，它只是被转移到了新的地方。
以大模型应用为例，你要解决提示词怎么设计和管理的问题，要解决上下文窗口怎么策略性利用的问题，要解决大模型输出怎么与外部工具可靠交互的问题，要解决模型幻觉怎么抑制、输出格式怎么约束的问题。这些工作全都有很强的工程属性，你如果没有从零构建系统的经验，面对这些问题时会更加手足无措。
7.2 RAG和Agent应用，本质上还是数据工程和可靠性的较量
这两年被讨论最多的应用方向是检索增强生成（RAG）和智能体（Agent）。我在实际做了几个相关项目之后有一个很强烈的感受：决定这类应用上限的，往往不是大模型本身的聪明程度，而是工程体系的精细程度。
做RAG的时候，最大的难点不在“把文档切开、向量化、存进向量库”这一套流程，而在于如何保证检索出来的内容是准的、相关的，以及如何设计大模型对检索结果的理解和生成逻辑。其中涉及到的文档解析质量、分块策略、向量检索的召回率、重排序的精度，每一个都是需要反复打磨的工程细节。
Agent应用更是把可靠性问题推到了前台。大模型在Agent里并不是直接输出最终结果，而是要自主决定调用哪些工具、按什么顺序调用、参数怎么填、结果怎么处理。这整个链条中任何一环出错，都会导致最终结果无法使用。怎么用工程手段约束大模型的行为边界、怎么设计工具接口让调用更稳定、怎么加入错误恢复机制，这本质考验的还是系统工程能力。
7.3 越抽象的工具，越需要扎实的内功来驾驭
编程这件事也是在不断“抽象化”的。早期我们面向机器写代码，后来面向操作系统写代码，再后来面向框架写代码，现在开始面向大模型去写提示词。抽象层次越来越高，看起来是越来越容易，但实质上对使用者的底层理解能力要求反而更高了。
就拿提示词工程来说，很多人在网上抄各种“神奇Prompt”，一换场景就失效。真正能写出稳定有效提示词的人，一定是对大模型背后的注意力机制、上下文学习规律有比较扎实的理解，同时又有很强的逻辑表达能力。而那些从零开始构建过完整系统的人，在面对抽象工具时，会自然地多问几个“为什么”，更倾向于做可解释、可控制的设计，而不是纯粹赌运气。
所以我给所有正在走“AI工程从零开始”这条路的人一个总的建议：永远不要只满足于“跑通了一件事”，而要去追问“为什么能通”以及“换一个条件它还能不能通”。这种追根究底的习惯，决定了你是在被动使用工具，还是主动驾驭技术。
8. 一条更落地的路线图：按你自己的节奏走完它
8.1 用大概三个月时间，把地基和基础模型走完
前三个月是这个路线的第一阶段。目标是完成数学基础核心内容的学习、Python工程能力的基本训练，以及传统机器学习算法的系统掌握。这个阶段不需要追求面面俱到，但关键的数学概念要建立直觉，Python要能熟练写出清晰、可调试的程序，常用的机器学习算法要能独立完成从训练到评估的完整流程。
这个阶段的验收标准，我觉得是你能够独立完成一个端到端的表格数据项目，包括数据清洗、特征工程、模型训练、评估对比，以及最终产出一份清晰的报告。能够做到这一点，说明你已经具备了AI工程最底层的学习和动手能力。
8.2 用三个月时间，攻克深度学习与训练基本功
第二阶段的核心任务是深度学习。包括亲手实现神经网络的前向和反向传播以建立深层体感，深入了解CNN、RNN、Transformer这些基础架构的原理，同时认真掌握训练环节中的优化器、学习率调度、正则化、模型评估等各项关键技能。
这一阶段还需要大量阅读和复现经典论文。我的建议是从相对简单的经典结构入手，比如ResNet、Attention机制的原论文，先把结构吃透，然后自己复现出来，跑通并验证效果。这个过程会非常磨人，但收获极大。
8.3 用一到两个月时间，打通工程化部署这条线
第三阶段聚焦部署上线。你需要选择一个场景，最好是一个相对完整的分类或预测任务，然后把训练好的模型完整地部署成可访问的在线服务。从预处理到推理到后处理，完整地封装成一个整体。
在此基础上，接下来你要给这个部署加上监控和告警能力，建立基本的数据漂移和效果指标监控。你还要尝试把模型更新的流程做规范，包括数据版本管理、模型版本管理、灰度发布和回滚机制。做完这个阶段，你会对“线上系统的复杂性”有非常真切的体感。
8.4 用持续精进的姿态，不断拓展自己的工程边界
基础路线走完之后，后续的学习方向就完全取决于你的场景和兴趣了。如果你对大规模推荐系统感兴趣，可以去深入学特征平台、在线学习、多目标排序等技术方向。如果你对计算机视觉感兴趣，可以去探索视频理解、多模态模型、边缘部署等领域。如果你对大模型应用感兴趣，那么提示词工程、RAG系统、模型微调、Agent框架就是你应该重点深耕的领域。
越到后面，你越会发现“从零开始”并不是一个只属于新手阶段的事情。每进入一个新的技术领域，你都会经历一次“从零开始”的循环，但你的底子越扎实，每一次进入新领域的成本就越低，达到可用状态的速度也就越快。这才是AI工程师最核心的竞争力。
我在带团队的过程中越来越确信一件事：真正有价值的，不是你今年又用了哪个新框架、新模型，而是当框架和模型都换了一茬之后，你依然能够靠对底层原理和工程本质的理解，快速驾驭新工具、解决新问题。这就是从零开始做AI工程能带给你最宝贵的东西。希望这份经验对你有一些真切的帮助，少走一些我曾经走过的弯路。
