最近读了 GitHub 上一个叫 obra/superpowers 的项目。这是一套给 Claude Code 设计的开发流程 Skill 集，14 个 Skill 覆盖了从头脑风暴到代码审查的完整开发生命周期。
读完之后，我从里面提炼出三条对 AI Agent 工程最有用的"铁律"，已经落地到我自己的多 Agent 系统里了。
对于openclaw工作流程优化帮助比较大，分享一下。
铁律一：没有验证的完成是谎言
NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE
这是 obra/superpowers 里 verification-before-completion 这个 Skill 的核心规则。
为什么需要这条
用过 AI Agent 的人都知道一个痛点：Agent 特别喜欢说"完成了"。
你让它写个脚本，它写完会说"脚本已经写好了，应该没问题"。你让它改个配置，它改完说"配置已更新，应该可以正常工作了"。
注意那个"应该"。
实际情况呢？脚本可能有语法错误跑不起来，配置可能格式不对导致服务崩溃。我自己就踩过这个坑 —— 让 Agent 写一个系统巡检脚本，它信心满满地说搞定了，结果我一跑就报错。改了一轮还报错，改了五轮才真正跑通。
问题出在哪？Agent 写完代码就认为"完成了"，从来没有自己跑一遍验证过。
怎么做
规则很简单：
声称完成之前，必须执行验证命令，并且贴出验证输出作为证据。
具体来说：
写完脚本 → 必须 bash script.sh 跑一次，贴出运行结果
加完定时任务 → 必须查看任务列表确认注册成功
改完配置 → 必须跑 validate 命令确认格式正确
创建文件 → 必须 ls 确认文件存在
同时，以下表述一律不算"完成"：
"应该没问题"
"理论上可以工作"
"should work now"
"我已经修复了这个问题"（但没贴证据）
这条规则听起来简单到有点傻，但它解决了一个 AI Agent 的本质问题 —— 大语言模型天生倾向于给出乐观的确认，而不是去实际验证。你不强制它验证，它就真的不会验证。
落地效果
写入所有 Agent 的共享安全基线后，效果立竿见影。之前 Agent 报告"完成"后我还得自己去检查，现在它会自己跑验证，跑不通就继续修。省了大量来回沟通的时间。
铁律二：没有根因的修复是浪费
NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST
这来自 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" 看变量实际值
形成假设 — 基于以上证据，提出根因假设
最小修复 — 只改与根因直接相关的代码
验证修复 — 跑验证确认修好了 + 没引入新问题
同时明确禁止三种 anti-pattern：
猜修：报错就改一行跑一次，不行再改
臆断：跳过错误信息直接"我觉得是这个问题"
散弹枪调试：同时改多处"试试看哪个管用"
落地效果
这条主要写入了负责代码开发的 Agent 的行为规范。效果是调试路径变得可追踪了 —— Agent 会先说"我看到的错误是 xxx"、"变量值是 xxx"、"根因是 xxx"，然后才提出修复方案。虽然单次调试的步骤多了，但总的来回次数大幅减少。
铁律三：太简单不需要设计是 anti-pattern
EVERY project goes through this process. A todo list, a single-function utility, a config change — all of them.
这来自 brainstorming Skill 里的一段话。
为什么需要这条
"这个很简单，直接做就行。"
每个工程师都说过这句话。每次说完都有概率翻车。
AI Agent 也一样。你说"帮我加个定时任务"，它直接就加了。没问你要什么时间触发，没问你推送到哪里，没问你要不要错误重试。等你发现它加的任务时间不对、推送到了错误的频道、失败了也没有告警 —— 三轮来回修改，比一开始花 2 分钟讨论清楚慢多了。
obra/superpowers 把这个叫做 HARD-GATE：任何创造性工作之前，必须先完成设计，不允许跳过。
设计可以很短 —— 对于真正简单的任务，几句话就够了。但你不能跳过"想清楚再做"这个步骤。
怎么做
在现有的工作流程里加两个约束：
约束一：必须提出 2-3 个方案
不管任务看起来多简单，都至少提出两种做法，说明各自优劣，给出推荐理由。这一步强制 Agent 思考"还有没有更好的方式"，而不是直接跳到第一个想到的方案。
约束二：设计文档存档
做完的设计决策存到 docs/plans/ 目录，方便未来回顾。很多时候你会遇到类似的问题，翻翻之前的设计文档就能避免重复踩坑。
落地效果
这条规则最大的收益不是避免翻车（虽然确实减少了），而是加速了后续的迭代。因为设计文档留底了，下次遇到类似需求不用从零开始想。之前做过的健康模块设计、英语学习系统设计、安全防御方案，如果当时都存了文档，后续优化会快很多。
这三条铁律都在对抗 AI Agent 的天性。
大语言模型天然倾向于：给出乐观确认（不验证）、快速给出修复方案（不分析根因）、直接行动（不提前设计）。这些倾向在聊天场景下是优点，但在工程场景下是致命缺陷。
所以你需要用显式的、不可跳过的规则来约束它。不是"建议"，不是"最佳实践"，是 Iron Law —— 铁律。
obra/superpowers 仓库里还有不少其他有用的 Skill（并行 Agent 调度、TDD、代码审查等），但这三条是我认为最通用、最值得所有 AI Agent 系统采纳的。
如果你也在搭建自己的 AI Agent 系统，不妨试试把这三条写进你的 Agent 行为规范。效果，比你想的明显。
