AI 账单是企业使用大语言模型等 AI 服务后收到的用量费用明细：模型以 token 计价、账务以点数或现金结算，而每一笔费用都应该能归回某个项目。这份指南写给第一次要对 AI 费用负责的工程、财务与管理者。
先给答案：一张 AI 账单只有三层——token 是计价单位、点数是结算单位、逐请求记录是审计单位。账单难读，几乎都是因为其中一层缺了：只有月总额（缺第三层）、各家单位不一致（缺第二层）、或不知道钱花在输入还是输出（缺第一层）。下面逐层拆解，再按角色与异常场景对照使用。
第一层：token 是计价的最小单位
token 大致可以想成字的碎片，一个中文字通常折合一到两个 token。这一层有三个计价事实，决定了你账单的形状。
输入与输出分开计价，输出贵数倍
同样一笔请求，回答越长越贵。控制输出长度（例如约束回复格式）是最直接的成本杠杆。
上下文越长越贵，每一段背景都在计费
你贴进提示的每一份文档、每一轮历史对话都算输入 token。输入异常肥大，多半是上下文塞了不必要的内容。
缓存命中另计费率，重复前缀可以省下大半
重复出现的系统提示与文档前缀，命中缓存时费率远低于新内容。各家供应商的公开费率页都把这三件事列成表格，例如 OpenAI 的定价页；同一句话交给不同模型，成本可能相差几十倍——各模型的计价模式可在模型目录对照。
所以比起盯着单价表，更实用的内部指标是每千次调用的平均成本：它同时反映模型选择、提示长度与缓存策略。多步 agent 还要搭配每次完成任务成本——见什么是 agent tax。
第二层：点数把多家费率换成同一种单位
同时使用多家模型时，每家的币种、费率表、计价逻辑都不同，财务会收到好几种语言写成的账单。点数制的意义在此：先充值，各模型按费率扣点，所有消耗最后落在同一种单位上。
为什么需要同一种结算单位
点数不是价格魔术，而是把「不同供应商的计价逻辑」翻译成财务看得懂的同一种语言；预算、对账、趋势分析才有共同基准。运作细节见点数文档。
低水位告警让服务不会中途断线
配合余额告警与自动充值，「跑到一半没额度」就从事故变成一条通知。
第三层：逐请求归账是最小的可审计单位
一张看得懂的账单，最小单位不是「这个月」，而是「这一次调用」。
一笔逐请求记录长什么样
月报只能告诉你花了多少，回答不了「谁、为了什么」。逐请求记录把每一笔调用都写下项目、密钥、模型与 token 数：
{
"request_id": "req_01HZXK3T9",
"project": "support-bot",
"model": "claude-sonnet-5",
"input_tokens": 1284,
"output_tokens": 412,
"cost_credits": 0.0087
}
归账质量由密钥决定
如果多个系统共用一把密钥，上面那笔记录能告诉你模型与成本，却永远说不出是哪个团队。项目密钥与逐请求归账其实是同一个功能：密钥替每笔请求盖上主人的章，记录让这个章日后可审计。这也是企业 AI 治理清单把「一个项目一把密钥」放在第 1 项的原因。字段与报表见用量与费用。
按角色：工程、财务与管理层各看哪一层
工程看第一层：token 结构
输入输出比例、缓存命中率、模型选择——三个数字决定单位成本能不能再降。
财务看第二层：点数与充值节奏
一种单位、一份账单、可预测的充值周期；异常留给第三层去查。
管理层看第三层的汇总：项目维度趋势
按项目汇总的月度趋势，是续批 AI 预算时唯一站得住脚的依据。
按场景：三种常见的账单异常
费用突然跳升——先按项目排序，再往模型钻
九成的跳升集中在单一项目——这也是上线后 AI 账单为什么会炸的同一种模式；逐请求记录能在几分钟内把范围缩小到一个模型、甚至一段上线时间。
输入 token 异常肥大——检查上下文组装逻辑
常见元凶是「把整份文档塞进每一轮对话」；修法通常是改用摘要或检索。
余额不足导致中断——设告警水位与自动充值
把「还剩多少点数」变成仪表盘上的日常数字，而不是事故报告里的第一行。
更现代的做法：用 ATP Token 把归账变成默认值
上面三层，逐层自建都做得到，但更现代的做法是让平台默认就长这样：项目密钥决定归属、每笔请求自动写入记录、所有模型以点数结算——工程不用改调用方式（兼容 OpenAI、Anthropic 与 Gemini 格式，换 base_url 即接入），财务每月只看一份账单。
延伸阅读
账单不该是月底的惊喜，而是日常就看得到的仪表盘。三层都对上之后，「AI 花了多少钱」就从一个难题，变成一个查询。