审得最严、还能直接放行：Copilot 代码评审 Max 档位与审批正式上线

10 月 28 日，GitHub 在官方 Changelog 上宣布了 Copilot 代码评审的两项变化：新的 Max 评审档位进入公开预览，Copilot 审批（approvals）正式全面可用。两件事合在一起，意思很直接：Copilot 不再只是“帮你看看代码有没有问题”，而是可以在条件满足时直接给合并放行。这一步跨得不大，但性质变了——评审从“提建议”变成了“参与决策”。对每天都要合并不少 PR 的团队来说，这篇就是讲这一步到底改变了什么、以及放行权交给 AI 之前要先立好哪些规矩。

先把事实说清楚。Copilot 代码评审原来有两个档位：Lite 和 Balanced，Max 是第三档，定位是最彻底的一档。它的做法不是让一个模型更努力，而是同时跑多个独立的评审智能体，分别用不同厂商的模型，每个模型从自己的角度审一遍，再由一个汇总智能体把结果合在一起：调和分歧、核对准确性，最后输出一份统一的评审。GitHub 的说法是，这是 Copilot 覆盖面最广的一档，尤其在关键问题上，同时保持噪音较低。代价也写得很明白：Max 做的工作更多，所以更慢、消耗的 AI 点数也比 Lite 和 Balanced 多。

审批则是另一件独立的事。Copilot 评审一直会在 PR 概览评论里给一个“是否可以合并”的评估，现在这个评估可以变成真正的批准：开启审批后，Copilot 的批准会计入仓库要求的批准数。机制上它和人类评审员的批准行为一致：批准之后如果又推了新提交，批准会被撤销，需要重新请求评审才能拿到新的批准。还有两个关键默认值：审批默认是关闭的，需要管理员在企业、组织或仓库层面手动开启；仓库管理员还可以指定 Copilot 有权批准的文件路径范围。换句话说，放行权不是一开全开，而是可以按路径收紧的。

Max 档位适合什么，不适合什么

GitHub 对 Max 的定位说得很具体：适合那些“漏掉问题代价最高”的改动，比如认证逻辑的改动，或者多个服务共同依赖的共享库。反过来，日常的小改动、文档改动、纯样式调整，用 Max 就是浪费：更慢、更贵，收益却不明显。档位的选择可以在三个层面定：单个 PR 从评审员栏里选一次，仓库、组织、企业层面可以设默认档位，而且每一层都可以覆盖上一层。管理员还可以设一个最高档位上限，超过这个上限的档位在该范围内就不可用。这套分层规则的实际意义是：团队可以把 Max 锁在真正高风险的仓库和路径上，而不是让所有人、所有 PR 都默认跑最贵的一档。

多智能体评审这个做法本身也值得拆开看。不同模型的长处和盲点不一样，多个模型各审一遍，确实能抓到单个模型漏掉的问题；但汇总智能体调和分歧的方式，决定了最终评审的质量下限。如果汇总只是“少数服从多数”，那一个模型发现的关键问题可能被另外两个没发现的模型投掉；如果汇总是“宁可误报、不漏关键”，那噪音又会回来。GitHub 说汇总会“核对准确性”，但没有展开核对的标准和流程。这部分目前只能当作厂商说法，团队上线后要自己抽查：连续看两周 Max 的评审，数一数它报的问题里有多少是真问题、有多少是噪音，再决定它值不值这个价。

还有一个容易被忽略的细节：Max 的“最彻底”是有边界的。它审的是 PR 里的改动，不是整个系统。跨服务的连锁影响、灰度发布后的真实表现、业务逻辑对不对，这些都不在一次代码评审的视野里。把 Max 当成“最严的一道关”是对的，把它当成“合并就安全”的保证是错的。评审档位升得再高，也替代不了测试、灰度、回滚和值班。

审批权交给 AI 之前，先立好四条规矩

第一条，按路径设权。仓库管理员可以指定 Copilot 有权批准的文件路径，这个功能一定要用起来。建议的起点是：只给低风险路径开审批，比如文档、测试、纯前端展示层；认证、支付、权限、数据迁移、共享库这些路径，先不给，或者只给“评审 + 人类复核”的组合。路径清单要写进仓库的评审规范里，而不是只存在管理员的设置页面上，否则新人接手时没人知道为什么这样设。

第二条，批准数不能只靠 AI。Copilot 的批准可以计入仓库要求的批准数，但这不等于“一个 AI 批准就够了”。建议至少保留“人类批准”的硬性要求：关键路径的 PR，必须有一个人类批准，AI 批准只能算附加分，不能替代人类。否则团队会慢慢养成“AI 说了可以合并”的习惯，人的评审能力会在不知不觉中退化。评审的意义不只是抓 bug，更是让团队成员理解代码在变什么，这部分 AI 替代不了。

