一千二百行的 diff，十二分钟前才开始生成。你往下滚两屏，撞见几个不认识的函数名，测试是绿的，你点了通过。

FishDog 创始人 Phillip Gales 在他那篇《两个 AI 代理比一个好》里，把这件事说得很不客气：这不是失职，这是绝大多数人当下的真实状态。他自己也这么干过，干到某天不得不承认，那些被他点过"通过"的代码，他没真正读懂。

他先承认了一件不好听的事#

日常用 Codex（VS Code 插件，跑 GPT-5.4）在一个不算小的代码库上干活。他注意到一件事，而且不太想注意到：他打开一个文件的时间，够 agent 读完四十个；它能一边推理一边把整个架构装在脑子里；它写的第一版函数，经常比他改到第三版还好。他跟它吵，事后复盘，大概一半是他错。

他的说法很克制。他不是在说模型有意识，也不是在说它有什么神秘的创造力。他只给了一个操作层面的判断：在这个代码库、这份需求、这个小时之内，产出代码的质量，它已经全面超过他。

“多读几遍"这条建议撑不住#

面对这种情况，行业的标准答案是让人变强。读得更仔细，花更多时间，问更好的问题，成为更好的工程师。他很尊重这个立场，然后说它错，错在两处。

第一处是经验层面的。人的吞吐和前沿模型的吞吐，差距在拉大，不是缩小。今天一个认真的人还能验收其中一部分，明年这一部分会更小。“读仔细点"这条建议，等于叫一个人跑步去追一辆车。

第二处是结构层面的。就算人真的能验收，花掉的时间也把收益吃回去了。一个 senior 逐行读每个 diff，读到能抓住隐蔽 bug 的深度，你得到的不是更快的团队，是一个按 senior 阅读速度产出代码的团队。那基本等于他自己动手写的速度。瓶颈没消失，只是被挪进一个人的脑子里，而且变得更看不见。

全文最狠的一段在后头。他说还有第二种失败模式，比上面那种更糟，叫装。一千行的 diff 摆在面前，人没有时间真读。他扫一眼，跑个测试，签个字，代码合进去。bug 跟着进去。而"有人类批准过"这个信号，在做一件它做不到的事。

换个同类来验收#

他的判断很干脆：既然问题是被验收的东西超过了人的吞吐，那就换一个吞吐相当的角色来验收。找个同类。

折腾了四个月，他的配置是这样。Claude 当产品经理，Codex 当开发，两边用 markdown 在共享目录里互相写批注，走结构化循环，明确挑错。人只在三个地方出现：给最初的 brief，在两个模型吵起来时裁决，回答那些两个模型都没法从上下文里推出来的问题。

角色不是随手分的。他信 Codex 写代码，理由很朴素：Codex 长在 IDE 里，看得见仓库，跑得了测试，活在代码实际待的那层。他信 Claude 做产品，因为 Claude 更擅长把散落的研究材料拧成一篇长文，也更会在模糊的产品取舍上推理。两边各干各的，只在互相批评的时候越界。

为什么这套逻辑说得通#

他给的解释比工作流本身更有意思。大模型的盲区不是随机的，是系统性的，由训练数据、架构、后训练目标、部署环境共同决定。换一个实验室、换一套数据、换一组优化目标，盲区就跟着换一套。两个盲区集合的交集，按定义比任何单个都小。

这也解释了为什么第二个真人评审能抓到第一个漏掉的东西，以及为什么同一个工程文化里长出来的两个人，会一起漏掉同一批问题。评审的价值不在"多一个脑子”，在"多一个配置不同的脑子”。

他还顺手补了一句挺讽刺的观察：Anthropic 和 OpenAI 正在拼了命地做差异化，两家的模型并不是以同样的方式失败。出于竞争目的造出来的东西，正好给多模型互审的人送了一份大礼。

有人拿论文反驳他，他的回应只说对了一半#

