AI Agent 如何做网页性能审计？我的 Lighthouse Skill 实践笔记

05/07/2026

AI Agent 如何做网页性能审计？我的 Lighthouse Skill 实践笔记

封装了一个 Lighthouse 性能审计 Agent Skill：阶段 A 只出报告不改代码，AskQuestion 确认后再进阶段 B 出优化清单。支持 MCP/CLI 双通道，内置 URL 重试、device 锁定、本地/线上回归分流。Cursor / Claude Code 通用，Skill 按阶段拆成 7 个 md 渐进加载。

#Agent Skill #Lighthouse #性能优化 #Cursor

一、背景：为什么需要这个 Skill

直接用自然语言让 AI「分析一下网站性能」，常见问题有：

  • 一上来就读全仓库、改文件，用户其实只想看报告
  • 工具混用，MCP trace 和 Lighthouse CLI 指标对不上
  • 线上 URL 连不上就代测本地，结论不可信
  • 输出冗长，反复科普 CWV，或把 AskQuestion 选项写在正文里

我希望 Agent 遵守一条简单原则：先审计、后优化；有证据、再动代码。

于是封装了 lighthouse-analysis-optimization Skill——不绑定具体框架，Cursor / Claude Code / Codex CLI 都能用。

二、整体设计：两阶段 + 九步主流程

Skill 把任务拆成 阶段 A（审计） 和 阶段 B（优化），严格按序执行：

步 阶段 动作
1 A 解析输入：URL / 路由 / device / 本地|线上
2 A 能力自检：MCP 或 CLI
3 A 执行审计（失败同 URL 重试最多 5 次）
4 A 输出审计报告（评分、指标、结论）
5 A→B AskQuestion：是否继续优化
6 B AskQuestion：确认项目范围
7 B 读代码 + 输出优化清单（含「涉及文件」）
8 B AskQuestion：选择执行项
9 B 改代码 + 回归对比 
flowchart TD
  A[解析 URL / device] --> B[MCP 或 CLI 自检]
  B --> C[执行 Lighthouse 审计]
  C --> D[输出审计报告]
  D --> E{用户意图?}
  E -->|只问达标 / 不要改代码| F[结束]
  E -->|全绿且未要求优化| G[达标，无必改项]
  E -->|默认 / 有 fail| H{AskQuestion: 继续优化?}
  H -->|否| F
  H -->|是| I[确认项目范围]
  I --> J[优化清单 P0/P1/P2]
  J --> K{AskQuestion: 选执行项}
  K --> L[改代码 + 回归]

意图分支（和普通 prompt 的核心差异）

用户说法 Skill 行为
「某 URL 移动端达标吗？」 审计 + 结论；全绿则「达标，无必改项」，不弹继续优化
「分析某 URL，不要改代码」 报告后结束，跳过步骤 5–9
「分析某 URL 性能」（默认） 报告后 AskQuestion 是否继续
「分析并优化本项目首页」 可跳过步骤 5，但改代码前仍须确认工作区

三、关键 Guardrails

这些是 Skill 里写死的约束，也是封装时最有价值的部分：

1. 阶段 A 不读仓库、不改文件

审计报告只有评分和结论，没有「涉及文件」。避免 Agent 还没问用户就开始 grep。

2. URL 不可达时的诚实失败

用户给完整线上 URL 时，只对同一 URL 重试最多 5 次。5 次均失败 → 简短失败报告，禁止 build 工作区代测本地、禁止猜分数。

3. lab vs field 只说一次

Lighthouse 是实验室数据；CWV 达标看 CrUX 现场数据。全文最多提 1 次，放末尾一句，开头不科普。

4. AskQuestion 必须用结构化 UI

步骤 5 / 6 / 8 的选项禁止写在报告正文（不能用「需要我继续吗？1. 是 2. 否」代替）。

5. device 与工具模式全程锁定

mobile/desktop 选定后，回归对比必须用同一 device、同一 MCP/CLI 模式。

6. 输出克制

直接给结论，不复述内部流程（「我先 emulate…」）；不自动 commit / push / 部署。

四、工具选型：MCP 与 CLI 分工

每次执行前做能力自检：

  1. 有 chrome-devtools MCP → MCP 分支
  2. 无 MCP，有 npx → 官方 npx lighthouse CLI
  3. 都没有 → 引导安装 MCP 或 Node.js
想要的数据 正确来源
A11y / SEO / Best Practices 分 lighthouse_audit（不含 Performance）
LCP / CLS / TTFB 归因 performance_start_trace + analyze_insight（须先 emulate）
TBT / Speed Index / opportunities Lighthouse CLI
真实用户现场数据 CrUX（MCP trace 附带）或 PageSpeed Insights（CLI 分支）

