Copilot 代码审查：API 支持与新的默认审查强度
GitHub Copilot 代码审查现可通过 REST 与 GraphQL API 调用，并支持逐次设置审查强度；默认审查强度改为 Balanced，面向 Pro、Pro+、Max、Business 和 Enterprise 计划全面可用。
原贴
查看原文原文
中文翻译
你现在可以通过 REST 和 GraphQL API 请求 GitHub Copilot 代码审查，并为每个请求设置审查强度。Balanced 现在也是默认的审查强度。
这些变更已面向 Copilot Pro、Pro+、Max、Business 和 Enterprise 计划全面可用。
你现在可以使用受支持的 REST 和 GraphQL API 从 Copilot 请求审查。当你发起请求时，你可以选择为该次审查设置审查强度。这让你能够把 Copilot 代码审查带入你自己的脚本、工作流和内部工具，使审查可以从你的团队已经在使用的系统开始。
正如 2026 年 8 月 28 日所宣布的，默认审查强度现在对使用 Copilot 代码审查的新建和现有仓库及组织使用 Balanced。如果你在设置中明确选择了 Lite，该选择会被保留。此变更于 2026 年 9 月 28 日生效。
如果你更喜欢 Lite，或想尝试可用的选项，你可以在你所管理的层级把审查强度从 Default 改为 Lite：企业：在你的企业设置中，转到 AI controls → Agents → Copilot code review。组织：在你的组织设置中，转到 Copilot → Code review。仓库：在你的仓库设置中，转到 Copilot → Code review。个人：点击你的个人资料图片，然后转到 Copilot settings → Copilot → Code review。每个层级都可以覆盖其上一层级。
有关分步说明，请参阅 Configuring code review by GitHub Copilot。
核心信息
GitHub Copilot 代码审查现可通过 REST 与 GraphQL API 调用，并支持逐次设置审查强度；默认审查强度改为 Balanced，面向 Pro、Pro+、Max、Business 和 Enterprise 计划全面可用。
- GitHub Copilot 代码审查现可通过 REST 与 GraphQL API 调用，并支持逐次设置审查强度；默认审查强度改为 Balanced，面向 Pro、Pro+、Max、Business 和 Enterprise 计划全面可用。
- 原贴提到：You can now request a GitHub Copilot code review through the REST and Gr
- 来源：github.blog
详细解读
这是什么信号
GitHub 把 Copilot 代码审查从“开发者在 PR 页面点一下”的界面能力，变成了可编程调用的一等能力：REST 与 GraphQL API 都能发起审查请求，并且每次请求可以单独指定审查强度。与此同时，Balanced 从可选项变成默认值，新建和现有仓库、组织都会受影响。这不是一个孤立的功能点，而是代码审查被正式纳入“可被自动化流水线调用”的基础设施层。
为什么重要
代码审查过去是流程中最后一段依赖人工触发的环节。一旦它可以被 API 调用，就意味着它可以被放进 CI/CD、提交门禁、内部质量平台和自研研发工具里，审查不再要求人先打开 GitHub。对已经大规模使用 Copilot 的组织来说，这决定了 AI 审查能不能进入“默认路径”——不是靠开发者记得去点，而是由系统在合适的时机自动触发。默认强度改到 Balanced，也说明 GitHub 判断更深的审查应作为基线体验，而不是少数人手动开启的加分项。
对谁有价值
第一类是平台工程和开发者体验团队：他们可以把审查调用嵌进 PR 机器人、合并门禁和内部研发门户，形成统一入口。第二类是企业安全与合规团队：四级配置（Enterprise、Organization、Repository、Personal）并且下层可覆盖上层，意味着可以在组织层面统一要求，再对个别高风险仓库单独加严。第三类是使用 Copilot Pro、Pro+、Max 的个人开发者和小团队：即使没有企业治理需求，也能用 API 把审查接进自己的脚本。
可以怎么行动
可以从三件事开始：一是盘点现有 PR 流程中哪些环节适合自动触发 Copilot 审查，例如合并前的检查或关键仓库的提交门禁；二是明确强度策略，低风险、迭代频繁的仓库可以保留 Lite，核心仓库依赖默认的 Balanced，避免所有仓库一刀切；三是确认治理层级，先在组织或企业设置里定基线，再看是否需要仓库级覆盖，并注意下层配置会覆盖上层。若此前有人手动选过 Lite，该选择会被保留，值得在团队内核对一遍，避免默认值变更后各地策略不一致。
风险或限制
API 化意味着调用量会随自动化程度上升，审查强度越高，耗时和资源消耗越可能增加，需要在流程设计里考虑等待时间和额度。默认值从原先状态切到 Balanced，会让依赖 Default 的现有仓库在无感知的情况下改变审查行为，上线后应观察 PR 时长和噪音反馈。此外，多层配置虽然灵活，但也带来“谁有权改哪一层”的治理问题，缺少约定时容易出现策略漂移。原文只明确了 Default（Balanced）与 Lite 两个强度选项，其他组合需要以实际可用设置为准。
信息差价值
这条内容的真正价值，不只是“有人发布了一个新功能”，而是它揭示了 github.blog 背后的产品方向、工作流变化或竞争信号。对 OPC 来说，这种信息可以转化成持续追踪的栏目选题。
如果把《Copilot 代码审查：API 支持与新的默认审查强度》放到你的内容系统里，它最大的价值在于帮助读者更快看懂“为什么值得关注”，而不是只看到一条碎片化动态。
参考来源
TOPIC HUBS
延伸专题
AI SUMMARY
这篇文章回答了什么
Copilot 代码审查：API 支持与新的默认审查强度主要讲什么？
GitHub Copilot 代码审查现可通过 REST 与 GraphQL API 调用，并支持逐次设置审查强度；默认审查强度改为 Balanced，面向 Pro、Pro+、Max、Business 和 Enterprise 计划全面可用。
这篇文章最值得关注的要点是什么？
GitHub Copilot 代码审查现可通过 REST 与 GraphQL API 调用，并支持逐次设置审查强度；默认审查强度改为 Balanced，面向 Pro、Pro+、Max、Business 和 Enterprise 计划全面可…；原贴提到：You can now request a GitHub Copilot code review through the REST and Gr；来源：github.blog
这篇文章和哪些AI专题相关？
它适合放在AI副业、AI工具专题里阅读。 关联原因：这篇内容命中「项目、小生意、变现」等主题信号。；这篇内容命中「工具」等主题信号。
阅读这篇文章建议先理解哪些关键词？
建议先理解AI工具、工具、自动化、模型、Cursor这些关键词，再结合正文判断工具、机会或风险是否值得进入自己的工作流。