WorkbuddyAPI 账单怎么按项目对账？多个项目共用一个账户时如何核对到每一次调用？

WorkbuddyAPI 的账单能按项目对账的前提，是调用侧已经按项目做了凭据隔离：每个项目使用独立的 API Key，账单即可先按 Key 汇总，再与账户扣费流水勾对；如果多个项目共用一个 Key，账单层面无法还原到项目，只能用分摊方式估算。这个边界决定了后面所有操作的准确度上限。 第一步是建立项目与 API Key 的一一对应关系，这是整条对账链路的起点。做法是按项目、环境、调用方三个维度分别签发 Key，Key 名称带上可读的项目标识，禁止跨项目复用同一把 Key。账单和用量明细通常只记录 Key 维度的消耗，业务归属必须靠 Key 台账映射出来，一旦复用，明细就失去了区分能力。 第二步是确认计费口径，先弄清楚账单金额到底是怎么算出来的。需要分别确认计费单位是按输入与输出 token 分开计价，还是按调用次数计价，不同模型单价是否不同，是否设有最低计费粒度。这些信息在平台的用量与价格说明中可以查到，但不会自动反映在自建汇总表里，口径搞错会让对账表看起来对得上、实际已经错位。 第三步是把用量明细的导出区间与账单周期对齐。用量明细的时间戳按平台时区记录，账单周期也按平台时区切分，如果导出时用本地时区筛选，账单日边界附近的调用就会被算进错误的期。稳妥做法是固定用平台时区导出，并把账单周期首尾各一天的调用单独拉出来核对。 第四步是把明细汇总成一张可复核的项目对账表。这张表至少要含项目、Key、模型、调用次数、输入 token、输出 token、金额七列，缺任何一列都会在差异出现时无法定位。汇总可以用数据透视表或脚本按项目分组求和，再用各项目金额合计与账单总额倒轧，差额就是待查项。 第五步是处理不计费记录，这一步最容易被放大成假差异。失败的调用、被限流拦截的请求、命中缓存的请求是否计费，各平台口径并不一致，必须先从官方说明确认，再用一期真实账单做小样本验证。在口径未确认前就直接从明细里剔除失败记录，会让汇总金额系统性偏低。 第六步是把预付费余额扣减与按量计算金额之间的差额拆成调整项。预付费账户的消耗金额来自余额扣减流水，按单价乘 token 算出来的金额是理论值，两者会因四舍五入、赠送额度抵扣顺序、退款回冲而不一致。正确做法是把赠送金、抵扣券、退款、补扣各自单列成调整项，而不是混进项目消耗里。 第七步是处理确实无法拆分的共用调用，并如实标注。多个项目共用一个 Key 时，只能按可观测比例分摊，例如按网关侧记录的业务标识、请求日志中的来源参数，或各项目历史调用量占比。分摊值和对账表中的实耗值必须分列，否则下一期做趋势对比时会把估算当成事实。 第八步是差异定位与留痕。单期差异在设定阈值内可以挂账到下期，超过阈值就需要逐笔定位到请求 ID、时间戳和模型名，判断是漏记、重复计费还是归属错误。每次对账都要保留导出的原始明细、对账表版本和调整说明，否则跨月追溯时没人能解释某个数字的来源。 第九步是把上述动作固化成月度例行动作，而不是每次临时拼表。可以按固定顺序执行：更新 Key 台账、导出明细、按项目汇总、与账单勾对、列调整项、记录差异、归档，全流程使用同一套模板。导出的具体字段名、路径与账单周期定义以 WorkbuddyAPI 官方说明为准，平台改版时优先核对导出字段是否增减。 最后要接受一个事实：按项目对账的精度上限由 Key 的拆分粒度决定，事后用算法补救的成本远高于事前隔离。项目数量增长后，应把 Key 台账纳入配置管理，新增项目先申请 Key 再上线，避免出现无主调用；对已经混用的历史数据，只能按分摊处理，并在报表中明确标注。