06 质量闭环：TDD、调试、验证与审查¶

一、质量不是最后再加一层测试¶

Superpowers 把质量拆成四个互补的时间点：

TDD                 → 设计实现顺序，先证明行为不存在
systematic-debugging → 解释失败根因，而不是猜修复
code review          → 让另一个视角检查范围和质量
verification         → 在宣布完成前获取新鲜证据

它们解决的是不同问题：TDD 防止实现偏离行为，调试防止修复错因，review 防止单人盲点，verification 防止用旧输出或感觉冒充结果。

二、TDD 的铁律：没有先失败，就没有测试驱动¶

skills/test-driven-development/SKILL.md 把红—绿—重构写成不可跳过的顺序：

stateDiagram-v2
    [*] --> RED: 写一个描述行为的失败测试
    RED --> RED: 测试没有按预期失败，修正测试
    RED --> GREEN: 确认失败原因是缺少行为
    GREEN --> GREEN: 写最小实现
    GREEN --> REFACTOR: 全部测试通过
    REFACTOR --> RED: 清理后进入下一个行为

RED：失败要有意义¶

测试先写，运行后应因为“行为尚未实现”而失败。如果测试因为导入错误、语法错误或测试本身写错而失败，就不能进入 GREEN；必须先修正测试环境。

GREEN：最小实现¶

Green 阶段不是预先设计完整架构，而是写刚好让当前行为通过的最小代码。这样可以避免在没有测试保护时一次性引入大量未验证抽象。

REFACTOR：保持绿色再清理¶

重构阶段只能在测试通过后进行；每次改动后重新运行测试。这个顺序把重构风险限定在可观测的行为不变范围内。

三、好测试测试行为，不测试实现愿望¶

writing-good-tests.md 把测试质量落到几个问题：

测试名是否说明用户可观察行为？
是否只测试一个关键行为？
失败时能否快速定位原因？
是否使用真实依赖或最小可靠替身，而不是过度 mock？
是否包含边界和错误路径，而不仅是 happy path？

一个测试如果只能证明“某个私有函数被调用了”，却不能证明用户行为成立，就很难作为 Agent 的交付证据。

四、Systematic Debugging：先调查，后修复¶

skills/systematic-debugging/SKILL.md 的铁律是：没有根因就不修复。它把调试分为四阶段：

Phase 1：Root Cause Investigation¶

收集错误信息、复现步骤、堆栈、相关代码路径和环境差异。不要只看最后一行异常；要找到失败发生的第一处边界。

Phase 2：Pattern Analysis¶

对照工作正常的相似路径、最近变更和数据差异，寻找“哪里开始分叉”。这一步把问题从单个症状提升为模式。

Phase 3：Hypothesis and Testing¶

提出一个可证伪假设，然后设计最小实验。每次只改变一个变量；如果实验结果不支持假设，就更新假设，而不是强行改代码。

Phase 4：Implementation¶

确认根因后，用最小修复解决问题，并添加能防止回归的测试。最后按证据门验证全套行为。

symptom → evidence → pattern → hypothesis → experiment → root cause → fix → regression test

五、为什么 TDD 和调试不是一回事¶

两者都强调测试，但起点不同：

问题	正确入口	关键产物
新功能还没有实现	TDD	先失败的行为测试
已有行为异常	systematic-debugging	可复现的根因证据
修复已经完成	verification	新鲜的完整命令输出

把所有 bug 都强行写成 TDD，可能会跳过现有系统的因果调查；把新功能直接修成“先改到能跑”，又会失去行为驱动的设计约束。

六、Verification：完成声明的证据门¶

skills/verification-before-completion/SKILL.md 将完成声明写成 Gate Function：

Identify：什么命令能证明这句话？
Run：现在执行完整命令。
Read：读完整输出，检查退出码和失败数量。
Verify：输出是否真的支持结论？
Claim：只有确认后才对用户声称完成。

它特别警惕这些语言信号：should、probably、seems to，以及“代码改了所以应该好了”。源码把“相信 Agent 的报告”明确列为不充分证据。

七、Review 的双轴模型¶

requesting-code-review 和 receiving-code-review 共同构成协作审查：

request review → 收集具体反馈 → 判断反馈是否适用
                → 按优先级修复 → 重新验证 → 回复/记录

接收反馈时不能盲目同意，也不能先为自己辩护。应该逐条确认：

反馈指出的实际行为是什么？
是否能在代码或测试中复现？
它属于 spec 违约、代码质量、性能、风险还是 YAGNI？
需要新测试、修改实现还是拒绝范围外建议？

“看起来专业”的额外功能也要过 YAGNI 检查；review 不只是寻找更多代码可以添加，而是判断当前变更是否足够小且正确。

八、四种证据如何拼成闭环¶

设计批准       → 证明做对了问题
RED 测试       → 证明测试能捕捉缺失行为
GREEN 测试     → 证明实现满足行为
review 报告    → 证明有独立视角检查
fresh verify   → 证明当前工作区状态仍然成立

少一环都可能出现“局部正确、整体不可信”：

没有设计批准，可能实现了错误目标；
没有 RED，可能测试永远不会失败；
没有 review，可能遗漏跨任务问题；
没有 fresh verify，可能引用的是旧输出。

小结¶

质量闭环的核心不是增加更多流程，而是让每种判断都对应合适的证据。Superpowers 用 TDD 管实现顺序，用系统调试管因果，用 review 管独立视角，用 verification 管最终陈述，形成一条从意图到事实的证据链。