ux-error-recovery

错误恢复技能

此技能的行为方式（请先阅读）

这是一项生成式技能。Claude 的默认错误处理方式就是失败模式：它会写出“出了点问题”，只在提交时验证，把责任推给用户（“您输入的值无效”），对所有错误一视同仁地处理，使用全大写字母大声警告，或泄露错误代码（“错误 403：禁止访问”），遇到 404 时不给用户任何退路，而且从不考虑如何预防错误。优秀的错误恢复会彻底扭转这一做法。第一步是预防错误（大多数错误都可以通过约束、输入掩码和默认值在设计上避免），然后让无法避免的错误可以恢复——告诉用户发生了什么以及接下来该怎么做，为他们提供安全保障，并且绝不让他们陷入死胡同。因此，此技能会按以下步骤把关：

1. 明确风险程度、错误来源，以及错误发生在流程的哪个阶段——这些因素决定需要多大程度的操作阻碍、确认和升级处理。
2. 落实始终适用的核心原则——先预防，在不打断用户的情况下验证，撰写便于恢复的提示信息，提供安全保障，绝不让用户陷入死胡同。
3. 指出因情境而异的决策（确认还是撤销、验证时机、幽默、AI 降级/置信度、透明度与安全性之间的权衡），并说明利弊。

然后，它会移交给 ux-heuristics-audit、ux-accessibility-audit、ux-aesthetics-audit、ux-microcopy-audit、ux-dark-patterns-audit，以及（适用于移动端时）ux-mobile-responsiveness-audit 进行验证。

范围与组合方式（依据 docs/orchestration-policy.md §9）：此技能负责错误/失败/恢复体验——错误状态、提示信息撰写、验证行为、撤销/确认、降级和错误页面，并组合使用范围更窄的技能，而不是重新推导这些内容。核心子技能（作为恢复体验的一部分构建）：通过 ux-inputs-and-forms 处理输入字段结构。负责某一子部分的同级技能（交由其处理）：将Toast/通知的类型与频率交由 ux-notifications-and-toasts，将确认对话框的机制交由 ux-modals-and-dialogs（若涉及，由它们负责相应子部分）。下游技能（可建议使用，但不自动构建）：通过 ux-empty-states 处理首次使用/无结果/清空后的空状态界面，通过 ux-login-signup 处理密码重置流程，通过 ux-settings 处理保存状态确认，通过 ux-contact-support 处理错误发生时提供的帮助/联系方式。**继承，不重新生成：**如果已有设计系统，就从其设计令牌中沿用颜色、字体和间距——只有从头开始设计时才设置这些内容。

---

步骤 0 — 设计前先明确背景

如果不清楚，就先询问；如果没有答案也要继续，请说明所做的假设：

• 如果出错，后果有多严重？ 错误处理必须符合现实中的后果。气球颜色建议错了，只会让人有些失望；推荐了不安全的食物、转错账户，或永久删除数据，则会造成严重伤害。低风险场景可以轻松应对错误；高风险场景则需要详细说明、保守的默认设置、撤销功能和人工升级处理的途径。如果不清楚风险有多高，应优先谨慎，而非图方便。
• 这是操作失误，还是认知错误？ 操作失误是熟悉系统的用户在无意识操作中犯的错（例如点了“全部回复”而不是“回复”）——通过限制、建议、合理的默认设置和撤销功能来解决。认知错误源于错误的心智模型，通常出现在新用户身上（例如因为图标含义不清，误将邮件归档而不是删除）——通过更清晰的标签和指引，并缩小用户与系统之间的心智模型差异来解决（可通过调研发现这种差异）。不要指望用户会“慢慢学会”一个令人困惑的系统；他们会离开。
• 错误发生在用户旅程的哪个环节？ 错误有三种发生场景，需要采用不同的设计：输入／验证（表单字段）、系统／AI 故障（服务器、网络或错误预测）和导航（404、失效链接）。每种情况都需要各自的恢复方式。
• 平台。 在移动端，预防措施尤为重要——使用受限键盘、输入掩码、OTP 自动填充、更大的触控目标，以及在键盘上方持续可见的错误文本。

---

始终适用的核心原则（适用于几乎所有错误体验）

1. 先预防，再处理

• 限制输入。 设置边界，避免用户输入错误的值：电话号码／卡号字段使用数字键盘、时间选择器仅提供营业时间、无效选项置灰。
• 采用宽容的格式和输入掩码。 允许用户按习惯输入，并在输入过程中自动整理格式（添加空格／括号／连字符，去除多余字母）。输入掩码会展示并应用格式，减少电话号码、日期和卡号输入时的困惑。
• 设置符合大多数用户需求的合理默认值，但绝不能设置有利于企业而非用户的默认值（预先勾选订阅选项是暗黑模式，不是贴心的默认设置）。
• 减轻记忆负担。 显示持续更新的摘要（例如多段航班、多步骤预订），并自动识别短信验证码，避免用户切换屏幕。使用清晰易扫读的标签和提示，不要堆砌成片的说明文字。

