Copilot Code Review 的 Lite / Balanced 已 GA：用风险路由代替每个 PR 都深度审查

调研日期：2026-08-09
本文目标：基于 Copilot code review 的 Lite 与 Balanced 审查深度，设计一套可解释的 PR 风险路由；把"要不要自动审查""审查多深""谁最终负责合并"分成独立决策。

2026-08-07，GitHub 宣布 Copilot code review 的 Lite 与 Balanced effort levels 正式可用。Lite 取代预览阶段的 Low，Balanced 取代 Medium；已有配置会自动沿用。它看似只是界面里多了一个选项，实际却暴露了一个常被忽略的工程问题：并不是每个 Pull Request 都值得以相同的深度、成本和时延被审查。

同一天，GitHub 还关闭了 GitHub Code Quality 曾自动创建规则集中的 Copilot 评审请求、审查新 push 和审查 draft PR 三个开关。这并不表示 Copilot code review 被移除；相反，团队可以继续在仓库或组织级规则中显式配置自动审查。变化传递出的工程信号很清楚：是否让 Agent 在什么时机开始审查，应该是团队的明确选择，而不是某个相邻产品功能带来的隐含副作用。

**适用前提：**你的团队使用包含 Copilot code review 的付费 Copilot 计划，并且组织策略已允许该功能。本文讨论的是风险分流和验证流程，不会把 Lite 或 Balanced 描述为安全审批，也不会把 Agent 的建议当成自动合并授权。

一、不要用一个开关回答三个不同的问题

在 PR 审查里，至少有三件事彼此独立：

|--------|---------------------------|----------------------------|---------------------|
| 决策 | 真正的问题 | 合适的控制面 | 不应由它替代的事情 |
| 是否触发审查 | 这个 PR 在什么时机需要 Copilot 参与？ | 仓库或组织的自动审查规则；人工请求 | 分支保护、人工 reviewer、CI |
| 选择什么深度 | 该次审查是常规反馈，还是更高推理与更长分析？ | Lite / Balanced 默认值与每次审查选择 | 任务权限、模型准入、成本预算 |
| 是否采纳建议 | 一条评论是否正确、完整且适用于当前架构？ | 人工 review、测试、静态分析与变更流程 | "Balanced 跑过了"的表面确认 |

GitHub 当前文档把 Lite 定义为默认的标准审查，适合快速发现常见 bug、安全问题和风格不一致；Balanced 会路由到更高推理模型，对复杂逻辑、安全敏感代码和跨服务变更做更长分析。Balanced 也会消耗更多 AI credits 和 GitHub Actions minutes。

因此，最稳妥的默认不是"所有 PR 都选 Balanced"，而是先把风险因素显式化：代码修改是否跨服务？是否会改变身份、密钥、支付、数据迁移或生产基础设施？是否需要理解大量仓库上下文？只有这些信号出现时，深度审查的额外成本才有清晰的工程理由。

二、建立一张团队可复核的风险---审查矩阵

下面的矩阵不是 GitHub 的内置规则，也不自动改变每次审查等级；它是一份团队契约，用来确保不同作者在相似风险下作出相似选择。

|-----------------------|------------------------------|----------------------------|------------------|
| PR 类型 | 建议审查深度 | 必须叠加的验证 | 不要误解为 |
| 文档、注释、局部样式或低风险测试修正 | Lite | 常规 CI 与作者自检 | 不需要任何人工 review |
| 单服务内、边界清楚的小功能或 bug 修复 | Lite 起步；出现复杂失败信号再请求 Balanced | 单元测试、变更说明、人工抽查 | Lite 只能看格式 |
| 鉴权、权限、密钥处理、数据迁移、部署定义 | Balanced | 安全 reviewer、最小权限核对、回滚方案 | Balanced 等于安全签字 |
| 跨服务协议、共享数据模型、大规模重构 | Balanced | 端到端或契约测试、架构 reviewer、分阶段发布 | 更长推理一定能覆盖所有回归 |
| 依赖锁文件、日志、SVG | 另走供应链或专用检查 | Dependabot、SCA、签名/许可检查 | Copilot 已经审过这些文件 |

最后一行很重要。GitHub 文档列出了一些 Copilot code review 不会审查的文件类型，包括依赖管理文件、日志和 SVG。即使这个 PR 被标为 Balanced，也不能把"已请求 AI 审查"当作供应链或资产安全检查已经完成。

