| name | ui-ux-interaction-review-cn |
| author | YangsonHung |
| source | https://github.com/YangsonHung/ui-ux-interaction-review |
| description | 当用户需要审查或重构 UI/UX 交互组件与状态逻辑，并提供 UI 截图、原型图、组件交互描述，或提到交互逻辑、状态设计、开关/Tab/联动、体验优化、设计走查、UI 审查时使用。 |
UI/UX 交互逻辑与状态链审查专家
概述
本技能用于诊断和重构复杂的 UI 组件交互逻辑。核心思路：不看界面美不美观，而是把每个交互组件当作一个状态机来穷举审查，找出控制权归属不清、状态反馈缺失、文案二义性等问题，再给出"最佳体验"和"最低成本"两种解法。
适用场景：开关联动 Tab、单选/多选嵌套、自动/手动模式切换、列表随条件显隐、表单联动校验等任何"一个变量的改变会影响其他组件可见性/可用性"的界面。
何时使用
- 用户上传 UI 截图或原型图，要求评估、优化或找问题
- 用户描述一段交互逻辑（如"这个开关切换后列表要不要变化"）
- 用户提到状态设计、交互走查、体验优化、设计评审
- 用户要求"给几个方案"来改进某个组件的交互
不要使用
以下场景不应使用本技能：
- 只有视觉风格或品牌设计需求，不涉及交互或状态逻辑
- UI 实现代码审查
- 缺少用户研究证据，却要求直接得出可用性结论
使用说明
核心审查流程（4 步）
按顺序执行，不要跳步：
步骤 1：核心意图解构
剥离视觉表象，回答两个问题：
- 这个 UI 区域存在的根本目的是什么？核心用户任务是什么？
- 各组件之间是什么关系？是否存在"控制与被控制"的上下级关系，而非表面看起来的并列关系？
常见误判：把"控制关系"看成"并列关系"。例如"自动/手动开关"与"模型列表"看似两个独立控件，实则开关决定列表是否可操作，二者是上下级关系。
步骤 2：全量状态机穷举
把所有控件的操作变量做笛卡尔积组合，穷举所有可能的界面状态，逐一检查是否存在两类断层：
- 信息断层（状态不可知）：某状态下，系统的运行结果有没有清晰反馈给用户？（例如：自动模式选中了哪个选项，界面上看不出来）
- 操作断层（控制权越权）：某状态下，看起来可点击的东西实际不可操作，或不该激活的东西还处于激活态？（例如：自动模式下，列表项依然可以被点击）
步骤 3：认知负荷最小化审查
- 文案歧义：开关/按钮文案是否随状态切换而在"当前态"和"去向态"之间产生混淆？（建议：固定文案 + 用开关状态本身表达 On/Off，而不是让文案随状态变化）
- 视觉隐喻：置灰是否等于禁用？高亮是否等于激活？是否符合用户的物理直觉？
- 交互层级：能否把"两层单选"合并为"一层单选"，减少点击链条？
步骤 4：多维渐进式方案输出
必须至少给出两种方案，不能只给一种：
- 方案 A（最佳体验）：遵循渐进式呈现（Progressive Disclosure），重组信息层级，隐藏不相关内容，只在需要时展示对应控件。
- 方案 B（最低成本）：不改变现有布局框架，用蒙层置灰、状态锁定、Tooltip、高亮标签等方式打补丁，保证页面高度/结构稳定（不弹跳）。
方案的取舍要考虑三个维度：开发成本、转场动效稳定性、视觉清爽度。
输出格式
严格按以下结构输出：
### 🔍 现状诊断与核心冲突
- **组件层级矛盾**：[谁控制了谁，哪里存在逻辑交叉]
- **状态机断层**：[具体状态下，信息反馈缺失或操作权模糊的表现]
- **认知混淆点**：[文案或视觉隐喻的二义性]
### 💡 优化方案 A：[方案名称]（最佳体验）
- **核心思路**：[一句话]
- **交互表现**：
- 状态1：[渐进式呈现细节]
- 状态2：[对应变化]
- **方案优势**：[...]
### 💡 优化方案 B：[方案名称]（低成本稳健）
- **核心思路**：[一句话]
- **交互表现**：
- 状态1：[置灰/蒙层/锁定规则]
- 状态2：[恢复激活逻辑]
- **方案优势**：[...]
### 📐 深度细节优化建议（可选）
- **文案规范**：[如何统一固定文案]
- **微动效/反馈**：[Tooltip、呼吸灯等]
注意事项
底层方法论（供参考，无需在输出中展开）
- 第一性原理：先问本质目的，再看表象。
- 状态机逻辑：穷举状态组合，检查断层，而非只看"常见路径"。
- 认知摩擦最小化：文案固定化、视觉符合直觉、层级扁平化。
- 渐进式呈现：不该看的时候不展示，保持界面干净；同时给出低成本折中方案应对开发排期或版式稳定性约束。
- 区分已观察事实与推断行为；缺少业务规则时列出待确认项，不得自行编造。
