audit

必须进行的准备工作

阅读 frontend-design，并遵循其中的上下文收集协议。重用现有上下文，只针对重要的信息缺口提问。

---

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

使用视觉验证来记录证据来源、不可用的工具和可重用的发现。除非用户要求或已纳入授权的工作流，否则不要保存报告。关于审计的问题只是征求建议，并不代表授权执行审计。

这是代码级审计，而非设计点评。检查实现中可衡量、可验证的内容。

审查灰度层级、操作优先级、克制处理的区块标题以及标签/值处理方式时，请参阅层级检查清单。 检查是否存在受通用趋势驱动的反模式时，请参阅AI 套路检测。 审查主要、次要、三级和破坏性操作时，请参阅操作层级。 检查颜色是在传达状态还是仅作装饰时，请参阅语义色彩。 检查边框、阴影、卡片、重叠和背景变化是否经过有意设计时，请参阅表面区分。 当截图、图标或媒体处理影响可用性或精致度时，请参阅图像处理。 将自动化检查（axe、WAVE、Pa11y）集成到审计工作流或 CI 流水线时，请参阅无障碍测试。 检查代码级无障碍、焦点状态、表单、动效、内容适应性、导航状态、安全区域、本地化和 hydration 安全性时，请参阅React 和 Tailwind 实现审查。

报告违反适用设计系统和任务要求的具体问题，例如文字难以辨认或主要操作之间相互竞争。说明观察到的影响，不要把风格偏好当作实现缺陷。

诊断扫描

针对 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
• 交互延迟：常见操作没有即时反馈、依赖空等，或错过明显的乐观更新／预取／渐进式加载机会
• 图像传输：资源尺寸过大、对首屏以下内容进行不必要的 eager loading，或对首屏可见且可能成为 LCP 的图像进行 lazy loading
• 包大小：不必要的导入、未使用的依赖项
• 渲染性能：经测量确认的高开销渲染或重复计算导致交互延迟
• Hydration 安全性：仅客户端生成的日期、非受控／受控输入不匹配、不必要的 suppressHydrationWarning
• 大型列表处理：重复列表未进行虚拟化，或列表规模导致渲染开销较高时缺少 containment

在建议优化前，先测量加载和交互表现。缺少 memoization 或 will-change 本身并不算缺陷。只有在性能分析确认存在瓶颈，且对比结果显示有所改善时，才添加其中任一项。参见 React memo 和 will-change 指南。

评分 0-4：0=延迟阻碍任务完成，1=经测量确认存在严重的加载或交互问题，2=可用但存在经测量确认的瓶颈，3=符合目标设备预算，仅有轻微问题，4=在所有已测试条件下均符合约定预算。如果未测量性能，请报告为未测试，并省略综合评分。

3. 主题

评估项目实际支持的主题。仅支持浅色主题的产品无需支持深色模式即可通过。根据现有系统和范围判断设计令牌的一致性；不要仅为提高此项评分而引入令牌架构。

检查项：

• 硬编码颜色：颜色未使用设计令牌
• 深色模式异常：缺少深色模式变体，或深色主题下对比度不佳
• 令牌不一致：使用了错误的令牌，或混用不同类型的令牌
• 主题切换问题：主题切换时数值未更新
• 缺少颜色阶梯：使用临时的单独色调，而非定义好的调色板
• 色调过多但缺少系统：到处都是略有差异的蓝色／灰色，却没有清晰的色阶

评分 0-4：0=主题缺陷妨碍任务完成，1=系统存在严重不一致，2=部分状态或令牌不一致，3=存在轻微偏差，4=在所有支持的主题和已测试状态下表现一致。

4. 响应式设计

检查项：

• 固定宽度：硬编码宽度导致窄视口下布局异常
• 视口高度问题：使用 h-screen 或 100vh 的页面区块在移动浏览器界面显示时跳动或裁切内容
• 粗指针目标：交互元素小于 44x44px
• 水平滚动：窄视口下内容溢出
• 文本缩放：文本尺寸增大时布局异常
• 缺少断点：没有针对窄／中等视口的变体

评分 0-4：0=仅适用于宽屏布局（窄视口下异常），1=存在严重问题（有一些断点，但大量场景异常），2=部分适配（不同视口下均可使用，但仍有明显瑕疵），3=良好（响应式表现良好，仅有轻微的目标尺寸或溢出问题），4=出色（布局流畅，适配所有视口，目标尺寸合理）

5. 反模式（关键）

使用 AI slop 检测 参考资料评估构图和品牌契合度。将视觉模式视为供审核的提示，而非自动判定为缺陷。保留已获批准的字体和颜色。报告具体问题，例如层级不清、内容难以阅读、不必要的装饰，或与设计简报不符。

还要执行以下实现层面的层级检查：

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

评分 0-4：0=构图妨碍主要任务，1=存在多个重大的层级或品牌契合度问题，2=存在一些明显的构图问题，3=还需要少量调整，4=层级清晰且品牌契合度一致。这是一项定性判断。请引用观察到的实例，而非统计字体、颜色或效果的数量。

生成报告

审计健康度评分

仅为有充分证据的已检查维度评分。其他维度标记为未测试或不适用。除非评估了全部五个维度，否则省略总分和评级。综合评分绝不能凌驾于重大问题之上，也不能证明已具备发布条件。

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

评级区间：18-20 优秀（仅需细微润色），14-17 良好（改进薄弱维度），10-13 尚可（需要大量工作），6-9 较差（需要全面整改），0-5 严重（存在根本性问题）

设计构成评估

说明观察到的层级关系和视觉系统是否支持任务。指出具体的可读性、交互或品牌契合度问题。不要推断设计者身份，也不要仅因设计采用了经批准的字体、颜色或常见布局就判定其不合格。

执行摘要

• 如果覆盖范围足够，列出审计健康度评分；否则列出已检查和未测试的维度
• 发现的问题总数（按严重性统计：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）
• 未经核实就报告误报
• 将明显的层级结构问题当作主观意见带过——如果用户无法判断哪些内容更重要，那就是实现问题

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