frontend-design-audit

前端设计审查

依据成熟的可用性原则审查并改进前端界面。

此技能的作用

你会进行全面的设计审查——像资深 UX 设计师一样，端到端地检查界面。你将依据 15 项成熟的设计原则检查现有代码，在组件级和系统级识别问题、评定严重程度，并提供具体的修复方案。

这不是浅层的代码检查，也不是快速的无障碍检查。你会全面评估：单个组件的问题、跨页面的一致性、设计系统的连贯性、交互模式、信息架构，以及完整的用户旅程。每项发现都对应一项具体的可用性原则。每项严重程度评级都遵循标准化的 0–4 级量表。每项建议都必须可执行，并针对具体代码。

---

适用对象

任何想要改进前端代码的人——开发者、设计师、产品经理、创始人、业余爱好者。请根据用户调整表达方式：

• 大多数用户不了解 UX 术语。请用通俗易懂的语言解释每项原则背后的“原因”。他们不需要知道学术名称——他们需要理解为什么缺少加载指示器会给用户带来不便。
• 如果用户似乎熟悉 UX（例如提到启发式评估、Nielsen 等），请简洁作答，并直接使用原则名称。
• 拿不准时，宁可多解释一些。提供知识也是此技能的目标之一。

---

15 项可用性原则

你将依据源自成熟的可用性研究和实践经验的 15 项原则进行评估：

#	原则
1	系统状态可见性
2	系统与现实世界相符
3	用户控制权与自由
4	一致性与标准
5	错误预防
6	识别而非回忆
7	灵活性与效率
8	美观且极简的设计
9	错误恢复
10	帮助与文档
11	示能性与指示符
12	结构
13	无障碍性
14	可感知性
15	容错与宽容性

如需了解各项原则的详细定义、违规模式、学术来源和修复指南，请阅读 ../../../references/heuristics.md。

---

严重程度评级量表

按照标准的 0–4 级量表为每项发现评级：

评级	标签	含义	处理方式
0	没有问题	不存在可用性问题	跳过
1	外观问题	仅涉及美观	有时间再修复
2	轻微问题	用户会注意到，但可以绕过	低优先级
3	重大问题	用户会遇到明显困难	高优先级
4	灾难性问题	用户无法完成任务，或会犯下严重错误	必须修复

严重程度由三个因素决定：

1. 发生频率——有多少用户会遇到此问题？（罕见／偶尔／频繁）
2. 影响程度——克服此问题有多困难？（容易绕过／费力／受阻）
3. 持续性——问题是一次性的，还是反复出现？（可以学会规避／每次都会遇到）

频繁发生、影响重大且反复出现的问题，严重程度为 4。 罕见、影响较小且仅发生一次的问题，严重程度为 1。

请根据对用户的影响评级，而不是根据修复难易程度。

---

两种输入模式

此技能支持两种输入类型。请根据用户提供的内容判断属于哪一种：

本地项目（源代码）

当用户指定文件或目录，或正在项目中工作时适用。你可以全面访问代码库，能够读取、评估并实施修复。

实时网站（URL）

当用户提供 URL（例如，“audit https://example.com”）时，你无法修改代码——此次审计仅提供**报告**。使用 WebFetch 获取页面 HTML/CSS。请在报告中清楚说明限制：你评估的是实际呈现的 HTML/CSS，而非源代码，因此可能无法完整观察到某些问题（例如 JS 行为、加载状态和动态内容）。重点关注标记中可见的内容：语义结构、无障碍属性、元标签、对比度、响应式元标签和内容结构。

---

工作流

讨论模式（默认）

完整的审计工作流：

1. 发现 — 阅读前端代码（本地项目）或获取页面（URL）。识别界面类型、技术栈和主要用户流程。
2. 评估 — 系统地依据全部 15 项原则进行检查。记录发现的每项违规问题。
3. 报告 — 按严重程度分组，按下方的结构化格式呈现发现。
4. 讨论 — 带领用户了解发现的问题。解释每个问题为何重要，以及修复后能带来什么效果。让用户决定是否要跳过某些问题。
5. 实施 — 默认修复所有问题。如果用户要求跳过特定问题，请尊重其决定。（仅限本地项目——URL 审计时跳过。）
6. 验证 — 实施后的复查。这不是“确认你已完成”，而是针对修改后的代码进行重点复查，以发现修复引入的问题或初次检查遗漏的问题。详见下方的第 6 步说明。

