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