better-interface

界面

此技能负责跨领域评审。它会将界面评审分派给各个 better-* 技能，收集证据，并整合成一份按优先级排序的结论。

它只负责协调工作。无障碍规则归 better-accessibility 负责，结构归 better-layout 负责，文案归 better-writing 负责，字体排版归 better-typography 负责，颜色归 better-colors 负责，视觉润色和动效归 better-ui 负责。

对未提交的工作、分支和拉取请求进行变更范围评审，归 interface-review 负责。

以证据为准，而非个人偏好

严格审查升级触发条件，并尊重项目有意作出的选择。无论样式指南怎么说，触发条件代表的都是缺陷。你只是不同意的密度、圆角或语气，不算问题。

报告问题的门槛是有证据。给出 Approve 的门槛是确实检查了你声称检查过的内容。

1. 先确定范围

根据请求和当前工作区，推断屏幕、流程、功能或代码库范围。在输出中说明确定的范围。

在每个领域都覆盖全部范围，包括其中存在的空状态、加载状态、错误状态和窄屏状态。

当范围过大，无法可信地完成检查时，将其缩小到一个完整流程。优先选择请求重点提及的流程；否则，选择所有用户都必须经过的入口路径。说明范围边界及排除的内容。绝不要暗示检查过未检查的界面。

2. 将变更交由 interface-review

如果请求提及分支、拉取请求、提交范围或未提交的变更，这就是变更评审。说明这一点，并请用户运行 interface-review；它需要由用户调用，无法在此启动。绝不要自行确定变更范围，因为猜测差异会让报告的范围无法核实。

当 interface-review 返回评审结果时，按以下所有要求处理。数量上限和结论仅涵盖 Introduced 和 Regression 问题，因此，如果变更中的问题全是 Pre-existing，结论就是 Approve。

3. 先侦察，再判断

确认框架、样式系统、组件库、设计令牌、支持的视口，以及任何预览或测试命令。所有修复都要遵循项目自身的惯例，绝不要要求项目改用其他技术栈。

然后阅读项目对自身界面的说明：CONTRIBUTING.md、CODING_STANDARDS.md、AGENTS.md、CLAUDE.md、设计系统文档、Storybook 文档和界面 ADR。说明找到的文件，或说明没有找到。

文档中的约定可以解决个人偏好问题，但绝不能成为忽略触发条件或违反领域规则的理由。它改变的是问题的报告位置。如果问题源于指南或共享令牌，只需针对该来源报告一次，并将相关组件列为位置。

4. 以领域技能为准绳

加载以下所有负责领域的技能，并在汇总之前完成各领域评审。按此顺序评审，避免基础问题被视觉润色掩盖：

1. better-accessibility
2. better-layout
3. better-writing
4. better-typography
5. better-colors
6. better-ui

采用每项技能中的原则、参考资料和验证检查。其严重性等级和格式适用于独立评审；本文件中的等级和格式优先于它们。

如果无法使用某项负责领域的技能，将该领域标记为 Not reviewed，注明技能名称，然后继续评审其他领域。不要凭记忆重建其规则，不要用相邻领域的技能替代，也不要声称已完成全面评审。

如果两项技能似乎都涉及同一问题，将问题归给底层规则的负责人，并在 Why 单元格中注明次要影响。

5. 验证可验证的内容

运行项目提供的安全且相关的检查。如果运行时行为或视觉判断很重要，就检查渲染后的界面，并报告具体的命令或交互及其结果。无法运行的检查应标记为 Not verified，绝不能算作问题。

要求提供证据

每项发现都要引用 path/to/file:line，并展示当前实现。如果结果取决于运行时行为，仅凭源代码无法支持视觉问题的判断，仅凭截图也无法支持代码问题的判断。

按用户影响排序

使用统一的严重程度等级：

• HIGH：阻碍任务、误导用户、隐藏内容或控件、造成数据丢失风险，或引发反复出现的系统性故障。
• MEDIUM：显著损害理解效率、适应性或一致性。
• LOW：影响有限的局部润色问题。