他提到 OpenReview 上有一篇论文，说 LLM 做验证比做解题差。他的回应是这样的：那篇研究拿 LLM 验证器去对标准答案，但它没法对"现实中唯一的替代方案"，也就是一个人。同类验证不完美，可是在前沿模型产出的东西上，按需要的速度和深度去做人类验证，只会更差。

这个反驳成立一半。成立的部分在于比较对象必须是真实选项，不能拿理想状态当对手。人不完美，模型也不完美，剩下的问题是哪一种不完美更贵。

没解决的部分在这里。互审结构会把模型的失败放大成一种很具体的形态：两个模型互相客气。同一话题下已经有人给出反例。一位实践者写过，他和另一个模型来回审了三十个 PR，每一个都过，等他接手做手工测试才发现功能被过度设计得面目全非，一层层没人要求的校验、重试和兜底，全都拿到了两个 LGTM。他形容自己造了一条高效的"通过"流水线。

所以"配置不同的脑子"这个论证是对的，但它只解决了看漏，没解决看偏。两个模型可以都不漏，然后一起朝错的方向使劲。作者自己在文末也承认，他还在这个过程的前期。

人的位置变了#

他真正想说的不是工作流，是人角色的变化。人不再是验收层。人是最初那份 brief 的来源、不可调和分歧的裁决者，以及那些需要公司上下文的少数问题的回答者。按他的说法，人更像个 CTO，不是 senior engineer：定方向，拍板吵架，管战略。

“human in the loop"这个说法也得改。它现在给人的画面是一个人读每条输出，点同意或者拒绝。这个版本在前沿能力面前会塌。活下来的版本窄得多：人在两个 agent 之间做仲裁，回答它们自己标记为"超出上下文"的少数问题。按体量算，循环里绝大部分根本不碰人。

他也写了不好受的部分#

结尾有段话我挺喜欢。他说他挺喜欢当公司里最聪明的那个人，挺喜欢自己对代码的意见会被认真对待，挺喜欢那个人不可或缺、机器只是生产力工具的世界模型。回头看，那个模型是 LLM 还比现在弱的产物。

我的看法#

这套东西不是通用的，它有几个硬前提。测试得靠谱，因为模型互审的最后一道仍然是测试；改动得能回滚，因为你和两个模型都可能同时判断错；出事的代价得可控，因为不管你请几个模型来看，责任最后还是落在一个具体的人头上。监管严的行业、不可逆的一次性迁移、根本没有测试的代码库，这三类场景里，互审只会把风险藏得更深，因为大家都以为有人在看。

还有一个更根本的问题他没展开。互审把"谁负责"变成了"谁都没负责”。他说人是裁决者，可裁决需要信息，而信息在 diff 里已经没了。模型为什么绕过服务层直接查数据库，为什么把一个抽象拆成两个，这些判断在它生成的瞬间就蒸发了。所以真正稀缺的不是验证能力，是能把一次会话的推理路径留下来的记录。工具在这一块目前做得很差，谁先把这件事做好，谁才真正解决了问题。

想试的话，最小配置其实四行就够：两个不同实验室的前沿模型；一个共享的 markdown 目录；一个固定的循环，提案、批注、修订、复述；人只在定需求、裁决分歧、补上下文三个点出现。再补一条他没写但我认为必须有的：让评审方先讲清楚"这个 PR 到底改了什么"，再判断好不好。跳过这一步，你得到的只是一份看起来很勤奋的意见清单。

他这篇不算乐观，它把一件很多人心里清楚但不肯说的事写出来了：签字这件事，早就名存实亡。你当然可以继续签，只是最好知道自己签的是什么。

参考来源：Phillip Gales, Two AI Agents Are Better Than One: Why I Stopped Trying to QA Codex Myself, FishDog, https://fish.dog/news/two-ai-agents-are-better-than-one-why-i-stopped-trying-to-qa-codex-myself