GitHub Copilot 获批自动 Approve PR：组织级代码评审交给 AI，团队要不要开这个权限
2026 年 9 月 1 日，GitHub Changelog 发布了一条更新：Copilot code review can now approve pull requests。管理员开启后，Copilot 提交的 Approve 会计入仓库的 required-approvals 规则，与人类签字同等效力。
这条更新在开发者社区炸了锅，但很多讨论其实没搞清楚它到底是两件事。
两个独立的能力
GitHub 这次其实加了两个功能，别混为一谈。
其一：approval assessment（仅提示）
每次 review 的 overview comment 里新增一段"批准评估"，但不计入合并要求。这只是一个参考意见，相当于 Copilot 说"我觉得这个 PR 可以合"。
其二：正式 Approve（计入合并门）
管理员开启后，Copilot 提交的是正式 Approve，计入仓库 required-approvals 规则。这才是真正有争议的部分。
默认关闭，企业级默认项为 Disabled everywhere。
三层开关怎么配
权限结构分三层，理解这个才能控制风险：
| 层级 | 配置项 |
|---|---|
| Enterprise | 可下放给组织 |
| Organization | 策略名"Count Copilot approvals toward merge requirements" |
| Repository | 两个独立开关："Allow Copilot to approve pull requests" 与 "Allow Copilot approvals to count toward merge requirements" |
关键在仓库层的两个开关是独立的。
只开第一个（Allow Copilot to approve）而不开第二个：Copilot 能提交批准，但不计入合并门——这等于沙盘演练，可以观察它的判断质量，不承担实际风险。
这个设计其实挺聪明，给了团队一个低成本的验证路径。
文件路径限制： 仓库级可以设置 glob 模式，每行一个，上限 15 个。且 PR 的全部变更文件都要命中才计入——只要有一个文件不在范围内，这次批准就不算数。
这个"全部命中"的规则很严格，实际上把 Copilot 的批准范围限制在了明确的目录里，比如只让它批准 docs/ 或 *.md 的改动。
其他机制：
- 新 commit 推送后批准自动 dismissed，与人类一致——不会出现"批准了旧代码"的问题
- public preview 阶段
- 覆盖 Copilot Pro、Pro+、Max、Business、Enterprise
前序动作和关联产品
GitHub 在这之前已经铺垫了两步：
8 月 27 日： 取消 Copilot review 的 300 文件 / 20,000 行上限，并将自动评审扩展到机器人及 Copilot cloud agent 的 PR。
这条其实比自动批准影响更大——之前大 PR 根本不受理，现在全部纳入。
关联产品 GitHub Code Quality： 已 GA（2025 年 10 月开启预览、超 10,000 家企业试用），CodeQL + Copilot Autofix 组合，$10/活跃提交者/月，不含 Advanced Security，Enterprise Server 首发不支持。GitHub 自称本组织 67.3% 的发现项在合并前修复。
争议在哪
反对声音主要集中在一点：AI 自动批准会放大既有的 LGTM 橡皮图章问题。
HN 上的讨论主基调就是这个——很多团队的代码评审本来就已经流于形式，人类 reviewer 看都不看就点 Approve。现在加一个 AI 自动批准，等于给这种形式主义加了一层自动化合法性。
一个被反复引用的案例：
2026 年 6 月 18 日，Snowflake 仓库 PR #1218（commit 4a1b8ce）引入 GitHub Actions 引号注入；6 月 23 日 Wiz Red Agent 借 issue 标题提取 Jira token，当日修复。squash commit 署名含"Copilot Autofix powered by AI"，但 GitHub 复核称漏洞代码由人类工程师编写合并、Copilot 未参与。
这个案例的说明力在于：它同时说明 AI 不是万能的，也说明把锅甩给 AI 是不准确的。
真正的问题不是 AI 会不会误批，而是团队有没有能力定义"什么样的改动可以自动批准"。
要不要开，怎么开
我的判断是：可以开，但必须限定范围，而且要走沙盘阶段。
第一步：只开第一个开关，跑 2-4 周。 观察 Copilot 的批准判断跟团队标准的一致率。如果它批准了大量你认为不该批准的 PR，说明它不适合你的代码库。
第二步：限定目录。 先用 glob 把范围限到低风险区域——docs/**、*.md、**/*.test.js 之类。让 AI 批文档和格式改动，风险极低但能省下人力。
第三步：核心代码不要开。 涉及认证、支付、数据删除、权限判断的代码，必须保留人工审批。这不是对 AI 的不信任，是对变更风险的合理分级。
第四步：配合 Code Quality。 Copilot Autofix + CodeQL 的组合已经 GA，$10/活跃提交者/月。如果团队连静态检查都没上，先上这个，别急着开自动批准。
需要明确的一点：这个功能的价值不在"省掉人工评审"，而在"把人工评审的资源集中到高风险改动上"。 如果你的团队把低风险改动交给 AI，省下的时间用来认真审高风险 PR，那这个功能就是正收益。如果只是用它来让流程"看起来更快"，那就只是在加速积累技术债。
注意事项
- 功能默认关闭，企业级默认项为 Disabled everywhere，不会自动生效。
- 仓库层两个开关独立，只开"Allow Copilot to approve"等于沙盘演练，不计入合并门。
- 文件路径 glob 上限 15 个，且 PR 全部变更文件都要命中才计入，规则很严格。
- 目前是 public preview，无 GA 时间表。
- 新 commit 推送后批准自动 dismissed，与人类审批行为一致。
- GitHub Code Quality 不含 Advanced Security，Enterprise Server 首发不支持。
FAQ
Q1：Copilot 的批准和人类的批准完全等价吗？ 在开启第二个开关后，是的——计入 required-approvals 规则，与人类签字同等效力。
Q2：Copilot 批准错了怎么办？ 人类 reviewer 依然可以拒绝覆盖。Copilot 的批准不剥夺人类的否决权。
Q3：误批率有多高？ 官方未公布误批率数据。建议先只开第一个开关跑 2-4 周，自行统计一致率。
Q4：小团队有必要开吗？ 小团队本来评审就快，收益有限。这个功能更适合 PR 量大、评审资源紧张的团队。
Q5：怎么限定只让它批准文档改动？
在仓库层设置 glob 模式（如 docs/**、*.md），且 PR 全部变更文件都要命中才计入。