superior-ui-audit

卓越的 UI 审查

根据实际支配某个连贯产品界面的规范进行审查。优先提供少量证据充分的发现，而不是罗列大量风格意见。

范围界定

• 将产品源代码视为只读。
• 审查期间不要安装依赖、格式化文件或修改生成的制品。
• 仅在用户要求，或有必要使用只读工具证明视觉问题时，才渲染或交互操作 UI。
• 除非用户将功能缺陷、无障碍问题、性能问题和代码质量纳入范围，否则不要将其写入报告。
• 如果用户要求修复 UI，本审查技能不应凌驾于该请求之上；请改用实现工作流。

追踪界面

从范围内的路由、屏幕、组件系列或用户旅程开始。沿着实际路径追踪布局、组合、组件、变体、令牌和最终解析出的样式。名称相似或文件位置相近只能作为候选，不能证明其所有者会影响该界面。

记录该界面、相关所有者、设计依据、明确的例外，以及可获取时的当前修订版本。

重建局部规范

仅使用当前有效的依据：

• 已采纳的设计或品牌文档；
• 已发布的令牌和组件契约；
• 已证明共享所有权的代表性界面；
• 同一用户旅程中的直接矛盾；
• 为本次审查提供或检查的渲染证据。

草案和提案描述的是未来意图，除非仓库将其标记为已采纳。缺少文档本身并不构成 UI 缺陷。

证实每项发现

一项发现只有满足以下条件才可保留：

1. 观察： 所选界面上确切的表现结果；
2. 规范： 表明该属性应由什么规范支配的证据；
3. 关联： 证明所引用的所有者会作用于受影响界面的依据；
4. 修正： 一个明确且不会臆造产品意图的改动。

如果证据支持多种互不兼容的修复方案、差异属于有意的例外，或提议的修正主要改变业务行为，则应剔除该候选项。

报告前，重新打开所引用的来源，并主动查找反证。

报告

最多返回五项发现，并按用户影响、置信度、影响范围和修正成本排序：

## Audit scope
- Surface:
- Governing evidence:
- Runtime owners:
- Explicit exceptions:

## Findings
| # | Observed problem | Evidence and connection | Required correction | Reach | Confidence |
|---|---|---|---|---|---|

## Highest-leverage change
<One finding, or “No supported recommendation.”>

如果没有任何发现通过证据检验，请直言说明。不要凑数。

规划选定的工作

用户选定某项发现或明确要求制定计划时，请阅读 references/change-plan.md。针对每个根本性修正分别编写一份完整独立的计划。执行者无需查看审查对话，也应能理解所有权、范围、保留要求和验证方式。