很多人把“AI工程”想得太玄，又有人把它想得太简单。玄的那批人觉得要懂数学推导、要能复现论文；简单的那批人觉得调个API、跑通一个notebook就算入了门。我见过太多在这两个极端之间反复摇摆的人，最后既没做成产品，也没沉淀出能力。
“ai-engineering-from-scratch”这个标题，说白了就是一条从零开始把AI能力真正“工程化”的路线。它强调的不是某一个算法、某一个框架，而是一整套做事的顺序、判断标准和思维方式。这篇文章我想用我实际踩过坑的经验，把这条路线拆开讲清楚：该学什么、按什么顺序学、用什么项目练手、遇到问题怎么定位。适合刚入门想系统化提升的开发者，也适合已经在做算法但觉得“工程感”不足的人。
1. 先想明白：AI工程到底“工程”在哪里
1.1 从“模型能跑”到“系统能交付”之间的差距
很多人第一次跑通一个深度学习模型时很兴奋，觉得“我会AI了”。但真实的生产环境根本不是这样。你在notebook里能跑通的模型，放到线上要面对的是：数据分布变了怎么办、推理延迟太高怎么办、模型偶发出错怎么办、别人要接手你的代码能看懂吗。
我有个很直观的类比：模型像发动机，AI工程是整辆车。发动机性能再强，没有传动系统、刹车、仪表盘、底盘调校，它也只是一台裸机，上不了路。AI工程解决的就是这些“发动机之外”的问题——可靠性、可维护性、可观测性、成本控制。
一个典型的例子：你在离线测试集上准确率95%，上线后却收到一堆用户投诉。为什么？因为离线测试集跟你线上真实的数据分布不一样。工程要做的事情之一，就是建立一套机制去发现这种偏差，并且在发现之后能快速修正。这不是某一个模型的“魔法”能解决的，而是整个系统的设计问题。
所以，AI工程的核心不是把模型训得更准，而是让一个AI系统在真实环境里稳定、可控、可迭代地运行。这才是“工程”二字的分量所在。
1.2 从零开始的四个里程碑
我带了几个从零起步的开发者，观察下来，比较合理的能力成长路径可以分四个阶段。每个阶段都有一个明确的验收标准，不需要“学完”再动手，而是边做边补。
第一阶段：跑通一个最小的端到端项目。从数据准备、模型训练、评估到简单部署，能完整走一圈。哪怕用现成的模型、现成的数据集都没关系，关键是“全链路”跑通。验收标准：你自己写的代码能从原始数据走到一个可访问的接口。
第二阶段：建立数据与评估的闭环。训练集、验证集、测试集怎么划分，评估指标怎么选，如何通过数据改进模型效果。这个阶段的核心是“反馈回路”——改了什么、效果变化了多少、为什么变化。验收标准：你能解释模型效果变化的因果关系，而不是“调了个参，好像好了点”。
第三阶段：掌握部署与服务化能力。Docker、推理服务、GPU资源管理、并发处理、监控日志。这一阶段的目标是把模型从“文件”变成“服务”。验收标准：你的服务能在无人值守的情况下运行一周以上，出问题时能通过日志快速定位。
第四阶段：具备系统优化的思维。识别系统瓶颈在数据、模型还是架构，能做性能调优、成本优化、模型迭代的灰度发布。验收标准：你可以独立负责一个小型AI系统的迭代，而不是只写训练脚本。
这四个里程碑我不建议跳级。很多人一上来就想“做一个大模型应用”，结果卡在细节里出不来，反而挫败感很强。路是一步一步走出来的，每一步提前把“完成”的标准定清楚，学习效率会高很多。
身边很多朋友问我“从零开始”是否意味着要从数学补起，我的回答通常是否定的。如果目标是AI工程方向，数学够用就行，关键是系统的思维方式和调试能力。换句话说，你要能看懂loss曲线、理解学习率带来的影响、知道特征分布异常意味着什么，就够了。不需要从傅里叶变换推起。
2. 工程视角下的技术栈选型与学习路线
2.1 核心技术栈清单与选择理由
“AI工程”这个词看着大，但落到具体技能上其实是有限的。我按重要程度列一份清单，每一项我都会说一下为什么需要。
Python是默认的开发语言。这不需要争论，生态摆在那里，PyTorch、transformers、数据处理库全都是Python生态。更重要的是Python让你能快速验证想法，省下的时间可以用在系统设计上。
Linux与Shell是绕不开的基础设施。训练服务器、推理容器基本都是Linux。如果你连看日志、查GPU状态、配环境变量都不熟练，会非常被动。
Git是协作和版本管理的底线。AI项目比其他软件项目更依赖版本管理，因为数据和模型权重都是需要被追踪的“产物”。一个模型跑了两周，效果很好，但代码、数据版本、训练参数没记录，等于白跑。
Docker是环境统一的手段。本地能跑、服务器不能跑，绝大多数情况是环境不一致。Docker把环境、依赖和代码一起打包，能消除“在我机器上是好的”这种经典问题。
评估与实验管理的工具链很重要，比如MLflow、wandb这类工具。它们解决的核心问题是：记录每次实验的参数、指标、代码版本，让实验变得可比较、可复现。
推理服务与性能优化相关的技能（ONNX、TensorRT、vLLM等）决定了模型上线的效率。这就是从“能跑”到“能高效跑”的台阶，也是AI工程里含金量较高的一块。
向量数据库和检索组件是当下RAG应用的基础设施。随着AI应用从“单模型”变成“模型+知识库+工具”的组合，掌握这些组件的使用场景和选型逻辑已经成了AI工程师的必修课。
把这些内容摊开看会发现，真正花时间的是工程工具和系统思维，不是某一个模型的结构。
2.2 学习顺序背后的“为什么”
为什么我建议按上述顺序而不是从最新的大模型论文开始？因为工程能力是积累式的，而模型技术是快速迭代的。今天让你兴奋的模型结构可能半年后就过时了，但Linux、Docker、评估体系、追踪数据版本的能力，十年后依然有用。
而且，工程工具掌握得越早，学习新模型技术的成本就越低。举个例子：你理解了数据版本管理和评估闭环之后，换一个新模型本质上就是“改一版配置、跑一次对比”，这对你的认知负担很小。但如果你跳过这些工程基础，直接追新模型，你每一次实验都在“裸奔”——没有记录、没有对比、没有可复现性，学的东西很快就会变成一团乱麻。
这背后有个顶层逻辑：AI工程的学习应该是“技能树”而不是“知识链”。知识链是一条线，学完A再学B；技能树是每个技能独立存在，但组合起来才能发挥价值。新手容易陷入“必须先把所有前置知识学完再动手”的思维陷阱，其实在工程实践中，你只需要掌握“够用”的基础，然后带着问题去查、去补就行。
2.3 避免两个极端：调包侠与论文党
我看到两类人容易走弯路。第一类是“调包侠”，什么模型都调现成的API，效果好了就交差，完全不理解内部机制。这类人一旦遇到模型失效的情况就束手无策，因为他们没有Debug的能力。
第二类是“论文党”，迷恋理论推导，非要搞懂每一个公式才肯动手。这类人往往学了很久还停留在纸面，动手能力弱，做不出实际东西。
正确的姿态是在这两者之间找到平衡点：模型当成工具来理解，工具的内部机制不要求从头推导，但要清楚它的工作原理、适用边界、关键参数的影响。这个“度”需要在实际项目中反复拿捏。
我个人的经验是：用一个模型前，先花半个小时搞清楚它的输入输出、核心机制、适用场景、已知限制，然后立刻动手跑一个demo。碰到问题再回头深入研究。这种“先用起来，再搞明白”的方式比“全懂了再用”要高效得多。
3. 从零到一：用项目驱动能力搭建
3.1 挑选你的第一个端到端项目
你一定听过一句话：项目是学习技术最快的方式。但很多人忽略了一个前提——不是所有项目都适合当前阶段。
适合第一个端到端项目的类型，我推荐三个方向：RAG问答系统、文本分类服务、小模型微调。这三个方向都有共同特点：数据容易获取，评估相对明确，部署路径清晰。
RAG问答系统适合想贴近当下热点的人。你的目标是“外挂”一套知识库，让模型基于你的文档回答问题。它能锻炼文本切分、向量化、检索排序、Prompt拼接、结果评估这条完整链路。
文本分类服务适合想最简化流程的人。它入门曲线平滑，数据标注、模型训练、评估、部署每个环节都清晰可见，便于理解整体架构。
小模型微调则适合对模型机制感兴趣的人。比如用领域数据微调一个开源模型，让它学会特定风格或特定知识。它锻炼的是数据构造、训练参数调整、效果评估这几项核心能力。
选择标准还有一个很重要的原则：这个项目要有“可感知的完成标准”。如果你做了一个问答系统，问它问题它能给出像样的答案，这就是“可感知”。有了完成标准，你才知道自己什么时候算“做完”，做完之后才有正反馈，才会继续往下走。
3.2 最小闭环拆解：数据、训练、评估、部署
无论选哪个方向，都要按“最小闭环”的方式去做。我第一次搭建一个文本分类服务时，就经历了完整闭环，这里我用这个案例来拆解。
第一步是数据。我用的是一份公开的电商评论数据，目标是判断评论情感是正向还是负向。数据量不大，几千条。这个阶段要做的动作是：划分训练集（60%）、验证集（20%）、测试集（20%），并且要确认标签分布是否均匀。很多新手在这一步就踩坑——把带标签的全部数据直接拿去训练，最后评估结果虚高，上线就现原形。
第二步是训练。我先用了一个轻量级预训练模型，原因是迭代速度快。训练时重点关注loss变化趋势，判断模型是否收敛。这里有个关键点：不是所有任务都需要大模型。几千条数据的文本分类，小模型已经足够。把问题拆小了，学习成本也会变低。
第三步是评估。这步远不止看Accuracy一个数字。对于情感分类，要看精确率（Precision）、召回率（Recall）、F1分数这三个指标。为什么？因为如果正负样本不平衡，Accuracy会骗人。假设90%是正向评论，你全部预测为正向，Accuracy有90%，但你的模型实际上什么都没学会。这种“评估指标与业务目标脱节”的问题是新手最常犯的。
第四步是部署。这一步我用Flask搭了一个最简接口，输入一段评论文本，返回情感类别和置信度。部署不是终点，部署完要验证：请求延迟多少、并发能力如何、模型效果是否跟离线一致。你可以在本地用curl发请求测试，看看返回的JSON是否符合预期。
这四步走完之后，你在认知层面就建立起了一个基础的“AI系统框架”，后面学什么都是在这个框架上做增量。
3.3 进阶：把系统做到“能交出去”的水平
能跑通最小闭环和“能交出去”之间，还有很长的路。所谓“交出去”，是让别人也能用、也能维护、也能迭代。
这一阶段要做的事很明确。第一是版本管理：代码进Git，数据集和模型文件做好命名规范，训练参数要有记录。我习惯在项目根目录下建一个experiments文件夹，每次实验留下的配置、日志、指标截图都存在里面。这样即使两周后回看，也能准确知道当时的实验状态。
第二是自动化评估。你会发现随着迭代次数增加，手动验证效率太低。可以写一个评估脚本，每次训练完自动跑一遍测试集，把指标输出到文件。这能帮你建立一个“回归测试”的护城河——模型改进后，至少保证旧能力不掉。
第三是监控与日志。线上服务要记录请求量、延迟、错误率，以及模型输出的抽样日志。我遇到过一个典型场景：某个线上分类任务在凌晨突然错误率飙升，查了下日志发现是某类特殊输入触发了模型崩溃。如果没有日志，我根本无法定位这个问题。监控日志不是可选项，是上线系统的“仪表盘”。
第四是性能调优。延迟和成本是AI系统能否持续运行的关键。常见的优化手段有：模型量化、批处理、缓存、推理框架加速。一个很简单的例子：同一个模型用PyTorch默认方式推理，跟用ONNX Runtime推理，延迟可能相差两三倍。这些都是“从能跑，到能规模跑”的锦上添花。
4. 常见问题与避坑技巧实录
4.1 新手最容易踩的五个坑
我先说结论，再解释。
第一个坑：数据集泄漏。这是数据科学里最常见、后果最严重、又最容易被忽视的问题。什么叫泄漏？你做文本分类，先把所有数据做了全局标准化（比如用全量数据的均值方差去归一化），然后再划分训练集测试集，这样测试集的信息就从“均值方差”这条路径泄漏进了模型，测试指标虚高。正确的做法是先划分数据，再在训练集上计算标准化参数。很多比赛里的“高分模型”在真实场景失效，原因之一就是泄漏。
第二个坑：评估指标与业务目标脱节。我在前面举过accuracy在高不平衡数据下的骗局。类似的坑还有很多：做排序任务只看准确率不看排序质量；做生成任务只看BLEU分不看用户感受。指标要服务业务，不是业务服务指标。
第三个坑：只调模型不调数据。错。AI系统是个整体，数据、模型、评估、业务逻辑一起决定效果。最常见的情况：模型效果差，新手第一反应是“换一个更大的模型”，但其实认真清洗一下数据、修正标注错误、补充边界case，效果提升可能比换模型更明显。数据质量是模型效果的上限，这句话值得反复咀嚼。
第四个坑：忽略系统瓶颈。模型训练的GPU利用率、推理服务的请求延迟，这些都是系统瓶颈。有人训练一个小模型，却发现GPU利用率只有20%，检查了一下才意识到DataLoader的num_workers设成0了，数据加载速度跟不上训练速度。这种问题如果只看训练代码是找不到的，要有能力“拉高视角”看全局。
第五个坑：一个项目做到“完美”才开始下一个。比如调了两周还没达到理想的准确率，就死磕不动。其实，一个AI项目永远没有“完美”的时候，你更应该做的是设置一个“可接受的完成线”，到了就收，然后进入下一个项目，把技能面铺开。项目广度上去了，深度自然有机会练。
4.2 实战排查清单
当AI系统出了问题时，很多人会慌，然后乱试。我建议用一张排查清单来规范动作。
问题现象：模型效果差。 排查步骤：
- 先看数据是否有标签噪声、是否有数据泄漏，这件事花不了多少时间，但能排除一类致命问题。
- 再看训练过程：loss曲线是否收敛，训练集指标是否正常，判断是欠拟合还是过拟合。
- 最后看评估方式：指标是否算错、测试集是否和训练集同分布。
问题现象：线上服务不稳定。 排查步骤：
- 看日志和监控：是全部请求失败还是特定输入失败，错误码是什么。
- 看资源状况：CPU、内存、GPU显存是否打满，有没有频繁重启。
- 看依赖与并发：同一个服务在低并发下正常，高并发下超时，往往是代码里有串行阻塞或句柄泄漏。
我经常把这套排查思路简化成一句话：**先定位问题在哪个环节，再决定怎么修。**不要一上来就换模型，那是最浪费时间的方式。
4.3 心态与习惯层面的建议
除了技术问题，我想聊聊软性的部分，这对长期成长的影响可能更深远。
养成每天写实验记录的习惯。不需要长篇大论，哪怕几行字：今天改了数据清洗方式、验证集F1从80.2提升到80.9、明天计划尝试增加一个特征。这个习惯能让你在几周后回看时拥有清晰的时间线，而不是靠大脑记忆做判断。
让评估先于优化。永远先建立可靠的评估体系，再做任何优化。没有评估体系的优化就像闭着眼睛开车，你觉得自己在前进，其实可能早就偏航了。
学会做“最小可行版本”。这是我一再强调的。很多项目失败不是能力不行，而是规划太重。如果你要在新领域验证想法，设定24小时内做出一个能用但不完美的demo，用它来校验方向。
这些习惯看起来不像“技术”，但时间拉长后，它们比任何一个具体的框架都更能定义你的工程水平。
我记得自己第一次独立完成一个全链路AI项目时，每天有无数个瞬间想放弃。但当我真正跑完整个从数据到服务的闭环后，那种“图景在脑海中展开”的感觉，确实很难用语言形容。
如果你真的想从零开始走AI工程这条路，我给你最真诚的建议是：不要花三个月看完一堆教程才动手，今天就找一个小数据集，跑通一个最粗糙的端到端流程。哪怕很丑、哪怕很慢，那个粗糙但完整的闭环，才是你真正起飞的第一块跑道。
