用途
这份技能用于指导界面中状态指示、校验、提醒和错误状态的设计。它面向需要设计或审查状态反馈的界面工作，目标是在用户出错或系统异常时，让用户能快速理解状态并找到下一步。
主要能力
保持颜色集合精简
每增加一种状态颜色，都是对用户的认知负担。用户需要学习每种颜色的含义、记住它，并在压力下正确解读——而压力恰恰是错误发生时。
覆盖绝大多数情况的最小集合：
- 红色：错误 / 失败 / 破坏性。表示出了问题，或该操作不可撤销。
- 橙色 / 琥珀色：警告。表示继续之前需要关注。
- 绿色：成功 / 正面。表示操作完成，状态健康。
- 蓝色：信息 / 中性状态。表示信息性内容，无需操作。
规则：每种颜色在整个产品中只映射一个含义。如果橙色在一个组件里表示“警告”，在另一个组件里表示“待处理”，系统就会失效。
每种状态色调必须与其他色调在视觉上明显不同。如果两个 token 渲染结果相似，只保留一个。同一可见颜色的第二个名称不是第二种状态：作者会任选其一，用户只读到一个状态，而这个名称就成了谎言。草稿和待处理状态使用中性色，而不是警告色。
拿不准时，删掉颜色——中性灰能在不携带语义权重的情况下传达状态，中性色好过被误用的语义色。
橙色始终是警告
橙色（琥珀色）携带特定信号：注意，可能出问题。不要将它用于：
- 中性状态（用灰色）
- 进度或待处理（用蓝色或加载指示器）
- 信息性内容（用蓝色）
- 状态指示器内的品牌或装饰用途
如果界面中出现橙色，用户应立刻知道这需要他们关注。
错误应当可恢复
最糟糕的错误是用户无法从中恢复的错误。每个错误状态都应设计一条前进路径。
错误信息结构：每个错误应回答三个问题：
- 出了什么问题？——用平实语言，不要错误码
- 为什么发生？——如果有用且已知
- 用户下一步该做什么？——具体、可操作
反例：“Error 500”“Something went wrong” 正例：“We couldn't save your changes. Check your connection and try again.”“This email is already in use. Sign in instead, or use a different email.”
恢复操作：
- 对瞬时故障（网络错误、超时）始终提供重试按钮
- 对校验错误，直接指向有问题的字段
- 对失败的破坏性操作，向用户保证没有丢失任何内容
- 对会话过期，重定向到登录并让用户回到原位置
在发生前预防大错误
最具破坏性的错误——数据丢失、不可逆操作、状态损坏——应在设计层面预防，而不是事后处理。
- 不可逆操作前确认：“Delete this project and all 47 tasks? This cannot be undone.”
- 禁用不可用操作，而不是让用户触发后撞上错误
- 尽可能自动保存，使浏览器崩溃或意外关闭不会毁掉工作
- 乐观 UI 加回滚：立即显示成功状态，失败时静默重试，只有重试也失败才暴露错误
在用户行动前说明后果，而不是之后。恐惧来自不知道控件会做什么。让结果在行动前可读，用户才能有信心地提交：
- 在控件旁或控件内用平实语言写后果文本：“This will email all 240 subscribers”“Publishing makes this visible to everyone”。
- 对多步骤或重型操作提供分阶段引导：拆成步骤，并在用户继续前告知每一步会做什么，使整个操作可预测，而不是一次跳跃。
把强打断（确认对话框、输入确认）留给上述真正危险的情况；对日常操作，一行安静的辅助文本就够了。目标相同——没有意外，所以没有可怕的事。
严重程度分级——谨慎使用
并非每个问题都同等重要。让反馈的视觉权重与严重程度匹配。
- 阻塞错误：整页错误状态或模态框。应用无法继续，用户必须行动。
- 行内错误：字段下方红色文本。表单字段校验失败。
- Toast / snackbar：屏幕底部的临时通知。用户应知道但可忽略的瞬时故障。
- 警告横幅：区块顶部的常驻条。影响当前上下文的持续问题。
- 空状态：带插图或说明的空屏。尚无数据——用作引导机会，而不只是空白。
避免同时展示多种错误类型——一条清晰信息比三条重叠提醒更有用。
相似度用单一色相，绝不用红到绿
这关乎数量，而非状态。状态仍采用上述语义调色板，有已知惯例的图表保留惯例。当一个单元格展示两个事物有多相似，或某物有多少时，用单一色相从近黑（毫无共同点）到强调色（相同）进行着色。低端的红色和黄色读作警告，会把一页差异变成错误；绿色读作评分。单一色相读作数量，而这正是数字所表达的。
使用方式
该技能以审查清单和反模式表的形式提供可操作指导。
审查清单：
- 产品是否使用四种或更少的语义状态颜色？
- 每种颜色是否只表示一个含义，并在各处一致使用？
- 每种状态色调是否与其他色调渲染明显不同，相似 token 是否已合并？
- 橙色 / 琥珀色是否专用于警告？
- 每条错误信息是否说明出了什么问题以及下一步做什么？
- 所有瞬时错误（网络、超时）是否都有重试操作？
- 不可逆破坏性操作是否有确认步骤保护？
- 长表单或复杂输入是否有自动保存或草稿恢复？
- 是否避免了多个同时出现的错误状态？
- 相似度或数量级刻度是否用单一色相绘制，警告色和成功色是否保留给状态？
常见反模式：
- “Something went wrong”且无操作：用户卡住无路可走。修复：加入具体原因和重试或联系链接。
- 橙色同时用于“待处理”和“警告”：颜色失去含义。修复：橙色仅用于警告；待处理用蓝色或加载指示器。
- 五种或更多状态颜色（红、橙、黄、青、紫……）：用户必须学习和记住复杂图例。修复：削减到最小集合：红、橙、绿、蓝。
- 仅在提交时行内校验：用户一次性发现所有错误。修复：在失焦（离开字段）时校验，提供即时反馈。
- 删除无确认：用户意外删除数据。修复：对所有不可逆操作要求明确确认。
适用场景
适用于设计状态指示器、表单校验、提醒和错误状态时，也适用于审查现有界面的状态颜色与错误处理是否一致、可恢复。
限制
资料未提供该技能的具体安装方式、平台支持、收费模式或代码示例。