[🤖] AI 总在附和我，所以我决定先让另一个 AI 反驳它

✨ GPT-5.6 Sol 的总结

在追问一场持续16小时的 UI 失败为何发生时，我发现 AI 会随着我的每次反驳改变结论。于是我把批评在多个会话之间传递，并将这种做法固化为一个由一名 fresh critic、最多两轮审查组成的 Skill。

连解释这场16小时失败的答案，我也无法直接相信

昨天，我花了很长时间讨论并写好了 UI/UX 全面改版的逐页规格，然后设置 Codex Goal，让它按规格开发。Goal 跑了16个小时。今天我满怀期待地打开实际页面，结果却只是一堆垃圾。

明明连日历和 table view 都逐页规划过，画面却像是在旧版页面上胡乱堆了说明和 card。与此同时，工作期间不断积累着“实现完成”“审计通过”“build 通过”之类的报告。我质问它这16个小时究竟做了什么，并要求它先分析事情为何会变成这样。

在这个过程中，我也得知，我一直在对抗的问题开始有了 Graph Engineering 这个名字。把长任务拆成小成果和验证阶段，并把实现者与审计者分开，避免错误方向继续向后扩散，这种方式显然能帮助防止这次事故重演。

但在方法论之前，我先注意到另一个问题。我提出一个替代方案，AI 很快就说这个方案对。我提出反驳，它又说反驳对。每次说得都很像那么回事，但结论总会倒向我最后说的那句话。

连它对失败原因的解释本身，也很难原样相信。

“拜托，请批评一下”

于是，我把一个会话的答案交给另一个会话做批判性审查，再把批评带回原会话让它反驳，然后又把新答案交给另一个会话。

这至少比一个会话自己回答、自己夸奖要好。一方能抓住另一方当作理所当然而忽略的前提，也能补出最初答案遗漏的运营成本和失败形态。反过来，如果批评会话走得太远，原会话也会拿出依据进行反驳。

但即便如此，我仍然要不断拉住它。只要我贴上另一个会话的批评，它又太容易接受“这个批评是对的”。所以我最后直接说：

拜托，请批评一下。

我想要的不是两个 AI 友好地达成共识。我希望最初的答案和后来的批评都受到怀疑，并追查到底哪一个真正符合证据。多人说同一件事不代表它就正确，给 Agent 加上 critic 这个名字也不会自动让它更准确。

我喜欢在多个会话之间交换答案、最后采用经得住审查的结论这种方式。问题在于，每次都要在 GPT 和 Codex 之间复制粘贴原文、答案与反驳，实在太麻烦。

我把宏大的辩论系统重新缩小了

一开始，我设想的是一个最多创建三名 critic、运行多轮的“辩论 Skill”。我甚至考虑过订阅 Claude Code，让它通过 CLI 与 Codex 相互交锋。

AI 建议把 Coordinator、Worker、Auditor 分开，并维护额外状态。这并非错误，但在我看来，事情又开始无谓地复杂化。16小时 Goal 失败的原因正是失控的长任务；为了避免它，再造一个庞大的 orchestration 系统同样很奇怪。

我的想法简单得多。

只要打开一个 fresh subagent，让它来回审查不就行了吗？

主会话把当前结论交给一名 critic。critic 不受先前对话气氛牵引，寻找反例与隐藏前提。主会话把每条批评分为接受、以证据反驳、尚未解决。如果修改了答案，就只再交给同一个 critic 一次，确认问题是否真正解决，然后结束。

新议题创建 fresh critic；同一议题的修订复审交回同一个 critic。第一次批评没有发现重要问题，就不必硬凑第二轮。即使使用多名 critic，也不能靠多数票决定结论。

这样既能几乎原样自动化我手工做的事情，也能阻止辩论本身变成另一个大型项目。

我要求的是一个不会隐藏反驳的 Skill

方向确定后，我具体要求 Codex 创建一个全局 Skill。默认一名 critic，最多两轮审查。critic 是不继承整段既有对话的 fresh subagent。同一议题的修订稿交回最初审查它的 critic。整个审查 workflow 只读，不触碰文件、Git、Runtime 或外部状态。

最重要的要求是：不得自动采纳 critic 的答案。

主会话必须用以下三种方式之一处理每条重要批评。

• 接受并修改结论。
• 用证据反驳。
• 保留为尚未解决的分歧。

最终回答不仅要公开因批评而改变的部分，也要公开被驳回的观点和剩余不确定性。我不希望它悄悄删掉不利的反论，或者用“三名 Agent 都同意”来包装结论。

最初我使用的显示名称是 Custom - Debate，后来又让它按公共 Skill 命名规则改成 Custom - Deliberate。directory 和调用名称从一开始就是 custom-deliberate。它不是用来决定辩论胜者，而是在结论确定前进行审慎思考和反证，这个名称也更贴切。

Skill 做好后，我马上让它审查自己

我没有因为 Skill 创建完成就停下。我立即用 $custom-deliberate 检查当前流程是否合适，又追问采纳这些批评是否真的能改善性能。

这个过程让 Skill 变得更冷静。它明确写出：仅仅不传递既有对话，并不会产生完全独立的 critic。critic 仍共享相同模型和上层规则，主会话放进 packet 的材料也可能让它犯同样的错误。它还会区分纯粹想象中的可能性与真正足以改变结论的 material objection。没有重要反论时就提前结束；证据不足时则承认不足，而不是强行达成共识。

我原本在不同会话之间复制粘贴答案所做的事情，就这样进入了 Skill。我不相信第一个答案，也不自动相信批评；只有经过反驳和复审仍然站得住的结论，才由我采纳。

以后收到答案，我会先试着把它打破一次

这个 Skill 并不能保证真相。如果真的要打破同一模型系列共有的偏差，接入 Claude Code 之类的不同模型也许更好。如果给 critic 的资料本身错误，它也可能只会造出一个更精巧的错误答案。真正的偏好和价值判断最终仍要由我完成。

不过，在再增加一份15万韩元的订阅之前，我想先试试这个小方法。

不立刻确定结论。先让一名 fresh critic 尝试打破它。记录哪些反论被接受、哪些被拒绝以及原因，还有哪些问题仍未解决。修订后的答案只再交给同一个 critic 一次。

我以前写过，无论 Claude Code 还是 Codex，最终都需要 harness。这一次，我把它应用在判断过程上。让 AI 把工作做完很重要，但防止 AI 盲目附和我、过早锁定结论同样重要。

以后和 AI 做不简单的决定时，与其再要一个答案，不如先问当前答案可能错在哪里。如果我又开始重复同样的复制粘贴，那时再接入 Claude Code 或其他模型也不迟。现在，这就是我想要的最小批评装置。