前言¶
上線前或改版後，性能、可訪問性、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 證據，再源碼對照，分類修復並重驗。若你正在統一「審站」入口，可從官方倉庫安裝並在對話裏直接提出審計需求。
