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、MLflowAI 工程师完整的 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 的每一个工程环节都过一遍。如果你也在路上记住一句实在话不要和别人的进度比和高楼比你会焦虑和昨天的自己比你每天都在长高。
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、MLflowAI 工程师完整的 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 的每一个工程环节都过一遍。如果你也在路上记住一句实在话不要和别人的进度比和高楼比你会焦虑和昨天的自己比你每天都在长高。
