"抱歉，服务暂时不可用"是最没用的提示
降级或故障时的用户提示，绝大多数产品都写错了 ✗：要么是技术术语 ✗，要么是空洞道歉 ✗，
要么干脆一个转圈 ✗。好的失败提示应该让用户知道"现在能做什么" ✔。
一、提示要回答三个问题
- 发生了什么（人话，不暴露内部细节 ✔）："当前回答服务繁忙" ✔ / "上游 502" ✗；
- 你现在能做什么（给 1~2 个可行路径 ✔）："稍后重试""换用关键词搜索""查看原始文档" ✔；
- 什么时候可能恢复（能给就给 ✔）："预计 5 分钟内恢复" ✔ / "请稍后再试" ✗（太含糊）。
二、按降级层级给不同提示
| 状态 | 提示要点 |
|---|---|
| 正常 | 无需提示 |
| 已降级（小模型/缓存） | 如实标注"当前为快速模式，结果可能较简略" ✔ |
| 部分能力不可用 | 说明哪些能用、哪些不能用 ✔ |
| 完全不可用 | 给出替代入口（离线工具、原文检索、稍后重试）✔ |
最忌讳的是"静默降级" ✗ —— 用户以为在用完整能力，实际拿到兜底结果 ✔（见降级设计那篇 ✔）。
三、让提示"可操作"的三个技巧
- 保留用户输入 ✔：重试时不要让他重新打字 ✗；
- 给一键动作 ✔（"重试""换个小模型""只看官方来源"）；
- 给进度（"正在排队，前面 3 个"）✔ 比"请等待"有用得多 ✔。
四、错误信息里不要出现的东西
- 内部路径、服务名、版本号、堆栈 ✔（信息泄露 ✗）；
- 密钥片段、提示词原文 ✗；
- 无法行动的指责（"你的输入不合法" ✗ → 应说"输入过长，请缩减到 2000 字以内" ✔）。
五、怎么验证提示有效
用真实用户视角做五个状态的走查 ✔（正常 / 降级 / 部分不可用 / 不可用 / 限流 ✔），每条问：
- 我知不知道发生了什么 ✔？
- 我知不知道下一步做什么 ✔？
- 我的输入还在不在 ✔？
三问全"是"才算合格 ✔。
一条判据
把提示文案单独拿出来读（不看界面 ✔），如果读者不知道"现在该干什么" ✔，
那这条提示就是失败的 ✗ —— 无论它多有礼貌 ✗。