ux-audit

UX 审计

一次只审查一个界面，采用可重复、基于标准的 UX 评审方式。基准由以下两项共同构成：

1. Jenifer Tidwell，《Designing Interfaces》——说明优秀界面由哪些模式构成的模式语言。请参阅 references/pattern-catalog.md。
2. ux 技能——LobeHub 关于流程应如何_运行_的执行检查清单。

审计要回答：界面使用了哪些模式（以及效果如何），以及体验有哪些薄弱之处（每个差距都与一项检查清单条目关联）。反复出现的差距会反馈为新的 ux 检查清单条目；审计本身也会成为一份示例参考。

每次只审计一个界面——一次性审查整个应用，工作量太大。随着产品发展，逐页重新审计；这就是“持续”的含义。

三个层级——根据需要发现的问题来选择

审计并非单一活动。只有能够实际_观察_到问题的层级，其发现才可信。每个层级都有自己的流程文件；根据界面需要运行相应流程。

层级	文件	作用	可发现的问题	成本
L1 静态	layer-1-static.md	阅读代码	缺少状态/分支（空状态/错误/重试）、草稿未持久化、缺少模式、结构问题	成本低、离线、每次审计都需执行
L2 视觉	layer-2-visual.md	获取渲染后界面的屏幕截图	实际视觉层次与主要控件、间距/对比度/对齐、截断/溢出、空状态/加载中/错误状态的实际观感、响应式断点、深色/浅色	成本中等；需要渲染
L3 动态	layer-3-dynamic.md	通过验收和检测来驱动真实的用户旅程	进行中/锁定状态、强制触发错误/空状态、步骤 N 是否能进入 N+1、焦点/键盘、量化的 CLS / LCP / INP / 长任务	成本高；需要运行环境和身份验证

覆盖矩阵 — 各层能得出什么结论

核心原则：结论必须来自能够观察到相应情况的层。 不要仅凭代码就判定视觉或运行时问题。

发现类型	L1	L2	L3
缺少空状态／错误分支、没有重试、草稿未持久化、缺少相应模式	✅	—	—
真正的视觉层级／最显眼的控件是否为主要操作	❌ 会误导	✅	✅
间距／对齐／对比度／截断／溢出／深色模式	❌	✅	—
屏幕外的选择项；空状态／加载状态／错误状态实际呈现的内容	❌	✅	✅
响应式断点（窄屏／移动端）	❌	✅	✅
进行中／锁定状态；强制触发的错误／空状态；受功能支持情况限制的状态	❌	❌	✅
流程衔接（步骤间的推进连贯性）	较弱	较弱	✅
焦点顺序／键盘可达性	❌	❌	✅
CLS／LCP／INP／长任务数值	❌	仅定性分析	✅
两个变体中哪个_更好_（A/B 胜出者）	❌ 会误导	❌ 会误导	✅（+ 分析数据）

⚠️ 这可以避免一个常见陷阱：仅凭代码中的 variant 属性，就认定“只有一个主按钮”或“空状态是真实页面”。这些都属于 L2 结论——必须在渲染结果中确认，不能只看 L1。

分层 — 不要每次都运行全部三层

• 始终运行 L1 — 对每个界面进行快速、完整覆盖的基线检查。
• 发现涉及布局、层级、渲染状态或响应式设计时，添加 L2。
• 需要走完流程、触发 L1／L2 无法触及的状态，或测量性能（CLS 等）时，添加 L3。

--l1 / --l2 / --l3 可将一次运行限定为某个层；默认运行 L1（如果提供了截图，则加上 L2）。

基本原则：依据证据，而非直觉

每项发现都必须注明证据来源——file:line（L1）、已使用 Read 工具核验的截图（L2），或捕获的数值／快照（L3）。提出关键主张前，请在负责核验该主张的层中确认；错误地断言“它缺失”比不提出任何发现更糟。

基本原则：基准应依据界面类别，而不只是我们自己的产物

阅读代码只能发现我们构建的内容中存在的问题——对于我们根本没构建过的功能，它在结构上视而不见，因为完全缺失的交互入口不会留下任何 file:line、失效分支或接线不完整的按钮供你搜索。检查清单能保障现有状态的质量；但它们不会告诉你此类界面应当具备哪些状态。

