Copilot 代码审查支持 API 统一配置

GitHub Copilot code review 这次更新，把企业、组织和仓库的审查设置开放给 API，同时压缩审查概览，补上费用展示、自动审查和失败重试等细节。适用套餐包括 Copilot Pro、Pro+、Max、Business 和 Enterprise。

对程序员来说，重点是审查结果更容易追踪，配置可以纳入自动化，没审到的文件和实际消耗也更透明。不过，多模型参与审查是否更准，公告没有给出对照数据。

审查配置能自动化，但权限要分三层看

此前，REST API 已经支持请求审查、选择审查力度（review effort）和获取返回信息。这次新增的管理能力覆盖 REST 和 GraphQL API，可以从企业策略一路管理到单个仓库。

三层权限各有边界：

• 企业管理员可以统一开启、关闭代码审查，也可以把选择权交给组织管理员。
• 组织管理员可以管理审查开关、默认审查力度和 runner 配置，但不能覆盖企业统一管理的设置。
• 仓库管理员可以管理审查力度，以及是否使用自定义指令和 MCP 工具。

REST API 接受的审查力度与网页界面一致，组织和仓库的设置响应会列出当前可用的级别。公告没有提供具体接口路径、请求示例或完整级别清单，不能直接据此拼出调用代码。

认证方式尤其容易踩坑。同样是管理审查设置，企业、组织和仓库接口支持的凭据并不相同。

企业和组织设置端点，包括组织 runner 端点，不支持 GitHub Apps，也不支持细粒度个人访问令牌（fine-grained personal access tokens）。仓库设置端点支持这两种方式：读取需要 Administration: read，修改需要 Administration: write；使用经典个人访问令牌时，需要具备仓库管理员权限。

结果侧也增加了可追踪信息：显式归属字段可以识别 Copilot 生成的审查和评论；有对应元数据时，可以查询实际使用的审查力度；还可以查看 Copilot 报告为评论来源的 skills、MCP servers 和 custom instructions。

这里的「来源」是 Copilot 报告的上下文依据，公告没有承诺它能完整解释每条结论的推导过程。

概览变短了，哪些文件没审到反而更清楚

新的审查概览优先把发现的问题放在顶部，审查力度和问卷移到紧凑的页脚。空章节直接省略，过长列表显示剩余数量。

更有用的调整，是把跳过的文件和被内容排除规则排除的文件，统一放进「Files not reviewed」。这里会列出文件名，并附上可点击的排除原因。

审查报告没有发现问题，和相关文件根本没被审查，是两回事。把未审查范围集中展示，能帮助开发者判断报告覆盖到了哪里。

反馈也更具体：对概览点 👎 后，可以选择 Add a reason，再标明主要问题，例如不认同通过判断、评论太啰嗦，或者发现的问题错误、过于挑剔。GitHub 表示会用这些反馈改善审查发现。

同一个 pull request 后续再次审查时，与最近修改无关的问题会先折叠，再隐藏。这能减少重复阅读，但这些问题只是调整了展示方式，不能据此判断它们已经解决。

多模型、费用和重试，分别解决不同问题

Balanced effort 审查现在由三个 reviewer models 分别审查，再由另一个模型合并发现。它尝试汇集多路结果，但公告没有说明模型名称、耗时变化，也没有提供准确率或误报率对比。

费用方面，code review agent session 现在会显示单次审查消耗的 AI credits。

可靠性方面，失败或超时的审查会自动重试一次；首选模型不可用时，可以切换到其他符合条件的模型。服务更新期间，正在进行的审查会获得更多完成时间，刚启动就误报失败并丢弃结果的问题也已修复。

自动化规则同样有变化。Automatically request Copilot code review 仓库规则现在支持 bypass list，名单中的豁免主体不会触发 Copilot 自动审查。

当 Block reviews requested with an external Copilot license 开启时，GitHub Actions、Dependabot，以及组织或企业拥有的 apps，可以再次为机器人创建的 pull request 请求审查，前提是由该组织承担费用。

此外，关闭再开启代码审查会保留计费与预览设置；组织和仓库设置页面的文案、布局更清楚；组织退出反馈收集后，也不会再出现审查问卷。

我的判断

这次更新最值得肯定的是管理和可见性。对维护多个仓库的团队，API 配置比逐个点击页面更适合统一管理；显式归属字段、未审查文件列表和费用展示，也让审查流程更容易核查。

前提是先处理好权限继承与认证限制。已有 GitHub App 的团队，不能默认把仓库级方案直接搬到组织级。

我会对多模型审查保留判断。三个模型审查、另一个模型合并，是实现方式，还不能证明它比单模型或其他审查力度更有效。公告也没有提供作者实测或团队对照数据。是否值得使用，应结合自己仓库里的有效发现、误报、耗时和 AI credits 消耗评估。

能拿来做什么

• 管理多个前端或 Node 仓库时，可以先整理统一的审查力度、自定义指令和 MCP 使用策略，再通过仓库 API 落地，并检查企业策略是否限制了修改。
• 把 Copilot 审查接入日常 PR 流程时，应同时检查「Files not reviewed」，避免把未覆盖文件当成已经通过审查。
• 评估 Balanced effort 时，可以记录有效问题、误报、审查耗时和 AI credits 消耗，用本团队的结果判断是否合适。
• 使用 Dependabot 或 GitHub Actions 创建 PR 的团队，可以核对自动审查的 bypass list、外部许可证限制和组织付费条件，确认机器人 PR 是否会按预期获得审查。