摘要： GitHub Copilot 已能自动审查 Pull Request，并在管理员明确启用后提交可计入 Required Approvals 的批准；但 Copilot Approval 仍处于 Public Preview、默认关闭，也不等于允许它自动合并代码。本文面向研发负责人、GitHub 管理员和 DevSecOps 团队，完整讲解 Copilot Code Review、自动复审、路径级批准、Rulesets、分支保护、CODEOWNERS、Required Checks、Actions 与 MCP 权限。核心建议是：普通低风险目录可让 Copilot 承担第一道审查，生产代码必须保留至少一名独立人类批准者；Copilot 编写的 PR、工作流文件、基础设施、权限与密钥相关变更绝不能形成“AI 写、AI 批、AI 合并”的闭环。
核心结论
直接答案： 可以让 Copilot 自动审查并批准 PR，但不建议让 Copilot 成为生产仓库唯一的合并门槛。正确配置应把能力拆成三层：自动审查负责发现问题；Copilot Approval 只对低风险路径计入批准；Auto-merge 仅在 Copilot、人类批准、Required Checks、Code Owner、会话解决和安全扫描全部满足后执行。对支付、身份认证、生产部署、GitHub Actions、基础设施、数据库迁移和密钥处理路径，应禁止 Copilot Approval 计入合并要求，并强制人类 Code Owner 审查。
GitHub 官方资料支持以下判断：
- Copilot Code Review 默认提交的是 Comment，而不是 Approve 或 Request changes，因此默认不满足 Required Approval。
- Copilot Approvals 目前处于 Public Preview，默认关闭；启用后，Copilot 的 approving review 可以像队友批准一样满足仓库 Required Approval。
- 管理员可以在企业、组织和仓库层配置 Approval，并用文件路径控制哪些 Copilot 批准能够计入合并要求。
- Copilot 批准后若有新提交，Approval 会被撤销，需要重新审查。
- GitHub 明确要求 Copilot Cloud Agent 创建的 PR 接受同等严格审查；若仓库要求 PR Approval，PR 发起人的批准不计数，必须由另一名审查者批准。
因此，标题中的“自动批准”应理解为一个受 Ruleset 约束的审查信号，而不是把合并权限交给模型。
自动审查、自动批准与自动合并不是一回事
这三个动作在 GitHub 权限系统中相互独立：
| 动作 | Copilot 能否执行 | 默认状态 | 是否直接改变主分支 |
|---|---|---|---|
| 自动审查 PR | 可以 | 需在 Ruleset/仓库配置 | 否，只生成评论和建议 |
| 提交 Approve Review | 可以，Public Preview | 默认关闭 | 否，但可满足一个 Approval 条件 |
| 修复审查意见 | 可调用 Cloud Agent | 需启用相关能力 | 修改 PR 分支，不直接合并 |
| 自动运行 Actions | 可配置 | Copilot PR 默认需人工批准运行 | 间接执行代码，风险较高 |
| Auto-merge | GitHub 仓库能力，不是模型判断本身 | 需启用 | 条件全部满足后会合并 |
| 绕过 Ruleset | 只对被列入 bypass 的 Actor 生效 | 不应授予 Copilot | 可以突破门禁，风险极高 |
Copilot 的 Approval Assessment 也不等于正式批准。每次 Code Review 都会在概览评论中表达它认为 PR 是否“可以批准”，但这个判断本身不计入合并要求。只有启用 Copilot Approvals 后，它提交的正式 approving review 才能满足 Required Approval。
这一区分能够防止一个常见误配置：团队看到 Copilot 说“Ready to approve”，便认为分支保护已满足；实际上 merge box 仍以正式 Review、状态检查和 Ruleset 结果为准。
Copilot Code Review 能做什么
Copilot 可以在 GitHub 网页、VS Code、Visual Studio、JetBrains、Xcode、GitHub Mobile 和 GitHub CLI 中审查代码。网页端可以把 copilot-pull-request-reviewer[bot] 指定为 Reviewer，也可以使用 CLI：
# 创建 PR 时请求 Copilot 审查
gh pr create --reviewer @copilot
# 给已有 PR 添加 Copilot Reviewer
gh pr edit 128 --add-reviewer @copilot在自动审查模式下，仓库可以对符合条件的 PR 自动发起 Copilot Review，并选择是否在新 Push 后重新审查。Copilot 评论会标记 High、Medium 或 Low 严重级别；能形成明确补丁时，还会给出 Suggested Change。开发者可以接受建议，或使用 Fix with Copilot 让 Cloud Agent 在当前 PR 分支提交修复或创建新的 PR。
Review Effort 分为 Lite 和 Balanced。Lite 更节省成本，适合常规 Bug、安全问题与风格检查；Balanced 会使用更高推理模型，对复杂逻辑、安全敏感代码和跨服务变更做更深入分析。企业可将普通仓库默认设为 Lite，将核心服务设为 Balanced，但不能把 Balanced 当作安全审计替代品。
审查指令配置
Copilot Code Review 支持多类仓库上下文：
.github/copilot-instructions.md：仓库级审查要求；AGENTS.md：代码库架构、测试和实现约定；.github/instructions/**/*.instructions.md：路径级规范；REVIEW.md、CLAUDE.md、GEMINI.md：可被 Code Review 读取的补充说明；.github/skills：面向审查任务的 Agent Skills。
示例：
When reviewing a pull request:
1. Reject direct SQL string concatenation.
2. Require tests for every changed authorization branch.
3. Flag modifications under .github/workflows/ as HIGH risk.
4. Verify migrations have a documented rollback path.
5. Never treat generated snapshots as proof of correctness.重要风险是：Copilot 审查时读取的是 PR Head Branch 中的指令，而不是 Base Branch。因此恶意或被攻陷的 PR 可以同时修改审查指令，尝试弱化判断。防护方法不是“把指令写得更长”，而是把审查配置文件本身纳入敏感路径，要求 Code Owner 人工批准，并禁止 Copilot Approval 对这些路径计数。
启用自动审查和 Approval 的完整步骤
第一步：确认许可与管理员范围
Copilot Code Review 的可用性与组织订阅和管理员策略有关。先由 Enterprise Owner 决定是否允许组织使用，再由 Organization Owner 或 Repository Administrator 配置具体仓库。没有 Copilot 个人席位的组织成员，在企业或组织启用相应能力后也可能使用 Code Review，具体以控制台显示为准。
第二步：配置自动审查 Ruleset
进入仓库 Settings，打开 Rules/Rulesets，创建或编辑针对默认分支的 Branch Ruleset。启用 Copilot Code Review，并选择目标分支、Review Effort 和是否 Review new pushes。
推荐先使用 Evaluate 模式或仅覆盖试点仓库，观察两周的误报、漏报、耗时和 Credits，再切换为 Active。避免一次性对所有历史活跃分支开启 Balanced 复审。
第三步：启用 Copilot Approvals
在企业、组织和仓库的 Copilot Code Review 配置中明确开启 Approval。该功能目前是 Public Preview，选项名称和范围可能变化，以当期控制台为准。组织应采用“上级允许、仓库按路径收紧”的方式，不要默认让所有 Copilot Approval 都计数。
第四步：用路径限定 Approval
仅让低风险路径的 Copilot Approval 计入合并要求，例如：
允许 AI Approval：
docs/**
examples/**
tests/fixtures/**
*.md
禁止 AI Approval 作为唯一批准：
.github/workflows/**
infra/**
terraform/**
k8s/**
auth/**
payments/**
migrations/**
**/*secret*真实路径匹配能力和语法以 GitHub 配置界面为准。核心原则是按“修改后的后果”划分，而不是按文件扩展名简单划分。
第五步：启用 Required Reviews
在同一 Ruleset 中启用 Require a pull request before merging，并设置至少一个 Required Approval。对生产仓库建议要求两个批准：Copilot 可以提供辅助批准，但至少一个必须来自拥有写权限的独立人类；关键路径再要求 Code Owner。
第六步：撤销过期批准
启用 Dismiss stale pull request approvals when new commits are pushed。这样 Copilot 或人类批准后的 Diff 一旦变化，旧批准会失效。若担心 PR 被追加未审查内容，GitHub 官方也认为撤销 stale approvals 更安全。
还可以开启 Require approval of the most recent reviewable push，确保最新 Push 由不同于 Push 者的人批准。高风险仓库可同时采用更严格的 stale approval 策略。
第七步：配置 Required Status Checks
至少设置：单元测试、集成测试、Lint、类型检查、构建、SAST、依赖扫描、Secret Scanning 与必要的部署预览。给 Required Check 指定可信 GitHub App 作为状态来源，避免拥有写权限的普通集成伪造同名成功状态。
状态检查 Job 名必须唯一。GitHub 官方提醒，不同 Workflow 中出现相同 Job 名可能造成模糊结果并阻止合并。
第八步：限制绕过者
Ruleset 可为用户、团队或 GitHub App 配置 bypass。不要把 Copilot、通用 CI App、机器人团队或所有管理员列入无条件 bypass。启用 Do not allow bypassing，或只给极少数 Break-glass 团队授予受审计的紧急权限。
第九步：设置 Auto-merge
只有前述条件全部满足后才开启 Auto-merge。Auto-merge 的含义是“等待门禁满足后由 GitHub 合并”，不是“Copilot 自己决定可以上线”。若 PR 修改高风险路径，即使 Copilot批准和测试通过，也应由人类完成最后批准。
推荐的 Ruleset 组合
| 控制项 | 文档仓库 | 普通应用 | 核心生产服务 |
|---|---|---|---|
| Copilot 自动审查 | 开启 Lite | 开启 Balanced | 开启 Balanced |
| Copilot Approval 计数 | 可按路径开启 | 仅低风险路径 | 不作为唯一 Approval |
| 人类批准 | 可选或 1 人 | 至少 1 人 | 至少 2 人/含 Code Owner |
| Dismiss stale approvals | 开启 | 开启 | 强制开启 |
| Required Checks | 链接/Lint | 测试＋扫描＋构建 | 全套测试＋安全＋部署门禁 |
| Conversation resolution | 开启 | 开启 | 开启 |
| Merge queue | 可选 | 推荐 | 推荐/强制 |
| Bypass | 极少 | Break-glass | 双人审批 Break-glass |
| Auto-merge | 可开启 | 条件式开启 | 仅低风险变更或关闭 |
这张表是实施建议，不是 GitHub 官方强制模板。团队应结合事故成本、合规要求和发布频率调整。
CODEOWNERS 与独立人类审批
CODEOWNERS 是阻止 AI 闭环最实用的一层。对安全敏感路径指定真实团队：
# 默认所有代码由平台团队负责
* @company/platform-reviewers
# 身份认证与授权
/src/auth/ @company/security-team @company/identity-team
# CI/CD 与供应链
/.github/workflows/ @company/devsecops
/scripts/release/ @company/release-managers
# 基础设施与生产部署
/infra/ @company/sre
/k8s/ @company/sre
# 数据库迁移
/migrations/ @company/database-owners启用 Require review from Code Owners 后，修改相应路径的 PR 必须获得 Code Owner 批准。还要保护 CODEOWNERS 文件本身，否则提交者可能先修改所有权规则再修改敏感代码。
“Copilot 写代码、另一个 Copilot Review”不构成真正独立的控制，因为两个步骤可能共享类似模型缺陷、指令和上下文偏差。独立性应来自不同责任主体和不同验证手段：模型审查、静态分析、动态测试、安全扫描与人类判断相互交叉。
Copilot 创建的 PR 为什么要更严格
GitHub 官方明确写道：Copilot PR 应获得与其他贡献相同的彻底审查。若仓库要求批准，PR 发起人对 Copilot PR 的批准不计入要求，必须由另一名 Reviewer 批准。这种设计避免任务委派者既提出目标又单独认可结果。
Copilot Cloud Agent 默认在 GitHub Actions 驱动的环境中工作，能够研究仓库、修改一个分支并打开一个 PR。一次任务只操作一个仓库、一个分支，并最多打开一个 PR；当前官方说明单个会话最长 59 分钟。
更关键的是，Copilot 向 PR 推送更改后，GitHub Actions 默认不会自动运行。原因是 Workflow 可能拥有 Secrets 和高权限。人类应先检查 Diff，特别是 .github/workflows/，再点击 Approve and run workflows。虽然管理员可以配置无需人工干预自动运行，但这不适合来自不可信上下文或能够修改 Workflow 的任务。
必须禁止的循环
flowchart TD
A["Copilot 编写代码"] --> B["Copilot 自己审查"]
B --> C["Copilot Approval 唯一计数"]
C --> D["高权限 Actions 自动运行"]
D --> E["Auto-merge 至生产分支"]这个闭环把编写、审查、执行和发布交给同一类自动化主体。一旦提示注入、依赖投毒、错误指令或模型漏报进入链路，缺乏独立控制阻止扩散。
MCP、Skills 与网络权限风险
Copilot Code Review 可以使用仓库配置的 Agent Skills 和 MCP Server。GitHub MCP 与 Playwright MCP 在相关场景可能默认启用；仓库中的“Allow Copilot to use MCP tools when reviewing pull requests”也可能默认开启。MCP 能提高审查质量，例如读取 Issue、事故单或运行浏览器验证，但也扩大数据访问与外部动作面。
建议：
- 只允许只读 MCP 工具参与审查；
- 禁止 Code Review 使用生产数据库、部署、支付和消息发送工具；
- 限制 MCP Server 可访问的仓库与组织；
- 检查 Review Comment 底部的 Skill/MCP attribution；
- 定期审计 Review Session Log 中调用的工具；
- 不需要 MCP 的仓库关闭相应开关。
Code Review 运行在临时开发环境中，可以通过 .github/workflows/copilot-code-review.yml 单独配置，也可沿用 copilot-setup-steps.yml。建议为审查环境设置独立的网络防火墙和域名白名单，不要直接复用拥有发布凭据的 Agent 环境。
一个可落地的低风险自动化方案
目标：让 Copilot 自动审查文档、示例和普通测试更新，在条件满足后自动合并；应用源码仍需人类批准。
实施流程：
- Ruleset 匹配
main与release/*； - 所有 PR 自动触发 Copilot Lite Review，新 Push 自动复审；
- 只允许
docs/**、examples/**、*.md的 Copilot Approval 计数； - 必须通过 Markdown Lint、链接检查、Secret Scan 和构建预览；
- 开启 stale approval 撤销与 conversation resolution；
- 文档路径可以 Auto-merge；
- 一旦 PR 同时修改
src/**、.github/**或infra/**，要求人工 Code Owner； - Copilot、Actions App 和普通 Maintainer 均不在 bypass list。
伪策略如下，用于表达治理意图，不是 GitHub 可直接导入的原生格式：
copilot_pr_policy:
automatic_review:
enabled: true
review_new_pushes: true
effort: lite
approval:
enabled: true
counts_for:
- "docs/**"
- "examples/**"
- "*.md"
excluded:
- ".github/**"
- "src/auth/**"
- "infra/**"
- "migrations/**"
merge:
dismiss_stale_approvals: true
require_conversation_resolution: true
human_approval_for_sensitive_paths: true
copilot_bypass: false风险边界：哪些 PR 不能只靠 Copilot 批准
| 风险类别 | 例子 | 必须增加的控制 |
|---|---|---|
| 身份与权限 | OAuth、RBAC、Token 验证 | Security Code Owner＋安全测试 |
| CI/CD | Actions、发布脚本、Runner | DevSecOps 人审＋最小 GITHUB_TOKEN 权限 |
| 基础设施 | Terraform、Kubernetes、IAM | Plan 审阅＋环境审批＋SRE 批准 |
| 数据库 | Schema、迁移、删除脚本 | 备份验证＋回滚演练＋DB Owner |
| 支付 | 计费、退款、订单状态 | 业务 Owner＋集成测试＋审计 |
| 密钥与隐私 | Secrets、PII、客户数据 | 禁止进入上下文＋DLP/Secret Scan |
| 依赖供应链 | Lockfile、Action SHA、镜像 | 依赖审查＋固定 SHA＋来源验证 |
| 安全配置 | CSP、WAF、加密、日志脱敏 | 安全团队审批＋专门扫描 |
Copilot 可能漏掉跨文件业务约束、并发问题、环境差异、许可证风险和恶意代码。它的评论也可能不正确或不完整。Approval 只代表模型在当前可见上下文中未发现阻断问题，不构成安全、合规或功能保证。
成本与运行限制
Copilot Code Review 使用 GitHub Actions 运行 Agent 能力，在私有仓库中会消耗 Actions Minutes；新的 Copilot 计费体系下也会消耗 AI Credits。Balanced Review、频繁的每次 Push 复审、大 PR 和 MCP 工具调用都会增加成本。
成本控制建议：
- 小 PR 默认 Lite，大范围/高风险 PR 才用 Balanced；
- 限制 PR 规模，超过 500 至 1000 行拆分；
- Draft PR 不自动重复审查，Ready for review 后再触发；
- 合并机器人生成的依赖升级，先按风险分组；
- 对频繁 Push 设置节流或团队约定；
- 每月同时查看 AI Credits 和 Actions Minutes。
具体每次审查费用随模型、Token 和环境执行时间变化，官方没有统一固定价格，应以组织 Usage 数据为准。
故障排查
Copilot 评论了但没有 Approve
检查 Approvals 是否在企业、组织和仓库层启用。默认 Code Review 只提交 Comment；概览中的 Approval Assessment 也不等于正式 Approve。
Copilot Approve 了但 PR 仍不能合并
检查 Copilot Approval 是否匹配允许计数的文件路径、是否被新 Push 撤销、是否仍缺人类/Code Owner 批准、Required Checks、会话解决、部署或 Merge Queue 条件。
新 Push 后没有重新审查
自动审查不必然自动复审。需要在 Ruleset 的 Copilot Code Review 设置中开启 Review new pushes，或手动再次请求 Copilot。
Required Check 已绿但合并仍被阻止
检查是否存在同名 Job、状态来源是否为指定 App、分支是否要求与 Base 保持最新，以及是否有另一条 Ruleset 同时生效。
Copilot PR 的 Actions 没有运行
这是默认安全行为。检查 PR Diff，特别是 Workflow 变更，然后由有权限的人点击 Approve and run workflows。不要为解决便利问题直接对所有 Copilot PR 开启高权限自动运行。
上线检查清单
- 明确自动审查、正式 Approval 和 Auto-merge 三者的区别
- 确认 Copilot Approvals 为 Public Preview 并经过风险评估
- 为生产分支建立 Active Ruleset
- 开启 Required PR、Required Checks 和 Conversation Resolution
- 开启新 Push 后复审及 stale approval 撤销
- 敏感路径要求人类 Code Owner
- Copilot Approval 只覆盖低风险路径
- Copilot、CI 与普通管理员不在无条件 bypass list
- Required Checks 指定可信 App 来源且 Job 名唯一
- Copilot PR 的 Workflow 默认保留人工运行批准
- Review 指令文件本身受 CODEOWNERS 保护
- MCP 仅开放只读、最小权限工具
- 审查环境设置独立网络白名单
- 同时监控 AI Credits、Actions Minutes、误报和漏报
- 保留紧急回退、撤销和审计流程
FAQ
1. Copilot 现在真的可以批准 PR 吗？
可以。管理员启用 Copilot Approvals 后，其 approving review 可以满足 Required Approval；但截至 2026 年 9 月该能力仍是 Public Preview、默认关闭。
2. Copilot 的“Ready to approve”会直接计入批准吗？
不会。那是 Approval Assessment。只有正式提交的 Approve Review 才可能计入分支保护要求。
3. 能否让 Copilot 审查后自动合并？
技术上可以把 Copilot Approval 与 GitHub Auto-merge 组合，但应同时要求测试、安全扫描和至少一名人类批准，尤其不能用于高风险路径。
4. Copilot 批准后继续 Push 会怎样？
官方说明新提交会使 Copilot Approval 被撤销，需要重新请求 Review。团队还应启用 stale approval 撤销和 Review new pushes。
5. Copilot 能批准自己创建的 PR 吗？
不要设计这种闭环。GitHub 要求 Copilot PR 受到彻底审查；仓库要求批准时，任务发起人的批准也不计数，需要另一名 Reviewer。
6. 为什么 Copilot PR 的 Actions 默认不运行？
Workflow 可能访问 Secrets 或执行高权限代码。GitHub 要求人先检查变更，再批准运行；管理员虽可放开自动运行，但风险更高。
7. Copilot Approval 能代替 CODEOWNERS 吗？
不能。CODEOWNERS 表达业务和安全责任。认证、支付、基础设施、数据库与 Workflow 路径仍应由对应人类团队批准。
8. 如何控制审查成本？
普通 PR 使用 Lite，高风险变更才用 Balanced；减少大 PR 和无意义 Push，限制 MCP，监控 AI Credits 与私有仓库 Actions Minutes。
事实依据与来源
官方已确认的事实包括：默认 Comment Review、Approval Public Preview、启用后可满足 Required Approval、新 Push 撤销 Copilot Approval、路径级控制、自动复审、Review Effort、Head Branch 指令来源、MCP 默认设置、Actions 默认人工批准，以及分支保护的 Required Review/Checks/CODEOWNERS 规则。
“至少保留一名独立人类”“低风险路径可计入 AI Approval”“高风险目录清单”和推荐 Ruleset 是实施建议，不代表 GitHub 对特定行业的合规承诺。
参考来源
- Using GitHub Copilot code review
- Configuring code review by GitHub Copilot
- About GitHub Copilot code review
- About protected branches
- Available rules for rulesets
- Review output from Copilot
- About GitHub Copilot cloud agent
- Application card: GitHub Copilot Agents
相关阅读
工具选型与提示词资料
适合阅读工具评测、工具推荐、对比测评类文章后继续转化。
