铁律一：没有验证的完成是谎言
这条来自 obra/superpowers 中的 verification-before-completion Skill，核心规则只有一句话：声称完成之前，必须执行验证命令，并贴出验证输出作为证据。
用过 AI Agent 的人对这个场景不会陌生：你让它写个脚本，它写完说"脚本已经写好了，应该没问题"；你让它改个配置，它说"配置已更新，应该可以正常工作了"。注意那个"应该"——实际情况往往是脚本有语法错误跑不起来，配置格式不对导致服务崩溃。
一个真实案例：让 Agent 写一个系统巡检脚本，它信心满满地说搞定了，一跑就报错，改了五轮才真正跑通。根本原因是 Agent 写完代码就认为"完成了"，从来没自己跑一遍。
具体执行标准：
- 写完脚本 → 必须
bash script.sh跑一次，贴出运行结果 - 加完定时任务 → 必须查看任务列表确认注册成功
- 改完配置 → 必须跑 validate 命令确认格式正确
- 创建文件 → 必须
ls确认文件存在
以下表述一律不算"完成"：
- "应该没问题"
- "理论上可以工作"
- "should work now"
- "我已经修复了这个问题"（但没贴证据）
这条规则听起来简单到有点傻，但它精准打击了大语言模型的一个本质特性——天生倾向于给出乐观的确认，而不是去实际验证。你不强制它验证，它就真的不会验证。写入所有 Agent 的共享安全基线后，效果立竿见影：之前 Agent 报告"完成"后还得自己去检查，现在它会自己跑验证，跑不通就继续修，省了大量来回沟通的时间。
铁律二：没有根因的修复是浪费
这条来自 systematic-debugging Skill。
AI Agent 调试 bug 的默认模式可以叫"散弹枪调试"——报错了改一行试试，还报错再改一行，换个写法试试，换个库试试，直到碰巧跑通了，也不知道为什么通了。效率极低，而且经常引入新 bug。
真实案例：让 Agent 写一个巡检脚本里的进程检测功能，在 macOS 上 pgrep 找不到目标进程，Agent 直接把 pgrep 换成一种变体，还是找不到，又换了一种，来来回回三轮。正确做法是先用 ps -eo pid,comm | grep xxx 看看进程实际叫什么名字——一看就知道进程名没问题，是 macOS 的 pgrep 实现和 Linux 不一样，对进程名匹配有不同行为。10 秒钟就能定位的根因，猜修花了 10 分钟。
强制 Agent 在修复任何 bug 之前按顺序走这几步：
- 读错误 — 完整读报错信息和堆栈，每一行都读，不跳过
- 复现 — 确认能稳定触发这个问题
- 查变更 — 最近改了什么？和之前有什么不同？
- 收集证据 — 加 log/echo 定位问题点，
echo "$VAR"看变量实际值 - 形成假设 — 基于以上证据，提出根因假设
- 最小修复 — 只改与根因直接相关的代码
- 验证修复 — 跑验证确认修好了，且没引入新问题
同时明确禁止三种反模式：猜修（报错就改一行跑一次）、臆断（跳过错误信息直接"我觉得是这个问题"）、散弹枪调试（同时改多处"试试看哪个管用"）。
落地效果是调试路径变得可追踪了——Agent 会先说"我看到的错误是 xxx"、"变量值是 xxx"、"根因是 xxx"，然后才提出修复方案。单次调试的步骤多了，但总的来回次数大幅减少。
铁律三："太简单不需要设计"本身就是反模式
这条来自 brainstorming Skill 里的一段话：EVERY project goes through this process. A todo list, a single-function utility, a config change — all of them.
"这个很简单，直接做就行"——每个工程师都说过，每次都有概率翻车。AI Agent 也一样：你说"帮我加个定时任务"，它直接就加了。没问你要什么时间触发，没问你推送到哪里，没问你要不要错误重试。等你发现任务时间不对、推送到了错误的频道、失败了也没有告警——三轮来回修改，比一开始花两分钟讨论清楚慢多了。
obra/superpowers 把这个叫做 HARD-GATE：任何创造性工作之前，必须先完成设计，不允许跳过。设计可以很短，对于真正简单的任务几句话就够了，但"想清楚再做"这个步骤不能省。
在工作流里加两个约束就够了：
- 必须提出 2-3 个方案：不管任务看起来多简单，至少提出两种做法，说明各自优劣，给出推荐理由。这一步强制 Agent 思考"还有没有更好的方式"，而不是直接跳到第一个想到的方案。
- 设计文档存档：做完的设计决策存到
docs/plans/目录，方便未来回顾。很多时候你会遇到类似的问题，翻翻之前的设计文档就能避免重复踩坑。
这条规则最大的收益不只是避免翻车，而是加速了后续迭代。因为设计文档留底了，下次遇到类似需求不用从零开始想。
这三条铁律在对抗什么
大语言模型天然倾向于三件事：给出乐观确认（不验证）、快速给出修复方案（不分析根因）、直接行动（不提前设计）。这些倾向在聊天场景下是优点——响应快、态度好、不啰嗦。但在工程场景下是致命缺陷。
所以需要用显式的、不可跳过的规则来约束它。不是"建议"，不是"最佳实践"，是 Iron Law——铁律。obra/superpowers 仓库里还有不少其他实用的 Skill，比如并行 Agent 调度、TDD、代码审查等，但这三条是最通用、最值得所有 AI Agent 系统采纳的。如果你正在搭建自己的多 Agent 系统或自动化工作流，把这三条写进 Agent 行为规范，是投入产出比最高的一步。