第三条，新提交撤销批准的机制要用好，不要绕过去。GitHub 的机制是：批准后推了新提交，批准自动撤销，需要重新评审。这个机制是保护，不是麻烦。团队规范里要明确写清：不要为了“保住批准”而把多个改动攒到一个 PR 里一次性推，也不要在批准后偷偷 force-push 小修补。每一个新提交都值得一次新的评审，哪怕只是改了一行——尤其是改了一行的时候，因为一行改动恰恰最容易藏着“顺手改了逻辑”的风险。

第四条，审批开启后要复盘。建议开启审批的前一个月，每周抽查一次 AI 批准的 PR：它批准的 PR 里，后续有没有出线上问题？它拒绝或者没批准的 PR 里，人类最终是怎么判的？这两组数据跑一个月，团队才能判断审批的阈值是太松还是太严。没有复盘的审批授权，等于把放行权交出去之后再也不看一眼，这是最危险的用法。

成本账：Max 不是免费的“更认真”

Max 的成本要算两笔账。第一笔是 AI 点数：多智能体、多模型、再加一个汇总智能体，一次评审的成本是 Lite 和 Balanced 的数倍。如果团队把 Max 设为所有仓库的默认档位，月底的账单会先告诉你这个决定有多贵。第二笔是时间：Max 更慢，PR 的等待时间会变长。对高风险改动来说，多等几分钟换更严的评审是划算的；对一天要合并不少 PR 的团队来说，全量 Max 会把合并队列拖长，反而逼着大家绕过评审、攒大 PR、一次性推——这些行为对代码质量的伤害，比少审一轮更大。

所以 Max 的正确用法是“定点用”，不是“全量开”。建议的做法是：默认档位保持 Balanced，只在两类 PR 上用 Max，一是改动了认证、支付、权限、共享库等高风险路径的 PR，二是发布前最后一个大版本 PR。怎么判断一个 PR 是不是高风险？最省事的办法是按路径规则自动匹配：PR 里包含高风险路径的文件，就自动建议 Max；不包含，就默认 Balanced。规则写进仓库配置，而不是靠每个人凭感觉选。

还有一个成本是隐性的：评审噪音的成本。GitHub 说 Max 在保持噪音较低的同时扩大了覆盖面，但“较低”是相对说法，不是零噪音。噪音的代价不是多看几条评论，而是团队对评审的信任被消耗：误报多了，开发者会开始批量忽略评审意见，真问题混在误报里也被一起忽略了。上线 Max 之后，要盯着一个指标：评审意见的采纳率。如果 Max 的意见采纳率明显低于 Balanced，说明它的“更彻底”正在变成“更啰嗦”，这时候要收紧使用范围，而不是继续加量。

和本轮另一篇的关系：评审是 harness 落地的一个环节

把这篇和本轮的微软 Copilot harness 篇放在一起看，会发现一条线：10 月 28 日这一天，微软和 GitHub 在讲同一件事的不同层面。harness 篇讲的是底座——模型可以换，管模型干活的那套东西开放出来；这篇讲的是底座上的一个具体环节——代码评审这个环节里，多个模型怎么分工、评审结果怎么变成合并决策。Max 的“多个独立评审智能体 + 汇总智能体”就是 harness 思路在评审场景里的具体样子：不是一个模型包打天下，而是多个模型各司其职，再由一层编排把结果合成一个决策。

对小团队来说，这条线还有一个实际意义：评审环节是验证“多模型协作”最便宜的地方。一次评审的成本是可见的、结果是可抽查的、出错的影响是有限的（最坏是多了一次人工复核）。如果你在考虑要不要把更多环节交给多智能体协作，先从评审环节开始：开 Max、开审批、跑一个月、看采纳率和线上问题数。这一个月的数据，比任何厂商博客都更能告诉你，多模型协作在你的团队里到底值多少钱。

最后，和站内已有的 Copilot 文章划清界限：10 月 19 日的 Copilot 六模型退役与模型政策篇讲的是模型供给和管理员政策；10 月 28 日的 Copilot Fusion 全面可用篇讲的是写代码时选模型这件事交给系统；10 月 28 日的 Copilot Projects 公开预览篇讲的是跨仓库协调多个 Agent 做一整件工作。本文讲的不是写代码、不是选模型、不是跨仓库任务，而是代码写完之后、合并之前的那一关：评审怎么审、审批怎么放。同一天、同系列产品、不同环节，读者按“写代码—评审—合并”这条线读下来，正好是 Copilot 在 10 月 28 日拼出来的完整图景。

