API配置不是背一串字段。先分清客户端、服务和配置管理工具，后面的每一步才有判断依据。
只看账户余额变化，很难判断是哪天、哪个客户端或哪个任务产生用量；只看本地任务次数也不等于服务端计费请求数。
所以这篇文章只解决一件事：建立不暴露Key的任务、请求和控制台用量核对记录。重点不是得到一段看起来完整的答案，而是让输入、步骤、结果和检查标准能够彼此对应。
适合谁
适合开始长期用Codex或Claude Code，希望知道哪些任务产生调用、如何发现异常消耗的人。
这不是一套让工具替你承担责任的方法。材料缺失要补，结论无法定位要标记，涉及不可逆操作时要停下来确认。
API Key相当于调用凭证，不能出现在截图、文章示例、聊天记录、日志或代码仓库。地址、模型、协议和Provider字段只以当前控制台及客户端说明为准。
开始前准备
- 控制台当前用量或账单记录
- 客户端任务时间线
- Provider、模型和重试情况
- 建立一个测试副本或新目录，不直接操作唯一原件。
- 写下一句验收标准：用量区间、时区和口径明确，异常能对应任务或重试证据，记录中没有完整Key或敏感输入
开始前再做一次反向检查：少了哪份材料就无法判断结果？哪一步做错会影响原件？把答案写进当前任务，而不是留在自己脑中。
完整步骤
第一步之前：先做一个最小样本
先选最有代表性的一小份材料：既包含正常情况，也包含一个容易出错的边界。小样不合格时，继续全量处理只会增加返工。
第一步：固定核对时间范围
统一时区，记录开始与结束时间、期初和期末读数。
这一阶段的完成标志不是工具有回复，而是“用量核对区间”已经可供人工检查。
第二步：整理任务与请求事件
按客户端、Provider和任务记录成功、失败、重试和并发，不保存敏感内容。
继续下一步之前，抽查“任务请求时间线”中的边界项和异常项；发现前提不成立就先修正。
第三步：对照服务端口径
确认控制台按请求、输入输出或其他单位展示，以当前页面说明为准。
把“用量口径说明”作为本轮留存证据。后续合并或扩大范围时，都应能用它复盘。
第四步：识别异常并小样验证
发现突增时先查重试、重复进程和长任务，用一个固定小任务观察增量。
先停在这里检查一次。此时应已经形成“异常用量调查”，并且能回到原始材料说明它从哪里来。
第五步：人工验收并沉淀流程
最后把结果与原始材料逐项对照，记录有效步骤、人工判断点和没有解决的问题。重复任务可以继续整理成模板、项目规则或Skill。
实际示例
一个任务在客户端只显示一次，但后台自动重试五次，服务端可能记录多次请求。要结合日志和控制台时间线，不用任务数量直接推算费用。
可以先这样描述任务：
我正在处理“建立不暴露Key的任务、请求和控制台用量核对记录”。已有材料包括控制台当前用量或账单记录、客户端任务时间线、Provider、模型和重试情况。请先不要扩大任务范围，也不要补造缺失信息。先完成“固定核对时间范围”，输出可以人工检查的中间结果；我确认后，再继续“整理任务与请求事件”。最终请按照“用量区间、时区和口径明确，异常能对应任务或重试证据，记录中没有完整Key或敏感输入”列出验收结果和仍需人工确认的内容。
若第一次结果仍然太宽泛，不要继续追加十条要求。缩小输入，只重做最早出现偏差的那一步。
常见问题与报错
本地记录和控制台数量仍对不上
检查统计延迟、时区、失败请求、多个客户端或其他Key；无法完全归因时给出已确认范围和差额，不强行解释。
配置保存了，客户端仍然使用旧地址
确认当前Provider已经切换生效，完全退出客户端后重开，并检查环境变量或其他配置文件是否覆盖了刚保存的值。
401、404、429和超时一起排查
先记录真实状态码、最终请求路径和响应信息，再按认证、路径、额度、频率和网络分层处理；每次只改一个变量。
API排错必须保留真实状态码、最终请求路径和脱敏响应。每轮只改Key、地址、模型或Provider中的一项。
完成后的检查方法
- 用量区间、时区和口径明确，异常能对应任务或重试证据，记录中没有完整Key或敏感输入
- 关键结论能回到原始材料、文件、命令输出或当前控制台。
- 没有把缺失信息、推测内容或示例数字写成已经确认的事实。
- 重要文件保留原件、版本或可恢复副本，敏感信息没有进入公开内容。
- 结果已经由真正负责这项工作的人审阅，而不是只看页面是否生成。
当这套步骤连续在两个真实样本上成立，再考虑扩大范围或做成Skill。第一次跑通不等于流程已经稳定。
资料来源
- 小贺API控制台
地址、模型、价格、套餐和配置字段可能调整，以登录后当前页面为准。
- CC Switch项目说明
用于核对Provider管理和客户端切换入口；界面以当前版本为准。
FAQ
可以一次把整个任务交给工具完成吗？
不建议一次交付全部范围。先按本文步骤完成一个小样，用“用量区间、时区和口径明确，异常能对应任务或重试证据，记录中没有完整Key或敏感输入”验收，再决定是否扩大范围。
遇到“本地记录和控制台数量仍对不上”应该先检查什么？
检查统计延迟、时区、失败请求、多个客户端或其他Key；无法完全归因时给出已确认范围和差额，不强行解释
完成后还需要人工检查吗？
需要。AI或执行工具负责推进流程，最终仍要由你根据原始材料、任务规则和“用量区间、时区和口径明确，异常能对应任务或重试证据，记录中没有完整Key或敏感输入”完成验收。