audit

必须完成的准备

用户使用 /audit 启动此工作流。此技能激活后，加载 $frontend-design — 其中包含设计原则、反模式和上下文收集协议。继续之前，遵循该协议 — 如果尚无设计上下文，必须先加载 $setup。

---

运行系统性的技术质量检查并生成全面报告。不要修复问题 — 记录问题，留待其他命令处理。

这是代码层面的审计，不是设计评析。检查实现中可衡量、可验证的内容。

审查灰度层级、操作优先级、节标题克制程度以及标签／值的呈现方式时，请参考层级检查清单。 检查是否存在泛化的趋势驱动型反模式时，请参考AI 味检测。 审查主要、次要、三级和破坏性操作时，请参考操作层级。 检查颜色是否在传达状态，而非仅作装饰时，请参考语义颜色。 检查边框、阴影、卡片、重叠和背景变化是否经过有意设计时，请参考表面区分。 当屏幕截图、图标或媒体处理影响可用性或精致度时，请参考图像处理。 将自动化检查（axe、WAVE、Pa11y）集成到审计工作流或 CI 管道时，请参考无障碍测试。

不过，如果实现明显违反了共享设计系统或显而易见的 Refactoring UI 原则 — 层级薄弱、间距随意、彩色背景上的灰色文字、所有按钮都采用主要按钮样式 — 请将其指出为实现问题，而非审美偏好。

诊断扫描

从 5 个维度运行全面检查。按照下列标准为每个维度打 0–4 分。

1. 无障碍（A11y）

检查项：

• 对比度问题：文字对比度低于 4.5:1（或 AAA 标准的 7:1）
• 缺少 ARIA：交互元素缺少适当的角色、标签或状态
• 键盘导航：缺少焦点指示器、Tab 顺序不合逻辑、键盘陷阱
• 语义化 HTML：标题层级不当、缺少地标元素、用 div 代替按钮
• 替代文本：缺少或不佳的图像描述
• 表单问题：输入框没有标签、错误提示不佳、缺少必填标识

评分 0–4：0=无法访问（未通过 WCAG A 级），1=存在重大缺陷（ARIA 标签很少、没有键盘导航），2=部分符合（做了一些无障碍改进，但仍有显著缺陷），3=良好（基本符合 WCAG AA 级，仅有轻微缺陷），4=优秀（完全符合 WCAG AA 级，接近 AAA 级）

自动化测试集成：

• 在人工审查前，使用 axe-core、WAVE 或 Pa11y 检查关键页面
• 将自动化结果视为快速预警系统，而非通过／失败判定
• 确认自动化检测到的对比度问题是否属实（有时抗锯齿或叠加层会导致误报）
• 使用自动化工具捕获容易在人工检查中遗漏的缺失标签、错误 ARIA 和焦点问题
• 记录启用了哪些自动化规则，以及出于何种理由有意禁用了哪些规则

2. 性能

检查以下方面：

• 布局抖动：在循环中读取／写入布局属性
• 开销较大的动画：对布局属性（width、height、top、left）做动画，而不是使用 transform／opacity
• 交互延迟：常见操作没有即时反馈、依赖空白等待，或错失明显的乐观更新／预取／渐进式加载机会
• 缺少优化：图片未启用延迟加载、资源未经优化、缺少 will-change
• 包体积：不必要的导入、未使用的依赖项
• 渲染性能：不必要的重新渲染、缺少记忆化

评分 0-4：0=问题严重（布局抖动、几乎所有内容都未优化），1=存在重大问题（未启用延迟加载、动画开销大），2=部分优化（有一些优化，但仍有不足），3=良好（大多已优化，仍有少量改进空间），4=优秀（快速、精简、优化完善）

3. 主题

检查以下方面：