因此，在阅读代码之前（或同时），先明确界面的类别及其领域惯例：成熟且可比的产品会如何构建这个确切的屏幕？它们提供了哪些第一版产品容易遗漏的功能？例如，OAuth 授权屏幕的类别规范（GitHub / Google / Okta）包括：显示你正以哪个身份进行授权，并允许用户切换账户／重新进行身份验证；标明发起请求的应用，列出权限范围，允许用户拒绝，并指出之后如何撤销授权。文件选择器、结账流程、分享对话框也各有各自的类别规范。先写下这份预期功能清单，再据此审查缺口——否则，审查只会不断打磨已存在的流程，并在不知不觉中默认缺失的流程也没问题。

❌ OAuth 审查的第一轮只根据我们的内部状态检查清单衡量授权流程，并报告了按钮层级／重试方面的缺口，却漏掉了最大的问题：授权屏幕将用户锁定在当前身份，没有切换账户的途径（OAuthConsent/Login.tsx）——而所有可比的 OAuth 提供商都会遵循这一类别规范。对照竞争产品规范的审查第一分钟就能发现这个问题；只看代码的审查永远无法发现。

基本原则：比较两个变体——胜出判定关乎结果，而非制作水准

审计比较同一界面的两个变体（“Agent 还是 Classic 的引导流程更好？”）时，容易陷入的误区是判断哪个做得更好（更精致、模式更多、更具 AI 感），而真正的问题是哪个更能帮助用户达成目标。对于网关／过渡界面——引导流程、征求同意、付费墙、加载门槛——两者的差异会非常大：最佳版本往往是_最精简_的版本，因为该界面_挡在_用户与其目标之间。制作水准不等于结果，更丰富的产物往往反而更差。

因此，比较变体时必须：

1. 先明确成功指标，再据此评判。 引导流程看完成率、达到价值所需时间和流失率，而不是模式丰富度。结账看转化率。评分前先写明指标，否则你会默认按制作水准打分。
2. 只有达到 L3／分析数据的门槛，才能判定胜出。“哪个变体更好”是行为结果——它属于覆盖矩阵中与 CLS／INP 并列的 L3 行。基于 L1／L2，你可以比较机制（“A 的错误恢复更完善”“B 的步骤更少”）；但不能宣布胜出者。没有漏斗数据 → 就说“证据不足，以下是我需要的数据”，然后停止。先自信地宣布胜出者，再把“需要 L3”藏在附注里，这正是问题所在——这条附注并不能为判定背书。
3. 用户付出的成本是首要评估维度；对于网关界面，应反向加权。 时间、步骤、令牌、延迟。超过某个阈值后，在用户想要_通过_而非_进入_的任何界面上，丰富度都会成为_负担_。
4. 围绕用户的真实目标来判断意义感，而非围绕功能的丰富程度。 用户目标在别处时，如果流程把用户留在流程本身，那么即使更吸引人，意义感也会_更低_——正确理解后，在这种情况下，意义感和自然度都会倾向于快速路径。不要把“更具对话感／更多 AI／制作更精良”误认为“更有意义”。
5. 把组织显露出的偏好视为证据。 功能标记、哪个变体是回退方案、受限制最多的平台（桌面端）被迫使用哪个变体，以及近期的回退记录。当通用回退方案_就是_变体 B 时，B 就是值得信赖的基线，举证责任在 A 一方——不要把这些信号解释成“上限与下限”。
6. 选对参照类别，并按真实意图分布加权。 AI 工具的首次使用体验，应对照 ChatGPT／Claude／Cursor（几乎无需引导流程，直接进入输入框），而不是那些奖励详尽引导流程的 SaaS 设置向导（Notion／Linear）。按最常见的用户（想跳过引导的用户）打分，而不是按理想的高参与度用户打分。

❌ 本技能自身的误判：一次 L1 评估认为 Agent 引导流程“优于”Classic，因为它更精致／更具对话感（完成面板更丰富、提供名称建议、视图切换更流畅），并引用了意义感 ≳ 自然度 > 确定性。实际上，Agent 的有效引导完成率并不高，用户觉得它太慢（他们想要的是工具，而不是聊天），组织也回退到了 Classic。以上错误无一遗漏：把制作水准当成结果，反向评估意义感，把成本放在脚注里，将一个属于 L3／分析指标的结论仅凭 L1 就判定胜出，还把受功能标记控制／降级为 Classic／桌面端排除在外等信号解释掉了。

