技术 · 熟练
回答空白，未必是超时
推理型模型给出的「超时」「返回空」「回答只剩半句」，很多根本不是网络问题 —— 是它的输出预算被思考过程吃干净了，轮到回答时已经没有额度。这一类故障最费时间的地方在于：报错信息指向网络，而真正要改的是你的调用参数。这一页给一段可直接复制的诊断提示词，把「我该怎么办」变成一条能走完的路：先分清是网络超时、预算被思考吃掉、还是真的限频；再给推理和回答分别留额度；最后用 finish_reason 和 completion_tokens 把这件事变成可核对的数字。判据只有一个：同一段输入连跑三次，回答长度稳定了，才算修好。
1
先分清三种「没回答」 — 报错码只说明失败位置，不说明原因：① 连接层面（连不上 / 5xx / read timeout）② 生成层面（HTTP 200 但 content 为空、或只有思考没有答案）③ 频率层面（429 / 并发上限）。三类的修法完全不同，先归类再动手
2
把「思考」和「回答」分开计量 — 取一次原始响应，看 usage 里的输出 token 数与 finish_reason：若是 length 截断、或思考 token 占掉了绝大部分输出预算 ⇒ 就是预算被吃掉，不是超时
3
给推理设上限，给回答留底 — 不要只设一个总输出上限。把「思考预算」单独调小（或显式要求它先给结论再展开），并为回答保留一个下限 —— 只要出现「回答为空但思考很长」，就是回答额度被挤没了
4
把结构锁在前面 — 在提示词里规定输出结构：「第一行给结论，第二行给依据，最后才是过程」。这样即使预算被压，最重要的内容也已经落纸，而不是被思考吞掉
5
记录并复核 — 每条失败样本记四个值：输入长度 / 输出 token / 思考 token（可得时）/ finish_reason。三次重跑后回答长度稳定 ⇒ 收工；仍抖 ⇒ 回第 3 步继续压思考预算
# 角色
你是我的「模型调用故障分诊台」。我不需要你解释原理，我需要你把这次失败归到三类里的一类，并给出改哪几个参数。
# 我给你的输入
① 我这次调用的原始响应（含 HTTP 状态、body 里的 finish_reason 与 usage）
② 我用的模型名与是否开着深度思考
③ 我的调用参数（只贴和输出长度、超时、并发有关的那几个）
# 你要做的
1. 归类，只允许选一个：
- 连接类：连不上 / 5xx / read timeout —— 判据是「请求根本没走完」
- 生成类：HTTP 200 但回答为空、只有思考、或被 length 截断 —— 判据是「走完了但没内容」
- 频率类：429 或并发上限 —— 判据是「被限流」
2. 如果是生成类，再算一个比例：思考占掉的输出预算 ÷ 总输出预算。超过一半就判「回答额度被思考挤没」。
3. 给出最小改动清单，最多三条，每条写「改哪个参数 / 从多少改到多少 / 预期看到什么变化」。
# 输出格式
【归类】三类之一 + 一句判据
【占比】思考预算 ÷ 总输出预算 = 多少（拿不到就写「数据不足」）
【最小改动】最多三条
【复核方式】一句：我怎么确认真的修好了
# 约束
- 不要建议我「换个模型」当作第一步 —— 先把我现在这个模型的参数调对。
- 不要给我一份通用参数大全，只给针对这次响应的那几条。
- 拿不到 usage 就直说数据不足，不要猜数字。
- 输出里不要用星号做强调，要强调就用「」括起来。