翻译：OpenAI：A Practical Approach to Verifying Code at Scale

原文：A Practical Approach to Verifying Code at Scale ↗

作者：Maja Trębacz, Sam Arnesen, Albin Cassirer, Max Johnson, Xin Lin, Thibault Sottiaux，与 Codex 团队其他成员合作

发布日期：2025年12月1日

随着自主协作编码系统的普及，产生的代码量迅速超出了人类详尽审查的能力范围。随着这一差距的扩大，AI 编写的代码引入严重 bug 和漏洞的风险也在增加——无论是意外还是故意的。

我们不能假设代码生成系统是可信或正确的；我们必须检查它们的工作。自动化代码审查是一种实用的输出监控器，作为纵深防御策略的一部分，它与思维链监控 ↗、动作监控、内部激活监控 ↗、行为测试 ↗、诚实性训练和其他安全工作相辅相成。

在这篇文章中，我们分享了作为 gpt-5-codex ↗ 和 gpt-5.1-codex-max ↗ 一部分训练专用智能体代码审查器所学到的经验¹。我们讨论了赋予审查器仓库范围的工具和执行访问权限如何同时提高召回率和精确率，以及部署时的考量如何引导我们走向高信号、最小对齐税的设置。这些想法并非理论：在 OpenAI 内部，每个 PR 都会被自动审查，许多工程师在推送代码前会在 Codex CLI 中运行 /review ↗，该模型已经保护了高价值实验并捕获了阻塞发布的问题。

精确率比召回率对可用性更重要#

防御措施失败往往不是因为它们在技术上是错误的，而是因为它们太不实用，以至于用户选择不使用它们。一个缓慢、嘈杂或笨重的系统会被绕过。在部署代码审查智能体时，我们明确接受了一个经过测量的权衡：以适度降低召回率换取高信号质量和开发者信任。我们首先优化信噪比，然后才在不损害可靠性的前提下提升召回率。

代码审查器可以尝试标记提议的代码变更中存在的每一个可能问题。在实践中，许多”问题”是误报或误解用户意图的结果。我们希望看到一个提议的 bug 发现的预期收益超过验证它的预期成本和误报造成的损害。也就是说，我们希望发现能够最大化以下公式的结果：

$P(\text{正确}) \times C_{\text{节省}} - C_{\text{人工验证}} - P(\text{错误}) \times C_{\text{误报}}$

技术上正确但更多属于风格性质的评论甚至可能产生负效用（例如，在个人研究笔记本中指出评论拼写错误可能不值得）。

虽然我们对精确率和召回率的正确平衡做出了有主见的猜测，但我们认为允许这种权衡和其他指南通过自定义任务指令或包/仓库级别的 AGENTS.md ↗ 规范进行调整是很重要的。

精确率-召回率帕累托前沿

图1. 在发现真实 bug（召回率）和避免对虚假问题发表评论（精确率）之间存在权衡。我们可以用不同的开发者指南来引导模型，范围从”只输出最关键和确定的破坏性问题”到”尽可能分享更多发现”。GPT-5.1-Codex 同时提高了召回率和精确率，相比具有特殊脚手架和仓库访问权限的 GPT-5。

仓库范围的工具和执行是必要的#

早期的研究（例如 CriticGPT ↗，2024年6月）塑造了我们的方法，但它是为更简单的任务设计的，不适合实际部署。这个审查器添加了推理、工具使用、仓库级上下文以及精确率/延迟目标，以达到采用门槛。之前大多数代码审查的尝试依赖于仅向模型提供变更的 diff 以及可选的简短周围上下文。这导致了最快的审查时间。然而，它经常遗漏关于整个代码库以及变更与其依赖项交互的重要上下文。

我们评估了向 GPT-5 模型提供仓库访问和代码执行能力，发现这会产生更强的审查器，能够捕获更多关键问题并减少误报。专门针对代码审查的训练进一步改善了结果。

图2. 对流行开源仓库最近提交的代码审查性能的人工评估。专门为更高信噪比训练的 GPT-5-Codex 做出的评论更不可能是错误的或不重要的，为关键问题保留用户注意力。使用默认提示且仅访问 PR diff 上下文时，GPT-5 能够识别大量高影响评论，但也产生大量误报。

你训练的奖励模型并不完全是你应该发布的审查器#

训练时的验证和面向人类的审查可能看起来相似，但它们解决的是根本不同的问题，因此需要不同的设计。在训练代码生成模型时，我们依赖自动化检查来大规模减少错误，优先捕获尽可能多的潜在错误，而不是避免误报。这些奖励模型过度敏感是可以接受的。这些训练时检查还可以使用关于任务的额外信息，允许它们强制执行精确的指令遵循，而无需推断开发者的意图。部署的代码审查具有相反的优先级。审查器必须处理由人类或人机工作流产生的模糊、真实世界的代码，通常具有不完整的规范和不断演变的惯例。它必须避免过度断言意图，在不同语言和领域保持稳健，最重要的是，建立用户信任。