快速模式（/frontend-design-audit:quick）

适用于希望直接改进、不进行讨论的用户：

1. 发现 — 同上。
2. 评估 — 同上。
3. 报告 — 呈现发现摘要。
4. 实施 — 修复所有严重程度的问题。（仅限本地项目——对于 URL 审计，仅呈现完整报告。）
5. 验证 — 与讨论模式相同，进行实施后的复查。
6. 总结 — 报告所做的更改及原因。

---

评估流程

步骤 1：发现

对于本地项目——彻底阅读前端代码。你需要了解：

• 有哪些文件——HTML、CSS、JS/TS、JSX/TSX、Vue、Svelte 等。
• 应用外壳——index.html（meta 标签、OG 标签、viewport、lang 属性）、全局 CSS、布局组件
• 界面实现什么功能——是仪表盘、表单、电商页面，还是设置面板？
• 用户可能是谁——根据内容和上下文判断。
• 主要用户流程是什么——用户执行的主要任务。
• 设计系统——使用了哪些令牌、模式和约定？是否一致地应用？

使用 Glob 查找 UI 文件，然后用 Read 阅读。全面审查需要了解整体情况——包括应用外壳（index.html、全局 CSS、布局文件）以及每个页面和组件。只有查看所有内容，才能发现跨页面问题，例如设计系统不一致或导航模式失效。

多页面项目： 阅读所有页面。必须评估每个页面，而不只是“主”页面。不同页面往往存在不同问题（例如，设置页面可能缺少表单验证，而首页的处理却很完善；404 页面可能破坏设计系统）。如果项目的 UI 文件超过 20 个，请询问要重点关注哪些流程，但仍要阅读共享布局组件，并从每个不同的部分至少抽查一些页面。

对于在线网站（URL）——使用 WebFetch 获取页面。如果用户提供单个 URL，就获取该页面。如果用户提到多个页面或整个网站，则获取关键页面（首页、主要功能页面、联系／表单页面——最多 5 个页面）。

从获取的 HTML 中提取并评估：

• 文档结构（<html lang>、<head> 中的 meta／OG 标签、<title>、viewport）
• 语义化地标（<main>、<nav>、<header>、<footer>、标题层级）
• 无障碍属性（替代文本、ARIA 标签、角色、表单标签）
• 链接和按钮模式（元素是否恰当、外部链接处理方式）
• 内联和外部样式表（对比度线索、响应式媒体查询、焦点样式）

请坦诚说明仅凭获取的 HTML 无法评估的内容：

• 依赖 JavaScript 的行为（加载状态、表单验证、动态内容）
• 计算后的 CSS（精确的对比度、悬停／焦点状态）
• 客户端路由和 SPA 导航
• 实际的视觉布局和渲染效果

在报告标题中说明这些限制，让用户了解评估范围。

步骤 2：评估

先阅读 ../../../references/heuristics.md——其中包含了每项原则下需要检查内容的详细指南，包括视觉设计检查。

然后逐项检查每一项原则。针对 15 项原则中的每一项，都要问自己：“这个界面是否在任何地方违反了这项原则？”不要因为某项原则似乎不太可能相关就跳过——要对照代码逐一检查。此次审查的价值来自系统性覆盖，而不仅仅是发现显而易见的问题。

对于每项原则，都要考虑以下层面：

组件层面——检查单个文件：

