state-sweep

状态扫描

找出常规流程设计掩盖的行为。

始终遵循

• 上下文——先检查已知信息，再请用户重复说明。如果产品目的或预期结果可能影响答案，请使用 .ux/INTENT.md，并且只加载任务所需的额外项目上下文。
• 用户——围绕受影响的人、他们的目标、任务、情境和现有证据开展工作。不要臆造用户需求、行为或角色。
• 证据——在差异很重要时，明确区分已知、推断、假设、未知和相互冲突的信息。
• 系统——优先采用既有的产品用语、组件、模式和规则，而不是另起炉灶。
• 清晰——先讲有用的要点，只采用必要的结构，并删除泛泛的 AI 填充内容。
• 信任——绝不臆造证据、需求、理由、实施状态或合规情况。
• 结果——对于较复杂的多步骤工作，持续关注意图；只有在需要保持连续性时才使用精简的 .ux/STATE.md；优先解决影响最大的未决问题，再进行润色；宣布完成前，依据意图验证实际体验。

除非这些规则会实质性影响答案，否则不要向用户复述。

如果用户和任务已经明确，或缺失的信息不会实质性影响工作，就不要引入研究问题、用户角色或探索工作。

阅读流程和系统

检查当前设计或实现、最精简的相关项目上下文、可用的相关 API 或数据行为、设计系统状态、无障碍规则和现有产品模式。

按转换扫描，而非按清单检查

针对每个有意义的用户操作或系统转换，思考用户会看到什么、能做什么：

• 数据尚不可用时；
• 工作进行中时；
• 没有任何内容时；
• 只有部分操作成功时；
• 输入无效时；
• 权限或资格阻碍操作时；
• 数据发生变化或已过时时；
• 网络、服务或依赖项发生故障时；
• 会话或操作超时时；
• 用户中断、离开、重试或恢复操作时；
• 操作成功后，包括确认和持久化。

如果动态状态变化会影响无障碍体验，还要检查焦点、播报、键盘行为和恢复方式。

避免状态膨胀

如果现有系统行为已能妥善处理某种情况，就不要为其创建单独的视觉状态。尽可能复用文档中已有的组件状态。

输出

生成精简的状态映射。对于每个缺失状态，说明触发条件、预期的用户可见行为、恢复路径，以及设计系统是否已支持该状态。

优先处理缺失后可能导致用户无法继续操作、工作丢失、产生错误信心或造成实现不一致的状态。

对比示例

不佳：

请考虑加载、空状态、错误、成功、离线、权限、超时、禁用、悬停、焦点、验证和边缘情况等状态。

良好：

用户提交付款后，请求可能会在服务响应期间一直处于待处理状态。当前设计在此期间仍允许点击“提交”，因此可能重复提交。请添加待处理状态，以防止重复提交、保留已输入的数据、告知用户当前进度，并明确请求超时时的处理方式。

原因：良好的回答从真实的转换和后果出发，而不是生成泛泛的状态清单。

示例

• “我还遗漏了哪些状态？”
• “请扫描这个结账流程的状态。”
• “工程团队想知道 API 超时时会发生什么。”