用户体验定律 — 索引与协议
本文件用于选择模式、确定适用的 30 条定律，并定义它们如何协同工作以及如何报告。每条定律都位于 references/ 下的独立文件中，文件名与下表中的名称一致（例如 fitts-law → references/fitts-law.md）。仅打开你选择的相关文件。
如果用户提到了某条具体的定律（例如“根据波斯特尔定律审查这个表单”），则仅打开该定律的参考文件，并按用户要求的模式使用它。审查仍需遵循本文件的第 5 节。
0. 文件与环境
此技能适用于任何能够读取文件的智能体，不依赖于特定的工具。
- 路径：本技能中所有文件（包括引用的文件）的路径，都是相对于包含此
SKILL.md的目录。references/fitts-law.md始终指代<技能目录>/references/fitts-law.md，即使它出现在另一个引用文件中也是如此。 - 如果你无法打开参考文件（例如，此文本是直接粘贴到提示中，而没有附带其文件夹），请说明情况并请求你需要的定律文件。不要凭记忆运行检查：检查 ID、严重性和证据类型仅在这些文件中定义。
- 证据取决于你能检查的内容。 如果你无法查看图片，那么截图和模拟图对你来说不算
static（静态）证据；请审查你拥有的任何文本或代码，并在审查范围行中说明。如果你无法运行工件，则interactive（交互）和runtime（运行时）证据不在审查范围内，除非用户提供了录屏或测量数据。
1. 选择模式
| 模式 | 使用场景 | 产出物 |
|---|---|---|
| 建议 | 仅存在目标、简报、问题陈述、路线图项或早期概念时。 | 一份简短的方向性简报：此处最重要的定律、它们预测的风险、团队必须回答的问题以及现在需要做出的决策。 |
| 构建 | 设计或实现正在进行中，需要指导参考。 | 针对当前组件或界面的针对性指导，来自相关定律的模式 2，包含具体的数值（如果存在）。 |
| 审查 | 即将提交完成的设计、原型、截图集、URL 或代码差异。 | 一份严格的发现报告，包含严重性、证据、修复建议和结论。 |
如果请求未指明模式，则从输入中推断：目标 → 建议；进行中的工作 → 构建；完成的工件 → 审查。如果仍不明确，询问一个问题。
2. 选择定律
不要为每个任务都打开全部 30 条定律。根据情境选择，然后添加任何与你所见相匹配的触发器。
任何 UI 审查的基线（始终运行）：fitts-law, jakobs-law, cognitive-load, law-of-proximity, law-of-similarity, selective-attention, cognitive-bias。如果工件是交互式的，则添加 doherty-threshold。
按情境：
| 情境 | 打开的定律 |
|---|---|
| 表单、数据输入、注册 | postels-law, working-memory, chunking, law-of-proximity, parkinsons-law, goal-gradient-effect |
| 导航、菜单、信息架构 | hicks-law, serial-position-effect, mental-model, jakobs-law, chunking, pareto-principle |
| 仪表盘、数据密集型及专家工具 | cognitive-load, chunking, law-of-common-region, law-of-pragnanz, flow, pareto-principle |
| 数据可视化和图表 | law-of-pragnanz, law-of-uniform-connectedness, law-of-similarity, von-restorff-effect |
| 新用户引导、首次运行、帮助 | paradox-of-the-active-user, goal-gradient-effect, zeigarnik-effect, cognitive-load, mental-model |
| 定价、套餐、目录、结账 | choice-overload, hicks-law, cognitive-bias, von-restorff-effect, serial-position-effect, peak-end-rule |
| 通知、提醒、状态 | selective-attention, von-restorff-effect, flow, zeigarnik-effect |
| 移动端和触控 | fitts-law, law-of-proximity, serial-position-effect, doherty-threshold |
| 性能、加载、异步工作 | doherty-threshold, goal-gradient-effect, peak-end-rule, flow |
| 重新设计和迁移 | jakobs-law, mental-model, serial-position-effect, aesthetic-usability-effect |
| 自动化、AI 和智能功能 | teslers-law, mental-model, cognitive-bias, doherty-threshold |
| 范围、优先级、路线图 | pareto-principle, occams-razor, teslers-law, hicks-law |
| 视觉设计和设计体系工作 | aesthetic-usability-effect, law-of-similarity, law-of-proximity, law-of-common-region, law-of-pragnanz, von-restorff-effect |
| 错误、失败和结束 | peak-end-rule, postels-law, selective-attention, mental-model |
仅当某个发现或问题实际涉及某条相关定律时，才去查阅该定律。
3. 建议协议
- 用两三行话重述目标、用户和上下文。如果用户或上下文未知，请说明——这是首要风险。
- 从上表中选择 3–6 条定律。超过六条会稀释建议的针对性。
- 针对每条定律，给出它预测的针对当前项目的一两个风险，以及团队必须回答的问题。以定律的模式 1 为来源，但要具体化。
- 列出现在需要做出的决策（预算、默认值、约定、重点规则、度量方式）以及谁应该负责这些决策。
- 明确指出定律之间需要刻意权衡的冲突（参见第 6 节）。
保持在大约一页的篇幅。目标是提供方向，而非预先设计。
4. 构建协议
- 确定正在工作的组件、界面或流程。
- 打开匹配的定律，使用其模式 2 的列表作为参考，引用具体数值（目标尺寸、时间、对比度、WCAG 标准）。
- 当指引发生冲突时，说明情况，并针对当前情况推荐一种解决方案。
- 在构建过程中不要执行完整的审查；仅在问题很可能是 阻止者 时才提及审查级别的问题。
5. 审查协议（严格）
审查的目的是在提交前阻止问题。严格规则：
- 没有证据，不予通过。 检查项仅在工件中存在正面证据时才通过。绝不假设你无法看到的状态、尺寸、时间或行为。
- 无法验证等同于未验证，而非通过。 指出你需要什么（错误状态、测量值、真实数据、设备、代码）。
- 审查范围是明确声明的，而非隐含的。 结论仅涵盖你被赋予的证据。需要某类证据但未提供的检查项，被列为“超出范围”；因此，截图审查不能被视为完全通过。
- 不要软化语气。 不要添加赞美性的“润色”，不要使用“总体看起来很好”之类的表述，也不要因为截止日期或已投入的努力而降低严重性级别。
- 要具体。 每个发现都应指明位置（界面、组件、元素或文件:行号）、你的观察以及具体的修复建议。
- 一个问题，一个发现。 如果多条定律标记了同一个问题，仅报告一次，列出所有检查 ID，并使用最高的严重性。
- 明确报告通过的定律。 列出哪些定律已应用且未发现任何问题，以便审查覆盖面可见。
步骤：
- 盘点你被赋予了哪些内容（界面、状态、视口断点、代码）以及缺少什么，并设定证据范围：你拥有下方所列的哪些证据类型。
- 选择基线定律和情境定律。
- 运行每个选定定律模式 3 表格中的每个检查项。将每个检查项归类为：
- 已检查 — 通过或产生了发现；
- 未验证 — 其证据类型在范围内，但所需的状态、元素或测量值缺失（例如，范围是
static，但没有错误状态的界面截图）； - 超出范围 — 其所有证据类型均不在范围内；
- 不适用 — 工件中不存在检查项所涉及的内容（例如，在一个纯鼠标操作的桌面工具上检查
FIT-1）。用几个字说明原因。
- 合并重复项，分配严重性，编写修复建议。
- 给出结论及其范围。
证据类型
模式 3 的每个检查项都有一个证据列，列出了可以判定该检查项的输入类型。当列出多个类型时，任何其中之一即可。
| 类型 | 是什么 | 典型输入 |
|---|---|---|
static | 在相关界面和状态的静态图像中可以看到的内容。 | 截图、静态模拟图、带测量值的设计文件、流程板 |
interactive | 仅在你操作时才能显示的内容：键盘、焦点、过渡、体验到的时序、操作后发生的结果。 | 可点击的原型、正在运行的构建版本、URL、屏幕录屏 |
code | 源代码或标记中的内容：语义、ARIA、autocomplete、点击区域、令牌以及源代码明确规定了的行为（错误处理程序做什么、输入是否保留、焦点在何处）。 | 差异对比、组件源代码、渲染后的 DOM |
runtime | 在真实硬件、网络和数据上的测量值。 | 性能跟踪、真实用户监控 (RUM) 或实验室数据 |
context | 工件之外的事实：使用数据、研究、决策记录、业务规则。 | 分析数据、研究发现、PRD 或 ADR、团队的声明 |
只有当你有实际证据时，才认为该证据类型在范围内。被告知代码存在并不会使 code 类型自动进入范围。
严重性
| 严重性 | 含义 |
|---|---|
| 阻止者 | 妨碍或误导核心任务；存在数据丢失、财务、安全或人身伤害风险；未通过 WCAG 2.2 AA 标准；或属于欺骗性模式。必须在提交前修复。 |
| 主要 | 显著的摩擦、容易出错的设计或与约定或设计体系明显不一致。在提交前修复，或由指定负责人明确接受并安排跟进。 |
| 次要 | 润色和一致性。在下次涉及该区域时修复。 |
结论
应用第一条匹配的规则：
- 任何 阻止者 → 请勿提交。
- 任何在范围内的 阻止者 检查项为 未验证 → 等待证据，提交受阻。 说明缺失的状态或测量值，团队本可以用他们已经提供的证据来补充。
- 任何 主要 → 仅当每个主要问题都已修复或由指定负责人接受后方可提交。
- 只有 次要 或无 → 通过。
每个结论都包含其范围，例如 通过（静态范围）。如果任何阻止者检查项超出范围，请在结论行列出它们及其各自需要的证据类型，例如 超出范围: JAK-1 (interactive), SA-2 (interactive), DOH-1 (interactive)。只有当所选定律中没有任何阻止者检查项超出范围或未验证时，结论才能是无条件的（仅为“通过”）。超出范围的检查项不会改变结论。它们告知团队哪些内容尚未审查，以及在发布前是否需要使用更多证据进行第二轮审查。
报告模板
## 用户体验定律审查 — <工件名称>
审查对象: <审查了哪些内容：界面、状态、断点、文件>
证据范围: <static | interactive | code | runtime | context — 实际提供的那些>
未提供: <缺失的状态或证据>
应用的定律: <代码>
结论: <请勿提交 | 等待证据，提交受阻 | 接受主要问题后提交 | 通过> (<范围> 范围)
超出范围: <阻止者检查ID及其需要的证据类型，若没有则填“无”>
### 阻止者
- [阻止者] FIT-1, JAK-1 · <位置> — <观察> → <修复>
### 主要问题
- [主要] CL-2 · <位置> — <观察> → <修复>
### 次要问题
- [次要] SIM-6 · <位置> — <观察> → <修复>
### 未验证（在范围内，证据缺失）
- POS-2 · <无法检查的内容> — 需要 <特定的状态或测量值>
### 超出范围
- interactive: JAK-1, SA-2, DOH-1, …
- code: CH-3, PKL-3, …
### 不适用
- FIT-1 — <原因>
### 已应用，未发现问题
<codes>
6. 常见权衡
| 权衡 | 默认解决方案 |
|---|---|
| 希克/奥卡姆（更少选择） vs. 帕累托长尾和专家需求 | 通过渐进式披露保持关键但罕见的功能可被发现；绝不仅仅因为使用率低就移除它们。 |
| 奥卡姆（移除） vs. 泰斯勒（不可简化的复杂性） | 移除偶然复杂性；将固有复杂性转移到系统端，同时提供可见性和撤销能力。 |
| 雅各布（遵循惯例） vs. 差异化 | 在问题域上创新，而不是在核心控件上。偏离惯例需要陈述并经过测试证明其收益。 |
| 冯·雷斯托夫（强调） vs. 相似性（一致性） | 每个视图最多一个被强调的元素；其他所有元素保持一致。 |
| 菲茨（大尺寸、便利的目标） vs. 意外激活 | 将破坏性操作隔离开；对影响重大的操作增加撤销或确认步骤。 |
| 心流（无干扰） vs. 安全确认 | 仅对影响重大、不可逆的操作进行中断。 |
| 认知负荷（显示更少） vs. 工作记忆（显示上下文） | 显示当前步骤所需的上下文；隐藏其余内容。 |
| 波斯特尔（宽松接受） vs. 正确性 | 在格式上宽松，在意义上严格；对模糊但影响重大的值进行确认。 |
| 目标渐进、蔡格尼克、序列位置、冯·雷斯托夫作为杠杆 vs. 用户兴趣 | 仅用于引导用户走向他们期望的结果；参见 cognitive-bias。 |
7. 所有定律
感知与注意力
| 定律 | 代码 | 适用场景 |
|---|---|---|
aesthetic-usability-effect | AUE | 视觉润色、第一印象、品牌表达、可用性测试解读，以及产品外观和实际体验之间的差距 |
law-of-common-region | CR | 卡片、面板、分组、边框、背景填充、表格行、表单组以及任何用于指示项目属于同一组的容器 |
law-of-proximity | PRX | 间距、布局密度、标签到字段的关联、控件和内容的分组，以及间距比例尺 |
law-of-pragnanz | PRG | 图标、插画、数据可视化、布局轮廓、标志以及任何必须一目了然的视觉元素 |
selective-attention | SA | 通知、提醒、状态变化、横幅、新用户引导提示、系统消息，以及放置用户不可错过的信息 |
law-of-similarity | SIM | 视觉一致性、链接和按钮样式、组件变体、状态颜色、图标家族以及设计体系使用 |
[后续部分已截断，因原文如此]