GitHub 在 9 月 1 日 的更新日志中写了两件不同的事，而它们之间的差别就是全部故事。首先： “每次 Copilot 代码审查现在都会在概览评论中包含一项 审批评估。” 其次，紧接着是： “单独的审批评估不计入合并要求。”
真正计入的机制
真正具有约束力的那个是分开的：“启用后，Copilot 可以提交一项审批，计入仓库的必需审批规则。” GitHub 表示，这一能力默认关闭，并可在企业、组织和仓库层级进行配置——管理员可以在这三个地方开启它。仓库管理员还可以“选择 Copilot 允许批准哪些文件路径”，而且该审批在失效方面与人工审批的表现相同：如果 Copilot 批准后又推送了新提交，它的审批会像审查者的审批一样被撤销。
常见说法错在何处
这两种简化说法在相反方向上都不对。“GitHub 为 AI 拉取请求审批开启了功能”夸大了对所有人实际发布的内容——真正面向所有人开启的是评估，而 GitHub 说它在合并时不计任何作用。但“它只不过是另一个审查机器人”又严重低估了它，因为一旦管理员打开开关，一个配置为只需一次审批的仓库，可以在没有任何人读过差异的情况下合并。路径白名单是唯一的结构性制动，而且它按仓库单独设置。
它落到的控制项
必需审批并不是普通设置。它是大多数工程组织向审计员出示、作为变更管理和职责分离证据的控制项，适用于 SOC 2。这也是首次有第一方 AI 审核者可以满足这一要求，而更新日志并未说明 Copilot 的审批是否可解除这一控制。这个问题现在对平台上的每一家企业都已成为现实，答案将由审计员而不是 GitHub 给出。
可用范围
该功能已在 公开预览 中推出，覆盖五种方案——Copilot Pro、Pro+、Max、Business 和 Enterprise。默认关闭在这里确实发挥作用；风险不在于发布时间，而在于第一个为了打通积压工作而在全局启用它的季度。