这条学习路径我已经走过一遍，也带人走过一遍。如果你正在搜索“ai-engineering-from-scratch”这样关键词，大概率已经受够了网上那些“三天搞定大模型”的速成帖，想找一条真正能让自己从零搭起、最后能交付真实系统的路线。这篇文章就是我基于这条路径做的完整复盘：学什么、怎么学、哪里最容易被卡住，以及每一步的落地细节。适合自认为“编程刚入门”但打算转型AI工程方向的人，也适合已经在玩模型但总觉得是在“调包”的同学。
1. 从零开始学AI工程，先想清楚边界
很多人一听到AI工程，第一反应是“那我得先把机器学习论文啃一遍”。我的观点正好相反：AI工程和算法研究是两件事。算法研究追求的是模型精度上限，AI工程追求的是在有限资源、有限时间、有限成本内，把一个模型变成别人能用、好用、持续可改的系统。所以你不需要从论文推导开始，但你需要把工程链路中的每一个环节都亲手打通。
我见过不少想转行的人，一开始就扎进Transformer论文里，读了两周就放弃了，因为数学基础被劝退。也有人绕开了所有理论，直接用LangChain把各种API串在一起，结果产品一上线就各种乱回答，完全不知道怎么排查。这两类人其实是同一个问题：缺少一个把“原理”和“工程”衔接起来的完整路径。
“ai-engineering-from-scratch”的核心价值，就在它强迫你按依赖顺序一路建上去：先会写代码处理数据，再理解模型是怎么推理的，然后才谈得上搭应用、做评估、上部署。这个顺序不是我拍脑袋定的，而是被无数个“为什么当时没先学这个”的教训逼出来的。你会踩的所有坑，基本都能归因到某一层基础没夯实。
还有一个边界要澄清：这条路不是“从零学编程”。如果你连Python基本语法、函数、类都完全没写过，还是先花两到四周补一补基础语法和常用库（requests、pandas、json），再来进入AI工程学习。这个路径的“零起点”，指的是零AI基础，不是零编程基础。
2. 路线图整体拆解：从地基到屋顶
“从零开始”真正难的不是某节课、某个模型，而是你不知道自己当前处在哪个位置，下一步该往哪走。所以我把整条路线在图里拆成了四层：工具层、原理层、应用层、交付层。每层都有明确标志物，学完之后能做某件具体的事，就可以认为这一层过关了。
2.1 工具层：Python、数据操作与实验环境
第一层看起来最不起眼，但它决定你后面会不会每天都在“返工”。我建议先搞定的不是深度学习框架，而是数据处理三件套：json、pandas和requests。你后面做任何AI项目，数据都是从文件、API、数据库里来的，如果连读取、清洗、切片都做不顺，模型调得再花也没用。
环境上，我推荐直接用Anaconda或者miniconda来管理Python环境，而不是裸装一个全局Python，否则你会在不同项目的依赖冲突里耗掉大量时间。一个实用的习惯是：每个项目建一个独立的conda环境，Python版本用3.10或3.11，因为主流框架在这两个版本上兼容性最稳。
这层还有一个看起来不重要但后期救命的动作：从第一天就习惯用git做版本管理。你改代码、改实验参数的时候，如果没有版本记录，一旦发现某个改动把效果搞差了，会完全回忆不起来之前是怎么跑的。我自己的习惯是哪怕一个探索性脚本，也先git init再说。后面做项目协作、模型迭代这些都会轻松很多。
2.2 原理层：神经网络与大语言模型打底
不建议上来就吃透Transformer全部数学细节，但你至少要建立三个直觉：
- 模型不是一个“知识库”，它本质是一个根据上下文预测下一个词的系统。这个直觉能让你明白为什么它会一本正经胡说八道。
- 参数越多，模型容量越大，但如果没有经过足够好的训练数据对齐，能力不一定和参数成正比。
- Token是模型理解文本的基本单位，所有长度限制、成本估算、上下文窗口都是围绕token来计算的。
在这个阶段，我的做法是去跑一个微型Transformer的代码实现，比如用几万条数据训练一个字符级语言模型。你不需要追求效果惊艳，关键是通过代码看见“训练损失在下降”是什么感觉，“过拟合”是什么表现，这样才能在你后面使用几亿参数模型时，对“状态”一词有直观的体感。
如果你没有精力自己从零实现，那就去看Andrej Karpathy的nanoGPT这类极简复现项目，跟着走一遍前向传播和训练循环，比你在书上看十遍都有用。很多人在这一步就被劝退了，因为要补向量、矩阵、概率统计的知识。其实不需要一步到位，只需要能看懂代码里的张量变换，剩下的在后续遇到问题时再逐步补。
2.3 应用层：提示词、RAG与Agent范式
原理层的尽头，是你能自己跑通一个开源模型，或者熟练调用API。再往上就是AI工程的主战场：怎么把模型的能力封装成一套真正的产品系统。
这个阶段有三条主线，必须按顺序推进：
- 提示词工程：这不是简单的“把问题写清楚”。你需要学会结构化指令、少样本示例、思维链引导，以及最关键的——如何设计一套输入输出格式，让模型的结果稳定得可以被代码解析。所有没有“输出格式约束”的提示词，放到工程里都是定时炸弹。
- RAG（检索增强生成）：如果你要做一个基于私有知识库的问答系统，RAG是绕不开的范式。它要解决三个问题：怎么把你手里的文档切成合适的片段、怎么把片段变成向量存起来、怎么在用户提问时把最相关的片段找出来并拼接给模型。每一步都有讲究，后面我单独展开。
- Agent（智能体）：在一个开放任务里，让模型自己决定调用什么工具、按什么顺序执行，这就是Agent做的事。它的工程复杂度比RAG高一个量级，因为你不仅要处理模型的输出，还要管理多步状态、错误恢复和成本上限。
我特别提醒一点：不要一上来就想着堆Agent。你连单步工具调用都没写稳的时候，直接上多步Agent，出错时你根本不知道是模型理解出了问题，还是工具返回格式出了问题，还是状态处理逻辑有bug。先把提示词和RAG做扎实，Agent才会变成水到渠成的事情。
2.4 交付层：评估、部署与监控
很多自学者走到“模型能跑通demo”就停了，但这恰恰离“AI工程”还差一大截。工程意味着你要回答这几个问题：这个系统改不改得好？上线之后怎么观测？出了问题怎么回滚？
所以在这条路线的最后一个阶段，我安排了三件事：
- 评估集建设：把测试问题整理成一批固定集合，每次改动后用这批问题统一测一遍，看效果是变好还是变差。没有评估集，你后面所有“优化”都是赌博。
- 部署：至少要会一次把模型封装成HTTP接口，或者用国内云的模型服务部署一套可被外部调用的服务。这里牵扯到并发、超时、显存管理，是工程能力和demo能力的分水岭。
- 监控与日志：对每个请求记录输入、输出、延迟、token消耗。否则用户反馈一个“偶尔回答很奇怪”，你完全没有数据可查。
3. 核心模块实操：我踩过的坑和验证过的做法
理论知识谁都能讲，但真正让你和别人拉开差距的，是每个模块里的细节怎么处理。下面这些内容不是教科书上的标准答案，是我在真实项目里反复试出来的东西。
3.1 提示词工程：从“会聊天”到“能交付”
提示词工程最大的认知转变，是它从“让模型听懂我”转变成了“让模型按我的接口输出”。工程场景里，模型的输出不只是给人看的，更多时候是给代码用的。比如你要让模型从用户反馈里提炼“问题类别”和“紧急程度”，如果它回答“我觉得这个问题是关于支付的呢”，你的json.loads()就直接崩了。
所以我在所有项目里都坚持两个原则。第一，提示词里必须包含明确的输出格式描述，然后配上两三个示例。示例的作用远大于你写一百句“请严格按照JSON格式输出”。第二个原则是，凡是关键输出字段，都要在代码里做格式校验和重试，而不是默认模型每次都会乖乖听你的。我通常会在代码里写一个parse_model_output()函数，负责清洗、修正、重试，这个函数成熟之后，你的系统稳定性会上升一大截。
写提示词的时候，还有一个小技巧：把提示词当成代码来管理。不要只在Jupyter Notebook里随手写长字符串，而是建一个prompts.py，把所有提示词模板集中管理，用f-string或者模板引擎传参。这样你改一个字、调一段话，都能通过git看到历史变化，也方便做A/B对比。
调试提示词时，最有效的做法是做“对照实验”：固定一个问题，单独改一个变量。比如只改示例数量看效果变化，只改角色设定看效果变化。如果你一次改三个地方，就算效果变好了，你也不知道是哪个起了作用。
3.2 RAG落地：分块、向量与混合检索
RAG是目前大模型应用里最实用也最容易翻车的模块。它的基本流程是：文档导入 → 分块 → 向量化 → 存入向量库 → 查询时召回相关块 → 拼接给模型生成答案。每个环节都有需要抠的细节。
先说分块。很多人偷懒，直接把整个文档塞给模型，这样不仅超tokens，而且检索时相关性很差。我验证下来，比较稳的分块策略是：尽量按文档本身的语义边界切，比如按Markdown标题、段落、表格维度来分块。不要用一个固定的字符数硬切，因为硬切会把一句完整的话拦腰截断。对一般技术文档，每个块控制在300到800字比较合适，还要设计块与块之间有一定重叠（比如50到100字），避免关键内容恰好落在边界上被切成两段。
再说向量化。选择嵌入模型时，别只看榜单上的分数，要拿你自己的文档去实测。中文场景下，目前一些国内厂商的中文向量模型和开源模型（比如BGE系列）效果通常比通用英文模型好。其中有一个很容易被忽略的细节：查询语句和文档片段的表示方式不完全一样。很多向量模型在训练时就区分了“查询侧”和“文档侧”的编码方式，如果你两边都直接用默认的encode方法，效果会打折扣。务必查模型文档，按对应接口分别编码。
光靠向量召回还不够。我强烈建议你在项目中加入“混合检索”，也就是向量检索再加上一个关键词检索（比如BM25）。原因是：用户提问里的确切关键词，比如“发票抬头格式”，向量召回可能返回一堆意思相近但没包含关键词的段落，而关键词检索能把真正提到这个词的段落捞出来。把两路结果做加权融合，最终效果通常比任何单一路都好。我见过太多人纠结于“换更好的向量模型”，结果把关键词检索加上之后，效果直接提升了一大截。
检索之后还有一步容易被忽略：重排序。初次召回可能拿回几十个块，真正对答案有用的只有几个。这时可以再跑一次rerank模型，拿用户问题逐个和召回块算相关性分数，把分数最高的3到5个块放进提示词里。这个步骤会多消耗一点时间，但效果提升非常明显。我在一个客户项目里，加了重排之后，答案准确率从67%升到了82%，所以这一步绝对值。
3.3 Agent与工具调用：从单步到多步
做Agent首先要认清楚一件事：它不是一个神秘的东西，本质就是“模型决定调用哪个函数 + 程序执行函数 + 把结果返回给模型”。所以工具调用的底层前提是，你的函数得定义得干净清晰，包括函数名、参数描述、返回结果格式，模型才能理解该什么时候调它。
我建议你先实现一个最简单的单步工具调用：给模型两个工具，比如“查天气”和“查日历”，看它能不能根据用户请求选出正确工具并填好参数。这一步顺了，再考虑多步循环。多步循环的核心是状态管理，你要记录模型已经执行了哪些步骤、当前手里有哪些信息、还缺什么条件。我当时用的是一个简单的AgentState类，把这些信息全部保存在内存中，每一步结束后更新状态。
多步Agent有一个特别常见的致命问题：死循环。模型可能会反复调用同一个工具，或者在一个错误结果上反复重试。解决方案有三个：设置最大循环次数（一般5到8次就够）；每一步记录“已尝试过的动作”，如果模型要重复执行完全相同的参数组合，直接拦截并换策略；第三步，给模型的提示词里强制要求“如果工具返回错误，不要重试超过一次，直接向用户说明当前遇到的情况”。这几个限制加起来，Agent才算具备了基本的可控性。
还有一个成本问题：Agent每一步都在消耗tokens，而且多步叠加起来费用很吓人。我在做Agent系统时会给每一步加一个预算上限，一旦累计token数超了，就停止并返回当前能确认的信息。用户宁可得到一个“我还没查完，但目前已确认的是…”的回答，也不愿意等着你烧钱不知不觉烧掉几十块钱。这算是我踩过最贵的坑之一。
3.4 评估与回归：没有评估就没法迭代
如果要说整个AI工程里最不值得跳过的一步，就是评估。没有评估集的项目，我从来没见它能稳定迭代超过三轮。你可以想象一下：你今天调整了一段提示词，感觉某几个case变好了，但另外几个case变差了，你没有评估集的话根本发现不了。
建评估集不需要很复杂。就两个文件：一个questions.jsonl，每行一条测试问题；一个expected_answers.jsonl，存对应的期望答案或关键评分维度。规模不用大，50到80条高质量问题起步就够。覆盖范围要全面：至少包含普通问题、边界问题、恶意对抗问题、无答案问题（模型应该承认不知道）这四类。
评估方式我分成两个梯队。第一梯队是硬指标：能不能被程序自动判定的，比如输出是否有效JSON、是否调用了指定工具、答案是否包含了必需字段、延迟是否超阈值。这些用脚本就能算，必须全部通过。第二梯队是软指标：用LLM当裁判，拿一个更强的模型来给答案打分，或者人工抽检。LLM去评估在一致性上比人靠谱，但你也要防止裁判模型偏爱某种风格，所以每轮改动后至少人工复核20条。
我这里提供一个最简的规则化判分思路：把期望答案拆成两三个关键点，比如“必须提到退款政策”“必须给出申请链接”。实测的时候，看模型输出里是否包含这些关键点的语义。统计出“关键点覆盖率”，虽然粗糙，但能很好反映改动前后的相对变化。等你有了这个基准线，再去做提示词优化、RAG调参，才会真正走在“迭代”而不是“乱试”的路上。
4. 项目实战：拿一个真实问题串起全链路
如果你跟着前三个部分一步步推进，学到这里手里已经有了不少零散的技能点。接下来的任务，是做一个完整项目把它们串成串。否则你面试的时候很难讲清楚自己到底能干什么。这一章我就用“构建一个企业内部知识库问答助手”作为例子，展示一个典型项目的完整决策过程。
4.1 选题标准与范围控制
我接触过很多初学者，最大的问题不是不会做，而是选了一个过大的题目，比如“做一个通用AI助手”。这种题目做出来，demo看起来很全，但没有任何一个环节能深入，面试一问就露馅。
我建议选一个范围极窄但真实存在的题目。比如“查公司内部请假制度的问答机器人”“产品说明书的故障排查助手”“课程推荐助手”，这些题目自带知识边界，方便你构建评估集，也更容易看出RAG效果好不好。真实业务背景也很重要，因为你能借到真实的用户提问，而不是自己编几个问题自嗨。
拿知识库问答助手来说，它的输入是几十份公司制度文档或产品手册，输出是当员工问“年假可以累积吗”时，返回一段有依据、有出处的准确回答。这个项目覆盖了数据解析、分块、向量检索、混合检索、重排、提示词工程、评估、部署，几乎全链路都跑到了，非常适合作为你的第一个完整作品。
4.2 从数据准备到系统联调
第一步，把PDF、Word、HTML这些不同格式的文档统一转成Markdown或纯文本。这一步看起来简单，实际上最花时间。PDF转出来的文字经常缺行、表格错乱，Word里可能有图片版式问题。我当时写了不少解析脚本去针对不同文档做清洗。这个过程的经验就是：不要想写一个万能解析器，每种格式单独处理，能转成干净的文本最重要。
第二步，做分块和向量化入库。我建议你在这一步就顺手把元数据（比如来源文档名、章节标题、页码）存进向量库的payload里。后面做引用来源时，这些元数据就是你的救命稻草。
第三步，写检索服务。把“用户问题进来 → 混合检索召回 → 重排 → 组装提示词 → 调用模型生成→返回答案和引用来源”封装成一个完整的流程。我建议从一开始就为这个流程写清晰的功能函数，不要把所有逻辑堆在一个大文件里。我的经验是分四层：数据层（负责访问向量库）、检索引擎层（负责召回和重排）、生成层（负责拼提示词、调用模型）、接口层（对外提供HTTP服务）。
最后一步，接入评估集。把之前提到的50条测试问题跑一遍，记录覆盖率和准确率，作为项目基线。后续你要做的所有优化，都要拿这个基线来对比，不能拍脑袋说“感觉好了”。
4.3 部署与监控的现场经验
部署这一步，很多人以为就是把代码放到服务器上。实际上模型服务的负载、并发、召回延迟都会在这里集中爆发。我自己是从FastAPI开始把检索和生成封装成接口的，本地调试好了再接线上。用uvicorn启动服务时，有两个参数特别重要：--workers表示进程数，--timeout-keep-alive是长连接超时，配置不好就会出现莫名其妙的连接断开。
对大模型API调用，我强烈建议在代码里加上超时和重试机制。我的习惯是设置单次调用超时30秒，最多重试2次，而且重试之间要有退避，不能连续打。因为线上模型服务偶尔会抖动，重试一次往往就好；密集重试反而容易引发限流。
监控方面不用一开始就上特别重的系统，我推荐先做一个最朴素的“日志表”：每条请求记录时间、用户问题、召回块、最终答案、引用来源、延迟、token数。这几个字段，已经能帮你排查掉90%的线上问题。后来如果你还想更进一步，可以再用日志里的延迟和错误率去配告警，但没必要一开始就铺开。
5. 常见问题速查与避坑指南
走到这里，你应该对整个路径有了全景认识。但学习过程中一定会在局部遇到具体的坑，我把我在这个方向上反复遇到、并且见过别人也反复遇到的问题整理成了一张表，每一条都是验证过的：
| 常见问题 | 典型表现 | 根本原因 | 推荐对策 |
|---|---|---|---|
| 模型答案没有依据 | 回答得很流利但内容是编的 | 提示词没有强制“没有依据就承认不知道” | 在提示词里显式要求“仅基于检索内容回答”，并让代码检测答案是否来自召回块 |
| 向量召回相关块不准确 | 检索到的内容和问题意思相近但缺关键信息 | 只用向量检索，忽略了关键词匹配 | 加上BM25，两路召回结果加权融合 |
| 分块导致答案割裂 | 一段流程被硬切到不同块里 | 固定字符数切块 | 按标题、段落等语义边界切，并保留重叠区间 |
| Agent反复调用同一工具 | API花费暴涨，响应卡死 | 缺少循环上限和重复动作拦截 | 设置最大步数并拦截完全相同的工具调用参数 |
| 改一个效果，另几个就崩 | 优化顾此失彼 | 没有固定评估集 | 先建50条以上的回归问题集，每次改动后统一测试 |
| JSON格式解析偶尔失败 | 模型多说了几个字导致程序报错 | 没有做输出清洗和重试 | 写解析函数，做格式修正，失败后自动重试一次 |
| 部署后第一次请求特别慢 | 首token迟迟不出来 | 未做预热或冷启动 | 服务启动后先发一条探测请求，预加载模型和检索索引 |
除了上面这些技术坑，还有三个心态坑，我觉得同样值得单独说明。
第一个是“追新工具”。AI领域几乎每周都有新框架、新模型出现。我特别理解那种“不学新东西就焦虑”的感觉，但学习路径的中前期，工具越少越好。与其天天研究新框架的API，不如把一套工具链用透，摸清楚底层原理。新工具里90%都是对旧问题的重新包装，你把基础打牢，切换到新工具通常只需要一两周。
第二个是“收藏等于学会”。我见过最多的情况是github上标星了上百个项目，自己一行代码没写过。我自己的做法每个项目不落地，不允许自己加入新的收藏。把“看一个教学视频”换成“照着敲一遍再自己改一遍”，投入产出比差距十倍不止。
第三个是“不会提问”。自学卡住一天以上，多半是提问姿势不对。你问别人“我的RAG效果不好怎么办”，没人能回答。但如果你说“我用了BGE向量模型加BM25混合召回，重排用了rerank模型，在50条测试集上覆盖率只有60%，其中有10条是表格提取失败导致召回为空，请问有没有更好的表格解析方案”，别人一听就知道问题在哪，你也能在社区获得真正有价值的回复。
6. 从学习到作品：怎样才算真正“会了”
最后我想聊聊什么叫“真正会了”。光学完知识不算，你得能把它证明出来。所以整条“ai-engineering-from-scratch”路径的终点，不是一个证书，而是三个可展示的产出物。
第一个产出物是代码仓库。它至少要包含一个可运行的完整项目：数据导入、索引构建、查询接口、日志记录。代码要整洁到另一个陌生人clone下来，读一遍README就能把服务跑起来。很多初学者只关注代码本身，忽略README，其实一份好的README能说明你对整个系统了如指掌，面试官最先看的就是它。
第二个产出物是实验报告。至少写一份“我做过哪些尝试，结果如何”的记录。哪怕结论是“混合检索比纯向量检索好5个百分点，重排再提升3个百分点”，这种记录本身就在向别人证明你有工程思维。做AI项目最怕的是你只说“成功了”，而没有暴露过“试错过程”。每一个真实项目都有大量失败尝试，能把这些失败讲清楚的人，才真正理解系统工作方式。
第三个产出物是一份部署完成的在线服务。哪怕是部署在一个临时域名或云服务器上，只要能随时访问、可交互、可持续运行，就会让你对“系统在产品环境运行”这件事产生直观感觉。在线部署那一刻，你看到的就不再是一个Notebook里的输出，而是一个可供他人使用的服务。你会发现用户不会按你测试集里的方式提问，你会发现请求一多接口就会慢，你会发现服务日志比你想的更重要。这些“发现”才是AI工程的经验本身。
等你把这三样东西都做出来，再把之前学的原理、每个模块的细节串讲一遍，你就已经完成了从零到AI工程师的转变。这个转变和证书、毕业院校都没有关系，它只取决于一件事：你能不能把一个模型从一个想法，变成一个能被人稳定使用的系统。这条路没有捷径，但它也不需要天赋，需要的是在正确的路径上持续投入。
