GitHub Copilot 代码评审开放更多请求与配置方式

GitHub Copilot 代码评审现在为扩展后的 Copilot 计划集合提供更多个人配置，并提供一项企业级默认设置。

这些改进现已正式可用：一个用于自动评审和你的默认评审力度的专用个人设置页；一项面向组织自有仓库的企业级默认评审力度设置。

此前，个人 Copilot 代码评审设置仅在 Copilot Pro、Pro+ 和 Max 上、在“Copilot features”页面中提供。它们只包含单一的自动评审设置，没有针对草稿拉取请求或新推送的独立控制。

在你的个人资料 → Copilot 设置下，Copilot 下的专用“code review”页面现已在每一个 Copilot 计划上可用，包括 Copilot Business 和 Copilot Enterprise。在此页面上你可以：

• 打开 Copilot 的自动评审，当你创建拉取请求、作为共同作者创建拉取请求，或把拉取请求移出草稿状态时触发。
• 为你创建或作为共同作者的新推送以及草稿拉取请求打开自动评审。
• 设置你的默认评审力度，目前显示为 Lite 或 Balanced。你的默认力度适用于你请求的评审，包括被配置为自动评审你的拉取请求的评审。
• 当你通过拉取请求页面的“Reviewers”手动向 Copilot 请求评审时，你仍可以在请求前选择不同的评审力度。

经授权的企业管理员现在可以为整个企业设置一个默认评审力度（即 Lite、Balanced 或 GitHub 默认）。该默认值通过继承适用于组织自有仓库。组织和仓库仍可设置自己的覆盖值。

GitHub Copilot 代码评审把个人配置从 Pro、Pro+、Max 扩展到全部 Copilot 计划（含 Business 与 Enterprise），新增独立的 code review 设置页与草稿 PR、新 push 的自动评审开关，并新增企业级默认评审力度设置。

• GitHub Copilot 代码评审把个人配置从 Pro、Pro+、Max 扩展到全部 Copilot 计划（含 Business 与 Enterprise），新增独立的 code review 设置页与草稿 PR、新 push 的自动评审开关，并新增企业级默认评审力度设置。
• 原贴提到：GitHub Copilot code review now offers additional personal configurations
• 来源：github.blog

这是什么信号

GitHub 把 Copilot 代码评审的个人配置从少数付费计划（Pro、Pro+、Max）扩展到全部 Copilot 计划，包括 Copilot Business 和 Copilot Enterprise，同时新增企业级默认评审力度设置。配置入口也从原先挂在“Copilot features”页面上的单一自动评审开关，变成独立的 code review 设置页，并拆出了草稿 PR、新 push 的独立开关和默认评审力度。一句话：AI 代码评审正在从“个人尝鲜功能”变成“组织级默认能力”。

为什么重要

过去 AI 评审的瓶颈不在模型能力，而在控制权：什么时候触发、用多大力气评审，开发者几乎没有可配项。现在个人维度可以按事件类型分别开关——创建 PR、作为共同作者创建 PR、移出草稿状态、新推送、草稿 PR——并设置自己的默认评审力度（当前显示为 Lite 与 Balanced）；手动请求评审时仍可临时切换力度。

对企业而言更关键的是“默认值”这个概念第一次出现。企业管理员可以为整个企业设定一个默认评审力度（Lite、Balanced 或 GitHub 默认），通过继承作用于组织自有仓库，而组织和仓库仍可各自覆盖。这意味着 AI 评审的基线不再依赖每个开发者自觉去开，而是可以由平台侧统一定义。对要规模化推行 AI 评审的组织，这比多一个模型能力更有价值。

对谁有价值

• 平台 / DevEx 团队：可以用企业默认值统一 AI 评审基线，减少逐仓库、逐团队沟通的边际成本。
• 工程管理者：在推动“让 AI 参与评审”时，终于能把“审什么”和“审多重”分开管理。
• 个人开发者：草稿 PR 与新 push 的独立开关，能直接减少早期迭代阶段的无效评审噪音。
• 安全与合规角色：默认开启后评审链路覆盖更广，需要重新确认代码内容流转是否符合内部要求。

可以怎么行动

• 先决定企业或组织层面的默认评审力度取向：Lite 更克制，Balanced 更细，取取决于团队对评审延迟与评论噪音的容忍度，而不是取“最全的那个”。
• 对高噪音的大仓库，优先关闭草稿 PR 与新 push 的自动评审，只保留 PR 就绪后的评审，把 AI 评审用在真正需要人看的时点。
• 把“团队默认评审力度”写进工程规范文档，避免同组织内配置漂移、不同团队体验割裂。
• 先用个人设置页在小范围试点，观察评论质量与噪音比，再决定是否提升为企业默认，而不是一次性全量铺开。

风险与限制

• 原文只提到 Lite 与 Balanced 两种力度，未说明是否存在其他档位，不要假设有更多选项。
• 企业默认是“继承”关系且组织与仓库可覆盖，因此“企业设了默认”不等于“实际生效”，需要抽样检查落地情况。
• 自动评审触发面扩大（含草稿 PR、新 push）可能带来评审评论噪音与额外运行成本，原文未给出具体计量方式。
• 原文未说明各计划之间的功能边界、可用区域或计费变化，相关判断需要另行核实，不能从这条更新直接外推。

这条内容的真正价值，不只是“有人发布了一个新功能”，而是它揭示了 github.blog 背后的产品方向、工作流变化或竞争信号。对 OPC 来说，这种信息可以转化成持续追踪的栏目选题。

如果把《GitHub Copilot 代码评审开放更多请求与配置方式》放到你的内容系统里，它最大的价值在于帮助读者更快看懂“为什么值得关注”，而不是只看到一条碎片化动态。

• Allison 原帖