第11章 让输出更稳定：模板、示例与验收标准

同一份工作说明，有时输出像会议纪要，有时却变成一篇长文章，通常不是 Agent “突然变笨”，而是我们只说了要做什么，没有说结果应该长什么样、哪些内容算合格。模板、示例和验收标准可以一起解决这个问题，但三者各自负责的事情不同。

模板规定栏目和顺序，示例帮助 Agent 理解每个栏目应该写到什么颗粒度，验收标准则让人判断结果能不能继续使用。它们都不能代替原始资料，也不能让人工检查消失。本章用一份虚构会议纪要展示正例、明确标注的教学用错误草稿、局部修正和复查结果。

三种工具，三种职责

先记住这个比喻：模板像表格的列，示例像一行填写好的样品，验收标准像交卷前的评分表。模板不能证明内容正确；示例不能成为事实来源；清单也不能自动修正所有错误。

工具	它约束什么	不能解决什么
模板	栏目、顺序、字段和格式	输入资料有没有说过这些事实
示例	句子长短、证据写法、颗粒度	示例里的姓名、日期和数字是否真实
验收标准	事实、结构、边界和交付条件	代替负责人做决定

如果输出只是“更长、更像文章”，不代表稳定性提高。真正的稳定，是每次都能找到固定栏目，缺少依据时有一致写法，修正后能说明改了什么。

先设计模板，再决定示例

主案例的模板如下：

# 会议筹备方案初稿

## 1. 目标
## 2. 现状
## 3. 行动
## 4. 风险
## 5. 待确认事项
## 6. 人工核对提示

六个栏目不是越多越好。它们分别回答“要做什么、现在知道什么、已经提出哪些动作、哪里可能出问题、还缺什么、交付前谁要核对”。如果你的任务不需要风险栏，可以删掉，但要说明删掉后由谁检查相关问题。

示例只演示颗粒度：

示例（虚构，仅用于说明写法）：
目标：在下次筹备会前确认活动主题方向。
行动：整理两种候选方向，交由项目负责人确认。
待确认事项：负责人姓名和确认日期未出现在资料中。

这里没有填入真实姓名、日期或预算。示例告诉 Agent “一句话写一个可核对动作”，却没有替会议纪要提供事实。把示例直接复制到真实结果里，是常见的误用。

主案例：模板 + 示例得到一份正例

使用《XX项目第三次筹备会议纪要》（虚构）：

已确定：活动主题方向为“数智未来·转型赋能”。
当前情况：主题方向已讨论，但嘉宾、场地和最终预算尚未确认。
讨论建议：整理两种主视觉方向，并准备活动流程草案。
已提出行动：整理主视觉初稿；确认候选场地；补充预算信息。
待确认：负责人、截止日期、嘉宾名单、场地和预算。

生成时先解释约束，再给 Prompt：

请根据我提供的虚构会议纪要，按下面六个栏目生成“会议筹备方案初稿”。
每条结论都要能在原文中找到依据；没有负责人、日期、预算数字或其他来源时，统一写“待确认”。
“讨论建议”不能改写成“已确定”，“行动”不能改写成已经完成。
最后列出人工核对提示，不发送、不发布。

模板：
{输出模板}

参考示例（只用于说明颗粒度，不是事实来源）：
{虚构示例}

会议纪要：
{会议纪要}

期望的正例应具备五个事实栏目，预算和负责人保留“待确认”，并在人工核对提示中提醒回到原文。即使结果看起来正确，也要逐项回读原文；模板只保证有位置，不保证填入的内容有证据。

截图中的正例只能说明这一次输入得到了可检查的结构。人工仍要把每个事实句子与会议纪要对照，尤其要检查“讨论建议”和“已提出行动”有没有被写成已经完成。

旧图实际展示了“没有附会议纪要时，Agent 要求补资料”的真实失败证据。它可以保留在排错段落，不能被当作正例结果。

明确标注的失败草稿：用于教学，不伪装成真实错误

为了练习局部修正，可以使用下面固定的教学材料。它必须在正文和截图中标明“教学用错误草稿，不代表真实事实”，不要求 Agent 先犯错，也不把它描述成 Agent 自己产生的错误：

【教学用错误草稿，不代表真实事实】
目标：完成项目筹备会议。
行动：张伟负责确认活动主题，活动将在下周五完成预算。
待确认事项：无。

这份草稿的问题是可定位的：虚构姓名和日期没有来源，“待确认事项：无”掩盖了会议纪要明确留下的空缺。教学材料的价值在于让你练习验收和修正，不在于证明模型会犯某种固定错误。

局部修正：只改需要改的地方

把整篇重写会让你无法知道问题是否真的解决。更安全的修正方式是限定栏目、句子数量和不应变化的部分：

这是一份明确标注的“教学用错误草稿”，不是事实，也不是 Agent 自己犯错。
请只修正“行动”和“待确认事项”：
1. 删除未经资料支持的姓名和日期，改为“负责人和日期待确认”。
2. 把“待确认事项：无”改为列出负责人、截止日期、嘉宾名单、场地和预算待确认。
目标栏目保持原意，其他未要求修改的文字不要改。
请在末尾列出本次实际修改的两处。

修正结果要检查三件事：是否真的只改了指定栏目；是否把教学错误恢复为待确认，而不是填入新的猜测；是否列出修改记录。如果 Agent 顺手重写标题或添加宣传语，先退回，不要直接保存。

