AI 工具支出审计：先搞清钱花在哪
数据截至 2026-07，价格与限额以各官网为准。
做 AI 工具支出审计，第一步不是砍预算，是先把”钱到底花在哪”这句话回答到能拿出证据的程度。绝大多数团队卡在这一步：财务那边有一笔总额，工程这边有一堆账号，中间没有人能把两者对起来。在对不上的状态下讨论”要不要降本”，砍掉的往往是能报销给你的那部分，留下的反而是真正在漏的那部分。
一个常见的误解是：支出审计等于把各家平台的账单导出来加个总和。加总只能得到”花了多少”，得不到”为什么花这么多、这笔钱换回了什么、下个月会不会更多”。而且账单本身就有陷阱——同一家厂商在一年之内换过计费口径的情况现在并不少见，你手上那张 6 月前的账单和 6 月后的账单，可能压根不是同一个计量体系，直接相加得到的数没有意义。
下面这套流程按实际操作顺序走，做一遍大概占用半天到一天，之后每季度复查一次就够。
一、拉清单：四类最容易漏掉的账
先别打开表格算钱，先把”有哪些账”列全。经验上漏得最多的是这四类：
第一类，个人卡垫付的订阅。 工程师自己先开通、月底走报销，或者干脆没报。这类支出在财务系统里可能挂在”办公费”甚至根本不存在，但它是真实发生的成本，也是真实存在的数据安全敞口——公司代码进了一个公司完全不知情的账号。审计时的做法是发一份自查表，问三个问题就够：用了什么工具、谁在付钱、有没有登录过公司仓库。
第二类，云平台里”顺手开”的 AI 服务。 模型 API、向量库、托管的推理服务，这些通常不单独出账单，而是混在云账单的某一行里。要按服务标签逐项拆开看，不能只看云平台的总额。
第三类，捆绑在别的产品里的 AI 功能。 协作工具、设计工具、客服系统里加的 AI 套件，往往是在原订阅上加价，容易被当成”原来那笔钱”直接放过。
第四类，同一个工具的重复购买。 团队 A 走公司统一采购，团队 B 自己开了个组织，两边的席位互不知情。这类重复在 20 人以上的团队里出现概率相当高。
清单拉全的判断标准很简单：把清单拿给财务，让他对照付款流水勾一遍，勾不上的那几笔就是你还没找到的账。
二、统一口径：订阅和按用量不是一把尺
清单有了，接下来是最容易做错的一步——把不同计费方式的数字放进同一张表。
AI 工具的计费现在大致分三种：固定席位订阅（每人每月多少钱，用多用少一个价）、纯按用量（按 token 或调用次数扣）、以及混合制（订阅里含一份额度，超出部分按量扣）。混合制现在越来越普遍，也最容易算错，因为它同时具备”固定成本”和”可变成本”两种性质。
GitHub Copilot 是个很典型的例子。根据 GitHub 官方博客与文档，自 2026-06-01 起，Copilot 全部计划转为按用量计费，用 GitHub AI Credits 替代了原来的 premium requests 计数，1 credit = 1 美分（$0.01），用量按输入、输出、缓存 token 的消耗，参照各模型的 API 费率折算。
这意味着什么？意味着你在 6 月之前记的账和 6 月之后记的账，计量单位不一样。以前一句提问算”一次请求”，现在算的是这次请求实际吞掉多少 token——同一句话，换个上下文更长的会话、换个更贵的模型，扣掉的额度可以差出一个数量级。如果你的审计表里还有一列叫”本月请求数”，那一列在新口径下已经不能用来推算成本了。
各档包含的额度，按第三方公开资料的汇总口径大致是这样（精确数字以 GitHub 官方计费页为准）：
| 计划 | 月费 | 包含额度 |
|---|---|---|
| Pro | $10/月 | 含 $15 credits |
| Pro+ | $39/月 | 含 $70 |
| Max | $100/月 | 含 $200 |
| Business | $19/用户/月 | 约 1,900 credits/用户 |
| Enterprise | $39/用户/月 | 约 3,900 credits/用户 |
这些数字来自第三方汇总，未与 GitHub 官方 pricing 页逐字核对，做审计时请以你自己账户后台看到的为准。有两点结构性的信息值得记住：付费档的基础额度大致等于其价格，GitHub 另外还加一份浮动的 flex 额度，所以实际可用总额可能比表上更高；Business 和 Enterprise 走的是组织池化余额，不是每人一份独立的钱包，这一点直接影响你下一步怎么拆账。
统一口径的做法是：把所有工具都折算成”每月固定支出 + 每月可变支出”两列。固定列放席位费和最低消费，可变列放实际超额扣款。只看总额看不出风险，看这两列的比例才看得出——可变列占比越高，下个月账单的不确定性越大。
三、把钱拆到人和项目上
总额拆不到人头上，审计就只是一份报表，产生不了任何决策。
拆账有两个维度，都要做。按人拆，是为了发现席位错配：有人每月把额度用得干干净净还要超额，有人三个月没登录过。按项目拆，是为了回答”这个项目的 AI 成本占它总研发成本多少”，这个比例才是跟业务对话时用得上的数字。
具体做法上，池化余额的产品要格外小心。像 Business/Enterprise 这种组织池化的模式，后台看到的是整个组织消耗了多少，不会自动告诉你是谁消耗的——如果平台提供按用户或按 cost center 的用量视图就用它，如果没有，退而求其次的办法是按人分配预算上限，用”谁先撞墙”来反推谁是重度用户。
拆完之后你通常会看到一个很不均匀的分布：一小部分人消耗掉大部分额度。先别急着判断这是浪费。重度使用者可能正是产出最高的那批人，也可能是在用错误的方式反复重试。区分这两种情况要看第五节讲的单位成本，不能只看用量排名。
四、揪出沉默支出
沉默支出是指账在扣、但没有产生任何价值的部分。审计能立刻省下来的钱，八成来自这里。四种典型形态：
离职和转岗后没回收的席位。 这是最常见的一种，也最好查：拿 HR 的在职名单和各平台的席位名单做一次差集。
开通了但从没用过的席位。 大多数平台后台能看到”最后活跃时间”，把超过 30 天没活跃的挑出来，一个个去问，通常能收回一批。
年付和月付的错配。 年付通常单价更便宜，但把人锁住了；月付贵一点，换来的是随时能停。团队规模波动大的时候，年付省下的那点差价未必划算。还有一个容易被忽略的副作用：计费体制变更时，年付用户和月付用户的迁移节奏可能不一样。仍以 Copilot 为例，官方文档说明月付的 Pro / Pro+ 用户在 2026-06-01 自动迁移到新的按用量计费，而年付的 Pro / Pro+ 用户在计划到期前仍然走原来的 premium request 制——也就是说，同一家公司里两个人用着同一个产品，账却是两套体系记的。审计时如果不分开处理，数据一定对不上。
被漏记的关联计量。 有些用量不体现在你盯着的那个额度上。同样按官方文档，Copilot 的 code review 自 2026-06-01 起同时消耗 GitHub Actions 分钟数；另外仅针对仍在老制度的年付用户，2026-06-01 起模型倍率上调，code review 的倍率为 13，即每次 PR 或 IDE 代码评审扣 13 个 premium request。这类”一个动作扣两笔账”的设计，在审计时不专门去找是找不到的。
五、算单位成本，别只盯总额
到这一步，把”每月花了多少”换成”每单位产出花了多少”。分母选什么取决于你的业务，常见的有：每位工程师每月的 AI 成本、每个合入的 PR 的 AI 成本、每千行有效代码的 AI 成本、每张工单的 AI 成本。
这些分母都不完美——PR 有大有小，代码行数更是出了名的不可靠指标。但单位成本的价值不在于绝对值精确，而在于同比：同一个团队、同一个分母口径，这个月比上个月是升是降，升的原因是什么。总额涨了 30% 可能是因为团队扩了 30%，那其实什么也没发生；总额没变但单位成本涨了 40%，那才是需要查的信号。
也要诚实说清这个方法的局限：AI 工具带来的价值里有相当一部分落不到任何分母上——少踩一个坑、少加一次班、新人上手快两周，这些都是真实收益但没法量化。所以单位成本适合用来做横向对比和趋势判断，不适合直接拿来算 ROI 然后据此砍工具。审计的目的是让花钱变得可解释，不是把每一分钱都证明成正收益。
六、审计输出什么
一次审计做完，交付物建议就三样，多了没人看：
一张清单表，列出所有工具、计费方式、当前月支出、负责人、下次续费日期。这张表的价值是长期的，之后每个月更新一次比重做一遍容易得多。
一张异常表，列出这次查出来的问题及处置建议：几个空席位、几处重复采购、哪几个人的用量偏离均值需要沟通。每条都要写清”预计能省多少”，否则推不动。
一份下月预测，这是审计里最有决策价值的一张。混合计费下预测尤其重要，因为你的可变支出可能还没进入稳态。这里有个时间点值得团队现在就去确认：按第三方公开资料的说法，既有 Business / Enterprise 客户在按用量计费的头三个月（2026-06-01 至 2026-09-01）享受更高的促销额度，Business 约 3,000 credits/用户、Enterprise 约 7,000，促销结束后回落到标准的 1,900 / 3,900。这些数字同样来自第三方汇总口径，请以官方计费页和你自己的账单面板为准。它的现实含义是：如果你现在看到的用量水位刚好卡在促销额度之内，那么促销一结束，超出标准额度的部分就会开始扣钱。在 9 月之前去计费面板看一眼”预测用量”，那个数更接近你之后的真实账单。
预测的时候还要把两个机制算进去。一是额度耗尽后没有自动降级到便宜模型的机制——不允许超额的话就是直接阻断到下个周期，不会悄悄给你切个便宜模型继续干活。二是未用完的额度不结转，每个自然月 1 号重置，所以”这个月省下来的留着下个月用”这种打算是不成立的。另外，预算可以设在 user / cost center / enterprise spending limit / organization 四个层级，管理员用美元预算控制超额，按 $0.01/credit 扣减（$10 预算即 1,000 credits）；需要注意把某个用户的预算设为 $0 会立即阻断该用户，别把它当成”零超额提醒”来用。
常见坑 / 注意
- 别把 6 月前后的账单直接相加：计量口径变过的产品，两段数据不是一把尺，要么分段看，要么统一折算成金额再比。
- 别拿”请求数”当成本代理指标：按 token 计费之后，请求数和花的钱之间已经没有稳定关系。
- 池化余额不等于人均额度：组织池是一整笔钱，个别重度用户可以把整个池子吃掉，拆账时要单独处理。
- 年付不一定省：便宜的是单价，代价是锁定期和计费体制切换时的不同步，团队规模不稳时要重算。
- 查沉默支出优先于谈判折扣：先把不该花的停掉，再去谈价格，顺序反了容易白忙。
- 数字以自己后台为准：本文引用的额度数字来自第三方公开汇总，做决策前务必打开你自己的计费面板核对。
小结
支出审计的产出不是一个总数，而是一份能对得上、拆得开、说得清的账。先把清单拉全，尤其是个人垫付、云账单里混着的、捆绑加价的和重复采购的这四类；再把订阅制和按用量换算到同一把尺上，固定支出和可变支出分开看；然后把钱拆到人和项目，用单位成本的同比变化找信号，而不是盯着总额的绝对值。计费口径变更是这两年的常态，Copilot 从请求计数改成 credits 只是其中一例，审计流程要能容纳这种变化，而不是每次都从头重做一遍。最后诚实地说，审计管的是”花得明白”，不是”花得最少”——有些价值本来就落不进任何一个分母里。