一句话：CWV 归因走 MCP + emulate，完整指标表走 CLI，达标看 CrUX。

五、阶段 B：优化清单怎么来

进入阶段 B 后，清单基于阶段 A 的 audit 证据，按 LCP 四段对症下药：

  • TTFB 占比大 → 后端 / 缓存 / CDN，不是压图片
  • 资源加载延迟大 → preload + fetchpriority="high"，首屏勿 lazy
  • 资源加载时长大 → AVIF/WebP、srcset、压缩
  • 渲染延迟大 → 关键 CSS 内联、异步 CSS、拆分 JS

优先级示例：

  • P0：LCP > 4s、CLS > 0.25、A11y fail、首屏 lazy
  • P1：preload、WebP/AVIF、font-display:swap、防 CLS 尺寸
  • P2：代码分割、依赖瘦身、Speculation Rules

输出格式：

## 优化清单

**目标项目：** 当前工作区 / <绝对路径>

### P0 — 必须修复
1. 问题 → 改法 → 涉及文件

### P1 — 强烈建议
2. …

六、回归：本地 vs 线上分流

改完代码后不能一刀切：

本地 URL → 可直接回归。优先 build + preview，用生产构建对比前后指标。

线上 URL → 改完先停，提醒用户部署：

> 改动尚未上线，直接回归只会测到旧代码。请先部署/发布。

用户确认「已部署」后，先做部署校验（DOM 属性、响应头、请求次数），确认改动已生效，再重新审计对比。

七、Skill 文件结构：渐进式加载

不把几万字一次性塞给 Agent，而是按阶段 lazy load：

lighthouse-analysis-optimization/
├── SKILL.md              # 主流程 + 全局约束 + 意图分支
├── phase-a-audit.md      # 阶段 A：输入约定、URL 重试、审计步骤
├── phase-b-optimize.md   # 阶段 B：项目范围、清单格式、优先级
├── askquestion.md        # 步骤 5/6/8 的结构化交互规范
├── tools.md              # MCP/CLI 自检与数据来源分工
├── regression.md         # 本地/线上回归规则
└── examples.md           # 6 个典型意图示例

阶段 A 只读 tools.md + phase-a-audit.md；进入阶段 B 后再读其余文件。这样 token 更省，行为也更稳定。

八、使用示例

例 1 — 只问达标

「https://example.com 移动端达标吗？」

→ 审计 + 结论；全绿则「达标，无必改项」，不弹继续优化。

例 2 — 分析外部 URL（默认流）

「分析一下 https://example.com 的性能」

→ 审计报告 → AskQuestion 是否继续 → 确认项目 → 优化清单 → 选执行项 → 改代码。

例 3 — 明确不要优化

「分析 https://example.com，不要改代码」

→ 审计报告 → 结束。

例 4 — 直接优化本项目

「分析并优化本项目首页性能」

→ 审计 → 跳过「是否继续」→ 确认工作区 → 清单 → 改代码 → 本地回归。

例 5 — 线上不可达

完整线上 URL 连不上 → 同 URL 重试 5 次 → 失败报告 → 不 build 工作区、不测本地。

九、安装与触发

路径（个人 Skill）：

~/.claude/skills/lighthouse-analysis-optimization/
# 或 ~/.cursor/skills/lighthouse-analysis-optimization/

依赖： chrome-devtools-mcp 或 Node.js + npx lighthouse

触发词（写在 description 里）：

Lighthouse、性能分析、LCP/CLS/TTFB、优化清单、analyze page performance

MCP 安装示例（Cursor）：

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": ["-y", "chrome-devtools-mcp@latest"]
    }
  }
}

十、复盘：封装 Skill 的几条心得

  1. Skill 是状态机，不是长 prompt
    把「何时读代码」「何时 AskQuestion」「何时必须停」写清楚，比堆技巧更有效。

  2. reference 文件按阶段拆分
    主文件 SKILL.md 做索引，细节按需加载，减少 Agent 跑偏。

  3. Guardrails 要写否定句
    「禁止代测本地」「禁止正文写选项」比「请尽量…」更好执行。

  4. lab 和 field 分开
    Lighthouse 负责找问题和验改动；CrUX 负责回答「用户真实体验是否达标」。

  5. 回归必须分本地/线上
    否则 Agent 改完本地代码就对线上 URL 再跑一遍，测到的还是旧版本。

点击跳转体验Skill