验收标准：把“看起来不错”变成可检查

建议把清单分为四类，总数控制在 5–8 项：

- [ ] 结构：目标、现状、行动、风险、待确认事项和人工核对提示都存在
- [ ] 事实：每条重要结论都能回到会议纪要找到依据
- [ ] 状态：建议没有写成已确定，行动没有写成已完成
- [ ] 缺口：负责人、日期、预算和数字缺失时标为“待确认”
- [ ] 修正：未要求修改的栏目保持不变，并列出实际修改记录
- [ ] 边界：没有代替负责人决策，也没有发送、发布或共享

让 Agent 自检时，先说明清单的作用，再输入：

请不要重写正文，只按以下清单检查结果。
每一项标记“通过 / 不通过 / 待确认”，并引用对应原文或指出缺口。

结果：
{待检查结果}

验收清单：
{验收清单}

自检结果不是最终批准。它可以帮助你定位缺口，但事实、日期、负责人和是否发布仍要由人确认。若资料本身没有提供依据，正确结果是“待确认”，不是让 Agent 用常识补全。

三种组合如何逐步比较

你可以用同一份虚构资料做三次小实验。第一次只给模板，观察栏目是否齐全；第二次加入示例，观察句子是否更接近所需颗粒度；第三次加入验收清单，观察 Agent 是否能指出缺口。每次只增加一种东西，才知道改善来自哪里。如果第二次输出更好看却增加了没有来源的结论，说明示例表达方式太强，需要删掉或改成更中性的示例。

这个实验也帮助你决定是否需要技能。模板和清单已经能解决问题时，不必为了“看起来专业”再封装技能；只有当同一组合在不同的虚构输入上都能稳定工作，且你愿意维护它的版本，才把它交给第 12 章评估。

复查要看“没有改变什么”

局部修正的验收不只是看两句是否改对，还要看未要求修改的内容有没有被悄悄替换。可以在修正前给每个栏目加一个简短标记，复查时对照栏目顺序、条目数量和原文引用。若 Agent 把整篇重新组织，即使新版本读起来更顺，也不能算局部修正通过，因为你无法确认其他事实是否被改动。

迁移案例：内容发布准备

把模板迁移到一篇虚构的内容发布准备稿，栏目可以变为标题、正文、事实依据、待核实项和版权检查。示例只展示一条“事实后附来源”的写法；验收标准则检查是否存在夸大承诺、未核实数字和未经授权的图片。输出可以很完整，但只有事实和版权都人工复核后，才进入发布决策。

失败排错：模板完整，却没有输入

现象：Agent 输出了六个标题，却说“请提供会议纪要”；或者它照着示例写出完整方案，却没有引用原文。

先检查：文件是否真的附加、变量是否替换、示例是否被误当成资料、当前对话是否引用了旧文件。

修正或停止：先让 Agent 回显输入名称和范围；缺少资料就停止生成，不用更多 Prompt 掩盖问题。若已有错误草稿，保留原版，另起一次局部修正并记录差异。

恢复标准：结果中的每个栏目都有输入依据或待确认标记，Agent 能明确说出缺少哪份资料；局部修正没有影响未指定的栏目。

若恢复后仍有缺口，把“通过”改为“待确认”，并把具体缺口交给人处理。验收标准的价值就在于允许暂停；它不是一张逼着所有项目打勾的表。

复查记录要留下依据

验收时不要只在清单后面打勾。每一项最好附一小段依据，例如“行动第 1 条对应会议纪要中的‘整理主视觉初稿’”，或写明“原文没有负责人，因此标记待确认”。这样下次修改模板时，能分清是模板缺栏、资料缺信息，还是 Agent 误读了状态。

如果复查发现三项以上不通过，先不要把结果交给下一步。回到输入范围和模板定义，找出共同原因后再局部修正。把一个不合格结果继续封装成技能，会让错误规则更难清理。

给不同任务选择不同模板

模板不是越通用越好。会议纪要需要“已确定/建议/待确认”的状态，商品资料需要“已知字段/缺失字段/来源”，内容发布准备则需要“事实/来源/版权”。如果把三类任务强行塞进同一模板，Agent 会为了填满栏目而制造无关内容。迁移到新任务时，先保留模板的设计原则，再重新命名栏目和验收标准。

这也是模板与工作说明的分工：工作说明可以保持“无依据就待确认”这样的通用边界，模板则随任务改变。第 12 章只有在模板和边界已经稳定时，才值得把它们一起封装。

模板设计也要照顾阅读者：栏目标题用普通语言，说明一条结果来自哪里，必要时给出一条“待确认”的示例。读者能沿着模板回到原文，才算真正降低了核对成本。

本章产物与验收

本章产物包括一份带虚构示例的输出模板、一份 5–8 项验收清单、一个标注清楚的教学用错误草稿，以及一次局部修正和复查记录。人工验收时重点问：模板是否真的需要这些栏目，示例是否泄露或虚构事实，失败句子是否可定位，复查后未修改部分是否保持原样。

本章小结与下一步

稳定输出不是让 Agent 写得更长，而是同时写清“结构、颗粒度和合格条件”。下一章再把已经测试过的低风险流程放到合适的复用层级，决定继续用固定 Prompt、Agent 说明，还是制作技能/任务方案。

阅读第 12 章：把成功经验整理成可复用技能。