ai-engineering-from-scratch，这个项目名是我给自己定的一条路线，而不是某个现成仓库的克隆。周围不少人听到"从零学 AI 工程"的第一反应是去薅一堆免费教程、跟着视频敲一遍就完事，但我亲测下来，这种学法最大的问题是：三个月后你确实会跑通几个 demo，却依然说不清楚一条数据从入库到被模型消费、再到上线服务的完整链路。这篇内容不是课程广告，也不是技术手册的搬运，而是我把完整路线重新走了一遍之后留下的笔记，适合那些刚入行、以及在业务团队里被要求"顺手搞搞 AI"的开发同学。读完之后你应该能清楚自己缺在哪一块、下一周该补什么，以及那些教程里不会告诉你的真实工程坑。
1. 从零开始的三个前提：先破除直觉上的错误认知
1.1 第一条幻觉：AI 工程不就是调接口吗
等等，我先说清楚我不是否定调 API 这个动作本身。今天很多业务场景，调一个 OpenAI 或国内大模型的接口就能解决 80% 的需求，这确实是 AI 应用开发的主流形态。但"调用接口"和"AI 工程"之间，隔着一条完整的生产链路——数据从哪来、怎么清洗、怎么构造上下文、结果怎么评估、失败了怎么兜底、上线之后怎么监控。你调通一个接口，只证明你完成了最后一个环节里的一小步；而工程要做的是让这个动作在真实流量的冲击下稳定、可控、可度量地反复发生。
我给这个项目起名的时候专门用了 from-scratch，想强调的就是：不要把别人的成熟框架当成理所当然，而是要把从数据到模型再到服务这条链路的每一环都亲手摸一遍。只有亲手建过，才谈得上拆和改。我自己最早也是从"调接口跑通一个聊天机器人"上路的，那个项目给了我很大的信心，但也让我误以为 AI 工程不过如此。直到后来业务方要求我回答"这个回答质量怎么量化""并发一上来会不会崩""换个模型价格差多少"的时候，我才发现自己对整条链路一无所知。
1.2 第二条幻觉：数学不好就不配学 AI
这个观念害了很多人，包括我自己早期也差点被劝退。坦白讲，如果你目标是做前沿算法研究，数学确实要过硬；但 AI 工程是系统性的工程学科，不是纯理论研究。我见过很多一线 AI 工程师，日常大量工作集中在数据质量、评测体系、服务编排、异常处理上，高深的数学一年都用不上几次，用得最多的反而是概率直觉和统计思维——准确率、召回率波动意味着什么，采样偏差会带来什么影响，这些靠的是"按需补课"而不是本科数学全套。
我的建议很直接：先动手，哪里卡住补哪里。模型训练跑起来之后，你自然会发现自己缺矩阵运算的理解，缺损失函数的直觉，那时候再回头学，效率完全不一样。这个原则叫 just-in-time learning，开发者社区早已验证过它的有效性。拿我自己举例，第一次在训练脚本里看到 transpose 和 view 的用法区别时完全懵了，于是花了三个晚上把线性代数的维度和矩阵乘法过了一遍，从此再遇到张量形状问题，基本一眼就能定位。这种带着问题去学的方式，比从第一页看到最后一页扎实得多。
1.3 第三条幻觉：跟完教程就等于学会了
跟着教程敲代码的时候，大脑会产生一种"我全会了"的错觉，因为每一行代码都是对的，所有环境都是配好的，数据是干净的，目标是一步到位的。真实世界里，你接到的往往是一句"帮我把这个月的数据跑出来看看"，数据是脏的，目标是模糊的，错误信息是不会告诉你出处的。教程给你的是"标准答案"，而工程要处理的是"没有标准答案"。
所以这个项目从一开始就没有把"做多少节课"或"复现多少个开源仓库"当作目标，而是以"能不能独立把一个端到端任务做完"来检验自己。做完一个任务，比看十个教程都有用。后面我会具体讲我是怎么设计这些"任务"的。顺便说一句，检验"学会了"有个很土但是很有效的标准：关上教程页面，重新打开一个空白的项目目录，如果你还能从零写起、不翻笔记，这个过程才算真正内化了。
2. 岗位定位：AI 工程师和旁边几个角色到底差在哪
2.1 为什么这个问题值得先想清楚
我见过太多准备入行的人，在学习清单里同时堆了机器学习理论、深度学习框架、数据分析、后端开发、产品设计，最后哪个都没深入。原因很简单：他们没想清楚自己要成为什么角色，于是什么都要学。AI 工程是一顶帽子，不是一棵树的全部枝丫。先把它从其他角色里剥离出来，学习路径才能聚焦。搞清楚岗位定位还有一个实际好处：它能帮你直接映射到招聘 JD 上的技能要求。你去翻十份"AI 工程师"的岗位描述，再翻十份"算法工程师"的岗位描述，把出现频率最高的技能词拉一个交集，自然会知道自己要补什么。
2.2 和机器学习工程师、数据科学家的分工差异
为了说清楚边界，我用一张表来对比现在的典型分工：
| 角色 | 核心产出 | 典型工作内容 | 常用工具 |
|---|---|---|---|
| 数据科学家 | 洞察与模型原型 | 数据分析、特征探索、模型选型实验 | Python、SQL、Notebook |
| 机器学习工程师 | 可复用的模型服务 | 特征平台、模型训练与优化、上线评估 | PyTorch、Kubernetes、MLflow |
| AI 工程师 | 完整的 AI 应用系统 | 数据链路、模型调用/微调、RAG、Agent、评测与监控 | LangChain、向量库、API 网关、Prompt 框架 |
你会发现 AI 工程师的独特之处在于：它不追求创造新的模型结构，而是追求把模型能力稳定地嵌入到业务系统中。这决定了它需要的是"横向贯通"的能力——数据库、服务端、模型 API、前端交互、评测体系，你不需要每样都精，但每一样都得能接上线。如果拿建筑来类比，算法工程师是设计院，负责画图和论证结构可行；AI 工程师是施工总包，负责把图纸变成能住人的房子，还要管水电、管线、验收和后续维护。
2.3 AI 工程师的核心能力清单
我把自己训练时的能力要求归纳为六项：
- 数据工程基础：能写 SQL 取数、会用 pandas/Spark 做清洗、理解数据血缘与质量。
- 模型应用能力：会调用 API、会做 prompt 工程、能做轻量级微调，知道模型能力边界。
- 评测体系设计：能给一个 AI 功能设计离线指标和在线指标，并能解释指标波动的含义。
- 服务化部署：能把模型包成 HTTP 服务，能处理并发、超时、降级。
- 可观测性：能记录日志、监控延迟与成功率、设置告警、追踪异常案例。
- 成本意识：能计算一次调用的成本，能在效果和花费之间做出理性权衡。
这六项里，前两项占了学习曲线的大部分，后面四项往往是被忽略的，但真正到了生产环境，它们才是决定项目成败的关键。我自己在第二个月做第一个端到端项目时，前两项很快就做完了，反而在部署和监控上花掉了三周。但也正是因为那三周的折磨，我才真正理解了"AI 工程"的核心不在模型，而在系统。
3. 地基阶段：编程、数学、数据，按需学而不是从头啃
3.1 编程：Python 学到什么程度算够用
这里的标准不是"成为 Python 专家"，而是"能快速把想法变成可运行代码"。我的判断标准是三条：能熟练使用 pandas 做数据透视和清洗；能看懂 numpy 的基本广播规则；能独立写一个类、装饰器、异常处理，把逻辑组织成可维护的函数。达到这个程度后，语法层面的学习就该停止，剩下的语法细节全部靠搜索和 AI 辅助工具现场解决。
写代码的时候，有一个习惯值得从第一天就养成的：做任何数据集操作前先备份原始数据。
提示：读进来之后立刻复制一份 raw 版本，之后所有清洗操作都基于副本进行。这不是一句废话，而是我用一次"数据消失"换来的教训。
我早期在这个问题上吃过亏，用 pandas 直接 dropna 之后还重新赋值，最后发现数据少了 10%，再想找回原始文件已经来不及了。工程习惯从来都不是什么高深道理，就是这些每天重复几十次的自我保护动作。
3.2 数学：能画出一条最小学习曲线吗
可以。进入模型相关的实战之前，你真正需要的是三块基础：
- 概率与统计基础：理解分布、期望、方差、条件概率、贝叶斯思想。这块对评估模型输出、判断数据漂移最有用。
- 线性代数基础：向量、矩阵、矩阵乘法、维度变换。理解 embedding 和 Transformer 的 self-attention 都离不开这些。
- 微积分基础：导数、链式法则、梯度下降的概念。不要求会手推复杂公式，但梯度怎么沿着 loss 曲面走这个直觉得有。
这三块怎么学？我建议不要直接抱着一本《深度学习》从头啃，而是先用 3blue1brown 的线性代数系列和微积分系列建立直观，然后边写代码边回头翻书。AI 里的数学多数是"工具性"的，知道什么时候用什么工具，比每一步都亲手推导重要得多。记住：数学是给你"看懂 model card 和训练日志"用的，不是给你当拦路虎用的。
3.3 数据：被严重低估的入门关卡
很多人把 AI 入门理解成"模型入门"，但真实项目里 70% 的时间在跟数据打交道。从零开始学 AI 工程，数据能力至少要覆盖三件事：用 SQL 把需要的字段从数仓捞出来、用 pandas 完成缺失值/异常值/重复值处理、能看懂一个数据集里每一列的含义并能发现其中的统计陷阱。
我给你一个具体的自查题目：给一份包含 10 万条用户行为记录的 CSV，你能在半小时内完成"去重、按时间排序、统计每个用户的会话数"吗？如果做不下来，说明数据基本功还没过关。这道题不涉及任何模型知识，却是很多 AI 项目第一个卡壳的地方。
3.4 环境与工具链：先把"能跑起来"的底子打好
数据、代码、数学之外，还要花一点时间把本地实验环境理顺。我的标准配置很简单：Anaconda 管理 Python 环境，Jupyter 做探索性分析，VS Code 写正式脚本，Docker 留着部署阶段再用。这个阶段不要去折腾 GPU 集群、云原生产品，一台普通笔记本足够跑完入门到部署的全部任务。
环境问题的核心原则是"可复现"：把依赖清单写进 requirements.txt，把关键包的版本号记录下来。我见过太多反例——项目在本机跑得好好的，换个同事的机器就报错，最后发现是 numpy 版本不一致。这种问题不解决，后面的协作和上线都会寸步难行。
4. 主线链路：从原始数据到稳定服务的四段航程
4.1 数据处理：清洗与特征，决定模型上限的地基
模型的上限不取决于算法有多先进，而取决于喂给它的数据有多干净。清洗环节有一串固定的步骤：去重（同一用户的重复行为）、缺失值处理（是删行、填默认值、还是用统计方法插补）、异常值识别（超过 N 个标准差的是噪声还是真实极端值）、格式统一（时间戳、单位、文本编码）。
真正让我学到最多的是一次"看似干净实则埋雷"的数据集：销售数据里金额字段有负值，原因是订单被退款了，但文档里并没有说明。如果拿这个字段直接训练，模型的预测会被退款样本严重带偏。所以我现在做每个数据集的第一件事永远是"列级体检"——每一列是什么类型、取值范围是什么、有没有业务上不合理的数值。这步不需要什么高深工具，groupby + describe 就能完成大半。
特征工程方面，初级阶段的重点不是创造复杂特征，而是理解"模型看到的是什么"。文本类任务里，切分长度、是否加摘要、是否有检索上下文，这些选择最影响效果；结构化任务里，归一化、分箱、类别编码是基本操作。我的经验是：每一个特征变换，都要在笔记本里留下记录，否则几个月后你会完全想不起这个字段是怎么构造出来的。
4.2 建模选型：什么时候该调 API，什么时候该自己训
这是 AI 工程里最需要判断力的选择题，我给一个简化但实用的决策流程：
- 需求能不能靠现有大模型 API 直接满足？能，就用 API。这是成本最低、迭代最快的路径。
- API 效果到了瓶颈（幻觉严重、格式可控性差），但领域数据量不大？考虑微调一个开源基座模型。
- 数据量巨大且有特殊结构（非文本、多模态、超长序列）？这时才需要认真考虑从预训练或复杂架构入手。
把这个决策练熟，比盲目跟风"我必须自己训一个模型"高级得多。很多团队死磕本地训练，最后发现效果还不如一个精心调过的 prompt，且推理成本高出几十倍。我举一个具体例子：做一个客服工单分类器，如果你手头有 2000 条带标签数据，用大模型 API 加 few-shot 就能达到 90% 以上的准确率；自己训练一个模型从零调参，很可能两三天都追不上这个效果。工程上"够用 + 可控 + 可迭代"永远是第一位的。
4.3 评估：没有评测体系，AI 工程就是"靠感觉开发"
评估是整个 AI 工程里最容易被跳过的环节，也是我最后悔没早点认真对待的环节。一个 LLM 功能上线之前，至少要有三层评估：
- 规则评估：输出是否符合格式要求、关键词是否齐全、长度是否合理。可以用正则或简单的校验脚本完成。
- 数据集评估：准备一批有标准答案的测试样本，计算准确率、召回率、F1。这批测试样本要针对边界情况设计，不能只有"正常提问"。
- 人工抽检：定期抽一批线上真实输入，人工判断输出质量，并反哺进测试集。
有了这三层，你才能回答"这个功能改完到底变好了还是变坏了"——这个问题在 AI 项目里远比想象中难回答，因为模型输出有随机性，单凭几次肉眼观察根本不可靠。我第一次优化一个问答系统时，凭感觉觉得新 prompt 效果好，上线后指标反而掉了 5 个点，就是因为没有先做离线评估。从那之后，"先评测后上线"成了我给自己立的规矩，谁也不能跳过。
4.4 部署与发布：能简单就别复杂，但底线不能省
部署这件事，我的建议是：第一版能简单就简单。一个 FastAPI 服务、一个模型加载模块、一个内存队列做并发控制，就可以跑起来了。不要一上来就上 Kubernetes、GPU 弹性伸缩、多区域容灾这些重型设施，那是在用架构复杂度掩盖"还没有真实流量"的空洞。
但有几个底线不能省：超时与重试机制（上游模型接口会慢会挂）、降级策略（模型挂了要返回兜底结果而不是白屏）、并发上限控制（不至于被流量打死）。这些不是 AI 知识，是普通后端工程的常识，但很多 AI 项目恰恰死在这里——模型准确率很高，服务一上线就超时崩溃。我自己第一次部署时也踩过这个坑：一个同步调用模型的接口，没有设置超时，模型服务一卡，整个 Web 服务线程池就被占满了，所有请求排长队，最后线上直接雪崩。后来只是加了一个 3 秒超时和一个简单的队列，问题就解决了。
5. 真实战场：被生产环境教育过的五个细节
5.1 数据漂移：模型上线一周后效果开始悄悄变差
我第一次上线一个文本分类模型，前三天效果很好，一周后 F1 明显下滑。排查了很久才发现，用户提问的分布变了——上线前测试集里多是短句和标准问法，真实流量里出现了大量长句、方言和口语化表达。这不是 bug，这是 data drift，是 AI 系统最普遍的慢性病。
对抗漂移的手段不是一次性的，而是要常设：记录输入数据的分布画像（长度、关键词频率、主题分布）作为基线；定期重算线上分布并对比基线；当偏差超过阈值时触发告警。这听起来复杂，但用一个简单的统计脚本加一张趋势图就能跑起来，关键是有没有这个意识。顺带说一句，当你发现某个模型"最近好像变笨了"，先别急着怀疑模型出了问题，多半是输入分布的锅。
5.2 模型版本管理：一个模型文件引发的"血案"
模型不是代码，一个 2GB 的权重文件，Git 是管不动也管不好的。团队里需要一套针对模型产物的版本管理方案：命名规则带上日期和数据版本（例如 sentiment_model_20250115_v3.pt），元信息里记录训练数据、超参数、离线指标；上线时把"代码版本 + 模型版本 + prompt 版本"三者绑定，才能保证出了问题能回溯。
我踩过的坑是：有一次更新了 prompt 模板，但没有更新版本号，线上跑了 3 天，业务方反馈质量下降，我却查不到任何变更记录，只能靠猜。从那以后，所有影响模型输出的变更，都必须过一遍"变更单"，记录时间、内容、预期影响。这个习惯在一个人做项目时看起来多余，一旦进入团队协作，它就是救命稻草。
5.3 监控与告警：你不可能 7x24 盯着日志
生产环境里，模型服务会静默地坏掉：接口返回 200，但内容全是空字符串；延迟不涨，但缓存命中率掉到零；准确率没变，但某个高频类别肉眼可见地在瞎答。没有监控，这些只能等用户投诉了才知道。
我建议最基本的监控面板至少要有四个数字：请求量、平均延迟、错误率、空输出率。比面板更重要的是告警——数值异常时能不能及时通知到你。
提示：我这里常用的经验阈值是：延迟均值 +2 个标准差，错误率超过 1%，空输出率超过 0.5%，任一触发就告警。实际项目按自己的数据基线调整，但一定要有。
告警不是越多越好，告警疲劳比没有告警还可怕。我的原则是：只对"需要人介入"的异常告警，能通过脚本自动恢复的问题就交给脚本。
5.4 成本与延迟的博弈：效果很好但用不起
大模型调用按 token 计费，token 数直接决定单次调用成本。优化成本的常见手法包括：缓存高频问题的答案、用小模型做初筛大模型做精修、限制输入长度或压缩上下文、批处理非实时任务。延迟也一样，不是越高频越好——检索召回 top 5 还是 top 20，效果差距可能很小，但延迟翻倍。
我见过一个团队，为了追求一个点的准确率提升，把每次请求的上下文塞满了 8000 token，结果单次成本涨了十倍，客户因为响应太慢直接流失。工程思维在这里体现为一句扎心的话：效果好到用户用不起，等于没效果。合理的做法是先定一个目标延迟和单位成本预算，再反过来约束 prompt 长度和模型选型，而不是先追求效果再无限追加预算。
5.5 安全与合规底线：不该碰的数据一次都不能碰
AI 工程处理的数据往往涉及用户隐私和合规问题。我的原则很简单：第一条是"能拿最少就拿最少"——只需要用户 ID 和文本，绝不冗余采集 IP、设备信息；第二条是流程隔离，用于模型训练的数据必须经过脱敏，日志里不能出现明文手机号、身份证号；第三条是不做踩线功能，任何可能侵犯用户权益或引发争议的功能设计，在一开始就主动砍掉。工程设计上的克制，是 AI 工程中最难但最必要的成熟。
6. 我的三个月路线图：每天两小时能走到哪
6.1 阶段拆解：第一个月打地基，第二个月走主线，第三个月做闭环
按每周 10-14 小时估算，我给自己规划的三阶段如下：
第一个月（150 小时以内）：完成 Python 数据能力自查、补概率与线性代数直觉、能独立完成一份 CSV 数据清洗报告。验收标准就是前面那道 SQL 和 pandas 自测题，以及一份能讲出"每一列怎么来、为什么这样做处理"的数据说明文档。
第二个月：完成一个端到端的最小项目，比如"基于公开数据集的情感分类服务"。拆成四个子任务：取数清洗、模型微调或 API 调用、离线评估、FastAPI 部署。每一步都记录问题和解决方案，最后写一份一页纸的项目总结。这个项目会成为你的"代表作"，后面无论是面试还是接项目，都可以直接拿出来讲。
第三个月：给第二个月的项目加上"生产级配件"——监控指标、版本管理、降级策略、成本估算，并尝试第二到三个方向（RAG 问答、Agent 场景、结构化输出），每个方向只做最小验证，目的是拓宽视野而非深入精耕。这一阶段的核心目标是"闭环"，即每个小项目都走完数据、模型、评估、部署四个环节，哪怕每个环节都很浅。
6.2 资源清单：我实际用下来没被劝退的四个来源
- 官方文档：PyTorch 官方教程、FastAPI 官方教程、主流模型平台的 API 文档。优先级最高，因为代码一定是新的，且不存在"二手信息过时"的问题。
- 经典书籍：李航《统计学习方法》适合补概率与模型直觉，但不用全看，挑支持向量机、决策树之前的部分即可。进阶阶段再考虑《深度学习》（花书）和《Designing Machine Learning Systems》。
- 开源项目：找 2-3 个 star 高且文档全的项目读代码，重点读数据处理和部署部分，不要只读模型部分。读代码的时候可以尝试"删掉一行看会发生什么"，这是最快理解一段逻辑的方式。
- 社区与博客：关注一线工程师的博客和案例分析，比看营销味很重的"AI 速成"文章靠谱得多。判断标准很简单：作者有没有提到具体失败案例和指标数字，通篇都是"强大、高效、领先"的基本可以直接跳过。
还有一条使用 AI 工具的建议：利用 ChatGPT 或 Claude 当"随身导师"是可以的，但要防止自己被它惯坏——每让它生成一段代码前，先自己尝试写出思路，再让它评审。否则三个月后你依然不会写代码，只是会复制粘贴。我见过太多"AI 原生学习者"能跑通一切 demo，但被问到"为什么这里要加异常处理"时一句话都答不上来。
6.3 实操中反复出现的三个心理关口
第一个关口是"感觉自己什么都不会"。这是正常的，因为你开始接触的都是别人封装好的概念，你会觉得自己在假装学习。破解方法是回到"完成度"——每完成一个可运行的小目标，这种恐慌就消失一点。你把一个 API 调通了、把一个 CSV 洗干净了、把一个服务部署上线了，这些"完成的事件"比任何知识点都更能支撑信心。
第二个关口是"模型效果怎么都不对"。学习阶段的模型往往效果很差，这不代表你方向错了，可能是因为数据量太少或特征没做好。这时候最有效的动作是把错误样本打出来看，一个一个看，看懂了错误你才懂模型。我一直觉得，看错误样本比读十篇论文都有用，因为错误样本会告诉你模型真正在学什么。
第三个关口是"到底该深入还是该铺开"。我的经验是：主线上必须有一个项目走完部署监控的闭环（这是你的代表作），侧线上多试几个方向找手感。没有代表作的人，简历上写再多课程证书都没用。这个取舍会反复出现，最好每隔两周就主动复盘一次，把自己花的每一小时记录下来，月底看统计，比凭感觉决策靠谱得多。
这个项目走到现在，我最大的收获不是"会跑多少个 demo"，而是建立起一套面对不确定性时的判断框架：从数据怀疑开始，用评测说话，让监控证明，最后用成本和安全把关。ai-engineering-from-scratch 这条路线，真正的译名其实不是"从零学 AI 工程"，而是"亲手把 AI 的每一个工程环节都过一遍"。如果你也在路上，记住一句实在话：不要和别人的进度比，和高楼比你会焦虑，和昨天的自己比，你每天都在长高。
