第九章：铁律与反模式
铁律是管理每次 Superpowers 启用 agent 会话的不可谈判规则。它们不是指南、默认值或建议。它们是无法被指令、紧迫性或便利性所覆盖的硬性约束。
理解这些铁律存在的原因——以及违反它们时会发生什么——对于有效使用 Superpowers 至关重要。
四条铁律
铁律一：TDD
"没有先有失败测试，就不得编写任何生产代码"
每个功能、每个 bug 修复、每个行为变更都必须先有一个描述预期行为的失败测试。这是严格应用的测试驱动开发（TDD）。
为什么不可谈判：
没有先有失败测试，你就无法证明你的代码做了你认为它做的事情。你是在实现并寄希望于结果。有了先有的失败测试，你就有了一个你的实现必须满足的精确规格——以及一个永远运行的验证机制。
这能防止什么：
- 充满信心地实现了错误的东西
- 总是通过的测试，因为它们什么都没测试
- "我确定它能用"作为唯一的验证方式
- 六个月后代码变更导致的回归
如何应用：
1. 编写测试 → 它失败（RED）
2. 编写使其通过的最简代码（GREEN）
3. 在不破坏测试的前提下重构（REFACTOR）
如果你无法编写失败测试，说明你对需求的理解还不足以实现它。停下来，先澄清需求。
铁律二：验证
"没有最新的验证证据，就不得声称工作已完成"
除非你刚刚运行了验证并将输出摆在面前，否则你不得声称工作已完成、已修复或已通过。
为什么不可谈判：
心理模型是不可靠的。"应该能用"的变更往往不能用。"之前能用"的代码可能已被后续变更破坏。唯一有效的证据是现在运行实际验证命令的输出结果。
这能防止什么：
- 充满信心地交付破损代码
- "在我机器上能用"的失败模式
- 将过时的测试结果视为当前状态
- 以口头保证替代证据
验证必须是最新的： 五次 commit 前运行测试然后声称当前状态没问题，不是验证。在当前状态上运行测试，阅读输出，然后再做声明。
铁律三：调试
"没有先做根本原因调查，就不得编写任何修复代码"
在编写任何修复代码之前，你必须完成第六章所描述的根本原因调查。你必须能够用一句话准确说明 bug 的成因。
为什么不可谈判：
不理解原因就修复症状，是技术债务积累的主要驱动力。每次症状修复都增加复杂性、掩盖真实问题，并使根本原因在之后更难发现。代码库变成了一层层没有人能理解的补丁。
这能防止什么：
- 同一个 bug 以不同形式再次出现
- 每次修复都破坏其他东西的修复链
- 丧失架构清晰度
- 三次失败模式（参见第六章）
根本原因陈述测试： 在实现修复之前，你必须能够毫无含糊地完成这个句子："这个 bug 是由 [具体事物] 引起的，因为 [证据]。" 如果你不能，调查尚未完成。
铁律四：Skills
"没有先有失败测试，就不得使用 Skill"
在创建或修改 Superpowers skill 时，同样的 TDD 规则适用。编写一个演示 skill 预期行为的测试，验证它失败，然后实现该 skill。
为什么不可谈判：
Skills 是代码。它们的行为可以是正确的，也可以是错误的。没有测试，skill 开发与任何其他未经测试的代码一样不可靠——它能用直到不能用，你无法知道它什么时候停止工作以及为什么。
主要红色警报表
这些是铁律即将被违反的警告信号。当你观察到其中任何一个时，立即停止当前操作并回到正确的规范。
| # | 红色警报 | 信号含义 | 停止操作 |
|---|---|---|---|
| 1 | "这应该能用" | 验证已被跳过 | 立即运行验证命令 |
| 2 | "应该没问题" | 无证据的假设 | 找到证据或承认不确定性 |
| 3 | "测试应该通过" | 测试尚未运行 | 运行测试 |
| 4 | "让我试试这个修复" | 没有根本原因调查 | 先完成调试第一阶段 |
| 5 | "我以后再加测试" | TDD 违规正在进行 | 现在先写失败测试 |
| 6 | "这是小变更，不需要测试" | 正在发明 TDD 例外 | 没有例外。写测试。 |
| 7 | "你说得完全正确！"（立即反应） | 表演性认同 | 先 Read → Understand → Verify → Evaluate |
| 8 | 修改测试以匹配破损的行为 | 掩盖 bug | 修复代码，而不是测试 |
| 9 | 直接 commit 到 main | 绕过隔离规范 | 创建 worktree 和分支 |
| 10 | 同一 bug 的第四次修复尝试 | 架构问题被掩盖 | 停下来。重新设计。不要继续打补丁。 |
| 11 | 总结测试输出而不是展示它 | 可能的幻觉或选择性阅读 | 展示实际输出 |
| 12 | 在新 worktree 中跳过基线测试 | 未知的起始状态 | 在编写任何代码之前运行完整的测试套件 |
反模式总结
以下反模式出现在本指南的所有章节中。它们在此汇总作为参考。
来自第一章：基础
- 工具配置错误： 使用 Superpowers 时未阅读 CLAUDE.md 或设置文档。Skills 需要正确配置才能正确触发。
- 绕过 Skill： 要求 agent "直接做"而不调用适当的 skill。Skills 的存在有其原因；绕过它们会产生质量较低的输出。
来自第二章：撰写计划
- 无计划即实现： 在计划被编写和审查之前就开始编写代码。计划能廉价地发现架构问题；代码则不能。
- 模糊的计划： 以结果而非具体步骤来编写计划。"实现认证"不是计划。具体操作的编号序列才是计划。
来自第三章：执行计划
- 串行执行独立任务： 在可以并行化的任务上一个接一个地执行。这不必要地成倍增加了实际耗时。
- 并行任务间共享状态： 并行运行修改相同文件或状态的任务。这会产生合并冲突和竞态条件。
来自第四章：TDD
- 实现后再写测试： 在代码编写完成后再写测试。这些测试很可能是围绕实现而非需求来塑造的。
- 测试实现细节： 编写每次代码重构时都会失败的测试，即使行为没有改变。测试行为，而不是实现。
来自第五章：头脑风暴
- 实现前跳过头脑风暴： 不探索问题空间就直接编码。在任何创意工作之前，头脑风暴是必须的。
- 将头脑风暴视为形式： 走一遍头脑风暴的流程而不真正探索替代方案。价值在于探索，而不是仪式。
来自第六章：调试
- 猜测和尝试： 在没有根本原因调查的情况下尝试修复。这是三次失败模式的主要来源。
- 同时修复多个问题： 为解决一个 bug 做多个变更，导致无法知道哪个变更有效。
- 过早声称完成： 在运行验证之前就说"已修复"。
来自第七章：代码审查
- 表演性认同： 未经评估就立即同意审查反馈。这会将错误的建议应用到正常运行的代码上。
- 忽视严重性级别： 将所有反馈视为同等紧迫。严重问题阻塞进度；次要问题记录存档。
来自第八章：Git Worktrees
- 直接 commit 到 main： 在 merge 或 PR 之外对 main 做任何变更。Main 始终是可部署状态。
- 没有基线测试就开始工作： 在首先验证基础分支上所有测试通过之前就开始功能工作。
执行
铁律由 agent 行为执行，而非工具。当你观察到违规——无论是 agent 的违规还是会导致违规的指令——正确的回应是指明被违反的铁律并回到正确的规范。
这不是阻碍。这是维持质量的方式。对铁律的每一次例外都是一次赌注，赌这个特殊情况足够特殊，值得豁免。这个赌注几乎总是错的。