用对抗性Agent审核提示词发现隐藏的工程漏洞

我最近正在用 Claude Code 开发一个应用。

这套协作方式有点特别：一个「指挥官」session 负责编写指令，多个独立的「执行者」session 并行实现。指挥官自己从不碰键盘，它唯一的任务，就是把「下一步该做什么」整理成一份交接 prompt，让执行者拿到后可以直接开工。

而这份交接 prompt，恰恰是整个流程中最令人不安的部分。交出去的那一刻，执行者就会把它当作 spec，开始全速推进。如果 spec 有误，它就会迅速而自信地做出错误的东西。

交出去之前，我照例做了一遍自己的固定仪式

最近我养成了一个习惯：在把指令交给执行者之前，先让一个 subagent 审查一遍。这个 subagent 的唯一任务，就是把这些指令彻底拆穿。它被明确要求绝不能批准，要专门寻找漏洞，而且无论如何都不能用「整体看来还算合理」作为结论。

这次不一样的地方在于：它不只是阅读我的 prompt 文本，还真的去读了实际代码。它给出的回复，让我心里猛地一沉。

质疑一：我写了「让测试通过（变绿）」，但那个测试即便空有其表也能变绿

在指令中，我把下面这句话写成了完成标准：「让 XX 测试通过（变绿）。」

负责拆解的 Agent 回复道：「即使被测试的功能失败，这个测试也会变绿。」

我检查了一遍，确实如此。这个测试只检查「进程是否完整运行到了最后」，却从未检查唯一真正重要的事情：它到底成功了吗？即使失败了，只要它「返回了失败结果并完成运行」，测试仍然会变绿。更糟的是，批处理路径还会吞掉异常，所以无论哪里出了问题，最终依然是绿的。

因此，即使执行者回来报告「DoD 已满足，测试全绿！」也根本证明不了什么。我亲手写下的完成标准，只是一次毫无意义的空通过。

质疑二：我写了「只需切换一个 flag」，但那个开关根本不存在

还有一个问题。我写道：「切换一个配置 flag，就会换成真实组件。」仿佛这项功能早已存在。

负责拆解的 Agent 沿着代码调用关系追查后回复：「这段接线逻辑从未被任何地方调用。函数虽然存在，但没有任何东西连接到它。」

这也是真的。替换组件的函数确实存在，但 UI 中没有任何路径能够触达它。执行者差一步就可能落入两种境地：要么花一个小时寻找一个根本不存在的开关，要么找累了之后，自己捏造一个「差不多能用」的东西。

真正让我害怕的是，我把这两件事都当成了事实来写

两次我都写得斩钉截铁：「测试会通过。」「这个 flag 会完成替换。」写下这些话时，我确实深信不疑。负责拆解的 Agent 只是读了那些我没有重新读过的代码，区别仅此而已。

交接 prompt 本质上就是一份 spec。而谎言往往恰好会在工作交接的那一刻混进来——无论是人交给 AI、AI 交给 AI，还是今天的自己交给下周的自己。一个空有绿色结果的测试；一条「本来应该已经接好」的线路。只阅读文字、点点头然后批准的审查，发现不了这些问题。只有真正阅读实际代码，并带着攻击性审视它的评审，才能将其揪出来。

「测试是绿的」这一结论，只有在测试本身正确时才有意义。而由你亲手写下的完成标准，往往正是你最不容易怀疑的东西。

所以，也许在开始敲代码之前，最应该被彻底拆解的并不是代码，而是指令。如果实现工作已经跑了十个小时，才发现「那个绿色结果毫无意义」，代价远比交接前花三分钟做一次对抗性审查高得多。

如需采取进一步措施，你可以考虑屏蔽此人和／或举报滥用行为。