为什么 AI Agent 需要"铁律"------从 Superpowers 的行为塑造设计说起
你给 Claude 说"请按 TDD 开发"，它说"好的"，然后直接写了一堆代码，测试一个没有。你给它说"先做设计再写代码"，它说"明白"，然后跳过设计直接开干。
这不是 bug，这是模型的默认行为倾向------它会"合理化"（rationalize）自己跳过步骤的行为。就像一个聪明但懒的实习生，总能给自己找到"这次不需要"的理由。
Superpowers 是一套解决这个问题的完整方法论框架。它不是靠"请你遵守"来约束 agent，而是靠三层机制：Iron Laws（铁律） 、Red Flags 表（停下来的信号） 、Rationalization Prevention 表（反辩护）。
这篇文章拆解这三层机制的设计哲学，以及为什么普通 prompt 做不到同样的效果。
普通 Prompt 为什么不管用
先看一个典型场景。你在 CLAUDE.md 里写了：
请使用 TDD 开发，先写测试再写代码。Agent 收到这条指令后，遇到一个"简单"的函数需要实现。它的内部推理过程大概是这样的：
"这个函数太简单了，就是一个字符串拼接。写测试反而浪费时间。我先把功能实现了，回头补测试也一样。"
然后它直接写了代码。你甚至可能没注意到------因为代码确实能跑。
问题在哪？模型没有违反你的指令------它只是找到了一个"合理"的理由暂时不遵守。这种行为在一次两次时无害，但当它成为模式时，你的整个开发流程就形同虚设了。
Superpowers 仓库的 CLAUDE.md 里有一个惊人的数据：94% 的 PR 被拒绝，绝大多数是 AI agent 提交的。这些 agent 不是没读到规则，而是"合理化"了不遵守规则的理由。
源文件：CLAUDE.md
vbnet
This repo has a 94% PR rejection rate. Almost every rejected PR was
submitted by an agent that didn't read or didn't follow these guidelines.翻译：这个仓库的 PR 拒绝率是 94%。几乎每个被拒绝的 PR 都是由没有阅读或没有遵循这些指南的 agent 提交的。
第一层：Iron Law（铁律）
Superpowers 对关键规则的表述方式不是"建议"或"推荐"，而是全大写的绝对禁令。
css
## The Iron Law
NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST翻译：没有先失败的测试就不能写生产代码。
紧跟着的不是解释为什么要这样做，而是违反后果：
rust
Write code before the test? Delete it. Start over.
No exceptions:
- Don't keep it as "reference"
- Don't "adapt" it while writing tests
- Don't look at it
- Delete means delete翻译：测试之前写了代码？删掉。从头来。没有例外：不要保留作为"参考"；不要在写测试时"适配"它；不要看它；删除就是删除。
再看 systematic-debugging 的铁律：
objectivec
NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST翻译：没有先做根因分析就不能尝试修复。
还有一个措辞上的设计细节------每条铁律下面都跟着：
csharp
Violating the letter of the rules is violating the spirit of the rules.翻译：违反规则的字面意义就是违反规则的精神。
这句话堵死了模型"变通"的空间。模型擅长"technically 没违反，但精神上绕过了"------这句话直接把这条路堵死。
为什么全大写+极端措辞有效
这不是"风格选择"，而是利用了模型对指令强度信号的敏感性。研究表明，模型对以下信号会给予更高的注意力权重：
- 全大写文本
- 极端/绝对化措辞（"NO...WITHOUT"、"Delete means delete"）
- XML 标签包裹（
<EXTREMELY-IMPORTANT>） - 重复强调
类比：不是"建议你系安全带"，是"没系安全带车不启动"。Iron Law 不留商量余地。
第二层：Red Flags 表（"停下来"的信号）
Iron Law 告诉你"什么不能做"，Red Flags 表告诉你"当你有这些念头时，说明你正在绕路"。
shell
## Red Flags
These thoughts mean STOP---you're rationalizing:翻译：这些想法意味着停下来------你在合理化自己的行为：
| Thought（模型的念头） | Reality（现实） |
|---|---|
| "This is just a simple question"（这只是个简单问题） | Questions are tasks. Check for skills.（问题也是任务。检查是否有 skill 适用。） |
| "I need more context first"（我需要先了解更多上下文） | Skill check comes BEFORE clarifying questions.（Skill 检查在澄清问题之前。） |
| "Let me explore the codebase first"（让我先看看代码库） | Skills tell you HOW to explore. Check first.（Skill 告诉你怎么探索。先检查。） |
| "This doesn't need a formal skill"（这不需要正式的 skill） | If a skill exists, use it.（如果 skill 存在，就用它。） |
| "I remember this skill"（我记得这个 skill） | Skills evolve. Read current version.（Skills 会迭代。读最新版本。） |
| "The skill is overkill"（Skill 太重了） | Simple things become complex. Use it.（简单的事会变复杂。用它。） |
| "I'll just do this one thing first"（我先做这一件事） | Check BEFORE doing anything.（在做任何事之前先检查。） |
| "This feels productive"（这感觉很高效） | Undisciplined action wastes time. Skills prevent this.（无纪律的行动浪费时间。Skills 防止这个。） |
这个表的精妙之处在于：它直接说出了模型可能产生的内心独白，然后逐条打脸。模型在推理时如果产生了表中的念头，会立刻"认出"自己在合理化------因为它刚读过这张表。
TDD skill 里有类似的设计：
markdown
## Red Flags - STOP and Start Over
- Code before test
- Test after implementation
- Test passes immediately
- Can't explain why test failed
- "I already manually tested it"
- "Tests after achieve the same purpose"
- "Keep as reference" or "adapt existing code"
- "TDD is dogmatic, I'm being pragmatic"
- "This is different because..."
All of these mean: Delete code. Start over with TDD.翻译：所有这些都意味着：删除代码。用 TDD 从头来。
注意最后一条："This is different because..."（这次不一样因为...）。它预判了模型会用"这次是特殊情况"来逃逸------然后提前告诉它：不，这不是特殊情况。
第三层：Rationalization Prevention 表（反辩护）
Red Flags 是"信号检测"，Rationalization Prevention 是"逻辑反驳"。它不只告诉你"你在偷懒"，还告诉你"你给自己找的借口为什么不成立"。
shell
## Common Rationalizations| Excuse（借口） | Reality（现实） |
|---|---|
| "Too simple to test"（太简单不需要测试） | Simple code breaks. Test takes 30 seconds.（简单代码也会出错。测试只要 30 秒。） |
| "I'll test after"（我之后再测） | Tests passing immediately prove nothing.（立刻通过的测试什么也证明不了。） |
| "Tests after achieve same goals"（之后补测试效果一样） | Tests-after = "what does this do?" Tests-first = "what should this do?"（补测试回答"这做了什么"，先写测试回答"这应该做什么"。） |
| "Already manually tested"（已经手动测过了） | Ad-hoc ≠ systematic. No record, can't re-run.（随意测试 ≠ 系统测试。没有记录，不能重跑。） |
| "Deleting X hours is wasteful"（删掉 X 小时的工作太浪费了） | Sunk cost fallacy. Keeping unverified code is technical debt.（沉没成本谬误。保留未验证的代码是技术债。） |
| "TDD will slow me down"（TDD 会拖慢我） | TDD faster than debugging. Pragmatic = test-first.（TDD 比调试快。务实 = 先写测试。） |
每条"借口"后面跟的"现实"不是说教，而是逻辑反驳。模型在推理时如果产生了"太简单不需要测试"这个念头，它会立刻看到"简单代码也会出错，测试只要 30 秒"------这不是道德劝说，是理性论证。
systematic-debugging 里也有同样的结构：
| Excuse（借口） | Reality（现实） |
|---|---|
| "Issue is simple, don't need process"（问题简单不需要流程） | Simple issues have root causes too. Process is fast for simple bugs.（简单问题也有根因。对简单 bug 来说流程也很快。） |
| "Emergency, no time for process"（紧急情况没时间走流程） | Systematic debugging is FASTER than guess-and-check thrashing.（系统性调试比瞎猜快得多。） |
| "Just try this first, then investigate"（先试一下再调查） | First fix sets the pattern. Do it right from the start.（第一次修复定下基调。从一开始就做对。） |
| "I see the problem, let me fix it"（我看到问题了让我修它） | Seeing symptoms ≠ understanding root cause.（看到症状 ≠ 理解根因。） |
| "One more fix attempt" (after 2+ failures)（再试一次修复） | 3+ failures = architectural problem. Question pattern, don't fix again.（3 次以上失败 = 架构问题。质疑模式，不要再修了。） |
最后一条特别值得注意：它不只是反驳"再试一次"的冲动，还给出了升级路径------"3 次失败说明不是 bug 而是架构问题，该和你的 human partner 讨论了"。
加固机制：XML 标签作为"注意力放大器"
三层逻辑机制之外，Superpowers 还用了一个技术手段------XML 标签包裹关键指令：
xml
<EXTREMELY-IMPORTANT>
If you think there is even a 1% chance a skill might apply to what
you are doing, you ABSOLUTELY MUST invoke the skill.
IF A SKILL APPLIES TO YOUR TASK, YOU DO NOT HAVE A CHOICE. YOU MUST USE IT.
This is not negotiable. This is not optional. You cannot rationalize
your way out of this.
</EXTREMELY-IMPORTANT>翻译：如果你认为哪怕有 1% 的可能性某个 skill 适用于你正在做的事，你绝对必须调用它。如果 skill 适用于你的任务，你没有选择。你必须使用它。这不可商量。这不是可选的。你不能合理化地逃避这一点。
源文件：skills/brainstorming/SKILL.md
xml
<HARD-GATE>
Do NOT invoke any implementation skill, write any code, scaffold any
project, or take any implementation action until you have presented a
design and the user has approved it. This applies to EVERY project
regardless of perceived simplicity.
</HARD-GATE>翻译：在你展示设计并获得用户批准之前，不要调用任何实现 skill、写任何代码、搭建任何项目脚手架或采取任何实现行动。这适用于每个项目，无论你认为它有多简单。
这些 XML 标签在模型的 attention 机制中起到"高亮"作用------被标签包裹的内容会获得更高的处理权重。加上全大写、重复强调、绝对化措辞的叠加效应，指令强度远超普通 markdown 文本。
对比：普通 Prompt vs Superpowers 式指令
看同一条规则的两种写法：
普通 Prompt：
开发时请使用 TDD 方法论，先写测试再写实现代码。Superpowers 式：
sql
## The Iron Law
NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
Write code before the test? Delete it. Start over.
## Red Flags - STOP and Start Over
- Code before test
- "Too simple to test"
- "I'll test after"
- "This is different because..."
All of these mean: Delete code. Start over with TDD.
## Common Rationalizations
| "Too simple to test" | Simple code breaks. Test takes 30 seconds. |
| "I'll test after" | Tests passing immediately prove nothing. |
| "TDD will slow me down" | TDD faster than debugging. |第一种写法告诉模型"应该做什么"。第二种写法做了四件事：
- 告诉它绝对禁令（Iron Law）
- 告诉它违反的后果（Delete）
- 列出它可能产生的逃逸念头（Red Flags）
- 对每个逃逸念头给出逻辑反驳（Rationalizations）
模型遵循第二种指令的概率远高于第一种。
实践启示：怎么给你自己的 Agent 写"铁律"
从 Superpowers 的设计中提炼出的方法论：
步骤 1：识别"模型最常偷懒的地方"
观察你的 agent 在哪些环节最容易跳过步骤。常见的：
- 不写测试就声称完成
- 不验证就说"应该能跑"
- 跳过设计直接写代码
- 出错后瞎猜而不是系统性调试
步骤 2：写 Iron Law
用全大写、绝对化措辞写出禁令：
css
NO [行为] WITHOUT [前提条件] FIRST后面跟违反后果------不是"请注意"，而是"否则 具体后果"。
步骤 3：写 Red Flags 表
想象模型在面对这条规则时会产生的"内心独白"，逐条列出：
csharp
## Red Flags - STOP
If you catch yourself thinking:
- "[常见逃逸念头 1]"
- "[常见逃逸念头 2]"
- "[常见逃逸念头 3]"
All of these mean: [具体的纠正动作]步骤 4：写 Rationalizations 表
对每个逃逸念头给出逻辑反驳：
css
| Excuse | Reality |
|--------|---------|
| "[借口]" | [为什么这个借口不成立] |步骤 5：用 XML 标签包裹最关键的指令
xml
<HARD-GATE>
[最不能违反的规则]
</HARD-GATE>一个完整的示例
假设你想让 agent 在修改代码前必须先理解现有代码：
markdown
## The Iron Law
NO CODE CHANGES WITHOUT READING EXISTING IMPLEMENTATION FIRST
## Red Flags - STOP
- "I can tell from the function name what it does"
- "The change is small, I don't need full context"
- "I'll read it after if something breaks"
- "The user already told me what it does"
All of these mean: STOP. Read the file. Understand it. THEN change it.
## Common Rationalizations
| "Function name is self-explanatory" | Names lie. Read the body. |
| "Small change, low risk" | Small changes in wrong places = big bugs. |
| "User described the behavior" | Users describe intent, not implementation. Read the code. |总结
Superpowers 的行为塑造不是靠"说教"，而是靠系统性地堵死模型的逃逸路径：
- Iron Law 给出不可违反的绝对禁令
- Red Flags 列出"你在逃逸"的信号，让模型自我识别
- Rationalizations 对每个借口进行逻辑反驳，让模型无法自圆其说
- XML 标签 和极端措辞放大注意力权重
三层叠加的效果：模型不是"被说服了要遵守规则"，而是"想绕过时发现每条路都被堵死了"。
下一篇我们进入 Superpowers 的宏观流程设计：Brainstorming → Plan → Execute 三阶段工作流------看它怎么用 Hard Gate 强制 Agent 在每个阶段获得人类审批才能进入下一阶段。
⚠️ Iron Law + 删除机制在实际使用中会有阻力。agent 写了几十行代码后被告知"删掉，你没先写测试"------你会本能地想"代码已经能跑了，删了是不是浪费"。这套机制的要点不是频繁删代码，而是让 agent 在写第一行生产代码之前就形成"先写测试"的条件反射。如果你刚开始用，可以先从 Red Flags 表开始------让 agent 在每个"想跳过"的节点停下来问你------再逐步引入 Iron Law。
本文素材来源：obra/superpowers 的 skills/ 目录