Superpowers 系列（六）：证据门禁
Agent 很容易产生“成功幻觉”：代码改了，所以应该好了；测试写了，所以应该覆盖了；子代理说完成，所以应该可信；局部命令通过，所以整体应该没问题。
Superpowers 用三类证据门禁压住这种幻觉：TDD 约束实现前证据，systematic-debugging 约束修复前证据，verification-before-completion 约束完成声明前证据。对应源码里，TDD Skill 用 Iron Law 固定红绿重构顺序，systematic-debugging 要求先调查根因，verification-before-completion 则把“完成”这类语言输出绑定到刚运行过的命令。
三个门禁控制不同阶段
这三个 Skill 经常被混在一起理解，但它们控制的不是同一件事。
| 门禁 | 控制时机 | 核心问题 |
|---|---|---|
| TDD | 写生产代码之前 | 这个测试是否真的能捕捉缺失行为 |
| systematic-debugging | 提出修复之前 | 你是否已经知道根因 |
| verification-before-completion | 声明完成之前 | 当前声明是否有新鲜证据支撑 |
TDD 不保证你找到了 bug 根因；它保证新行为先被失败测试描述。系统调试不保证最终完成；它保证修复前不是猜测。完成前验证不保证设计正确；它保证当前要说的话有刚运行过的证据。
这三个结论不能互相替代。
TDD 控制的是测试和实现的因果顺序
test-driven-development 的核心规则很硬：没有先失败的测试，就不能写生产代码。如果先写了生产代码，就删除后从测试开始。
这个规则的深层目的不是教条式测试优先，而是防止测试被实现污染。测试写在实现之后，Agent 会根据已经写出的结构补用例，容易验证实现细节，而不是验证期望行为。
TDD 强制一个可观察因果链：
期望行为 -> 失败测试 -> 最小实现 -> 通过测试 -> 重构保持绿色如果缺少“失败测试”这一环，后续所有绿色都不可靠。因为测试可能原本就不会失败。
系统调试控制的是修复前的认知边界
systematic-debugging 的核心规则是先找根因，再修复。它把调试拆成四阶段：根因调查、模式分析、假设和验证、实现修复。
这个设计针对的是 Agent 的另一个倾向：看到症状就生成修复方案。模型会很擅长提出“可能是 X”的解释，但“可能是”不是工程证据。
系统调试要求：
- 读完整错误和调用栈；
- 稳定复现；
- 检查近期变化；
- 在多组件边界加诊断；
- 寻找工作样例；
- 列出差异；
- 一次只验证一个假设；
- 三次修复失败后质疑架构，而不是继续堆补丁。
这里的“三次失败后质疑架构”很重要。它承认有些问题不是再加一个补丁能解决，而是当前结构已经无法解释变化。
完成前验证控制的是语言输出
verification-before-completion 控制的是 Agent 的声明权。
它要求在任何完成、修好、通过、可以提交、可以开 PR 的表达之前，先识别证明该声明的命令，运行完整命令，读取输出和退出码，再决定能不能说这句话。
这个 Skill 的价值在于，它不只约束行动，还约束语言。因为在协作系统里，“完成了”本身会成为下游输入。下游 Agent 或用户可能基于这句话继续推进。如果这句话没有证据，就会把不确定性传给后续流程。
证据链如何串起来
修一个 bug 的健康链路应该是：
这个链路把“我觉得修好了”拆成多个可检查状态：根因是否明确，复现是否存在，测试是否先失败，修复是否最小，验证是否新鲜。
证据门禁的边界
证据门禁不能替代设计判断，也不能替代用户对目标的确认。它只回答当前技术声明是否有证据支撑。
比如，测试通过只能证明被测试的行为在当前命令下通过；根因调查完成只能证明修复前的理解更可靠；完成前验证只能证明当前声明有新鲜命令支撑。这些证据都很重要，但它们不能自动证明产品目标正确。
Superpowers 的价值在于让 Agent 少跨层推断。它要求每一句“完成、修好、通过”都贴着对应证据，而不是靠自信扩写。
参考资料：
- test-driven-development/SKILL.md
- systematic-debugging/SKILL.md
- verification-before-completion/SKILL.md
系列导航：