audit

audit 技能概览

audit 技能能做什么

audit 技能用于对页面、功能或组件执行结构化的技术 UX Audit。它会从 accessibility、performance、theming、responsive behavior 以及 front-end anti-patterns 等多个维度检查实现质量，并输出一份带评分的报告：问题会按 P0 到 P3 标注严重级别，同时附带后续行动计划。

谁适合使用 audit

这个 audit 技能特别适合前端团队、设计工程师、要复盘已上线 UI 的产品设计师，以及那些需要可重复、可落地的技术评审，而不是一句宽泛“帮我点评一下这个 UI”的 AI 用户。尤其在做 UX Audit 时，如果目标是找出实现层面的具体缺陷与风险，audit 会非常有用。

最适合解决的工作任务

当你需要回答下面这类问题时，就应该使用 audit：

• “这个页面在技术实现上到底哪里有问题？”
• “哪些问题严重到现在就该优先处理？”
• “这个组件在实际使用中是否真的 accessible、responsive？”
• “在开始修之前，哪些实现 anti-patterns 需要先被识别出来？”

它不是一个 redesign 工具，而是一个诊断型技能：负责把问题记录清楚，方便后续由其他命令或人工去修复。

这个 audit 技能有什么不同

audit 最核心的差异在于“结构化”。它不是给你一串没有排序的观察意见，而是专门设计成可以：

• 一次性检查多个质量维度
• 以一致的方式为每个维度打分
• 将技术缺陷和主观设计偏好区分开
• 输出按优先级排序的发现，而不只是泛泛评论

安装前必须知道的限制

仓库里明确写了一个依赖关系：audit 应与 /frontend-design 配合使用；如果当前还没有设计上下文，就需要先运行 /teach-impeccable。这一点非常重要，因为该 audit 依赖前置的上下文收集流程，而不是靠一张截图或一段孤立代码去猜产品意图。

如何使用 audit 技能

安装上下文与调用方式

仓库并没有在 SKILL.md 中提供专门的 audit install 命令，所以具体安装方式取决于你使用的 skill runner。在启用了 skills 的环境中，你通常直接按名称调用 audit，并传入一个目标区域，例如 page、feature 或 component。仓库声明的参数提示是：

[area (feature, page, component...)]

实际调用时可以像这样：

• audit checkout page
• audit pricing table component
• audit onboarding flow

先执行必需的前置步骤

在使用这个 audit 技能前，请先完成仓库要求的准备流程：

1. 调用 /frontend-design
2. 按它的上下文收集协议执行
3. 如果还没有 design context，先运行 /teach-impeccable

这不是仓库里可有可无的说明。如果跳过这一步，audit 很可能会误判产品意图、错误归类 anti-pattern，或因为上下文不完整而给出价值很低的结论。

audit 技能需要哪些输入

如果你提供的信息不只是一个模糊目标名，audit 的效果会明显更好。高质量输入通常包括：

• 需要检查的确切界面范围
• 链接、截图或代码路径
• 预期的用户流程
• 目标设备或断点
• 已知问题区域
• 约束条件，例如 design system 规则或 performance budgets

一个较弱的输入：

• “Audit my app”

一个更强的输入：

• “Audit the mobile checkout page in the signed-in flow. Focus on accessibility, responsive issues, and performance regressions affecting form completion. Primary files are app/checkout/page.tsx and components/PaymentForm.tsx.”

如何把模糊需求变成高质量 audit 提示词

想提高 audit usage 的效果，最好在一次请求里把范围、证据和输出要求都说清楚。一个高质量提示词通常包含：

• target：page、feature 或 component
• context：谁在使用、在哪些设备上使用
• evidence：URL、截图或代码文件
• focus：你最关心的评估维度
• output：明确要求输出 scores、severity 和 action plan

示例：
“Run the audit skill on the account settings page. Review accessibility, keyboard navigation, semantic structure, responsive behavior, and theming consistency. Use the attached screenshots and inspect SettingsPanel.tsx. Return a scored report by dimension, list issues with P0-P3 severity, and end with the top fixes to schedule first.”

audit 技能在实践中会评估什么

根据仓库内容，这个 audit 会覆盖五个技术维度：

• accessibility
• performance
• theming
• responsive design
• front-end anti-patterns

因此它很适合技术导向的 UX Audit 场景：问题既横跨代码质量，也影响用户体验，同时又需要保持可验证、可落地。

运行 audit 后应该期待什么输出

一次有用的 audit 执行，通常会输出：

• 按维度拆分的评分，通常为 0-4
• 与可观察实现问题直接对应的具体发现
• P0 到 P3 的严重级别
• 可执行的后续行动计划

这种结构的价值在于，它能帮助团队判断“先修什么”，而不是把所有问题都当成同样紧急。

初次使用 audit 的最佳工作流

一个阻力较低的使用流程是：

1. 先通过 /frontend-design 准备设计与产品上下文
2. 定义一个范围足够窄的 audit 目标
3. 提供代码路径或截图
4. 运行 audit
5. 审阅评分报告
6. 将最高优先级的 P0 和 P1 问题转成 tickets
7. 修复后重新运行 audit

建议先从一个页面或一个组件开始，而不是一上来就审整个产品。只有在范围足够聚焦时，这个技能才更容易给出细致、站得住脚的结论。

采用前建议的仓库阅读路径

如果你想在正式依赖这个技能前先判断是否适合，建议按这个顺序阅读：

1. SKILL.md：了解调用规则和必需准备项
2. “MANDATORY PREPARATION” 章节：确认依赖关系
3. “Diagnostic Scan” 章节：查看评估类别
4. 各维度的评分标准与 severity 逻辑

