同样是Claude Opus 4.7和Codex GPT-5.5配合写代码，谁先写、谁来审，结果并不对称。加州大学戴维斯分校、约翰斯·霍普金斯大学、加州州立大学长滩分校团队在116道LiveCodeBench中高难度题上测试发现：Claude审查Codex草稿，正确率从71.6%升到89.7%；Codex审查Claude草稿，却把91.4%降到82.8%。
实验模拟的是提交测试前的一次静态代码审查。审查模型只能看到题目和初稿，不能运行代码、查询测试结果或多轮修改。它测到的是“第二个模型读完代码后直接重写答案”的效果，不是带终端、测试和持续反馈的完整开发代理。
六种组合放在同一批题上比较
研究设置包含Claude单独作答、Codex单独作答、各自自审，以及两个方向的交叉审查。团队用相同的116道题和相同的通过标准计算完整样本，并对多重比较做了校正。
论文Table 2：Claude、Codex单独作答及四种复查条件的通过率、成本和延迟。
Claude独立作答通过106题，正确率91.4%；Codex独立作答通过83题，正确率71.6%。Claude审查Codex后通过104题，净增加21题；Codex自审后通过98题，净增加15题。两种方式都能帮助Codex初稿，但Claude审查的提升更大。
有效方向是Claude审Codex
把作者和审查者整理成矩阵后，差异更直观。Claude写、Claude审仍为91.4%，没有显著变化；Claude写、Codex审降至82.8%。Codex写、Claude审升至89.7%，Codex自审则升至84.5%。
论文Table 3：行是初稿模型，列是审查模型；同一组模型交换角色后结果明显不同。
研究者给出的工作流建议很具体：初稿来自Codex时，增加Claude审查有统计显著收益；初稿已经来自Claude时，再让Codex重写并不划算。这个判断只适用于论文使用的模型版本、题集和无执行反馈设置，不能外推到所有编程语言、代码仓库或未来版本。
审查既会修复，也会制造回退
一次审查的最终通过率掩盖了两种相反行为：审查者可以把失败答案修对，也可能把已经通过的答案改坏。Claude审查Codex时修复26题、破坏5题；Codex审查Claude时修复5题，却破坏13题。
论文Figure 1：绿色表示修复，红色表示回退；Claude审Codex的净收益最大。
论文抽查案例显示，有效修改往往保留初稿结构，只修复局部边界、状态恢复或动态规划处理；有害修改更容易大范围重写，删掉原本正确的保护条件。模型“能力更强”并不能直接推出“更适合做任何初稿的审查者”。
成本和延迟也不能从正确率里删掉。论文记录了各组合的API花费与响应时间，第二次调用会增加等待和费用；如果审查方向选错，团队承担的不只是精度回退，还有一次额外调用。更稳妥的做法，是按任务类型持续记录“修对多少、改坏多少”，而不是只看最终总通过率。
116道题都来自竞赛式函数实现，输入、输出和判题条件相对明确。真实代码审查还包含依赖、接口兼容、可维护性与安全要求，模型可能给出测试能过但不适合合并的修改。因此，这项研究回答的是受控题集中的角色分工，不是对企业代码审查流程的一次总评。
论文Table 5：被人工检查的修复与回退案例，以及审查动作造成的具体变化。
下一步要把测试工具接回审查流程
这项实验刻意禁止审查模型执行测试，以隔离单次代码阅读本身的作用。真实开发环境通常还会提供编译器、单元测试、静态分析和代码库上下文，审查者可以用反馈确认修改，而不是一次性押注重写结果。
后续更有价值的验证，是把同样的角色对照扩展到仓库级任务、更多语言和可执行测试环境，并同时记录成本、延迟与回退率。对开发者而言，当前结果足以说明一件事：增加第二个模型不是自动保险，先确定它适合审谁，比单纯多调用一次更重要。
