系列位置：基础篇第 32 篇
调研日期：2026-09-02
关键词：GitHub Copilot · Pull Request · 分支保护 · Required approvals · 代码审查 · Agent 治理
本文目标：把 Copilot Code Review 新增的 approval 能力翻译成可试点、可回退的合并治理方案，而不是把机器意见直接升级为生产发布凭证。
30 秒结论
GitHub 于 2026-09-01 宣布：Copilot Code Review 可以提交 Approve 类型的 PR review，并且在管理员明确开启后，该 approval 可以计入仓库的 merge requirements。它目前是 public preview ；管理员须显式开启，企业层的相关策略默认是 Disabled everywhere。企业、组织和仓库都有控制面，仓库还能用最多 15 条文件 glob 限制"哪些 PR 的 Copilot approval 才能计数"。新 commit 到来后，Copilot 的正式 approval 会像人类 approval 一样被 dismiss。
这并没有推翻第 27 篇的核心边界。每次 Copilot review 都会生成一份 approval assessment ：这是模型对"是否应批准"的判断，默认只作为 review 过程的一部分，不计入 required approvals。只有管理员开启"允许 Copilot 提交 approval"，并进一步开启"允许其 approval 满足合并要求"后，Copilot 才会提交可计数的正式 approval。
所以新的默认门不应是"Copilot 批了就合并"，而应是：
Copilot assessment / 正式 approval
+ 独立 required checks
+ 人类责任审查
+ 当前 head SHA 的证据卡
= 才有资格进入合并队列一、先把两种"批准"分开
|---------------------|---------------------------------------|-----------------------------|-----------------|
| 名称 | 官方产品行为 | 是否计入 required approvals | 正确用途 |
| approval assessment | 每次 Copilot review 都会进行的审查判断 | 否 | 发现候选问题、辅助人审 |
| 正式 Copilot approval | 管理员启用后，由 Copilot 提交的 Approve review | 仅在进一步开启计数后才可能计入 | 受限场景的补充审批信号 |
| 人类 approval | 由有权限的人提交，受 CODEOWNERS、规则集和分支保护约束 | 取决于规则 | 对业务影响、例外和发布责任签字 |
| required checks | CI、测试、扫描、部署验证等独立状态检查 | 不是 approval | 验证可执行事实，不替代责任判断 |
事实： GitHub 文档把"Allow Copilot to approve pull requests"和"Allow Copilot approvals to count toward merge requirements"拆成两个开关。若只开前者，Copilot 可以提交 approval，但不自动变成合并门的计数项。
团队推断： 这两个开关必须分两次评审。第一步可观察 Copilot 的正式 approval 与人审结论是否一致；第二步才讨论极窄范围内是否允许它占用一个 required-approval 名额。把两步合并为一次配置，等于跳过了对误批率和失败模式的观测。
二、控制面不是一个开关：企业、组织、仓库各管什么
GitHub 支持逐层治理。企业层可让组织自行决定、仅为选定组织启用，或"Disabled everywhere"；后者是默认值。组织层可设为全组织启用、仓库自行决定、仅选定仓库启用或全禁用。仓库层才决定是否允许 Copilot 提交 approval、是否可计入合并要求，以及可计数 approval 的路径范围。
|--------|----------------------------|----------------------------------|
| 层级 | 应承担的决策 | 推荐默认值 |
| 企业 | 哪些组织有资格试点，谁可改变策略 | Disabled everywhere；仅安全评审后的组织例外 |
| 组织 | 哪些仓库类别可进入试点 | Enable for selected repositories |
| 仓库 | 是否提交 approval、是否计数、哪些路径可计数 | 先允许 approval 但不计数；路径只覆盖低风险目录 |
路径限制不是"只要改动里有一个安全文件就不计数"，而是只有当 所有变更文件 都匹配所列 glob 时，approval 才能计入。它适合把试点锁在文档、测试夹具、非生产示例或可重复生成文件；它不适合替代 CODEOWNERS、密钥扫描或部署审批。
# 团队策略示例，不是 GitHub 原生配置。
copilot_approval_pilot:
repository: docs-and-test-fixtures
formal_approval: enabled
counts_toward_merge_requirement: false # 第 1 阶段固定为 false
eligible_paths:
- "docs/**"
- "test/fixtures/**"
never-eligible:
- "infra/**"
- ".github/workflows/**"
- "**/*secret*"
human_required_roles: [code-owner]
independent_required_checks: [unit, dependency-scan, secret-scan]三、从"可审"到"可签字"，不应移走独立门
第 27 篇讨论的是 Copilot 对 Agent 和超大 PR 的审查入口扩大；当时 Copilot 留下的是 Comment review，不计 required approvals。现在新增的 approval 能力改变了 PR 的一个状态类型，却没有让模型成为测试、部署或业务责任的替身。
建议按副作用建立分层路径策略：
|-------------------|-------------------------|--------------------------|--------------------------------|
| 路径/变更类型 | Copilot 正式 approval | 可计 required approval | 必须保留的人审与检查 |
| docs/**、示例、测试夹具 | 可开 | 72 小时试点后可评估 | 至少 1 位维护者；渲染/测试 |
| 普通应用逻辑 | 可开 | 默认不开 | CODEOWNER + 单测/集成测/依赖扫描 |
| 身份、权限、支付、数据迁移 | 可开作辅助 | 禁止 | 安全或领域负责人 + 专项检查 |
| CI、IaC、部署、密钥、策略文件 | 可开作辅助 | 禁止 | 平台/安全双人审 + policy/plan/dry-run |
所谓"独立 required checks"是指其失败条件不依赖 Copilot 是否批准。例如，锁定测试命令、签名的构建产物、依赖与密钥扫描、IaC plan 以及部署前 dry-run 都应继续作为单独 status check。若模型、检查和批准都来自同一 Agent 生成链，一个错误假设会同时污染三份看似独立的证据------这就是同源失败。
四、人审职责与反自批：谁能对谁的产物签字
机器 approval 最危险的使用方式，是让"生成 PR 的 Agent""审 PR 的 Agent""触发合并的自动化"共享同一身份、同一提示上下文或同一信任边界。这样即使系统显示两次 approval，也不代表存在两套独立判断。
最小职责分离应包括：
- 生成 PR 的 bot/Agent 不得成为该 PR 的唯一可计数批准者；
- Copilot approval 不能取代作者所属团队的 CODEOWNER approval；
- 高风险路径必须由与作者不同的人员、不同角色或不同团队签字；
- 自动合并机器人只能读取已经满足规则的结果，不能通过改规则、重写 required check 或替换 reviewer 来制造"已满足"；
- review 使用的外部工具、仓库 instructions 与 skills 若由 PR 头分支改动引入，应作为审查系统供应链变更单独复核。
这是团队控制，不是 GitHub 对"同源失败"的自动保证。应把它编码为 ruleset、CODEOWNERS、bot token 权限和审计告警的组合，而不是放在 PR 描述里期待每次自觉遵守。
五、approval 必须绑定 head SHA，不能拿旧签字放行新代码
GitHub 文档说明，新 commit 推送后 Copilot approval 会像人类 approval 一样 dismiss。这是必要的版本绑定，但团队还应在合并前检查：每一项有效 approval、required check、部署验证和人审结论对应的是不是当前 head_sha。
可保留一张不含源码和敏感提示词的回放卡：
# 团队回放卡示例，不是 GitHub 原生 schema。
merge_replay_card:
pull_request: 4821
head_sha: "ab12...redacted"
policy_revision: "copilot-approval-pilot-v1"
copilot:
assessment_completed: true
formal_approval: true
counts_toward_requirement: false
eligible_paths_only: true
required_checks:
- name: unit
sha: "ab12...redacted"
result: pass
- name: secret-scan
sha: "ab12...redacted"
result: pass
human_approvals:
- role: code-owner
reviewer: "recorded-in-github"
decision: "merge-eligible"如果 SHA 变化，旧卡立即作废并重建；不要用"变更很小"作为跳过重审的理由。真正需要省时的场景，应通过拆 PR、确定性生成和稳定检查来实现，而不是复用过期审批。
六、72 小时试点：先测一致性，再谈计数
0---24 小时：只观察
- 在一个低风险仓库、低风险路径开启正式 approval，但保持"不计入 merge requirements"。
- 固定 review effort、禁止自动合并；记录 assessment、Copilot approval、人审、检查和最终结论。
- 验证新 commit 是否会 dismiss approval，并演练一次失败检查阻断合并。
24---48 小时：测试失配
- 取一组已知缺陷、边界回归和无风险机械改动，比较 Copilot approval 与 code owner 判断。
- 模拟生成 Agent 与审查 Agent 同源、CI 绿但安全扫描红、路径混入
infra/**等情况，确认规则不能被 approval 绕过。 - 审核谁拥有企业/组织/仓库开关，以及审计日志能否还原一次策略变化。
48---72 小时：做"是否计数"的否决式评审
只有同时满足下列条件，才讨论一个更窄的可计数试点：误批样本已复盘；人审未被减少；所有必需检查独立存在；路径限制确实排除了生产和策略文件；SHA 回放卡完整；停止开关与负责人明确。任一条件不满足，就维持"可 approve 但不计数"。
常见误区
- "每次 review 的 approval assessment 已经是 required approval。" 不是；它默认不计数。
- "启用 Copilot approval 就自动计入合并规则。" 不是；计数是额外的管理员开关。
- "只要限定路径，就可以删除人审。" 路径 glob 只决定是否计数，不提供业务、合规或供应链判断。
- "绿勾 + Copilot approval 是两份独立证据。" 若同一 Agent、同一 token、同一工具链生成两者，它们可能同源失败。
- "approval 没被手动撤销就一直有效。" 新 commit 会 dismiss；团队仍须核对所有证据的 head SHA。
- "public preview 的配置一经试点就不会变化。" 预览功能可能调整，应把其状态、配置截图/导出和回退开关留入运行手册。
结语
Copilot 的能力已经从"对 PR 留下评论"走到"可提交审批"。这使自动化审查更接近现有的 GitHub 合并语言，但也使组织更容易把产品状态误读为责任转移。
正确的重画方式不是把人从门里拿掉，而是让机器签字只在被限定的路径、独立检查、职责分离、SHA 绑定和可回放证据之间发挥作用。先用 72 小时收集失配与回退证据，再决定它是否值得占用哪怕一个 required-approval 名额。
官方来源
- Copilot code review can now approve pull requests：GitHub Changelog，2026-09-01；用于核验正式 approval、默认关闭、public preview、新 commit dismiss 与路径限制。
- Configuring code review by GitHub Copilot：GitHub Docs，当日复核；用于核验企业/组织/仓库三级控制、两个 approval 开关、最多 15 条 glob 与默认企业策略。
- Using GitHub Copilot code review：GitHub Docs；用于对照传统 Comment review 与 required approvals 的边界。