[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"site-settings":3,"notes-all":12,"note-agent-skill-lighthouse-performance-audit":41},{"siteName":4,"siteDescription":5,"authorName":6,"copyright":7,"logoSymbol":8,"createdAt":9,"updatedAt":10,"id":11},"DICE","前端工程师的技术日志，记录 AI 探索与独立开发的思考","dice","Copyright © 2026 Dice. All rights reserved.","https:\u002F\u002Fstatic.diceio.com\u002Ff\u002Fb263d41b758729f8a32abdfeed19f620b85b22e9f4e2a126b2bd016f88a4df41",1782794723207,1783653454363,"6a4349e3ab9e79d68cae07a4",[13,29],{"id":14,"slug":15,"title":16,"summary":17,"content":18,"category":19,"tags":20,"date":26,"cover":27,"views":28,"likes":28},"6a4a8dade2c37b4b335c52ea","open-spec-and-spec-kit","学习如何项目上运用OpenSpec+Spec Kit进行开发","学习如何项目上运用OpenSpec+Spec Kit进行开发,学习中","","ai",[21,22,23,24,25],"Open Spec","Spec Kit","AI","TDD","SDD","2026-07-05","\u002Fcovers\u002Fpost-1.webp",0,{"id":30,"slug":31,"title":32,"summary":33,"content":18,"category":34,"tags":35,"date":26,"cover":40,"views":28,"likes":28},"6a4a87e9e2c37b4b335c525c","agent-skill-lighthouse-performance-audit","AI Agent 如何做网页性能审计？我的 Lighthouse Skill 实践笔记","封装了一个 Lighthouse 性能审计 Agent Skill：阶段 A 只出报告不改代码，AskQuestion 确认后再进阶段 B 出优化清单。支持 MCP\u002FCLI 双通道，内置 URL 重试、device 锁定、本地\u002F线上回归分流。Cursor \u002F Claude Code 通用，Skill 按阶段拆成 7 个 md 渐进加载。","Skills",[36,37,38,39],"Agent Skill","Lighthouse","性能优化","Cursor","\u002Fcovers\u002Fpost-3.webp",{"id":30,"slug":31,"title":32,"summary":33,"content":42,"category":34,"tags":43,"date":26,"cover":40,"views":28,"likes":28},"## 一、背景：为什么需要这个 Skill\n\n直接用自然语言让 AI「分析一下网站性能」，常见问题有：\n\n- **一上来就读全仓库、改文件**，用户其实只想看报告\n- **工具混用**，MCP trace 和 Lighthouse CLI 指标对不上\n- **线上 URL 连不上就代测本地**，结论不可信\n- **输出冗长**，反复科普 CWV，或把 AskQuestion 选项写在正文里\n\n我希望 Agent 遵守一条简单原则：**先审计、后优化；有证据、再动代码。**\n\n于是封装了 `lighthouse-analysis-optimization` Skill——不绑定具体框架，Cursor \u002F Claude Code \u002F Codex CLI 都能用。\n\n---\n\n## 二、整体设计：两阶段 + 九步主流程\n\nSkill 把任务拆成 **阶段 A（审计）** 和 **阶段 B（优化）**，严格按序执行：\n\n| 步 | 阶段 | 动作 |\n|---|---|---|\n| 1 | A | 解析输入：URL \u002F 路由 \u002F device \u002F 本地\\|线上 |\n| 2 | A | 能力自检：MCP 或 CLI |\n| 3 | A | 执行审计（失败同 URL 重试最多 5 次） |\n| 4 | A | 输出审计报告（评分、指标、结论） |\n| 5 | A→B | AskQuestion：是否继续优化 |\n| 6 | B | AskQuestion：确认项目范围 |\n| 7 | B | 读代码 + 输出优化清单（含「涉及文件」） |\n| 8 | B | AskQuestion：选择执行项 |\n| 9 | B | 改代码 + 回归对比 |\n\n```mermaid\nflowchart TD\n  A[解析 URL \u002F device] --> B[MCP 或 CLI 自检]\n  B --> C[执行 Lighthouse 审计]\n  C --> D[输出审计报告]\n  D --> E{用户意图?}\n  E -->|只问达标 \u002F 不要改代码| F[结束]\n  E -->|全绿且未要求优化| G[达标，无必改项]\n  E -->|默认 \u002F 有 fail| H{AskQuestion: 继续优化?}\n  H -->|否| F\n  H -->|是| I[确认项目范围]\n  I --> J[优化清单 P0\u002FP1\u002FP2]\n  J --> K{AskQuestion: 选执行项}\n  K --> L[改代码 + 回归]\n```\n\n### 意图分支（和普通 prompt 的核心差异）\n\n| 用户说法 | Skill 行为 |\n|----------|------------|\n| 「某 URL 移动端达标吗？」 | 审计 + 结论；全绿则「达标，无必改项」，**不弹**继续优化 |\n| 「分析某 URL，不要改代码」 | 报告后结束，**跳过**步骤 5–9 |\n| 「分析某 URL 性能」（默认） | 报告后 **AskQuestion** 是否继续 |\n| 「分析并优化本项目首页」 | 可跳过步骤 5，但改代码前仍须确认工作区 |\n\n---\n\n## 三、关键 Guardrails\n\n这些是 Skill 里写死的约束，也是封装时最有价值的部分：\n\n**1. 阶段 A 不读仓库、不改文件**\n\n审计报告只有评分和结论，**没有「涉及文件」**。避免 Agent 还没问用户就开始 grep。\n\n**2. URL 不可达时的诚实失败**\n\n用户给完整线上 URL 时，只对**同一 URL** 重试最多 5 次。5 次均失败 → 简短失败报告，**禁止** build 工作区代测本地、**禁止**猜分数。\n\n**3. lab vs field 只说一次**\n\nLighthouse 是实验室数据；CWV 达标看 CrUX 现场数据。全文最多提 1 次，放末尾一句，开头不科普。\n\n**4. AskQuestion 必须用结构化 UI**\n\n步骤 5 \u002F 6 \u002F 8 的选项**禁止**写在报告正文（不能用「需要我继续吗？1. 是 2. 否」代替）。\n\n**5. device 与工具模式全程锁定**\n\nmobile\u002Fdesktop 选定后，回归对比必须用同一 device、同一 MCP\u002FCLI 模式。\n\n**6. 输出克制**\n\n直接给结论，不复述内部流程（「我先 emulate…」）；不自动 commit \u002F push \u002F 部署。\n\n---\n\n## 四、工具选型：MCP 与 CLI 分工\n\n每次执行前做能力自检：\n\n1. **有 chrome-devtools MCP** → MCP 分支\n2. **无 MCP，有 npx** → 官方 `npx lighthouse` CLI\n3. **都没有** → 引导安装 MCP 或 Node.js\n\n| 想要的数据 | 正确来源 |\n|------------|----------|\n| A11y \u002F SEO \u002F Best Practices 分 | `lighthouse_audit`（不含 Performance） |\n| LCP \u002F CLS \u002F TTFB 归因 | `performance_start_trace` + `analyze_insight`（须先 emulate） |\n| TBT \u002F Speed Index \u002F opportunities | Lighthouse CLI |\n| 真实用户现场数据 | CrUX（MCP trace 附带）或 PageSpeed Insights（CLI 分支） |\n\n一句话：**CWV 归因走 MCP + emulate，完整指标表走 CLI，达标看 CrUX。**\n\n---\n\n## 五、阶段 B：优化清单怎么来\n\n进入阶段 B 后，清单基于阶段 A 的 audit 证据，按 LCP 四段对症下药：\n\n- **TTFB 占比大** → 后端 \u002F 缓存 \u002F CDN，不是压图片\n- **资源加载延迟大** → `preload` + `fetchpriority=\"high\"`，首屏勿 `lazy`\n- **资源加载时长大** → AVIF\u002FWebP、`srcset`、压缩\n- **渲染延迟大** → 关键 CSS 内联、异步 CSS、拆分 JS\n\n优先级示例：\n\n- **P0**：LCP > 4s、CLS > 0.25、A11y fail、首屏 `lazy`\n- **P1**：preload、WebP\u002FAVIF、`font-display:swap`、防 CLS 尺寸\n- **P2**：代码分割、依赖瘦身、Speculation Rules\n\n输出格式：\n\n```\n## 优化清单\n\n**目标项目：** 当前工作区 \u002F <绝对路径>\n\n### P0 — 必须修复\n1. 问题 → 改法 → 涉及文件\n\n### P1 — 强烈建议\n2. …\n```\n\n---\n\n## 六、回归：本地 vs 线上分流\n\n改完代码后不能一刀切：\n\n**本地 URL** → 可直接回归。优先 `build` + `preview`，用生产构建对比前后指标。\n\n**线上 URL** → 改完先停，提醒用户部署：\n\n> 改动尚未上线，直接回归只会测到旧代码。请先部署\u002F发布。\n\n用户确认「已部署」后，先做部署校验（DOM 属性、响应头、请求次数），确认改动已生效，再重新审计对比。\n\n---\n\n## 七、Skill 文件结构：渐进式加载\n\n不把几万字一次性塞给 Agent，而是按阶段 lazy load：\n\n```\nlighthouse-analysis-optimization\u002F\n├── SKILL.md              # 主流程 + 全局约束 + 意图分支\n├── phase-a-audit.md      # 阶段 A：输入约定、URL 重试、审计步骤\n├── phase-b-optimize.md   # 阶段 B：项目范围、清单格式、优先级\n├── askquestion.md        # 步骤 5\u002F6\u002F8 的结构化交互规范\n├── tools.md              # MCP\u002FCLI 自检与数据来源分工\n├── regression.md         # 本地\u002F线上回归规则\n└── examples.md           # 6 个典型意图示例\n```\n\n**阶段 A 只读** `tools.md` + `phase-a-audit.md`；进入阶段 B 后再读其余文件。这样 token 更省，行为也更稳定。\n\n---\n\n## 八、使用示例\n\n**例 1 — 只问达标**\n\n「https:\u002F\u002Fexample.com 移动端达标吗？」\n\n→ 审计 + 结论；全绿则「达标，无必改项」，不弹继续优化。\n\n**例 2 — 分析外部 URL（默认流）**\n\n「分析一下 https:\u002F\u002Fexample.com 的性能」\n\n→ 审计报告 → AskQuestion 是否继续 → 确认项目 → 优化清单 → 选执行项 → 改代码。\n\n**例 3 — 明确不要优化**\n\n「分析 https:\u002F\u002Fexample.com，不要改代码」\n\n→ 审计报告 → 结束。\n\n**例 4 — 直接优化本项目**\n\n「分析并优化本项目首页性能」\n\n→ 审计 → 跳过「是否继续」→ 确认工作区 → 清单 → 改代码 → 本地回归。\n\n**例 5 — 线上不可达**\n\n完整线上 URL 连不上 → 同 URL 重试 5 次 → 失败报告 → **不** build 工作区、**不**测本地。\n\n---\n\n## 九、安装与触发\n\n**路径（个人 Skill）：**\n\n```\n~\u002F.claude\u002Fskills\u002Flighthouse-analysis-optimization\u002F\n# 或 ~\u002F.cursor\u002Fskills\u002Flighthouse-analysis-optimization\u002F\n```\n\n**依赖：** chrome-devtools-mcp 或 Node.js + `npx lighthouse`\n\n**触发词（写在 description 里）：**\n\nLighthouse、性能分析、LCP\u002FCLS\u002FTTFB、优化清单、analyze page performance\n\n**MCP 安装示例（Cursor）：**\n\n```json\n{\n  \"mcpServers\": {\n    \"chrome-devtools\": {\n      \"command\": \"npx\",\n      \"args\": [\"-y\", \"chrome-devtools-mcp@latest\"]\n    }\n  }\n}\n```\n\n---\n\n## 十、复盘：封装 Skill 的几条心得\n\n1. **Skill 是状态机，不是长 prompt**  \n   把「何时读代码」「何时 AskQuestion」「何时必须停」写清楚，比堆技巧更有效。\n\n2. **reference 文件按阶段拆分**  \n   主文件 `SKILL.md` 做索引，细节按需加载，减少 Agent 跑偏。\n\n3. **Guardrails 要写否定句**  \n   「禁止代测本地」「禁止正文写选项」比「请尽量…」更好执行。\n\n4. **lab 和 field 分开**  \n   Lighthouse 负责找问题和验改动；CrUX 负责回答「用户真实体验是否达标」。\n\n5. **回归必须分本地\u002F线上**  \n   否则 Agent 改完本地代码就对线上 URL 再跑一遍，测到的还是旧版本。\n\n\u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fskillhub.cn\u002Fskills\u002Flighthouse-analysis-optimization\">点击跳转体验Skill\u003C\u002Fa>\n",[36,37,38,39]]