学完能做到 知道每月 AI 花在哪、还剩多少余额、成本异常时能定位到是哪个功能在烧钱。
开始之前
- 全档位均可用（起步版起即含，按实际 token 扣费）
- 有平台或管理员权限查看用量
操作步骤
先理解计费单位：元 / 百万 token
单价单位统一成「元/百万 token」，与大模型厂商官网定价表逐字对应。这样抄价不用换算，而换算就是出错的第一步。图像模型按元/张，语音按元/秒。
看清三个价格：输入、缓存命中、输出
同一个模型有三档价：输入（缓存未命中）、输入（缓存命中，通常便宜很多）、输出（最贵）。系统会分别计价再相加。如果某个模型没有缓存差异，命中价就按普通输入价算。
峰谷时段会影响单价
部分厂商分峰谷。系统按北京时间判断是否高峰，高峰期在基础价上乘倍数（比如某厂商高峰是空闲的 2 倍）。价目表里填的永远是基础价，倍数自动生效。所以批量任务安排在闲时能省钱，这是真实可选项。
按场景看用量，而不是只看总额
每一笔 AI 调用都记了业务场景（对话、语音报工解析、拍照计数、计划风险分析等）。月底看「哪个功能在烧钱」，靠的就是这个维度。如果全都记成未知场景，成本分析就做不了——这也是为什么场景字段要认真填。
预付费钱包：余额不足会提醒，不会先斩后奏
余额低于阈值（默认 10 元）会提醒充值，但只提醒不拦截。充值 10 元起，转账后由平台后台确认到账，余额与流水立刻更新。
允许扣成负数，但不会无限透支
计费是事后结算，最后一笔可能超支几分钱，所以余额允许为负。扣负之后下一次调用会被余额检查拦住。这是刻意的设计，不是漏洞——比"突然断掉正在跑的对话"体验好得多。
对账要看流水，不要看余额
每一次充值、消费、退款、人工调账、赠送都有一条流水，带变动前后余额。余额是个汇总值，流水才是事实。客户对 AI 费用有疑问时，逐条流水给他看，比一句"系统算的"有说服力得多。
包月合同客户走另一套：周期额度
签了包月合同（比如每月给 2000 元额度）的客户，用「周期额度」而不是钱包：可以设金额上限、token 上限，超出后的动作可配成「直接拒绝」「只告警」「继续但计超额」。默认是只告警——改成直接拒绝前想清楚，AI 突然不可用会让人以为系统坏了。
容易踩的坑
账单比我自己估的高，是不是算错了？
先看缓存命中。有些网关不返回缓存命中的 token 数，这种情况下系统会全部按未命中价（贵的那个）算。源码注释写得很直白：少收是亏自己，多收会在对账时被发现并退，风险不对称。所以这是有意的保守设计。
为什么不直接按次收费，要按 token？
按次收在大模型上必然亏。问"昨天二车间干了多少"和问"分析近三个月良率趋势"，后者可能是前者几十倍的 token。按次收要么定价过高没人用，要么被长对话打穿。
调价了，历史账单会变吗？
不会。价目表按生效日期分段，历史用量永远按当时的价重算。所以调价要新增一条价目并把旧记录填上失效日期，不要直接改历史记录——改了以后历史账单就无法重现。
客户欠费了，直接删 key 吗？
别删。把钱包状态设成冻结即可，调用会被拒但 key 还能用，充完值解冻，历史配置不用重配。删 key 会导致客户所有集成断掉。
赠送额度怎么记？
走「赠送」类型流水，别直接改余额。直接改余额会让「变动前/变动后」断链，对账时无法解释这笔钱从哪来。