1. 先搞清楚AI工程师的职责边界：不是调包侠，也不是炼丹师
我在这个领域泡了几年，一个很深的感受是：AI工程师这个头衔被用得太泛了。有的团队招AI工程师，实际是让写爬虫加调接口；有的团队希望AI工程师从论文复现到模型上线全包；还有的老板以为会个深度学习框架就能当AI工程师用。题目标题叫“ai-engineering-from-scratch”，说白了就是想知道从零起步到底要学什么、练什么，而不是被各种铺天盖地的课程列表吓住。
我自己对AI工程师的定义比较朴素：**能用系统的工程方法，把机器学习或大模型能力稳定地落到真实业务场景中，并且对它上线之后的表现负责。**这个定义里最关键的两个词，一个是“稳定”，一个是“负责”。训练一个离线指标还不错的模型，和上线一个能扛住流量、能处理脏数据、能持续迭代的模型服务，中间隔着大量工程细节。很多新手在Kaggle上能刷出好看的分数，但一接触真实业务就手足无措，原因就是工程能力没有跟上模型能力。
1.1 为什么这个岗位不是“会调参”就行
把时间倒回七八年，机器学习工程师的核心工作确实集中在特征工程、模型调参、离线评估这几件事上。但现在的AI工程，尤其是大模型起来之后，工作重心发生了明显转移：数据管道的稳定性变成了第一位，模型评估体系的设计变得复杂，服务的延迟和成本必须精细化控制，还要处理幻觉、安全、权限这些以前不必太担心的问题。
举个例子。你做了一个基于向量检索的问答机器人，模型本身可能只是调用现成的Embedding接口加一个大模型，看起来“没有训练”，但工程难度一点没降。你需要处理文档切分，要决定切分粒度，要考虑召回率与准确率的平衡，要设计Prompt模板让模型在“不知道”的时候敢于说不知道，还要在用户反复追问时保持上下文一致。这些问题没有标准答案，只能靠工程经验和系统化的调试方法来逼近。所以从这个角度说，AI工程师的能力模型更像“系统工程师+机器学习基础+产品思维”的杂交体，而不是单纯的理论研究者。
1.2 从数据科学家到AI工程师：能力地图的迁移
我经常被问到：数据科学家和AI工程师有什么区别？我的理解是，数据科学家更偏向“探索未知”，通过统计分析、实验设计来发现问题、量化问题；AI工程师更偏向“把确定的东西稳定交付”。在成熟团队里，数据科学家拿出可行的方案，AI工程师把它变成可靠的产品，两者之间有重叠，但侧重点明显不同。
这也就解释了为什么很多人转型AI工程师时会觉得别扭。如果你原来是数据分析师，你习惯的是写SQL、做可视化、跑AB实验，面对“把这个模型封装成服务并压测到毫秒级延迟”这种任务会无从下手。如果你原来是后端工程师，你擅长的是高并发、缓存、微服务，但面对“为什么验证集指标和线上指标差距这么大”这种问题也会一头雾水。AI工程师恰恰需要同时补这两块短板。
2. 从零开始的四根支柱：数学、代码、模型、系统
很多新手问我的第一个问题就是：数学要达到什么水平？网上说法两极分化，有人说微积分线性代数概率论都得精通，有人说现在都是调包根本不用数学。我的看法比较中庸：经典机器学习入门必须有基本的数学直觉，但不需要推导全部公式；深度学习工程化则需要更强的实验思维，而不是数学推导能力。
2.1 数学学到什么程度才算够
我把数学要求拆成三个层级来说：
- 线性代数：理解向量、矩阵、矩阵乘法、点积的含义就够了。Word2Vec需要点积算相似度，Transformer的注意力机制本质也是矩阵运算，Embedding检索更是直接基于向量的相似度计算。你不需要手推SVD分解，但看到相似度矩阵必须知道它在干嘛。
- 概率与统计：需要理解分布、期望、方差、条件概率、贝叶斯思想。评估指标比如精确率、召回率、AUC，本质都是统计概念。更重要的是，理解“不确定性”是AI工程师的日常——模型输出是概率分布，不是确定答案，所以系统设计要留有余地。
- 微积分：只需要记住梯度下降的基本逻辑：沿梯度反方向更新参数，让损失变小。深度学习里95%的优化问题都是梯度下降的变体，所以你不需要会推导链式法则的直接展开，但得知道学习率太大为什么会震荡，梯度消失大概是什么机制。
我的建议是不要线性地先把数学学完再去碰代码，那是错误的顺序。更有效的路径是：做项目时遇到哪个数学概念，就花半天补哪个概念。你学逻辑回归时补Sigmoid函数的性质，学Transformer时补注意力公式里的缩放因子为什么是根号d_k。这样学得慢，但每个知识都有锚点，不会学完就忘。
2.2 编程能力：Python是必须的，但工程素养不能丢
Python是AI生态的绝对主力，这个没有争议。你需要熟练使用NumPy、Pandas、Matplotlib这些基础库，至少要达到“不查文档也能写出数据处理脚本”的程度。但我重点想说的是另一件事：很多自学AI的人Python功底只停留在Notebook层面，这是远远不够的。
真实部署环境下，AI工程师要和后端代码、CI/CD流程、监控告警系统打交道。你需要掌握至少这些工程基础：
- 函数、类、模块的基本组织方式
- 异常处理与日志记录
- 版本控制（Git是底线）
- 基础的Linux命令和Docker使用
- 单元测试的基本思路
尤其是测试这件事，我踩过很大的坑。早期我改了一个数据预处理函数，自己觉得没问题就提交上线了，结果因为一行索引逻辑写错，导致线上特征全部错位，模型表现断崖式下跌。如果有单元测试，这种问题在提交前就能暴露。所以我不厌其烦地跟新人强调：模型代码的测试，和业务代码的测试同等重要，你甚至要更小心，因为数据类bug往往超安静，不报错，只是算出来的东西是错的。
2.3 模型知识：经典机器学习绕不开
Deep Learning很热，但我不建议零基础的人直接上手Transformer。原因很简单：如果你不理解过拟合、正则化、偏差方差权衡这些基本概念，你在深度学习中遇到的各种奇怪现象都无从解释。模型不收敛、验证集指标高得离谱但线上崩盘、训练集loss下降但验证集loss上升——这些问题背后都是机器学习的经典原理。
所以我的学习路线建议是：先用逻辑回归、决策树、随机森林这些经典算法建立“模型是怎么学习的”基本心智模型，再进入神经网络。好消息是，今天有大量高质量开放课程，不用啃大部头教材，但一定要亲手写代码实现。哪怕是只实现一个最简单的感知机，也比只看十遍教程强。
3. 从零跑通第一个端到端项目：选什么题、走哪些步骤
理论和实践之间隔着一条巨大的鸿沟。我想给一个非常具体的建议：**不要以“学算法”为目标，要以“跑通一个端到端项目”为目标。**所谓端到端，就是从原始数据开始，经过清洗、特征处理、模型训练、评估、部署上线，最后提供一个对外可访问的API或界面。这个完整链路你跑过一次，后续所有学习都会顺很多。
3.1 选题要小，但链路要完整
我见过不少人第一个项目就选“构建一个智能问答系统”，结果被卡在数据收集阶段，一个月过去还没开始写模型代码。我的建议是选一个数据集公开、目标单一、评价指标明确的任务。
这里有几个具体的选题方向供参考：
- 垃圾短信分类：二分类任务，数据量小，训练快，评估指标直观
- 影评情感分析：经典NLP入门，可以对比不同文本表示方法的效果
- 房价预测：回归任务，特征工程能玩出花样，适合理解数据质量的重要性
- 手写数字识别：CV入门，但链路太短，只做分类不做部署的话收获有限
我自己比较推荐垃圾短信分类或影评情感分析，因为它们天然是文本任务，和大模型时代的工作有承接关系。完成一个文本分类项目后，你再去看ChatGPT时代的文本任务，会发现很多技术是相通的。
3.2 数据处理阶段最耗时也最见功夫
如果说这个项目里有一半时间应该花在哪，那就是数据处理。我这么说不是夸张。真实场景中的数据通常长这样：字段缺失、格式混乱、语义重复、标签噪声大。很多初学者拿到的都是Kaggle上清理过的数据集，觉得数据预处理不过如此，这是很大的错觉。
以文本分类为例，你需要处理：
- 文本去重：同一句话被重复采集
- 标签纠偏：标注不一致的情况如何取舍
- 文本长度分布：长文本要不要截断，短文本要不要补齐
- 数据不平衡：正负样本比例失调时，评估指标选择会受影响
我当时在处理影评数据时发现，数据里有大量HTML标签和转义字符没被清理干净，简单的正则替换搞了好几轮才基本弄完。这活儿很枯燥，但结果立竿见影——模型在同量级数据上的F1分数直接提升了近8个百分点。所以我很想告诉新手：不要急着调模型结构，先把你手里的数据看成最大变量。
3.3 训练和评估：怎么判断模型真的可用
当你终于跑通了模型训练，下一关就是评估。最经典的错误就是只看准确率。二分类场景中如果正负样本比是9:1，你全部预测为多数类也有90%的准确率，但这个模型毫无价值。所以至少要看精确率、召回率、F1，如果有排序需求还要看AUC。
更进一步的评估思路是分维度看错误。我一般会做一个“错误分析”步骤：把模型预测错的样本挑出来，人工查看它们到底长什么样。很多信息会从中冒出来，比如：
- 模型总是把长度很短的文本判成某一类
- 包含某个特定关键词的样本几乎必错
- 训练集里某个类别的样本太少导致几乎学不到模式
这些发现会反过来指导你的特征工程和数据补充策略。这一步看起来“土”，但比研究新模型有效得多。
3.4 部署：从一个简单的API服务开始
对很多纯做算法的人来说，部署是最陌生的环节。我的建议是不要一开始就上微服务、K8s这些重型架构，先用FastAPI写一个最朴素的HTTP接口，把模型推理逻辑包进去，能在本地跑通，再用Docker打包，就足够了。
部署时要注意的一个关键点是模型文件和代码分离。不要在代码里硬编码模型的路径或参数，用配置文件或环境变量管理。这样后续模型迭代时，你不需要重新部署整个应用，只需替换模型文件并重启服务。另一个容易忽略的点是请求输入校验，尤其是文本类接口，用户传一个超长的文本或空字符串可能导致模型推理异常，必须在接口层做好防御。
4. 跑通项目之后的学习进阶：经典ML到深度学习再到LLM应用
第一个端到端项目完成以后，你会发现自己对AI工程的整个链路有了体感。这时候再进入深度学习、大模型应用这些领域，就不会像空中楼阁一样悬着。学习进阶的顺序，我建议还是按“按需深入”而不是“全面铺开”。
4.1 深度学习入门的正确姿势
我的建议是找一门结构清晰、带代码实现的课程或教程，而不是直接读论文。深度学习入门最忌惮的是“死磕数学推导”——不是推导没用，而是在你还没有直觉之前，推导的结果无法在大脑中落地。
一个人比较高效的学习方式是：**每隔一段时间拿一个经典模型（如CNN、LSTM、Transformer），亲手用PyTorch实现一遍关键组件，然后在真实数据集上训练，观察训练曲线和异常行为。**比如你实现了Transformer的多头注意力后，可以用一个较小的文本分类任务去看不同头数、不同隐藏维度对效果的影响，这种实验带来的理解深度远超读十篇讲解文章。
4.2 大模型时代的三个新基本功
经典机器学习还没完全消化，大模型浪潮已经来了。很多新人焦虑：那我还要不要学经典机器学习？我的回答是：要，但时间占比可以缩小。大模型应用开发有了几个新的基本功，这些技能在经典ML课程里往往不教：
- 提示词设计：虽然很多人觉得这只是“写话”，但真正稳定可靠的Prompt背后是有系统方法的：角色设定、任务拆解、输出约束、示例引导、兜底规则。
- 检索增强生成（RAG）：如何把私有知识库接入大模型，涉及文档解析、切分、Embedding、向量检索、重排序这些环节，每个环节都有大量微调空间。
- Agent设计与工具调用：如何让模型自主调用外部工具、如何设计工具协议、如何控制循环次数与异常处理。
这三个技能的学习成本比训练一个大模型低得多，但商业价值很高，也是当前AI工程师岗位需求里最旺盛的部分。
4.3 从“模型正确”到“系统正确”的思维转变
我观察到一个现象：刚接触大模型的开发者，经常把精力花在“找一个更强的Prompt技巧”上，却忽略了整个系统的鲁棒性。正确答案是：提示词只是系统的极小组成部分，数据质量、检索质量的优化空间通常比提示词本身大得多。
这里的核心思想是“系统正确性”。比如你的RAG问答系统答案不对，原因可能出在：文档切分时把一个完整知识点截断到两个块里、向量检索的TopK设置不合理、Embedding模型和查询语句的领域不匹配、重排序环节丢失了关键信息。你需要在日志里把每一环的结果输出出来，逐个排查，而不是盲目改Prompt。
我自己的经验做法是：在系统里为每个请求记录一条完整链路日志，包括查询改写结果、检索到的前N个片段及得分、输入给大模型的Prompt完整内容、模型输出、后处理结果。这样每次线上效果不好，都能直接定位到具体环节。这套东西就是“可观测性”，它在LLM应用里的重要性远超很多教程里强调的内容。
5. 工程化避坑清单：数据泄漏、评估偏差、线上漂移
这部分是我最想写的。因为网上大量教程教你“怎么做”，但很少讲“哪里容易出错”。我自己在工程化过程中踩过的坑，拿出来分享，也许能帮你少走很多弯路。
5.1 数据泄漏：最隐蔽的模型性能杀手
数据泄漏是指训练过程中模型“偷看”了本不应该看到的信息，导致离线指标虚高，上线后立刻现原形。最经典的例子是做时序预测时，不小心把未来数据当训练特征用；或者做数据划分时，没有按用户维度做分组，导致同一条数据既出现在训练集又出现在测试集。
我印象很深的一次事故是做一个文本分类项目，数据里有一个字段是“是否被用户举报”，这个字段本身和标签高度相关。结果我在特征工程时把这个字段选进去了，离线F1高达0.98，上线后效果一塌糊涂。原因就是：线上预测时这个字段的获取是滞后的，我们根本上拿不到实时的“是否被举报”。这个坑的本质是没有区分“你有哪些数据”和“预测时你实际能拿到哪些数据”。
避免数据泄漏的办法没有捷径，只能靠思考和审查。每次构建特征之前，都问自己一个问题：**假设我此刻在线上做预测，这个特征能实时拿到吗？**如果答案是否定的，那它就不该进训练集。另外，数据划分时要格外注意分组逻辑：数据集里涉及用户、商品等实体时，最好按实体维度划分，避免同一个实体的记录同时出现在训练和测试中。
5.2 离线评估与线上表现的鸿沟
离线评估指标高，线上表现差，这可能是AI工程师最崩溃的场景之一。鸿沟出现的原因通常有几个：
- 数据分布漂移：线上的输入分布和训练集不一样。比如模型的训练数据来自某个时间段的用户行为，上线后用户兴趣变化了，分布自然就偏了。
- 线上特征缺失或延迟：很多特征在离线训练时是完整历史值，但线上获取时有缺失或延迟。比如用户实时位置这种特征，离线时是准的，线上可能拿不到。
- 反馈延迟：线上效果的度量往往基于用户反馈，但用户反馈是滞后的。点击、停留、转化都是事后才知道，所以线上指标天然有一个时间滞后。
我处理这类问题的一般流程是：先看线上日志和训练数据的特征分布对比，确认是否有明显偏移；再逐特征检查线上特征获取是否完整；最后再看样本的时间分布，用近期数据做一次离线模拟测试。通过这个流程，大多数鸿沟都能定位到具体原因，再决定是补数据还是换模型策略。
5.3 模型上线后的监控：不能只盯着准确率
模型部署上线不是终点，而是运维工作的起点。我见过太多团队模型上线后只关注一个综合准确率，结果某个特定用户群体、某个特定时段的异常表现完全未被发现。
我的建议是至少监控以下几个维度：
- 输入数据监控：特征值分布是否发生变化，有没有出现训练时没见过的取值
- 预测分布监控：模型预测结果中各类别比例是否和训练时一致，比如原来预测正类的比例约10%，突然变成50%，那一定哪里出了问题
- 业务结果监控：CTR、转化率、用户满意度这些业务指标是否波动
- 延迟与资源：推理耗时、显存占用、CPU使用率
监控不一定上来就搭建复杂的平台，先用定时脚本把关键指标记录到表格里，每天看一眼，也比完全不管强得多。等有资源了再上专业监控系统也不迟。
6. 给真正想从零开始的人：一份相对务实的路径建议
最后这部分，我想从个人经验出发，给“ai-engineering-from-scratch”的实践路径做一个整体梳理。前面讲了职责边界、学习支柱、项目实践、大模型进阶和工程避坑，现在把这些内容串成一条可执行的路径。
6.1 时间与阶段的规划参考
每个人的基础不一样，我不建议按“月数”来硬性规划，但可以按“能独立完成哪类任务”来划分阶段：
- 阶段一：工具熟练期。能用Python写数据处理脚本，能读懂Pandas和NumPy代码，会用Git管理代码。大部分人需要一到两个月的密集练习。
- 阶段二：模型基础期。能理解并独立实现经典机器学习模型的训练流程，能正确使用评估指标，能完成分类、回归两类基础任务。这个阶段的关键是项目练习，至少完成2~3个完整项目。
- 阶段三：深度学习期。能用PyTorch搭建并训练一个神经网络，理解梯度下降、反向传播的基本原理，能复现至少一个经典模型（CNN或Transformer）。
- 阶段四：LLM应用期。能基于大模型API开发完整的RAG应用或Agent应用，掌握提示词设计、检索调优、结果评估的方法。
- 阶段五：独立工程期。能独立架构一个中小规模的AI系统：从数据管道到模型服务，从监控告警到迭代流程。
这五个阶段的命名是我自己日常带人时用的，未必适合所有人，但大体方向是对的。核心思想是每个阶段都有明确产出，而不是学了多长时间后感觉自己“好像会了一点”。
6.2 学习心态上的三个提醒
最后想分享三个学习心态上的提醒，这些都是我自己走过的弯路。
第一，不要收藏过多资料。资料收藏得越多，动手时间就越少。同一类主题的教程只需要选一套，从头到尾学完，然后立刻做项目。我电脑里躺着一百多个未打开的收藏链接，都是当年“觉得有用”的教程，实际上注意力只是在收藏那一刻得到了满足，并没有学到实质内容。
第二，做项目时宁愿“小”，也不要“假”。做一个小而真实的本地项目，好过做一个大而空的Demo。比如做一个能解析本地PDF并回答问题的个人知识库助手，虽然只能你自己用，但它的链路完整程度远超那些只调API的演示项目。把这个工具用起来，你才会遇到切分粒度不合理、检索结果不稳定、回答内容冗长等等真实问题，解决问题才是真正的学习。
第三，尽早建立对成本的感知。大模型API调用、GPU训练、向量数据库存储都是有成本的。我见过不少新手做实验时大手大脚，跑一次全量微调烧掉几千块钱，结果只是验证了一个业界早已知晓的结论。做AI工程，成本意识不是财务的要求，而是技术决策的重要维度。你能不能在有限的成本预算下得到一个够用的效果，这本身就是AI工程师的核心竞争力之一。
从零开始做AI工程，确实有一段漫长且枯燥的积累期。但当你亲手搭建的系统第一次稳定运行在线上，接受真实流量时，那种成就感是单纯调通一个模型的快乐没法比的。按部就班来，别怕慢，真正动手写代码、调bug、看数据的时间，每一分钟都会在未来回报你。
