WorkbuddyAPI 账单怎么按项目对账？共用主账号按量计费时如何拆出每个项目的真实消耗？

WorkbuddyAPI 账单按项目对账的标准做法是密钥隔离、明细归集、差额校验三步：为每个项目分配独立 API Key，导出请求级用量明细按密钥归集，再用调节表把明细汇总与账单总额对齐。这套方法适用于能拿到请求级明细、且项目可以独立授权密钥的账户；如果整个团队共用一个主密钥、平台只提供月度汇总账单，那就只能按调用量比例分摊，结果只能用于内部估算，不能作为结算依据。 对账精度由密钥粒度决定，而不是由账单科目决定。WorkbuddyAPI 这类按量计费账单通常只给到模型、时间和总额三个维度，项目是业务概念，平台并不知道哪一次调用属于哪个项目。所以拆分动作必须发生在调用侧：一个项目一个 Key，Key 名称里写清项目代号、环境和负责人，让账单上的密钥字段本身就能读出来归属。 共用密钥的项目只能靠标签还原，而还原能力取决于网关日志是否落库。做法是在 API 网关或中转层统一注入 project_id、业务线、调用人三个字段，随每次请求写入日志表，日后按字段聚合即可。没有网关的项目退一步在请求头里带业务标签，但要清楚标签可能被客户端改写，只适合内部互信环境，不适合对外结算。 导出的明细至少要有六列：时间、密钥、模型、输入输出 token、单价或金额、请求 ID。缺少单价列时用账单附带的模型单价表回算金额，不要拿官网当期价格替代，两者可能已经调整过，回算出来的数和账单对不上。请求 ID 是后续逐条比对和申诉的唯一凭据，导出时务必保留，不要只导汇总行。 归集顺序是先按密钥分桶，再把共用密钥的部分按标签二次拆分，拆不动的统一进未分配池。未分配池是判断对账质量的核心指标：占比很小说明打标完整，持续偏大则说明有人在用个人密钥或共享密钥跑项目。每月把未分配池对应的密钥清单拉出来，逐个补标签或直接回收，比事后猜账有效得多。 明细汇总和账单总额之间一定存在差额，来源基本固定在四类：赠送额度与测试金、缓存命中或批量折扣、阶梯计价、退费与调账。把这四类逐项列成调节表，每一笔差额都要能落进其中一类。落不进去的，要么是明细导出漏了时段或模型，要么是账单侧存在未告知的计费项，需要带着请求 ID 找平台核对。 赠送额度和测试金必须在对账前单独剔除，否则项目成本会被系统性低估。处理办法是把它当作独立的抵扣行，不参与项目分摊，只对真实现金消耗做归集。项目报表同时给出含赠送和不含赠送两个口径，前者用来看用量趋势，后者用来做成本核算和内部结算。 包月席位、预留额度这类与调用量无关的固定成本，按用量比例分摊而不是平均分摊。分摊比例优先用 token 数，其次用调用次数，选与成本动因最接近的那一个，并把选择的理由写进对账说明。分摊规则一旦确定就冻结一个完整账期，中途改口径会让前后两个月的数据不可比，也容易在部门之间产生争议。 重试和失败请求产生的重复计费要单列，不能混进项目消耗。做法是按请求 ID 去重，同一个 ID 多次出现只计一次，多出来的部分进异常损耗科目。如果平台侧已经实际扣费，先留存日志证据再提交申诉；申诉期间这笔钱仍然挂在对应项目上，否则账实不符，结账后更难追。 对账节奏建议日监控、周归集、月核对。日粒度只看异常，比如某个 Key 的单日消耗明显偏离近七日均值；周粒度检查打标缺失和未分配池变化；月度做最终调节表并与账单逐项勾稽。三个节奏使用同一套字段和同一张映射表，避免月中临时改表结构导致历史数据断裂。 含税或多币种账单要先统一到不含税本位币再分摊。汇率取账单日汇率并记录在调节表里，不要用月度均价倒推，也不要在不同项目上混用两种口径。跨区域团队共用一个账户时这一点尤其关键，口径不统一会让项目之间的成本比较完全失真。 对账完成的标准是三张表勾稽成立：项目消耗表、未分配池表、账单调节表。勾稽关系是项目消耗加未分配等于明细汇总，明细汇总加减抵扣项与调节项等于账单总额，两边都对得上才算结账。只对上总额却没解释清差额的，属于形式上平账，下个月同样的问题还会原样出现。