一句话总结：Max 让评审更彻底，审批让评审结果可以直接放行，但放行权不是开出来就完事的。按路径设权、保留人类批准、用好新提交撤销机制、每月复盘一次，这四条规矩立好了，AI 评审才是帮团队省时间的工具；规矩没立好，它就是帮团队省掉思考的捷径，而省掉思考的代价，最后总会在生产环境里还回来。

评审意见怎么用：分流比全盘接受更重要

Max 和审批上线之后，团队还要面对一个日常问题：评审意见来了，怎么处理？最省事的做法是全盘接受或者全盘忽略，这两种做法都错。建议把评审意见分成三流处理。第一流是自动修：格式、命名、明显的空指针、未使用的变量，这类意见事实清楚、改动安全，可以直接让 Copilot 或者开发者顺手修掉，不需要开会讨论。第二流是人工复核：涉及业务逻辑、边界条件、并发和性能的意见，必须由熟悉这块代码的人看一遍再决定，因为 AI 评审看的是代码文本，不一定理解业务上下文，上下文之外的“问题”可能是误报，也可能是真问题，机器分不出来。第三流是明确忽略：风格偏好、重构建议、超出本次 PR 范围的意见，记下来、放到后续任务里，不要让一次评审无限扩大 PR 的范围。

分流的标准要写进团队的评审规范，而不是每次现想。更重要的是，分流的结果要回流到档位选择里：如果某类意见长期落在“明确忽略”里，说明这个档位对这个仓库来说太啰嗦了，该降档；如果某类意见长期落在“人工复核且确实是问题”里，说明这个档位有价值，该保持甚至扩大范围。档位不是一成不变的，它应该跟着采纳率数据走。很多团队上线新工具时只做开启动作，不做调档动作，结果就是工具越用越不贴合，最后被悄悄弃用。

小团队落地清单：五步开起来

最后给一张可以直接照着做的落地清单。第一步，先开一个试点仓库，不要全量开：选一个中等活跃度、PR 量适中的仓库，先把 Max 和审批都在这个仓库里打开。第二步，设路径规则：写清哪些路径可以 AI 批准、哪些路径必须人类批准，规则写进仓库文档，设置页面和文档两处对齐。第三步，定默认档位：默认 Balanced，高风险路径自动建议 Max，发布前的大版本 PR 手动选 Max。第四步，跑一个月，盯三个指标：评审意见采纳率、AI 批准 PR 的后续线上问题数、PR 从提交到合并的平均等待时间。第五步，月末复盘一次，根据三个指标调档位和路径规则，再决定要不要推广到下一个仓库。五步走完，团队对“AI 评审值多少钱”就有了自己的答案，而不是厂商给的答案。

审批记录与审计：AI 批过的 PR，事后要能查

审批一旦可以由 AI 做出，审计问题就跟着来了：三个月后有人问“这个 PR 当时是谁批准的”，答案不能是“Copilot”。GitHub 的机制里，Copilot 的批准会像人类批准一样留在 PR 记录里，这是好事，但团队规范里还要补两条。第一，AI 批准的 PR，合并信息里要能一眼看出来是 AI 批准还是人类批准，不要混在一起统计；否则复盘的时候，你分不清“人类评审质量下滑了”还是“AI 批准占比上升了”。第二，关键路径的 PR 即使 AI 批准了，也要留一条人类复核记录——不一定是正式批准，可以是一条“已阅”的评论。复核记录的意义不在当时，而在事后：出问题的时候，你能顺着记录找到当时是谁看过、看到了哪一步，而不是面对一个只有机器批准的空白。

审计还有一个更实际的用途：回答“AI 评审到底帮我们省了多少时间”。省时间的算法不能只算“少等了几小时评审”，还要算“AI 批准的 PR 后续返工花了多少时间”。两边相减才是净收益。建议在复盘表里加两列：一列是 AI 批准 PR 的返工率，一列是人类批准 PR 的返工率，跑一个季度再比。如果 AI 批准的返工率长期高于人类，说明审批开得太宽了，该收紧路径；如果两者差不多甚至更低，说明这套机制真的在帮团队省时间，推广才有底气。数字比感觉可靠，尤其是在要不要扩大 AI 权限这种决定上。

把这句话作为本篇的收尾标准：AI 评审上线一个月后，团队应该能拿出三张表——采纳率、返工率、等待时间——而不是一句“感觉快了不少”。感觉会骗人，表不会。