把“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和CTContinuous 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工程能带给你最宝贵的东西。希望这份经验对你有一些真切的帮助少走一些我曾经走过的弯路。 
长河君 · 2026/10/2 10:15:22 · 阅读 1.2k AI工程从零开始：构建稳定生产级系统的完整路径
把“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和CTContinuous 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工程能带给你最宝贵的东西。希望这份经验对你有一些真切的帮助少走一些我曾经走过的弯路。