用途
audit 是一个前端技术质量审计技能，启动方式为 /audit。它对实现代码运行系统性的技术质量检查并生成一份完整报告。定位是代码级审计，而不是设计评审：只检查实现中可测量、可验证的内容，并且只记录问题、不负责修复，把修复交给其他命令处理。
前置要求
用户通过 /audit 启动该工作流。技能激活后，必须先加载 $frontend-design——其中包含设计原则、反模式以及 Context Gathering Protocol。必须先遵循该协议再继续；如果目前还没有任何设计上下文，则必须先加载 $setup。
参考清单
审计过程中需要对照以下参考内容：
- hierarchy checklist：检查灰度层级、行动优先级、章节标题克制程度、标签/数值处理。
- ai slop detection：检查通用、趋势驱动的反模式。
- action hierarchy：检查主要、次要、第三级和破坏性操作。
- semantic color：检查颜色是在传达状态还是仅作装饰。
- surface separation：检查边框、阴影、卡片、重叠和背景变化是否被有意使用。
- image treatment：检查截图、图标或媒体处理是否影响可用性或完成度。
- accessibility testing：把 axe、WAVE、Pa11y 等自动检查集成进审计工作流或 CI 流程。
当实现明显违反共享设计系统或明显的 Refactoring UI 原则时（例如层级薄弱、间距随意、彩色背景上使用灰色文字、每个按钮都被设成主按钮），应将其作为实现问题指出，而不是品味问题。
主要能力：五维度诊断扫描
1. 无障碍（A11y）
检查对比度低于 4.5:1（AAA 为 7:1）、缺少 ARIA、键盘导航（焦点指示缺失、tab 顺序不合理、键盘陷阱）、语义 HTML（标题层级、landmark、用 div 代替 button）、alt 文本、表单问题（无标签输入、错误提示差、缺少必填标识）。
评分 0-4：0=不可访问（未通过 WCAG A），1=重大缺口，2=部分达标，3=良好（大体满足 WCAG AA），4=优秀（完全满足 AA，接近 AAA）。
自动测试集成：在人工审查前对关键页面运行 axe-core、WAVE 或 Pa11y；把自动结果当作快速预警系统而非通过/失败判决；验证自动报告的对比度失败是否真实（抗锯齿或叠加层可能造成误报）；用自动工具捕捉缺失标签、错误 ARIA 和焦点问题；记录启用了哪些规则、哪些被有意禁用以及其理由。
2. 性能
检查布局抖动（循环中读写布局属性）、昂贵动画（动画 width、height、top、left 而非 transform/opacity）、交互延迟（常见操作无即时反馈、依赖空白等待、缺少乐观更新/预取/渐进加载）、缺失优化（图片无懒加载、资源未优化、缺 will-change）、包体积（多余导入、未使用依赖）、渲染性能（不必要的重渲染、缺少 memoization）。
评分 0-4：0=严重问题，1=主要问题，2=部分优化，3=良好，4=优秀（快速、精简、优化良好）。
3. 主题
检查硬编码颜色（未使用设计 token）、深色模式损坏、token 使用不一致、主题切换时数值不更新、缺少色阶（临时一次性色值、颜色过多且无系统）。
评分 0-4：0=无主题化，1=token 极少，2=部分（token 存在但使用不一致），3=良好，4=优秀（完整 token 系统，深色模式完美）。
4. 响应式设计
检查固定宽度在窄视口下断裂、触控目标小于 44x44px、窄视口内容横向溢出、文字放大时布局断裂、缺少断点变体。
评分 0-4：0=仅支持宽布局，1=主要问题，2=部分（跨视口可用但有粗糙边缘），3=良好，4=优秀（流式布局、适配所有视口、目标尺寸正确）。
5. 反模式（关键项）
对照 frontend-design 技能中所有 DON'T 准则和 ai slop detection 参考进行检查，包括 AI 配色、渐变文字、玻璃拟态、hero 指标、卡片网格、通用字体，以及灰字置于彩色背景、嵌套卡片、弹跳缓动、冗余文案等。
同时执行实现层面的层级检查，包括：层级检查（约 2 秒内能否识别主次第三级元素）、系统检查（间距、字体、颜色、圆角、高度是否来自系统）、行动检查（是否有一个明显主操作）、边框检查（边框是否在做本应由间距/对比度/背景变化承担的工作）、label:value 反模式测试、链接过度着色测试、彩色背景上灰字失败测试、分组歧义测试、字号过多测试、章节标题语义/视觉不匹配测试、数字右对齐测试、章节标题过响测试、行长/行高测试、行动层级扁平化测试、缩小截图可读性测试、放大图标粗糙度测试、表面分离测试、重叠冲突测试、暗黑模式（dark pattern）检查、护栏检查。
评分 0-4：0=AI 味画廊（5+ 个特征），1=重度 AI 审美（3-4 个），2=有一些（1-2 个明显），3=基本干净，4=无 AI 痕迹（有辨识度、有意图的设计）。
报告输出
报告结构包括：审计健康评分表（五维度得分与关键发现、总分 ??/20 及评级区间：18-20 优秀、14-17 良好、10-13 可接受、6-9 较差、0-5 严重）、反模式判定（通过/失败、具体特征、一句话层级判定）、执行摘要（评分、按 P0/P1/P2/P3 统计的问题数、前 3-5 个关键问题、建议的后续步骤）、按严重程度分组的详细发现、系统性模式问题、正面发现和推荐动作。
每个问题需记录：严重级别与名称、位置（组件、文件、行号）、类别、影响、所违反的 WCAG/标准（如适用）、修复建议、建议命令。P0 为阻塞任务完成、需立即修复；P1 为显著困难或违反 WCAG AA、发布前修复；P2 为存在绕过办法的烦恼、下一轮修复；P3 为无实际用户影响的打磨项。
推荐命令只能从以下集合中选择：/animate、/arrange、/critique、/extract、/polish、/optimize、/audit、/typeset、/bolder、/clarify、/delight、/adapt、/colorize、/quieter、/harden、/distill、/onboard、/normalize、/showcase，并按优先级排序，若推荐了任何修复则最后以 /polish 收尾。
呈现摘要后需告知用户：可以按你偏好的方式一次运行一个、全部一起运行或任意顺序运行；修复后重新运行 /audit 可看到评分提升。
限制与禁忌
不得只报告问题而不说明影响、不得给出泛泛建议、不得跳过正面发现、不得忘记排优先级、不得未经验证就报告误报、不得把明显的层级失败当作主观问题。要求彻底但可执行，避免过多 P3 问题造成噪音。自动化检查结果应作为预警而非最终判决，需验证误报。
适用场景
适用于前端项目在发布前进行代码级质量核查、把无障碍自动检测纳入 CI 流水线、或在迭代后重新审计以观察评分变化。