代码审查一直是软件团队”合代码前的最后一道人肉防线”，现在 GitHub 要让 Copilot 从”提意见的 Reviewer”变成”能盖章的人”。9 月 1 日的官方更新里，Copilot 代码审查可以直接批准 Pull Request了。
别急着羡慕或担心，GitHub 自己显然也知道这事敏感：功能默认关闭，要管理员显式开启，审批后只要有新提交就自动作废。AI 从”给建议”到”负责任地放行”，中间隔着一整层安全设计。
一、这次更新到底改了什么
过去 Copilot 做代码审查，主要输出评论：发现问题、给修改建议、指出潜在 bug。这轮升级给审查加了一个新动作——approve，也就是对 PR 给出正式的”同意合并”结论。
具体机制拆开看，有三点值得注意：
- 每条审查自带”合并评估”：Copilot 在给出结论时，会明确标注它认为这个 PR 是否 ready to merge（是否达到可合并状态），而不是含糊地”看起来还行”。
- 审批会自动失效：如果 Copilot 批准之后又有新提交合入这个 PR，它的审批会自动撤销，跟人工 Reviewer 的行为逻辑一致——防止”批完就改、改了没人管”的空子。
- 管理员能限定审批范围：仓库管理员可以限制 Copilot 允许批准哪些文件路径。比如只让它碰测试目录和脚手架代码，核心业务代码不在它的”盖章权限”内。
覆盖范围上，这是 Public Preview（公开预览），面向 Copilot Pro、Pro+、Max、Business、Enterprise 各档套餐，启用入口在企业、组织或仓库三个层级。
二、为什么默认关闭？因为”放行”比”建议”重得多
提意见说错了，Developer 可以不采纳，风险可控；但一个错误的”批准”意味着代码直接进了主干，出问题责任在团队。Copilot 的审批从产品逻辑上就被设计成”默认不给权”：
- 启用权在管理员手里，且要显式开启，不是悄悄上线；
- 权限可细化到文件路径，把 AI 的放行权关进笼子；
- 审批状态可被新提交自动撤销，保持和人工审批同等的严谨性。
这套设计我挺认可。它没有假装 AI 已经可以完全替代人工审查，而是先把”AI 审批”这件事约束在可控范围内，让想用的团队自己评估、自己担责。
三、对团队意味着什么：该不该开，怎么开
先说结论：别全开，挑低风险仓库试点。 判断标准就一条——这个仓库的 PR，合并错了后果重不重？
适合先试的场景有三类：
- AI 自己写代码的仓库。如果你们已经在用 AI 批量生成代码，让 Copilot 审查 Copilot 写的东西，至少能保证风格和基础质量一致，人也省得看几十个雷同 PR。
- 测试、文档、脚手架类 PR。这类变更影响面小，配合路径限制，把 Copilot 的审批权限圈在 test/、docs/ 这类目录里，风险可控。
- CI 已经很强、人工审查只是走流程的仓库。如果你们的自动化检查（lint、测试、覆盖率门禁）已经很严，人工 review 的意义本就在”兜底”而非”找茬”，AI 审批可以先把兜底的活接过去。
不建议一上来就开的：核心业务、涉及资金或用户数据的变更。这类 PR 就算 Copilot 说可以合并，也值得保留一道人工确认——不是不信 AI，是责任需要人来背。
开启路径不复杂：管理员在组织或仓库设置里把 Copilot 代码审查的审批能力打开，按需配置允许批准的文件路径，然后让团队在真实 PR 上观察它的 approval assessment 是否靠谱，再逐步扩大范围。
四、老达点评
这轮更新的真正信号，是 AI 在开发流程里的权限又往前走了一步：从”读代码”到”写代码”，现在到”放行代码”。 回头看我之前梳理的 Anthropic《AI 原生开发手册》——代码不再是瓶颈，六阶段流水线收敛成一个循环——审查环节本来就是那个”循环”里人力残留最多的位置。GitHub 这一刀，正好砍在这。
三个判断供你参考：
1. “审批自动化”的前提是”可审计”。 这功能最聪明的地方不是 AI 能批准，而是它把判断显式化（approval assessment）、可追溯（谁批的、什么时候批的、批完有没有被新提交撤销）。没有这些护栏，AI 审批就是灾难；有了它们，它才是一个可以交给流程的工具。
2. 跟 Copilot 进 Slack/Teams 是同一盘棋。 8 月底 Copilot 刚能在聊天工具里被 @ 着干活，这周又拿到审批权。GitHub 的路线很清楚：让 Copilot 渗透到开发者协作的每一个动作里，从”帮你写”到”替你把关”。对用 GitHub 的团队，这比又换一个新模型实在得多。
3. 别把”AI 批准”理解成”免人工”。 我的建议是把它当成一个筛选器：AI 先过一遍、放行它认为没问题的低风险变更，人工把精力集中在它拿不准的和高风险的 PR 上。人机分工而不是人机替换，才是这轮功能正确的打开方式。
如果你所在团队正在评估要不要开，可以先在 AI编程工具专题 里对比一下各家 AI 审查方案，再结合发布前检查清单那套思路，给自己仓库定一套”AI 能批什么、人必须看什么”的规则。合代码的门，开多大，永远得自己心里有数。这个话题我会持续跟，AI智能体与自动化专题 里已经攒了不少相关实践，感兴趣的可以翻翻。