2. 验证时不要打断用户

• 在焦点离开字段后再验证，不要在每次按键时验证，也不要等到提交时才验证。 让用户填完字段并切换焦点后再提示错误；如果等到点击“提交”才显示错误，用户可能会放弃。
• 只有对有明确要求的输入（如新密码），才例外地进行实时验证——每项规则满足时显示勾选标记，避免用户猜测。
• 错误状态应持续显示，直到输入内容确实有效，而不是用户刚开始重新输入时就消失。只有当输入值真正通过验证时，字段才恢复为默认／成功状态，这样用户才能记住自己正在修正什么。

3. 编写帮助用户解决问题而非指责用户的消息

• 每条消息都按以下结构编写：发生了什么 → 为什么重要 → 接下来该怎么做。（“你输入的代码不匹配。没收到验证码？重新发送。”）先说明该采取的行动，而不是问题（说“试试改善光线或换个角度”，而不是“图像识别失败”）。
• 使用通俗、自然的语言。 不要用行话、代码或“未授权／受限”之类的机械表达。文字要简短——1～2 句话；人在紧张时读得更少。
• 具体准确，不要含糊。 “发生错误”对任何人都没有帮助；应指出具体字段和解决办法。
• 保持礼貌；不要让用户觉得自己很笨。 不要指责，也不要居高临下。
• 不要使用全大写字母——这会让人觉得是在吼叫，使阅读速度降低 13～20%，还会影响低视力和阅读障碍用户的无障碍体验。
• 把消息放在相关内容旁边——显示在字段旁，而不是放在用户容易错过的横幅中。

4. 提供安全保障

• 为可撤销的操作提供撤销功能。 确保撤销操作即时且一目了然（例如“撤回发送”窗口）。这样可以消除犯下永久性错误的顾虑，让用户放心尝试。
• 仅对确实具有破坏性或不可逆的操作进行确认——让中断程度与可能产生的遗憾相匹配。过度确认会让用户产生对话框疲劳，之后便不再阅读。确认按钮应与触发按钮保持一定距离，避免用户连续点击时误触确认。
• 失败时保留用户的工作。 系统或 AI 步骤失败时，不要让用户从头开始——保留其输入，标出需要检查的内容，并在交由用户手动接管时保留上下文。

5. 永不让用户陷入死胡同

• 每条错误信息都应提供前进路径——重试、返回首页、搜索或访问相关链接。这体现了 Nielsen 提出的“帮助用户识别、诊断并从错误中恢复”。
• 404 页面应帮助用户恢复，而不是把路堵死。 清楚、诚恳地说明页面为何不存在，保持品牌风格，并提供明确的退出路径：搜索框和／或一组简短的实用链接（检查 URL 拼写，并查找相近匹配项）。保持简洁——简短说明加搜索框就足够了。
• 在出错时及时提供帮助。 如果下一步是“获取帮助”，就在此处链接到合适的渠道（支持体验本身交由 ux-contact-support 处理）。

---

取决于具体情境的决策（指出选择，不要自动应用）

逐项说明权衡，并给出与步骤 0 相关的建议；让用户决定。默认应用所有这些做法是错误的。

决策	适用情形	避免／需调整的情形	默认建议
确认还是撤销	确认不可逆、后果严重的操作（删除账户、永久丢失数据）	确认低风险／可逆的操作（造成对话疲劳）；对真正不可逆的操作只依赖撤销	对可逆操作提供撤销；仅对后果严重的操作要求确认——并尽可能同时提供撤销
验证时机	对复杂的要求输入（密码）进行实时验证；对简单字段在失焦时验证	在普通字段输入过程中验证；仅在提交时验证	通常在失焦时验证；密码类输入实时验证
文案中的幽默感／个性	友好的消费品牌、低风险错误、404 页面	高风险场景（金融、健康、安全），或用户来此寻求支持时	符合品牌调性；优先保证功能路径清晰；不确定时就不加玩笑
AI／模型置信度展示	展示结果会影响用户决策且风险较高时（医疗）	无意义的精确数值（85.8% 对比 87%），徒增干扰却不改变行为	仅在能指导行动时展示；面向非专业人士时，优先使用分类标签（高／中／低）或 N-best，而非原始百分比
渐进式降级／回退方案	功能或 AI 可能部分失效时——应逐步降低能力并提供人工接手选项，而不是直接中断	在不安全的时刻突然全部交由人工处理；隐瞒能力已降低	平稳降级，保留上下文，提供人工处理途径；风险较高时始终提供升级至人工处理的途径
解释中的透明度与安全性	解释用户有理由了解的常规限制	可能教会不法分子利用系统的细节（垃圾信息过滤器、身份验证失败）	指导善意用户采取下一步行动，但不暴露漏洞；对试图利用系统的人，只提供平淡无奇的失败提示
错误时的“帮助我们改进”反馈	反馈简短、二选一，并且你确实会采取行动（且会告知用户）	打断问题恢复流程，或收集毫无后续的表面反馈	反馈轻量、在问题解决后征求；表述为共同改进，而非“举报投诉”；设为可选
404 页面的丰富程度（插图／交互）	有助于体现品牌特色，且页面不会显得杂乱	强行开玩笑或加入杂乱元素，增加认知负担并掩盖退出路径	使用简洁且符合品牌调性的文案 + 搜索 + 热门链接；仅在确实符合品牌调性时添加视觉元素／交互

