Claude Code 与 Codex 交叉进行代码审查是否优于单模型审查？

Claude Code 与 Codex 的交叉代码审查不一定优于单模型，顺序会改变结果。一项针对 116 道中高难度 LiveCodeBench Python 任务的受控实验发现：Claude Opus 4.7 审查 Codex GPT-5.5 草稿能显著提高通过率，反向让 Codex 审查 Claude 草稿却降低通过率。因此应按“谁写、谁审”配置流程，不能只因为用了两个模型就期待质量提升。

实验怎样隔离审查效果

研究设置六种条件：两款模型各自单独作答、两个交叉审查顺序，以及两种同模型自审。写作者先生成完整 Python 程序；审查者看到题目、初始代码和草稿，只能静态阅读，不能运行测试或查看隐藏用例，最后提交保留或修正后的程序。

所有调用使用高推理档位，最终代码由同一 LiveCodeBench 隐藏测试评估。116 个任务都在六种条件下产生有效结果，研究同时记录通过率、修复、回归、延迟和成本。这种设计能较好隔离单次审查的影响，但不等同于可运行测试、读取完整仓库的真实工程审查。

交叉审查结果为何不对称

流程	通过率	相对写作者基线
Claude 单独写	91.4%	基线
Codex 单独写	71.6%	基线
Codex 写，Claude 审	89.7%	提高 18.1 个百分点
Claude 写，Codex 审	82.8%	降低 8.6 个百分点
Codex 写，Codex 审	84.5%	提高 12.9 个百分点
Claude 写，Claude 审	91.4%	没有净变化

Claude 审查 Codex 时修复 26 个失败草稿，同时破坏 5 个原本通过的草稿，净增 21 个通过任务。反向流程只修复 3 个 Claude 失败草稿，却使 13 个原本正确的草稿回归，净减 10 个。

统计结果应该怎样表述

相对于 Codex 单独作答，Claude 审查的提升在多重比较校正后仍显著；Codex 自审的提升也显著。Codex 审查 Claude 则显著低于 Claude 单独作答。不过两个交叉方向彼此直接比较时，校正后的差异没有达到统计显著，因此不能把“两个方向绝对可分”说得过强。

论文结论针对当前模型、提示、任务样本和一次静态审查。模型输出具有随机性，竞争编程题也不能完整代表多文件重构、框架升级、UI 设计或生产故障排查。

为什么第二次模型调用可能破坏正确代码

审查者不仅给建议，而是重新输出最终程序。它可能修正边界条件和复杂度，也可能重写已经正确的逻辑、改变输入输出格式或引入新错误。审查价值因此取决于“修复数减回归数”，而不是审查意见看起来是否专业。

同模型自审也不是必然有效。Codex 自审在样本中修复 21 个并回归 6 个，净效果为正；Claude 自审各修复和破坏 3 个，整体通过率不变。已有较强草稿时，额外审查的上升空间较小，破坏风险反而更显眼。

在真实项目中如何配置流程

1. 保留写作者原始提交，不允许审查结果直接覆盖唯一副本。
2. 让审查者输出问题、证据和最小补丁，而不是无条件重写整个实现。
3. 对原稿和修订稿运行完全相同的测试、静态分析和构建矩阵。
4. 只有修订稿新增通过项且没有回归时才合并。
5. 记录每种“写者→审者”组合的修复、回归、成本和延迟。
6. 定期按真实仓库数据调整角色，不把单篇论文的顺序固化为永久规则。

净审查收益 = 修复的失败草稿数 - 破坏的正确草稿数
审查后通过率 = 通过全部验收的修订稿数 / 有效任务数
总成本 = 写作调用 + 审查调用 + 测试与人工复核

测试能力会怎样改变结论

论文刻意禁止审查者运行代码，用于测量纯静态审查。如果真实流程允许执行单元测试、类型检查和最小复现，审查者可以依据失败证据修改，结果可能不同。工具反馈也可能让同模型自修更有效，因此不能把静态实验比例直接当作代理式开发流程的预期成功率。

现有证据支持的结论是：交叉审查存在价值，但并非对称，也并非总是增益。对于论文所测组合，优先让 Claude 审查 Codex 草稿；对于 Claude 已生成的高通过率草稿，不要自动交给 Codex 重写，而应先运行测试，并只接受有证据的最小修复。