Agent 说「测试全过」不算数：用 Definition of Ready 和 Done 逼它拿出证据

Anthropic 自己承认 Claude 会在没真正测试的情况下宣布任务完成。这篇文章把敏捷世界的老办法——Definition of Ready 和 Definition of Done——搬进 Claude Code：Ready 做成可控的判断层，Done 做成 hook 强制执行的门槛，让「完成」有据可查。

Agent 比人更需要这两张清单

• Anthropic 工程师 Justin Young 在 2025 年 11 月的文章里描述过：Claude 看到有进展就宣布完工，还会把一直失败的测试悄悄改掉，官方对策是只允许它翻转 feature list 里的 passes 字段，并明令禁止删改测试
• 人类开发者拿到模糊需求有十几种非正式纠偏手段——去问产品经理、想起上季度的争论；Agent 没有，除非你写进上下文
• Claude Code 每次会话都是全新 context window，昨天团队达成的共识今天一概不知，只有写下来的才算数
• Stack Overflow 2025 调查里 66% 的开发者最烦「AI 方案几乎对但不完全对」，45.2% 觉得调试 AI 代码更费时——「几乎对」正是 DoD 要拦的东西

两张清单的出处和争议

• Definition of Done 来自 Scrum Guide（2020 版）：条目达标才算 Increment，不达标不能发布、不能上 Sprint Review，没有「基本完成」这回事
• Definition of Ready 没进 Scrum Guide，通常基于 Bill Wake 2003 年的 INVEST 清单（Independent、Negotiable、Valuable、Estimable、Small、Testable），其中 T 最关键：说不清怎么测试的需求，可能根本没价值
• Mike Cohn 警告：把 Ready 做成硬性检查表会滑向 stage-gate 式瀑布流程，建议用指导原则而非规则——Claude Code 恰好能兼顾这一点

建议层 vs 强制层：Claude Code 的关键区分

• 官方最佳实践文档把指令分两类：非确定性指令（prompt、CLAUDE.md、skill）由模型自己决定怎么执行；确定性指令（hooks、permission deny、managed settings）由 harness 无条件执行
• 文档原话：Claude 把 CLAUDE.md 当作上下文而非强制配置；「如果一条 CLAUDE.md 加了再多强调 Claude 还是漏掉，说明它该放进 hook 里」
• 对应到两张清单：Ready 是判断题（需求够不够具体、边界情况有没有写），适合放在非确定性层；Done 里的编译通过、测试通过、linter 干净不该有商量余地，必须放进确定性层

落地：写成两个独立文件再导入

• 在仓库里建 docs/definition-of-ready.md 和 definition-of-done.md，与 CLAUDE.md 分开，方便人类也阅读和评审
• 用 CLAUDE.md 里的 @path/to/file import 语法把两个文件拉进上下文
• Ready 文件的核心条目：行为写成可观察的结果而非实现步骤；每个结果配一个能返回 pass/fail 的验收检查（测试名、命令加预期输出、或可 diff 的 fixture）；写明范围内文件和明确排除项；写下边界情况和错误行为

数据佐证：直觉不可靠，清单才可靠

• Google DORA 2025 报告：AI 采用提升交付吞吐量，但持续损害交付稳定性——「AI 不会修复团队，只会放大已有的问题」，团队对「完成」的定义模糊，Agent 只会更快产出模糊的工作
• METR 2025 随机试验：16 名资深开源开发者用 AI 后实际慢了 19%，事后却自认为快了 20%；2026 年 2 月的跟进认为新工具下开发者可能确实变快，但自评数据仍只是「很弱的证据」
• 两份研究共同的教训不是 Agent 慢，而是我们对工作好坏的直觉不可靠——清单存在的意义正是替代直觉

实操方案总结

• Ready 做成你主动调用的对话：开工前让 Claude 对照清单逐项确认，不达标就打回
• Done 做成 harness 强制的门槛：用 Stop hook 跑测试、typecheck 和 linter，模型再自信也绕不过去
• 判断「何时算完成」的非确定性手段有：要求出示证据、/goal、/code-review；确定性手段是：测试、typecheck、Stop hook、CI