基本原则：“冗余”控件首先是组合问题，而非删减问题

当 L1 发现两个看似作用相同的控件时，第一反应往往是删减—— 删除一个、隐藏一个、合并它们，或让重复项有所区别。请克制这种冲动。两个控件即使 _意图_相同，作用范围也常常不同；坦诚的修复方式应通过布局表达这种范围差异—— 将作用范围更广的控件提升为一个可见且有标题的并列项——而不是将其删除。删减是 _行为_层面的操作；更好的答案通常存在于组合层面，而这恰恰是审查者只走一遍 ux 检查清单，却从未打开 references/pattern-catalog.md 时会漏掉的基准测试的一半。检查清单谈的是状态、 操作惯性和草稿安全；它们没有_带标题的分区 / 等列网格 / 中心舞台_这类术语，因此只看检查清单的人总会想到“去重”。在为任何“冗余 / 重叠” 问题编写修复方案前，先完成模式目录检查（L1 步骤 2），并问问自己：意图相同，作用范围不同？ → 修复方式是并列呈现，而不是删除。

❌ CC AskUserQuestion 审查将每个问题旁的“自己编写”框和全局的 “或直接输入”入口标记为冗余，并建议隐藏 / 合并它们——这属于删减。 它们并不冗余：每个问题旁的输入框作用于_问题_，而该入口作用于_整个表单_。组合层面的答案是：只有一个问题时隐藏该入口；有多个问题时，将其作为问题区块的可见并列项呈现——这是一种_带标题的分区_布局，只有检查清单的审查方式不会揭示这一点。跳过模式目录，错失了更好的答案。

基本原则：报告优点，而不只是缺陷

如果审查只列出出问题的地方，那就已经偏离方向，变成了 Bug 报告。任务要求报告正在使用哪些模式，以及使用得有多好——因此优点是一级发现，而不是表格装饰。设计完善的状态机、保存失败后仍能保留的草稿、开放重定向防护、智能默认值：这些都是优秀案例。请点明它们，注明其 file:line，并将突出项标记为 ✅ 亮点，原因有三：

• 它们能传授经验。 优秀案例是回灌循环中的 ✅ 部分——它会成为 ux 检查清单条目引用的正面示例，就像缺陷会成为 ❌ 示例一样。审查中没有优秀案例，只会一味强化检查清单中的 ❌ 部分。
• 它们能起到保护作用。 “不要让它退化”本身就是一项发现。后续重构需要知道哪些行为至关重要——example/task-detail.md 中的值得保留的优点区块（加载 / 未找到状态机、失败时保留评论草稿、全部运行预览 → 确认流程），以及 example/home.md 中的 ✅ 亮点条目（空内容发送 → 当日提示回退、抽屉不导航的界面契约），正是这样的清单。
• 它们能校准严重程度。 同一个缺陷，出现在整体表现良好的界面上，与出现在全面薄弱的界面上，意义不同；优秀案例是给缺陷排序的基准。

❌ 这条原则要防止的是这种偏差：审查中的“正在使用的模式”✅ 条目只有一个词的评价 （“持久”、“强大”、“教科书式”），而每个缺陷都有一段说明——优秀案例被降格成复选框。 example/task-detail.md 是应该效仿的范例： 每个突出模式都有对应的 file:line 和 ✅ 亮点标记，让优点和缺陷一样清晰可见。

严重程度分级（通用）

• 🔴 破坏信任——数据／输入丢失、卡住／永久性状态、掩盖故障的误导性“空状态”、发送失败却不提示。
• 🟠 无路可走或产生误导——没有后续路径、状态含糊、缺少进行中反馈、不是真实页面的空状态。
• 🟡 操作阻力／不一致／错失惊喜——可预测性、冗余控件、渐进式披露缺口、CLS 抖动。此级别最容易漏报：只检查正确性会偏向 🔴／🟠，忽略细节一致性——同类元素的样式不同（选项带数字标签，自由文本行却没有）、有操作暗示却没有标签。当界面其他方面都很扎实时，应有意在一轮检查中切换到界面细节视角，否则这些问题永远不会被记录下来。

输出（通用）

参见完整示例 references/example/home.md。注明检查了哪些层级，然后：