由于这个技能是以单个 SKILL.md 形式交付的，评估是否采用时，关键不在于有没有隐藏工具链，而在于你是否接受它的流程设计和评分模型。

什么时候 audit 比通用提示词更合适

通用提示词也许能列出一些明显的 UI 问题，但在以下场景中，这个 audit 技能更强：

• 你需要跨多次评审保持一致的评分标准
• 你要的是技术评估，而不是风格点评
• 你需要基于严重级别来排优先级
• 你要对多个界面做可重复的检查

如果团队需要在多个页面之间做可比较的 audit，光是这种结构化输出就已经是很实用的优势。

常见配置错误

最常见的误用，是把 audit 当作自由发挥的设计点评工具。仓库说明得很明确：它是代码层面的 audit，不是泛化的 design review。若你要求它评价品牌感、版式审美或视觉方向，却又不给实现证据，那要么是工具选错了，要么是工作流不完整。

audit 技能 FAQ

这个 audit 技能只是做 accessibility 吗？

不是。accessibility 只是其中一个重要维度，这个技能还会检查 performance、theming、responsive design 和 anti-patterns。如果你要的是更广义的技术 UX Audit，而不是单纯的 accessibility review，那么 audit 更合适。

audit 适合初学者吗？

适合，前提是你能明确指出要评审的是哪个界面。它的评分和 severity 模型可以帮助初学者把“总觉得哪里不对劲”转化为更可执行的问题清单。新手最容易踩的坑，是跳过前置的上下文步骤。

使用 audit 一定需要代码访问权限吗？

不一定，但有代码访问权限会显著提高输出质量。你可以先从截图或线上页面开始，不过这个技能本质上仍然是面向实现层的。如果你希望在 semantics、ARIA、结构或 anti-patterns 上得到更可靠的发现，提供代码路径会非常有帮助。

什么情况下不应该使用 audit？

当你需要以下内容时，不应使用 audit：

• 创意型 redesign
• copywriting 反馈
• 产品策略建议
• 纯视觉层面的品牌评论
• 在同一步里直接修代码

这个技能的定位是诊断与优先级排序，不是直接产出解决方案实现。

audit 和直接让 AI “review this UI” 有什么区别？

普通提示词往往会产出质量参差不齐的反馈，既没有稳定的评分逻辑，也缺乏清晰的优先级。audit skill 更适合那些需要固定评审格式、更明确的 severity 分级，以及基于可测量检查项展开技术审查的场景。

我可以用 audit 审整个 app 吗？

可以，但实际落地通常从更小范围开始会更顺。建议先 audit 一个页面、一个 flow 或一个 component。范围过大的请求，如果边界不清、证据不够代表性，常常只会得到比较浅的结论。

如何改进 audit 技能的使用效果

缩小范围，拿到更好的 audit 结果

提升 audit 输出质量最简单的方法，就是缩小范围。“Audit the dashboard” 往往太宽泛；而 “Audit the table filtering experience on the dashboard at mobile width” 这种表述，则更有助于技能深入检查并正确排序优先级。

提供技能能够核实的证据

输入越扎实，输出越可信。好的证据包括：

• URL 或 route
• 关键断点下的截图
• 受影响的组件
• 相关代码文件
• 复现步骤
• 已知的 accessibility 或 performance 投诉

这个技能最擅长“核实”，而不是“猜测”。

明确要求你想要的报告格式

如果你需要的是可直接交付的产出，就把格式要求说清楚。比如：

• “Score each dimension 0-4”
• “Use P0-P3 severity”
• “Group findings by page section”
• “End with the top five fixes by user impact”

这样能让 audit 更贴合你的交付流程。

把诊断和修复分开

仓库明确把 audit 定义为文档化问题的步骤。不要在第一次运行时就同时要求它做诊断、重设计、实现方案和代码 patch。正确做法是：先拿到一份干净、结构明确的 audit 报告；然后再用后续技能或提示词去处理优先级最高的问题。

用有针对性的后续提问改进第一次输出

如果第一次得到的 audit guide 输出太泛，不要原样重跑同一个提示词。更有效的做法是补充：

• 缺失的上下文
• 更窄的范围
• 具体文件
• 目标设备尺寸
• 用户流程细节
• 你最关心的评估维度

相比单纯要求“讲得更详细”，第二次用更好的提示词通常效果更好。

留意常见失败模式

低质量 audit 结果通常来自以下问题：

• 缺少前置上下文
• 范围过大
• 没有截图或代码引用
• 想要主观设计反馈，而不是技术评审
• 在一次请求里混合了不相关的多个界面

这些情况都会让报告既不够可执行，也不够有说服力。

把 audit 作为持续性的 QA 检查点

对团队来说，这个 audit 技能最值得长期使用的方式，是把它当作可重复执行的检查点：

• 发布前
• 大型 UI 重构后
• design system 迁移后
• accessibility bug 持续积累时
• 出现 responsive regressions 时

在这种重复使用场景里，它的评分模型会比一次性的 review 更有价值。

第一轮之后，继续优化优先级判断

完成初次 audit 后，可以继续追问这类问题：

• “Which P0 and P1 issues block release?”
• “Which findings are fastest to fix for the most user benefit?”
• “Which issues likely stem from shared components?”
• “Which problems should be solved in the design system rather than locally?”

这样就能把 audit 从一份报告，推进成一张可执行路线图。

让 audit 配合正确的上游上下文一起工作

既然仓库要求先运行 /frontend-design，那就应该把 audit for UX Audit 视为更大评审流程中的一步：

1. 收集产品和设计上下文
2. 运行 audit
3. 对发现的问题排优先级
4. 将修复工作交给更偏实现的工作流
5. 重新运行 audit，确认是否真的改善

相比孤立使用 audit 技能，这套顺序能带来更好的结果。