`guide` 给你一套清晰的设计规则，`review` 给你带优先级的修复清单。下面三个示例用同一业务目标的“前后界面”对比， 把差异做成可视化结果：主任务更清晰、提示更克制、状态更完整、操作更可发现。
直接点名 Skill + 说清页面目标，输出会更稳定。
请使用 $oiloil-ui-ux-guide 的 guide 模式。 页面类型：B 端设置页。 输出：简洁的“该做 / 不该做”规则。
请使用 $oiloil-ui-ux-guide 的 review 模式。 目标：提升首次配置完成率。 输出：P0/P1/P2 + 修复方案 + 验收标准。
不追求写很多，只保留最能稳定结果的规则：先过这 6 条，再做视觉润色。
同样是“完成首次配置”，差异主要来自提示分层与主操作的层级。
主操作与次级按钮同权重，用户容易误点或犹豫。
提示重复且过多，扫描成本高，关键约束不突出。
缺少保存后的结果反馈，用户不知道是否生效。
同样是“看数据”，差异来自主次层级与关键风险的可见性。
只保留一个主指标做视觉主点，其他指标降权作为支撑信息。
关键风险要可见，并提供可点击的下一步入口。
不要让所有数字同权重铺满首屏，用户难以判断重点。
同样是“打开项目”，差异来自操作可发现性与一致的行动入口。
请使用 $oiloil-ui-ux-guide 的 review 模式。 页面：项目列表（列表-详情）。 目标：减少误点，提高“查看项目”的可发现性。 输出：P0/P1/P2 + 修复方案 + 验收检查点。
把抽象概念变成可检查的界面信号：可做什么、怎么做、做完发生了什么、错了怎么恢复。
设计手段
诊断标签
目标是对的，但点错了/手滑了。修复方向：可撤销、更安全的触达、二次确认。
理解错了：以为“删除”只是移出列表。修复方向：命名、后果、概念模型要更明确。
同一个界面，在不同状态下也要“可理解、可操作、可恢复”。
加载 / 空 / 错误 / 成功 / 权限状态，且每个都有可执行下一步。
只用全局 toast 代替关键页面状态；状态和内容混在一起导致难读。
骨架屏保持布局稳定；失败后尽量保留用户输入。
少量关键细节决定“看起来专业”，也决定“用起来不费劲”。