Web项目审计技能：一次性完成无障碍、体验与代码质量审计，并输出可直接执行的优先修复清单
- 它是什么：一个面向入门 Web 项目的审计技能，围绕无障碍访问（Accessibility）、代码质量与用户体验三条线做系统排查，最终产出「问题发现 + 修复计划 + 变更记录 + 可视化报告」四份工件。
- 它怎么用：把项目代码放进
src/或inputs/src/，把待办清单放进inputs/TODO.md，触发词为accessibility audit、web audit、qa pass，技能会按 5 步工作流程输出报告。 - 它的差异点：不止「挑毛病」，还会按「投入产出比」给修复排优先级，并提供可验证的修复说明，工程和产品都能看懂。
- 它适合谁：独立开发者、学生团队、刚接手的开源项目维护者，以及需要在交付前做一次质量兜底的研发小组。
- 它解决什么：把「上线前心里没底」变成「有一份可执行、可复核的审计结论」。
该技能叫什么？如何下载安装 AI 技能提升开发效率？
基础信息
| 项目 | 内容 |
|---|---|
| 技能中文名 | Web项目审计技能 |
| 技能英文名 | web-starter-audit |
| 技能ID | 13832 |
| 版本 | 0.1.0 |
| 作者 | tandem |
| 兼容环境 | tandem（以官方说明为准） |
| 标签 | web、audit、quality |
| 前置依赖 | HTML、CSS、JavaScript |
| 触发词 | accessibility audit / web audit / qa pass |
它到底解决什么问题
入门级 Web 项目最常见的困境不是「写不出来」，而是「写完了不知道哪里有问题」：按钮没有可访问名称、弹窗无法用键盘关闭、对比度不达标、控制台反复报错、console.log 与死代码残留、默认配置不安全。这些问题单看都不致命，凑在一起就会在演示、验收或上线后集中爆发。
这个技能的定位就是「交付前的质量兜底」：它按固定的工作流程扫描项目结构，先识别用户关键流程，再从无障碍访问与代码质量两个方向逐项审计，最后按「努力 × 影响」给出优先修复方案，并生成四份可交付的审计工件。
「一键安装」提升效率的思路
它的效率来源不是自动化跑测试脚本，而是把「一套固定的审计方法论」变成可复用的技能：你不需要每次重新组织检查清单、重新设计报告结构，只要把项目喂进去，就能得到结构一致的审计结论与修复计划。
安装与启用的一般步骤如下（具体入口、命令与调用方式以官方说明为准，本文不做臆测）：
- 确认前提：你的项目是一个由 HTML、CSS、JavaScript 构成的前端项目，且运行环境为 tandem（compatibility 字段限定）。
- 准备输入目录：在项目根目录下准备
src/（或inputs/src/）用于存放待审计源码，并把已知待办事项写入inputs/TODO.md。这一步决定了审计结果是否贴合你的真实关注点。 - 通过技能市场 / 技能管理入口完成安装：在技能库中按技能英文名
web-starter-audit或技能ID13832检索并安装，具体安装命令与页面入口以官方说明为准。 - 验证是否生效：在对话中直接说出触发词之一（如
web audit），或明确要求「对本项目做一次 Web 审计」。若技能正常生效，它会先扫描src/结构并识别用户关键流程，随后按流程产出outputs/下的四份工件。 - 检查输出目录：出现
outputs/audit_findings.md、outputs/remediation_plan.md、outputs/changelog.md、outputs/project_audit_report.html即代表链路跑通。
该技能的主要功能和特点
- 结构扫描与关键流程识别：第一步不是逐个文件挑错，而是先扫描项目结构、找出「用户关键流程」。这让后续审计聚焦在真正影响用户的高价值路径上，而不是在无关紧要的样式细节里耗时间。
- 无障碍访问专项审计：覆盖语义化结构、焦点管理、表单标签、颜色对比度、键盘导航五大维度。每个无障碍问题都会被映射到具体标准，而不是只给一句「这里不太友好」。
- 代码质量专项审计：检查运行时错误、不安全的默认设置与假设、死代码、不良默认配置。它关注的是「会不会出事」，而不是「符不符合个人编码风格」。
- 按投入产出比排优先级：所有修复方案都会结合「努力」与「影响」两个维度排序，交付的是一份有先后次序的行动计划，而不是一份平铺的问题清单。
- 带严重性与复现指引：每条发现都标注严重程度并给出重现指导，方便开发者先复现、再修复、后验证。
- 四份可交付工件：
audit_findings.md（问题发现）、remediation_plan.md（修复计划）、changelog.md（变更记录）、project_audit_report.html（可视化报告）。其中 HTML 报告适合直接发给非技术同事。 - 面向双读者写作：质量标准明确要求报告「易于工程和产品理解」，也就是说它同时承担了技术文档与沟通材料的角色。
- 和普通工具比强在哪：普通扫描工具通常只给「检测结果」，这个技能给的是「检测结果 + 排序后的修复路径 + 可复核的记录」，并且把报告结构固定下来，多次审计之间可以横向对比。
如何使用该技能？
以下按实际使用顺序给出分步指南，示例尽量贴近真实项目。
第 1 步：整理输入
把待审计的代码放到 src/（技能也支持 inputs/src/）。同时准备 inputs/TODO.md，把你已知的顾虑写进去，例如：
# TODO
- 移动端导航菜单用键盘打不开
- 首页表单提交后没有提示
- 想确认配色是否满足对比度要求
这一步的意义在于：TODO 里的条目会成为审计的重点关注项，而不是被淹没在通用检查里。
第 2 步：触发审计
用技能提供的触发词发起请求，常见的三种调用方式：
- 直接说触发词：
accessibility audit - 使用通用词：
web audit或qa pass - 自然语言描述：「请对这个项目做一次完整的质量审计，重点关注无障碍访问」
第 3 步：确认关键流程
技能会先扫描结构并识别用户关键流程。此时建议你主动确认一次，例如「关键流程是注册、登录、下单三步」，帮助它把审计重心放对位置。
第 4 步：查看问题发现
打开 outputs/audit_findings.md。预期内容形态是「问题 + 严重性 + 复现指导 + 对应标准（无障碍项）」。你可以按严重性从高到低逐条处理。
第 5 步：执行修复计划
打开 outputs/remediation_plan.md，按其中的顺序施工。这份计划已经按努力与影响排序，所以不要跳着改——先做高影响、低成本的项，通常就能消掉大部分明显问题。
第 6 步：核对变更与汇报
outputs/changelog.md 记录本轮变更，便于提交说明与团队同步；outputs/project_audit_report.html 是可视化报告，适合给产品、设计或负责人做验收汇报。
第 7 步：复跑验证
修改完成后再次触发审计，对比两轮 audit_findings.md 的差异，即可形成「审计—修复—复核」的闭环。
同类型竞品对比分析
| 方案名称 | 定位 | 核心功能 | 安装/使用门槛 | 适用场景 | 优势与不足 |
|---|---|---|---|---|---|
| web-starter-audit（本技能） | 面向入门 Web 项目的全流程审计与修复规划 | 结构扫描、无障碍审计、质量审计、优先修复方案、四份审计工件 | 需在 tandem 环境安装技能，项目需 HTML/CSS/JS，学习成本低 | 交付前质量兜底、教学项目评审、开源项目接手 | 优势：给的是「问题 + 排序后的修复路径 + 报告」；不足：偏入门项目定位，超大型工程化项目需配合专业流水线 |
| Chrome DevTools / Lighthouse 类内置检测 | 浏览器端页面的性能与无障碍指标检测 | 生成指标分数与基础无障碍检测项 | 浏览器内置，零安装 | 单页面快速体检、性能优化 | 优势：即时、免费、分数直观；不足：偏向指标与检测项罗列，不产出修复顺序与变更记录 |
| axe DevTools 类无障碍专项检测 | 聚焦 WCAG 规则的无障碍检测 | 规则库扫描、定位到元素级问题 | 需安装浏览器插件，具体以官方说明为准 | 无障碍专项整改、合规自查 | 优势：规则覆盖细、定位精准；不足：主要解决无障碍单一维度，代码质量与体验问题需另找工具 |
| WAVE 类可视化无障碍评估 | 可视化标注页面无障碍问题 | 页面内问题标注、结构视图 | 在线或插件方式，以官方说明为准 | 设计评审、无障碍教学演示 | 优势：可视化直观，沟通成本低；不足：不涉及死代码、不安全默认值等质量问题，缺少修复计划工件 |
| 人工代码评审清单 | 由人按清单逐项检查 | 依赖评审者经验与清单完整度 | 零门槛但高度依赖人手与时间 | 小团队互评、重要版本把关 | 优势：能结合业务上下文判断；不足：结果不稳定、耗时、难以横向对比，容易漏项 |
选择建议：如果你要的是「一份能直接照着改的审计报告」，本技能的形态更贴合；如果你要的是即时分数或单一维度的深度检测，可以把上述工具与本技能配合使用——前者负责发现，本技能负责组织修复路径。
该技能的典型应用场景与实际体验情况
场景一：独立开发者的上线前自查
角色：一个人包办前后端的独立开发者。痛点：功能写完就发，出了问题靠用户反馈。使用方式：把项目丢进 src/，写几条 TODO，触发 qa pass，然后按 remediation_plan.md 的顺序挨个改。
实际体验：上手几乎没有门槛，触发词说对就能跑起来。收益最明显的是「排序」——新手面对几十条问题容易直接放弃，按努力与影响排序后，先做几项高性价比修复，页面可用性就有肉眼可见的变化。注意：TODO 写得越具体，审计越贴合你的真实痛点。
场景二：学生团队或培训班项目评审
角色：课程项目小组或带教老师。痛点：评审标准不统一，评语停留在「体验一般」。使用方式：以 audit_findings.md 作为评审依据，每条问题都带严重性和复现步骤，无障碍项还映射到具体标准。
实际体验：把「凭感觉评价」变成「按条目讨论」，沟通效率明显提升。project_audit_report.html 可以直接当作答辩材料。注意：报告是辅助材料，最终判断仍需人工把关。
场景三：接手一个陌生开源项目
角色：刚接手他人代码的维护者。痛点：不了解原作者的默认设置与遗留问题，改一处怕崩一片。使用方式：先跑一次 web audit 摸清结构、关键流程与安全隐患，再参考 remediation_plan.md 制定迭代节奏。
实际体验：结构扫描 + 关键流程识别这一步价值很大，相当于快速建立项目地图。质量审计部分对「不安全的假设」和「不良默认设置」的提示，往往能提前拦住后续的坑。注意：审计结论要结合项目历史上下文判断，不要机械执行。
场景四：迭代前的质量兜底
角色：小团队研发。痛点：每次发版前靠人工点点点，漏测概率高。使用方式：把 web audit 固定为发版前动作，changelog.md 记录每轮修复，多轮 audit_findings.md 做纵向对比。
实际体验：因为输出文件名和结构是固定的，很容易形成流程习惯，图表化程度虽然有限，但够用。注意：这是流程补充而非替代自动化测试，别指望它跑回归用例。
该技能能为用户带来的价值
- 把「隐性经验」变成「显性流程」：无障碍审计的五维检查（语义、焦点、标签、对比度、键盘导航）和代码质量的四类排查（错误、不安全假设、死代码、不良默认）原本是资深开发者的经验直觉，现在变成了每次都跑一遍的固定动作。
- 大幅压缩问题定位时间：不需要自己组织检查清单、不需要手写报告模板，审计与文档产出合并在一轮流程里完成，重复劳动被消除；四份工件的结构固定，多轮审计可直接横向对比。
- 降低无障碍门槛：无障碍规范条文多、术语重，是很多入门项目直接跳过的部分。技能把问题映射到具体标准并给出复现指导，让不熟悉规范的开发者也能按图施工。
- 让修复真正落地：按努力与影响排序的修复计划，解决的正是「知道有问题但不知从哪改」的普遍困境。先做高影响低成本项，投入产出比最高。
- 提升协作与沟通效率：
project_audit_report.html面向产品与设计，audit_findings.md面向工程，changelog.md面向版本管理与交接，一份审计同时服务多个读者。 - 长期价值：随着审计次数累积，团队会沉淀出属于自己的质量基线与常见缺陷模式，新成员加入时可以更快对齐标准。
常见问题 FAQ
Q1：这个技能怎么安装？需要什么前置条件？
在技能库中按英文名 web-starter-audit 或技能ID 13832 检索并安装，具体安装入口与命令以官方说明为准。前置条件是：HTML、CSS、JavaScript 构成的 Web 项目，运行环境需兼容 tandem。安装后说出触发词 web audit 即可验证是否生效——能产出 outputs/ 下四份文件就说明链路正常。
Q2：这个技能收费吗？
技能本身的定价与授权方式由作者（tandem）与所在技能平台决定，本文提供的信息中不包含价格内容，请以官方说明为准。需要注意的是，它是审计与规划工具，不替代任何付费测试服务。
Q3：它适合谁用？不适合谁？
适合独立开发者、学生团队、带教老师、开源项目维护者，以及需要在交付前做质量兜底的研发小组。它明确面向「入门 Web 项目」，如果你的项目是大型工程化系统、需要覆盖端到端回归测试与性能压测，建议把它当作流程中的一环，而不是全部。
Q4：它和 Lighthouse、axe DevTools 这类工具怎么选？
看你想要的是「发现」还是「行动」。浏览器内置检测与 axe 类工具擅长快速给出指标与元素级定位，适合即时体检与专项整改；本技能的价值在于把发现整理成带严重性、带复现指引、带优先级顺序的修复计划与报告工件。实际做法是组合使用：专业工具负责发现，本技能负责组织修复路径与产出交付物。
Q5：为什么一定要提供 inputs/TODO.md？不提供行不行？
不提供也能跑，但会损失一个重要信号。inputs/TODO.md 是你主动声明的关注点，它会让审计在通用检查之外额外照顾你真正担心的问题；同时 TODO 里的条目往往对应「未完成的关键流程」，有助于技能更准确地识别用户关键流程，从而把审计重心放对位置。