看到ai-engineering-from-scratch这个标题，我脑子里第一反应不是模型排行榜，也不是又一套课程大纲，而是一个更实在的问题：你到底是真想把AI工程这件事吃透，还是只想让屏幕上出现一个“看起来会跑”的东西？
这两年“AI工程”四个字被反复提起，但大部分人的路径是装个PyTorch、跑通一个开源模型、接几个API，然后简历上写“熟悉AI工程”。这不算错，但它更像“使用AI”，离“工程”还差着十万八千里。真正的AI工程，是当你面对一个完全没跑过的新模型、一份脏到不想看的数据、一个压榨到极限的推理服务时，你有系统的方法去拆解、定位、修复和优化。这篇文章我不打算给你一份“七天速通”式的清单，而是拆开讲清楚：从零开始搞AI工程，到底哪些东西值得学、怎么学、学了怎么用，以及我自己踩了几年坑换来的那些取舍。
1. 重新定义“从零开始”：AI工程和算法调参根本不是一回事
1.1 为什么“从零开始”这个起点比你想的重要
我见过太多人一上来就奔着Transformer去，结果写了两天注意力机制，代码一跑就爆显存，然后开始怀疑人生。问题不出在Transformer上，出在他对“上一步”的理解是空心的。AI工程里的“从零开始”，不是指从线性代数课本重新学一遍，而是指你对自己正在运行的每一个环节，都保有“能拆开看一眼”的能力和习惯。
这里的“零”更像是一张检查清单：给你一份没有标签的数据集，你能不能在半天内完成清洗、统计、可视化并产出特征报告？给你一个训练脚本，你能不能在五分钟内定位它是CPU瓶颈还是显存瓶颈？给你一个推理接口，你能不能在十分钟内回答出它的P99延迟和最大吞吐？这些能力组合起来，才叫AI工程的底子。它跟论文复现不一样，论文复现跑通就行，工程落地要的是可控、可测、可运维。
我自己带人时有个偏见：简历上写了五年PyTorch，不如现场手写10行反向传播来得可信。因为用过和懂过，在工程输出上是两种完全不同的东西。前者遇到问题时会换库、换参数、换网络结构去瞎试，后者会先停下来说“等一下，这个梯度的shape不对”。
1.2 AI工程与AI科研、算法调参的真正边界
很多人以为AI工程和算法研发是上下级关系，其实它们是两条并行的线。算法研发的产出是“模型效果”，核心指标是F1、AUC、BLEU这些数值；AI工程的产出是“系统能力”，核心指标是复现成功率和上线稳定性。算法可以只跑通一个Notebook，工程则需要把那个Notebook变成一个24小时无人值守、能自动恢复、能监控告警的服务。
举个具体例子：算法团队把一个新的精排模型离线指标从0.72提到0.75，这是成果。工程团队要做的，是把参数更新逻辑跟线上的特征管线对齐，把模型大小从2GB压缩到300MB以降低推理成本，把推理服务从单机串行改造成多副本负载均衡，还要让每次模型升级可以一键回滚。这四个事情里任何一个做不好，那个0.75就是纸上数字。
所以如果你真的想“从零开始学AI工程”，第一步不是去啃更多数学公式，而是先把你的目标切换到“交付一个可靠的系统”这条线上来。调试一个线上概率问题，和调试一个离线loss曲线，难度不在一个量级。
1.3 三个可以先跳过的基础和三个不能跳的
市面上很多教程喜欢劝你什么都学，我说点反话。以下三个基础内容，在你没碰到具体问题之前可以先跳过：第一，泛函分析和测度论，除非你要自己发明新模型；第二，分布式系统设计，除非你要写万卡调度器；第三，完整的编译原理，除非你要做算子融合。这些内容不是没用，而是它们离你前两年的日常工作太远，先去学只会消耗动力。
反过来，有三个基础劝你早点补扎实。一是线性代数里的矩阵求导，哪怕你只用显式求导的公式，也要清楚矩阵乘法中各个维度的含义，因为所有模型代码的bug本质都是维度不匹配；二是概率论里的条件概率和贝叶斯思维，因为线上AI系统做的一切决策本质上都是概率推断，你要能解释“为什么模型在这个样本上给出这个置信度”；三是Linux和Shell，因为从数据清洗到分布式训练再部署上线，你极少在Windows环境下完成，不会用命令行基本寸步难行。
2. 搭建环境：一套能复现、能折腾、能上线的技术地基
2.1 硬件与算力：别一上来就买显卡
“从零开始”的人最容易犯的错，就是先买一张四五万的卡，然后发现自己跑的模型调度不起来。我给你一个更务实的路径：第一年先在云上按小时租卡用。好处是你可以随时换型号、换显存，不用承担硬件折旧和散热那些破事。
如果你坚持本地折腾，从入门到进阶我推荐看这几个指标：算力看TFLOPS，显存看容量和带宽。显存带宽对训练和推理的影响往往被低估，它决定了你在每毫秒内能喂给计算单元多少数据。如果你要跑7B级别的开源模型做微调，显存至少得32GB起；如果是纯推理，至少16GB，否则量化都救不了你。另外注意电源和散热，我见过一张3090插在额定550W电源上直接黑屏重启的案例，这不是笑话，是工程事故。
2.2 环境隔离与依赖管理：conda、Docker、uv怎么选
Python环境的混乱程度，是AI工程的第一道下马威。搞了几年的人都会遇到“明明昨天还能跑，今天换了CUDA版本，整个训练环境崩了”的情况。为了避免这个，请从第一周就养成环境隔离的习惯。
conda适合管理Python解释器版本和部分底层库，但它在处理一些非Python依赖时力不从心。现在很多新项目直接上了uv，它比pip快非常多，依赖解析也更可靠，我个人的新项目基本都在用。但真正能达到“复现无痛”的，是Docker：把操作系统、CUDA驱动、Python库、模型文件全部打包成一个镜像，提交一份Dockerfile，别人就能在完全一致的环境里跑出一样的结果。
我在推进自己项目时定过一个规矩：任何训练任务，提交代码时必须附带一份可用的Dockerfile和requirements清单。没有这两样东西，哪怕代码写得再漂亮，这个任务也没有“工程”属性，因为别人无法复现，也就无法协作。
2.3 数据准备：直接决定训练成败的第一步
环境搭完了，一大半的人会急着去写模型结构，但我劝你先好好整理数据。数据问题有时候比模型问题隐蔽得多。比如你的模型训练loss总是降不下来，费了半天劲去换模型结构，最后发现是训练集里有大量重复样本；又比如你的模型线上表现和离线评估差出一个等级，原因可能是你把测试集的信息“泄漏”到了训练集里。
一个合格的数据管线应该长这样：原始日志存储、清洗去重、格式统一、堵漏（对缺失值策略明确）、采样策略、数据集版本管理。数据集版本管理这句话值得强调——训练模型用的数据是会变的，如果不对数据版本做记录，你无法解释“同一个模型，同一个代码，换了批次数据，为什么效果变了”。
这里再引用一句我常对组员说的话：数据管线里的清洗逻辑，是比模型结构更核心的工程资产。因为清洗逻辑里埋着你对业务的理解，它才是那个让系统真正“适配场景”的东西。
3. 动手写：从线性回归到最小Transformer的完整一条龙
3.1 为什么先手写梯度下降而不是直接调PyTorch
我建议所有人都手写一个线性回归和逻辑回归，用纯Python加NumPy，一步步把前向传播、损失计算、反向传播和参数更新这四个环节写出来。这个过程通常只需要几百行代码，但给你的回报是——你以后再也不会把“梯度消失”和“梯度爆炸”这两个概念搞混，也不会在看到某个网络层时只把它当作一个符号而不知道它内部发生了什么。
写到逻辑回归时，你会第一次真实理解“似然函数”长什么样，然后你会明白为什么交叉熵损失是分类任务的默认选择。这些基础不是空中楼阁，它们会在你调试真正的深度学习模型时反复回来找你。
3.2 一个真正“从零开始”的中文分词加词向量加训练循环
从线性模型跨到神经网络，最大的坎是理解词向量和序列处理。我建议从文本分类这个任务切入：用jieba做中文分词，把分词结果映射成一个词表，然后用一个简单的词嵌入层加一两个隐藏层，跑一个意图识别或情感分类。
这个过程中你一定会踩到几个经典问题：词典规模怎么定（太小容易UNK，太大占内存）、序列长度怎么截断（取均值还是尾部补零）、初始化对收敛的影响等。当你能用代码解释“为什么给同一个词分配不同上下文的向量是合理的”，说明你已经从“背API”进步到“懂机制”了。
再往后，我会建议你把注意力机制手工实现一遍。不必写完整的Transformer，但至少要把Q、K、V三个矩阵的计算和缩放点积的公式写出来，跑一个几百万参数的小模型，拿真实数据做训练。第一次训练时，“注意力矩阵可视化”出来的东西会让你上瘾，但更重要的是看清楚它的计算复杂度为什么是 $O(n^2d)$——这会直接影响你后续对长文本模型选型的判断。
3.3 训练循环里那些不写代码永远学不会的细节
很多初学者以为训练循环就是“喂数据、算loss、更新参数”这三步，实际上做工程时你要处理的细节多到吓人。比如学习率预热到底怎么设计，用了Adam是不是就能完全不管学习率；比如梯度裁剪的值设在多少合适，不同的模型对这个参数极其敏感；再比如权重衰减该不该加、加了多大，这些直接决定模型的泛化表现。
还有一个容易被忽略的细节：评测指标和loss之间的解耦。训练时我们通常用可导的loss来优化，但真正关心的是不可导的指标，比如F1、MAP、NDCG。所以你要在训练循环里周期性地做验证集推理，把指标算出来，并把指标变化记录到日志里。很多工程问题就是在这一步露出马脚的：loss在降，指标在跌，说明模型在过拟合某个特定模式，而不是在学真正的规律。
3.4 评估与调优：loss不是唯一指标
如果你只盯着loss曲线，会漏掉大量信息。我建议每个任务至少维护一份“模型评估四看”清单：一看训练loss和验证loss的间距，正常应该很近，如果越拉越大就是过拟合信号；二看验证集上分类别、分区间、分样本来源的指标，防止“平均分好看但群体不均衡”的情况；三看具体badcase，每周抽几十条预测错的样本，真正去读一读，看到底是数据标注错、模型类型错还是问题本身无解；四看稳定性，同样的数据和代码，多跑几次，方差很大说明初始化或随机性控制有问题。
调优的顺序也是门学问。我自己的经验是：先调数据（包括清洗、增强、去偏），再调模型结构（加深加宽注意力），再调训练策略（学习率、批次大小、正则），最后才动优化网络结构之外的招（比如集成）。因为数据问题占用了最多的实际调试时间，如果一上来就动模型结构，你根本不知道优化的是“模型”还是“数据噪声”。
4. 工程化落地：从“能跑”到“能用”再到“能上线”
4.1 模型部署的三种路径与真实选型
模型训练完，真正的工程挑战才刚开始。部署方案这些年演进得太快，但核心就三条路径。第一条是用FastAPI加PyTorch或TensorFlow Serving直接上线，开发效率高，适合实时性要求不那么苛刻的内部服务；第二条是把模型先转成ONNX格式，再用ONNX Runtime做推理，好处是跨框架、跨平台，且推理性能通常比原始PyTorch快不少；第三条是把模型转到TensorRT，针对NVIDIA GPU做深度优化，适合对延迟极其敏感的在线服务。
怎么选？我的经验是，小于百毫秒时延要求的服务，FastAPI加PyTorch足够；对并发和成本有要求的，优先考虑ONNX Runtime；如果你在做大模型推理，TensorRT配合量化和批处理几乎是必然选择。注意ONNX导出不是总顺滑的，某些算子不兼容时，你可能要在模型结构层面做替换，这就是为什么“从零开始”时要多留意模型里常用的那些操作。
4.2 显存、延迟、吞吐：三个绕不开的工程指标
做AI工程如果你不关心这三个数字，等于做后端不关心QPS。先说显存计算：一次训练迭代的显存占用大概是“模型参数量乘以优化器状态系数”加上前向激活值。用Adam优化器，参数量为N的模型，优化器状态约需要2N到3N的浮点数存储，因此32GB显存跑不了太大的Transformer训练，这个算式你要心里有数。
延迟和吞吐是互为表里的。低延迟追求单次请求返回要快；高吞吐追求单位时间处理的请求数要多。工程上常用批处理（batching）来同时提升吞吐和GPU利用率，但批太大会让延迟上升。最理想的做法是动态批处理：把毫秒级窗口内到达的请求攒在一起，凑一个批再送进GPU。这个方案做完后，同样的硬件能承接近两倍的线上流量。
4.3 版本管理与实验追踪：模型训练没有“后悔药”
算法研发阶段你可以随意在Notebook里跑实验，但一旦进入工程化，版本管理就是生死线。代码用Git管理这已经不用多讲，数据要用DVC或LakeFS这类工具做版本管理，模型文件要记录来源、训练日志、评估指标和上线状态。
实验追踪这块，MLflow和Weights & Biases是目前用得最多的方案。MLflow的优势是开源、可私有化部署，能管理完整的生命周期；WandB则在可视化对比实验曲线时特别顺手。如果你不想引入额外服务，用Git记录参数文件加固定的随机种子也能凑合，但长期下来一定后悔。
我自己的项目习惯是：每个实验都要有一个唯一ID，里面绑定配置、数据版本、代码版本、关键指标和模型权重地址。这样半年后翻回来，还能准确回答“当前线上这个模型是怎么来的”。
5. 实战避坑：AI工程里最常见的几个翻车点
5.1 训练不收敛：先查数据，别急着改模型
训练不收敛是第一大坑。你可能在尝试十个学习率、三种优化器之后才发现，问题出在训练集里有几千条标签是错的。先讲结论：当模型不收敛时，70%的概率是数据问题，20%是训练配置问题，只有10%是模型结构问题。
排查顺序要固定：第一步看数据样本的标签分布是否正常，有没有存在NaN或异常值；第二步看预处理前后样本的feature分布是否合理；第三步用一个小规模的干净子集跑几十步，确认loss能逐渐下降；第四步检查梯度是否有回传，好多人的模型“不收敛”，其实是因为某个API用错，梯度根本没到参数上。这个排查顺序能帮你避开大量无效调参。
5.2 显存溢出：不只是换大卡就能解决的事
显存溢出（OOM）看起来是个硬件问题，其实是个工程问题。最粗浅的办法是换大卡，但成本高。进阶的做法有三个：一是减小batch size，中间结果能少占显存；二是开启梯度累积，用小batch的梯度模拟大batch；三是用混合精度训练，把部分精度降到FP16甚至BF16，大部分模型的显存占用能直接砍半。
另一个很多人不知道的技巧是“按层释放激活值”：在前向传播时只保留反向传播必需的激活值，其他临时状态及时释放。这个在论文里叫activation checkpointing，工程上叫重计算，它跟显存-算力做了一次交换。如果这些都做完了还是溢，再回过头看模型结构——是不是某个输入尺寸设计得太大了，比如多头注意力里的序列长度，能不能先压缩。
5.3 过拟合与数据泄漏：隐蔽的“幽灵Bug”
离线指标好得吓人，上线后立刻崩塌，这是AI工程里最经典的翻车场景。数据泄漏的原因往往很隐晦：你可能把归一化统计量（均值和方差）直接用全量数据计算，而没有严格只用训练集，导致验证集也被“看过”；也可能在时序任务里随机切分样本，导致未来信息混进了训练集。
排查数据泄漏有一个笨但有效的方法：拿训练好的模型去“预测”训练集本身，如果正常效果应该因为过拟合而好，但不同寻常的是，再用一张随机的噪音特征试一下，如果模型预测仍然极有信心，说明它学到了不该有的捷径。另一个习惯是把数据切分逻辑写成函数并做单元测试，每次训练前花五分钟检查训练集和验证集之间有没有样本重叠。
5.4 工程日志与反思清单：可持续进步的唯一方法
踩坑不可怕，可怕的是踩完就忘，下次继续踩同样的坑。我坚持给每个任务写一份“工程日志”，包含这几个板块：任务目标与评估指标、数据描述与版本、关键代码变更、训练曲线截图、badcase分析、以及一个“下次遇到类似问题先做什么”的批注。这样累积上百条之后，你会发现自己解决新问题的速度比之前快了好几倍。
以我自己带项目的体会来说，多数人卡在AI工程门槛上，缺的不是聪明，而是闭环：从问题定义、数据理解、模型开发、部署验证，到复盘沉淀，每一步都要有真正的产出物。这条路径没法速成，但它每走一步，都会在你脑子里留下一个可复用的工程模板。等到你能不看文档就把一个模型从零跑到上线，那种“手里有系统”的感觉，跟初学阶段那种“眼前全是API”的眩晕感，完全是两个世界。