降级顺序需预先定义

概念解释

失败当场由值班工程师或模型自己「看着办」，每次走的退路会不一样。人无法预测下一步，也无法排练。预定义的降级阶梯（predefined degradation order）把顺序写死在产品里：生成 → 检索增强 → 规则/模板 → 手工 → 人工，每一步在什么条件下触发、把什么交给下一步，发布前就定好。

顺序是设计对象，不是事故响应。

机制

现场即兴降级有两个失败模式。一是循环：生成失败就再生成，或检索失败又退回生成，人被关在同一层。二是跳跃：一次失败直接把人甩到人工或首页，中间本可用的层被跳过，人工被噪声打满。阶梯把「下一层是谁」变成确定的状态机，评估循环才知道该等什么。

预先定义还有训练价值。支持人员和用户可以排练「到这一层时我该做什么」。没有排练过的退路，在压力下会被当成新故障。

怎么研究

用故障注入走完整条链，记录实际经过的层是否与文档一致，有无环、有无跳。再比较「文档化阶梯」与「模型自行选择退路」。因变量：恢复时间、人工接管率、用户能否说出下一步。自变量：阶梯深度、是否允许层内重试、重试上限。

层内重试次数必须封顶。不封顶的阶梯在测量里会退化成「一直停在生成」。

边界

只有一层退路的产品，阶梯退化成单步，这条的重量下降，但仍要写明「失败 → 该层」。多层代理把阶梯拉得很长时，用户不需要看见每一层，但系统内部仍要有序，对外只暴露用户可理解的两三档。灾难恢复（整区宕机）可能另有一张运行手册，不要和产品内降级混成一套状态机。这条不讨论退路必须是确定性的——那是前一张——只讨论顺序不能现场发明。

怎么落地

• 写一张表：每一层的进入条件、层内最多几次重试、超时、出口。表进发布清单，和代码同审。
• 禁止「模型决定下一步去哪」。下一步由状态机决定。
• 对外文案与内部层对齐：用户听到的应是阶梯上他们站着的那一档，而不是内部工具名。
• 验证：按表把每一层单独打满，看是否落到表里写的下一层。出现循环或跳层，表和实现有一处是假的。再问一个没看过表的同事「失败之后会发生什么」——说不出顺序，顺序就还只写在工程师脑子里。

延伸

• 同组：L1.06.1 失败时需回到确定性路径 · L1.06.3 静默失败比明确失败更有害 · L1.06.4 失败分为无输出、错误输出与部分输出，三者需要不同的降级路径 · L1.06.5 最危险的是看起来正常的错误输出，它不触发任何降级机制 · L1.06.6 降级到确定性路径的前提是该路径一直被维护，而非只在故障时才存在 · L1.06.7 降级需保留用户已输入的内容，让用户从头再来是最常见的降级失败 · L1.06.8 超时与限流是可预期失败，其说明方式应与模型出错区分开
• 相邻：L4.13 代理的失败上报与求助 · I2.13 自动重试 · L4.05 可中断与可回退
• 站内检索：predefined degradation order · fallback ladder · degradation state machine