Copilot可以批准PR了：默认关闭，也能计入合并门槛

GitHub于2026年9月1日将Copilot code review的Pull Request批准能力带入公开预览。GitHub变更公告 显示，Copilot现在会在每次代码审查中给出审批评估；管理员还可允许它提交正式Approve，该能力默认关闭，启用后可以计入仓库的必需审批规则。

这意味着答案是“可以，但有条件”：审批评估、正式Approve和计入合并门槛是三个不同状态。一份 9月1日独立技术简报 也列出了公开预览、默认关闭、分层管理和新提交会使旧批准失效等状态；最终是否影响合并，仍取决于管理员配置。

这次更新带来了判断和批准两项能力

第一项是审批评估。每次Copilot代码审查的概览评论都会说明它是否认为当前PR已达到可批准状态，这项评估不需要管理员开启正式批准权限。

审批评估只是Copilot展示的判断，不是Approve审查事件，也不会增加合并规则统计的批准数。假设一个分支要求两个批准，而PR只有一名成员的正式Approve和Copilot的正面评估，规则仍只获得一个有效批准。

第二项是正式Approve。管理员授权后，Copilot可以提交批准审查；如果“计入合并要求”的设置也允许，该批准便能满足required approvals规则中的一个名额。标题中的“可以批准”和“计入合并门槛”，指的正是这一受配置约束的能力，而不是所有Copilot评估都会自动放行PR。

批准还与具体版本绑定。Copilot批准后如果PR收到新提交，原批准会被撤销，开发者需要重新请求Copilot审查，才能让它根据最新变更重新评估并批准。

决策树：页面上的结论到底算不算数

判断一次Copilot审查是否改变了合并状态，可以依次检查三个问题。顺序不能颠倒，因为页面上出现积极结论，并不表示分支规则已经满足。

1. 只有审批评估吗？如果概览只是显示Copilot认为PR可以批准，它没有提交正式Approve，合并计数不变。
2. 允许Copilot提交Approve吗？打开这一权限后，Copilot可以成为正式审查者；若计数开关仍关闭，批准会被记录，但不会满足必需审批。
3. 批准被允许计入合并要求吗？只有计数设置已启用，而且PR符合仓库配置的文件范围时，Copilot的Approve才会进入门槛计数。

因此，团队可以形成一个中间状态：允许Copilot留下正式Approve，但暂不让它改变合并结果。这与只看审批评估不同，因为前者会产生正式审查记录；它也不同于完整启用，因为受保护分支仍需其他有效批准才能解锁。

权限可以从企业逐层收窄到文件路径

控制链覆盖企业、组织、仓库和文件路径。GitHub配置文档 列明：企业可让组织自行决定、仅为选定组织启用或全部禁用，其中企业策略默认全部禁用；组织可在全部仓库启用计数、交由仓库决定、仅选部分仓库或全部禁用。

仓库层有两个独立开关。“Allow Copilot to approve pull requests”决定Copilot能否提交批准审查；“Allow Copilot approvals to count toward merge requirements”决定该批准能否满足PR审批要求。只打开前者，会得到可记录但不参与门槛计数的状态。

文件路径进一步限制哪些PR可以使用Copilot批准满足合并规则。管理员最多可填写15个glob，每行一个；只有PR修改的每个文件都至少匹配其中一个glob，Copilot批准才会计入门槛。路径列表留空时，计数不受文件路径限制。

这个“全部文件均须匹配”的条件会影响混合PR。若一个PR同时修改允许范围内的文档和范围外的生产代码，即使部分文件匹配，Copilot批准也不能凭此计入合并要求。上层策略同样构成边界：企业或组织禁用后，下层管理员不能自行扩大权限。

文档、测试与生产代码不必采用同一级别

分层启用的价值在于把“允许机器表达判断”和“允许机器改变放行结果”分开。对责任边界清楚、回滚成本较低且另有自动检查的文档、翻译资源、测试夹具或生成文件，团队可以先观察审批评估，再允许正式Approve，最后才考虑把限定路径内的批准计入门槛。这是风险分级建议，不是GitHub对这些文件安全性的保证。

测试目录不宜仅凭名称或扩展名整体开放。测试数据、快照和夹具可能风险较低，但测试框架、权限校验、发布验证及端到端测试本身可能决定质量门槛。glob若写得过宽，也可能让同一PR中的关键改动落入原本只为辅助文件设计的计数范围。

生产代码、身份认证、支付、基础设施、安全策略和发布配置更适合保留人工批准，尤其是在公开预览期间。需要试验时，可以只使用默认出现的审批评估，或允许Copilot提交不计数的Approve，以比较机器判断与人工结论，而不让预览功能直接成为关键分支的放行条件。

配置责任也应与代码责任对应。企业层决定哪些组织可以使用该能力，组织层决定哪些仓库可以参与，仓库层再以独立开关和文件glob限定实际效果。这样才能避免一个局部设置无意间把机器批准扩展到整个代码库。

公开预览能满足批准数量，不等于满足所有规则

这项能力目前面向GitHub Copilot Pro、Pro+、Max、Business和Enterprise方案提供，状态为公开预览，行为仍可能变化。已经明确的是，获得授权并符合路径条件的Copilot批准可以满足仓库的required approvals数量规则。

但“批准数量达标”不应被理解为所有治理条件都已满足。GitHub现有配置页没有说明Copilot批准能够替代CODEOWNERS指定的代码所有者审查，也没有承诺它等同于合规签署、职责分离或特定团队批准。依赖这些控制的仓库仍需分别验证对应规则，不能只看批准总数。

目前可以确定的边界是：评估会出现在每次Copilot审查中，但不计数；正式批准默认关闭；是否计入门槛还受独立设置、上层策略和文件glob约束；批准后的新提交会使旧批准失效。GitHub尚未在已核验页面中给出结束公开预览的时间，也没有公布独立的批准质量指标。