9月1日，GitHub在官方更新日志中宣布了一项引发开发者社区热议的变动：Copilot代码评审现在可以正式批准拉取请求。过去，Copilot的代码评审只能提意见、标问题、给建议，最后的合并签字权始终掌握在人类手里；如今，当管理员在设置中开启相应选项后，Copilot提交的批准将与团队成员的批准一样，计入仓库的必需审批人规则，成为满足合并门槛的有效签字。这一功能的公开预览覆盖Copilot Pro、Pro+、Max、Business与Enterprise全部付费计划，被视为AI从"建议者"走向"权威者"的分水岭事件。
GitHub为这项能力设计了相当克制的默认姿态：默认关闭，绝不让存量仓库在不知情的情况下开始接受机器审批。权限控制采用企业、组织、仓库三级架构，企业层可以整体禁止或授权组织自行决定，组织层可以选择全量开启、限定仓库或委托给仓库管理员，仓库层则拥有最细粒度的开关与路径限制。管理员甚至可以指定Copilot的批准只在哪些文件路径下生效，例如文档与测试文件可以交给AI把关，而认证、支付、数据库迁移等敏感路径仍然强制要求人类评审。
功能生效的细节也经过了精心设计。每次Copilot评审都会在总览评论中附带一份"批准评估"，提示模型认为该拉取请求是否已准备好被批准，但评估本身不参与合并计数；只有当管理员开启"允许Copilot提交正式批准"后，模型才会提交可计入必需审批人规则的批准。如果批准后仓库又推入新提交，Copilot的批准会像人类评审者的批准一样被自动撤销，需要重新请求评审才能获得新批准。这种"可以授权、随时可收回"的设计，把机器签字框定在规则允许的范围之内。
与审批功能同步推出的还有多项评审能力扩容。Copilot代码评审此前存在300个文件、2万行的硬上限，如今这个限制被取消，依赖更新、大规模重构这类动辄上千文件的巨型拉取请求也能被完整评审。Copilot还开始支持评审由机器人创建的拉取请求，其中就包括Copilot自身云代理生成的代码。一条"AI写代码、AI审代码、AI批合并"的完整闭环就此成形，虽然提升了自动化程度，却也把独立性与同源风险的讨论推上台面。
行业研究给出的数据加深了这种忧虑。一项覆盖2024年至2026年公开数据的分析发现，至少24.8万个AI署名的拉取请求收到过至少一次AI署名的评审，其中约20.8万个属于同一产品家族内部的"自己人审自己人"。The Futurum Group副总裁米奇·阿什利评价说，批准是代码评审从建议变成权威的那条线，GitHub刚刚让Copilot跨了过去。GitLab的调查也显示，80%的组织采用AI工具的速度快于治理政策的更新速度。当机器既能写代码又能批代码，谁来为最终上线负责，成为团队必须直面的组织问题。
对多数团队而言，Copilot审批更像一把需要谨慎使用的双刃剑。支持者认为，AI评审能显著缓解代码评审的人力瓶颈，CircleCI的2026年数据显示，功能分支吞吐量同比上升59%，而主干分支的合并吞吐量不升反降，AI生成代码的速度已超过团队安全评审的速度，把低风险变更交给AI签字，能让人类把精力留给真正危险的改动。
反对者与治理专家则反复强调同一个原则：可以授权，但必须有边界与审计。他们建议从低风险仓库起步，把批准权限先用路径规则限定在文档与测试文件，运行一段时间并记录AI批准后的问题率，再决定是否扩大范围；敏感路径上保留独立的人类审批，并记录是谁开启了机器审批、范围如何变化。GitHub官方也承认，预览阶段的功能行为仍可能调整，且平台暂不提供审批准确率指标。AI审批究竟能走多远，最终取决于团队能否在效率红利与责任归属之间画出清晰的那条线。
任何治理工具的价值，最终都取决于使用它的组织如何定义边界。GitHub把审批能力设计成默认关闭，本身就是一种态度：平台负责提供机制，团队负责承担责任。对已经启用Copilot评审的企业而言，合理的做法是先在小范围、低风险的仓库试点，把审批权限限定在文档与测试路径，运行一段时间后复盘AI批准后又出问题的案例比例，再决定是否扩大范围；对安全敏感的金融、医疗与基础设施代码，则应始终坚持人类最终把关，让Copilot的签字成为加速手段而非豁免凭证。
更长期的挑战在于可观测性。目前GitHub并未提供Copilot审批准确率的统计面板，团队若想评估机器审批的质量，需要自行记录每次AI批准后的代码变更是否引发回归、事故或返工。第三方工具与审计日志只能记录"谁批了"，无法回答"批得对不对"。可以预见，围绕AI评审质量的度量标准会像当年的代码覆盖率一样，逐渐沉淀为行业共识；而GitHub此次把审批权交给管理员的尝试，正是这场度量革命的第一块试验田。