Copilot 代码评审的隐藏成本：两个计量表
数据截至 2026-07，价格与限额以各官网为准。
很多团队把 Copilot 的代码评审当成”订阅里附赠的功能”，一开就是全仓库自动触发。真实情况是它同时挂在两个计量表上：一个是 AI 用量（credits 或 premium request），另一个是 GitHub Actions 分钟数。只盯着其中一个看，月底账单一定和预期对不上。
更麻烦的是，这件事在 2026 年 6 月刚刚改过一次规则，网上大量教程还停留在旧口径。如果你搜到的文章通篇在讲”premium requests 用完了怎么办”，先确认它是什么时候写的——对大部分人来说，那套算法已经不适用了。
先分清你在哪套计费制度上
这是理解成本的前提，搞错了后面全错。
2026-06-01 起，全部 Copilot 计划转为按用量计费（usage-based billing），用 GitHub AI Credits 替代原来的 premium requests 计数。credits 的换算很直白：1 credit = 1 美分（$0.01）。用量按 token 消耗计算，输入 token、输出 token、缓存 token 分别计，再按各模型对应的 API 费率折算成 credits 扣减。
也就是说，新制度下”一次代码评审扣几次请求”这个问题本身就不成立了——它扣的不是次数，是这次评审实际吞掉的 token 量。同样是一个 PR，改了三行和改了三百行，成本差得很远；同样的 diff，你选的评审模型不一样，费率也不一样。
但有一批人还在老制度上：
- 月付的 Pro / Pro+ 用户，已在 2026-06-01 自动迁移到 credits。
- 年付的 Pro / Pro+ 用户，在当前计划到期之前仍然走 premium request 制。
对这批年付用户，有一条容易被忽略的变化：2026-06-01 起模型倍率上调，Copilot code review 的模型倍率是 13——也就是说，每触发一次 PR 评审或 IDE 内的代码评审，扣掉 13 个 premium request。
13 这个数字值得停下来想一秒。如果你习惯性地在每个 PR 上点一次评审，再在 IDE 里对着改动点几次，一天下来就是几十上百个 premium request 出去了。很多年付用户之前的心理账本是”一次交互 ≈ 一次请求”，按这个直觉去用 code review，额度掉得会比预期快一个数量级。
第二个计量表：GitHub Actions 分钟数
这是最容易漏的一条：code review 自 2026-06-01 起同时消耗 GitHub Actions 分钟数。
它的意义在于，评审的成本不再只落在 Copilot 那条账上，还会落到你组织的 Actions 用量里。这带来两个实际后果：
第一，账单的锅可能算错人。你看到 Actions 分钟数突然上涨，第一反应通常是去查 CI 流水线是不是哪个 job 变慢了、是不是有人加了矩阵构建。查半天找不到原因，因为涨的那部分根本不是 CI，是代码评审。
第二，两条额度会互相拖累。如果你的组织本来 Actions 分钟数就贴着上限走，打开全仓库自动评审等于凭空又加了一份消耗，可能在你完全没意识到的情况下把 CI 卡住——而 CI 被卡住的表现是构建排队或失败，看上去和 AI 功能八竿子打不着。
所以核算 Copilot code review 的成本时，正确的做法是同时打开两个面板：Copilot 的计费面板，和组织的 Actions 用量页。只看前者会系统性低估。
各档包含多少额度
下面这张表是第三方公开资料的汇总口径，具体数字以 GitHub 官方计费页为准，这里列出来只是给个量级感：
| 计划 | 月费 | 包含额度 |
|---|---|---|
| Pro | $10/月 | 含 $15 credits |
| Pro+ | $39/月 | 含 $70 |
| Max | $100/月 | 含 $200 |
| Business | $19/用户/月 | 约 1,900 credits/用户 |
| Enterprise | $39/用户/月 | 约 3,900 credits/用户 |
几个读表要点：
- 付费档的基础额度大体和价格对得上，GitHub 另外还加了一份浮动的 flex 额度，所以实际可用总额可能比表里更高。这也意味着你不能拿表里的数字去做精确预算，只能当下限参考。
- Business / Enterprise 走的是组织池化余额，不是每人一份独立钱包。池化的好处是重度用户和轻度用户互相调剂，坏处是几个人的异常用量能把全组织的余额吃掉，而其他人往往到被阻断那一刻才知道。
- 未用完的额度不结转，每个自然月 1 号重置。所以”这个月省着点，下个月好好用”这种策略是无效的。
2026-09-01 这个日子要记一下
如果你是既有的 Business 或 Enterprise 客户，现在看到的额度很可能不是常态值。
GitHub 给既有 Business / Enterprise 客户在按量计费的头三个月（2026-06-01 至 2026-09-01）提供了更高的促销额度：Business 3,000 credits/用户、Enterprise 7,000 credits/用户。促销结束后回落到标准的 1,900 / 3,900。
对 Business 来说，这是从 3,000 掉到 1,900，少掉约三分之一；Enterprise 从 7,000 掉到 3,900，几乎腰斩。
所以现在（7 月）最该做的一件事是：去 Copilot 计费面板看”预测用量”那个数。如果当前用量已经明显超过 1,900（或 3,900）这条线，那么 9 月开始你就会开始产生超额费用，而团队的使用习惯是在促销额度下养成的，不会自己缩回去。留出一到两个月去调整策略，比 9 月账单出来再救火好得多。
具体要不要调、怎么调，看你自己的用量结构，这篇不替你下结论。但至少要知道 9 月 1 号那天会发生什么。
额度用完会怎样：没有降级，只有阻断
这一节的结论可能和你的直觉相反。
额度耗尽时没有自动降级到便宜模型的机制。 不少人会假设”用完了系统会自动切个小模型继续跑，只是效果差点”——不会。如果你不允许超额，就是直接阻断到下个计费周期。
超额部分由管理员通过美元预算来控制，扣减规则还是那个 $0.01 一个 credit（$10 的预算 = 1,000 credits）。预算可以设在四个层级：
- user（单个用户）
- cost center（成本中心）
- enterprise spending limit（企业级支出上限）
- organization（组织）
有一条要特别提醒：把某个用户的预算设为 $0，会立即阻断该用户。 这不是”限制到基础额度用完为止”，而是立刻停。管理员在做预算收紧的时候很容易误把 $0 当成”不允许额外超支”的意思，结果一保存，那个人的 Copilot 当场不能用了。
给管理员的实操建议：
- 先别急着一刀切设限。观察一到两周，看用量分布是集中在少数人还是全员平均。
- 要收紧，优先用组织级或成本中心级的预算兜底，而不是给个人设 $0。
- 如果确实要限制某个人，设一个小额（比如几美元）而不是 0，至少他还能收到”快用完了”的信号，而不是直接失联。
把评审成本降下来的几个方向
前面讲的都是账怎么算，这里给几条实际能动的。这些做法是否适合你的团队，要看你们的评审文化，不存在一套通用最优解。
别开全仓库无差别自动评审。 这是成本失控最常见的单一原因。文档改动、依赖版本号 bump、格式化 PR 这类改动过 AI 评审的价值很低，但一样烧 token 和 Actions 分钟。用路径过滤或标签，把自动评审收窄到真正的业务代码目录。
控制 diff 规模。 credits 制下成本直接和 token 挂钩，一个动了两千行的巨型 PR，评审成本会显著高于拆成几个小 PR 分别评审——但小 PR 数量多了，触发次数也多。这里有个权衡点，不同团队的最优拆分粒度不一样，建议先跑两周实际数据再定规矩，别凭感觉。
IDE 内评审要留意重复触发。 IDE 里的代码评审和 PR 上的评审是分别计量的。如果开发者在 IDE 里反复点评审调整代码，然后提 PR 时又走一遍自动评审，同一批改动实际付了两次以上的费用。对年付用户来说，这就是一次 13 个 premium request 的事，点几下就出去了。
把评审当补充而不是替代。 AI 评审擅长发现明显的空指针、遗漏的错误处理、命名不一致这类问题，但对架构合理性、业务语义正确性这些真正值钱的判断帮助有限。如果因为开了 AI 评审就减少人工 review 的投入，省下的钱和引入的风险不成比例。
不适用的场景
有几种情况，认真算下来可能就不该用 code review 这个功能：
- 仓库以配置、文档、数据文件为主：AI 评审在这类内容上产出的意见质量普遍不高，付两份计量的钱不划算。
- 团队本身 review 文化很强：如果每个 PR 本来就有两个人认真看，AI 那层增量价值有限。
- Actions 分钟数已经紧张：前面说过，这会挤压 CI。先解决 CI 的额度问题，再考虑加评审。
- 对 diff 内容上传有合规顾虑的项目：这属于另一个维度的判断，和成本无关，但同样要在开功能之前想清楚。
关于本文数字的来源说明
这篇里的额度表来自第三方公开资料的汇总口径（GitHub 官方 pricing 页未逐字核对），具体数字请以 GitHub 官方计费页为准。计费制度变更、credits 换算、模型倍率、Actions 分钟数消耗、预算层级与阻断行为，来自 GitHub 官方博客与文档。由于计费规则在 2026 年内已经改过一次，做预算前建议再去官方页面确认当次数值，本文不作承诺性结论。
小结
Copilot code review 挂在两个计量表上：AI 用量（credits 或年付用户的 premium request）和 GitHub Actions 分钟数，核成本必须两个都看。2026-06-01 起的 credits 制按 token 计费，1 credit = 1 美分；仍在年付计划里的用户走旧制，code review 模型倍率是 13。既有 Business / Enterprise 客户的高促销额度在 2026-09-01 到期，现在就该去计费面板看预测用量，那个数大致就是 9 月账单。额度耗尽不会自动降级，只会阻断，而把用户预算设成 $0 是立即生效的阻断而非软限制。真要控成本，先收窄自动评审的触发范围，比事后调预算有效得多。