GitHub 在 9 月 23 日把两项 Copilot 代码审查配置推到了 GA。一是面向个人的自动审查设置页，二是面向企业的默认审查强度。个人设置页从原来只对 Pro、Pro+、Max 开放的单一开关，变成一个所有 Copilot 档位（含 Business 和 Enterprise）都能用的独立页面；企业管理员则第一次可以为整个企业设一个默认审查强度，通过继承下发到组织拥有的仓库。
代码审查是 AI 编程工具里最容易被配错的一环。开得太少，评审意见来得太晚；开得太多，同一个 PR 每推一次都被重新点评一遍，评审噪音反而盖住了真正的问题。这次更新的价值不在于多了一个开关，而在于把「什么时候审」和「审得多深」拆成了两件可以分别配置的事，并且让企业能设一个团队级的起点。
AI Coding 交流群
如果你也在用 AI 写代码，或者正在研究 Cursor、Claude Code 这些工具，欢迎加入以下交流群。群里平时会聊一些 AI 编程的实际用法、开发工作流，还有各种新工具和新玩法。
发生了什么
按 GitHub Changelog 9 月 23 日的条目，两项能力同时进入 generally available：一个是个人层面的自动审查与默认审查强度设置页，另一个是企业层面的默认审查强度设置。这不是预览功能转正那么简单，个人设置的覆盖面本身也扩大了。
之前的情况是：个人设置只对 Copilot Pro、Pro+ 和 Max 开放，入口挂在「Copilot features」页上，而且只能控制一个自动审查开关，没有针对草稿 PR 或者新推送的独立控制。现在路径变成了「个人资料 → Copilot settings」，里面有专门的 code review 页面，Copilot Business 和 Copilot Enterprise 的用户同样能用。
四个可配置项，逐条说清楚
个人页面上有三个自动审查开关和一个强度选项，截图里的默认状态是前两个开、第三个关、强度为 Balanced。
第一个是「Automatic Copilot code review」，控制是否自动请求审查，触发时机有三个：你创建一个 PR、你作为共同作者、或者一个 PR 被你移出草稿状态。第二个是「Review new pushes」，针对 Copilot 已经在审查中的 PR，每次新推送都自动重新审一遍。第三个是「Review draft pull requests」，把自动审查扩展到「仍然标记为草稿」的 PR 上，截图里这一项默认是关闭的——这个默认值是有道理的，草稿阶段的推送通常最频繁，打开它意味着噪音最大。
第四个是「Review effort level」，也就是默认审查强度，目前界面上显示为两档：Lite 和 Balanced。个人设置的这一项会作用到你请求的审查上，包括自动触发的那部分。如果你临时想换一档，可以在 PR 页面「Reviewers」里手动请求审查时先选另一个强度，不必改个人默认值。
一个完整场景：从草稿到合并的四次推送
假设你负责一个改动面比较大的重构，PR 会经历多次推送。
你把「Automatic Copilot code review」和「Review new pushes」都打开，「Review draft pull requests」保持关闭。第一次推送之前，PR 还是草稿，Copilot 不介入，你可以放心地推半成品。你把 PR 移出草稿状态，第一个触发条件命中，Copilot 自动给出评审。之后你又推了三次修改，每次推送都命中「Review new pushes」，审查意见跟着更新，而不是停在第一版上。
如果这四次推送里有一次只是改了文案，你觉得不值得再审一遍，可以在那一次手动去 Reviewers 里用 Lite 请求一次，个人默认的 Balanced 不变。企业侧则决定了起点：管理员设了 Balanced 作为企业默认强度，你所在的组织拥有的仓库继承这个值，你个人页面上看到的默认就是它——除非组织或者仓库自己设了覆盖。
企业默认强度为什么值得单独设
企业级设置的机制是继承。授权管理员可以为整个企业选一个默认审查强度：Lite、Balanced，或者用 GitHub 自己的默认。这个值通过继承到达组织拥有的仓库，同时组织和仓库两层都保留了设置自己覆盖值的能力。
这个「默认 + 可覆盖」的结构解决的问题很具体。在多团队的企业里，如果每个仓库都自己决定审查强度，结果通常不是有人配得太深、就是有人根本没配。给一个企业级起点之后，「我们默认按 Balanced 审」变成一条可讨论的团队约定，而不是散落在各个仓库设置里的个人偏好。想要更轻的组织可以在组织层级覆盖掉。
限制与需要人接管的地方
最直接的限制是审查强度目前只有两档，Lite 和 Balanced。这意味着你无法表达「比 Balanced 更深」这种需求——想更严格，只能靠人工评审补上。
第二个限制在继承链上：企业设置作用于组织拥有的仓库，组织和仓库可以覆盖。换句话说，企业管理员设的值是起点，不是保证。如果你所在的仓库被设了更轻的覆盖值，你在个人页面上看到的默认强度是被覆盖之后的结果。排查「为什么我的审查深度和别人不一样」时，需要沿着企业 → 组织 → 仓库 → 个人这条链往上找。
第三个需要人判断的地方，是「Review draft pull requests」该不该开。它是三个开关里唯一默认关闭的，因为它把审查触发点推到了最容易产生噪音的阶段。团队如果不加区分地打开，很可能在草稿阶段就积累大量评审评论，最后没人认真读。合理的做法是按仓库性质来定：改动小、推送少的仓库可以开，改动大、迭代频繁的仓库保持关闭。
如何试用
个人侧：进入「个人资料 → Copilot settings → code review」，按需打开三个自动审查开关，并选一个默认审查强度。企业侧：由授权管理员在企业管理设置里选择企业的默认审查强度，然后到具体组织和仓库确认有没有覆盖值。如果只想先小范围试，建议先在一两个仓库上打开「Review new pushes」，观察评审评论的数量和可读性之后再决定要不要开草稿 PR 审查。
信息来源
- GitHub Changelog，2026-09-23：More ways to request and configure Copilot code review（https://github.blog/changelog/2026-09-23-copilot-code-review-more-ways-to-request-and-configure-reviews）
开发必备：API 全流程管理神器 Apifox
介绍完上文的内容，我想额外介绍一个对开发者同样重要的效率工具 —— Apifox。作为一个集 API 文档、调试、设计、测试、Mock、自动化测试于一体的工具，Apifox 是目前提升研发效率的首选。
如果你正在开发项目，不妨试试其极其友好的界面设计，它完全兼容 Postman 和 Swagger 数据格式，导入数据非常方便，，即使是新手也能很快上手，点击这里即可注册使用。
值得一提的是，除了个人和常规团队使用，针对有高安全合规要求、或需要在内网环境协作的企业，Apifox 还提供了深度定制的私有化部署方案。
获取专属报价与部署方案
详细的私有化部署系统架构与安全白皮书
针对您公司规模的专属报价单
免费的 1v1 专属产品演示 (Demo) 机会
