失败提示只是表面，错误正文才是排障的起点

调用人工智能接口失败时，新手常被“请求失败”四个字卡住。这通常只是工具显示的摘要，并不是服务端返回的全部信息。真正有用的线索，往往藏在响应正文里：缺了哪个参数、触发了哪种限制，以及这次请求留下了什么追踪标识。先读正文，再决定修改请求还是等待重试，通常比反复点击发送更有效。

状态码只能划定故障范围，错误正文才能补足具体原因

一次接口响应可以粗略分成三部分：状态码、响应头和正文。状态码像门口的指示牌，告诉你大致遇到了哪类问题；正文则像工作人员留下的说明。例如，四百类状态码通常与请求、权限或额度有关，五百类通常指向服务端异常，但这些都不是最终诊断。相同状态码可能对应不同原因，具体含义还要结合服务商的约定和正文判断。

正文也不一定是整齐的结构化数据。正常的接口错误可能包含错误对象，网关或安全防护拦截却可能返回网页内容，连接中断时甚至没有完整正文。因此，解析失败不等于服务端没有解释。应先确认响应的内容类型，并保留经过脱敏的原始内容，避免只看到应用自己抛出的第二层异常。

先找错误类型与具体描述，再判断这次请求能否直接重试

• 错误类型与错误码：先确认它属于鉴权、参数、限流还是服务异常。不同平台的命名并不统一，不要只凭一个熟悉的英文词下结论。
• 具体描述与参数位置：留意是否指出了缺失字段、不支持的参数或过长的输入。描述如果已经给出明确位置，优先修正那里，而不是同时改动多个设置。
• 请求标识与等待提示：请求标识通常用于查找日志，并不是错误原因。等待时长、限额信息等线索也可能位于响应头，不能只检查正文。

排障时，可以先问自己：这个问题是否会在请求不变的情况下自行消失？密钥无效、模型名称写错或参数不受支持，通常不会靠重试解决。限流或暂时性服务异常则可能适合稍后重试，但应遵循服务端提示，设置等待间隔和次数上限。连续快速重发，反而可能让限流持续更久。

流式响应还多一层容易误判的情况：连接建立成功，并不保证整次生成成功。错误可能在数据流开始后出现，也可能表现为内容突然中断。此时既要查看流中的错误事件，也要检查客户端是否识别到正常结束。已经收到部分文本时，重新发送可能带来重复内容或额外费用，不能把它当成完全没有执行过的请求。

经过中转服务的请求仍需区分故障来源与实际计费证据

本文由以质量为先的接口中转服务 BestRelay 发布。它按请求指定的模型转发至官方服务，不用其他模型替代，覆盖 Claude、GPT、Gemini、DeepSeek、Kimi、GLM、Qwen、Grok 等系列，并支持 Claude Code、Codex、Gemini CLI 及任意 OpenAI SDK。这样的调用链涉及客户端、中转层和模型提供方，错误可能来自其中任意一层；看到服务商名称，并不足以断定故障发生在哪里。

提交排障信息时，建议保留发生时间、所选模型、状态码、请求标识，以及脱敏后的错误正文。不要发送密钥、完整私人对话或未经检查的日志。中转层可能保留、包装或转换上游错误，因此最好同时说明错误来自原始响应，还是工具界面显示的摘要。信息来源清楚，比粘贴大量日志更有帮助。

费用也应单独核实。BestRelay 按提供方报告的令牌数量按量计费，缓存读取与写入分别定价；仅凭一次报错，不能推断此前没有生成内容，也不能推算最终账单，应结合用量记录确认。会员邀请他人充值可获得推荐佣金，但这与错误诊断无关。欢迎创建 BestRelay 账户。读错误正文的目标始终很简单：找到证据，采取对应动作，而不是把每次失败都交给重试按钮。