1. 先把话说透：AI工程和普通写代码，到底差在哪里
我最早接触ai engineering这个概念的时候，以为就是"学会调大模型API，写几个Prompt，然后做得比以前用规则匹配更聪明的系统"。真上手做了几个项目之后，发现完全不是这么回事。如果只用一句话总结我的认知转变，那就是：传统软件工程处理的是确定性，AI工程处理的是不确定性。代码运行一万次结果都一样，但同一个Prompt调用十次，结果可能有细微差别；同一个问题换个问法，模型可能给出完全相反的答案。这种"不可控"才是AI工程所有方法论要解决的核心问题。
所以，从零开始学AI工程，不能从某个具体框架的API学起，而是要先建立一套思维框架：你的系统里哪个环节是确定性的，哪个环节是不确定性的，怎么在不确定性的前提下把系统的整体行为控制在一个可接受的范围。这篇内容不是某个工具的手册，而是我这几年来从零开始搭建AI工程能力、落地实际项目的经验梳理。适合正准备把大模型接入业务系统、但又不太确定从哪下手的工程师，也适合那些写Prompt已经有一阵子、但总感觉"演示很美好、上线就翻车"的团队。
咱们把AI工程拆成四条主线来看：模型调用层、上下文工程层、Agent编排层、质量评估层。每一层都有对应的新工种和新技能要求。标题里的from scratch，不是说从写Transformer开始，而是说从"一个只会调API的开发者"成长为"一个能独立交付AI项目的工程负责人"。这篇文章就是记录这条路怎么走的。
2. 从零起步的第一步：搭建AI工程底座，而不是急着写业务代码
很多新手拿到OpenAI或者国产大模型的API Key之后，第一件事就是打开Jupyter Notebook，写一个model.generate(prompt)，跑通了就很兴奋。但真正做工程的时候，你需要的不是Notebook，而是一套能持续迭代、可观测、可回滚的小型基础设施。
2.1 底座应该长什么样：版本管理、配置中心、评测通道三件套
我现在的每个AI项目，哪怕是最小的内部工具，也一定先搭三层东西。
第一层是Prompt与样本的版本管理。Prompt不是写一次就完事的，它会在项目生命周期里被改几十次。你应该像管理代码一样管理Prompt文本——放Git仓库，每次修改有diff、有提交记录。很多团队用Notion或者飞书文档管理Prompt，上线后发现"这版Prompt是哪个版本跑出来的"根本查不清楚。我的建议是，Prompt文件（一般我按system_prompt.py或prompts.yaml组织）必须进版本库，最好绑定一个版本号；如果用了LangChain之类的框架，它们有Prompt模板管理，但底层还是得靠Git把关。
第二层是模型路由与参数配置中心。你把API Key、模型名、温度参数、最大Token数、重试策略这些配置集中到一个配置文件或者环境变量里，而不是散落在各处。模型迭代很快，今天用的GPT-4，明天可能换成更便宜的替代模型。如果配置写死在代码里，换模型就变成一次大改。配置中心和业务代码分离之后，切换模型只是改一个YAML的问题。
第三层是最小可用的评测通道。哪怕项目还没开始，也要先把"输入样本集 + 预期行为 + 评分逻辑"这个骨架搭起来。这个通道不一定一开始就很完善，但它的存在会让你后续做的每一次改动都变得可以被验证。我见过太多团队，项目做了三个月，问"你们怎么评估模型输出质量"，答曰"我们每次都是人肉看的"——听起来还行，但一旦业务量上来，人肉看的代价会彻底拖垮迭代速度。
2.2 环境选型的一些思路：不是越贵越好，也不是开源就一定省钱
关于模型选型，只说一点个人经验。不要一开始就把主力业务绑在单一最强模型上。先拿最强的模型做原型验证，确认"这个任务方向可行"，然后根据任务难度做分层——简单分类任务用便宜小模型，复杂推理交给大模型，中等难度的提取类任务可以用开源模型私有化部署。成本差距是几十倍甚至上百倍。
倒不是说开源模型不好，而是你要算清另一笔账：自托管模型需要GPU机器、运维监控、模型版本迭代的管理成本。如果团队只有一两个后端工程师，优先用API服务，等业务量稳定了、调用次数上来了，再评估自托管的性价比。我们团队有个经验公式：如果单日Token消耗稳定在千万级别以上，并且延迟要求较高，再考虑自托管方案，否则API服务永远是省心的选择。
2.3 模型调用层的工程细节：重试、超时、流式与结构化输出
模型调用看似只是发一个HTTP请求，但工程细节非常多。
一是重试策略。大模型API经常有超时和限流，尤其是业务峰值时段。不能每次失败就直接抛异常回去，否则用户看到的体验就是"AI时不时抽风"。通常我会做三次重试，第一次快速失败，第二次和第三次用指数退避，间隔分别为1秒、3秒。如果三次都不行，再走降级通道——比如返回一个预设的兜底回复，或者调用一个更便宜的备用模型，而不是把错误直接扔给用户。
二是结构化输出。纯文本输出对最终用户没问题，但如果你要让AI的结果继续参与程序逻辑，就得让模型输出严格格式化的内容。常见的做法有两种：一种是老牌的JSON Mode / JSON Schema约束，提示模型只输出JSON并校验；另一种是Function Calling，让模型直接选择工具并填入参数，参数本身就是结构化的。我在生产中绝大部分场景都走Function Calling路线，它可以天然地和Agent框架结合，比先输出文本再解析JSON少踩很多解析错误。
三是流式输出。如果是面向聊天窗口的C端产品，非流式响应会让人等得很崩溃。但是流式输出也有坑：用户界面截断后半句话的展示、Token计费对不上、中间态被当作最终态缓存。如果你的产品接入流式，务必设计好"最终结果以finish_reason=stop为准"的约定。
3. 提示词工程的核心逻辑：不是你写不出好Prompt，而是你没有把Prompt当代码
提示词工程（Prompt Engineering）是AI工程里面被讨论最多、被误解也最多的一个子领域。很多文章把写Prompt讲得像玄学，动不动就说"魔法词"。但我的观点很朴素：Prompt是运行在模型里的程序，你要用一种偏软件工程的思维去写它。
3.1 一个生产级Prompt的骨架：角色、任务、约束、示例、边界
我提倡把Prompt拆成若干个语义模块，每个模块对应一个变量。一个比较经典的结构是这样：
- 角色设定（System）：明确"你是谁、你服务谁、你用什么风格说话"。比如"你是一名客户技术支持专家，回复要专业、简洁、不提其他渠道没见过的问题。"有了角色设定，模型输出的风格方差会显著下降。
- 任务描述（Task）：说明"这次具体要完成什么"，尽量用指令式的祈使句，避免模糊的形容词。不是"帮我看看这个评论怎么样"，而是"判断这条评论的情感极性，输出结果为positive/negative/neutral三种之一"。
- 约束条件（Constraints）：说清"什么不能做"。比如"不要编造你不知道的参数""不要回答和问题无关的内容""不超过50字"。约束不是越多越好，过多的约束会互相打架、降低指令遵循率，我一般控制在三条以内，挑最重要的。
- 示例（Few-shot）：给一两个输入输出对，相当于给模型示范"长什么样算是好结果"。示例的质量非常重要，不要随便写，示例本身就是一套最小的评测标准。
- 边界声明（Fallback）：告诉模型"遇到拿不准的情况怎么办"。比如"如果信息不足，请直接说明需要补充哪些材料，不要猜测"。
这里要提一个细节：模型对Prompt末尾的指令遵循度高于开头。如果你有一段非执行不可的硬性指令，放在末尾比放在开头有效。这个特点不是玄学，Tokens的自注意力结构决定了模型对临近位置的上下文更敏感。
3.2 从写Prompt到建Prompt版本：把提示词当代码管理的实操建议
我在2.1提到Prompt要进Git，这里展开说说具体怎么组织。
建议目录结构长这样：
prompts/ classify/ v1.yaml v2.yaml extract/ v1.yaml response/ v1.yaml v2.yaml v3.yaml每个YAML文件里面至少包含model,temperature,system_prompt,few_shot_examples四部分。改Prompt的时候不要直接在原文件上改，而是新建一个v_n+1文件，保留旧版本。因为线上系统多半还跑着旧版本，一旦你发现新Prompt效果不好，随时能回滚。这个习惯救过我太多次了。
另外一个容易被忽视的点是：给每个Prompt版本记录"为什么改"。在Git的提交信息里写清楚"用户反馈答非所问，补充了关于xx场景的约束"或者"准确率下降，调整示例中的xx边界"。三个月后再看提交历史，你能还原当初的所有决策，这是工程化的一个标志。
3.3 提示词工程和模型能力的关系：别再迷信"万能Prompt"
一个现实是：当模型能力不够的时候，再多的提示词工程也只是在逼近效果天花板。比如让一个小模型做复杂的数学推理，你给它几十个示例，它可能能达到70%的准确率；换个大模型，也许拆成两步ReAct就够了。所以，做AI工程要有个成熟的心态：先把任务拆解成小任务，再判断每个小任务对模型能力的需求级别。真正成熟的AI工程师会花大量时间在做任务拆解而不是写长Prompt。
大任务拆小任务，也是后续做Agent编排的基础。所以我把Prompt工程这章收个尾：Prompt值得你认真对待，但要意识到它只是整个AI工程体系里的一个环节。别把全部希望押在"一段神奇Prompt"上，那个东西我至今没见过。
4. 上下文工程：RAG、记忆与窗口管理，决定系统是"聪明"还是"失忆"
AI工程里，模型本身是固定的，真正拉开系统智商差距的，是你往上下文里塞了什么、怎么塞的。这套东西现在被叫Context Engineering，我从零搭建项目的时候完全没有这个框架，是纯靠踩坑悟出来的。
4.1 RAG不是"把文档塞给向量数据库"就完事了
检索增强生成（RAG）现在是AI应用最主流的知识接入方式，但太多人做出来的RAG效果差，根本原因在于：他们把一个检索问题想得太简单了——以为把PDF切块、向量化、存进向量数据库，然后用户一提问就top-k召回，把文档块拼进Prompt就完事了。实际效果通常是：召回的东西和问题沾边但不精准，模型被不相关信息带跑，输出答非所问。
我自己的RAG实战经验，核心是三个环节都要花心思：
第一，切分策略要跟着"回答粒度"走。页面上常见的固定500字切块法，效果并不好。我发现更有效的是按文档的语义结构切分——比如按Markdown的二级标题来切，每个标题下为一个块；如果块太长再往下拆到三级标题。这样生成的块，语义是完整的，而不是从一个观点中间硬生生截断。回答按"块"来找，而不是按"字数"来找。
第二，检索要多路召回再融合。只做向量Similarity检索有个毛病——对精确术语、人名、型号这类信息不敏感。我在实践里通常跑三路检索：向量检索查语义相似、BM25类关键词检索查精确匹配、必要时加一路元数据过滤（比如"只看2024年之后的文档"），再把三路结果按一个简单的分数公式融合后排序。不要一上来就上"基于Reranker的重排序"，虽然效果好，但会增加系统复杂度和延迟。先用三路召回+加权融合，多数场景就够了。
第三，上下文拼装要引导模型"先看证据再回答"。把检索出的文档块拼进Prompt的时候，不要平铺所有块，要在前面加一行"以下是参考资料，请基于这些内容回答，如果资料中没有相关信息，请明确说明。"这行字看着简单，但对结果的引用准确性有明显影响。模型给自己立了一个"忠于材料"的默认设定。
4.2 记忆管理：短期窗口和长期事实要分开
Agent系统的记忆问题，也是上下文工程的一部分。如果你做一个多轮对话型Agent，不能把历史消息全部无脑塞进上下文，窗口迟早爆掉。我的做法是三层记忆分层：
- 会话短期记忆：保存最近N轮对话全文（一般我在生产环境设10-15轮，取决于模型窗口）。这些是模型当前推理必须依赖的信息。
- 事实长期记忆：从对话中抽取关键事实（用户偏好、已知条件、业务参数），存成结构化记录（JSON或数据库字段）。每次对话开始时，把这些事实重新注入系统Prompt，而不是靠模型从成千上万条历史消息里自己找。
- 技能记忆：记录过这个用户过去要求过哪些处理方式，相当于个性化规则，下次遇到类似问题直接匹配。
这里有个最常见的误区，就是聊记忆的时候只想到"把多轮聊天记录存下来"。真正的记忆系统要存储的，是已经被提炼过的、与用户或者业务相关的状态。存储本身不复杂，难的是"什么时候提炼、提炼什么东西"。
4.3 手动管理Token窗口的一些计算公式
上下文窗口规划，建议从一开始就算清楚账。最大窗口W，你要留出三块空间：系统所需固定上下文（角色设定、工具描述、知识库片段）设为S，多轮历史设为H，模型输出空间设为O，剩下的才是知识库动态检索块R。经验公式是R = W - S - H - O，并且要给O留足余地，输出空间不够是生产环境很常见的问题。
打个比方，假设用16K窗口的模型，系统固定上下文约2K，多轮历史约4K，输出预留2K，那知识库动态检索块最多只有8K——按英文大概6000个Token、中文约4000字。明白这个账之后，你就知道为什么盲目地"文档库几千个块全都塞满"是行不通的。有些团队做完RAG发现上下文放不下，就开始压缩文档，那其实应该早点在规划阶段就做取舍。
5. Agent编排与Harness Engineering：给"会自己循环"的系统装上缰绳
如果说RAG是AI工程的第一阶段，那么AI Agent就是第二阶段。Agent的概念不复杂——让大模型自己规划步骤、调用工具、观察结果、调整行动，形成一个循环。复杂的是，怎么保证这个循环不失控。
5.1 我对Agent循环的认知：从单模型调用到不确定性循环
传统程序是直线式的——输入、处理、输出。Agent是循环式的——模型输出动作指令，程序执行动作，把结果反哺给模型，模型再决定下一步。这个循环，本质上是一个"感知-决策-行动-观察"链。每次循环都有出错和偏离主题的可能，所以工程上最核心的问题是：在什么情况下允许循环继续，在什么情况下必须强制终止。
我给Agent系统定了三条硬规则：
- 最大步数限制。循环最多执行N步（通常6-10步），超过就终止并告诉用户"任务较为复杂，我已执行了最多步数，这是当前进展"。不让Agent无限次地自我纠缠。
- 每一步都必须有可观测的输入输出。Skip不能坐视Agent自己跑了200次Tool Call但不知道它在干嘛。每一步的推理内容、工具参数、执行结果都要记录日志。
- 目标偏离检测。循环每执行完一步，检查当前状态是否还在朝终极目标推进。判断方式可以是一个轻量模型对"当前进度是否接近目标"打一个分，低于阈值就触发人工确认或终止。
5.2 工具调用的设计规范：比选框架更重要的设计模式
Agent的落地表现，很大程度取决于你给它设计的"工具集"。工具不是越全越好，工具越多，模型选错的概率越大。我自己的准则是：每个Agent场景下，工具数量控制在5-8个以内。宁可让工具数量少而精，也不要一股脑把几十个API全暴露给模型。
命名也很讲究。工具名要直白，比如search_orders比query_order_info_from_order_service更不容易混淆。工具的description字段非常关键——模型是根据description来判断该不该用这个工具的，必须写清功能、适用场景、参数格式、异常返回值含义。这个description本质上就是面向模型的"接口文档"。
5.3 Harness Engineering：Agent工程的前沿实践
AI工程圈最近一个很热的话题是Harness Engineering，我理解它的本质是：比起设法把Agent本身调得更聪明，更值得花力气的是设计一套约束、反馈和兜底机制，让一个"能力有限"的Agent也能在可控范围内干活。这个词的涵义有点像给一匹烈马套上马鞍与缰绳——不让它脱轨，也不让它失去奔跑能力。
Harness Engineering落到实践，通常包含四部分工作：
- 约束与护栏：定义Agent允许做什么、不允许做什么，比如"只能读取订单数据，不能执行删除操作"；敏感操作必须加入权限拦截和人工确认。
- 失败与降级路径：Agent工具调用报错时怎么处理？调用重试还是换工具？连续失败会不会让Agent陷入死循环？Harness的一部分就是提前铺好这些备选路径。
- 质量锚点：设定核心质量指标，比如回答准确率、工具调用成功率、任务完成率，让Agent的每一步都有短期的"锚"可以参考——这其实就是把前面说的评测通道引用进来。
- 人机协作接口：明确"什么时候交给机器跑、什么时候必须人工介入"。一个好的Harness不是全自动的，而是知道自己的自动边界在哪里。
近期还有个说法叫Loop Engineering，我理解它更多是关注循环本身的工程控制——包括步数预算、进展评估、中断恢复。这些和Harness是同一层的思想，只是侧重不同。如果你做Agent项目，可以把Loop Engineering看作：Agent跑起来之后的运维和控制问题。
5.4 多Agent不是招财猫，多度拆分的复杂度会反噬
很多团队一上来就要搭"多个Agent协作"的系统，什么规划Agent、执行Agent、审查Agent各司其职。我的强烈建议是：先从一个Agent做起，跑通端到端之后，再把流程拆成两个、三个。多Agent协作的通信开销、状态共享、死锁问题非常复杂，收益往往没想象中大。大部分实际场景，用一个Agent配上合理的工具集就能解决；只有当一个任务里包含多个明显不同的子目标、且需要不同知识体系时，拆分才有真正的收益。
如果团队没有很强的AI工程经验，我非常不建议第一个Agent项目就上多Agent架构。那不是炫技，是自找麻烦。
6. 质量保障：AI测试与评估，从零开始的工程化分水岭
前面说了一堆怎么搭系统，但AI工程项目真正的分水岭是——你有没有一套可靠的评估体系。没有评估体系的AI项目，是不可持续的；每个改动都是在盲改，上线靠感觉。
6.1 建设评测集：正例、反例、边界案例一个都不能少
评测集是AI工程的"测试用例"。我每次做项目，都会要求建设三类样本：
- 正例：输入表现正常、期望结果清晰。这部分是模型见过较多、效果较好的领域。
- 反例：针对"不应该答什么"的场景，比如用户问的超纲问题、带诱导性的问题，期望行为是拒绝或澄清。
- 边界案例：最容易让系统翻车的情况——上下文不够时的回复、超长输入的截断、多轮话题切换、特殊格式的输入等。
规模上，从30-50条起步就够了，不必等造出上千条才开工。但是一旦开始，就要把它当成固定资产去维护——每周根据线上真实用户反馈补充10-20条新样本。最终，一个稳定项目的评测集通常在500条以上。
有了评测集，评估方式有三层：规则评分（能用代码判断的，如格式正确性、是否包含禁用词）、模型评分（用一个较强模型当裁判，对输出质量和参考答案比对打分）、人工抽检（抽5%-10%样本做人工复核，校准模型评分的偏差）。三层结合，效率和质量基本都能保住。
6.2 回归测试：AI项目改动后的第一道关卡
AI项目上线之后，如果改了Prompt或换了一种模型，一定要跑评测回归。跑出来的分数不仅看平均值，还要看每个样本的分数变化。有时候平均值上升，但某个类别的样本大面积退化，这种"偏科"回归是最容易坑人的。我的实践是把评测样本按业务场景打标签，比如"投诉处理""订单查询""闲聊兜底"，回归结果按标签分组展示。看到某个标签的分数明显下降，就说明这个改动影响了那个子场景，需要针对性修正。
对于线上真实流量，建议加一个影子验证环节：新版本在导入生产环境之前先部署到影子环境，把线上输入同时发给新旧两个版本处理，跑几天对比两者输出质量，确定新版本确实在关键指标上不落后于旧版本，再慢慢放量切换。这个模式其实和互联网公司的金丝雀发布一脉相承，只不过"健康检查"从监控指标变成了"输出质量评估"。
6.3 可观测性：AI应用要有自己的日志规范和追踪体系
传统后端有日志、指标、链路追踪三大件，AI应用在此基础上，有几个特殊的观测点：
- 输入血统：每一次模型调用，对应的Prompt模板版本是多少，检索到了哪些文档块，最终生成结果是什么。
- Token账单：按会话维度、按用户维度、按场景维度统计Token消耗。不加追踪的话，你根本不知道哪个用户、哪个场景把成本吃掉了大半。
- 延迟分析：一次请求的总延迟里，模型推理占多少、检索占多少、向量化占多少、外呼其他API占多少。不加追踪，性能优化只能靠猜。
我用过的方案里，LangSmith方便但偏品牌绑定，自建一个小型的Prompt与调用日志表也不难——核心是把每次调用的输入输出和元数据存下来，之后配合评测集做离线回放分析。做到"每一个线上坏case都能回放到当时的输入上下文"，这是AI工程能力成熟的一个显著标志。
7. 我从零开始做AI工程踩过的几个真实的坑
前面讲的都是方法论，这一章我想把印象最深的一些坑单独拿出来说说，因为这些实际操作中积累的经验是文档里不会写的。
7.1 上下文塞爆的无声崩溃
有一次我们做一个客服助手，上线初期一切正常。运行了三天之后，用户反馈"机器人越来越傻了：刚说完的事情马上忘，有时候一句话要问三遍"。排查了很久，最后发现问题出在记忆策略上——我们没有对上下文做截断，Session越长，历史塞得越满，后续检索的文档块不断被挤掉，模型反而"看不到"当前需要的信息。这个问题的高明之处在于它不报错，也不崩，只是答案质量悄悄下降，如果不是用户投诉根本发现不了。从那之后，我给自己定了一条规矩：所有Agent系统必须显式监控当前上下文的Token占用率，超过80%就触发历史裁剪告警。
7.2 "越改越聪明"导致的回归丢分
还有一个印象很深的坑，是我们试图优化一个分类任务的时候，给Prompt加了一段"常识背景说明"，当时随手一测发现正确率提升了不少，就上线了。结果第二天一看评测结果，原来几个接近90分的数据类别掉到了60分。原因是我们丢进去的那段背景信息给模型带来了"先入为主"的偏见，某些类别的边界反而被模糊了。
这给了我一个重要教训：Prompt的每一次改动都要像改代码一样跑回归评测。不跑就跑，后面迟早有一脚是踩在同一个坑里的。
7.3 Token成本失控的"隐形账单"
我们有个多轮检索场景，刚开始没太在意Token消耗，结果是月底账单出来，成本比预估的高了三倍。复盘后发现，我们为了提升准确率，每轮都让模型把全文文档重新读一遍，导致单次调用的Token量巨大。
成本控制不能靠事后亡羊补牢，在设计阶段就应该有预判——控制检索块大小、限制最大步数、对高频固定内容加缓存。现在只要上线新功能，我第一件事就会要求能按场景预估Token成本，再决定要不要做精简化处理。
7.4 评测集与真实场景脱节
有一个很隐蔽的问题，就是评测集永远来自开发人员的想象，和真实用户提问相差很远。我们的一个项目，评测集准确率达到92%，但用户反馈还是经常"答非所问"。后来分析发现，评测集里的问题都是我们自己的工程师写的，表述规范，意图清晰；真实用户的问题却很口语化、会有错别字、会有意图混杂的表达。模型真正暴露在脏乱差输入下，表现自然大打折扣。
从那以后，我建评测集的一个原则就是：每周从真实会话日志里抽20条用户输入，直接进评测集，不经过任何加工。这样才能保证评测集和真相不脱节。
8. 下一步的方向：AI Native研发范式与团队能力模型
整个AI工程实践走到今天，正在从"把AI接入到传统软件系统"演进到"以AI为中心来设计整个系统"——也就是大家常说的AI Native研发范式。
8.1 从代码驱动到数据驱动的转变
传统软件研发是代码驱动的——逻辑写好，测试写好，行为就确定了。AI Native项目则变成数据驱动的：你维护的核心资产不是代码，而是"数据"——Prompt模板、评测样本集、用户反馈、模型配置。
这意味着研发过程中最重要的工作逐渐变成了数据的采集、清理、标注、迭代。团队会更像一个"数据运营团队"而非"代码开发团队"。一个可见的表现是：你在Git里面最多的提交不再是代码文件，而是评测集和Prompt配置。这也是为什么我会在前面反复强调，要像管代码一样管理评测集和Prompt版本——因为它们才是AI系统的灵魂。
8.2 团队角色有什么变化
从零搭建AI工程项目，团队至少需要四种角色：
- AI应用工程师：负责搭建端到端的AI应用，懂Prompt、懂RAG、懂Agent编排、懂必要的后端。
- 评测与数据工程师：负责评测集建设、回归分析、数据飞轮运转。没有这个角色，AI项目很容易沦为依赖个人感觉的黑箱。
- 平台/DevOps工程师：负责模型网关、成本监控、日志追踪、上线发布。
- 业务/领域专家：负责定义"什么是好的输出"，这是AI应用能否真正解决业务问题的关键。YAML里那行"不要在回复中编造没有依据的信息"听起来简单，但"哪些信息算有依据"，往往只有业务专家能定义清楚。
8.3 一个小结：从零开始的路线图
最后把这套从零开始的路径用路线图的方式压一遍，方便大家直接落地使用。
阶段一，搭底座：定模型选型、建配置中心、建一条最简陋的评测通道，哪怕评测集只有20条。
阶段二，做单点：选一个业务场景，用Prompt工程把它跑通，记录Prompt版本，添加上下文管理。
阶段三，接Agent：在稳定的单点闭环基础上，引入工具调用与Agent循环，设定步数上限、日志、护栏，走向Harness Engineering。
阶段四，建体系：把评测集规模拉到500条以上并每周补充，配置影子环境做回归对比，建立调用日志追踪，让AI效果可度量、可回归、可回滚。
阶段五，数据飞轮：从用户真实反馈中不断补充评测样本，用线上数据修正Prompt与检索策略，把项目从"上线就停"变成"持续进化"。
每个阶段之间不要跳步。我看到过太多团队直接从阶段一跳到阶段三，结果就是演示惊艳，上了生产环境天天救火。AI工程的本质，是用工程手段去驯服不确定性，而工程手段从来都不是靠一个惊艳的Demo就能替代的。
我个人这几年的体会是，做AI工程最需要的那种能力，其实不是技术知识，而是在不确定性面前保持冷静的耐心。面对模型的随机输出，你要有足够的工具和方法去观察它、评估它、约束它，而不是靠重试祈求运气。如果你正打算从零开始做AI工程，把前面这些内容当成一个路线图还不够，更建议从自己的第一个小项目出发，把评测集、Prompt版本、调用日志这三样基础功夫练扎实——这些才是真正的护城河。