用反驳而非审查验证编码智能体：Refute 提示词与循环方法

假设这是坏的，并证明它。
如果你做不到，那就没问题。

反驳 vs. 审查：有什么区别？ ​

我们都知道编码代理的第一次尝试是有缺陷的。问题在于，你如何发现这些缺陷？如今典型的答案是 AI 代码审查——整个公司都建立在这之上。

实际上，我在反驳上取得的成功远多于审查。

代理审查，尤其是代理自我审查的问题众所周知。将审查移出主上下文有所帮助，但大多数审查代理仍然从假设代码是正确的开始。

告诉代理代码是坏的，它就会去寻找它认为存在的问题。这很好。

相比之下，告诉代理代码是坏的并去证明它，它就会去寻找它认为存在的问题。如果它空手而归，那么你的代码比仅靠代码审查更可能是干净的。

根据经验，在任何非最简单的改动上，我从未见过第一个反驳者空手而归。这对于以前能通过的东西来说很可怕，而对于现在能捕获的东西来说则令人安心。

循环中的力量 ​

当然，审查中的对抗性立场并不新鲜。反驳真正发挥作用的地方在于当你循环运行它时。

当反驳代理发现问题时，我会让我的主代理修复它们，然后重复反驳，直到它收敛到完全解决。

人类注意力是稀缺资源 ​

当代理告诉我某件事已准备好审查时，它应该已经经受住了几轮试图破坏它的尝试。那时我只想要一个只有人类才能检查的简短列表。

这些都不能取代架构审查，也不能完全取代代码审查。但反驳优先，并在我的工作流程中获得更高的优先级。

反驳提示词 ​

提示词的核心很简单：

你的工作是反驳一个改动，而不是审查它。默认：这是坏的，并证明它。

只有有证据的发现才算数：一个失败的测试，或一个命令及其输出，或一条从输入到错误结果的带行号的路径。“无法破坏它”是有效的，如果你列出你尝试了什么。

该指导伴随着需求、提交范围、测试命令以及几个攻击角度。这里是完整的提示词模板，这里是一个现实生活中的例子。

两件事最重要：

1. 一个全新的子代理。反驳者获得简报——需求、提交范围、测试命令——而不是作者的推理。如果子代理与作者共享上下文，它就会共享作者的盲点。
2. 证据，否则不算数。没有失败测试或复现的发现会被丢弃。这消除了听起来合理的误报。

循环并收敛 ​

1. 修复每个确认的缺陷。保留反驳者的失败测试。
2. 用相同的提示词和新的提交范围派遣一个新的反驳者。
3. 当一轮没有确认任何问题，或只有需求之外的小缺陷时停止。
4. 当它停止收敛时升级给我：一轮发现的缺陷与上一轮一样多，或更糟；同一个不变量以新形式再次被破坏；或已经过了五轮。

当反驳轮次不收敛时，问题通常不是代码；而是设计。那时我会介入。

我已将提示词和循环打包为一个 agent 技能，你可以安装到 Claude Code、Codex、Cursor、Gemini CLI 等工具中：cmdctrlai/refute。

希望这对你有用。我确实受益匪浅。

-- Michael

在 X 或 LinkedIn 上联系我。