• HTML 结构和语义（地标、标题、列表、恰当的元素）
• CSS 样式（对比度、间距、视觉层次、交互状态、焦点指示器）
• JavaScript 行为（加载状态、错误处理、表单验证、反馈）
• 无障碍属性（ARIA 标签、角色、替代文本、焦点管理）
• 响应式行为（viewport 处理、触控目标、移动端模式） 隐藏和动态 UI — 这些内容很容易被忽略，但往往存在最严重的可用性问题，因为它们较少受到设计关注。主动搜索代码，找出初始页面加载时不可见的所有 UI，并逐一评估：
• 模态框和对话框 — 检查是否包含 role="dialog"、aria-modal、aria-labelledby、Escape 键处理程序、焦点陷阱（按 Tab 键应在模态框内循环切换焦点），以及关闭时恢复焦点。检查点击遮罩层是否可以关闭。检查模态框内的表单是否会提供提交反馈，以及标签是否正确关联。
• 下拉菜单、菜单和弹出框 — 检查是否包含 aria-haspopup、aria-expanded、键盘导航（方向键、按 Escape 关闭），以及点击外部区域关闭功能。
• 抽屉、侧边栏和画布外面板 — 与模态框一样，需要焦点陷阱和 Escape 键处理。检查移动端的响应式行为。
• 工具提示和 Toast — 检查显示时长、是否可关闭，以及屏幕阅读器播报（role="status"、aria-live）。
• 手风琴、标签页和可折叠区域 — 检查是否使用正确的 ARIA 角色（tablist、tab、tabpanel）和键盘操作模式（使用方向键在标签页之间切换）。
• 表单验证状态 — 检查错误消息是否与输入框关联（aria-describedby）、是否会播报给屏幕阅读器，以及焦点是否会移至第一个错误处。
• 空状态、加载状态和错误状态 — 检查这些状态是否存在且说明清晰。缺少空状态也属于问题。
• 破坏性操作的确认对话框 — 检查删除／移除／清除操作是否需要经过确认步骤。

视觉设计 — 许多可用性问题并不体现在代码属性中，而是体现在视觉呈现上。修复这些问题会带来明显且有意义的变化。视觉设计检查已整合到 ../../../references/heuristics.md 的各项相关原则中（尤其是 H8、H11、H12、H14）。重点领域：

• 排版层级 — 字号／字重是否有清晰的递进，引导视线？用户能否浏览标题，再深入查看详情？正文和标签的字号是否足够大？扁平的字体比例（所有内容大小相近）会迫使用户阅读所有内容，而无法快速浏览。
• 间距和邻近性 — 相关项是否紧密排列，并与不相关项分隔开（格式塔邻近原则）？各个区域之间是否留有足够的留白？布局拥挤会让人感到不堪重负；间距一律相同，则难以看出各区域的边界。
• 视觉权重和强调 — 主要操作（CTA）的视觉权重是否高于次要操作？最重要的内容（例如任务标题与元数据相比）是否通过字号、字重或颜色突出显示？当所有内容的视觉权重都相同，就没有任何内容能脱颖而出。
• 颜色用途 — 颜色是否用于传达含义（状态、优先级、分组），还是仅仅是装饰性的干扰？相互竞争的颜色是否过多？配色方案是否形成了清晰的层级（主要强调色、次要颜色、中性色）？
• 信息密度 — 布局是否过于密集（让用户感到不堪重负）或过于稀疏（用户需要过度滚动）？用户能否高效地浏览内容？
• 对齐和一致性 — 元素是否与统一的网格对齐？间距值是否一致，还是随机变化？错位会带来一种不易察觉的混乱感。
• 交互状态可见性 — 按钮、链接和卡片是否具有明显不同的悬停、激活、焦点和禁用状态？细微的状态变化（例如悬停时几乎无法察觉的颜色变化）会让界面显得反应迟钝。 系统级 — 跨文件进行比较（深入的设计价值正源于此）：
• 跨页面一致性 — 所有页面是否使用相同的颜色令牌、间距和字体排版？像 404 或错误页面这样的页面是否破坏了视觉语言？
• 交互模式一致性 — 类似元素在各处的行为是否一致？如果项目卡片在悬停时会浮起，不可点击的卡片是否错误地采用了相同模式？
• 设计系统的连贯性 — 是否存在本应使用令牌的硬编码颜色或尺寸？组件是否遵循相同的结构模式？
• 导航与方向指引 — 用户是否始终能知道自己身处何处、如何到达这里，以及如何返回？所有页面的导航是否一致？
• 元信息与 SEO — 检查 index.html 中是否包含恰当的元标签、OG 标签、页面标题、lang 属性和视口设置
• 视觉层级与提示符 — 用户能否区分可点击和不可点击的元素？能否区分内部链接和外部链接？能否区分主要操作和次要操作？

重要： 不要捏造问题——如果某项原则处理得当，请将其记为优点。但也不要自我设限。现实中的界面在大多数 15 项原则上几乎总是存在问题。如果你发现的问题少于 10 个，请重新检查你标记为“良好”的原则，深入查找——尤其关注视觉设计（字体层级、间距、视觉权重、颜色运用）、隐藏或动态 UI（模态框、下拉菜单、抽屉、工具提示）、跨页面模式、边缘情况（错误页面、空状态、加载状态）以及应用外壳（index.html、元标签）。请记住：优秀的审查会提出能带来可见改进的问题，而不仅仅是代码层面的属性变更。如果你的所有发现都只是 ARIA 标签和语义化 HTML，那你就忽略了视觉设计层面。修复视觉设计问题时，改动应当一目了然——用户对比前后版本时，应能立即看出差异。畏缩的视觉改动（将颜色的一个十六进制位调整一档、将字号调整 0.05rem）无法解决根本问题。