• 硬编码颜色：颜色未使用设计令牌
• 暗色模式失效：缺少暗色模式变体，或暗色主题下对比度不佳
• 令牌不一致：使用了错误的令牌、混用不同类型的令牌
• 主题切换问题：主题切换时值不会更新
• 缺少色阶：使用临时的单独色调，而非定义好的调色板
• 色调过多且缺少体系：各处使用略有差异的蓝色／灰色，却没有明确的色阶

评分 0-4：0=没有主题系统（所有颜色都硬编码），1=仅使用少量令牌（大多硬编码），2=部分支持（有令牌，但使用不一致），3=良好（使用令牌，仅有少量硬编码值），4=优秀（完整的令牌系统，暗色模式运行完美）

4. 响应式设计

检查以下方面：

• 固定宽度：硬编码的宽度导致窄视口下布局错乱
• 触控目标：交互元素小于 44x44px
• 水平滚动：内容在窄视口下溢出
• 文本缩放：增大文本尺寸时布局错乱
• 缺少断点：未针对窄／中等视口提供布局变体

评分 0-4：0=仅适用于宽屏布局（窄视口下布局错乱），1=存在重大问题（有一些断点，但许多场景仍有问题），2=部分适配（适用于不同视口，但仍有一些问题），3=良好（响应式设计完善，仅有少量触控目标或溢出问题），4=优秀（布局流畅，适配所有视口，目标尺寸合理）

5. 反模式（关键）

对照 frontend-design 技能中的所有 不要 指南，以及 ai slop detection 参考文档进行检查。查找 AI 味设计的迹象（AI 配色、渐变文字、玻璃拟态、主视觉数据指标、卡片网格、通用字体）和常见设计反模式（彩色背景上的灰色文字、嵌套卡片、弹跳缓动、冗余文案）。

另外，运行以下实现层面的层级检查：

• 层级检查：用户能否在约 2 秒内识别主要、次要和三级元素？
• 系统检查：间距、字体、颜色、圆角和层级效果看起来是否遵循设计系统，而非使用随意设定的值？
• 操作检查：是否有一个明确的主要操作，次要和三级操作则更低调？
• 边框检查：是否有些边框本该由间距、对比度或背景变化来承担作用？
• 标签：值反模式测试：即使值或上下文已经能够说明问题，数据是否仍被强行套进僵化的标签／值格式？
• 不必要的彩色链接强调测试：链接的颜色是否过于醒目，以至于与优先级更高的操作或内容争抢注意力？
• 彩色背景上的灰色文字失败测试：彩色表面上的次要文本是否因使用通用灰色而显得褪色？
• 分组不明确测试：组与组之间的区分是否不如组内项目之间清晰？
• 字体大小过多测试：排版是否出现了一堆相近的字号，却没有明确的字号体系？
• 章节标题语义／视觉不匹配测试：标题是否仅仅因为语义层级听起来重要，就被设计得过于醒目？
• 数字右对齐测试：对比时若右对齐更有利，数字列是否仍然左对齐？
• 章节标题过于醒目测试：章节标题是否抢走了其所标注内容的注意力？
• 行长／行高测试：段落是否相对于行高过宽，或行间距过紧，影响舒适阅读？
• 操作层级扁平化测试：是否有多个操作被设计得同样紧急，尽管实际只应有一个操作优先？
• 缩小截图可读性测试：截图是否太小，无法传达有用的细节或结构？
• 放大图标显得笨重测试：微小图标是否被放大到远超其预期尺寸？
• 表面区分测试：边框、阴影、卡片和背景变化是否被冗余叠加，而非有针对性地选择使用？
• 重叠冲突测试：重叠的图片／卡片是否彼此冲突，缺乏清晰分隔或可读的层次？
• 暗黑模式检查：是否存在误导性标签、预先选择的剥削性选项、受阻碍的取消／同意流程、虚假紧迫感，或迫使用户做出错误选择的层级设计？
• 防护措施检查：批量操作／破坏性操作／管理操作／强大功能是否缺少确认、撤销、权限边界或其他适度的防护措施？

