AI Engineering From Scratch这个标题我盯了很久。过去两年我带团队从一个只会调大模型接口的组慢慢走到能设计多 Agent 工作流、建立评估体系和护栏机制中间踩过的坑差不多能写成一本小册子。这篇文章我不想讲那些“三天上手大模型”的速成理论而是按项目复盘的节奏把从零到一搭建 AI 工程能力的完整路径拆给你看。内容包含能力地图、最小技术栈、一个双 Agent 实战案例以及工程化阶段最让人头疼的排查经验。适合三类人看准备转型 AI 工程的开发者、正在带 AI 项目的技术负责人还有已经把 API 调通了、但总觉得离“工程”还差一层的人。1. 项目定位与核心思路从调接口到做工程1.1 “从零开始”到底指什么很多人听到 AI Engineering 的第一反应是“这不就是调大模型 API 嘛”。作为过来人我可以直接告诉你如果只停留在调 API那叫接口对接不叫工程。真正的 AI 工程要从零搭建一条能处理真实业务输入的链路并且在模型输出不稳定、输入数据千奇百怪、业务方需求频繁变化的条件下依然保证系统能稳定运行。这条链路通常包含四层模型层、数据层、应用层、运维与交付层。模型层要搞清楚模型的能力边界什么任务适合它、什么任务它天生做不好数据层要考虑输入怎么清洗、带格式的文本怎么解析、输出怎么回流到业务系统应用层要设计 prompt、Agent、工具调用和业务逻辑的衔接方式运维与交付层则要解决稳定性、监控、成本和权限问题。任何一个环节缺失这个系统就只是一堆 demo 的拼凑。从零开始的真正含义是没有现成体系可以依赖。你不需要懂怎么从零预训练一个大模型——那是另一个完全不同的领域——但你必须懂得如何把已经存在的模型能力变成稳定、可控、可衡量的产品能力。这是 AI Engineer 和普通 API 使用者之间最本质的区别。我在面试候选人的时候通常不会问他会不会用某个框架而是让他描述一个线上 AI 功能从输入到输出要经过哪些环节、每个环节可能出什么错、出错以后怎么兜底。能把这些问题说清楚的人才是真的在做工程。1.2 能力地图先看全貌再动手我强烈建议所有从零开始的人先画一张能力地图不要一上来就写代码。这张地图至少包含五个模块模型认知理解上下文窗口、温度参数、推理模式、系统提示词对输出的影响。应用范式知道 RAG、Agent、Workflow 分别解决什么问题各自的局限在哪里。工程要素评估集、日志、可观测性、成本控制、安全与护栏。业务落地能识别高价值场景、定义清晰需求、设计用户反馈闭环。工具链知道每个环节用什么工具而不是盲目堆框架。为什么一定是这个顺序因为 AI 项目的失败大多不是模型能力不够而是场景选错了、链路没跑通、改动了却没有评估依据。我带团队时的固定要求是第一步先把业务场景写下来圈出最痛的一两个切片再决定技术方案。很多人一上来就想做个“万能 Agent”最后做出来的东西哪个场景都接不上这就是典型的没有先看全貌就动手。这里还要泼一盆冷水不要迷信“无限可能”。大模型确实能做很多事但把它放进一个真实系统里你考虑的是响应时间、费用、幻觉率、可维护性这些约束条件。技术永远是为场景服务的在 AI 项目里这个原则比传统软件项目更容易被人忽略因为模型能力本身太吸引眼球了。2. 从零搭建 AI 工程的最小技术栈2.1 模型选型逻辑先看任务再看参数从零起步时中心一定是 LLM API原因很简单自己训练模型既不经济也没必要。一个成熟的模型 API 能让你跳过权重管理、推理部署、算力成本等一系列问题把精力集中在业务逻辑上。但选型不是“哪个模型最强选哪个”而是要看你的任务类型。任务类型关键关注点选型倾向复杂推理、数学、代码生成推理能力、逻辑一致性通用旗舰模型或强推理模型长文档理解、大量上下文上下文窗口、长文本稳定性长上下文能力突出的模型中文场景、本地化中文语义理解、国内服务稳定性中文语料表现好的国产模型或开源中文模型高频低成本场景单次调用价格、延迟、吞吐轻量模型或开源权重模型我在实际项目里比较过多款模型最深刻的体会是同一个任务在不同模型上的稳定性差异非常大尤其是 JSON 输出、工具调用和长上下文这三项必须用你自己的语料做基准测试不能只看公开榜单。榜单测的是平均能力业务要求的是边界内的稳定——这两个是完全不同的维度。另外不要把模型服务商绑死在一个选择上。我的建议是在代码层做一层薄薄的模型抽象所有 prompt 的输入输出都走统一的数据结构这样后续替换模型时只需要改配置不用改业务代码。这个抽象成本很低但能救命的次数远超你的预期因为模型迭代太快今年最好用的方案明年可能就会被新的选择取代。2.2 最小技术栈清单克制是美德AI 工程的技术栈选择我的建议就两个字克制。先列一份最简清单再根据实际需要逐步加东西。环节工具或方案使用阶段LLM 接入API Key requests 或官方 SDK必须有编排框架先从 Python 脚本开始复杂之后再考虑 LangGraph 等按需向量数据库只有做 RAG 才需要没有场景就先别引入按需可观测性Langfuse 或 LangSmith或自建日志表强烈建议评估手工准备的黄金用例集 简单脚本必须有为什么这么克制因为框架抽象会掩盖底层问题。我对团队的要求是先用最直接的方式把“调模型、传参数、拿结果、写日志”这四步亲手实现一遍。等你自己写过一遍最原始的调用代码再去看任何编排框架都会觉得熟悉更重要的是线上出问题时你能分清楚到底是模型的问题、prompt 的问题还是框架本身的问题。一上来就套框架的话排查问题的效率会低好几倍。另外一个常见的错误是一开始就引入一堆中间件。有朋友的项目甚至还没跑通一个最小 demo就已经接好了 Redis、消息队列和三个向量数据库。我问他为什么他说觉得以后肯定用得上。这种“防御性架构”在 AI 项目里是毒药因为你的核心链路都还没验证过技术栈越复杂试错成本越高。先把单条链路跑通再考虑扩展这才是从零开始该有的节奏。2.3 动手前三件套环境、数据回流、评估意识正式开始写代码之前有三件事值得先做。第一是环境准备Python 3.10 以上版本用虚拟环境隔离依赖API Key 放在环境变量或 .env 文件里不要写死在代码中也不要提交到代码仓库。这个看起来是老生常谈但我见过不止一次有人因为 Key 泄漏被刷爆账单。第二是数据回流设计。把生产环境的每一次请求的输入、输出、模型、参数、耗时、费用全部落库。很多团队做 AI 应用做到后期发现没数据可用来评测、没数据可用来微调就是因为最开始没留这个心眼。数据回流不是可选项它是后续所有优化的地基。第三是评估意识。哪怕先准备 20 条“黄金用例”也要在写第一个 prompt 之前就准备好。所谓黄金用例就是你挑选的、能代表真实业务场景的输入输出对例如“某条典型用户问题应该得到什么结构的结果”。没有评估集你改 prompt 完全靠感觉改完也不知道是变好还是变坏。我在项目里被这条救过无数次它绝对值得排在最优先的位置。3. Prompt Engineering 与 Agent 的实战拆解3.1 Prompt 的四个基础模块角色、任务、上下文、输出约束Prompt 是最容易被低估的工程环节。我见过很多开发者的第一版 prompt 就是一句话“请帮我总结这段文字”模型输出当然也能用但完全不可控。真正工程化的 prompt至少要包含四个基础模块角色定义、任务描述、上下文输入、输出约束。角色定义之所以有效是因为模型在做自回归生成时角色设定会显著影响它输出的先验倾向。你告诉它“你是一个严谨的财务分析师”它给出的回答风格和你只说“帮我看看这段文字”是完全不一样的。用生活类比来说就像你找同事帮忙你告诉对方你的身份和需求背景对方就知道该用什么语气、按什么模板来回应。任务描述必须具体、可执行不要用“请帮我处理一下”这种模糊指令。上下文输入要给足相关信息但不能过量超出上下文窗口后模型会忽略中间部分甚至被无关信息带偏。输出约束是很多人最容易偷懒的一环恰恰又是后续程序化对接最关键的一环。我建议在 prompt 里直接给出输出格式示例例如你是一个资深行业分析师。 你的任务是根据用户提供的资讯文本生成一份结构化简报。 资讯文本如下 {article} 请输出 JSON 格式字段包括 source, title, summary, implications, confidence 要求 1. summary 不超过 80 字 2. confidence 取值 0 到 1 3. 如果资讯内容不足以判断confidence 给 0.4 以下并在 summary 中说明原因。给示例这件事本质上是把“抽象的要求”翻译成“具体的模板”。你让一个人“写清楚一点”他可能不知道什么叫清楚但你给他一张填好的表格模板他照着填就不会跑偏。模型也是一样的道理。所以凡是需要稳定输出的场景我都强烈建议加上 few-shot 示例哪怕只有一个例子效果也比纯文字规则好很多。3.2 从 Prompt 到 Agent意图识别、工具调用与上下文管理把静态的 prompt 变成动态的 Agent核心是引入一个循环模型读状态、决定动作、调用工具、观察结果、再做下一步决策。这个循环有三个子问题需要单独设计意图识别、工具调用、上下文管理。意图识别是第一步。用户输入进来系统要先判断它属于什么任务。简单场景可以用规则比如包含特定关键词就走某条分支复杂场景可以用模型自己分类但要注意分类结果的格式必须稳定否则后续逻辑没法处理。工具调用是把工具以 JSON Schema 的形式提供给模型模型返回要调用的函数名和参数代码层负责真正执行并把结果回填给模型。上下文管理则是决定哪些历史消息保留、工具结果怎么塞回去避免 token 溢出和上下文污染。下面是一个非常基础的 Agent 循环骨架理解了它任何框架在你眼里都是换了一层皮def run_agent(user_input, max_steps5): messages [{role: system, content: SYSTEM_PROMPT}] messages.append({role: user, content: user_input}) for _ in range(max_steps): response llm.chat(messages, toolsTOOLS) msg response[choices][0][message] messages.append(msg) if msg.get(tool_calls): for call in msg[tool_calls]: result execute_tool( call[function][name], call[function][arguments] ) messages.append({ role: tool, tool_call_id: call[id], content: json.dumps(result, ensure_asciiFalse) }) else: return msg[content] raise TimeoutError(agent exceeded max steps)这段代码看起来简单但它把最核心的几件事都做对了循环有上限、工具调用结果按协议回填、最终输出以模型返回为准。我在生产项目里发现Agent 出问题最容易的地方不是模型不会用工具而是上下文管理——工具结果太长、历史消息太乱导致模型下一轮决策被无关信息干扰。所以上下文管理不是“把信息都塞进去”而是“把必要信息以清晰结构塞进去”。3.3 多 Agent 协作的设计套路少拆拆了就要有协议当单个 Agent 的角色和任务太多输出质量会明显下降。这时候可以考虑拆成多个 Agent 协作常见套路有三种主管-执行者模式、流水线模式、辩论模式。主管-执行者模式适合一个任务需要多种能力的场景由主管负责拆解和分配流水线模式适合数据逐步加工的场景每一步的输出是下一步的输入辩论模式适合需要多角度分析的场景让两个 Agent 互相挑战再由一个裁判做最终裁决。协作模式适用场景优点风险主管-执行者任务复杂、能力多样职责清晰易扩展主管可能成为瓶颈流水线数据逐步加工链路直观好调试上游错误会一路放大辩论需要多角度分析能减少盲点输出不稳定成本翻倍但我要说的是多 Agent 不是越多越好。每多一个 Agent系统就多一层不确定性也多一个出错点。我的经验是先上单 Agent跑通之后再拆。必须拆的时候每个子 Agent 都要有明确的输入输出协议否则整个链路根本没法调试。你可以把多 Agent 想象成一个公司每个员工职责清楚、交接文档标准这家公司才转得起来。如果大家职责重叠、沟通靠感觉那这个公司一定乱成一锅粥。4. 完整实操从零构建一个“情报摘要 任务拆解”双 Agent 工作流4.1 场景定义与需求梳理纸上谈兵讲完了接下来我用一个完整的实操案例把整个过程串起来。我选的场景是“情报摘要 任务拆解”双 Agent 工作流团队每天会收到大量行业资讯第一个 Agent 负责把每篇资讯读成结构化摘要第二个 Agent 基于摘要和团队已有的历史决策记录拆解出可执行的任务。选这个场景的原因是它非常典型输入是非结构化的长文本输出是半结构化 JSON而且上游一旦出错下游全部跟着错非常适合演示 AI 工程最核心的协议设计、异常处理和链路调试。如果你现在想复现也不一定非要做行业资讯把输入换成评论、工单、政策文件都可以逻辑完全一样。需求梳理阶段要明确两点。第一第一个 Agent 的输出字段必须是第二个 Agent 可以直接消费的确定接口不能有模糊字段。第二整个流程必须有降级方案某个 Agent 失败时系统是重试、跳过还是人工介入要在需求阶段就定好而不是上线后遇到问题才临时拍脑袋。4.2 定义输出协议AI 工程的生命线整个工作流的核心是输出协议。我先定义第一个 Agent 的输出 JSON 格式{ source: 原文来源, title: 资讯标题, summary: 80字以内的核心内容摘要, trend_impact: { direction: positive, level: 4 }, suggested_actions: [可执行动作1, 可执行动作2] }每个字段的定义都要尽量没有歧义因为第二个 Agent 拿到这份 JSON 后不会再去看原文。字段含义一旦模糊整个下游就悬空了。我在项目里吃过这个亏一开始 trend_impact 只写了一个“impact”字段模型经常输出一些语义模糊的中性词下游根本无法判断应该怎么处理。改成 direction level 的二维结构之后解析和决策都稳定了很多。所以在设计协议时不要怕字段多怕的是字段定义不清。你可以把协议理解为两个模块之间的接口文档接口文档写得潦草联调的时候一定互相甩锅。AI 工程里的接口不只是代码层面更是模型输出层面的接口。4.3 摘要 Agent 的 Prompt 设计每个规则都要有理由摘要 Agent 的系统提示词我会写成这样你是一个行业情报分析师。你的任务是把用户提供的资讯文本做成结构化摘要。 你要严格遵守以下规则 1. 只基于用户给出的文本生成内容不自作主张补充外部知识。 2. 如果原文包含多个主题只挑出最重要的一个不要贪多。 3. summary 控制在 80 字以内使用简洁、客观的表达。 4. trend_impact.direction 只能是 positive、negative、neutral 中的一个。 5. trend_impact.level 是 1 到 5 的整数5 表示影响非常大。 6. suggested_actions 必须是可以直接执行的动作禁止写“继续关注”这类空话。 7. 当原文信息不足时将 confidence 降为 0.4 以下并给出原因。每一条规则的背后都有真实的踩坑第 2 条是因为模型喜欢把多个主题都塞进摘要导致每个都说不透第 6 条是因为模型最容易偷懒输出一堆正确的废话第 7 条是为了给下游一个明确的“不确定信号”让任务拆解 Agent 懂得收敛而不是强行拆解。所谓 Prompt 工程不是把要求写得漂亮而是每条要求都能对应到一次线上翻车。同时我要求这个 Agent 输出时 temperature 设为 0.2。温度太低模型会变得机械摘要质量反而下降温度太高输出会不稳定。0.2 是我在摘要类任务里常用的折中点。4.4 任务拆解 Agent 的 Prompt 设计基于结构化输入做决策第二个 Agent 的系统提示词核心要求是只基于第一个 Agent 的输出做决策不重新阅读原文。这样做的直接好处是控制 token 消耗并且让第二个 Agent 的注意力集中在结构化字段上不会被原文里的噪声干扰。你是一个任务规划专家。你会收到一份已经完成的资讯摘要 JSON请基于它拆解出团队下一步要做的任务。 注意你只能使用 JSON 中的信息不要假设任何 JSON 中没有提到的内容。 要求 1. 输出一个 JSON 数组每个元素包含 task_title、priority、assignee_hint、due_advice。 2. priority 只能是 high、medium、low 三个值。 3. assignee_hint 填写最合适承担任务的团队角色不使用具体人名。 4. 如果摘要中 confidence 低于 0.4不允许拆解任务输出空数组。 5. 任务数量控制在 1 到 3 条不要为了凑数而拆解。这里有一个非常实用的设计让模型“基于输入决策而不是基于想象创作”。很多任务拆解 Agent 效果差原因就是模型脑补了原文没有的信息。把规则限定死再配合温度 0.1任务输出的可执行性会大幅提升。4.5 代码串联把两个 Agent 变成一条可运行的工作流在代码层面不需要复杂的框架。最直接的思路是调用第一个 Agent、解析 JSON、失败重试、把结果传给第二个 Agent。伪代码如下def run_dual_agent(article): # 第一步摘要 Agent summary_text call_llm( SUMMARY_SYSTEM_PROMPT, article, temperature0.2 ) summary_data safe_parse_json(summary_text) # 解析失败则带示例重试一次 if summary_data is None: summary_text call_llm( SUMMARY_SYSTEM_PROMPT \n参考示例\n SUMMARY_EXAMPLE, article, temperature0.2 ) summary_data safe_parse_json(summary_text) if summary_data is None: return {error: summary_parse_failed, raw: summary_text} # 第二步任务拆解 Agent action_text call_llm( ACTION_SYSTEM_PROMPT, json.dumps(summary_data, ensure_asciiFalse), temperature0.1 ) actions safe_parse_json(action_text) if actions is None: return {error: action_parse_failed, summary: summary_data, raw: action_text} return {summary: summary_data, actions: actions}需要特别说明两点。第一safe_parse_json 里我会做容错处理包括去掉 markdown 代码块标记、提取第一个大括号或中括号内容、必要时截断修复。因为就算你反复要求“只输出 JSON”模型偶尔还是会夹带解释文字。第二解析失败后把原始输出一并返回这个信息对排查非常关键很多人的代码里只报“解析失败”却不留原始输出排查问题的时候两眼一抹黑。实际跑这个工作流我算过消耗摘要 Agent 平均消耗约 1200 token任务拆解 Agent 平均约 600 token。相比单 Agent 一股脑处理原文双 Agent 多了一个约 600 token 的调用成本但效果提升非常明显值得花这点钱。4.6 评估与迭代用数据说话别凭感觉我用 20 条真实资讯作为测试集每一条都预先标注了标准的摘要字段和任务拆解结果。跑完后的评估维度包括JSON 可解析率、字段覆盖率、人工打分。人工打分主要看三个点摘要是否偏颇、trend_impact 是否合理、任务拆解是否可执行。评估维度线上标准实测第一版优化后JSON 可解析率100%85%100%summary 准确率90%70%88%suggested_actions 可执行率80%45%90%第一版最让我头疼的问题是动作质量低。模型经常输出“持续关注行业动向”“保持跟踪”这种空话这本质上不是模型能力问题而是输出约束里没有给出好例子。我在 prompt 里加了一个“好动作 vs 坏动作”的对照示例后可执行率从 45% 涨到了 90%。这个迭代过程完美解释了为什么要先准备评估集——如果没有这 20 条测试用例我可能还在用“感觉变好了”来安慰自己。5. 常见问题与排查技巧实录5.1 常见问题速查表我整理了一份高频问题速查表都是真实项目里反复出现的问题问题现象可能原因排查思路常用解法JSON 解析失败模型被上下文带偏输出夹带解释文字查看原始输出确认是格式问题还是内容问题加 few-shot 示例、开启 JSON mode、后处理提取摘要内容偏离原文上下文过长被截断检查实际发到模型的文本长度做文本截断、分块只保留关键段落Agent 反复调用工具或死循环没有设置最大步数查看每一步的工具调用记录强制 max_iterations并定义明确退出条件上下文污染工具结果太长被原样灌回 prompt查看下一轮 messages 内容对工具结果做摘要压缩而不是原样回填输出效果飘忽不定温度过高查看请求参数结构化任务用 0~0.3创意任务再考虑调高这个表里的每一条都是我踩过的。尤其上下文污染这条我最初以为是模型推理能力不够排查了很久后来发现是前一轮工具返回了两千字的日志文本模型注意力完全被冲散了。从那以后凡是塞回 prompt 的工具结果我都会先做个摘要或限制长度。5.2 三层定位法从输出异常反推到底层AI 应用排查问题最难受的点在于不确定性强。我的排查方法可以归纳为三层定位法先看原始输出再回看 prompt 与上下文最后检查链路。第一层拿到异常的原始输出先判断它属于格式问题还是能力问题。如果模型根本没有输出你要求的结构通常是 prompt 约束不足如果结构有了但内容不对可能是模型本身推理能力不够。第二层回看发给模型的实际消息检查系统提示词、历史消息、工具结果有没有问题。很多时候你以为发了什么和你实际发了什么完全是两回事。第三层检查链路也就是上游的输出是不是被下游正确消费了有没有中间环节擅自修改了数据。我在真实项目里遇到过一起典型的“玄学问题”Agent 突然连续拒绝执行任务回复“抱歉我无法完成这个任务”。第一层看输出格式完全正常第二层看消息内容发现历史记录里混入了一条工具执行失败的错误文本模型误以为有一条用户指令要求它停止。我们把那条错误文本从上下文里过滤掉之后问题当场消失。这个案例说明日志留痕有多重要——如果没有完整的消息记录这种问题根本没办法定位。5.3 三个独家避坑技巧第一不要在 prompt 里使用模糊的程度词。“请尽量详细”“大概总结一下”“严格一点”这类表达对模型的影响极不稳定远不如直接给出“summary 不超过 80 字”“只输出 JSON”这样可校验的硬约束。模型理解字面规则的能力很强理解抽象程度词的能力很差。第二对用户输入先做过滤和校验不要把所有判断都交给模型。在用户输入到达模型之前先做长度限制、类型校验、内容合规校验。否则一个恶意或者极端的输入可能导致模型输出不可预测的内容。把安全决策放在代码层而不是依赖模型自觉。第三分阶段灰度。AI 应用的行为边界在初期是不清晰的建议先内部使用一到两周再开放给十人小团队最后才全量上线。小范围灰度的意义不只是收集反馈更是让最刁钻的那部分输入提前暴露避免一上线就被真实流量打崩。我见过太多团队直接全量结果第一天就被某个意料之外的输入搞出了线上事故。6. 从工程实现到工程化评估、护栏与演进路线6.1 控制层给 Agent 装上方向盘、刹车和仪表盘Agnet 的能力越强越需要一个外部的稳定控制层这就是圈子里常说的 Harness Engineering 思路。它要做的事情很简单任务边界、最大步数、敏感操作人工确认、异常分支自动降级。我把它比喻成给一个强劲的引擎装上方向盘、刹车和仪表盘——引擎再好没有刹车没人敢开。具体落地有四个要点。第一所有工具调用前做参数 schema 校验模型生成的参数再可信也要在代码层验证再执行第二涉及写操作、费用消耗或者影响外部系统时强制人工确认不让模型自行决定第三Agent 循环必须有最大步数和明确终止条件否则一个错误决策可能让系统无休止地调用工具第四加熔断机制连续三次调用失败就停止并通知人而不是反复重试烧钱。控制层看起来是在限制 AI 的能力实际上是让这个系统具备上线资格。一个没有止损能力、没有边界约束的 AI 应用本质上是个事故隐患。我在项目里把控制层的开发优先级排得比 agent 功能本身还高因为越接近真实用户越会发现边界条件才是最大的风险源。6.2 评估体系的建设顺序从小样本到自动化的演进评估体系不用一步到位可以分三个阶段。第一阶段用 20 到 50 条黄金用例做离线回归。每次改 prompt就对着这些用例跑一遍看评分是上升还是下降。这是成本最低的评估方式但对初创项目已经够用。第二阶段上线后自动收集真实输入输出定期从中挑选新增的典型 case 扩充评估集。第三阶段引入 LLM 作为裁判模型但裁判模型绝对不能自由发挥要给它一张固定维度的评分卡包括相关性、完整性、格式合规、有害性等。有一个教训值得单独说不要让生成模型和评估模型是同一个模型的同一种配置。用同一个模型既做生成又做评估它会非常偏向自己偏好的表达风格导致评估结果失真。我的做法是让裁判模型严格对照评分卡逐项打分并且定期人工抽检部分样本。如果你预算紧张宁愿少跑一些自动评估也要保住人工抽检的环节。AI 评估的本质不是追求完美的自动化而是保证“大的方向不会错”。6.3 进阶路线从工作流到推理模型再到产品化从工程实现走向更深层次有两条路线。研究向的朋友会关注如何从零构建推理模型这个方向确实很值得兴奋但它的门槛在于数据合成、训练稳定性和评估方法论如果没有对应的算力和研究时间我建议不要轻易碰先把手头的工程做扎实更有性价比。工程向的进阶优先级我的建议是prompt 工程做到体系化Agent 编排做到可观测评估体系做到半自动化之后才考虑微调或者训练专用小模型。大多数人卡在 Agent 编排这一层原因不是不会写 Agent而是没有把可观测性做起来。你无法看清每一步的状态就永远无法有效调优。先花大力气把日志、追踪、评估这三件事做好光这一步就能让你超过九成的团队。6.4 团队协作Prompt 也值得做代码评审AI 项目的团队协作和传统项目不太一样。除了代码评审Prompt 也必须进入评审流程。我们的做法是给 prompt 建版本管理每一条修改都关联到一次评估结果的变化而不是凭感觉“好像变好了”。AI 项目最怕的不是能力弱而是不知道谁在什么时候改了什么导致了效果变化。一个没有版本记录和评估数据的 prompt和定时炸弹没有区别。另外把评估集当成团队的公共资产任何人改 prompt、换模型、调参数都必须用同一套黄金用例回归。这个机制会逼迫每次变更都带上数据证据整个团队的工程质量会上升一个台阶。我在实际项目里发现坚持一个月后成员之间讨论问题的方式从“我觉得”变成了“数据说明”这种变化比任何技术选型都重要。我自己做 AI Engineering 最深的体会是这个领域最难的从来不是某个模型有多强而是你能不能把一堆不确定的东西变成可控的工程资产。每个环节都可以回归到四个字——定义清楚。输出协议定义清楚评估标准定义清楚退出条件定义清楚。只要你沿着最小闭环一步步跑起来哪怕第一步做得很丑也比停在原地强。如果让我只送一条建议给正在从零起步的人那就是先写 20 条测试用例再开始写代码。这句话帮我省掉的返工时间可能比这些年加班的时间还多。