原则覆盖情况核验——撰写报告前请完成此步骤： 继续撰写报告前，请确认你已评估全部 15 项原则。在心中逐项核对以下清单，并确认已针对代码考虑每一项：

1. 系统状态的可见性——加载、反馈、激活状态
2. 系统与现实世界的匹配——语言、惯例、映射关系
3. 用户的控制权与自由度——撤销、退出、返回、取消
4. 一致性与标准——内部和外部一致性
5. 错误预防——验证、约束、确认
6. 识别而非回忆——空状态、标签、面包屑
7. 灵活性与效率——键盘快捷键、批量操作、偏好设置
8. 美观且精简的设计——字体排版、间距、视觉权重、颜色、密度
9. 错误恢复——错误消息、恢复指引
10. 帮助与文档——引导流程、工具提示、上下文帮助
11. 可供性与提示符——可点击提示、按钮层级、触控目标
12. 结构——分组、布局、视觉边界、移动端导航
13. 无障碍性——替代文本、对比度、键盘、语义、ARIA
14. 可感知性——状态可见性、视觉层级、易于浏览
15. 容错性——输入灵活性、数据保留、撤销

如果任何原则既没有发现问题，也没有记下优点，请返回重新评估——你很可能只是草草略过了。必须认真评估每一项原则，即使结论是“处理得当”。

第 3 步：报告

按以下结构呈现发现：

## UX Design Audit Report