高风险场景（金融、健康、安全、破坏性／不可逆操作）会同时改变多项默认做法：默认策略更保守；必须确认，且尽可能同时提供撤销；严肃语气优先于幽默；明确提供升级至人工处理的途径；解释时兼顾安全性（不完全透明）。

验证结果（编排）

交接时应使用每个审查视角对应的可安装技能 name。只有安装了该技能时才调用；如果未安装，此技能自身的核心内容已包含这些规则，因此应继续执行，而不是因此受阻。

生成或修订后，应将结果交由审查视角审核，而不是直接宣布完成。这些都是候选审查视角——具体采用方式由 docs/orchestration-policy.md 决定，也可以将整个流程交由 ux-design-review 处理。此处，heuristics、microcopy 和 dark-patterns 属于 A 级（自动运行）；accessibility、aesthetics 和 mobile-responsiveness 属于 B 级（可选）——若已有设计系统，则不启用 aesthetics，而 accessibility 的范围缩小为使用体验；mobile-responsiveness 仅适用于移动设备。如果用户调用此技能是为了处理某一具体事项，请遵循该范围。

• ux-heuristics-audit（A级）——错误预防、“帮助用户识别、诊断并从错误中恢复”、系统状态的可见性（字段在修正前持续显示错误；失败情况会明确呈现），以及用户控制与自由（撤销、退出 404 页面）。
• ux-accessibility-audit（B 级——可选；使用设计系统时范围缩小）——错误提示不能只依靠颜色（使用图标或文本，而不只是红色）；错误文本应以程序方式与对应字段关联；焦点应移至错误消息；不使用全大写文本；错误和成功状态应具有足够的对比度。
• ux-aesthetics-audit（B 级——可选；使用设计系统时不启用）——404/错误页面应简洁明了；错误状态应足够醒目，但不令人惊慌；避免大段文字。
• ux-microcopy-audit（A级）——此技能专注于文案：采用“发生了什么／原因／下一步”的结构，行动优先的措辞，通俗自然的语言，礼貌且不归咎于人的语气，不使用行话或代码。
• ux-dark-patterns-audit（A级）——与错误相关的陷阱：在取消／删除确认中使用羞辱式确认，默认选项有利于业务而非用户，将确认按钮放在容易误触双击的位置，在只需点击一次即可执行破坏性操作时隐藏“撤销”，或用使用户内疚的方式描述反馈。摩擦和确认应保护用户，绝不能困住用户。
• ux-mobile-responsiveness-audit（B 级——可选）——受限键盘、输入掩码和 OTP 自动填充、错误文本不被键盘遮挡，以及重试／撤销／确认控件的触控目标尺寸。

如果审核发现冲突（例如，业务方要求每个操作都设置一道强制的“确定吗？”关卡，或使用让用户内疚的取消确认），应回归首要任务：用户已经在处理问题——减少阻碍，提供明确的解决途径，绝不利用出错时机操纵用户。

---

常见的该做与不该做

❌ 不该做	✅ 应该做
“发生错误” / “错误 403：禁止访问”	用通俗语言说明发生了什么 → 为什么重要 → 接下来该怎么做
只在用户点击提交时才验证	在输入框失去焦点时验证（密码实时验证）
用户重新输入时立即清除错误状态	持续显示错误，直到输入值确实有效
责怪用户；使用全大写	礼貌、优先说明操作、使用句首大写，并在字段旁提示
对所有错误一视同仁	根据后果调整操作阻力——可撤销的操作提供撤销选项，仅对后果严重的操作要求确认
对所有操作都要求确认	仅对不可逆操作要求确认，避免对话框疲劳
操作步骤失败时丢失用户的工作	保留输入内容，突出显示需要检查的部分，并在转为手动操作时保留上下文
只显示一个 404 页面，把用户送回原路	提供说明、搜索和实用链接，保持品牌风格且界面简洁
使用预先勾选、带操纵性的“默认选项”；在取消对话框中让用户感到内疚	默认选项应实用且有益于用户；确认提示应尊重用户
不做预防，只在错误发生后处理	通过限制、掩码和默认值，避免错误发生
未经检查就发布	交由启发式评估、无障碍性、美观、微文案和暗黑模式（以及移动端适配）检查

---

来源课程（Uxcel）

• 显示输入错误
• 编写问题提示
• 用户错误的本质
• 优雅的失败设计
• 设计 404 页面的 11 项最佳实践
• 安全网与撤销
• 常见模式