一次 API 请求结束时，响应已经抵达，但关于这次调用的记录，才刚刚开始。
调用了什么、消耗了多少、是否成功、等待了多久——这些问题看起来都可以用一个数字回答。真正开始整理时，才会发现，数字的意义来自它背后的口径。
先说明数字在说什么
“今天用了多少”不是一个完整的问题。这里的“今天”采用哪个时区？“用了”是请求次数、输入量、输出量，还是计费后的金额？失败的调用是否包含在内？
如果这些条件没有被说明，同一个数值就可能被不同的人读出不同的意思。因此，设计一份用量记录时，值得先写清楚指标的定义，再决定用什么图表展示。
一个有用的数字，应当能回答：它从哪里来，以及它包含什么。
给汇总留一条回去的路
汇总适合观察变化，明细适合解释变化。把一天的记录合成一行，可以快速看到趋势；保留必要的事件信息，则能在异常出现时，回到具体的时间、模型与状态。
这里的“必要”很重要。排查用量通常不需要把完整请求内容和密钥一起保存。记录应围绕问题本身，减少无关信息，也让后续查阅更轻松。
- 时间：使用明确的时间基准，展示时再转换。
- 身份：用内部标识关联调用，避免暴露完整凭证。
- 用量：区分不同来源的计量字段，不把未知值当成零。
- 状态：把成功、失败和未完成的请求分开理解。
为“不知道”保留位置
记录可能延迟，字段可能缺失，价格也可能尚未配置。这些情况都不等同于“没有使用”或“没有成本”。界面上的空白、待同步和未计价，是对信息边界的诚实表达。
与其让每个格子都显得完整，不如让每个已展示的数值都能被解释。统计的价值，在于帮助判断，而不是制造一种没有缺口的错觉。
从一个能解释清楚的视图开始
第一版可以很小：一个明确的时间范围、几项口径一致的指标、一份可回查的明细。等真正遇到新的问题，再增加新的维度。
当一个数字有出处、有边界，也有通向明细的路径，它才真正成为工具的一部分。
写于 2026.10.15
TIKOK