GitHub 于 2026 年 10 月 2 日公布 Copilot code review API 支持，让团队可以通过 REST 和 GraphQL API 发出代码审查请求，并在每次请求中设置 review effort。这意味着 Copilot code review 不再只是 pull request 页面上的一个按钮，而可以成为 CI、内部工具或其他开发流程中的一个可调用步骤。
这次更新同时把 Balanced 设为新的默认审查力度。GitHub 的说明把它描述为速度与深入程度之间的平衡；Lite 和 Highest 仍可由工作流按需要明确选择，而原本已经明确设置 Lite 的用户不会因为默认值改变而被强行改动。默认值是产品行为，不等于每次审查都能达到相同的质量，团队仍要按代码风险和测试结果校准流程。
API 化之后，一个常见的工作流可以是：提交变更、由自动化服务请求 Copilot code review、把结果与测试及静态分析合并，再将需要人判断的问题交给维护者。对大型代码库来说，这种方式有机会把审查安排放进既有的工程闸门，而不是要求每个人记得打开相同的界面。不过，审查结果仍应被视为建议，不能取代负责的 reviewer、测试及安全检查。
GitHub 也保留多层设置逻辑，组织或企业可以在较高层级管理可用的 review effort，仓库及个人设置则在允许范围内提供更细的调整。这种层级对企业治理很重要，因为不同代码库的风险、延迟预算和合规要求不一样；同一个默认值不应被当成所有团队的最佳设置。
这次发布的实际意义，是把「AI 审查」由一个产品功能变成一个可编排的服务接口。代理可以负责收集差异、启动审查、整理结果和要求升级，但质量责任仍在整个流程：要知道审查用了哪个力度、哪个版本、看到了哪些文件，以及出现误判时能否重跑和追踪。如果 API 权限过宽，或把 AI 意见直接接到合并动作，错误就可能由单一建议变成自动化事故。
目前 API 支持 Pro、Pro+、Max、Business 和 Enterprise 方案，但实际可用能力仍受账户、组织设置和 API 权限影响。较稳妥的采用方式，是先把它放在可回滚的非阻塞审查或低风险仓库，观察误报、漏报、延迟及成本，再逐步决定哪些检查可以成为阻塞闸门。
