对应 agent-orchestration 第 2.1 / 2.2 节（1.2 角色拆分见附录） · 形态：一页表单，可复制
用途：把「口头交代」变成一份可验收的委托。缺任何一格都会出事，不是「最好写上」。
一、卡片本体（复制填写）
【目标】
要完成什么，做完用来干什么（一句话，不超过 30 字）
【输入】
文件 / 数据在哪：
格式与关键字段：
参考材料（只看这些，不要自己找）：
【产出】
交给谁：
什么形式（文件 / 表格 / 文本）：
必须包含的字段或章节：
【验收】
①
②
③
【禁止项】
不要动：
不要自己决定：
不许出现：
二、每一格缺了会怎样
| 字段 | 缺了的后果 | 典型表现 |
|---|
| 目标 | 它自己定目标 | 做出来「挺完整」，但你要的不是这个 |
| 输入 | 它到处找文件 | 读错版本、把上个月的当这个月 |
| 产出 | 下游没法直接用 | 格式不对，你还要手工整理一遍 |
| 验收 | 你得逐字看 | 每份产出都要人通读，省下的时间又还回去 |
| 禁止项 | 它「顺手优化」 | 改了你辛苦调好的配置、动了不该动的文件 |
最容易被跳过的是「禁止项」，也是造成损失最大的一格。写它只需要三十秒，不写可能赔上半天。
三、验收标准：怎么写才可测
唯一的检验方法：换个人来判，结论一样。
可测三要素
| 要素 | 写法 | 例 |
|---|
| 数量或结构 | 写清条数、章节数、列数 | 「必须 5 个部分，每部分 3–5 段」 |
| 必须存在的字段或行为 | 点名要有的东西 | 「每段开头有一句结论句」「新增函数有入参校验」 |
| 不允许出现的东西 | 点名不要有的东西 | 「不出现『综上所述』『在当今时代』」「不出现未标注来源的数字」 |
改写示例
| 不可测 | 可测 |
|---|
| 「代码质量好」 | ① 新增函数有入参校验；② 错误分支有可读提示；③ 原有 3 个用例仍通过 |
| 「文案自然一点」 | ① 每段不超过 4 行；② 不出现 3 个以上并列形容词；③ 首段有一句具体事例 |
| 「整理得清楚一点」 | ① 按客户名升序；② 金额两位小数；③ 无空行、无合并单元格 |
三个反例（不要这么写）
- 「符合规范」——哪个规范？谁判？
- 「尽量准确」——「尽量」不是标准，是免责声明。
- 「参考行业惯例」——惯例本身有分歧，等于没写。
四、粒度：一张卡 = 一份可独立验收的产出
| 切法 | 现象 | 后果 |
|---|
| 太粗 | 一张卡要做四个页面 | 中途丢失约束，后期产出质量下降 |
| 太细 | 一张卡只改一行 | 协调成本吃掉收益（三次交接 ≈ 四十分钟） |
| 合适 | 一张卡对应一份能独立验收的产出，且能在一轮内完成 | —— |
切错位置的典型信号：一份产出需要三张卡才凑得出来。这说明你按动作切了，应该按产出切。
五、完整示例（内容整理角色）
【目标】
把 12 份客户对账单合并成一张汇总表，供月底对账使用。
【输入】
文件在 D:\work\in\2026-10\，共 12 个 xlsx，一文件一客户；
每个文件首行是表头：A 客户名、C 账期（2026-10）、E 金额（元）；
参考材料：只需上月汇总表 all-2026-09.xlsx，用于核对客户名单。
【产出】
交给：会计岗；
形式：xlsx，文件名 all-2026-10.xlsx；
必须包含字段：客户名 / 账期 / 金额 / 来源文件。
【验收】
① 行数 = 12 个文件的数据行之和（报告里要给出这个数）；
② 金额列为数值型，两位小数，无千分位；
③ 客户名与上月表完全一致，多出或缺失的客户单列一行说明。
【禁止项】
不要改动 in\ 目录下任何文件；
不要自行判断客户名写法是否相同（如「XX 公司」与「XX 有限公司」），有疑问列出来问我；
不许出现空行、合并单元格、隐藏列。
六、常见误用
| 误用 | 后果 |
|---|
| 五格齐全但验收全是形容词 | 等于没有验收，仍要通读 |
| 「禁止项」留空 | 它按自己的偏好「优化」，你要花时间改回来 |
| 输入写「相关资料」 | 它去找了不该找的文件，或漏了该看的 |
| 一张卡塞三个产出 | 中途丢约束，且无法判断哪部分没过 |
| 目标写成动作（「整理一下」） | 目标应当是结果 + 用途 |
附录 A｜角色拆分判据卡（第 1.2 节）
拆角色之前先确认：你真的遇到瓶颈了吗。三个信号命中任何一个才考虑拆。
| 信号 | 表现 |
|---|
| 需要回头重复交代 | 同一份约束要说三遍，说到后面它已经不遵守了 |
| 产出里的约束越来越少 | 开头还守格式，越往后越随意 |
| 不同阶段的判断互相干扰 | 实现和评审的标准搅在一起，互相迁就 |
两个判据（必须同时满足）
| 判据 | 怎么验 |
|---|
| 判断标准不同 | 两个角色的「通过 / 不通过」依据不一样 |
| 产出能被独立验收 | 各自有明确的交付物，可分别判过不过 |
三种拆法对照
| 拆法 | 例 | 结论 |
|---|
| 按工具拆 | 一个负责写、一个负责查 | 错：查的人没有独立标准，会跟着写的思路走 |
| 按阶段名拆 | 需求角色 / 设计角色 / 开发角色 | 表面合理，实际标准重叠 |
| 按职责拆 | 实现（管功能正确）/ 评审（管边界与回归） | 对 |
每个角色必须写「不负责什么」
| 角色 | 负责 | 不负责 |
|---|
| 实现 | 按任务卡产出可用结果 | 不负责判断需求是否合理、不改配置、不做上线决定 |
| 评审 | 按验收标准判过不过 | 不负责改代码、不提「更好写法」以外的重构建议 |
| 整理 | 把材料摆齐、摘要点 | 不负责下结论、不做取舍 |
为什么「不负责」比「负责」更重要：不写，它会热心地去补别人的活，结果两边都做一半，还互相覆盖。
1.1 单 Agent 的三个瓶颈（约 22 分钟）
要解决：先确认自己真的遇到了瓶颈，而不是「想试试多 Agent」。
演示步骤
- 用同一个长任务跑一次单 Agent，现场展示三种失效：中途丢失约束、阶段判断混淆、上下文被挤掉。
- 逐个定位原因（不是模型不行，是一个上下文承担了太多判断标准）。
- 给出三个自测信号：需要回头重复交代、产出里的约束越来越少、不同阶段的判断互相干扰。
- 反例：一个十几分钟的小任务也拆三个角色，展示协调成本超过收益。
口播稿
先说结论：多数任务不需要多个角色。你只有在遇到这三种情况时才考虑拆：要反复回头交代同一件事、产出里的约束越来越淡、实现和评审的判断标准搅在一起。最后一个反例很重要——我见过把一个十分钟的任务拆成三个角色的，光对齐格式就花了四十分钟。
演示素材（可直接照抄）
三个自测信号的判定表（每个信号给一条「算命中」的客观标准）：
| 信号 | 客观判据 | 记录方法 |
|---|
| 反复回头交代 | 同一件事在第 3 次产出时还要再交代一遍 | 每次交代记一行，数次数 |
| 约束逐渐淡忘 | 第 1 版守了 8 条约束，第 4 版只剩 4 条 | 逐版对照约束清单打勾 |
| 判断互相干扰 | 「实现质量」和「是否验收通过」两套标准在同一轮里打架 | 看反馈里是否混着两类话 |
反例算一笔账（真实演示里出现过）：一个 10 分钟的小任务拆 3 个角色，仅格式对齐就耗 40 分钟，总耗时 50 分钟，是单角色的 5 倍。
结论模板（贴在任务单上）：先跑单角色跑两轮，出现任一信号命中 ≥2 次，才启动拆分评估。
常见偏差
- 把「觉得慢」当成瓶颈信号。慢不等于该拆角色，先看是不是任务太大或约束没写清——这两个原因拆角色解决不了。
- 信号只凭感觉说「好像有」。三个信号都要有次数或对照记录，评估拆分时拿数字说话。
学员自查：能说出自己任务命中了哪个瓶颈，或者确认「不需要拆」。