AI 错误和普通错误不一样
表单提交失败可以重试，AI 回答错误却常常不可复现：同样的输入，换个时间可能得到不同结果。用户因此更困惑，也更不信任。
所以错误状态设计的目标不是消灭错误，而是让错误可理解、可修正、可追溯。
四类常见错误
服务不可用、内容不准确、内容不合规、结果不完整，是 AI 产品最常见的四类问题。每一类都应该有独立的提示和恢复路径。
- 服务不可用：明确说明是临时问题，提供重试
- 内容不准确：标注置信度与来源，允许用户纠正
- 内容不合规：拒绝并解释原因，给出替代方案
- 结果不完整：说明缺失了什么条件，引导补充
把「不知道」设计成功能
最好的错误状态是让 AI 承认不知道，而不是硬编一个答案。客服场景尤其如此：一次错误回答的伤害，可能超过十次正确回答带来的信任。
在产品里，这表现为「转人工」「我再确认一下」「这条信息需要更多资料」等诚实的出口。
让用户总能回到安全状态
无论错误发生在哪一步，用户都应该能撤销、重试或退出。永远不要让用户在一个不可恢复的对话里越陷越深。
错误状态做得好，用户记住的是「这个产品很诚实」，而不是「这个 AI 很蠢」。
错误文案的三种写法
承认问题、说明影响、给出下一步，是错误文案的三段式。「这个问题我暂时无法回答」比「网络异常」更诚实；「为了不误导你，建议转人工确认」比「请稍后重试」更有用。
文案要让用户感到系统知道发生了什么，并且已经准备好恢复路径，而不是把用户留在原地。
错误状态也需要测试
大多数团队只测试理想路径，错误路径留给运气。建议在发布前专门做一轮「错误演练」：断网、超时、空结果、模型拒绝，逐一看界面表现。
测试时记录两个数字：用户从错误中恢复需要几步，以及恢复后是否还记得原来的任务。步骤越少，恢复率越高。
把错误路径的测试用例写进回归集，以后每次改版都不会再踩同样的坑。
错误状态的三种角色
产品负责定义错误文案和恢复路径，工程负责保证错误可复现、可定位，客服负责把真实错误样本反馈回来。三个角色缺一个，错误处理就会偏科。
建议每月开一次「错误复盘会」：把本月最典型的 5 个错误案例拿出来，看每一类错误的文案、恢复路径和用户反馈。
错误状态不是一次性设计，而是随真实使用持续完善的系统。