写这篇笔记的时候距离我第一次给智能体写提示词其实还不到一个月。标题里的“唤醒实战笔记”是我们团队内部的叫法“唤醒”是一个多智能体协同中枢的代号负责把用户请求分流给不同的子智能体去执行。我负责的就是唤醒中枢的提示词。从 v1 到 v8八次迭代中间踩过不少坑推倒重来过两次最后总算把一个三行的“小作文”迭代成了一个模块化、可回滚、能跑回归测试的工程文件。这篇笔记就是把这八次迭代的思路、实测数据和教训原原本本记录下来给同样在做智能体提示词迭代的人当一份参考。先说一下这个“唤醒”是什么场景。我们做的产品里用户会发出各种指令比如查数据、设提醒、生成内容、调用知识库它们分别对应不同的执行模块。唤醒中枢要做的事情就是在入口处判断用户真正想要什么然后按顺序把任务派发出去并汇总结果。这个角色很像前台接待员不负责具体干活但所有活都要经它调度。问题在于这个接待员是一个大语言模型你稍不注意它就会开始“自由发挥”。提示词迭代就是在和这种“自由发挥”做斗争。接下来按 v1 到 v8 的顺序讲讲每条提示词版本是怎么死的又是怎么活过来的。1. v1 → v2先补三块基础短板1.1 第一版提示词和第一个翻车现场v1 其实只写了一个角色加一句任务描述当时我还觉得挺清楚。你是一个智能体负责处理用户的唤醒请求。 当用户输入信息时用自然语言回复。 不要啰嗦。结果第一次内测就翻车了而且是那种非常经典的翻车。测试用户输入“帮我调出昨天的销售数据再给今天上午十点设个提醒。”唤醒中枢回复“好的我已理解您的需求马上为您处理。”然后……就没有然后了。这个问题特别典型。模型把“理解需求”当成了“完成任务”它觉得只要回复一句“我明白了”就算干完活了。不调用工具、不回执、不拆解就干巴巴地告诉你它懂了。我当时第一反应是模型能力不行等冷静下来重新审了一遍提示词才发现问题根本出在我自己身上我压根没说清楚什么叫“处理”处理完要产出什么中间需要调用哪些工具失败的边界在哪里。v1 翻车给我最大的教训是提示词工程的第一原则不是让模型“更聪明”而是把自由度降到最低。你以为你在写一份说明书实际上你在写一套带边界的约束系统。凡是没说死的部分模型就会用它自己的方式替你补齐而它的补齐方式往往不是你想要的。1.2 角色卡加三条硬约束v2 的时候我做了两件事加角色卡加输出约束。角色卡解决的是“你是谁”的问题输出约束解决的则是“你说话长什么样”的问题。【角色】你是唤醒中枢的调度智能体负责将用户请求拆解为可执行子任务。 【职责】 1. 识别用户请求中的具体意图。 2. 当需要外部数据或工具时通过工具调用接口执行。 3. 全部任务处理完毕后输出完整回执。 【输出要求】 - 回复以“收到”开头。 - 必须包含三部分已执行动作、执行结果、下一步建议。这一版开始有点样子了。回复有了固定的起始标识结构也稳定下来模型知道不能只回一句“我明白了”它会主动调用工具也学会把结果汇总成回执。我把 50 条测试用例跑了一遍回复完整率从 v1 的大约 35% 提到了 62%工具调用率从 4% 提到了 45%进步是肉眼可见的。但新问题马上又冒出来多意图请求处理到一半就断片比如用户同时要查数据和设提醒它往往只执行第一个任务就结束工具调用失败时没有任何降级逻辑模型会卡在一个报错信息里反复绕圈。这些都不是加一句“你要完整处理”就能解决的需要在提示词里明确给出“对一个请求分几步走”的结构。v2 只能算打好了地基真正的结构改造是从 v3 开始的。1.3 版本迭代从什么时候开始不算冤枉如果你问我提示词从第几个版本开始才算正式进入迭代状态我的答案并不是 v2 或者 v3而是从我开始认真记录变更记录、保存每一个版本并且为每一个版本设计独立测试用例的时候。这听起来像工程规范不像提示词技巧但它的作用比任何一句“你要表现稳定”都大。因为提示词迭代有个很讨厌的特性改动一行字表面上没变化实际行为可能发生漂移改动十行字效果反而变差但你根本不知道是哪一行拖的后腿。没有版本锁和对照测试你会陷入“凭感觉改提示词”的泥潭——这版我加一句话结果变差了再删另一句话结果更差了最后干脆全部重来。我的做法是从 v2 开始给每个版本建一个测试集固定 50 条覆盖常见场景的输入每次改完都跑一遍。高分的版本才能继续迭代低分的版本要么回滚要么带着测试数据找到问题再动手。可以说如果没有这套流程后面 v4 到 v8 的改进根本无从谈起。2. v3 → v4从“会聊天”到“会执行”2.1 思维链让智能体学会提前思考v3 的核心改动是把“思考步骤”写进了提示词。当时我读了很多提示词工程材料看到思维链方法介绍得神乎其神就想着给唤醒中枢也加上一套拆解步骤。【思考步骤】 当你收到用户请求时先按以下流程思考 1. 找出用户请求中包含的所有意图。 2. 将每个意图对应到具体的工具或数据模块。 3. 确定执行顺序优先级高的先执行。 4. 执行完毕后汇总结果并生成回执。加了思考步骤之后唤醒中枢确实会“想”了。测试集里出现了多意图请求处理成功的情况比如“查昨天的销售额再提醒我下午三点开周会”这种复合指令它能拆成两条任务然后按顺序执行。这是 v3 的最大收获智能体开始具备结构化处理复杂请求的能力而不是一味地“接单”。但它立刻暴露了一个让我血压升高的新毛病过度思考。模型会把每一步都想得非常详细甚至把“我建议先查数据再根据结果决定是否设置提醒”这种根本不应该出现的半成品计划也输出出来。明明一次能执行完的操作它要思考三个来回才动手明明是确定性的工具调用它非要输出一大段“我认为”“我建议”。平均响应时间从 v2 的 2.1 秒直接飙到 4.5 秒翻了一倍还多。后来我意识到思维链理应是“内部推理过程”不是“对外输出内容”。v3 的问题不在思考步骤本身而是我没区分“想”和“说”。这个发现直接催生了 v4 的结构化输出改造。2.2 结构化输出才是“执行”的开始v4 是八次迭代里最像分水岭的一版。我做的关键决定是把唤醒中枢的输出格式从自然语言改成了严格 JSON并且把“思考”和“输出”切成两段思考过程不允许出现在回复里回复内容必须走 JSON 结构。{ context_id: 20260929_001, actions: [ { tool: data_query, params: { target: sales, date: 2026-09-28 } }, { tool: reminder, params: { time: 2026-09-29 10:00, note: 晨会 } } ], status: completed }我给唤醒中枢规定了 actions 数组每个动作必须包含 tool 和 params最后用 status 表明整批任务是否完成。这个改动看起来只是更换了输出格式实际效果却非常明显第一模型不能再用“我明白了”这种空话来糊弄因为它必须产出结构化的动作第二下游的调度程序可以直接解析 JSON 去执行不再需要一遍遍解析自然语言第三“过度思考”没了出口因为提示词里写死了“只输出 JSON不输出解析过程”。这套方案的逻辑在于让文本模型去生成可执行的结构而不是让文本模型去写一篇作文。对唤醒中枢这种调度型智能体来说JSON 就像一张工单把每一步要做什么、用什么工具、参数是什么全部写清楚。自然语言可以是产品跟用户交流的界面但绝不应该是系统内部传递指令的格式。2.3 工具失败必须给降级路径v4 还有一个来自实战的改动很多人容易忽略给工具调用失败预设降级路径。之前唤醒中枢遇到数据查询接口报错会在 JSON 里回一个状态码为 failed 的信息然后就结束了。问题在于用户那边根本不知道发生了什么也不知道接下来该怎么办。我在 v4 的提示词里加了一条规则当某个动作执行失败必须尝试一次替代方案替代方案也失败时在回执中明确标注失败原因并给出用户可以继续操作的建议。比如数据服务不可用就建议用户稍后重试或者在提示词里预设第二数据源。这条规则看似简单却把唤醒中枢从一个“汇报完就消失”的执行机变成了一个有点责任心的工作流节点。没有它整个调度链路在异常场景下是断的。v4 版本是我第一次敢把唤醒中枢放到评测环境里跑 24 小时的版本。工具调用成功率从 v2 的 45% 提升到了 78%平均响应时间回落到 2.4 秒而且 50 条用例里的多意图请求基本都能完整走完“识别-拆解-执行-回执”四步。但我心里清楚结构问题解决了内容质量问题还悬着比如模型偶尔会自作主张填错日期或者把它没有执行过的操作写成已执行。3. v5 → v6少样本和自检两张治幻觉的处方3.1 示例放哪里效果差很多v5 做的事情很纯粹在提示词里加入 few-shot 示例让唤醒中枢照着样例输出。第一次做的时候我把示例放在了提示词最前面结果效果很差模型好像被示例“带偏”了输出风格僵硬甚至出现了机械模仿示例关键词的毛病。后来我调整了顺序把角色定义和基础规则放在前面把示例放在行为规则之后、禁止事项之前并且把示例从“三个完全相同模式的正例”改成“两个正例一个反例”。【正例1】 用户调出昨天的销售数据 中枢{actions:[{tool:data_query,params:{date:2026-09-28}}],status:completed} 【正例2】 用户明天早上九点提醒我开项目会 中枢{actions:[{tool:reminder,params:{time:2026-09-30 09:00,note:项目会}}],status:completed} 【反例】 用户帮我随便看看 中枢错误做法仅回复“好的收到”未输出任何结构化动作。位置改变之后效果确实不一样了。我理解的原因是大语言模型对提示词内容有一个“就近响应”的倾向示例放在离输出要求越近的地方它越容易把示例格式当作参考答案。放到最前面相当于在开场就立了一个格式模板模型会误以为整段任务就是不停模仿示例放到规则之后、禁令之前示例才真正承担起“补充规则”的角色它是在给前面的抽象规则打样。v5 的实测数据是输出格式正确率从 v4 的 88% 提到了 96%因为格式错误导致的解析失败少了很多。但少样本并没有解决内容准确性问题。唤醒中枢依然会在某些信息不明确的时候凭自己的理解补齐数据还装成是用户说的。3.2 反例比规则更容易被模型记住v5 让我注意到一个现象写“不要做什么”比我写“你应该做什么”更管用。第一次系统性使用反例约束是我发现在少数场景里模型会输出“收到已处理”这种空回执即便 v4 的提示词里已经明确写了“必须输出 JSON”。我发现我写的规则是“承接式的”强调了正确路径却没有告诉模型错误路径有多错。于是 v5 后半段我专门加了一个“禁止事项”区域。比如【禁止事项】 - 禁止在未调用任何工具的情况下声称已经完成用户请求。 - 禁止输出思考过程和推理过程。 - 禁止使用“好的”“收到”“已了解”等纯问候式回复作为最终回执。 - 禁止在用户未指定时间时自行猜测日期和小时。 - 禁止在工具调用失败后直接结束对话必须给出替代方案。这五条禁令里第二条和第四条效果最明显。第二条杜绝了过度思考残留的啰嗦输出第四条直接把瞎猜日期的幻觉率压下去了一大截。尽管我没做过严谨的消融实验但从失败样本统计来看v5 中 70% 以上“自作主张填参数”的错误都集中在没有禁令约束的那几个参数上。这让我意识到对大模型来说给一个“反对样例”比给十个“正面要求”更容易建立边界。3.3 完成前自检我实测的减瑕效果v6 是建立在 v5 基础上的一个质量兜底机制。我给唤醒中枢加了一段“完成前自检清单”要求在输出最终回执前先拿清单做一遍检查能过才输出不能过就重新生成。【完成前自检】 1. 本次请求涉及的所有子任务是否都已尝试执行 2. 输出的 actions 是否为有效 JSON 结构 3. 所有时间、日期、名称是否都来自用户输入或查询结果而非猜测 4. 是否存在工具调用失败未补充替代方案的情况 5. 回执中是否包含 status 字段且状态与实际执行结果一致有读者可能觉得让模型自己检查自己不是掩耳盗铃么。实际操作下来不完全是这样。自检清单的本质不是让模型第二遍“思考”而是把最终输出往前推送到一个更严格的校验位置。我做了个简单的对照测试拿 v5 和 v6 各跑同一组 100 条用例统计“出现幻觉参数”的条数。v5 有 13 条出现幻觉v6 是 6 条降低了一半以上。其中第 3 条关于“数据来源必须来自用户输入或查询结果”的检查对压住幻觉帮助最大。当然自检机制不可能百分百消除幻觉它更像一道保险丝把明显不合理的输出在前置阶段就拦住。如果模型压根分不清信息是真还是假它也照样能把假的写进自检结果。所以 v6 的定位不是终极方案而是给 v7、v8 的继续迭代打底。4. v7 → v8压缩、模块化、版本化4.1 提示词变胖之后延迟和成本立刻翻脸到了 v6 末尾提示词已经从最初的 3 行膨胀到差不多 1000 个字符。角色卡、思考步骤、JSON 格式、示例、禁止事项、自检清单越加越多效果确实有提升但我明显觉察到输入 token 和生成 token 都不对劲了。我之前优化协同模块有个习惯每隔一段时间就统计一次接口延迟和成本这次统计出来的数字让我倒吸一口气。我拉了一张内部记录表把几个关键版本的指标放在一起看版本提示词长度字符平均响应时间单次调用成本相对v1格式正确率v1800.8秒1.035%v22601.2秒1.158%v44602.4秒1.488%v610103.1秒1.993%这里有两个数字必须盯着看响应时间和单次成本。v6 相对 v1成本几乎翻了一倍响应时间从不足 1 秒涨到 3.1 秒。对于单用户交互来说3 秒勉强能忍如果同时有几十个请求进来服务的吞吐量会明显下降。这个教训很直接提示词不是免费的每一段冗余文字都在用真金白银和时间买单。4.2 用表格和分隔符给提示词瘦身v7 的目标很明确在保效果的前提下压缩体积。我用了一个方法效果出奇地好把大段描述性文字改写成紧凑的表格式规则。比如多意图处理我原来写了一整段“当用户请求包含多个意图时你必须先把所有意图都识别出来按优先级依次执行……”几百个字改成表格之后是这种画风多意图处理规则 | 步骤 | 动作 | 说明 | | --- | --- | --- | | 1 | 识别 | 列出请求中所有意图 | | 2 | 排序 | 按优先级排列用户明确指定顺序优先 | | 3 | 执行 | 逐个调用对应工具 | | 4 | 回执 | 输出完整 actions 与 status |同样一条规则表格结构带来的输入 token 减少了一半。更关键的是表格让模型更容易把规则当作一条严谨规范来对待而不是一段可以随意稀释的自然语言。v7 还统一了分隔符。之前整个提示词里用了各式各样的横线、星号、括号模型偶尔会搞混“规则边界”和“示例内容”的区别。我把提示词统一成五个区块每个区块用标准分隔符隔开区块之间不允许交叉引用这一项改动虽然肉眼几乎看不出差别但测试集上的输出稳定性又提了一截。压缩之后 v7 达到 720 个字符响应时间回到 2.0 秒附近成本相对 v6 降了大约三成各项准确率指标基本没掉。这时我彻底确认了一个观点提示词不是越详细越好而是信息密度越高越好。4.3 模块化拆分换来的是可控性v8 是我在这篇笔记里最终保留的版本。它做的事情不是继续堆规则而是把原本一整块的提示词拆成了五个互相独立的模块系统设定、任务定义、技能方法、示例库、自检定检。[1 系统设定] 你是唤醒中枢调度智能体所有输出必须为结构化 JSON。 [2 任务定义] 负责意图识别、任务拆解、工具调度、结果汇总。 [3 技能方法] 多意图处理、工具降级、参数校验。 [4 示例库] 正例2条、反例1条。格式严格对齐 JSON。 [5 自检定检] 完成前逐条检查任一检查不通过则重新生成。这么拆的好处不是只为了短而是让每个模块可以独立修改、独立测试。举个例子这周如果业务方要求多支持一种“预约型”任务我只需要改技能方法和示例库两个模块系统设定和自检清单完全不用动如果发现知识库调用的降级逻辑写得不好我只要精修技能方法区块不需要担心影响任务定义部分。模块化还有一个隐性收益就是对版本管理变得更加友好。我现在把每个模块放在独立的 Markdown 片段里每次变更都记录到代码仓库版本号跟着提示词整体走。线上跑的是 v8试验中的新方案叫 v8.1等 v8.1 在测试集上超过 v8再把线上版本迁过去整个流程变成了一套可靠的小型发布流程。5. 迭代过程中最常踩的 6 个坑5.1 故障速查表八次迭代下来我遇到过的典型问题其实可以整理成一张表。如果你在调试智能体提示词时出现类似症状可以直接对照排查。现象可能原因处理方法回复空泛不调用工具提示词缺少输出物和执行路径定义增加结构化输出和工具调用要求多意图请求只执行一个缺少任务拆解步骤引入子任务拆解流程强制识别所有意图输出啰嗦、延迟变高思维过程混入输出内容提示词中明确禁止输出思考过程工具失败后直接结束对话缺少降级路径增加失败替代方案和人工回退建议时间、日期等参数被模型瞎猜输入信息不明确且缺少约束通过反例禁令明确禁止猜测参数提示词越长效果反而变差信息密度下降、相互干扰压缩规则、表格化、模块化拆分有一点我要特别提醒同样一个现象在两个不同模型上出现时排查路径可能完全不同。比如我之前遇到精简后的提示词反而导致工具调用率下降换到另一个模型后同样的提示词表现又恢复正常。所以上面这张表更多是给思路不是给标准答案。真正可靠的方式是每个版本都留测试集数据用数字而不是感觉来判断问题出在哪。5.2 三个值得内化的提示词原则抛开具体技巧我复盘 v1 到 v8最后沉淀下来的是三条非常朴素但好用的原则。第一条是“先给约束再给自由”。角色、格式、边界这些一定要定死模型才能在定死的范围内做正确的事。反过来如果你先把自由度给了它再想通过后期指令收紧往往会发现已经收不住了。第二条是“每条规则都要能映射到错误样本”。我后来给自己定了一条规矩没有对应失败案例的规则不加进提示词。因为每加一条规则都会消耗 token都会让提示词更复杂如果它没有解决一个已经被验证过的实际问题那就是纯浪费。v6 阶段我就删掉过几条听起来很合理但从未运用于实际问题的规则删完之后指标反而更干净。第三条是“提示词迭代和代码迭代没有任何区别”。必须用版本管理、测试集、对比评测。很多人把提示词当作文案改一句就上线上线出问题又回滚消耗大量时间。我建议你把提示词当成代码一样对待从 v1 开始建仓库把所有版本、测试集、评测结果都挂进去。这样每一次改动都会变成可追溯的资产而不是一段谁也说不清的“感觉”。5.3 给同样在迭代提示词的人三条建议如果你也在做一个智能体项目的提示词迭代我的建议很直接。第一先搭评测再改提示词不要上来就讲究文采。哪怕只是 20 条固定用例也好先把“好”和“不好”定义清楚否则你根本不知道该往哪个方向改。我见过太多人改了一星期连自己改出来的版本到底有没有变好都说不清楚这种迭代等于在原地打转。第二改动尽量小步快跑每次只动一个变量。v3 → v4 那次之所以能顺利推倒重来是因为我把工作分成了三小步结构改造、失败降级、自检机制每一步都单独验证过。如果一次憋一个大版本把所有改动都塞进去一旦效果变差你连问题出在哪都定位不了。第三给你的智能体留一条“人工接管”的口子。提示词再完善也不可能覆盖所有场景。我在 v8 里专门保留了一个转移指令当自检无法通过或者置信度偏低时唤醒中枢会把请求转移给人工作同时把上下文和失败原因一起带过去。这在生产环境里不是妥协是最基本的风控意识。6. 复盘一条适用性极强的提示词迭代路径6.1 为什么按版本号而不是重写这次项目里我最高频的一个习惯是不提“重写提示词”只提“升到下一个版本”。这两个说法看似差不多心里预期完全不同。“重写”意味着可以推翻一切从头再来很容易放弃那些经历过实战验证的细节“升版本”则带着存续性每代保留有价值的产出砍掉无效的部分像物种进化一样往前走。我后来意识到这是提示词工程最被低估的一点它不是靠灵感和妙手偶得而是靠一条清晰的继承关系。v8 之所以稳定是因为它继承了 v2 的角色卡、v4 的结构化输出、v5 的少样本位置规律和 v6 的自检清单。任何一次看起来卓有成效的“重写”背后一定有履历可查的迭代痕迹。不要迷信重写要相信版本。6.2 这一版之后还打算做的事v8 之后我手里还有几个没做完、但方向已经明确的事情。第一是引入更多评测模型来做交叉验证。目前测试集是人工标注的稳定可靠但覆盖面还不够广下一步打算把不同模型对同一输入的输出也纳入对比看看哪些规则是跨模型通用的哪些只是某一个模型特有偏好。第二是动态提示词根据任务复杂度切换详细版和简版提示词像一个人对不同场景切换沟通颗粒度。这个方向我觉得潜力很大比现在单版本走天下要更符合生产实际。我不打算把这些都堆到 v9 里一次性实现还是会延续小步快跑的方式一项一项验证。毕竟跟智能体打交道的经验告诉我变化越小越容易找到原因步子越大越容易把锅甩给玄学。6.3 写在最后的一点真实体会如果你看到这里准备去改自己的智能体提示词我只强调一句先保存好你的 v1哪怕它再蠢。因为我回头看的时候最有价值的不是漂亮的 v8而是那个充满破绽的 v1。它让我知道所有改进都是由什么驱动的哪些判断是后来验证过的哪些是中途差点走偏又拉回来的。每一个失败样本都像一块路标把后续版本的路径照得清清楚楚。提示词迭代没有终点因为模型在变场景在变用户在变。v8 也不是标准答案它只是接下来继续迭代的一个稳定起点。下次再出问题的时候我会翻出这篇笔记看看当时的判断和测试数据——然后新建一个 v9。