一、测试前先写清楚目标
不要为了“试一下”而试。先写下你要验证的一个真实场景：哪个产品调用、哪个模型、怎样的请求量、最不能接受哪种失败。测试只回答“这个入口是否适合进一步评估”，不替你承诺生产稳定性。
| 测试前 | 示例 |
|---|---|
| 使用场景 | 站内聊天、批量摘要、图文工作流或备用路由 |
| 测试模型 | 你实际会使用的一个公开模型 |
| 测试预算 | 从控制台当日可见的最小充值或小额档位开始 |
| 通过标准 | 请求成功、日志对应、扣费可解释 |
二、四步完成小额测试
- 注册自己的账号。不要使用共享账号，也不要把密码、验证码或完整 Key 发给任何人。
- 自己完成充值并创建 Key。付款、Key 和余额都留在自己的控制台里。
- 跑一条代表性请求。保持模型和 prompt 在你的真实场景范围内，记录请求时间和模型名。
- 核对三项结果。检查响应、日志、余额或扣费记录是否能对应同一笔调用。
acceptance-checklist.txt
[ ] request returned the expected model response
[ ] the call is visible in the usage log
[ ] the balance / billing record is understandable
[ ] no password or complete API key was shared
[ ] the use case is worth keeping as fallback or supplement三、失败时只收集必要证据
遇到问题时，不要反复重试，也不要发送敏感信息。只保留：发生时间、模型名、HTTP 状态码、请求 ID（如页面显示）和脱敏后的错误摘要。先检查 Base URL、Key、模型映射，再看服务状态。
测试通过，不等于收入或长期可用性已经验证。
测试结果只证明你在这次、这个模型、这个请求条件下观察到了什么。放量前仍要按自己的业务量继续观察。
四、从测试到放量的门槛
- 同一个常用模型至少能重复完成请求、日志、扣费三项核对。
- 你知道主渠道、备用渠道和模型补充之间的分工。
- 你能接受当前公开页面的价格、模型和服务边界。
- 批量采购同为 0.1 倍率；VIP 支持边界已经通过明确的人工报价确认。
达到门槛后，可以先把一小部分真实请求导向备用路由，继续记录失败原因和实际消耗；不要把一次成功请求直接扩展成全部生产流量。