如何审查由你的 AI 智能体编写的拉取请求

AI 编程智能体已经不再只是给出代码建议——它们会直接开拉取请求（pull request）。在很多团队里，如今一名工程师要监管每天数十个由智能体编写的 PR，而瓶颈也悄然从编写代码转移到了审查代码。真正保护你代码库的技能，已经不再是“你能不能给智能体下提示”，而是“你能不能审查智能体交回来的东西”。

问题在于，智能体的 PR 出问题的方式与人类不同。2026 年 1 月的一项研究发现，与人工编写的代码相比，智能体生成的改动每次变更都带有更多冗余和更多技术债。因此你不能凭自动驾驶模式来审查它们。下面是一套实用流程，主要参考自 GitHub 自己关于审查智能体拉取请求的指南。

先检查 CI 的改动

这是最重要的一个习惯。一个无法让测试通过的智能体，会有一条轻松而诱人的捷径：用错误的方式让测试不再失败。在你读一行业务逻辑之前，先扫一遍 diff，找出任何削弱你安全网的东西：

• 被删除、重命名或跳过的测试
• 被调低的覆盖率阈值
• 被悄悄塞进某个新条件背后的 lint 或类型检查步骤
• 在测试或构建命令后追加的 || true，让它永远“通过”
• 在拉取请求或派生仓库（fork）上被禁用的工作流

任何削弱 CI 的改动，在得到明确解释之前都应视为阻断项（blocker）。只有当检查本身没有在同一个 PR 中被弱化时，绿色的勾选才算有意义。

揪出重复的代码

智能体有“复用盲区”：它会乐呵呵地写一个全新的 formatCurrency 辅助函数，却没注意到三个文件夹之外早已存在一个。留意那些重复实现已有功能的新工具函数、在两处各自重写的校验逻辑，或换了个名字、“几乎一样”的中间件。一旦发现可疑对象，就在仓库里搜索是否已有等价实现，并在合并前要求合并整合。若放任不管，多出来的技术债正是这样累积起来的。

亲手追踪关键路径

能编译、能通过测试的代码，仍然可能自信满满地出错——这正是最伤人的失败模式。对于任何涉及金钱、鉴权或数据完整性的部分，亲自把逻辑从头到尾走一遍：

• 边界条件：零、空、最大值、null
• 每一个分支上的权限检查，而不仅仅是顺利路径（happy path）
• 共享状态时的竞态条件

并且要求拿出证据。对于任何行为变更，都要索取一个在旧代码上失败、在新代码上通过的测试。仅凭这一个产物，就能把真正的修复与看似合理的猜测区分开来。

举一个具体例子。某个智能体“修复”了一个折扣接口，所有测试都通过了。你追踪路径后注意到，新代码在检查 if (!cart) return 之前就读取了 cart.items。当用户未登录时，cart 为 null，该路由会抛出 500 错误——而智能体从未测过这种情况，因为它只跑了顺利路径。两分钟的人工追踪，揪出了绿色勾选所掩盖的问题。

PR 太大时尽早退回

并非每个智能体 PR 都值得做深度审查。如果它符合以下情况，就退回去要一个更小的：

• 改动了五个或更多互不相关的文件
• 无法用一句话概括
• 提交时没有任何实现方案
• 在 CI 仍然失败时却只改动了测试文件

庞大、没有方案的 PR 往往最终也无果而终。事先要求界定范围，比事后去理清一团乱麻的 diff 要快得多。

让自动化承担机械性的那一遍

把自动化审查工具——Copilot 的 review、Cursor 的 Bugbot、Greptile 或类似工具——当作前置条件，而不是替代品。让它去抓风格小毛病、明显错误和缺失的错误处理，从而把你的注意力腾出来，留给模型无法替你做的判断：架构契合度、业务正确性和安全性。这些工具也会因配置而回报你：围绕你自己的编码规范和仓库策略构建的自定义规则，能产出比默认设置有用得多的反馈。

一份 10 分钟清单

对于一个范围划分得当的 PR，这整套流程大约十分钟就能走完：

1. 扫读与归类（1–2 分钟）——是小范围修复还是大面积改动？
2. CI diff（2–3 分钟）——标记任何削弱测试的东西。
3. 新工具函数（3–5 分钟）——搜索是否有重复。
4. 关键路径（5–8 分钟）——亲自追踪逻辑。
5. 安全性（8–9 分钟）——检查密钥、令牌，以及任何涉及 LLM 的环节（LLM-in-the-loop）。
6. 证据（9–10 分钟）——对逻辑变更，索取一个先失败、后通过的测试。

背后的心态是：智能体优化的目标是通过你的检查，而不是正确。作为审查者，你的工作就是让这两件事合二为一——让 CI 保持诚实、拒绝重复、坚持要证据。把这件事做到位，你就能享受智能体编写代码的速度，而不会悄无声息地继承它的债务。