GitHub让Copilot代码审查可经REST和GraphQL API管理并让审查概览更紧凑：企业、组织和仓库设置可读可改，但企业与组织端点不支持GitHub Apps和细粒度令牌，最大审查强度、计费和批准仍在API之外

2026年11月6日，GitHub发布了一条更新日志，题为《Copilot code review：API管理与审查概览更新》。它说，现在可以通过REST和GraphQL API管理Copilot代码审查的设置，范围从企业策略到单个仓库，同时Copilot在拉取请求上发出的概览评论变得更紧凑。文章称这些更新适用于Copilot Pro、Pro+、Max、Business和Enterprise计划。它没有说明其中任何部分是否为预览，也没有给出价格变化。这是厂商的更新日志，我们没有测试这些端点。

在这次变化之前，REST API已经允许开发者请求审查、选择审查强度并读回信息。文章新增了三项。第一，明确的归属字段可以标识Copilot的审查和评论。第二，响应会显示一次审查所用的审查强度（在有这项元数据时）。第三，它会列出Copilot报告的、作为某条评论来源的技能、MCP服务器和自定义指令。“报告的”这个措辞很重要：这些字段描述的是Copilot自己说它用了什么，文章并没有声称有办法核实。对于要审计AI审查评论的团队，这些字段有助于把Copilot的输出与人工评论区分开，并看出是什么塑造了某条发现。

设置部分对应GitHub管理的三个层级。企业管理员可以为所有组织启用或停用代码审查，也可以把选择权交给组织管理员。组织管理员可以管理启用状态、默认审查强度和运行器配置，但不能覆盖企业所管理的设置。仓库管理员可以管理审查强度，以及审查是否使用自定义指令和MCP工具。REST API接受与网页界面相同的审查强度级别，设置响应会列出调用者可用的级别。在GitHub文档中，这些级别是：Lite，标准审查；Balanced，更深入地查看复杂逻辑、安全敏感代码和跨服务变更，也是内置默认值；Max，使用多个高推理模型做最密集的审查。

文章给出了一条容易漏看的认证警告。企业和组织设置端点（包括组织运行器端点）不支持GitHub Apps，也不支持细粒度个人访问令牌。仓库设置端点则两者都支持，读取设置需要Administration读权限，更新设置需要Administration写权限。经典个人访问令牌需要仓库管理员权限。所以，以GitHub App形式构建的自动化可以管理仓库，却不能管理组织或企业策略。文档还说，配置页面上的其他设置，例如最大审查强度、计费和批准，不能通过API使用。

审查概览评论也有变化。新的概览把发现集中在顶部；所用审查强度和调查问卷移到一个紧凑的页脚；跳过的文件和因内容原因被排除的文件共享一个叫“Files not reviewed”的区块，带有文件名和带链接的原因；空区块被省略，长列表显示溢出数量。现在对概览点踩时，用户可以添加原因，例如不同意的批准评估、过于冗长的评论，或不正确、吹毛求疵的发现。

其他改进包括：Copilot代码审查的智能体会话会显示消耗的AI积分；“Automatically request Copilot code review”仓库规则支持绕过名单，名单里的豁免对象不会收到自动审查；同一拉取请求的后续审查中，与最近更改无关的发现会先折叠再隐藏；Balanced强度的审查现在使用三个审查模型，再由另一个模型合并它们的发现。缺陷修复包括：关闭再开启代码审查时保留计费和预览设置；失败或超时的审查自动重试一次，首选模型不可用时可切换到另一个合格模型；当“阻止使用外部Copilot许可证请求审查”设置开启且组织付费时，GitHub Actions、Dependabot和组织自有应用又可以在机器人创建的拉取请求上请求审查；以及不再在审查刚开始后报告虚假失败。

GitHub文档补充了一条关于自动审查的规则。一个拉取请求可以从几个相互独立的来源获得自动审查资格，即用户自己的设置、仓库规则集和组织规则集。它们分别评估，Copilot仍然只发布一次审查，而用户自己的设置无法关闭规则集已经开启的推送审查和草稿审查。

我们的看法：对管理员来说有用的部分是把策略变成代码。团队现在可以用脚本管理企业、组织和仓库设置并标注评论来源，而不必在页面上点来点去。局限也很明确：认证规则使最上面两层无法用GitHub App自动化，关键控制仍在API之外，来源字段由Copilot自行报告，文章也没有给出审查质量的数字。建议先在一个小仓库里测试这些端点。