前言¶
上线前或改版后，性能、可访问性、SEO 和最佳实践往往要分别跑 Lighthouse、对照 WCAG、再翻源码对报告。多份结果口径不一，改完也不清楚哪些项已验证。下面介绍 Addy Osmani 维护的 Agent Skill web-quality-audit：在 Agent 对话里按统一流程做「有证据」的综合审计，并把发现按影响与置信度归类，而不是只盯一个总分。
这是什么¶
web-quality-audit 是 web-quality-skills 仓库中的 Skill（SKILL.md 元数据版本 2.0，MIT 许可）。官方描述为：在性能、可访问性、SEO、最佳实践以及 Agentic Browsing 等维度做以证据为导向的质量审查，结合真实浏览器观测与源码检查；不把聚合分数当作质量已合格的证明。
在 officialskills.sh 上的说明强调：一次覆盖 150+ 项 Lighthouse 相关检查，按严重程度归类并给出可落地的修复建议（含代码层面指向），避免性能、a11y、SEO 各跑一套工具再手工合并报告。
适用触发语包括：audit my site、review web quality、run lighthouse audit、check page quality、optimize my website 等。
文档要求与 Lighthouse 13+ 对齐：Performance 类别与 Chrome DevTools Performance 面板共用 Performance Insights；应跟随当前 insight 名称与证据，不要依赖已移除的 audit ID 或自动复刻其建议。
核心功能¶
审计维度¶
| 类别 | 要点（摘自官方 SKILL.md） |
|---|---|
| Performance | Core Web Vitals：LCP < 2.5s、INP < 200ms、CLS < 0.1；资源与加载策略（图片压缩、JS/CSS 优化、预连接、预加载、缓存等） |
| Accessibility | 可感知、可操作、可理解、健壮性（alt、对比度、键盘、焦点、表单标签、ARIA 等，对齐 WCAG AA 等常见要求） |
| SEO | 可抓取性（robots、sitemap、canonical）、页面元信息与标题层级、技术 SEO（HTTPS、移动友好、结构化数据等） |
| Best practices | 安全（HTTPS、依赖、CSP）、现代标准与控制台清洁、UX 模式（插屏、权限请求等） |
| Agentic Browsing | 用 Lighthouse Agentic Browsing 结果评估页面对助手是否可理解、可交互；含语义表面、WebMCP（若存在）、可选 llms.txt 等说明 |
工作流程¶
官方 How it works 概括为五步：
- 明确审计对象：代表性 URL、关键状态与用户路径、公开或需登录、移动/桌面范围。
- 若页面可运行，先按性能测量文档收集最小 live 基线，再大范围搜代码。
- 用运行时失败定位源码；实测结论与仅来自代码的假设分开记录。
- 按用户影响与置信度分类，给出或建议具体修复。
- 重跑等效自动化检查及受影响的手动流程，标明已验证与仍需现场/人工确认项。
工具路由（不阻塞于可选环境）¶
Skill 要求优先使用已有能力，可选 MCP 未配置时仍可审计：
| 需求 | 优先 | 回退 |
|---|---|---|
| 性能与 Core Web Vitals | 录制性能 trace 并分析 insight；有 Chrome DevTools MCP 时用 performance_start_trace / performance_analyze_insight |
Lighthouse CLI 或 PageSpeed Insights 实验室数据 |
| 真实用户性能 | 当前 DevTools trace 摘要中的 CrUX | PageSpeed Insights / CrUX Vis；有 key 或需自动化时用 CrUX API |
| 可访问性、SEO、最佳实践、Agentic Browsing | 现场 Lighthouse；有 MCP 时用 lighthouse_audit |
分类别 Lighthouse CLI + 手动检查 |
| 渲染语义与交互 | 无障碍树与 UI 操作；MCP 下 take_snapshot、evaluate_script |
浏览器/手动测试 |
| 源码冒烟 | scripts/analyze.sh <path> |
直接读源码 |
说明：Chrome DevTools MCP 的 lighthouse_audit 故意不包含 performance；导航模式会重载页面，需保留登录或用户状态时可用 snapshot 模式。静态分析脚本是快速冒烟，不能替代渲染页审计。
安装与启用¶
官方skills 目录给出的安装方式为：
npx skills add https://github.com/addyosmani/web-quality-skills --skill web-quality-audit
也可将 Skill 目录链接交给编码助手安装：
https://github.com/addyosmani/web-quality-skills/tree/main/skills/web-quality-audit
本文未在已抓取资料中核对 Cursor、Codex CLI、Claude Code 的差异化配置步骤；按各产品对 Agent Skills 的通用挂载方式启用即可。Skill 本体为仓库内 skills/web-quality-audit 下的 SKILL.md 及引用文档（如 ../performance/references/MEASUREMENT.md）。
典型用法¶
在 Agent 中安装 Skill 后，用自然语言说明站点与目标即可，例如 officialskills.sh 列出的场景：
- 落地页改版上线前检查 Core Web Vitals
- 营销站审查 WCAG AA 对比度与图片
alt - 审计 Next.js 构建中的无用 JavaScript、过大图片
- 校验博客的 meta、canonical、标题层级
- 生产部署前发现混合内容与过时依赖
执行时 Agent 会按上文五步建立 URL 与范围，在条件允许时先采 live 基线，再按工具表选择 Lighthouse、trace 或 analyze.sh，最后输出分级问题与修复建议。你可在对话中补充「仅桌面」「需登录态 URL」等约束，对应 Skill 第一步的审计范围定义。
适用场景与注意¶
适合：需要一次性覆盖性能、a11y、SEO、最佳实践（及 Agentic Browsing 信号）的前端/全栈团队；希望 Agent 按证据链报告而非只报 Lighthouse 总分；已有或计划接入 Chrome DevTools MCP、Lighthouse CLI 的环境。
注意：
- Performance 洞察以 Lighthouse 13+ 与 DevTools 当前 insight 为准，勿死磕已废弃 audit。
- MCP 的 Lighthouse 与 CLI/PSI 能力互补；性能与非性能类别可能走不同路径。
- 字段级 Core Web Vitals（CrUX）用于佐证体验信号，Skill 明确不承诺排名变化。
- Agentic Browsing / WebMCP 用于评估可自动化交互质量，不应为了分数而堆砌 WebMCP。
结尾¶
web-quality-audit 把 Lighthouse 体系下的多类检查收敛成一条 Agent 可执行的审计流程：先定范围与 live 证据，再源码对照，分类修复并重验。若你正在统一「审站」入口，可从官方仓库安装并在对话里直接提出审计需求。
