服务降级时的用户体验：把「抱歉」写成有用的提示

大多数失败提示都写错了。本文给出提示该回答的三个问题、按降级层级给不同提示、让提示可操作的三个技巧、错误信息里不该出现的东西，以及用五个状态走查验证提示的方法。

"抱歉，服务暂时不可用"是最没用的提示

降级或故障时的用户提示，绝大多数产品都写错了 ✗：要么是技术术语 ✗，要么是空洞道歉 ✗，

要么干脆一个转圈 ✗。**好的失败提示应该让用户知道"现在能做什么"** ✔。

1. **发生了什么**（人话，不暴露内部细节 ✔）："当前回答服务繁忙" ✔ / "上游 502" ✗；

2. **你现在能做什么**（给 1~2 个可行路径 ✔）："稍后重试""换用关键词搜索""查看原始文档" ✔；

3. **什么时候可能恢复**（能给就给 ✔）："预计 5 分钟内恢复" ✔ / "请稍后再试" ✗（太含糊）。

| 状态 | 提示要点 |

|---|---|

| 正常 | 无需提示 |

| 已降级（小模型/缓存） | **如实标注**"当前为快速模式，结果可能较简略" ✔ |

| 部分能力不可用 | 说明**哪些能用、哪些不能用** ✔ |

| 完全不可用 | 给出替代入口（离线工具、原文检索、稍后重试）✔ |

**最忌讳的是"静默降级"** ✗ —— 用户以为在用完整能力，实际拿到兜底结果 ✔（见降级设计那篇 ✔）。

**保留用户输入** ✔：重试时不要让他重新打字 ✗；

**给一键动作** ✔（"重试""换个小模型""只看官方来源"）；

**给进度**（"正在排队，前面 3 个"）✔ 比"请等待"有用得多 ✔。

内部路径、服务名、版本号、堆栈 ✔（信息泄露 ✗）；

密钥片段、提示词原文 ✗；

无法行动的指责（"你的输入不合法" ✗ → 应说"输入过长，请缩减到 2000 字以内" ✔）。

用真实用户视角做**五个状态的走查** ✔（正常 / 降级 / 部分不可用 / 不可用 / 限流 ✔），每条问：

1. 我知不知道发生了什么 ✔？

2. 我知不知道下一步做什么 ✔？

3. 我的输入还在不在 ✔？

三问全"是"才算合格 ✔。

> 把提示文案单独拿出来读（不看界面 ✔），如果读者不知道"现在该干什么" ✔，

> 那这条提示就是失败的 ✗ —— 无论它多有礼貌 ✗。