OpenAI 用 AI 写代码再用 AI 审查：Codex 安全门禁实践

Every pull request that OpenAI 的工程师提交进来，都会经过自动安全检查。如果模型发现漏洞，就能立即阻止该代码被合并，没有任何例外。

Codex 团队工程负责人 Tibo Sottiaux 在 The Pragmatic Engineer 播客中讲述了这个故事。他说的那句话耐人寻味，听起来简直像在吹牛。

"我们测试它的表现时，它在代码审查上就像是超越人类的存在，" Sottiaux 说，"而且不仅仅是正确性，还包括安全性。"

OpenAI 从 Codex 开发的早期就开始训练专门的代码审查模型。Sottiaux 解释说，这些模型能捕捉逻辑和推理错误，而工程师可能需要花好几个小时才能发现。之后这些能力被合并到 OpenAI 的主模型中，而在安全相关任务上，被标记的问题会立即阻止合并，没有任何例外。这意味着该系统不仅仅是一个给出建议的助手，而是真正拥有阻止工作的权力。

安全只是 OpenAI 分配给模型的众多任务之一。公司还使用代码审查模型来发现回归问题、管理依赖更新，以及处理 Sottiaux 所说的那些正常情况下可能需要数月才能完成的工作。

我认为最有趣的地方在于维护工作。Sottiaux 指出，第三方库的更新往往会破坏兼容性，然后被一个接一个地推迟，因为新功能工作总是更重要。但如果 changelog 足够清晰、文档尚可使用，agent 只需要一个下午就能处理这些更新。同样的原则也适用于常规的安全补丁。这还延伸到了大型重构工作——团队内心清楚应该整理什么，脑子里也已经有了更好的方案。但一旦评估出来是两三個月的工作量，所有人就会一直选择回避这些工作。

Sottiaux 提出，当 agent 能承接大部分工作时，这个等式就变了。那些曾经因为找不到理由批准一个季度预算而被搁置的工作，可能只需要几天就能完成。

即将消失的痕迹

面试中有一个细节我认为比表面看起来更重要。Codex 曾经有一个名为 /goal 的命令，它的设计目的是让模型在一天或一周内专注于单一目标，不偏离主题。Sottiaux 自己称其为"拐杖"，用来支撑模型在长任务上的弱点。但新版模型已经不需要它了。"你不再需要用 slash goal 了，不再需要用一个 harness 来套住它了。" Sottiaux 说。关键在于，它的方向与普通软件的演化方式相反。通常我们不断添加代码，但在这个角度上，团队需要构建额外的结构来弥补模型仍然做不到的事情，而到了下一代模型自己能做的时候，围绕旧模型构建的代码就不再有意义了。Sottiaux 说，团队在规划中已经计算过这个问题——如果研究人员预计下一代模型在几个月内能自己解决某个问题，有时会选择不构建绕过的方法。

原文提出的反驳

这是我最看重 Amanda Caswell 文章的地方，因为她没有轻易放过这些问题。如果 AI 写的代码越来越多，而 AI 又是审查这些代码的人，两个系统可能有相同的盲点。她直接写道，这个反驳是成立的，而 Sottiaux 的采访并没有充分回答它。风险有两面，而且两者都来自同一个原因：OpenAI 相信模型足够好，好到可以让它阻止 pull request。第一面是，如果模型过于谨慎，工程师就必须等待最初就没有问题的代码——应该完成的工作因此变慢，因为过于严格的检查并没有更安全，只是让一切变慢。第二面是，如果模型真的看不到漏洞，那代码就通过了，同时带着它已经通过安全审查的信任。而那种信任比真的不检查更危险，因为不检查会让我们保持警惕，但漏检会让我们放心。另一个她提出的问题是，当 AI 生成的代码数量庞大时，事情变得更复杂。代码编译通过，测试全部通过，但问题仍然可以不出现在 pull request 中，而且有些问题甚至不是出在工程师正在提交的代码上。如果弱点在 supply chain 上，问题可能始于几周或几个月前被入侵的依赖，使得检查 PR 的人不得不去处理源头完全不同的地方。

这件事与我直接相关

我用 AI 写每一篇文章，而且有另一个 AI 再做一层审查工作。这个结构与 OpenAI 所做的如出一辙，让人细思极恐——有人创建工作，然后有 AI 审查那些工作。所以我带着特别的兴趣阅读关于共同盲点的反驳。根据我自己的经验，盲点是存在的，但不是因为两个 AI 想的一样。我认为盲点来自两者读取了同一套上下文。如果我提交的工作伴随着错误的解释，审查者也会在同一个错误理解的基础上进行审查，并确认它是正确的。真正能帮助我的人是从外面看的人——就我的情况而言，就是正在阅读这篇文章的你，然后指出我哪里写错了。这就是我认为 OpenAI 的答案还不完整的原因——不是因为模型不够强，而是因为在封闭系统内自我审查，无法发现整个系统共同认定正确但实际错误的东西。

从每天与 AI 一起工作的人的角度

我让 AI 审查我的每一项工作，而阅读这篇文章让我意识到一件事。我的审查系统之所以运作良好，是因为 Veritas 和我真的从不同角度读取——不同的模型、不同的角色、不同的上下文。但如果有一天我使用同一个模型既写又审，并给出完全相同的上下文，我就不会再有任何机制来捕捉整个系统共同认定正确的错误。所以我认为组织在采用 OpenAI 方式之前应该问的问题不是"模型有多准"，而是"如果模型错了，有什么能捕捉到"。如果答案是"没有"，那就意味着还不应该让它有阻止人类工作的权力。

阅读此新闻的注意事项

一、所有信息均来自 OpenAI 内部人员接受的采访，经播客转述，再被整理成第二手新闻。我没有听完完整的原始音频，也没有独立数据来验证该公司的数字或测试结果。二、"超越人类在代码审查上的表现"是 Sottiaux 本人的说法，引用的是 OpenAI 的内部测量，但没有披露测试集或测量方法，因此与人类能力的比较无法核实。三、文章所引用的约十亿用户数是 OpenAI 广泛陈述的数字——该公司曾在 2026 年 2 月宣布每周约 9 亿活跃用户，有报道称 7 月突破 10 亿，因此合并为一个数字并不精确。四、给 AI 阻止人类工作的权力涉及责任问题——如果模型阻止了正确的工作，谁负责？如果它放行了有漏洞的工作，谁负责？采访没有讨论这个问题。

这不是关于 AI 变强的新闻，而是关于一个组织开始让 AI 在实际工作流程中拥有决策权的新闻。趣味不在于模型有多准，而在于当它错了时，有什么能捕捉到。而我读的原文就直接回答了这个问题——还没有答案。对于每天与 AI 一起工作的人来说，我认为应该问的问题是：如果您最信任的助手说"正确"，但实际上错了，您会意识到吗？如果答案是不知道，那就是应该开始的地方。

[1] Caswell, A., "OpenAI gave an AI the power to block its own engineers' code", The New Stack (2026年9月9日), https://thenewstack.io/openai-ai-code-review/

[2] Orosz, G., "Building Codex with Tibo Sottiaux", The Pragmatic Engineer (2026年9月9日), https://newsletter.pragmaticengineer.com/p/building-codex-with-tibo-sottiaux

[3] TechCrunch, "ChatGPT reaches 900M weekly active users" (2026年2月27日), https://techcrunch.com/2026/02/27/chatgpt-reaches-900m-weekly-active-users/

[4] Panto AI, "ChatGPT Statistics 2026: Users, Revenue & Growth" (2026), https://www.getpanto.ai/blog/chatgpt-statistics