OpenAI 用 AI 自动审查工程师代码并可主动拦截

我们很高兴你在这里。你可以期待每周一至周五收到 TNS 最优质的内容，让你随时掌握最新资讯并保持最佳状态。

查收你的收件箱，确认邮件中你可以调整偏好设置，甚至加入其他分组。

在你最喜欢的社交媒体平台上关注 TNS。

在 LinkedIn 上成为 TNS 关注者。

在等待你的第一封 TNS 新闻通讯时，查看最新的精选和热门故事。

每一位 OpenAI 工程师提交的 pull request 现在都要经过自动安全审查，如果 AI 模型发现漏洞，它可以阻止代码合并。

OpenAI Codex 团队的工程负责人 Thibault Sottiaux 在最近一期 The Pragmatic Engineer 播客采访中描述了这个系统，并解释说安全审查是强制性的，不需要人类审查员来执行。

安全审查只是 OpenAI 交给模型的任务之一。他们还在审查代码、抓取回归问题、处理依赖升级，并帮助工程师处理 Sottiaux 所说的以前可能需要数月才能完成的工作。OpenAI 甚至开始将一些代码审查模型基准测试为"超越人类"。

AI 审查员阻止每一次合并

OpenAI 在 Codex 开发的早期就开始训练专门的代码审查模型。在采访中，Sottiaux 描述了能够捕捉逻辑和推理错误的模型，而人类工程师可能需要花费数小时才能发现。

"当我们对它们进行基准测试时，它们在代码审查方面就像是超越人类的，"Sottiaux 说。"这不仅仅是正确性的问题，安全也是如此。"

这些能力最初存在于独立审查模型中，后来已合并到 OpenAI 的主线模型中。对于安全性，被标记的问题会毫无例外地阻止合并。

"当我们对它们进行基准测试时，它们在代码审查方面就像是超越人类的，"Sottiaux 说。"这不仅仅是正确性的问题，安全也是如此。"

意图取代检查

随着 AI 接管更多代码审查的机制性工作，Sottiaux 认为人类的角色可能会转移到流程更早的阶段。

OpenAI 的审查、部署和回归捕获流程，用 Sottiaux 的话说，已经"几乎完全自动化"了。工程师可以在同一天将 PR 提交给 ChatGPT，他说 ChatGPT 大约为十亿活跃用户提供服务。

"我们真正看到的，我看到的，是围绕 pull request 展开的关于意图的讨论，"Sottiaux 说。"就像，你到底想要做什么？而且做这件事是正确的选择吗？"

"我们真正看到的，我看到的，是围绕 pull request 展开的关于意图的讨论。"

Sottiaux 认为这种思考需要更早进行，回到计划阶段，而不是等待进入审查队列。工程师仍然需要就目标达成一致，并对拟议的变更进行仔细检验。将审查负担转移给 AI 并不会让人脱离循环，只是把直觉检查移到了任何人打开 PR 之前。

代理处理维护积压工作

虽然安全最引人关注，但基础维护可能是工程团队最先感受到影响的地方，特别是对于第三方库推送破坏性变更并因为新功能总是优先而被一次又一次推迟的情况。Sottiaux 的观点是，只要你有一个清晰的 changelog 和像样的文档，代理可以在一个下午完成那些繁琐的更新例行安全补丁同样适用。

同样的计算方式适用于更大的重构工作。一个团队可能清楚地知道想要清理什么，甚至已经有了更好的架构思路。然而，一旦评估回来显示需要两到三个月的工程工作，就很容易理解为什么每个人都在继续绕过这个问题而不是解决它。代码可能很丑陋，但它能工作，而且总有其他需要交付的东西。

当代理能够承担大部分工作时，情况就变了。一个本应被搁置的清理工作——因为没有人能证明花一个季度来做它是合理的——可能突然只需要几天而不是几个月，这就使得说"好的"变得容易得多。

当模型超出其脚手架时

Sottiaux 描述了代理开发中一个与大多数软件演进相反的动态。

Codex 有一个名为 /goal 的命令，旨在让模型专注于单一目标数天或数周而不偏离。作为一个"拐杖"（Sottiaux 自己的话），用来弥补模型在长期任务中容易丢失线索的倾向，但更新的模型不再需要它。

"你不再需要 slash goal 了。你不需要围绕它的马甲了，"Sottiaux 说。

Codex 团队经常需要在模型周围构建额外的基础设施来弥补它还不能做的事情，结果却发现下一代模型本身就能处理相同的行为，他们为前一个模型构建的代码就不再需要了。

Sottiaux 说团队现在将此纳入规划，有时如果研究人员预计下一个模型在几个月内自己就能解决问题，就会决定不构建变通方案。随着模型的改进，系统提示词和围绕它们的代码可以变得更小，而一度看起来必要的部分产品功能会完全消失。

盲点问题

如果 AI 编写更多代码，而 AI 审查这些代码，两个系统可能共享相同的盲点。这是显而易见的反对意见，而 Sottiaux 的采访并没有完全回答这个问题。

OpenAI 对这些模型有足够的信任，让它们能够阻止 pull request，这使得它们的错误以一种非常实际的方式产生影响。如果模型过于谨慎，工程师最终会等待本没问题的代码通过。如果它漏掉了一个真正的漏洞，那段代码可能会在自动化安全审查给每个人相信它安全无虞的理由下继续前进。

随着 AI 生成代码的激增，工作也变得更加复杂。代码可以编译、通过测试，但仍然可能有问题是从 pull request 本身看不出来的。其中一些问题可能甚至不是来自工程师正在提交的代码。当供应链是攻击面时，弱点可能是一个几周或几个月前就被入侵的依赖，让 PR 审查员去 catch 一个源自别处的问题。

代码可以编译、通过测试，但仍然可能有问题是从 pull request 本身看不出来的。