为什么要先想降级
线上 AI 功能最常见的故障不是"算法变差"，而是上游不可用：模型接口超时、限流、区域故障、余额耗尽。
如果不设计降级，这些都会直接变成"整站这个功能打不开"。
降级的目标不是"保持一样好"，而是保持可用、并且如实告诉用户。
四层降级（从轻到重）
- 重试与切换：短超时 + 有限次重试；有备用通道就切过去（注意换通道后输出风格可能变化，要在结果里标注用了哪条通道）。
- 换小模型：把任务降到能完成的最小模型上（分类、抽取、格式化通常小模型够用），并标注"已降级"。
- 规则兜底：用模板/关键词/正则给出有限但正确的结果（例如"暂不能生成，先给你要点清单"）。
- 明确不可用：直接说"当前不可用，可稍后再试"，并给出替代入口（例如离线工具、上传文件本地处理）。
三条容易做错的地方
- 静默降级：用户以为在用完整能力，实际拿到的是兜底结果——这比直接报错更糟，因为错误会被当成事实；
- 降级链条不设上限：逐层降级到"什么都能答应但什么都做不好"，不如在第 3 层就停住；
- 只降级不监控：降级触发率必须进看板，否则你会长期在降级状态里运行而不知道。
把降级写进产品
- 界面明确显示状态（正常 / 已降级 / 不可用），而不是用同一套文案；
- 降级时降低承诺：不展示"精确数字"，改成范围或"待确认"；
- 记录降级原因到日志（超时 / 限流 / 校验失败），便于归因。
一个可执行的检查清单
- 列出每个 AI 功能的上游依赖；
- 给每个依赖定超时与重试次数（不要无限等）；
- 为每个功能写一个规则兜底的输出样例，确保真人看得懂；
- 加一条"降级率"指标并设告警阈值；
- 演练一次：手动断开上游，看降级链是否按预期逐层生效。