你以为 Copilot 只会提意见？今天它真的把 PR merge 这件事也接过去了

九年了，Copilot 一直在做一件事：告诉你哪里有问题、怎么改。2026 年 9 月 1 日，它多了一项新技能——直接 approve 你的 PR。这件事从「提建议」跨越到了「有权力」，不只是功能更新，是 CI/CD 权限模型的一次重新定义。

这次到底加了什么

这次更新包含两个独立能力，别混为一谈：

第一，Approval Assessment（仅供参考）——每次 Copilot review 的 overview comment 里多了一段”批准评估”，说明它认为这个 PR 是否可以合并。但这段评估不计入任何合并要求，只是一个参考意见。

第二，正式 Approve（计入合并门）——管理员开启后，Copilot 提交的是正式 APPROVED 审查，计入仓库的 required-approvals 规则，和人类审核者同等效力。

三层开关怎么配

权限结构分三层，理解这个才能控制风险：

• Enterprise 层：管理员可以选择把权限下放给组织，或在企业范围内统一关闭
• Organization 层：「Count Copilot approvals toward merge requirements」开关
• Repository 层（关键）：两个独立开关

仓库层这两个开关是独立的，值得单独说：

• 只开第一个（Allow Copilot to approve）：Copilot 能提交批准，但不计入合并门——等于沙盘演练，团队可以观察 Copilot 的判断质量，不承担真实风险
• 两个都开：Copilot 的 APPROVED 才计入 required-approvals

路径限制也是这个道理——仓库管理员可以设置 glob 模式，每行一个，上限 15 个。PR 全部变更文件都要命中才生效——只要有一个文件不在范围内，这次批准就不算数。

新提交自动取消批准

这个设计很关键：如果 Copilot approve 了，之后又有人 push 新 commit，Copilot 的批准和人类审核者一样——自动被 dismiss。要重新合并，必须再发一次 review 请求。这个生命周期设计是 Copilot 审批权限最核心的安全垫。

合规框架还没说清楚

最大的未知数在这里：SOC 2、ISO 27001 这些要求「人工同行评审」的标准，是否接受 AI 签署的分支批准？还是说需要二次人工会签？目前 GitHub 官方没有给出明确答案。金融、医疗、受监管行业的工程团队在开启这个权限之前，这件事必须先问清楚自己的合规顾问。

还有一个隐患没说

自主 coding agent（Codex CLI、Claude Code、Cursor）和 Copilot Approvals 配合，如果团队在仓库层面给了宽泛权限，可能建立无人监督的 PR 创建→批准→合并循环。这个风险在审批权力下放给 AI 之前必须评估。

什么时候可以用

说了这么多风险，不是让大家不要用。正确的打开方式：

Copilot 适合处理低风险的签字：文档修改、依赖版本更新、简单的 refactor、测试用例补全。这些 PR 变化可预测、风险有限、人力审核ROI极低。

人类必须保留的场景：核心业务逻辑、加密相关代码、数据库 schema 迁移、受监管代码。

一句话：Copilot 接管机械性签字，人继续做真正需要判断的审核。

三步下一步

1. 查现有策略：去你团队的 GitHub 仓库设置里，看 Copilot Approvals 开关现在是开还是关
2. 开沙盘模式：如果没开过，先只开启「Allow Copilot to approve」看它的判断质量，积累两周数据再决定
3. 划定路径范围：如果要开正式权限，先从文档和测试文件开始，用 glob 模式限定范围