在同一严重程度内，按问题影响的位置数量，以及一次修复能带来的改善程度排序。修复设计令牌或共享组件，优先于只在一个叶节点中处理相同症状。

升级触发条件。 负责的技能一旦确认存在以下任一情况，立即定为 HIGH，不得因影响范围较小而降低等级：

• 交互控件没有无障碍名称。
• 键盘可访问的控件没有可见的焦点指示器。
• 某控件或路径可通过指针访问，但无法通过键盘访问。
• 动画或自动播放内容未遵循 prefers-reduced-motion。
• 在 320px 宽度或 200% 缩放下，内容或控件被裁切、遮挡或无法访问。
• 正文或控件文本的渲染对比度未达到要求的比例。
• 状态或含义仅由颜色传达。
• 破坏性操作没有确认、撤销选项或明显区别。
• 内容被截断，且没有办法查看完整内容。
• 内容或控件只能滚动到边缘之外，或只能通过没有可见提示的折叠区域访问。
• 错误信息未说明如何恢复。
• 语义颜色的使用与其含义相悖，例如在非破坏性操作上使用危险色调。
• 动画未运行时，状态变化仅由动画传达，且没有保留颜色、图标或标签来说明状态。

这些触发条件的优先级高于其他所有发现。如果触发条件数量超过上限，先列出这些问题，并说明有多少项因上限而未列出。上限可以缩短报告，但绝不能成为遗漏阻断性问题的理由。

这些条件用于确定严重程度，而非增设新规则。负责的技能判断是否存在相关症状；此列表决定其影响程度。

优先选择成本更低的修复方案

严重程度说明问题有多严重；此处说明应提出哪种修复方案。如果有多种可行方案，优先采用最先满足要求的一项：

1. 删除。 删除可由留白替代的分隔线、高频交互上的动画、原生元素已包含的冗余 ARIA 属性，以及没有被任何内容引入的色阶。
2. 使用平台原生功能。 使用原生元素、原生控件或浏览器自带的焦点环，而不是重新自定义实现。
3. 复用项目现有资源。 优先使用现有令牌、间距级别或动画曲线，而不是新增值。
4. 修正值。 使用负责的技能给出的准确值，修正错误的缓动、圆角半径、间距或对比度。
5. 新增。 新增令牌、包装器、媒体查询，或平台无法提供的 ARIA 属性。

如果被审查的代码新增了可通过删除解决的问题，这就是一项发现，其 After 应为删除该内容。

合并系统性问题

一个根本原因对应一项发现，并在同一行中列出所有已确认的位置。最多报告 15 项发现。不要为了凑满上限而填充内容；简短的审查结果或没有发现问题，都是有效结果。

默认以只读方式审查

将审查请求视为只读。除非用户也要求实现这些修复，否则不要编辑源代码。如果用户要求实现，请将合并后的报告作为修改范围，并在之后重新运行相关验证。

完成前

错误	修正
每个领域单独设置发现项章节	将发现项合并到一个表格中，按严重性排序，其次按影响范围排序
渲染结果的唯一依据是源代码，却声称已验证渲染效果	检查渲染状态，或标记为 未验证
缺少可访问名称或焦点环，却因为影响范围较小而评为 MEDIUM	一经发现即标记为 HIGH
覆盖情况行的证据单元格未注明文件、组件或检查项	检查该领域，或标记为 Not reviewed 并说明原因
某个领域的技能从未加载，却标记为 Clear	标记为 Not reviewed 并注明该技能
同一症状在多行中分别对应多个组件	针对共享令牌或组件列出一行，并列出所有位置
After 新增了包装器、令牌或 ARIA 属性	先检查删除操作或原生元素是否能解决问题
修复方案使用了项目并未采用的库或样式系统	改用项目自身的惯用写法

审查输出格式

格式见 review-format.md：范围与覆盖情况、发现项表格、验证和结论。只有将发现项报告在其中，审查才算完成。