audit

运行系统化的技术质量检查，并生成以下报告。不要修复此技能中的问题。

扫描前，请阅读现有设计系统（CSS / 令牌 / 主题和一个有代表性的组件），这样“正确”的评判依据就是项目自身的惯例，而非通用默认值。如果仓库包含设计背景信息（PRODUCT.md、DESIGN.md、.impeccable.md，或 .github/copilot-instructions.md 中的 ## Design Context 区块），也请阅读。

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

诊断扫描

从以下 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. 实现一致性（关键）

根据产品背景，检查重复使用的快捷方案、设计系统偏差、误导性内容和可互换的结构。将可衡量的源代码发现与视觉判断分开；仅凭配色或布局模式不能判定为缺陷。说明误报。

评分 0-4：0=系统性偏差，1=多处重大重复问题，2=已验证的多个问题，3=少数孤立问题，4=连贯且有意为之

生成报告

审核健康度评分

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

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

实现一致性结论

从这里开始。 实现是否体现了连贯且针对特定产品的系统？请引用已验证的证据。

执行摘要

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

按严重程度列出的详细发现

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

• P0 阻断：导致任务无法完成——立即修复
• P1 重大：造成明显困难或违反 WCAG AA——发布前修复
• P2 轻微：造成不便，但有替代方案——在下一轮修复
• P3 润色：修复后更好，但不会对用户造成实际影响——有时间再修复

针对每个问题，请记录：

• [P?] 问题名称
• 位置：组件、文件、行号
• 类别：无障碍 / 性能 / 主题 / 响应式 / 实现一致性
• 影响：对用户造成的影响
• WCAG/标准：违反的标准（如适用）
• 建议：如何修复
• 建议的命令：应使用哪个命令或技能进行修复

模式与系统性问题

找出表明存在系统性缺口而非个别疏漏的重复问题：

• “15 个以上组件中存在硬编码颜色，应使用设计令牌”
• “整个移动端体验中的触控目标都过小（<44px）”

正面发现

列出 1-3 项值得保留的实现实践，并提供文件/组件证据。没有具体的正面发现时，省略此部分。

建议的操作

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

1. [P?] /command-name — 简要说明（引用审核发现中的具体背景）
2. [P?] /command-name — 简要说明（具体背景）

规则：将发现映射到最合适的可用技能或命令。如果建议了修复，最后一项建议应为润色/清理步骤。

呈现摘要后，告知用户：

你可以让我按顺序逐个运行、一次全部运行，或按你喜欢的顺序运行。

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

除非用户要求提供完整待办清单，否则 P3 发现最多列出五项。

绝对不要：

• 报告问题却不解释其影响（这为什么重要？）
• 提供建议却没有文件/组件证据和修复途径
• 略过正面发现（肯定有效之处）
• 忘记按优先级排列（不能所有问题都是 P0）
• 未经验证就报告误报

相关内容

• accessibility — 当请求涉及 WCAG 合规性、ARIA、键盘操作或屏幕阅读器时，深入检查第 1 个维度。
• design-consistency-auditor — 当请求涉及令牌偏差、硬编码颜色或设计系统分歧时，深入检查第 3 个维度。