approval assessment 和 approval 不是一回事
GitHub 在 2026-09-01 宣布，Copilot Code Review 可以在管理员授权后提交 approval。普通的 approval assessment 只是评论中的判断，不会计入合并要求；开启真正的 approval 后，才可能满足仓库的 required approvals。
默认状态是关闭，控制范围可以是 enterprise、organization 或 repository。新 commit 推送后，Copilot approval 会像人工 approval 一样失效。
先把自动批准限制在低风险路径
仓库管理员可以选择 Copilot 允许批准的文件路径。建议先只允许文档、测试或低风险目录，把部署脚本、身份验证、数据库迁移和基础设施配置排除在外。
同时检查：
- CODEOWNERS 是否仍要求真实负责人
- required status checks 是否必须通过
- 生产分支是否仍禁止绕过人工 review
- Copilot approval 是否能与机器人作者 PR 叠加
用四个 PR 验证规则
在测试仓库中准备四个无害 PR：普通代码、受限路径、缺少 check、提交后再次推送。分别记录 Copilot 是否评论、是否提交 approval、approval 是否计入 required approvals，以及新 commit 后是否被撤销。
不要用“Copilot 说 ready”作为合并条件。官方说明 assessment 本身不满足 merge requirement；真正的批准行为才会影响分支保护。
什么时候不该启用
如果团队还没有稳定的 CODEOWNERS、测试门禁和高风险路径清单，不要先开启全仓库自动批准。自动批准降低的是排队时间，不会替代代码来源审查、依赖变更检查和生产发布授权。
成功标准
成功标准是管理员能明确回答“谁能开、哪些仓库开、哪些路径允许、哪些 check 仍必须通过”；测试 PR 的 approval、撤销和重新 review 行为与分支保护规则一致；高风险路径永远保留人工门槛。
自动批准只减少等待，不替代代码来源审查、依赖变更检查和生产发布授权。