两个数字相等之前，必须先回答它们各自在数什么
WordPress可能记录尝试次数，供应商控制台可能记录已接受或已计量的调用；一个请求失败后重试，会在本地出现两次尝试，也可能在供应商侧出现一次或两次用量。数字不同首先说明口径不同，不能直接证明任一系统错误。
令牌也有估算与结算之分。本地可以按已知文本或配置费率估算，供应商最终账单可能包含缓存、批处理、折扣、舍入或不同时间边界。产品本身的费用数字应视为运营信号，最终应付金额仍以供应商账单为准。
按固定顺序对齐五个分母
第一步把双方都切到同一个UTC起止时刻，并考虑控制台数据延迟；第二步区分尝试、接受、完成与计量；第三步按供应商和模型拆分；第四步核对输入、缓存输入和输出等令牌类别；第五步确认哪些请求路径确实经过WordPress保护。
只有完成这五步，才能讨论阈值。若供应商记录100次、WordPress只记录80次，而另外20次来自服务器脚本直连，差异是范围外调用；若两边都记录100次但本地令牌少20%，则应检查估算口径或费率，而不是寻找不存在的漏调用。
| 差异现象 | 可能合理的解释 | 需要升级调查的证据 |
|---|---|---|
| 本地尝试多于供应商调用 | 发送前校验失败或本地重试被去重 | 持续增长且无法关联错误状态 |
| 供应商调用多于本地记录 | SDK直连、其他主机名或范围外路径 | 确认所有路径均应受保护仍有缺口 |
| 调用数相同、令牌不同 | 本地估算、缓存或结算口径不同 | 使用同一计量字段后仍超阈值 |
| 短窗口不一致、日汇总一致 | 控制台入账延迟或时间边界 | 超过约定延迟后仍不收敛 |
Full、Core-only与范围外路径不能混在一个百分比里
保护范围决定本地看得到什么。默认受保护的WordPress AI Client传输器可获得Full覆盖，自定义或边车传输器属于Core-only；绕过WordPress AI Client、直接调用供应商API的路径则在范围外。对账表必须按这三类分别统计，而不是用全账户供应商总量除以某个局部计数。
范围外并不自动等于漏洞。它可能是经过批准的独立系统，也可能是需要迁移的旧调用；关键是有负责人、用途和预算。无法归属的范围外用量才应进入事件调查。
阈值来自历史收敛情况，不是通用常数
先观察至少一个完整结算周期，计算小时、日和月三个尺度的正常差异。可以为短时控制台延迟设较宽区间，为月末未解释差额设接近零的要求；不要把所有时间尺度都设成同一个5%。
预期差异规则应写明公式、允许原因、等待多久、由谁调查以及何时升级。修改供应商、模型或覆盖范围后，旧阈值必须重新校准，因为分母已经改变。
结论：先解释差异，再评价监测质量
一次合格对账的输出包括已解释差额、仍未解释差额和行动负责人。差异可以存在，但不能无人负责；完全相等也不保证覆盖完整，因为两个系统可能同时漏掉同一路径。有关本地记录字段与数据处理边界，应以隐私说明为准。
把这张规则表纳入每月复核后，团队不再因正常入账延迟频繁报警，也不会因为总数看似接近而忽略持续的SDK直连。真正有价值的是可解释性，而不是表面上的数字一致。
把“供应商控制台和WordPress计数不一致，并不一定是监测失灵”的预期差异规则用于第一次真实安装。免费下载 AI Cost Circuit Breaker，先从 Monitoring 开始，验证预期信号和回退方式后再启用强制控制。