Signal #28：AI 开始批准代码合并了

9 月 1 日，GitHub 宣布 Copilot 可以正式批准 PR，也就是代码合并请求。管理员授权后，这份批准可以计入仓库要求的审批数量。AI 的评审判断开始对代码能否合并产生正式效力。

功能仍在公开预览，默认关闭，可以限定文件路径。AI 批准后，实际合并仍需满足仓库的其他要求。

这让 AI 编程多了一个值得认真讨论的问题：当 Agent 同时参与实现和评审，后面的批准，能否发现前面的遗漏？

设想一次接口改造：需求要求调整返回字段，却漏写了“继续兼容旧客户端”。实现 Agent 按新字段修改代码，评审 Agent 对照同一份说明检查。如果测试也只覆盖新字段，整个流程就可能顺利通过，旧客户端却读不到原来的数据。

两个 Agent 看起来都完成了任务，却可能共同遗漏同一个要求。

多一个评审 Agent，不自动等于多一份独立的验证依据。 再读一遍代码、再生成一份评审意见，并不能保证补上需求和测试里的缺口。

评审需要能检验实现的材料。在这个例子里，已有调用方的信息、兼容性约定，以及保留下来的旧客户端测试，都比单纯增加一个“通过”更有帮助。这同样适用于人工评审；当批准开始自动化，这些依据也需要成为 Agent 能够获取和使用的输入。

此前，Vercel 的 AI SDK 软件工厂提供了一个具体案例。AI SDK 是一套开发 AI 应用的工具库，团队让不同 Agent 分别验证问题、实现功能和评审变更。

为搜索工具增加域名屏蔽能力时，Agent 先运行探测程序，确认现有实现缺少这项能力；完成修改后，再实际调用接口验证屏蔽效果，把结果附在 PR 中。评审 Agent 检查完成情况和风险，维护者最后阅读证据、审阅代码并合并。

评审者拿到的，是可以回头检查的实现过程和运行结果。 它们让“为什么通过”有了具体内容，也便于发现某项验证覆盖了什么、还遗漏了什么。

Vercel 仍由人最终合并，并按风险分配审查精力：文档修正快速核查，明确的适配变更重点验证，新增公共接口深入评审。这个案例说明，自动化可以围绕人的判断推进，同时把判断所需的材料准备得更充分。

提交之后的执行工作也在继续自动化。VS Code 的 Agent Merge（预览版）会处理评审意见、失败检查和合并冲突，持续推进到 PR 可以合并的状态。它负责把变更准备好，Copilot 的新功能则让团队能够授权 AI 正式批准。

把这些变化放在一起看，研发自动化正延伸到变更审批。团队除了决定让 Agent 做哪些工作，还需要决定在哪些范围内接受它的判断。

我的判断是，授权可以从影响明确、验收依据充分的变更开始。比如，文档示例修正已有对应测试，可以考虑有限授权；涉及公共接口兼容性的修改，则需要更多调用方信息和验证，必要时保留人工评审。

AI 的批准可以计入流程，团队对它的信任则需要来自验证。 每扩大一类授权范围，都应能够说明：这类变更为什么值得被接受。