Copilot代码审查API正式可用：单次请求可选深度，Balanced默认已于9月28日生效
2026年10月2日，GitHub宣布可通过REST和GraphQL API请求Copilot代码审查，并为每次请求选择审查投入级别。该能力面向Copilot Pro、Pro+、Max、Business和Enterprise计划正式可用。它给团队增加了程序化入口，让审查触发可以与内部工具、脚本和工作流衔接。
配图为AI生成的概念插图，表现代码变更通过可编程流程进入不同深度的审查，不是GitHub界面，也不代表实际审查结果。
两个日期需要分开理解
这份10月2日公告同时确认，采用Default设置的新旧仓库和组织，现在默认使用Balanced；这项调整已在8月28日预告，并于9月28日生效。明确选择Lite的设置会被尊重。因此，不能把10月2日写成所有审查突然切换Balanced的日期，也不能把“Default”理解为永远固定在某一档。
这一区别直接影响排查：假如团队在9月底观察到审查耗时或用量改变，应先核对当时实际使用的投入级别及设置继承，而不是将变化全归因于新API。公告提供了企业、组织、仓库和个人层级的配置入口；最终应以具体审查记录所显示的档位验证结果。
API入口让触发条件更具体
官方使用文档给出的REST方式，是向现有审查请求接口提交copilot-pull-request-reviewer[bot]这一审查者。对应接口为POST /repos/{owner}/{repo}/pulls/{pull_number}/requested_reviewers；REST参考说明，细粒度令牌需要Pull requests写权限，过密地创建请求还可能触发二级限流。接入时应核对所用API版本与实际支持的请求字段，不宜把网页设置名称直接猜成请求参数。
工程上可以据此设计分流：常规小改动按既定档位请求审查，涉及鉴权或跨服务逻辑的变更明确请求更深入的分析，并把触发原因与提交版本一同记录。这是可实现的流程设计，不是GitHub替团队提供的风险分类保证。脚本还应区分请求已接受、审查已产生和问题已处理，避免把一次成功的HTTP响应当成质量结论。团队可以用一批已知问题的历史变更做对照，观察不同档位是否发现真正相关的缺陷，再决定哪些路径值得提高审查深度，而非只统计评论数量。
深度与资源消耗一起配置
官方文档将Lite描述为较聚焦的常规审查，将Balanced用于复杂逻辑、安全敏感代码和跨服务变更的深入分析。Balanced使用更多AI credits，也可能略增GitHub Actions分钟用量。因此，逐次指定投入级别的价值在于把分析成本与变更风险关联起来，而不是无差别地提高所有请求的档位。
复审策略同样需要明确。官方说明，后续推送不会天然触发再次审查，除非已启用自动审查并配置Review new pushes，或重新发起请求。对于自行接入API的流水线，应防止同一个提交在多个触发器下重复请求，也应避免以旧提交的审查覆盖最新推送。
请求审查和允许合并是两层控制
代码审查API正式可用不等于自动开放审批权限。官方文档说明，Copilot默认的评论式审查不计入必需批准；让其提交批准并计入合并要求，需要另行启用相应设置，且审批能力仍标注为公开预览。上线程序化审查时，应把触发规则、投入级别与合并门禁分别核对，保留团队原有的人工判断和测试要求。
官方资料
资料核对：2026年10月3日（北京时间）。产品能力、配置与限制以官方后续更新为准。
