audit

强制准备工作

调用 /impeccable — 其中包含设计原则、反模式和上下文收集协议。继续之前，请遵循该协议 — 如果尚无设计上下文，必须先运行 /impeccable teach。

---

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

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

诊断扫描

针对以下 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）

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. 反模式（关键）

对照 impeccable 技能中的所有 DON'T 指南进行检查。留意 AI 生成内容的痕迹（AI 配色方案、渐变文本、玻璃拟态、主视觉指标、卡片网格、通用字体）以及常见设计反模式（彩色背景上的灰色文字、嵌套卡片、弹跳缓动、重复文案）。

评分 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、/quieter、/shape、/optimize、/adapt、/clarify、/layout、/distill、/delight、/audit、/harden、/polish、/bolder、/typeset、/critique、/colorize、/overdrive）

模式与系统性问题

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

• “15 个以上的组件中出现了硬编码颜色，应改用设计令牌”
• “移动端体验中的触控目标始终过小（<44px）”

优点发现

指出表现良好的方面 — 保持并推广良好实践。

建议的操作

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

1. [P?] /command-name — 简要说明（结合审计发现提供具体上下文）
2. [P?] /command-name — 简要说明（具体上下文）

规则：只推荐以下命令：/animate、/quieter、/shape、/optimize、/adapt、/clarify、/layout、/distill、/delight、/audit、/harden、/polish、/bolder、/typeset、/critique、/colorize、/overdrive。根据发现的问题选择最合适的命令。如果建议了任何修复，最后一步以 /polish 结束。

呈现摘要后，告诉用户：

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

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

重要：内容要全面，但必须可执行。过多 P3 问题会造成干扰。请聚焦真正重要的问题。

切勿：

• 报告问题却不解释影响（为什么这很重要？）
• 提供泛泛的建议（要具体且可执行）
• 忽略优点发现（肯定有效的做法）
• 忘记确定优先级（不能把所有问题都定为 P0）
• 未经核实就报告误报

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