如何 review AI 编程 agent 提交的 PR

先看改动范围。如果 PR 很大，先把它拆开，再去逐行争论。GitHub 的代码审查指南明确推崇更小的、按依赖顺序拆分的块，因为审查在更小的逻辑单元中进行，结果也更准确。这一点对 AI Agent 更为重要，因为它们能快速产出大量改动，而大量改动更难理清。

然后把 PR 当成故事来读，而不是当成文件清单来过。问自己：它解决什么问题？触动了系统的哪些部分？做了哪些假设？麻烦的地方在于，AI Agent 产出的代码可能看起来很整洁，却可能在不同文件间隐藏着行为缺陷、遗漏边缘情况，或者实现与原本要解决的问题之间根本不匹配。OpenAI 的 Agent 安全指南说，要让 Agent 保持在清晰的技术边界内，并保留日志以便审计它的行为。这也是一种很好的审查思路：先约束爆炸半径，再检查发生了什么。

不要先写评论。先做验证。跑掉用改动路径的相关测试，如果仓库有 lint、类型检查、安全扫描或构建检查，也一并跑。GitHub 的审查页面说，跑那些重要的检查。OpenAI 的工程指南说，AI 代码审查能给你信心，相信自己不会交付重大 bug，但当它发现真正的问题时，并不会让流程自动变快。

先审查风险最高的部分。如果 Agent 动到了认证、计费、权限、迁移、删除、重试、并发，或者任何可能静默失败的东西，先检查这些 diff，再去看样式改动。GitLab 的审查指南在路由逻辑密集型改动时也做了同样的实际区分。这是人们常犯的错误：把时间花在命名和格式上，因为这些容易看到，然后就漏掉了真正的故障模式。

把 AI Agent 当成二审，而不是权威。在 GitHub 上，可以从 PR 侧边栏请求 Copilot 代码审查，也可以设置为自动审查。它的评论对人类可见，但 Copilot 在该线程中看不到人类的评论。这意味着工作流是单向的：让 Agent 给你做第一轮扫荡，然后你来判断它的反馈是否有价值。

如果用 GitHub，像请求其他审查者一样请求 Copilot，然后把它的评论当成提示，而不是裁决。GitHub 的文档在侧边栏展示了审查请求，以及用 GitHub CLI gh pr create --reviewer @copilot 的路径。GitHub 公开的代码审查页面也将 Copilot 定为另一双眼睛，与团队的判断并列。

如果用 GitLab 或 Bitbucket，具体机制不同，但审查姿态是一样的。GitLab 允许在合并请求上请求审查，并选择评论是立即发布还是作为审查的一部分。Bitbucket 支持代码建议、任务和文件的已查看状态，并且在有新提交更改已审查文件时会重置已查看状态。最后这个行为很有用，因为它强制你重新打开在标记完成后又有改动的文件。

人们常犯的另一个错误是表面信任 Agent，然后跳过合并风险。AI 审查能捕获明显的问题，但它不会承担最终的合并决策，也不会理解你的产品约束——除非那些约束已经被编码到测试或检查中。OpenAI 的工程指南说得很明确：工程师可以把初始代码审查委托给 Agent，但最终的审查和合并流程仍然由工程师自己负责。

一个实用的顺序是这样的：

打开 PR 并阅读摘要。

先检查改动的文件，再看测试，最后看依赖或配置改动。

本地或 CI 中运行相关检查。

如果平台支持，让 AI 审查者做第一轮扫荡。

针对每条评论，对照代码和产品需求进行核实。

在设计、风险或测试覆盖缺失的地方留下人类评论。

只有当你能自己解释这个改动时，才批准合并。

如果出了问题，优先用小的修正提交，而不是试图在原地抢救一个巨大的 AI 生成 PR。GitHub 的审查模型支持请求更改、评论和批准。Bitbucket 也支持任务，这些任务可以作为作者的操作清单。实际上，明确的行动项比"看起来不太对"这种模糊反馈要好得多，因为下一个读到审查意见的人能清楚地看到还有什么阻塞了合并。

还要记住一件事：AI 生成的代码仍然可能引入有漏洞的模式、密钥和依赖问题。GitHub 的 Copilot 编码 Agent 材料直接说明了这一点。所以即使改动通过了 AI 审查，安全、数据处理和集成行为仍然需要真正的审查。这不是多余的仪式，而是防止一个看起来干净的 diff 变成一次糟糕部署的关键环节。

如果你的团队刚接触这种方式，定一条简单的规则：AI 可以起草、预审和总结，但批准权在人类。这样保持工作流快速，同时不假装 Agent 需要承担责任。OpenAI 关于编码 Agent 的指南说要保持清晰的技术边界，并把控制权交回给用户。这同样是这里正确的默认值。

对于想要一个基线检查清单的团队，最简版本是：阅读 diff、运行检查、审查风险最高的文件、让 AI 审查者做第一轮扫荡，然后你自己做合并决策。任何少于这些的，通常只是在审查最容易审查的部分。

我应该在看 PR 之前让 AI Agent 审查自己的 PR 吗？

如果平台支持，是的，因为它能提前捕获明显的问题。但要把那次审查当成基线检查，而不是批准。

AI 生成的 PR 中应该先检查哪些文件？

先看认证、权限、迁移、删除、重试、并发、配置和测试。这些地方即使 diff 看起来整洁，仍然可能隐藏真正的 bug。

如果 AI 审查者说改动没问题，我还需要人类批准吗？

需要。最终的审查和合并决策仍然属于人类，因为 Agent 不承担产品风险。

最快的安全审查大型 AI 生成 PR 的方式是什么？

把它拆分成更小的、按依赖顺序的改动，然后每个块分别用检查和上下文来审查。更小的 PR 更容易验证，也更容易回滚。

---

Code review and pull requests | GitHub

Using GitHub Copilot code review - GitHub Docs

Pull request reviews - GitHub Docs

Running Codex safely at OpenAI

Building an AI-native engineering team

Review code in a pull request | Bitbucket Cloud | Atlassian Support

最初发表于 devconnectplatform.com，并在该处保持更新。