告别繁杂的性能审查报告
Lighthouse 生成的 JSON 报告包含数百个深层技术指标（LCP、FID、CLS、TBT、DOM 节点深度等），开发者往往要花费几个小时对照指标去代码中寻找瓶颈。
智能化性能排查流
- 调用
lighthouse.audit_page(url)自动在无头浏览器中多轮采样并输出结构化评分； - 针对得分低于 80 分的指标（如 LCP 过长），Agent 自动检查资源包体积与图片格式；
- 结合本地代码库，直接将
<img>替换为带有loading="lazy"的响应式 WebP 格式，或对过大的三方库实施路由懒加载拆包重构。
采集侧：先把报告变成结构化工具输出
Lighthouse 的完整 JSON 动辄几十万字符，直接塞给模型既浪费上下文也容易让它迷失在无关指标里。合理做法是包一层工具：内部执行采集，只回传精简后的字段。
npx lighthouse https://example.com \
--only-categories=performance \
--output=json --output-path=./report.json \
--quiet --chrome-flags="--headless=new"
命令行参数以 Lighthouse 官方文档为准；更稳的做法是在 Node 里用它的编程接口跑同一个页面上限三到五次，取中位数后再输出。工具返回值建议只保留：核心指标及数值、低于阈值的审计项、每项的 details 中可定位的字段（资源 URL、选择器、浪费体积），以及本次采集的环境信息（视口、节流档位、是否禁用扩展）。节流档位与视口不同会让同一页面分数差出很多，对比前后必须固定。
诊断侧：指标到动作的映射
| 指标异常 | 常见根因 | 优先动作 |
|---|---|---|
| LCP 偏高 | 首屏大图、服务端渲染慢、关键资源被阻塞 | 预加载主图、压缩为现代格式、拆分同步脚本 |
| CLS 偏移 | 图片缺宽高、字体换入导致回流、动态插入内容 | 固定尺寸占位、字体策略调整 |
| TBT 偏高 | 主线程被大段 JS 占用 | 路由级懒加载、延后非关键第三方脚本 |
| 总体积过大 | 依赖全量引入、未做代码分割 | 按需引入、拆包、检查 polyfill 体积 |
给模型的提示词里写清约束：一次只针对一个指标提出改动，改动必须落到具体文件与选择器，禁止为了分数牺牲可访问性或功能。这条约束比换更强的模型更能减少无意义改动。
采纳侧：让改动可回滚
把采纳过程做成三段：Agent 提交补丁与理由，人看 diff 决定是否合入，合入后自动复测并回传同一组指标。每次只接受一类改动（图片、脚本、CSS 分开），一次改十项时性能提升与功能回归混在一起，谁也说不清是哪一步造成的。合并前跑构建与现有测试，合并后在相同节流档位下复测，指标没有改善的改动应当回退而不是留着。
验证方法
三个检查点。第一，同一 URL 连测三到五次，核心指标波动在可接受范围内，否则先修采集环境（扩展、后台任务、网络）。第二，用报告里的资源清单反查改动是否命中真实瓶颈，而不是只把数字改小。第三，如果有真实用户监控数据（例如 Core Web Vitals 字段数据），以它作为最终判据，实验室分数只是快速反馈。
常见故障速查
| 现象 | 原因 | 处理 |
|---|---|---|
| 同一页面分数忽高忽低 | 采样次数不足、节流档位不同 | 固定环境，多次取中位数 |
| 报告过长导致模型答非所问 | 直接投喂完整 JSON | 只传低于阈值的审计项与 details |
| 改动后指标反而变差 | 为分数牺牲了渲染逻辑 | 逐项回滚，一次一类改动 |
| 无头浏览器启动失败 | Chrome 路径或沙箱参数问题 | 本地先手动跑通再包进工具 |
| 需要登录的页面测不到 | 未复用会话或测试环境无数据 | 用测试账号与预置数据的环境 |
小结
这套流程是否可用，用一条判断标准就够了：每一次由 Agent 提出的改动，都能在同一采集条件下复测出对应指标的可复查改善，且不引入测试或功能回归。达不到就先退回到「只诊断不改」的模式，让它输出带文件路径的建议清单——这已经是多数团队能立刻拿到收益的形态，改代码可以慢慢放开。