使用 API 中转站前应该检查什么？稳定性、扣费、模型和售后清单

价格不是唯一标准

很多用户只看价格，但实际上：

• 低价格 = 差渠道：价格太低意味着中转站利润空间小，渠道质量差
• 低价格 = 扣费不透明：通过失败扣费、空回复扣费、预扣不返还等方式补贴利润
• 低价格 = 售后缺失：没有客服、没有日志、问题无法排查
• 低价格 = 高长期成本：质量差导致需要更多重试、更多调试时间

用户侧检查清单

• 测试扣费透明度
  用 raw quota 检测工具，发起失败请求，检查 quota 是否异常减少。页面余额可能经过处理，raw quota 才是真实数据。
• 测试模型稳定性
  用一个需要多步推理的任务测试（Claude Code 重构代码库），观察输出质量是否与预期一致。
• 确认 Base URL 选择
  普通聊天用 api1，长任务（Claude Code、Codex CLI）用 api2。选错 Base URL 可能导致 524 或响应缓慢。
• 测试错误可解释性
  故意触发 401/403/503/524 错误，检查错误信息是否清楚，是否有解决建议。
• 确认 request_id 排查
  出问题时有 request_id 才能让中转站排查日志。如果连 request_id 都没有，说明日志体系不完善。
• 检查充值门槛
  不要一次性大额充值。先用小额测试，确认稳定后再考虑大额。
• 测试售后响应
  发一个工单或消息，测试客服响应速度和质量。响应慢或没有响应的，长期使用有风险。
• 检查 API 文档
  有完整 API 文档说明有正常维护。没有文档或文档过时的，说明运营不稳定。

站长侧检查清单

如果你是在评估中转站作为技术方案，以下是站长应该关心的维度：

• 模型映射是否正确
  Opus 请求是否真的调用 Opus 渠道，Sonnet 是否调用 Sonnet 渠道。模型映射表是否有严格校验。
• 异常渠道处理机制
  渠道质量波动时是否有自动下线机制，是否有监控告警。
• 长请求通道隔离
  是否有独立的长请求通道（类似 api2），而不是所有请求混在同一队列。
• 扣费逻辑是否透明
  无有效输出时 final_quota 是否为 0，失败请求预扣费是否返还。
• 日志保留和查询
  是否保留请求日志，是否支持按 request_id 查询，是否支持按用户/时间筛选。
• 用户分组和权限体系
  用户分组是否能精细控制渠道和模型权限，是否支持按 API Key 隔离。
• 运营主体和稳定性
  是否有固定运营主体，域名注册时间，是否有持续维护。

失败扣费和空回复扣费

API Key 和 Base URL

这是两个最常被混淆的配置：

• API Key：身份认证，决定你能访问哪些模型（由用户分组和渠道权限决定）
• Base URL：请求地址，决定走哪个通道（普通请求还是长请求直连）

两者独立，但都重要：

• Key 正确但 Base URL 错误 → 可能 524 或响应慢
• Base URL 正确但 Key 无权限 → 403 权限不足
• 两者都正确 → 正常请求

售后和 request_id

request_id 是每次 API 请求的唯一标识，出问题时：

1. 用户提供 request_id
2. 中转站查询日志
3. 确认问题原因
4. 如果是中转站问题，进行补偿

没有 request_id = 无法排查 = 问题无法解决 = 用户损失无法挽回。

Link-AI 的承诺边界

Link-AI 不承诺：

• 永不故障（任何基础设施都有故障可能）
• 绝对满血（任何中转站都有渠道质量波动）
• 保证不扣费（但支持核查和补偿）

FAQ