企业官网建设流程全解析

从“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、aiohttp）；Python 包与模块的工程化组织；日志与异常处理规范。尤其是异步编程，大模型 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 做一个“命令行 Q&A 机器人”。目标很简单：用户输入一个问题，程序组装 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 工程化最值钱的内功。希望这份路线图能给你一些启发，也期待你在评论区分享自己从零动手时踩过的坑。