还记得前两年团队招聘的时候，简历上写"AI工程师"的候选人，十个里有八个聊下来其实是在调API，剩下两个是在跑开源模型的训练脚本。当时我就意识到，这个行业缺的从来不是会用某个模型的人，而是能把AI真正"工程化"的人。所谓AI工程，不是照着教程跑通一个Demo，而是要把模型、数据、评测、部署、监控这套东西当成一个整体系统来设计和维护。
这篇文章我想认真聊聊"从零开始做AI工程"这件事，给那些刚入行、或者已经在做AI应用但总觉得自己在"野路子"上摸索的开发者一些参考。我不会只讲概念，会把我在实际项目中验证过的路径、踩过的坑、以及真正重要的取舍都摊开来讲，希望能给不同基础的读者一条可以照着走的路。无论你是想转型AI方向的后端工程师，还是已经在做Prompt调优但想更进一步，这篇文章都适合你。
1. 先说清楚：AI工程不是"调接口"，也不是"写算法"
1.1 三种角色的边界，很多人一开始就没分清
我见过太多人把AI工程理解为"Prompt写得更好"或者"模型训练得更准"。但这两种理解都只覆盖了AI工程的一小块，而且都不是核心。
如果非要划一条线，我会把行业里的角色粗略分成三类：
- ML工程师（机器学习工程师）：核心是模型本身的训练、微调、性能优化，关心Loss曲线、数据集质量、模型精度。
- AI工程师（AI应用工程师）：核心是把模型嵌入到真实业务系统里，关心延迟、成本、稳定性、评测、Agent编排、工具链设计。
- Prompt工程师：核心是设计提示词和交互模板，让模型在给定任务上表现更好。
你会发现，AI工程师是三者里最需要"全局视角"的角色，他不需要亲手训练一个大模型，但必须知道模型怎么选、怎么评估、怎么接入、怎么兜底。
1.2 AI工程的核心是"不确定性管理"
传统软件工程里，函数的输入输出是确定的——我传一个整数进去，它一定返回一个整数，行为是可预测的。而AI工程面对的模型本质上是一个概率系统，同一个Prompt今天答得好，明天换一个Embedding模型结果就飘了，换一个解码温度结果又变了。
所以AI工程的本质工作，我总结成一句话：在不确定性的基础上，搭建确定性的系统。
这意味着你要做的不是追求某一次回答完美，而是保证一百次里有九十次可用，并且那十次不可用的能被系统识别出来、被兜住。这是所有AI工程实践的底层出发点。
1.3 一个端到端系统里的隐藏工作
很多人做第一个AI项目时，以为工作就是"调接口+拼Prompt"。等到真正上线才发现，一个能跑的AI系统里，模型的调用只占不到一半的工作量。我随便列一下：
- 数据的接入、清洗、切块、版本管理
- 评测集的构建和自动化评测流程
- Prompt模板的版本管理和AB实验
- 模型输出的缓存、限流、熔断设计
- 可观测性：Token消耗、延迟、成功率、用户反馈收集
- 安全兜底：内容审核、敏感信息过滤、Fallback策略
这些工作每一项都不性感，但每一项都决定系统能不能从Demo走到生产环境。从零开始学AI工程，本质上就是学会把这些"杂活"系统化。
2. 从零开始的"三步跳"：先跑通，再拆开，最后拼回去
2.1 第一步：选一个最小闭环项目，一年内不用换的那种
我建议所有新手从同一个项目开始：私有知识库问答（RAG）。
为啥是它？因为这个项目具备一个绝佳的"最小闭环"特征：你需要处理数据、做向量化、设计检索、写Prompt、做评测，甚至还能延伸到Agent工具调用。它规模不大，但五脏俱全，是一个可以反复拆解、反复优化的好样本。
我在带新人时给的第一课就是：不要一上来就搭那种"智能客服+多个Agent协作+自动下单"的大系统，那是个巨坑。先做一个能回答你公司内部FAQ问题的知识库问答系统，跑通它，你才算真正入门。
具体做法很简单：把自己手头最熟悉的文档（比如你常看的几十篇技术文档）收集起来，做切块，塞进向量库，然后用一个大模型做生成回答。不做任何花哨的设计，两三天就能跑通。
2.2 第二步：把闭环拆成五层，搞清楚每一层在干嘛
跑通第一个Demo之后，立刻做一个动作：把它拆开，分成五层来看。
- 数据层：原始文档从哪来，格式有多少种，怎么清洗。
- 索引层：切块的策略和向量化的模型怎么选。
- 检索层：怎么召回、怎么排序，召回多少条。
- 生成层：Prompt模板、模型参数、历史对话怎么组织。
- 评估层：用什么标准判断回答好不好，用哪些测试用例。
这五层就是整个AI工程的地基框架。后面你做的所有事情，无非是在这五层里做加深或者加宽。拆开看的时候，你会突然发现很多原来忽略的细节——比如你的切块策略其实影响检索效果，你的评测用例根本覆盖不了真实用户的问题。
2.3 第三步：以工程化标准重新拼装
这个阶段通常发生在第一个Demo跑通后的第三到第四周。你要做的不是加更多功能，而是把之前"能跑"的代码升级成"能用"的系统。我列的改造顺序是这样：
- 先做配置化：模型的名称、参数、向量库地址、Prompt模板全部外置到配置文件，让改一行Prompt不需要改代码。
- 再做缓存层：同一问题的答案在24小时内直接命中缓存，既省钱又降延迟。
- 然后做评测脚本：把测试集变成自动化脚本，每次改动模型或Prompt后能快速回归。
- 最后加可观测性：把每次请求的Token消耗、检索耗时、生成耗时、用户反馈全部记录下来。
走到这一步，你已经不是"调API的"了，而是在真的造一个AI系统。这三步走完，后面学Agent、学微调、学多模态都会快得多。
3. 动手搭环境之前，先把这几件事想明白
3.1 模型选型的真实成本：API与开源部署怎么选
我见过不少团队一上来就想部署开源模型，觉得"私有化部署更安全、不花钱"，结果折腾一个月，GPU集群的账单比API调用费还贵。
我给你一个很实际的对比视角：
| 维度 | 调用商业API（如大模型API） | 私有化部署开源模型 |
|---|---|---|
| 初始成本 | 低，按量付费 | 高，需要GPU服务器 |
| 技术门槛 | 低，接口简单 | 高，需要懂推理优化、部署运维 |
| 数据安全 | 取决于供应商协议 | 数据完全内网 |
| 迭代速度 | 模型升级由厂商负责 | 换模型版本要自己迁移 |
| 适合场景 | MVP验证、中小规模业务 | 数据敏感、规模大、长期成本敏感 |
我的个人建议是：第一个项目永远用API跑，哪怕你最终目标是私有化，也用API先把业务逻辑跑通。因为初期最大的不确定性不是算力，而是业务需求和技术路径理解。等你确定这套系统值得投入了，再评估要不要迁移到开源模型。
3.2 算力预算：不需要先买卡
很多人听说做AI就得买显卡，这是一个巨大的误解。做AI工程和做AI训练是两回事，你在99%的时间里需要的算力，云服务商按小时租就够了。
举个例子，我本地开发的时候几乎不跑任何大模型，所有的模型调用都走后端API。本地只跑Embedding模型做测试，那玩意儿CPU都能跑。真正需要GPU的场景只有两个：微调训练和部署开源模型做推理，这两个场景都是有明确需要才去做的事。
想清楚这一点，你从零开始的成本可以控制在非常低的水平——一个月的API调用费加一台普通开发机，完全足够你学完整个AI工程的基础路径。
3.3 数据优先：测试集就是你的项目说明书
这是我从零开始做AI工程时学到最重要的一件事：测试集比模型更重要。
这么说吧，你选模型、调Prompt、改检索，心里得有杆秤。这杆秤就是一个高质量、覆盖真实场景的测试集。没有测试集，你所有的优化都是在撞运气。
我会建议：项目启动的第一周，除了收集业务数据，还要花专门的时间去"造测试数据"。把业务同学常问的问题、论坛里出现过的问题、竞品的产品里用户会问的问题，全部整理成几百条QA对。先不急着标准化、打分，先把这些QA对按业务模块归类，这就已经比90%的团队领先了。
有了测试集，后面所有的工作都可以变成"修改-跑测试-看分数-再修改"的循环，这跟写单元测试驱动开发是一个道理。
4. 一个最小可用的AI工程长什么样：以RAG应用为例拆解
4.1 数据接入与切块：怎么决定chunk大小
数据接入听起来很无脑——把文档塞进去不就行了？但等你真做起来，第一关就会卡住：你的文档有的是PDF，有的是Word，有的是HTML页面，有的还有表格，格式各不一样。清洗和Parse就够折腾一阵。
切块策略就更讲究了。你切得太小，每块内容不完整，检索时缺少上下文；切得太大，向量检索的命中率下降，而且可能把不相关内容混进上下文。我常用的一个策略是按语义结构切：优先用文档本身的段落标题做锚点，标题和内容放在一个块里，块大小控制在500-1000字左右。如果是代码文档，可以按函数或类来切。
这里有个很实用的技巧：切块的时候给每个块加上"来源、标题、序号"作为元数据，检索阶段就可以用这些元数据过滤。比如用户问的是"安装步骤"相关问题，就直接过滤掉"API参考"章节的块。
4.2 Embedding与向量检索：选型与阈值
Embedding模型决定了你的检索效果的上限。不同Embedding模型的语义理解能力差异很大，不要光看开源排行榜，一定要用自己的业务语料去验证。
我踩过的一个坑是：直接用了一个通用中文Embedding模型，结果业务文档里大量出现专业术语的缩写（比如"CI/CD"、"CRUD"），向量检索的Top 10召回结果里有三四个完全不相关。后来换了一个在代码文档上效果更好的模型，召回质量明显提升。
检索环节还有一个容易被忽略的配置：相似度阈值。如果你的业务场景是"答不上来也不能瞎答"，那这个阈值必须调高，宁可召回结果为空，也别给用户一个错误答案。我的做法是在评测阶段统计正确答案的相似度分布，把阈值设在"比最差正确答案再低5%的位置"。
4.3 Prompt模板与生成策略
有了检索到的上下文，接下来就是把上下文塞给大模型生成回答。这里面有一个非常关键的设计：结构化的Prompt模板。
你是一个企业内部知识库问答助手。 请根据以下背景资料回答问题。 背景资料： {context} 用户问题： {question} 要求： 1. 如果背景资料中没有答案，请明确回答"未找到相关信息"。 2. 回答时优先使用背景资料中的原始表述。 3. 回答结束后，列出回答所依据的资料编号。这个模板有三个设计意图：第一，约束模型不能凭空编造；第二，强制带依据，方便用户追溯；第三，明确"不知道"的边界。这些看起来是Prompt技巧，其实是"不确定性管理"的具体落地。哪怕将来换成别的模型，模板的这些结构也不需要动。
4.4 配置、缓存、可观测性：从小就要有的三件事
我见过很多Demo代码，所有的配置都硬编码在Python文件里，后来要改模型名称得改代码重新部署。这种习惯在AI工程里特别致命，因为AI系统的实验次数非常多，你改Prompt、换模型的速度要比传统开发快得多。
所以我建议项目初始就引入一个简单的配置文件，哪怕是YAML也行。放什么内容？模型名称、模型API地址、API Key、Top P、Temperature、缓存开关、向量库地址、检索TopK、相似度阈值，这些都该外置。
缓存策略上，我的做法是语义缓存：把用户问题做Embedding，和缓存库里过去24小时的问题做相似度匹配，相似度超过0.95就直接用缓存答案。这个策略在高频重复问题的场景特别有效，能省下50%以上的Token费。
可观测性这块，不需要一开始就上重型监控平台，先做到每个请求都有结构化日志就够了。日志里存哪些字段：问题摘要、检索耗时、生成的Token数、总耗时、模型名称、测试结果ID。有了这些，出问题时你才能知道是检索慢了还是生成慢了，是模型变了还是Prompt改了。
5. 到了Agent阶段，工程复杂度会突然翻倍
5.1 ReAct循环：从"一次问答"到"一个任务"
当你的系统不满足于回答问题，而是需要"替用户完成任务"时，你就进入了Agent阶段。RAG是一次检索然后生成，Agent则是一个循环：观察输入 → 思考需要工具 → 调用工具 → 拿到结果 → 再次思考 → 直到任务完成。
这个循环在工程上就意味着：你的系统从"单次调用"变成"多轮调用管理"。你需要处理工具调用失败、循环超时、上下文膨胀、错误路径恢复等一系列问题。
我给新人的建议是：先不要自己手写Agent框架，先用LangChain或类似的成熟框架跑通，重点理解它的循环机制和各类工具的抽象方式，再考虑自己实现。因为Agent的核心难点不在"能跑通一次工具调用"，而在"跑十次别出岔子"。
5.2 工具调用：协议先行，模型后置
很多Agent翻车，问题不在模型，而在工具定义。模型本身是个"意图理解器"，你给它什么工具Schema，它就只能调用什么工具。如果你把工具参数描述写得模棱两可，比如"query_user_info(user_id: str)"，模型一定会在参数格式上犹豫不决。
正确做法是先定义一套严格的工具协议，把参数名称、类型、默认值、取值范围全部写清楚，甚至直接依赖框架的JSON Schema机制。比如：
{ "name": "query_user_info", "description": "根据用户ID查询用户的基本信息，包括姓名、部门、职级。", "parameters": { "type": "object", "properties": { "user_id": { "type": "string", "description": "用户的唯一标识，例如 u_12345" } }, "required": ["user_id"] } }一个我反复踩过的坑：工具描述里说"根据用户ID"，但没说清楚ID格式，模型经常把"张三"当ID传进去。后来把描述改成"根据用户的数字ID（如 u_12345）查询，如果用户提供的是姓名，请先调用 search_user 接口获取ID"，错误率降了一半。工具调用的工程化本质就是把模型的容错边界画清楚。
5.3 多Agent协作：编排方式与职责边界
到了一定规模，你会希望系统里有多个各司其职的Agent——一个管知识检索，一个管数据分析，一个管流程审批。这里最大的工程问题不是让它们各自完成单点任务，而是怎么编排它们的协作方式。
我比较推荐中心化编排模式：有一个"调度Agent"负责理解用户意图，把任务拆解成子任务，然后分发给各个专用Agent执行。调度Agent像一个项目经理，各专用Agent像执行者。这个模式的好处是职责清楚、出错好定位。
中心化编排有一个前提，就是调度Agent必须拥有"任务完成状态判断"的能力。比如子Agent返回了一个"查询结果为空"，调度Agent要能区分这是真的没数据，还是子Agent执行失败。这里就需要在子Agent的返回值里带上结构化状态码了，而不是一段自然语言描述。
6. 我的踩坑清单：这几件事没人提醒你
6.1 评测数据要"自己造"，不要只靠公开集
我一直强调评测集重要，但很多人会犯一个懒：直接拿公开的评测集（比如百科问答类数据集）来评估自己的业务系统。结果就是，评测分数很高，一上线就翻车。
为什么？因为公开评测集的数据分布跟你的业务差太远。你做一个企业内部知识库问答，用户问的是"报销流程能线上办理吗"，公开评测集里哪有这种问题。
我的做法是：用真实用户的历史问题造评测集，哪怕第一版只有一百条，也比一万条公开数据有用。具体方法是拉取过去一个月用户在系统里的真实提问，人工标注出标准答案和对应资料，再按照业务模块抽样平衡做成回归集。以后每次改模型、改Prompt，都拿这套回归集来跑。
6.2 Embedding模型升级会静默改变结果
这是我在一次系统升级中吃到的大亏。当时觉得旧的Embedding模型效果不够好，就换了一个更新更强的Embedding模型，重新向量化后测了几个测试用例，效果确实更好了，于是直接上线。结果上线第三天，用户开始反馈"之前能搜到的东西现在搜不到了"。
原因很简单：换Embedding模型意味着整个向量空间的语义分布变了，原来"距离近"的向量对现在可能变远了，而你只测了那十几个用例，没有覆盖所有高频问题。从那以后我定了一个规矩：换Embedding模型必须全量回归，且至少要观察一周的高频问题命中率对比。
6.3 别让Token成本失控：缓存与合并策略
生成式模型按Token计费，大模型的成本失控是AI工程里的"隐形杀手"。我见过一个团队做了一个客服问答系统，上线第一个月Token费用超出预算六倍，原因就是每次请求都把很大的背景资料塞给模型，而且完全没有做缓存。
控制成本的有效手段有三个：一是之前说的语义缓存，系统里至少有60%的问题是可以命中的；二是压缩检索上下文，给模型的背景资料控制在刚好回答问题的量级，不要盲目追求"把全部候选塞进去"；三是用轻量模型做分类和路由，只有复杂的、高价值的问题才调用大模型，简单问题交给规则或小模型。
6.4 可复现性：随机种子与版本锁
最后一个坑可能只会在你做了几个月之后才会遇到：某一天你发现昨天还能复现的测试结果，今天变了。一查原因是模型服务的解码参数没有固定，或者某个中间依赖偷偷升了版本。
AI系统的可复现性比传统软件更难保证，我一般这样处理：核心模型调用时固定temperature、top_p等采样参数；涉及Embedding的依赖库锁版本，单独形成一个依赖清单；每次测试单独记录模型服务的版本号。养成这个习惯之后，你回滚和排查问题的速度能快十倍。
我在实际项目中摸索出来的这套"从零开始"路径，不敢说适合所有人，但确实帮很多刚开始接触AI工程的人少走了一些弯路。如果你把这一套走通了，再回头去看新的模型发布、新的Agent框架，你真的会发现，所有的AI工程核心问题来来回回就是那几件事——数据怎么管、模型怎么控、系统怎么稳、结果怎么评。把这些基本功打扎实，后面做什么方向都不慌。
