团队的 AI 编程预算怎么规划：三种计费模型下的算法
数据截至 2026-07，价格与限额以各官网为准。
团队的 AI 编程预算之所以经常做飞，不是因为算错了单价，而是因为把一件按用量浮动的事，用”人数 × 月费”这种固定成本的算法去做了。2026-06-01 之后 GitHub Copilot 全线转为按用量计费，这个错法会更明显：席位费只买到一份包含额度，超出部分是另一条曲线。预算规划的正确起手式，是先判断你买的是哪一种计费模型，再套对应的公式。
先承认一个很普遍的误解：不少团队在做年度预算时，把 AI 编程工具当成和 Jira、Confluence 一类的东西——按人头买席位，签一年，成本在年初就锁死了。这个心智模型在 2025 年大体成立，但现在已经不完全对。当计费口径从”每人每月固定几美元”变成”按 token 消耗折算额度”，你的支出就从一条水平线变成了一条跟团队活跃度、模型选择、代码库规模同步波动的曲线。预算表里如果只有一个固定数字，那不是预算，是许愿。
三种计费模型，先分清你在哪一种里
市面上的 AI 编程工具，收费方式大致可以归成三类，各自的预算算法完全不同：
- 纯席位制：按人按月收固定费用，用多用少一个价。优点是预算好做，缺点是重度用户和几乎不用的人同价，人均效率差异被掩盖。
- 订阅含额度 + 超额按量：交一份月费，里面包含一定额度，超出部分继续计费或者被阻断。这是目前主流形态，Copilot 现在就是这一类。
- 纯按量制：不收月费，只按调用量结算，典型是各家的 API 直接调用。
这三类的预算算法不能混用。第一类算的是”人数”，第三类算的是”量”，第二类最麻烦——它同时受这两个变量影响，而且中间还有一个”包含额度”的缓冲带，缓冲带内边际成本为零，出了缓冲带边际成本立刻变成正数。很多团队预算失控就发生在这条边界上。
模型二怎么算：把 Copilot 的额度换算成可比口径
从公开资料看，Copilot 在 2026-06-01 起把原来的 premium requests 计数换成了 GitHub AI Credits，官方博客与文档都做了说明。这里有一个对做预算极其关键的换算关系：1 credit = 1 美分（$0.01），用量按 token 消耗（输入、输出、缓存 token）依各模型的 API 费率折算。
有了这个换算，“额度”这个抽象单位就能被翻译成钱，预算才可能算得动。按第三方公开资料汇总的口径（具体请以 GitHub 官方计费页为准）：
| 计划 | 月费 | 包含额度 |
|---|---|---|
| Pro | $10/月 | 含 $15 credits |
| Pro+ | $39/月 | 含 $70 |
| Max | $100/月 | 含 $200 |
| Business | $19/用户/月 | 约 1,900 credits/用户 |
| Enterprise | $39/用户/月 | 约 3,900 credits/用户 |
注意看规律：付费档的基础额度大致等于其价格本身（Business 的 1,900 credits 按 $0.01 折算正好是 $19），GitHub 在此之外另加了一份浮动的 flex 额度，所以实际可用总额可能比表里更高。这条对做预算的含义是——不要把包含额度当成天花板去做保守估计，也不要当成一个精确常数去做精细规划，它只是一个基准线。
Business 和 Enterprise 还有一个结构性差异：额度是组织池化的，不是每个人守着自己那一份。这意味着团队里三个重度用户吃掉五个轻度用户的余量，在池化模式下是被允许的，账面上不会有人被单独卡住。做预算时这反而是好事，你只需要估团队总量，不需要逐人估。
模型二的实际算法：四步
第一步，先测，别先估。选一个真实迭代周期（建议两到四周），让团队照常工作，然后去计费面板读实际消耗。任何脱离实测的人均消耗估算都不可靠——不同团队的代码库规模、上下文大小、模型选择差得太远，别人的经验数字搬过来大概率不成立。
第二步，把实测值折算成美元。用 1 credit = $0.01 把周期消耗换成钱，再按自然月折算成月度值。这里要留意计费周期口径：额度不结转，每个自然月 1 号重置，所以跨月的样本要按月切开来看，不能简单平均。
第三步，算缓冲带的溢出量。公式很直白：
月度净支出 ≈ 席位费总额 + max(0, 团队月总消耗 − 团队包含额度总和)
团队包含额度总和 = 人数 × 该档包含额度
举个纯算术的例子（单价按上表第三方口径，实际请以官方计费页核对）：50 人的 Business，席位费是 50 × $19 = $950/月，包含额度池按 50 × 1,900 = 95,000 credits，也就是价值 $950。如果实测月消耗是 12 万 credits，溢出 25,000 credits，即 $250，那么月度净支出约 $1,200。这个”溢出比例”（这里是约 26%）才是你真正要在预算里逐月跟踪的指标，而不是席位数。
第四步，给溢出比例留波动区间。上线新项目、大规模重构、集成测试周期，这几类事件都会推高消耗。预算表里应该有一个乐观值和一个悲观值，中间的差额就是你要跟财务申请的弹性额度。
超额怎么刹车：四个层级和一个要小心的设置
按公开资料，管理员用美元预算来控制超额，按 $0.01/credit 折算——也就是说 $10 的预算等于 1,000 credits。预算可以设在四个层级上：user、cost center、enterprise spending limit、organization。
层级的存在是为了让你把”总量控制”和”个体控制”分开做。实践上比较稳的组合是：在 organization 或 enterprise 层设一个总闸，保证任何情况下账单不会超过财务批准的天花板；在 cost center 层按项目组分账，方便事后归因；user 层则尽量不设死，因为下面这条：
**把某个用户的预算设为 $0，会立即阻断该用户。**这不是”降级”，也不是”警告”，是直接停掉。如果你的初衷是”先不给这个人开支出权限”，那结果确实符合预期；但如果你只是想把某人的用量控制得紧一点，误设成 $0 就等于把工具从他手上收走了，而且大概率是在他正忙的时候。
还有一条必须写进预算方案的机制：额度耗尽时没有自动降级到便宜模型的机制。有些人凭直觉以为超额之后系统会自动切到更省的模型继续提供服务——不是这样，不允许超额就直接阻断到下一个计费周期。这条对预算规划的含义是：如果你把总闸设得太紧，得到的不是”省钱”，而是”团队某天下午集体停工”。总闸的作用是防灾，不是日常调节手段，日常调节要靠用量监控和预警，不能靠硬阻断。
2026-09-01 这道坎：促销额度会回落
这是当前最容易被漏掉、也最有时间敏感性的一条：既有的 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、8 月按当时的账单做全年预算，9 月之后的实际支出会明显高于你的预测值，而且原因不是团队用得更多了，纯粹是缓冲带变窄了。
具体该做什么：在 9 月之前去 Copilot 的计费面板看”预测用量”这个数。促销期内你看到的实际扣费可能很低甚至为零，但预测用量反映的是真实消耗规模——它才是 9 月之后的账单基础。用这个数去套上面第三步的公式，重算一遍溢出量，你就能提前一个月知道预算要不要追加，而不是等 10 月账单出来才发现。
还在老制度上的人：年付是另一套账
有一类情况容易被漏在预算表外：月付的 Pro / Pro+ 用户在 2026-06-01 自动迁移到新制度，但年付的 Pro / Pro+ 用户在计划到期前仍然走 premium request 制。
也就是说，同一个团队里可能同时存在两套计费口径，年付那部分人的消耗不能用 credits 的公式去算。针对年付用户还有两条细节值得记进预算备忘：
- 2026-06-01 起模型倍率上调，例如 Copilot code review 的模型倍率是 13——每次 PR 或 IDE 里的代码评审要扣 13 个 premium request。如果团队把 AI 代码评审做成了强制流程，这一项的消耗会比人的直觉高不少。
- code review 自 2026-06-01 起同时消耗 GitHub Actions 分钟数。这是个很容易漏记的计量项，因为它不出现在 Copilot 的账单里，而是记在 Actions 那一栏。预算表如果只盯着 Copilot 这一行，这部分支出会变成”莫名其妙涨上去的 CI 费用”。
处理建议是：在预算表里给年付用户单开一行，标注到期时间，到期时统一切换算法。别让两套口径混在同一个平均值里，那会让两边都算不准。
模型一和模型三怎么算
纯席位制最简单：人数 × 单价 × 月数，加一个人员变动系数（招聘计划、外包周期）。风险不在算法上，在采购决策上——固定成本模式下，闲置席位是纯浪费，所以季度性地核一次实际活跃率比精算单价更有价值。
纯按量制（直接调 API 的场景）的公式是：月支出 ≈ 月请求数 × 平均每次 token 数 × 单价。三个变量里最难估的是”平均每次 token 数”，因为它跟你塞进上下文的内容量强相关。可操作的做法是先跑一周真实流量取样本，再按业务增长曲线外推，同时在网关层做用量记录，不要依赖厂商账单的月末汇总——那时候钱已经花掉了。关于监控这一层的具体做法，可以看 API 成本怎么监控？用量告警与预算护栏。
顺带说明一个前提：如果你的方案里包含海外厂商的 AI 服务，这几家官方并未把中国大陆列为受支持地区，注册、控制台与 API 端点都在境外。做预算时这是一个准入前提问题，不是网络优化问题；本文不提供也不背书任何第三方中转渠道，具体以各官网当前的地区政策页为准。团队做技术选型时，把这条写进可行性评估里，比事后补救省事得多。
一份能落地的预算表该长什么样
不用做得很复杂，但下面几行建议都有：
- 席位固定成本行：人数 × 单价，按档位分行（不同人可能在不同档）。
- 包含额度池行：人数 × 该档包含额度，折算成美元，标注促销期与到期日。
- 实测月消耗行：来自计费面板，逐月填，不填估算值。
- 溢出行：第 3 行减第 2 行，负数记零。这一行是唯一真正需要争取弹性预算的部分。
- 年付用户单开行：走 premium request 口径，另标 Actions 分钟数的关联消耗。
- 总闸设置行：记录 organization / enterprise 层设了多少，以及触发阻断后的应急流程是什么。
第 6 行常被忽略，但它决定了事故当天你有没有预案。既然没有自动降级机制，那”谁有权限临时提高总闸、多久能生效”就必须提前写清楚，不能等到有人被挡住了再去找管理员。
这套算法算不准的地方
得诚实说局限。第一，上表的各档 credits 数来自第三方公开资料汇总，GitHub 官方 pricing 页未逐字核对，做正式采购决策前请以官方计费页当前显示为准。第二，flex 额度是浮动的，意味着你的实际缓冲带比公式里的常数更宽也更不确定，这会让预测系统性偏保守——偏保守比偏乐观好，但也别因此过度采购。第三，按 token 折算意味着模型选择直接改变成本，团队换一次默认模型，历史实测样本就部分失效了，需要重新取样。第四，计费规则本身在 2026 年内已经变过一次，任何基于当前规则的年度预算，都应该预留”规则再变”的复盘节点，建议至少一个季度回看一次。
小结
判断你买的是席位制、订阅含额度制还是纯按量制，这一步比算单价重要，因为三者的公式根本不同。Copilot 现在属于第二类，1 credit = $0.01 是把额度翻译成钱的关键换算，预算的核心指标是”溢出比例”而不是席位数。超额控制有四个层级，总闸用来防灾不要当日常调节手段，因为额度耗尽是直接阻断、没有自动降级。促销额度在 2026-09-01 到期后 Business 回落到 1,900、Enterprise 回落到 3,900，务必在此之前去计费面板看预测用量重算一遍。年付用户仍在 premium request 制上，单开一行算，别忘了 code review 还会吃 Actions 分钟数。