1. 正在使用的模式——表格（来自 L1/L2），按模式系列分组，并附上一句话说明；将每个突出的 ✅ 行标记为 亮点，并提供真实依据（file:line），绝不能只打一个勾。
2. 优点／良好案例（不要回归）——设立一个专门的章节（## … — 优点／良好案例），而不是表格脚注：列出带有 ✅ 亮点 标记的条目，每项都要说明此界面做对了什么行为、提供依据（file:line），以及_为何_该行为至关重要——这是回灌循环中 ✅ 的一半，也是下一次重构的“不要回归”清单。将足以作为 ux 中 ✅ 示例 的案例标出（注记 → landed as ux <ref> ✅，并关联到 Skill 反馈章节）。每次审查都必须包含此章节——如果某个界面整体表现确实薄弱，请明确说明，不要省略。章节格式参见 example/fleet.md §2。
3. 体验缺口——按优先级排序；每项都需注明发现、违反的 ux 检查清单项目／目录模式、发现它的层级＋依据，以及一句话的改进建议。
4. Skill 反馈——说明现有检查清单项目的实际案例，以及值得添加到 ux 的新通用缺口；并列出值得作为 ✅ 示例收录的良好案例（见下文回灌）。

落实发现（共用）

审查并非写下发现就算完成，而是要落实才算完成。要结束一次审查，以下三步缺一不可：

• 具体缺陷 → 在同一次审查中修复，至少修复所有 🔴 项。任何未解决的问题都要保留在报告的差距列表中，并说明未修复的原因（需要产品决策、服务端变更或重新渲染确认）。
• 可推广的差距 → 回灌 ux（必须）。 每次审查都必须将结果反馈到 ux 技能中：对于每项适用于当前界面以外场景的发现，都要添加或强化一条 ux 检查清单项（规则 + ✅/❌ 示例，放入正确的模块），并引用审查过的界面作为 ❌ 示例。只有当现有提示未涵盖相关要求时，才在 ux 快速检查中添加或更新简短提示；示例和实现细节应放在模块中。这正是让审查保持_持续性_的方式——每次审查都应让检查清单比审查开始时更加完善。如果某次审查确实没有发现可推广的差距，请在报告的 Skill-feedback 部分明确说明（仅限已验证的现有规则实例）——不作说明不能算完成。
• 出色的案例 → 回灌 ux，完善规则（而非只是润色）。 回灌有两个方面：差距会完善检查清单项中的 ❌ 示例，优秀案例则会完善 ✅ 示例。但只有在优秀案例能教会规则新东西时，才值得纳入——✅ 示例只是基础；目标是完善规则文本，或提炼出当前规则尚未说明的潜在子规则/检查清单项。因此，当审查发现某种模式做得格外出色时，应思考：这项实践采用了什么尚未被规则要求的技巧？ 然后将其融入规则——完善表述、将一条单触发条件规则拆分为实际存在的不同情形，或添加检查清单项，并引用该界面作为 ✅ 示例。仅仅重新展示一条已经完善的规则，价值不大；揭示缺失的区别，才是优秀案例的意义所在。（例如，Fleet 的滚动到视图中功能提炼出“重新运行的触发条件分为两种——异步到达与先以命令方式添加再绘制”，以及“滚动轴应与列表方向一致”，并将其加入 Read §1.3；其骨架还提炼出“匹配文本的宽度比例，而不仅是高度”，并将其加入 Feedback §4.1——这些内容此前都未曾说明。）
• 审查结果 → 保存为 references/example/<page>.md，供下次审查参考。

审查与 ux 技能构成一个闭环：ux 是审查所衡量的基准，而审查则是确保 ux 始终经得起检验的机制。跳过回灌会打破这个闭环，使审查沦为一次性检查。

相关技能

• ux — 本审查所依据的执行检查清单，也是可推广发现的归档位置。
• acceptance — L3 所依赖的自动化框架（agent-browser CDP：快照 / 评估 / 截图 / GIF）。L3 假设其 Step 0 的环境与身份验证均正常。
• deep-review — 代码级审查；本技能是其设计级姊妹技能（deep-review 的 ux 维度会在代码审查中检查流程；本技能则审查整个界面）。
• skills-audit — 同样采用“定期、有证据支撑的审查”模式，不过审查对象是技能目录。