申诉之前先自查：把你的 key 到底做了什么拼出来
本文介绍在向 LLM API 聚合站申诉账号或 key 异常前，如何通过整合客户端日志与平台用量记录，构建一条清晰的事实时间线。文章提供具体步骤，帮助用户用调用量、来源、时间点等客观数据撰写申诉工单，提升沟通效率。
为什么需要自查
当 API 调用出现异常（如被限流、封禁或扣费争议），直接提交“请解封”的工单往往缺乏细节，处理周期长。聚合站的风控和客服需要依据事实判断，而事实来自两边的记录：你本地的客户端日志，以及平台侧的用量面板。把两者拼成一条时间线，申诉就变成了对事实的陈述，而不是请求。
第一步：导出客户端日志
大多数 HTTP 客户端、SDK 或代理工具都会记录请求时间、状态码、请求 ID、模型名称和 token 消耗。你需要关注：
- 请求发起时间（精确到秒，注意时区）
- 目标端点（base URL）和模型
- 响应状态码（200、429、401 等）
- 请求 ID 或 trace ID（如果有）
- 错误信息原文
如果使用自建代理或网关，确保日志包含上游返回的 x-request-id 等标识，便于与平台侧记录对齐。
第二步：拉取平台用量记录
登录聚合站控制台，找到用量明细或调用日志页面。通常可以按 API key、时间范围筛选，并导出 CSV。重点提取：
- 平台记录的时间戳
- 该次调用的模型、输入/输出 token 数
- 扣费金额（按 ×1.3 规则）
- 调用来源 IP（如果平台提供）
- 状态（成功/失败）
注意平台时间可能与本地时间存在时区差异，统一转换为 UTC 或同一时区后再比对。
第三步：对齐时间线
将两份数据按时间排序，以请求 ID 或“时间+模型+token 数”为键进行匹配。常见情况：
- 客户端显示 429，平台记录也是 429 → 限流事实清晰
- 客户端显示成功，平台记录扣费但状态异常 → 需要核对响应体
- 客户端无记录，平台有扣费 → 检查是否有其他程序共用 key
把匹配结果整理成表格，标注每个时间点的事实：谁（哪个 key/来源）、做了什么（调用哪个模型）、结果如何（成功/失败/扣费）。
第四步：撰写申诉工单
基于时间线，工单应包含：
- 问题概述（一句话）
- 涉事 API key 的末四位（不要发完整 key）
- 时间线表格（时间、事件、证据来源）
- 具体诉求（如复核某几笔扣费、解除误判限流）
- 附件：客户端日志片段、平台用量截图或 CSV
避免模糊表述如“我的 key 被封了”，改为“在 X 时间点，该 key 从 Y 来源发起了 Z 次调用，其中 N 次返回 429，平台记录扣费 M 次，请求 ID 如下”。
注意事项
- 不要伪造或修改日志，平台侧有完整记录
- 敏感信息（完整 key、个人信息）打码
- 如果使用多个客户端，分别导出并标注来源
- 贡献 key 的用户同样适用：返 USDC 按 ×1.1 或 ×1.2 计算，若对返利有疑问，用同样的方法对齐调用记录与返利明细
把事实拼出来，申诉就成功了一半。