Copilot 代码审查更新管理 API，团队怎样理解新的审查概览

GitHub 这次更新可以先用一句话理解：Copilot 代码审查开始更适合被团队当作“可治理的能力”来管理，而不只是 Pull Request 里的一条机器人评论。管理侧新增企业、组织和仓库层级的 REST/GraphQL API 能力；阅读侧则把审查结果、未审查文件和反馈信息重新收拢到更紧凑的概览里。

官方地址：https://github.blog/changelog/2026-11-06-copilot-code-review-api-management-and-review-overview-updates/

配置文档：https://docs.github.com/en/copilot/how-tos/copilot-on-github/set-up-copilot/configure-code-review

落地时不要先问“概览页面变成什么样”，而要先画出企业、组织、仓库三层的控制边界，再把 review effort、来源归因和 Files not reviewed 当作审查结果的固定字段来消费。

先区分三层 API 管理边界

这次更新最有价值的部分不是多了几个设置项，而是把管理范围做成了层级化接口。企业管理员可以决定整个企业是否启用代码审查，或者把选择权交给组织管理员；组织管理员可以管理启用状态、默认审查 effort 和 runner；仓库管理员则可以调整 review effort，并决定是否使用自定义指令和 MCP 工具。

可以把团队配置表先写成下面这样，后续再映射到具体的 REST 或 GraphQL 端点：

如果企业层级不允许组织自行决定，组织接口读到的设置就不能被当作“自由配置”。同样，组织管理的默认 effort 也不等于每个仓库最终实际采用的 effort，仓库仍可能受到上层最大值或本地配置的约束。

把 review effort 与来源元数据分开

更新后，团队可以通过 API 看到更明确的审查归因字段，也能在元数据可用时知道一次 review 使用了哪种 effort。GitHub Docs 当前把 Lite、Balanced 和 Max 描述为从标准检查、较深分析到最高投入的不同层级；它们不是“正确率等级”，而是审查投入和分析范围的选择。

对审查结果做内部汇总时，建议至少保留四类字段：

• 是谁产生的：明确区分 Copilot 的 review 和 comment，避免与人工评审混在一起。
• 用了多少 effort：记录实际可见的 effort，而不是只记录仓库默认值。
• 参考了什么：保留 Copilot 报告的 skills、MCP servers 和 custom instructions 来源。
• 结论落在哪里：把 finding、批准判断和未审查文件分开统计。

如果需要把这个思路接到内部采集器，可以先用类似下面的请求形状做字段设计。它是接口字段的示意，不代表某个组织已经授权这些路径：

# 先读取仓库级审查设置，再把返回字段写入治理快照
curl -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer $TOKEN" \
  "https://api.github.com/repos/ORG/REPO/copilot/code-review"

# 写入前检查仓库管理员权限，并保留 effort 与工具开关的变更记录
curl -X PATCH \
  -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer $TOKEN" \
  -d '{"review_effort":"balanced","use_mcp":true}' \
  "https://api.github.com/repos/ORG/REPO/copilot/code-review"

真正接入时应以 GitHub API reference 的实际端点和字段为准。尤其不要把 token 放进仓库脚本或日志；企业和组织设置端点对 GitHub App、细粒度个人访问令牌存在额外限制。

按新结构阅读 review overview

新的审查概览把主要 findings 放在更靠前的位置，把 review effort 和 surveys 收到紧凑的页脚；跳过文件与内容排除文件则合并到一个“Files not reviewed”区域，并附上文件名和排除原因。空区块不再占位，过长列表会用溢出数量提示。

团队阅读时可以按这个顺序处理：

1. 先看 findings 是否覆盖本次变更真正关心的文件和逻辑。
2. 再展开 Files not reviewed，区分“主动跳过”和“内容排除”，不要把未检查误读为没有问题。
3. 最后查看 effort 和 surveys，把审查投入与结果反馈一起写入评审记录。

这比把整条机器人评论当作一段连续文本更容易接入内部工具：finding 是结果，Files not reviewed 是覆盖范围，effort 是资源上下文，feedback reason 则是质量改进信号。

把权限与令牌限制放进落地清单

API 管理不是“拿到一个 token 就能改所有层级”。更新说明明确指出，企业和组织设置端点（包括组织 runner 端点）不支持 GitHub Apps 或细粒度个人访问令牌；仓库设置端点支持这两类认证，但读取至少需要 Administration: read，更新需要 Administration: write，经典个人访问令牌还需要仓库管理员访问。

因此，团队在自动化前应固定检查三件事：

• 调用者属于企业管理员、组织管理员还是仓库管理员。
• 当前认证方式是否被目标层级的端点接受。
• 读取和更新是否使用了对应的 Administration 权限，而不是只看仓库代码权限。

权限失败时先回到层级和令牌类型排查，不要把 403 直接归因于 review effort 或概览格式变化。

用反馈和重试信号改进团队规则

新概览允许用户对结果点踩后选择原因，例如审批判断不一致、评论过于冗长、finding 不准确或过于挑剔。这个反馈入口不只是产品调查，也可以帮助团队判断自定义指令是否过窄、MCP 上下文是否不足，或者某类仓库是否不适合使用同一套 effort。

同时，这次更新还包含几项运行行为调整：失败或超时的审查会自动重试一次；首选模型不可用时可以切换到其他符合条件的模型；同一个 Pull Request 的后续审查会折叠与近期改动无关的 finding。对内部看板来说，建议把“初次失败”“自动重试后成功”“仍然失败”分成三个状态，避免只统计最终有没有评论。

小结

这次 Copilot 代码审查更新可以落成一张团队配方卡：企业管总开关，组织管默认策略，仓库管具体例外；effort 说明审查投入，归因字段说明审查来源，Files not reviewed 说明覆盖边界，feedback reason 说明改进方向。先按这个模型整理治理数据，再接具体 API，比直接围绕页面变化写脚本更稳妥。

相关问题

Copilot 代码审查的 review effort 是不是准确率等级？

不是。Lite、Balanced、Max 表示审查投入和分析深度的不同选择，不能单独当作质量或正确率承诺。

Files not reviewed 为空是不是代表所有文件都检查了？

它表示概览没有列出未审查文件；仍应结合本次变更范围和审查结果判断覆盖情况，不要只根据一个区块下结论。

组织端点能不能直接用 GitHub App 调用？

本次更新说明对企业和组织设置端点（包括组织 runner 端点）列出了 GitHub App 和细粒度个人访问令牌的限制，接入前应以目标端点文档和当前权限为准。