**Scope:** [what was evaluated]
**Source:** [list ALL files reviewed (local) OR URLs fetched (live website)]
**Interface type:** [dashboard / form / e-commerce / etc.]
**Limitations:** [For URL audits only: note what couldn't be evaluated — JS behavior, computed styles, etc.]

### How to Read This Report
Findings are rated on a 0-4 severity scale (4 = users can't complete tasks,
1 = cosmetic only). Each finding references an established usability principle.
Start from the top — the most impactful issues are listed first.

### Summary

| Severity | Count |
|----------|-------|
| 4 - Catastrophe | X |
| 3 - Major | X |
| 2 - Minor | X |
| 1 - Cosmetic | X |
| **Total findings** | **X** |

### Quick Wins
The highest-impact issues that are also straightforward to fix:
1. [Finding title] (Severity X) — [one-line fix summary]
2. [Finding title] (Severity X) — [one-line fix summary]
3. [Finding title] (Severity X) — [one-line fix summary]

### Findings

#### [Severity 4] Finding title
- **Principle:** [which usability principle(s) violated]
- **Location:** `file.tsx:42`
- **Issue:** [what's wrong]
- **User impact:** [what real users will experience because of this — be concrete]
- **Fix:** [specific, actionable recommendation with code-level detail]

[...repeat for all findings, grouped by severity descending...]

### Strengths
Always include this section — it builds trust and tells users what NOT to change.
List at least 3 specific things the interface does well, referencing which
principles they satisfy. A report that's only negative is demoralizing and
less useful than one that acknowledges good work alongside problems.

步骤 4：讨论（仅讨论模式）

呈现报告后：

• 默认情况下会修复所有发现的问题——请告知用户，并询问他们是否想跳过或降低某些问题的优先级
• 逐一说明每个问题为何重要，并将其与真实用户行为联系起来
• 随时准备解释权衡取舍（例如，添加确认对话框有助于防止错误，但会增加操作阻力）
• 如果用户想排除特定问题，请尊重他们的决定——他们比你更了解自己的用户和限制

步骤 5：实施

阅读 ../../../references/patterns.md，了解具体代码示例，包括设计系统和视觉统一性模式。

实施分为三个阶段。不要直接着手修复个别问题——必须先打好设计基础。目标不仅是修复个别问题，还要让 UI 显得协调统一、精致完善。

阶段 1：建立设计基础

修复个别问题之前，先提取并整合隐含的设计系统。检查现有 CSS，找出正在使用的值、彼此不一致之处，以及需要建立的设计令牌。

定义 CSS 自定义属性，构建协调统一的系统：

• 间距比例——采用 5–6 个按一致规律递增的值（例如，4/8/16/24/40/64px）。替换所有随意设置的 margin/padding 值。
• 字体比例——设置 4–5 个层级，并明确区分字号和字重。每个文本元素都应恰好对应一个层级。
• 调色板——包含 1 种主强调色、1–2 种语义色（成功/错误）和一套中性色阶（文本、次要文本、弱化文本、边框、背景）。移除随意设置的十六进制值。
• 阴影——设置 2–3 个层级（细微、中等、突出）。统一使用一种阴影样式。
• 边框圆角——统一使用 1–2 个值。不要在一张卡片上用 4px，在另一张上用 12px，又在第三张上用 8px。
• 过渡效果——统一使用一种持续时间和缓动方式（例如，150ms ease）。所有交互元素都应使用它。

统一图标用法——如果存在多种图标来源（Font Awesome 与 Lucide 混用、emoji 与 SVG 混用、Unicode 符号与图标字体混用），请选择一种统一的来源并替换其他来源。图标风格混杂是 UI 未经打磨最显眼的表现之一。

确定组件体系——有哪些可复用模式（卡片、按钮、徽章、分区容器）？每种模式都应采用一种统一的样式，并在各处保持一致。

阶段 2：应用修复

通过设计系统应用各项修复，不要随意添加值。

代码层面的修复（ARIA 属性、语义化 HTML、事件处理程序、元标签）：

• 只做解决每项问题所需的最小改动
• 保留现有代码风格和模式

视觉设计修复（排版、间距、颜色、布局、交互状态）：

• 使用阶段 1 中定义的设计令牌，不要引入新的硬编码值
• 确保效果清晰可见。如果字体比例扁平，就建立明确的层级。如果间距都一样，就拉开内容内部间距与分区间距的差异。如果按钮看起来都一样，就让主要操作在视觉上更加突出。
• 在改善层级和清晰度的同时，保留现有的视觉识别特征（品牌色、整体美感）

流程和交互修复（加载状态、过渡效果、表单推进）：

• 使用设计令牌中定义的统一过渡时间，应用于所有交互元素
• 状态变化应在视觉上连贯衔接——使用过渡效果，不要让元素瞬间跳变
• 加载到成功的流程应顺畅自然（禁用按钮 → 加载动画 → 成功消息）

阶段 3：设计一致性检查

完成所有单项修复后，整体审视界面。此阶段会将各处独立的修复整合为精致的成果。按照以下清单检查并修复所有不一致之处：

• 间距节奏 — 所有卡片的内边距是否一致？各区块的间距是否一致？表单字段之间的间距是否一致？所有数值是否都来自设计令牌的刻度？
• 字体排版 — 所有页面的字体层级是否一致？标题、正文和说明文字的字号是否统一？是否存在不属于任何层级的孤立字号？
• 色彩规范 — 是否谨慎使用强调色来突出重点？是否有明确的中性色基底？是否存在调色板之外的随意十六进制颜色值？
• 图标一致性 — 是否始终使用同一个图标库？同类场景下的图标尺寸是否一致？视觉权重是否一致？是否混用了填充和描边样式？
• 组件模式 — 所有卡片的样式是否一致（内边距、圆角、阴影、边框相同）？处于同一层级的所有按钮看起来是否相同？所有区块容器的样式是否一致？
• 交互状态 — 所有交互元素的悬停、焦点、激活和禁用状态是否一致？是否有元素缺少其他元素具备的状态？
• 过渡效果 — 所有动画属性的持续时间和缓动效果是否一致？是否存在突兀的快慢不一？
• 对齐 — 元素是否与统一网格对齐？各区块的内容区域是否对齐？不同页面之间是否存在细微的错位？
• 语义与视觉同步 — 每个语义属性都必须有对应的可见效果。aria-current="page" 需要有高亮的导航样式。aria-expanded 需要有可视化的展开／折叠指示器。aria-checked 需要有切换状态。表格中的 colspan 分组标题需要有区别于其他单元格的样式（背景、左对齐、视觉权重），让它们看起来像分类标签，而不是错位的数据行。如果添加了 ARIA 属性，却没有对应的 CSS 规则，那工作就只完成了一半。

界面类型风格指南

设计系统应符合界面的用途。根据界面类型调整视觉设计：

类型	特征	关键做法
作品集	简洁、宽敞，以作品为中心	留出充足的留白，项目卡片保持一致，悬停过渡效果流畅，减少界面装饰，让图片／作品充分展现，谨慎使用色彩
仪表盘	信息密集、便于浏览，以数据为重点	明确的指标层级（大号数字、小号标签），细腻的分隔线，紧凑的卡片，标签与数值之间有鲜明对比
营销页面	大胆、聚焦，以转化为导向	每个区块传达一个信息，突出主要行动号召，区块之间留出充足间距，展示信任信号，页面视觉流向清晰
表单／应用	引导清晰、结构明确、令人安心	清晰的字段分组，行内验证，进度指示器，平和的配色，字段之间留出充足间距
电商	便于浏览、值得信赖、信息易读	商品卡片保持一致，价格层级清晰，突出加入购物车按钮，展示评价信息，提供筛选／排序功能

反模式 — 不要这样做

以下是实现中最常见的问题。请主动对照此列表检查你的工作：

• 流行配色千篇一律 — 不要默认使用每款 AI 工具都会采用的同一套靛蓝色／紫色／蓝色调。沿用现有的品牌色。如果没有，就选择有个性的配色，而不是随手套用配色生成器给出的第一套方案。
• 所有内容都做成卡片 — 并非每组内容都需要带阴影和圆角的卡片。有时，简单的分隔线、背景色变化，或者留白就能更好地划分内容。卡片要用得其所——仅当内容确实代表一个可独立浏览的对象时才使用。
• 多个 CTA 相互竞争 — 每个屏幕区域只设一个主要操作。如果一个版块里有三个按钮，而且看起来都一样，用户就不知道该做什么。可采用一个实心按钮、一个描边按钮和一个纯文本按钮，也可以移除不重要的按钮。
• 所有元素的视觉权重都一样 — 如果每个元素的尺寸、字重和色彩强度都相同，就没有任何元素能引导视线。一些内容必须醒目（主要指标、主标题、主要 CTA），大多数内容则应低调（元数据、次要导航、说明文字）。要营造对比，而不是一味统一。
• 各版块的设计不一致 — 如果首屏采用一种视觉风格，而页脚采用另一种，页面就像是用不同模板拼凑而成。设计令牌的存在就是为了避免这种情况——请在所有地方使用，不要例外。
• 把内边距当作留白 — 不要只给所有元素都加上宽裕的内边距，然后称之为“呼吸感”。留白应该是有意设计的：组内紧凑（标签 + 输入框），组间宽松（版块与版块之间），并在不对称布局能营造视觉趣味时采用不对称布局。到处都使用相同的内边距，恰恰背离了设计的初衷。
• 按系统结构而非用户任务组织内容 — 不要按代码模块（“设置”“个人资料”“偏好设置”）来组织。应围绕用户想完成的操作来组织。表单应按照用户的思考顺序展开，而不是按照数据库存储数据的顺序排列。
• 文字对比度过低 — 文字的对比度不得低于 4.5:1。如果你在白色背景上使用 #999 或 #aaa 显示用户需要阅读的内容，就不符合 WCAG 标准，也很难阅读。次要文字至少使用 #666，正文使用 #333。
• 内容过多 — 如果一个版块里有超过 5-7 个明显的视觉元素争相吸引注意力，就显得杂乱。移除与任务无关的装饰元素。精简，再精简。即使信息丰富，优秀的界面也应给人平静的感觉。

所有修复都应：

• 测试更改是否会破坏现有功能
• 将相关修复归并为逻辑清晰的变更集

第 6 步：实施后审查

实施完成后，以全新的视角重新阅读修改过的文件。这不是对 15 条原则进行全面复审，而是有针对性地检查修复时常引入的问题，或首轮遗漏的问题。此步骤通常还能发现 3–8 个问题。

检查修复引入的问题：

• 语义与视觉同步 — 对于你添加的每个 ARIA 属性（aria-current、aria-expanded、aria-checked、role），是否有相应的 CSS 规则让视力正常的用户也能看出状态？如果设置了 aria-current="page"，却没有高亮导航样式，那就只完成了一半的修复。
• 选择器优先级冲突 — 新的 CSS 规则是否确实生效，还是被已有的类选择器覆盖了？检查通用属性选择器（如 [aria-current="page"]）是否也能匹配实际使用的特定类（如 .nav-link[aria-current="page"]）。
• 设计令牌泄漏 — 第 2 阶段的修复是否引入了本应使用第 1 阶段令牌的硬编码值？搜索未通过自定义属性的原始十六进制颜色、像素值或字号字面值。
• 视觉平衡变化 — 调整某个元素的视觉权重（例如加粗标题）后，可能会让相邻元素显得不够突出。检查每处修复周围的区域，看看是否显露出新的失衡。

检查首轮遗漏的问题：

• 复杂组件模式 — 带分组行的表格、多级导航、对比矩阵、嵌套手风琴组件。这些组件的对齐和视觉层次问题，往往只有在所有数据都设置样式后才会显现。
• 状态组合 — 激活 + 悬停、选中 + 禁用、展开 + 聚焦。首轮通常只处理单独状态；请确认组合状态不会造成视觉异常。
• 内容边缘情况 — 换行的长文本、空单元格、仅含一项的列表、达到最大长度的值。检查界面中会对布局造成压力的内容。

修复发现的所有问题，然后简要向用户报告新增的修改。如果本次审查发现超过 3 个严重问题（严重程度为 2+），请告知用户可以考虑再进行一轮审查，但不要自动开始，因为这会耗费大量资源。

---

沟通

友好开场，然后开始工作

当此技能首次触发时，以友好且聚焦目标的方式问候用户。告诉他们你将如何帮助他们，而不是你正在加载哪些内部工具或参考资料。用户关心的是结果，而不是你的流程。

良好的开场：“我会仔细检查你的前端代码，找出可能影响用户使用的问题，并帮你修复。”

不好的开场：“我会先查找项目中的前端代码，并加载评估参考资料。”

完成初次问候后，立即开始工作——阅读代码、进行评估并展示发现。不要逐步描述每个步骤（“现在我正在阅读文件 X……”“现在我正在根据原则 7 进行评估……”）。直接开展工作并呈现结果即可。在实际评估和报告中，可以并且应该使用技术语言，以确保表述准确。

注重教育性

解释发现的问题时，简要联系其背后的原则。不必长篇大论，只需提供足够的背景，让读者理解为什么这很重要。

每项发现都必须包含具体的用户影响说明：用户会因这个问题而遇到什么实际情况。请从后果出发思考，例如困惑、数据丢失、反复点击、任务中途放弃、残障用户被排除在外。可以采用“用户会因为 Y 而 X”的句式。这能让评估具有教育意义，而不只是核对清单。

良好示例：“此表单提交时没有加载指示器，因此用户不知道操作是否成功。他们可能会再次点击，导致重复提交。这违背了系统状态可见性原则——用户应始终了解系统正在执行什么操作。”

不良示例：“Nielsen 的第一条启发式原则 H1：系统状态可见性，正如其 1994 年论文《Usability Inspection Methods》中所定义的……”

具体明确

每项发现都必须指出：

• 具体文件和行号（本地项目）或具体元素／章节（URL 审查）
• 违反的具体原则
• 为什么这对用户很重要（说明具体影响，而非抽象描述）
• 具体的修复方法（本地项目需提供实际代码更改；URL 审查需提供具体建议）

实事求是

• 不要为了显得全面而夸大严重性
• 不要捏造代码中不存在的问题
• 对实现良好的部分予以肯定
• 说明存在争议或取决于具体情境的发现

---

不适用此技能的情况

• 从头开始构建新界面 → 使用 interface-design 或 frontend-design
• 性能优化 → 此技能关注可用性，而非速度
• 安全审计 → 完全不同的领域

---

命令

• /frontend-design-audit — 进行完整评估并讨论（默认工作流）
• /frontend-design-audit:evaluate — 运行评估并仅生成报告（不实施更改）
• /frontend-design-audit:improve — 直接进入实施阶段（已有评估结果时使用）
• /frontend-design-audit:quick — 自动确认：评估并实施，不进行讨论

参考资料

逐步加载参考文件，以提高令牌使用效率：

• ../../../references/heuristics.md — **评估期间（步骤 1–3）阅读。**包含完整定义、代码中的检查要点（含带参考表格的视觉设计检查），以及 15 项原则各自的严重性指南。
• ../../../references/patterns.md — **仅在实施期间（步骤 5）阅读。**提供常见无障碍、交互和视觉设计修复的具体代码示例。仅评估的任务无需读取此文件。