评分 0-4：0=AI 味十足的设计图库（5 个以上迹象），1=浓重的 AI 风格（3-4 个迹象），2=有一些明显迹象（1-2 个），3=整体干净（只有细微问题），4=没有 AI 痕迹（设计鲜明且经过深思熟虑）

生成报告

审核健康度评分

#	维度	评分	主要发现
1	无障碍	?	[最关键的无障碍问题，或无]
2	性能	?
3	响应式设计	?
4	主题	?
5	反模式	?
总计		??/20	[评级区间]

评级区间：18-20 优秀（只需稍作润色），14-17 良好（改进较弱的维度），10-13 尚可（需要大量改进），6-9 较差（需要大幅改造），0-5 危急（存在根本性问题）

反模式评估

从这里开始。 通过／不通过：这看起来像是 AI 生成的吗？列出具体迹象。请直言不讳。

在本节中加入一行层级评估：明确说明界面层级清晰，或指出观察到的主要歧义。

执行摘要

• 审计健康评分：??/20 ([评分区间])
• 发现的问题总数（按严重程度统计：P0/P1/P2/P3）
• 3–5 个最关键的问题
• 建议的后续步骤

按严重程度分类的详细发现

为每个问题标注 P0-P3 严重程度：

• P0 阻断：导致任务无法完成 — 立即修复
• P1 重大：造成显著困难或违反 WCAG AA — 发布前修复
• P2 轻微：造成不便，但有变通方法 — 下次迭代修复
• P3 润色：值得修复，但不会对用户造成实际影响 — 时间允许时修复

对于每个问题，请记录：

• [P?] 问题名称
• 位置：组件、文件、行号
• 类别：无障碍 / 性能 / 主题 / 响应式 / 反模式
• 影响：对用户的影响
• WCAG/标准：违反的标准（如适用）
• 建议：如何修复
• 建议使用的命令：应使用哪个命令（优先考虑：/animate、/arrange、/critique、/extract、/polish、/optimize、/audit、/typeset、/bolder、/clarify、/delight、/adapt、/colorize、/quieter、/harden、/distill、/onboard、/normalize、/showcase）

模式与系统性问题

找出表明存在系统性缺陷而非偶发错误的重复问题：

• “15 个以上的组件中出现硬编码颜色，应使用设计令牌”
• “窄屏布局流程中的交互目标始终过小（<44px）”
• “间距值似乎随意设置；组和区块没有采用可识别的节奏”
• “多个操作都被设计为主要操作，削弱了决策层次”
• “区块标题始终比其引出的内容更醒目”
• “文本密集型屏幕中的段落宽度与行高不匹配”

正面发现

指出运行良好的方面 — 值得保持和推广的良好实践。

建议的操作

按优先级列出建议的命令（先列 P0，再列 P1，然后列 P2）：

1. [P?] /command-name — 简要描述（结合审计发现中的具体情况）
2. [P?] /command-name — 简要描述（具体情况）

规则：仅推荐以下命令：/animate、/arrange、/critique、/extract、/polish、/optimize、/audit、/typeset、/bolder、/clarify、/delight、/adapt、/colorize、/quieter、/harden、/distill、/onboard、/normalize、/showcase。将发现的问题对应到最合适的命令。如果建议了任何修复，最后一步必须是 /polish。

呈现摘要后，告知用户：

你可以让我逐个运行、一次性运行，或按你喜欢的任意顺序运行这些命令。

修复后重新运行 /audit，查看评分提升。

重要：全面但务实。P3 问题过多会造成干扰。聚焦真正重要的问题。

切勿：

• 报告问题却不说明影响（这为什么重要？）
• 给出笼统的建议（应具体且可执行）
• 忽略正面发现（肯定做得好的方面）
• 忘记确定优先级（并非所有问题都是 P0）
• 未经核实就报告误报
• 将明显的层级失效当作主观琐事 — 如果用户无法判断什么最重要，那就是实现问题

请记住：你是一名技术质量审计员。系统地记录问题，严格确定优先级，引用具体代码位置，并提供清晰的改进路径。