OpenAI 分享大规模代码验证的实践方法

2025年12月1日 · Maja Trębacz, Sam Arnesen, Albin Cassirer, Max Johnson, Xin Lin, Thibault Sottiaux，
与 Codex 团队其他成员合作

随着自主协作编码系统的激增，所产生代码的数量很快就超出了人工进行彻底审查的极限。随着这一差距不断扩大，AI 编写的代码引入严重缺陷和漏洞的风险也随之增加——无论是有意还是无意。

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

在这篇文章中，我们分享了在训练一个专用的、具备智能体能力的代码审查器过程中所获得的经验，该审查器是 gpt-5-codex 和 gpt-5.1-codex-max^[1] 的一部分。我们讨论了为审查器提供覆盖整个仓库的工具和执行权限如何同时提升召回率和精确率，以及部署时的考量如何引导我们走向高信噪比、对齐税最小的设置。这些想法并非纸上谈兵：在 OpenAI 内部，每个 PR 都会被自动审查，许多工程师在推送前会在 Codex CLI 中运行 /review，该模型已经保护了高价值实验，并捕获了会阻碍发布的问题。

对于可用性而言，精确率比召回率更重要

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

代码审查器可以致力于标记所提议代码变更中存在的每一个可能问题。在实践中，许多“问题”是误报，或者是误解用户意图的结果。我们希望看到所提议缺陷发现所带来的预期收益，超过验证它的预期成本以及误报造成的损害。也就是说，我们希望发现能够最大化：

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

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

虽然我们对精确率和召回率的正确平衡做出了带有主观判断的猜测，但我们认为，允许通过自定义任务指令或包级或仓库级的 AGENTS.md 规范来引导这一取舍及其他准则，是非常重要的。

仓库级工具与执行是必要的

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

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

你训练的奖励模型并不完全等同于你应该发布的审查器

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

对两种场景使用同一个验证器可能会导致两者都失败。如果生成器在训练期间过度优化以迎合奖励信号，它可能会学到损害下游审查质量的行为，例如过于谨慎或风格化的输出，从而让用户感到沮丧。因此，我们将训练上下文感知的审查器视为 Codex 训练中的一项独立任务，专为人类工作流设计，并密切监控其在评估 Codex 生成内容本身时的有效性。

验证可以比生成更便宜

我们观察到自动代码审查器能够有效识别人类和 Codex 生成的 PR 中的错误。Codex 代码审查对完全由 Codex cloud 生成的 PR 中的 36% 发表了评论。在这些评论中，46% 导致作者进行了代码更改。相比之下，对人类生成的 PR 的评论中这一比例为 53%。

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

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

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

我们从部署中学到了什么

在内部以及外部 GitHub 流量中部署该审查器，对于将强大的实验室原型转变为真实工程约束下可靠的安全层至关重要。代码审查模型现已成为 OpenAI 工程工作流的核心部分。当审查器留下评论时，作者在 52.7% 的情况下会通过代码更改来解决该问题（通常由 Codex 协助），这表明该系统能够持续发现可操作的问题。该审查器已帮助验证高风险实验、防止阻碍发布的问题，并避免了多起严重故障。

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

截至 2025 年 10 月，该系统每天处理超过 10 万个外部 PR，此外还有通过 /review CLI 触发的内部预 PR 检查，这些检查通常能在问题到达 GitHub 之前就将其捕获。实际影响的早期信号令人鼓舞，超过 80% 的评论反应是正面的。

外部部署之所以重要，不仅因为它提供了广泛可及的安全收益，还因为它在真实世界的分布偏移下检验研究假设。它为我们提供了离线评分根本无法提供的结果信号，并有助于确保实验室中的改进能够转化为实践中的改进。

结论

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

脚注

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

BibTeX

@misc{trebacz2025verifyingcodeatscale,
  title = {A Practical Approach to Verifying Code at Scale},
  author = {Trębacz, Maja and Arnesen, Sam and Cassirer, Albin and Johnson, Max and Lin, Xin and Sottiaux, Thibault},
  year = {2025},
  month = {Dec},
  howpublished = {OpenAI Alignment Research Blog},
  url = {https://alignment.openai.com/scaling-code-verification/}
}