刚转到 AI 工程方向那阵子，我一度以为只要把市面上的大模型教程刷完、能跑通公开数据集，就算入门了。结果第一次真刀真枪接需求——给企业的工单系统做一个“自动分类并推荐负责人”的功能，我才意识到，模型能跑出结果只是整个工程链路的 1%，剩下 99% 的活儿全藏在数据清洗、接口设计、失败兜底、效果评估和成本控制里。那个项目最后上线用了六周，真正花在调模型上的时间不到三天。所以当有人问我“ai-engineering-from-scratch”该怎么开始，我通常不会甩给他一份课程清单，而是让他先想清楚一个问题：你想要的到底是“会调模型”，还是“能交付一个稳定的 AI 功能”？
这篇文章就是围绕这个问题展开的。我会从 AI 工程和纯算法工作的本质区别讲起，再给出一套我自己实践过、也带人走过很多次的从零到一的路径：怎么选第一个项目、怎么设计系统分层、怎么处理评估和监控、钱花在哪里。适合两类人看：一类是有工程基础但没做过 AI 项目，想往 AI 应用方向转的开发；另一类是已经在跑模型、但总觉得离“生产可用”差一口气的研究型同学。
1. 先说清楚：AI 工程和“调模型”根本不是一回事
1.1 你负责的不是模型，而是模型能稳定交付价值的整个链路
很多人对 AI 工程的理解是“训练和微调模型”，这其实是把 AI 工程和算法研究混在了一起。真正的 AI 工程项目里，模型只是其中一个组件。我见过太多人把精力全花在提升一个百分点准确率上，结果上线之后被调用延迟、token 成本、脏数据、用户反馈循环这些问题拖垮。
给你一个直观的比例：一个典型的企业级 AI 功能，比如“智能工单分类”，它的工作量分布大致是——
- 需求定义与指标设计：20%
- 数据采集、清洗、标注与回流：25%
- 检索/上下文/提示词等应用层逻辑：20%
- 服务封装、异步任务、缓存与兜底：15%
- 离线评估与线上监控：15%
- 模型训练/微调本身：5%
如果一个人只盯着最后那 5%，就永远只能做 demo，做不了产品。AI 工程的能力本质上是：把模型的不确定性，用工程手段包裹成产品的确定性。模型可能答错、可能超时、可能胡说八道，工程师的职责是让这些情况发生的时候，用户感知到的依然是可接受的结果。
1.2 一个 AI 工程师在真实需求里到底要干哪些活
拆开讲的话，一个完整的 AI 功能从需求到上线，工程师核心要交付六类东西。
第一，数据回路。包括初始数据的抽取、清洗、切分、向量化，也包括线上用户反馈数据的回流和再标注。很多时候数据端的活比模型端更决定成败。
第二，推理服务。模型怎么被调用？是同步 HTTP 接口还是异步任务？用流式还是非流式？并发和限流怎么做？模型超时怎么办？这些问题不解决，模型再好也上不了线。
第三，上下文工程。提示词怎么组织、历史会话怎么管理、外部知识怎么塞进上下文、token 超限怎么截断。这一层是 AI 应用和传统后端最大的不同，因为模型的输入输出都是非结构化的文本，你得替模型“打理好”它看到的东西。
第四，评估体系。没有评估就没有迭代。你要建离线评测集，定义指标，在每次改动前跑回归；你还要在线上埋点，用人气反馈隐式判断效果是否退化。
第五，成本与性能治理。模型调用是花真金白银的，延迟也是用户体验的一部分。所以要有缓存、有方案降级、有模型分级路由。
第六，安全与兜底。输入要过滤敏感信息，输出要做合规校验，模型拒绝服务或乱答时要有固定话术承接。这套兜底机制必须提前写，不能等线上出事了再补。
1.3 从零开始需要建立的核心能力清单
基于上面的拆解，我建议从零起步的人把能力建设分成四条线，而不是一头扎进模型训练：
| 能力线 | 具体内容 | 优先级 |
|---|---|---|
| 数据工程线 | 爬取/解析/清洗/切分/向量化/标注 | 最高 |
| 应用工程线 | API 封装、并发、缓存、异步、状态管理 | 最高 |
| 模型应用线 | Prompt 设计、RAG、微调、模型选型 | 高 |
| 运维评估线 | 评测集、指标监控、成本分析、A/B 测试 | 高 |
这四根柱子缺一根，项目都撑不起来。而且你会发现，前三根其实都是传统软件工程能力的延伸，只有第四根稍微新一点。换句话说，从开发转 AI 工程没有你想得那么难，但前提是把“AI”从神坛上拉下来，把它当成一个会犯错的外部服务去设计系统。
2. 第一块跳板：怎么挑一个值得从零做完的 AI 工程项目
2.1 判断项目值的三个硬指标
很多人学 AI 工程卡在第一步：东西学了不少，但没有一个自己从头到尾做过的项目。我建议用一个“三有原则”来筛项目：
- 有真实数据。不用公开 benchmark 里那种加工好的数据，最好是能从网上拿到或自己产生的、带噪音的、不干净的数据。哪怕是一个社区评论、一份企业公开文档、一堆聊天记录都行。因为处理脏数据才是 AI 工程的主战场。
- 有反馈闭环。项目做完以后，要能收到“这次回答好不好”的信号。比如用户会不会点👍/👎，会不会复制答案，会不会追问。没有反馈信号的项目，做完了也不知道自己做得怎么样，也就没法迭代。
- 有清晰但非唯一正确解。任务最好既有客观评价维度（比如能不能被正确检索到），又有开放空间（比如不同的回答风格）。这样既能做量化评估，又能发挥工程设计的创造力。
2.2 我推荐的三种入门项目形态
结合这三个指标，我给别人推荐过很多项目，最后沉淀下来靠谱的主要是三类。
第一类：个人知识库问答助手（RAG）。拿你自己的笔记、博客文章、某本公开书籍做私有知识库，用向量检索加 LLM 回答。数据不干净、格式五花八门，非常练数据能力；而且好不好用你自己一测便知。
第二类：开源社区内容的高频信息抽取。比如扒某个技术社区一周的帖子，用模型做主题聚类、标签生成、摘要归纳。这类项目对评估指标的要求更高，能锻炼把模糊输出变成结构化结果的能力。
第三类：一个小而美的 Agent 工具。比如做一个能自动查天气、查股票、算汇率的多工具机器人。这个项目能逼着你学会函数调用（Function Calling）、任务规划、多轮状态管理。注意，功能别做多，三个工具以内，否则工程复杂度会迅速失控。
2.3 为什么反对一上来就训练大模型
还有一个很常见的误区：觉得从零学 AI 工程就要先训练一个自己的模型。我在这事上栽过跟头。当时为了“显得有技术含量”，我用开源底座微调了一个领域模型，花了两张卡跑了一周多，最后效果不如直接调 API 加一套好的检索和提示词。后来我把那次经历总结成一句话：模型的能力是市场给你的，工程的能力才是你自己创造的。
起步阶段不要自己训练或微调模型，理由很现实：第一，你没有足够的领域数据，微调大概率会过拟合；第二，硬件和训练调参的成本会吞掉你学习工程本身的时间；第三，现在商用 API 和开源模型的能力边界已经很宽，多数应用需求根本不用碰权重。把省下来的时间花在检索、评估、监控这些别人看不见但决定生死的环节上，性价比高得多。
所以我给“从零”定的技术路线是：从 API 起步 → 做透一个 RAG 项目 → 再把其中一部分换成本地开源模型 → 最后才考虑微调。每一步变化都只引入一个新变量，出问题你才知道该查哪儿。
3. 四层架构实战：一个客服问答助手的从零搭建全过程
3.1 整体分层和选型逻辑
纸上谈兵说够了，直接上一个我最近带人复现过多次的项目：“企业客服问答助手”。需求很简单：用户提问，助手基于既有的产品文档和常见问题库回答。我做这个项目时把系统拆成了四层，这是我认为最适合入门、也最能体现工程价值的结构。
四层分别是：接入层、编排层、数据层、评估层。输出端不用自建模型服务，直接接模型 API，这样可以聚焦在工程本身。
选型方面，我的逻辑是“能用最熟悉的就用最熟悉的”。Python 后端用 FastAPI，数据存取用 SQLite 起步，向量库早期直接用内存里的 FAISS，后面数据量大了再地方迁移到真正的向量数据库。模型先用商用 API 做主力，同时保留一个本地模型的接口，方便后面换。这样选的原因很简单：你要学的是架构思想和工程细节，不是学某个特定中间件怎么调包。一上来就上 Kubernetes 加一套分布式向量库，出了故障你根本分不清是检索问题还是部署问题。
3.2 数据层：知识库切分与向量化，索引建不好后面全是坑
数据层是四层里最“脏”的，也是工作量最大的。我处理客服文档时遇到过各种鬼东西：PDF 里文字是图片、表格被拆成乱码、同一份产品有多个版本说明互相冲突。给我 8 小时做数据层，大概有 5 小时会花在清洗和结构梳理上。
切分是第一个关键决策点。切得太粗，每段内容包含多个主题，检索时匹配不精准；切得太细，语义被切断，模型拿到的上下文碎片化。我常用的配方是：按标题层级结构先切出大块，再按段落和语义边界切小块，chunk_size 设在 400 到 800 个 token 之间，chunk_overlap 用 50 到 100 个 token。这个数据不是拍脑袋定的，它大致对应模型一次能有效阅读的上下文长度，以及相邻 chunk 之间语义衔接需要的重叠量。
向量化的时候要特别注意 embedding 模型的选择。我踩过的坑是：用通用 embedding 处理专业客服术语，导致“退款时效”和“退款到账时间”在向量空间里离得不够近。后来在切分时保留了关键词加权，同时在 embedding 前做了一步领域词表替换扩充，检索准确率明显提升。embedding 不是只要访问一次 API 就完事，数据清洗、标准化、领域适配都得做在前面。
3.3 编排层：检索、重排、上下文组装与提示词管理
编排层是 AI 应用的核心，干的事相当于传统后端里的业务逻辑，只不过操作对象变成了向量和文本。
我的检索策略不是一次召回直接丢给模型，而是两段式：先用向量检索召回 Top 20 个候选 chunk，再用一个轻量级重排步骤（比如基于关键词重叠和位置权重的简单打分）把最相关的 3 到 5 个 chunk 挑出来。为什么这么干？因为向量检索擅长语义匹配但不擅长精确判断，重排能结合词面信息把“看起来相关但实际答非所问”的 chunk 过滤掉。这个组合让我的最终答案引用准确率从 62% 提到了 81%，成本几乎没增加。
上下文组装也需要讲逻辑。我给模型的 prompt 会包含几个固定部分：角色设定、知识库内容、对话历史、当前问题、输出约束。知识库内容放在最前面，因为模型对开头的注意力通常更集中；对话历史做截断，只保留最近三轮，防止 token 超限；输出约束里写明“根据知识库回答，知识库不足时明确说不清楚，不要编造”。这套模板看似简单，但每一条都是从线上用户的实际错误反馈里逼出来的——模型不会天然知道什么叫“不乱编”。
3.4 接入层：同步还是异步，长文本场景怎么处理
接入层容易出现“代码五分钟，手段一整晚”的情况。客服助手有两个典型入口：网页聊天需要流式回答，API 对接需要标准响应。我的建议是优先做流式接口，因为 AI 应用的体验关键在于“首字延迟”，用户能接受你答得慢，但不能接受两秒没动静。
这里有个更隐蔽的坑：模型接口不是所有时候都稳定，会有超时、限流、内容审核拦截。我的兜底设计是三层——第一层，网络层面的重试和退避；第二层，业务层面的固定话术，告诉用户“当前问题比较特殊，我帮你转人工”；第三层，把失败的 query 记录到日志，方便后续进评估集反思。一个合格的 AI 接口，异常处理路径的长度不应该小于正常路径。
长文本场景上，我建议提前设计“拆分-分治-汇总”模式。比如用户问“你们售后政策涉及哪些方面”，可能同时命中多个 chunk，这时候与其让模型一次性读太多，不如先用检索把命中的 chunk 分组，让模型分别概括，再汇总成最终答案。这个模式早就有了，但配合大模型用，效果出奇地好。
3.5 我踩过的三个典型坑和完整排查链路
这部分我不直接给答案，还原一下排查过程，因为排查思路比答案值钱。
第一个坑：用户问题有点绕时，检索返回的 chunk 完全不对。我当时先去查向量化日志，发现 query 里的几个核心词在 embedding 后被分散到了不同方向，然后又去查切分结果，发现知识库里用户最关心的“退款周期”相关内容被埋在了一段讲“订单状态”的长文本里。根因是切分时没有照顾主题完整性，导致检索命中时语义权重被噪音稀释。解决方案是把那段长文本按主题子标题拆开，并给每个 chunk 额外生成了三组同义关键词，用于适配检索。链路是：现象 → 查日志 → 查切分 → 改数据 → 复测。
第二个坑：上下文组装后模型回答离题，而且很自信。第一反应是提示词问题，改了好几版没用。后来把 prompt 完整打印出来才发现，对话历史里夹了一句用户很久以前说的脏话，模型把注意力全吸走了。根因是对话历史清洗不到位。解决方案是在组装前做一轮历史和输入脱敏。这个坑教会我：先看模型“看到的东西”，别急着怪模型。
第三个坑：评估时人工看效果很满意，但线上用户满意度反而下降。排查发现线上实际 query 和测试集的 query 分布差很多——测试集来自产品同事写的“标准问法”，线上用户则是“半句话式”提问。根因是测试集构建偏见。解决方案是从线上日志里挑真实 query 回流标注，建立了一个“线上分布优先”的评测集。这个排查链路后来成了我做任何 AI 项目的标准动作。
4. 能上线只是及格线：评估、监控和成本这三件事决定项目生死
4.1 离线评估集这样建，指标才算数
我见过太多项目死在“我觉得效果不错”这句话上。没有离线评估集的 AI 项目，本质上是在盲改。评估集不该随便攒几条数据，至少要满足三个要求。
第一是来源真实。答案要来自真实用户问题，而不是团队成员自问自答。第二是覆盖均衡。我一般会按难度分三层：简单（知识库里能直接找到原文）、中等（需要拼合多个 chunk 的信息）、困难（知识库无法完整覆盖，需要触发拒答）。比例大致是 4:4:2。第三是标注透明。每条评测数据要写清楚标准答案、判定维度（是否准确、是否完整、是否基于引用），避免两个人评出完全不同的结果。
指标上我会把人评和机评结合。机评用 LLM-as-a-Judge，让一个强模型给回答打分化评分；人评则重点盯着“引用是否正确”这个硬指标，因为引用错了，流畅度再高也没用。每次改完代码或提示词，就跑一遍回归，对比分数差异。没有回归测试的 AI 项目和没有单元测试的后端项目一样，都叫裸奔。
4.2 线上监控比模型本身更容易被忽视
模型上线只是开始，监控才是保证项目不死的底线。我的监控分维度是三个词：量、质、本。
“量”指的是调用量、用户数、session 数这些基础流量指标，异常波动说明可能有活动或者系统出问题。“质”包含首字延迟、完整响应时间、失败率、无答案率。我习惯给“无答案率”设一个两条线：短时间小幅度上升不处理，持续上升就要告警。“本”就是 token 消耗量，我会按用户、按功能模块分别统计。
这里有一个很实用的技巧：给模型输出加一个不可见的“引用标记”，比如在回答最后加上一段固定格式的来源编号。线上判断回答质量时，直接统计“有多少回答带了有效引用”，作为响应质量热的代理指标。这个信号不完美，但胜在便宜、足够实时。你甚至可以把引用率骤降当成一个提前告警，因为它往往先于用户投诉出现。
4.3 成本账怎么算
AI 应用的成本不是线性的，随着用户量增长，成本结构会发生三次转变，你得提前有预期。
| 阶段 | 用户规模 | 成本特征 | 核心策略 |
|---|---|---|---|
| 0→100 | 测试期 | token 成本可以忽略 | 重点优化效果，别过度设计缓存 |
| 100→1k | 早期用户 | token 成本开始肉眼可见 | 加语义缓存、合并请求、降级方案 |
| 1k→10k | 增长期 | 成本成为约束 | 模型分级路由、本地小模型承接简单问题 |
第一次接到上千用户时，我算过一笔账：如果所有问题都走大模型，每月 token 费用相当可观。后来我加了一道“意图分类前置路由”——先用一个轻量小模型把问题分到简单/困难两档，简单问题走本地小模型，只有复杂问题才调用大模型。整体成本降了约 40%，而用户体验几乎没有变化。成本优化的本质不是省 API 钱，而是通过系统设计让每一块钱都花在刀刃上。
5. 给从零开始的人一份不鸡汤的成长路线
5.1 应该学什么、暂时别碰什么
从零开始，学习顺序比学习内容更重要。我建议“四个先学四个不碰”：
先学 Python 后端基本功（FastAPI 或 Flask），不碰大模型源码。先学 Prompt 工程和 RAG 流程，不碰分布式训练。先学评估和监控体系，不碰花哨的 Agent 框架。先学怎么用好现成模型，不碰从零预训练。
为什么不碰框架？因为现阶段的 LangChain 这类框架抽象层极厚，出了问题你会被框架和模型两头折磨。我自己更推荐先用原生方式写一遍 RAG：embedding、向量检索、prompt 组装、调用模型、解析输出，全流程都自己写一遍。写完这遍，框架里的概念你再看就是透明的了。
5.2 按周划分的实操节奏
我建议以六周为一个周期做完第一个项目。前两周搭环境、采集和清洗数据，不着急跑模型，把数据切分好、建好索引。第三周完成最简接口：输入问题返回一个未经优化的答案。第四周做检索优化和重排，让答案“看起来靠谱”。第五周做评估集和回归测试，开始量化迭代。第六周上监控、写自动化测试、整理项目文档。
这是一个刻意安排的节奏：每两周只解决一个层级的问题，避免同时改多个变量导致失控。六周后的产出不是一个“炫酷 demo”，而是一套带评估、带日志、带文档的完整系统，这放在简历上才叫项目经验。
5.3 作品集怎么沉淀，以及面试会被问什么
作品集不需要多，一个打磨透的项目胜过五个半成品。但“打磨透”有三个可验证标准：一是你能写清楚数据来源和处理流程，每一步处理都有理由；二是你能画出系统的分层架构图，并说清每层为什么这样设计；三是有量化结果，最好有一份“优化前与优化后”的对比记录。
面试时高频被问的问题其实也很固定：你做这个项目时，检索召回率低怎么排查的？模型回答出现幻觉，你的兜底机制是什么？线上调用量突然翻倍，你怎么应对？这些问题考察的都不是模型知识，而是工程判断力。如果你能讲清楚某个问题出现时你的完整排查链路，就已经比大多数只会背模型结构的人有竞争力了。
最后分享一个我个人的体会：做 AI 工程，重要的不是掌握最新最热的模型，而是建立“系统会出错”的预期，并提前为出错做好准备。这种思维不是看书能学来的，只能靠亲手把一个项目从无到有、从乱到稳地跑一遍。如果你正站在起点上，不用等什么“基础扎实了再开始”，直接挑一个数据不干净的、问题有点真实的小项目，动手做一次。做完那一遍，你就不再是 AI 工程“从零”的人了。