对两种设置使用单一验证器会导致两者都失败。如果生成器在训练期间过度优化以取悦奖励信号，它可能会学习到损害下游审查质量的行为，例如过于谨慎或程式化的输出，这会让用户感到沮丧。因此，我们将训练上下文感知的审查器视为 Codex 训练中的一个单独任务，专为人类工作流设计，并密切监控其对 Codex 生成本身进行评分的有效性。

验证可以比生成更便宜#

我们观察到自动化代码审查器在识别人类和 Codex 生成的 PR 中的错误方面都很有效。Codex 代码审查对完全由 Codex cloud 生成的 36% 的 PR 发表了评论。在这些评论中，46% 导致作者修改代码。相比之下，人类生成的 PR 上的评论有 53% 导致代码修改。

我们可以利用生成和验证之间的推理时差距。生成正确的代码变更通常需要广泛的搜索和大量 token，而证伪一个提议的变更通常只需要有针对性的假设生成和检查。

为了进一步研究验证-生成差距与推理预算的关系，我们进行了一项对照研究，其中我们从之前一代强大的代码审查模型中获取之前经过人工验证的评论，并扫描代码审查器的推理预算。即使在生成器 token 支出的一小部分预算下，验证器也能捕获 PR 作者确认的大部分先前识别的高严重性问题，额外的预算主要改善了校准并减少了误报。然而，我们也观察到，与人类编写的代码相比，审查模型生成的代码时，性能随思考预算下降得更快。这个评估有局限性，因为测试集只包含人类已经识别的问题。如果审查器在给予更多时间时提出新的见解，这个评估无法在没有额外人工输入的情况下告诉我们这些发现是否正确。

图3. 自动审查器（GPT-5.1-Codex）在 Codex 生成的（左）和人类编写的（右）代码上的召回率作为推理预算的函数，在 OpenAI 代码库中之前识别的问题集上评估。即使在较低预算下，验证器也能恢复相当比例的已知问题，在人类编写的代码上恢复率始终较高，表明验证难度存在潜在的分布偏移。

由于 Codex 代码生成器和代码审查器是执行不同任务的同一底层模型，我们预期它们的原始智能会随时间并行增长。我们密切关注在推理时是否存在真正的验证优势，以及模型是否学会微妙地博弈或规避自己的检查。对此没有干净的直接测量，所以我们依赖实际的代理指标，比较审查器在 Codex 生成的 PR 与人类编写的 PR 上提出可操作问题的频率，同时承认分布偏差。到目前为止，审查器保持类似的有效性，表明监督没有被显著削弱。

从部署中学到的#

在内部和外部 GitHub 流量上部署审查器对于将一个强大的实验室原型转变为在实际工程约束下可靠的安全层至关重要。代码审查模型现在是 OpenAI 工程工作流的核心部分。当审查器留下评论时，作者在 52.7% 的情况下通过代码修改来处理它（通常由 Codex 协助），表明系统持续提出可操作的问题。审查器已经帮助验证了高风险实验，防止了阻塞发布的问题，并避免了多个关键故障。

过度依赖是一个严重的风险。团队可能开始将干净的审查视为安全保证，而不是作为防御的一层。我们希望人们理解审查器是一个支持工具，而不是谨慎判断的替代品。令人鼓舞的是，我们看到合并的 PR 后来需要 bug 修复跟进工作的情况减少了，这与审查器帮助减少逃逸缺陷而不是简单地转移工作量相一致。

截至 2025 年 10 月，系统每天处理超过 10 万个外部 PR，以及通过 /review ↗ CLI 触发的内部 PR 前检查，这些检查通常在问题到达 GitHub 之前就捕获了它们。真实世界影响的早期信号是有前景的，超过 80% 的评论反应是正面的。

外部部署不仅重要因为它提供了广泛可访问的安全收益，还因为它在真实世界分布偏移下测试研究假设。它给我们提供了离线评分无法提供的结果信号，并帮助确保实验室中的改进转化为实践中的改进。

结论#

随着自主代码生成成为日常工程的一部分，监督必须围绕真实工作流来塑造。安全需要采用，所以我们优化审查器以实现低安全税和高精确率，赢得用户信任。我们的结果表明，具有工具访问权限的仓库感知审查器可以提供可靠、高信号的反馈，而不会拖慢团队。这项工作不是为了准备遥远的未来。内部部署已经发现了真正的生产缺陷，并暴露了我们之前可信数据集中的评估不一致性。我们看到在人因研究方面有丰富的下一个前沿，即审查器和监控器应该如何与开发者互动、加强工作流，以及避免脆弱或对抗性动态。保持人类控制是我们对齐哲学的核心，随着模型成为更强的生成器，它们验证、批评和支持人类判断的能力必须与之同步扩展。训练有能力的审查器是保持这种平衡的一步。

想要尝试 Codex 代码审查吗？#

在 Codex CLI ↗ 中使用 /review ↗，或将你的 GitHub 仓库连接到 Codex Cloud，然后在 Codex 仓库设置中打开代码审查 ↗。启用后，Codex 可以自动审查 PR，或者你可以随时通过在 pull request 上评论 “@codex review” 来召唤它。

Codex 的”代码生成器”和”代码审查器”是同一个模型。但用于教授这两种技能的训练方法不同。 ↩