从「建议」到「控制平面」
很长一段时间里，Copilot 的代码审查只是一条意见。它留下的是 Comment 类型的评审，从不给出 Approve 或 Request changes，GitHub 自己的文档也明确写过：Copilot 的评审不计入必需审批。你可以忽略它、照做，或者跟它争论，但它碰不到合并按钮。
按公开的更新记录，2026 年 9 月 1 日这条界线被移动了。Copilot 代码审查开始包含一份审批评估，管理员可以授权它提交一份计入仓库必需审批规则的批准评审。九天后，也就是 9 月 11 日，GitHub 又补上了一组能力：自动解决它自己提出的、已被后续提交处理的评审意见，在审查过程中执行命令，以及在 Lite 档位用一组智能体做集成评审。
这三件事放在一起，说明 AI 代码审查正从「建议层」走进「控制平面」。其中前两件争议不大，第三件会改变分支保护的含义。
审批权限是一条三级配置链
把这件事讲清楚，需要理解配置是怎么层层往下传的。按官方文档，链条分成三级。
企业级先设边界：路径是「企业 AI 控制项 → 可用智能体 → Copilot 代码审查」，然后是「允许 Copilot 批准拉取请求」。默认是全局禁用，任何组织都无法启用；也可以选择「让组织决定」，或只对指定组织放开。
组织级决定是否计入：路径是「组织设置 → Copilot → 代码审查 → 审批 → 将 Copilot 批准计入合并要求」。选项同样分为全局启用、交给仓库决定、只对指定仓库启用、全局禁用。
仓库级有两个开关：一个决定是否允许 Copilot 提交批准评审，另一个决定该批准是否满足规则集的必需审批数。仓库级还可以配置文件路径匹配规则，每行一个通配符，最多十五行；只有拉取请求中改动的每个文件都至少匹配到一条规则时，这次批准才生效。留空表示对所有文件生效。
这套设计的要点在于：一个开关负责「能不能说话」，另一个负责「说的话算不算数」。把两者分开，才让「先观察、后放权」成为可配置的路径。
9 月 11 日：审查器开始自己动手
同一批更新里，审查器的能力也变了。Lite 档位从单一审查者改成一组智能体协同，每个智能体提供自己的判断，再由 Copilot 合并成一份评审输出。按官方更新记录，这套做法让高严重级别问题被处理的数量增加约 47%，中等级别约 31%，低级别约 11%，同时审查成本下降约 8%。
另外两项体验改动也值得注意。当开发者推送的提交处理了某条未解决的评审意见，Copilot 会在重新审查时自动把该讨论串标记为已解决；此前即使问题已修好，线程仍要人工关闭。应用 Copilot 的自动修复建议时，生成的提交信息也会针对该次改动，而不是一段通用填充文本。
在分析侧，审查智能体现在可以使用 Copilot 开发工具包里的完整命令行工具集，在智能体防火墙之后运行。构建命令、测试执行与针对性脚本都能作为一次审查的一部分跑起来。用 GitHub 的说法，这是分析方式的改变，而不是新增一条评审请求流程。
这里必须把证据边界写清楚：上述比例来自 GitHub 内部实验，不等于每个仓库都会得到同样的检出率或成本变化；而且「被处理的意见」并不等于「生产环境里被避免的缺陷」，它衡量的是开发者是否采纳了意见。团队要评估这套能力，还得自己盯一组本地指标：重复误报、逃逸缺陷、审查时延，以及命令行因为评审环境缺少服务、密钥或依赖而失败的比例。
AI 扫描：从单仓库开关变成平台级接口
另一条线发生在 9 月 10 日。GitHub 为 AI 扫描加入了组织与仓库两级表述性状态传递接口：安全管理员可以读取或更新组织级的扫描配置，仓库管理员使用仓库级路径，请求体里的字段用 enabled 或 disabled 控制是否在拉取请求上扫描。
这让团队可以按风险批量启用，而不必逐个点开界面。组织级禁用时仓库不能自行打开，组织允许时单个仓库仍可退出。这种「上级设边界、下级做选择」的结构，比散落在各仓库的手工配置更容易审计。
但它有几条硬限制。当前版本只在公开站点上公开预览，企业版服务端不支持；需要 GitHub 高级安全与 Copilot 许可，并消耗 AI 额度。检测只在新建拉取请求与每次新提交后运行，直接分析变更代码，可通过代码搜索补充仓库上下文，不要求构建系统，主要覆盖静态分析规则尚未触达或覆盖不足的区域，例如 PHP、Shell 与 Bash、Terraform 的 HCL、Dockerfile、JSP 与 Blazor。
同样重要的是它的边界：发现只出现在拉取请求里，不进入仓库安全页的历史积压；结论是建议性的，不能用于规则集强制阻止合并；模型可能误报；而且它不会读取仓库里的自定义指令文件，例如 copilot-instructions.md 或 CLAUDE.md。也就是说，AI 扫描补的是语义空白，而不是给出确定性证明。
把 AI 审查当门禁之前，先回答几个问题
如果团队打算放权，比较稳妥的顺序是先回答几个问题：哪些仓库的常规校验命令是确定性的、不依赖生产凭证；Copilot 会读取哪个分支上的审查指令——按官方说明是拉取请求的头分支，这意味着审查规则本身也成了被审查代码的一部分；哪些校验需要付费服务或敏感网络，是否该把它们从审查环境里拆出去。
对于成本敏感的集成测试，一种做法是拆出一个快速、无特权的校验目标，把触及付费服务或敏感网络的作业单独隔开。无论审查器变得多能动手，分支保护与安全敏感改动的人工负责人都不应被撤掉。这套更新让 Copilot 的意见更「有测试依据」，但它并没有让评审来源、环境一致性与审批策略变得可选。
几点需要保留的谨慎
其一，Copilot 的审批能力目前处于公开预览，官方文档写明可能变更。把它当作稳定契约来设计流程，风险不小。
其二，「全公司已启用」不等于「漏洞会被自动拦住」。扫描结论是建议性的，规则集强制拦截与人工判断仍然是主防线。
其三，命令行访问让审查环境与持续集成环境的差异成为新的变量。审查会话里跑的命令失败，可能只是环境不齐，而不代表代码有问题；日志与审计需要能区分这两种情况。
其四，审批配置分散在企业、组织、仓库三处文档里，容易漏配。放权前应当把三级配置当成一次正式的变更评审来做，而不是勾一个开关。
各档位是否会跟进集成评审、企业版服务端的支持时间表，以及第三方对误报率与逃逸缺陷的长期数据，目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。