计数校验要对账
把本地统计的输入输出 token 与供应商账单逐项比对，差异超过约定比例就排查。为什么必须做：分词口径、工具调用与结构化输出都可能造成偏差，差异长期不查，预算与优化都会建立在错误数字上。
长上下文要测边界
构造接近上限的输入，观察截断发生在哪里、是否报错、是否静默丢内容。为什么危险：静默截断会让答案缺失关键条款，用户却以为看的是全文。测试要记录截断位置与提示方式，并写进产品说明。
限流与退避要验证
在配额边缘加压，观察是否返回限流、客户端是否按退避重试、重试是否成倍放大 token。怎么做：记录请求数、计费请求数与失败率三条曲线；边界是重试次数要有上限，不能无限重放长上下文请求。
成本回归门禁
把固定测试集接进发布流程，版本变更后自动比较 token 与质量。为什么有效：提示词与检索配置的改动最容易被忽略，人工评审看不出输入长度变化；门禁能在合并前拦下显著上涨的版本。
适用与不适用
适合谁
- 准备上线新提示词或新检索配置的团队
- 检索增强类应用的研发、测试与运维人员
- 需要向财务证明计费准确的平台方与团队
不适合谁
- 尚未接入计费接口、无法对账的早期原型
- 没有固定测试集、无法复跑的项目或试点
典型场景
一家在线客服系统在改版前做了验收：用两百条历史会话比对本地计数与账单，构造接近上限的长输入观察截断，再在配额边缘加压看退避行为。发现一处静默截断后补了提示与分段逻辑，改版上线后没有出现漏答投诉。
可执行步骤
- 建立两百条以上的测试集，固定版本与参数，覆盖长短上下文与失败样例
- 用同一批请求比对本地计数与供应商账单，记录差异比例并按输入输出分项
- 构造接近上下文上限的输入，观察截断位置与用户可见提示，并留样本
- 在配额边缘加压，验证限流返回、退避策略与重试上限，记录三条曲线
- 把 token 阈值接进发布流程，超标即阻断并要求说明原因，全程留痕
常见坑
- 只比对总量不比对分项，输入与输出的偏差相互抵消，问题被掩盖，长期查不出来，事后难补救。
- 长上下文测试只测不超限的情况，真正超限时静默丢内容，没人发现，投诉才暴露，损失已造成。
- 重试没有上限，限流时反复重放长请求，账单在几分钟内飙升，事后难以追回，追责也困难。
- 门禁阈值定得过松，每次都能通过，等于没有门禁，也没有人复核，形同虚设，风险照旧存在。
自检与验收清单
- 测试集是否覆盖长上下文与失败样例
- 本地计数与账单是否分项比对、逐月留档
- 截断行为是否有清晰、用户可见的提示
- 重试次数与退避策略是否有上限并演练
- 成本门禁阈值是否经双方书面确认
常见问题
计数差异多少算正常
取决于是否涉及工具调用与结构化输出。纯文本场景差异通常很小，复杂场景会略高。建议连续比对三个月，掌握自己的正常波动区间，再把明显超出区间的版本拦下来，而不是追求零差异。
超长输入应该截断还是报错
看业务。检索类可以分段处理并合并答案，问答类应明确提示内容过长并给出范围。最糟的是静默截断：用户以为问的是全文，系统只看了前半段，答案错误却无从解释。
压测要不要用真实数据
建议用脱敏后的真实样本，配合合成的极端输入。真实样本能暴露实际分布，合成样本能覆盖边界。两者都跑，才能同时验证正常路径与异常路径，也不至于把敏感数据带进测试环境。