组织所有者可以设置自动审查的默认 effort level，仓库管理员可以为具体仓库覆盖该默认值；每次手动请求评审时，选择只作用于那一次评审。公开文档描述的是组织默认、仓库覆盖和单次选择，并没有承诺"某个标签出现后自动把 Lite 改成 Balanced"的动态规则。因此，自建的风险分类器必须明确是建议工具，不能伪装成产品已经执行的策略。

三、先让一个小脚本解释"为什么建议 Balanced"

下面的脚本只读取当前分支与基线之间的变更文件名，给出 Lite 或 Balanced 的建议及理由。它不调用 GitHub API、不提交数据，也不会替你发起 Copilot review；作者仍要在 PR 流程中核对建议、选择审查深度并保留人工验证。

将其保存为 scripts/review-effort.sh，并赋予执行权限：

复制代码

#!/usr/bin/env bash
set -euo pipefail

base_ref="${1:-origin/main}"
mapfile -t changed_files < <(git diff --name-only "${base_ref}...HEAD")

if [ "${#changed_files[@]}" -eq 0 ]; then
  printf 'recommendation=lite\nreason=no changed files relative to %s\n' "$base_ref"
  exit 0
fi

balanced_reason=()

for file in "${changed_files[@]}"; do
  case "$file" in
    *"/auth/"*|auth/*|*"/security/"*|security/*)
      balanced_reason+=("identity-or-security-path:$file")
      ;;
    *"/infra/"*|infra/*|*"/deploy/"*|deploy/*|*.tf|*.tfvars|Dockerfile|*/Dockerfile)
      balanced_reason+=("infrastructure-or-deployment:$file")
      ;;
    *"/migrations/"*|migrations/*|*.sql)
      balanced_reason+=("data-migration:$file")
      ;;
    *"/api/"*|api/*|*"/contracts/"*|contracts/*)
      balanced_reason+=("shared-contract-or-api:$file")
      ;;
  esac
done

if [ "${#changed_files[@]}" -gt 20 ]; then
  balanced_reason+=("large-change-set:${#changed_files[@]} files")
fi

if [ "${#balanced_reason[@]}" -gt 0 ]; then
  printf 'recommendation=balanced\n'
  printf 'reason=%s\n' "$(IFS='; '; printf '%s' "${balanced_reason[*]}")"
else
  printf 'recommendation=lite\n'
  printf 'reason=routine path set; author must still assess business risk\n'
fi

运行方式如下：

复制代码

chmod +x scripts/review-effort.sh
scripts/review-effort.sh origin/main

脚本故意只看路径和变更规模，因此它只能降低遗漏风险，不能理解业务语义。例如，支付金额计算藏在一个普通的 utils 目录里，脚本可能建议 Lite；作者或 reviewer 应把业务关键性覆盖到建议之上。若团队要把这种推荐接入 CI，请仅把输出用作 PR 标签、检查说明或人工提醒，并在文档中写清"不会自动改变 GitHub 的 review effort"。

四、把自动触发、深度选择和人工合并串成一条可回放链

一个低噪声的上线顺序可以是：

先定义触发范围。 选择一个试点仓库或分支规则，明确是新 PR、ready-for-review 后，还是人工请求时才触发。不要因为开启了 Code Quality 或其他功能就假设审查规则符合预期。
设置保守默认。 对变化频繁、风险层级混合的组织，先用 Lite 默认值；对明确高风险、由专门团队维护的仓库，再考虑仓库级 Balanced 覆盖。任何默认都应有负责人和复审日期。
在 PR 中记录风险理由。 让作者在描述里回答"数据、鉴权、跨服务、部署、迁移是否受影响"，并附上脚本建议。人可以覆盖脚本，但应写下原因。
选择 effort 后再看结果。 GitHub 会在 PR 时间线事件和概览评论中标出实际使用的 effort level；把它记为事实，而不是从默认设置反推。
以独立证据决定能否合并。 评论需要人工核验，修复需要测试，生产风险还需要既有的分支保护、部署审批和回滚计划。

代码审查的 Agentic capabilities 会利用 GitHub Actions 进行全项目上下文收集以及把建议传给 Copilot cloud agent 等操作。Actions 不可用或相关工作流失败时，审查仍可能产生，但不会包含这些附加能力。出现"评论看起来更浅"的现象时，应先检查运行条件和 Actions 记录，而不是直接断言模型退化。

五、同时观察质量信号与成本信号

Copilot code review 的成本有两个分量：模型交互消耗的 AI credits，以及 Agentic capabilities 消耗的 GitHub Actions minutes。自动审查的 AI credits 通常归到 PR 作者，手动请求时则归到请求者；具体预算和无座席用户的归属还应以当前组织政策和账单文档为准。

建议在不记录源码和个人排名的前提下，按 PR 汇总以下字段：

|-----------------|-----------------------------------------------------|--------------|--------------------|
| 字段 | 获取位置 | 用途 | 不应用来做什么 |
| 实际 effort level | PR 概览评论与时间线 | 检查风险路由是否真的生效 | 推断默认配置永远没有被覆盖 |
| 风险类别与覆盖理由 | PR 模板或检查输出 | 找到分流规则的漏判与误判 | 评价个人能力 |
| 评论被接受、拒绝或需复查 | 人工 review 摘要 | 估计噪声与可操作性 | 把接受率直接等同于缺陷检出率 |
| CI、回归和安全检查结果 | 既有检查系统 | 验证修复没有引入新问题 | 证明 Copilot 找到了所有问题 |
| Actions minutes | Actions metrics 中 copilot-pull-request-reviewer 工作流 | 观察运行资源趋势 | 单独判断代码质量 |
| AI credits | 账单报告与预算视图 | 控制试点成本与异常峰值 | 在缺少任务难度信息时做横向排名 |

当 Balanced 的采纳率低、测试没有增益、却显著增加时延或成本时，应该回到 Lite 或缩小触发范围；当某类高风险变更在 Lite 下持续被人审发现上下文遗漏时，再把那类仓库或 PR 明确升级为 Balanced。这样得到的是一个随证据调整的路由策略，而不是一次性追求"最强审查"。

六、六个常见误区

1）把 Balanced 当成安全审批

Balanced 只是更深的模型分析。鉴权、部署、迁移和敏感数据仍需要拥有业务上下文和授权责任的人审阅。

2）把每次自动审查都设为 Balanced

这会让普通改动承担更高 AI credits 与 Actions minutes，却未必得到等比例的价值。应先由风险和样本结果证明深度审查值得。

3）把本地路径分类器当作 GitHub 原生策略

脚本只是建议层。产品当前暴露的是组织默认、仓库覆盖与单次选择；若动态策略没有经过实际验证，就不要在流程图里写成"标签会自动切换 effort"。

4）认为选择某个 Chat 模型会改变代码审查模型

GitHub 说明 code review 不支持模型切换，且"Models"设置控制 Copilot Chat。模型准入、Chat 使用和 code review 是不同的运行面。

5）忽略 Agentic capabilities 的运行退化

Actions 或其工作流不可用时，审查可以降级为较有限的形态。排查时应同时查看 PR 记录、runner 配置和 Actions 使用情况。

6）把一条 Agent 评论直接变成代码

官方文档明确提醒 Copilot 不保证发现所有问题，也可能出错。每条建议都要经过人工评估，并由独立测试和现有合并门禁支撑。

结语

Lite 与 Balanced 的价值，不在于给 PR 再加一个"高级"按钮，而在于逼迫团队把审查资源和变更风险对应起来。先明确是否触发，再根据可解释的风险选择深度，最后用人审、测试、Actions 运行记录和成本证据验证效果，才能避免自动审查从辅助工具变成不可控的背景噪声。

建议从一个仓库、三类 PR 和四周的脱敏记录开始：让 Lite 处理常规变更，让 Balanced 专注真正需要深上下文的风险路径，并保留人工覆盖和回退权。等到证据足够，再扩大规则的适用范围。

来源与延伸阅读

Copilot code review effort levels are generally available：GitHub 官方公告，发布于 2026-08-07；说明 Lite/Balanced、配置继承、组织默认和实际 effort 标记。
GitHub Code Quality no longer adds Copilot as a reviewer：同日的规则集调整；说明哪些自动评审设置被关闭，以及如何显式恢复自动 review。
About GitHub Copilot code review：当前能力范围、effort level、Agentic capabilities、文件排除、成本与人工验证要求。
Models and pricing for GitHub Copilot：AI credits、GitHub Actions minutes 与代码审查的当前计费说明。

CSDN 标题：

标签： GitHub Copilot · Code Review · AI Agent · DevSecOps · 工程效能 · 风险治理