超时与限流是可预期失败，其说明方式应与模型出错区分开

概念解释

模型胡编、工具崩溃、权限不足，是能力或正确性失败。排队太长、预算用尽、网关 429，是容量失败。两者对用户意味着完全不同的下一步：前者要换路或改任务，后者要等、降级用量、或换时段。把超时和限流写成「出错了」，是用正确性语言去描述容量，人会开始怀疑模型，或开始改提示——两者都是错的药。

可预期失败需要可预期的说法：什么时候能再试、是不是人人如此、现在还能做哪一档。

机制

容量失败的因果在队列和配额，不在提示质量。界面若用通用错误壳（红条、再试一次、换种说法），会把因果推向用户或推向模型。人随后采取的修复（改句子、换账号、给更长上下文）对 429 毫无作用，还可能加重负载。

可预期性本应降低威胁：人人都在等，就不是我的错。文案和进度如果把「全站忙」画成「你的这次请求失败」，社会比较信息被扔掉，剩下个人失败感。客服和状态页的研究都指出：说明范围（就你 / 所有人）和恢复时间，比道歉更能稳定行为。

怎么研究

同一 429/超时，四种文案：通用出错、请改提示、全站忙并给重试时刻、全站忙并给低容量退路。因变量：是否改提示、是否立即重试（打在热路径上）、是否改用退路、归责对象。自变量：是否显示队列位置或恢复时钟、是否允许同时做手工路径。

立即重试率是关键的系统量。文案若鼓励立刻再按，会把限流变成震荡。

边界

超时其实由模型死循环引起时，用容量语言会误导，应归到能力失败并走能力降级。对单个用户的配额（你今天的次数用完）不是全站忙，文案要说「你的额度」，并给出重置时间和升级/降级用量的选项。离线或权限错误也不是容量。这条只管容量类可预期失败的说明，不把它们和流畅错误混为一谈。

怎么落地

• 429、排队、预算耗尽使用独立的容量面板：原因、范围（你 / 本区 / 全站）、最早重试时刻、此刻可用的低容量动作。禁止「请换一种说法」。
• 客户端对容量失败做退避，不要把「再试」做成可连点的主按钮。主按钮应是退路或「到点通知我」。
• 状态页与应用内文案同一套原因码，避免应用说出错、推特说正常。
• 验证：人为打满配额。看文案是否提到改提示——提到就失败。看人是否在 10 秒内连点重试——连点，退避没装上。再问「是你写得不好还是现在忙」——答「我写得不好」，说明语言用错了家族。

延伸

• 同组：L1.06.1 失败时需回到确定性路径 · L1.06.2 降级顺序需预先定义 · L1.06.3 静默失败比明确失败更有害 · L1.06.4 失败分为无输出、错误输出与部分输出，三者需要不同的降级路径 · L1.06.5 最危险的是看起来正常的错误输出，它不触发任何降级机制 · L1.06.6 降级到确定性路径的前提是该路径一直被维护，而非只在故障时才存在 · L1.06.7 降级需保留用户已输入的内容，让用户从头再来是最常见的降级失败
• 相邻：I2.13 自动重试 · L1.12 延迟与流式输出的体验 · L4.13 代理的失败上报与求助
• 站内检索：rate limit copy · expected capacity failure · timeout versus model error