从“ai-engineering-from-scratch”这个项目名说起。这个名字一看就是那种“为了搞明白索性从头造一遍轮子”的狠活儿。AI 工程化这些年被聊得很多但大多数人的学习路径都是“打开 LangChain 文档调几个 API跑通一个 demo然后自我感觉良好”。真正动手从零实现一遍的人反而少得可怜。而这条路线恰恰是工程师从“会用 AI”走向“能造 AI 系统”的分水岭。我最初接触 AI 工程化时和大多数人一样手里攥着各种框架LangChain、LlamaIndex、HuggingFace哪个热用哪个。demo 跑起来很容易可一旦场景变成“私有知识库问答准确率要超过 90%”“单卡推理 P99 延迟压到 300 毫秒”“上千万条文档要稳定去重和切分”框架封装的高级能力反而成了障碍。你根本不知道它内部怎么检索、怎么给大模型拼提示词出了问题只能瞎猜。从零开始看似绕了远路实际上是在最短时间内补齐认知盲区把 AI 工程化这件事真正变成自己的基本功。这篇内容不是课程大纲复述而是一份基于我真实踩坑经历的学习地图。我会把它拆成五个部分先聊清楚 AI 工程和算法研究的区别到底是什么再梳理一套完整的核心知识模块然后给你一条从零开始可执行的实操路径接着分享几个学习过程中最常见的坎最后说说怎么长期维持学习节奏。每一段都是我自己摔过跟头之后总结出来的希望能帮你少走点弯路。1. 从零开始学 AI 工程先想清楚学什么1.1 工程师视角和算法研究视角的差别很多刚入门的朋友容易把算法工程师和 AI 工程师混为一谈。算法工程师的核心职责是“造模型”他们要设计网络结构、改进训练策略、在 benchmark 上刷分AI 工程师的核心职责则是“用模型”把已经存在的模型不管开源还是闭源稳定、可控、低成本地集成进真实业务系统里。这两件事需要的能力完全不一样。我见过算法背景很强的同事在系统设计上翻车也见过纯后端出身的朋友靠系统地学了 AI 工程化知识把公司基础设施全带起来了。关键在于你要很清楚自己的目标你不是在研究怎么训出下一个 GPT-4而是研究怎么用现有模型解决具体的业务问题。这意味着你的学习重心应该是数据工程、提示词工程、RAG 架构、推理优化、评估体系和成本控制而不是整天盯着训练 loss。这个认知很重要因为大部分人学习 AI 工程化时心态崩掉都是因为错误的“对标”总想着自己得先懂透 Transformer 原理、先会用 PyTorch 从零训练一个大模型才敢动手做应用。实际上工程化是一个独立的学科有它自己的深度只是深度不在“模型内部”而已。1.2 为什么“从零手写”比“调框架”更重要LangChain 这类框架最大的问题是“黑盒”。当框架内部帮你把文档切块、向量化、检索、拼提示词、解析输出全做完了你对系统里发生的每一件事就失去了感知。一旦线上出问题比如召回质量变差、输出格式不稳定、token 费用异常飙升你面对的是一堆抽象封装完全无从下手。从零实现本质是一种“认知排雷”。自己写一遍文档切分才知道 chunk size 和 overlap 对检索效果影响有多大自己设计一次向量检索的召回与重排才理解为什么 TopK 取 20 再精排到 5 能明显提升准确率自己拼一次给大模型的上下文模板才体会到 order 和分隔符设计有多敏感。这些经验是框架“喂”不到你嘴边的只有亲自动手才长得在自己身上。所以别把这个项目理解成“重复造轮子”。造轮子的目的不是取代 LangChain而是让你成为那种“引擎盖翻开来随手就能修”的工程师——框架对你而言是一件可以随时更换的工具而不是离了就没法走路的拐杖。2. 完整知识地图AI 工程化必须啃下的核心模块把整个知识体系拆开看一个合格的 AI 工程师至少要在六个模块上有“真理解”而不是“听说过”。这套框架无论是做学习规划还是拿来检查自己的盲区都非常好用。2.1 Python 工程基础远不止语法很多人以为自己会 Python 基础知识就等于具备 Python 工程能力其实是两码事。你在 Jupyter Notebook 里写代码是一回事在命令行项目里组织代码又是一回事。AI 工程里大量代码要处理异步调用、并发请求、数据清洗管道和错误重试这些都不是“会写 for 循环”能覆盖的。我建议你把以下内容当成底线项目虚拟环境管理venv、poetry类型注解与 pydantic 数据校验异步编程asyncio、aiohttpPython 包与模块的工程化组织日志与异常处理规范。尤其是异步编程大模型 API 调用动辄两秒起步一次批量任务发几百上千条请求不会异步任务根本跑不动。2.2 机器学习与深度学习基础可解释比能调通更重要注意这里不是让你成为论文复现机器。你需要理解的核心概念是token 和词表是什么embedding 到底在做什么为什么语义相近的文本在向量空间里距离更近Transformer 的基本结构自注意力机制、位置编码为什么能处理上下文训练和推理的区别为什么推理阶段需要 KV Cache以及过拟合、泛化等基础概念如何影响你对模型能力的判断。有了这些概念你才能在实际工作中合理推测模型行为。比如某个大模型突然输出变差你能立刻想到“上下文太长注意力分散了应该精简 prompt 或增加关键信息密度”而不是只能干着急。这块我推荐自己动手补一点微小的训练和推理过程——拿一个小模型在几万条数据上跑一个微调观察 loss 下降和输出变化比读十篇教程都管用。2.3 大模型应用开发API 之外还有一条完整链路很多人会调用 OpenAI API 或者通义 API就觉得这块学完了。真正的应用开发链路是从一个输入开始理解提示词如何被构造成 messages 列表系统提示词该承担什么角色few-shot 示例如何影响输出格式API 参数temperature、top_p、max_tokens在什么场景下该被怎样调节结构化输出的方案等。这些都是从零开始手写时最先碰到的东西。LangChain 其实在这部分做了大量封装问题也随之而来框架把消息列表、工具调用、输出解析器都抽象掉了你照着框架示例写代码但根本不知道自己发给模型的请求长什么样。所以我建议第一遍学的时候先直接用 requests 调用 API亲手打印出完整请求与响应把链路里的每一层都看明白。2.4 向量数据库与检索决定 RAG 效果的关键RAG检索增强生成是 AI 工程应用中的核心模式于是“向量数据库选型”变成了一项很热门的工作。可如果你从零手写过一次检索系统就不会只是纠结选 Pinecone 还是 Milvus而是会深入到更本质的问题文档切分策略按固定长度、按段落结构、按句意、还是混合策略向量化模型的选择中文场景用 bge、text2vec还是多模态模型检索结果的粗排与精排TopK 召回 重排模型混合检索向量 关键词在不同场景下的取舍。这些知识才是 RAG 效果好不好的分水岭。向量数据库只是其中最后一个存取环节前面的数据处理和检索策略才是真正的差距所在。2.5 微调、评测与部署把模型变成产品的最后一步微调Fine-tuning不是所有场景都必须做但如果要做你必须理解什么时候该用 RAG什么时候才需要微调LoRA 这类参数高效微调的基本原理和操作如何构造高质量训练数据指令数据、对话数据以及微调完成后如何系统评估效果而不是凭空感觉“好像变聪明了”。部署阶段则要掌握 vLLM、TGI 这类推理框架的常用参数了解 KV Cache、continuous batching 这些推理优化的基本概念明白显存估算和量化手段FP8、INT4怎么选择。这一整条链路才是从“模型开发”迈向“AI 产品”的完整闭环。3. 实操路径从第一行代码到能跑通完整系统理论知识再多也比不上亲手敲出一套完整系统。我从零实现的过程中逐渐摸索出了一条“五阶段实操路径”。每一步都对应特定能力和认知成长分享给你参考。3.1 阶段一用 API 搭出一个最小闭环第一步先不碰任何框架直接调 API 做一个“命令行 QA 机器人”。目标很简单用户输入一个问题程序组装 messages调用模型接口拿到回复并输出。但完成这个目标的过程中必须做以下几件事设计一个合理的 prompt 模板包含人设、任务边界、输出格式约束实现 API 调用失败时的自动重试和报错信息打印记录每一次请求的 token 使用量与耗时把程序封装成可配置的小项目API 地址、模型名称、temperature 全部走配置文件。千万别小看这个“最小闭环”它把 AI 应用开发最核心的几个步骤全部串起来了。我在这个阶段最大的收获是第一次直观感受到“token 消耗”这个概念的重量上下文里每多塞几百个 token 的系统提示词批量调用一千次费用就是肉眼可见的增长。3.2 阶段二用开源模型替换 API理解本地化部署API 用顺手之后第二阶段要换一条截然不同的路把模型从“云端 API”换成“本地开源模型”。推荐从 Qwen 这类中文能力优秀的开源模型入手。这个阶段的任务是本地部署一个小模型7B~14B 量级用脚本发起同样的对话请求对比它和商用 API 在输出质量、响应速度上的差异。部署这一步有很多细节是 API 调用完全不会碰到的显存怎么估算7B 模型 FP16 大约需要 14GB 显存、torch 和 transformers 的版本怎么配合、生成参数怎样设置才能避免无限生成。我强烈建议你在这一阶段尝试一下 vLLM 这类框架对比一下用 / naive transformers 直接加载的效果差异。这会让你直观地理解连续批处理continuous batching对吞吐量的提升有多大。3.3 阶段三实现一个端到端 RAG 应用这是整个学习路线中最难也最关键的一步。不要用现成的向量数据库客户端直接用 embedding 模型把一批文档转成向量后存进一个简单的向量索引里刚开始用 numpy 和暴力检索就足够了然后实现完整的问答流程查询向量化 → 计算相似度 → TopK 召回 → 拼装上下文 → 交给大模型生成。当你亲手用 numpy 实现了余弦相似度计算之后你对“向量检索”的理解会有质的飞跃。然后再去思考性能问题十万条向量的时候暴力检索还能忍百万条时怎么办这时候再去学 HNSW、IVF 这些 ANN近似最近邻索引才有真正“打通了”的感觉。接下来可以尝试引入重排序召回 20 条用重排序模型精排到 5 条对比直接召回 5 条的效果差异你会发现准确率有明显变化。这个阶段做完再去用 LangChain 或者 LlamaIndex你不再是“照抄”而是“校验”——能看懂框架每一步在做什么并且敢于改它的源码。3.4 阶段四针对私有数据的微调RAG 解决的是“模型不知道的私有知识”的问题但有些场景 RAG 不够用模型的行为方式需要改变比如输出必须遵循特定格式或者推理能力在特定任务上不足。这时候就需要微调。先从 LoRA 开始找一个开源基座模型构造几百到几千条指令数据做一次全过程的微调实验。过程中一项核心工作就是“构造数据”。我踩过最大的坑就是以为数据越多越好丢进去几万条网上爬来的通用数据结果模型原有的能力被干扰了。后来才意识到微调数据要少而精且要跟目标场景强相关。几百条高质量、人工校验过的数据有时候比几万条清洗过的网络数据更有效。3.5 阶段五部署和成本优化最后一步把某个微调过的模型做成一个可对外服务的小产品。这里要解决的是工程化的问题用 vLLM 部署一个 OpenAI 兼容的服务接口设计一个简单的服务端FastAPI 或 Flask对外提供 API对服务的 QPS、延迟、显存占用做一个简单压测思考优化空间比如量化、降低 max tokens、精简系统提示词等。成本优化这个环节特别值得关注。实际生产环境的成本黑洞往往就是 token 消耗——系统提示词太长、文档切分不合理导致上下文塞了大量无用内容、检索的 TopK 取值过大、多轮对话历史无限累积这些都要在实际压测中一项项排查。4. 踩坑记录学习 AI 工程必经的几个坎4.1 过高估计新技术低估基础能力这个领域最吊诡的一点是技术迭代速度之快让人觉得“基础不着急补先把最时髦的技术学了再说”。结果就是很多人模型能力已经追到最新连系统设计、数据结构的基础都没打好。我见过有同学研究大模型应用研究了大半年遇到并发请求直接崩溃连连接池是什么都不知道最后跑去补并发编程基础才意识到前期效率为什么那么低。所以我的建议是学习节奏上保持“顺风学新逆风补基础”。新模型、新论文当然要看但属于工程底子的那些东西——Python 工程能力、数据库知识、缓存设计、API 设计——一定要持续复习和加深。它们才是你走得远的底气。4.2 代码“抄”会了但下一次还是不会写这是调框架学习最容易掉进的坑。在 LangChain 里加载文档有现成的函数切分有现成的 splitter检索有现成的 retriever你照着示例改改参数demo 就出来了。可一旦让你脱离框架自己写一套脑子里就一片空白。原因很简单你从来没自己构建过完整链路只是在一个高度封装的系统中更换配置。我的建议很简单所有核心环节至少亲自动手实现一遍——不借助任何高阶框架。自己用 Python 写一个 JSON 加载器自己写一个固定长度切分逻辑自己实现一个暴力向量检索。过程并不复杂但带来的理解深度远超从框架里学到的。4.3 数据、评测和工程化才是真正的大头学习过程中很多人天天围着模型转折腾半天忽略了数据与评测这两个决定成败的环节。真实项目里模型选型工作可能只占 20%剩下 80% 的时间都花在数据清洗、测试集构建、效果评测、bad case 分析和系统调优上。可这部分恰恰是自学者最不愿意练习的因为不酷、不性感、出不了好看的 demo。我做的比较正确的一件事是花时间打造了一个小而精的“评测集”50~100 条覆盖典型场景的题目。每次改 prompt、切分策略或模型参数都固定跑一遍评测集而不是凭感觉觉得效果变好了。没有评测集AI 工程优化就变成了盲人摸象。4.4 警惕收集资料替代实际学习网上关于 AI 工程化的学习路线、资料列表、开源项目、视频课程多到爆炸。收藏转发的时候很爽但收藏夹里吃灰的东西越攒越多实际能力却原地踏步。收藏不是学习只有亲手把东西跑起来、改过、调过才算数。我自己的原则是任何资料收藏后 72 小时内必须消化。可以是跑通一个 demo可以是整理一页笔记也可以是复制关键代码改一改变成自己的。消化不了就直接删掉不需要有负担。5. 学习方法与节奏建议5.1 项目驱动学习才是唯一靠谱的方式学编程最怕的是“学了一堆概念不知道用来干嘛”AI 工程尤其如此。因为链路长、环节多每个环节拆开学都容易半途而废。唯一的解法是拉通一个完整项目让项目带着你学。目标不需要大——做一个“能够回答公司内部 PDF 文档问题的机器人”就足以牵动上面提到的所有知识点。围绕这个项目你会自然倒逼自己去学文档加载、切分、embedding、向量存储、检索、prompt 设计、模型调用、评估优化。每个环节的知识点在实际项目里都有了锚点学过就不会忘这才是真正有效的“项目驱动学习”。5.2 建立个人 AI 工程手册随着学习深入你会发现知识和经验点非常零散某个 API 的参数、某个版本兼容的坑、某个模型实测的速度、某个切分参数的建议值……这些如果不记录下来三个月后一定忘光。我建议你用任何方便的笔记工具甚至 markdown 文件建一个自己的 AI 工程手册按“API 调用”“RAG 链路”“模型部署”“问题排查”等分类持续沉淀。这份手册不追求系统完整而是记录真实经验。尤其是报错信息和解决方案记录多了你的“排查素养”会变成别人追不上的优势——遇到同样的问题别人还在搜 Stack Overflow你已经能直接定位到根因。5.3 保持节奏稳定比激进更重要AI 工程化内容量大很多朋友学习的时候给自己打鸡血第一周每天学八个小时第二周累到放弃。更好的方式是让自己像一个长期主义者每天保持一两个小时的有效投入但坚持半年以上。这个领域的知识密度需要时间和重复来消化不是短线冲刺能拿下来的。我自己的经验是设置“最低工作量”目标每天至少碰一次项目代码。状态好就多写点状态差就只改一个参数重新跑一遍评测集。重要的是保持和项目的连接感让脑子始终沉浸在“AI 工程”的语境里。半年下来积累的东西会让你自己都惊讶。最后再分享一个我实测下来的体会从零开始把 AI 工程链路完整走一遍之后最大的收获不是会调某个框架而是面对任何一个新模型、新工具、新框架时不会再有“陌生感”。你会自动把它拆解成“数据进、模型算、结果出”的链路然后用自己的工程直觉去判断风险在哪里、瓶颈在哪里、替代方案是什么。这种拆解和判断的能力才是 AI 工程化最值钱的内功。希望这份路线图能给你一些启发也期待你在评论区分享自己从零动手时踩过的坑。