性能优化最常见的失败长得都一样：一周花在抠 5ms 的后端，前端却有 3 秒 render-blocking CSS 没人动；或者加了三层缓存却不写失效，最后上线的不是”更快”而是”数据 stale”。下面这套 Prompt 强制反过来——先测量、点名最影响用户的瓶颈、再用最小改动去推那一个指标。这一版新增了 INP 题（Interaction to Next Paint 已于 2024 年 3 月取代 First Input Delay，成为 Core Web Vitals 之一，也是截至 2026 年 6 月最难达标的一项）、一道前后对比题用来把”装作没事”的回退抓出来，以及一个对最近 5 个性能 PR 的微优化检测题，专门挑”加了复杂度但没有度量收益”的那种。性能问题其实是正确性 bug 时，配合 Bug 审计 Prompt 一起用。
一句话总结
- 把真实数据（Lighthouse、PageSpeed 的字段数据、APM trace、慢查询日志）粘进 Prompt——绝不要让模型只看代码描述去猜瓶颈。
- 按 Google 真正打分的字段阈值优化，统计口径是真实访问的第 75 百分位：LCP 低于 2.5s、INP 低于 200ms、CLS 低于 0.1（见下表）。
- 分析本身值得上推理模型：Claude Opus 4.7 或 GPT-5.5（Thinking）处理长 trace 和 EXPLAIN 计划，远胜快速/Instant 档。
- 大多数团队漏掉、却最值钱的两道：INP 修复（第 3 条）和微优化检测（第 14 条）。
Core Web Vitals 阈值（2026 年 6 月）
Google 的过/不过看的是 Chrome 用户体验报告（CrUX）滚动 28 天的字段数据，统计口径是第 75 百分位——不是你本地的 Lighthouse 跑分。只有当 75% 的真实访问里三项指标都落在”良好”区间，这个 URL 才算通过。
| 指标 | 良好 | 需改进 | 差 | 衡量什么 |
|---|---|---|---|---|
| LCP（最大内容绘制） | ≤ 2.5s | 2.5–4.0s | > 4.0s | 加载：最大元素何时渲染出来 |
| INP（交互到下一次绘制） | ≤ 200ms | 200–500ms | > 500ms | 响应：最差一次交互的延迟 |
| CLS（累积布局偏移） | ≤ 0.1 | 0.1–0.25 | > 0.25 | 视觉稳定：意外的布局移动 |
INP 在 2024 年 3 月取代了 FID，截至 2026 年 6 月是三项里最难达标的一项——约 43% 的统计来源仍然过不了 200ms 这条线。Lighthouse 实验室里仍会报 Total Blocking Time（TBT）作为代理指标；把 TBT 当调试线索看，把 INP 字段数据当真正算分的那个。
这套 Prompt 适合用在哪
- 前端性能审计（LCP / INP / CLS）
- 后端延迟优化（TTFB）
- 数据库查询调优
- bundle 体积减小
- 内存泄漏排查
1. 瓶颈识别
下面是我的性能数据（[Lighthouse / PageSpeed 字段数据 / APM trace / 慢查询日志]）。
请定位 top 3 瓶颈。每条：发生在哪、对用户的影响估计、最小修复、修复的副作用。
按"对用户的可见影响"排序，而不是按修起来多容易。
[粘贴数据]2. LCP 优化
我的 LCP 在第 75 百分位是 [X] 秒；"良好"阈值是 2.5s。
下面是 HTML head、critical CSS，以及首屏主图的加载代码。
请诊断：(a) LCP 元素是什么；(b) 谁阻塞它渲染（render-blocking CSS/JS、图片发现得太晚、TTFB 慢）；
(c) 压到 2.5s 以内的最小改动集。可考虑给 LCP 图加 fetchpriority="high" 和 preload——但每页只给一个。
[粘贴]3. INP 修复
我的 INP 在第 75 百分位是 [X]ms；"良好"阈值是 200ms。
下面是最慢那次交互的事件处理函数，外加一段 performance 面板 trace。
请把延迟拆成输入延迟、处理时间、呈现延迟三段，然后告诉我：
(a) 哪个 long task 在阻塞主线程；(b) 哪些可以延后、让出（yield）或挪到 web worker；
(c) 这次交互里哪些是没必要的重渲染。
[粘贴]4. CLS 修复
我的 CLS = [X]；"良好"阈值是 0.1。下面是首屏 HTML 与 CSS。
请找出抖动元素，点名原因（图片/iframe 没写 width+height、字体替换、广告/横幅后注入、
在已有内容上方插内容），并给出"提前占位"的修复方案。
[粘贴]5. 慢查询识别
下面是慢查询日志 + EXPLAIN (ANALYZE) 计划。逐条 top 5：
(a) 为什么慢（顺序扫描、join 顺序差、缺索引、在索引列上套函数）；
(b) 具体缺什么索引或怎么重写查询；(c) 预期提升；
(d) 修复风险（写放大、索引膨胀、执行计划不稳定）。
[粘贴]6. N+1 查询识别
下面是单次请求的 ORM 查询日志。请找 N+1：哪个循环触发多少子查询、应 eager-load 什么、
可批量化什么。用 [Prisma / ActiveRecord / SQLAlchemy / Django ORM] 语法给修复，并给出预期的查询条数减少量。
[粘贴]7. JS bundle 减重
下面是 [webpack-bundle-analyzer / vite-bundle-visualizer] 的输出。列 top 5 体积大户：
(a) 是否 tree-shakable；(b) 是否有更轻的替代（点名）；(c) 是否能用动态 import 懒加载；
(d) 预估省的 kB（gzip 后）。
[粘贴]8. 阻塞资源修复
我的页面有 [N] 个 render-blocking 资源。下面是 HTML head。请提议：
(a) 哪些 CSS 内联为 critical；(b) 哪些脚本 defer 或 async；(c) 哪些字体/资源 preload；
(d) 哪些删除。说明顺序原因，以及对 LCP/INP 的影响。
[粘贴]9. 服务端响应时间（TTFB）优化
我的 TTFB = [X]ms，目标低于 [Y]ms。下面是后端 handler。请走一遍：
(a) 首字节前做了什么；(b) 哪些可并行或移出关键路径（后台任务、队列）；
(c) 在哪一层缓存什么。
[粘贴 handler]10. 内存泄漏定位
我的 [Node / 浏览器] 应用内存持续增长。下面是 heap 快照 / profiler。请识别泄漏：
(a) 什么被持有；(b) 为什么持有（闭包、游离 DOM 节点、无上限缓存、没移除的事件监听器）；
(c) 该修的具体那一行。
[粘贴]11. 缓存策略设计
我的 [端点 / 页面] 有 [N] req/s。下面是响应形状 + 可缓存约束。
请跨 edge/CDN、应用、DB 各层设计缓存策略，明确写出失效触发条件和一个现实的命中率目标。
标出绝对不能缓存的数据（按用户、带鉴权、实时）。
[粘贴]12. 图片优化审计
下面是页面上 10 张图的当前尺寸、格式、渲染显示宽度。每张给：
(a) 目标格式（AVIF 优先，WebP 兜底，JPEG 作 src）；(b) 目标宽度与 srcset/sizes；
(c) 加载策略（LCP 图用 eager + fetchpriority="high"，首屏以下用 lazy）；(d) 预估省的字节。
[粘贴]13. Web Vitals 前后对比
下面是改动前 Web Vitals（[粘贴]）与改动后（[粘贴]），都取第 75 百分位。请告诉我：
(a) 真正变好的是什么；(b) 反而变差的；(c) 哪些只是 CrUX 正常波动（噪声）、哪些是真信号；
(d) 上线 vs 回滚。14. 微优化检测
下面是我最近的性能 PR（[粘贴 5 个]）。逐个问：(a) 有没有改前/改后度量；
(b) 瓶颈是真实存在还是假设的；(c) 用户可见的实际收益；
(d) 哪些应被回滚为"加复杂度没收益"。对那些一个数字都没附的，下手狠一点。这些题该用哪个模型跑
- 长 trace、EXPLAIN 计划、多文件 bundle 输出： Claude Opus 4.7 或 GPT-5.5 的 Thinking 模式。两者都带 1M token 上下文（Opus 标配；ChatGPT 应用内完整 1M 是 $200 Pro 档），整份慢查询日志可以直接粘进去不被截断。
- 在编辑器里、对着真实仓库： 用 Cursor 或 Claude Code（见 Claude Code 执行 Prompt），让模型看到真实的 handler 和配置，而不是转述。
- 快速判断”这是不是瓶颈”： 快速档（GPT-5.5 Instant、Claude Sonnet 4.6）够用——但别让它凭空造瓶颈，先粘数据。
容易踩的坑
- 不测量就优化——猜瓶颈最浪费 sprint。
- 拿 Lighthouse 实验室分数给自己打分，而 Google 算的是 CrUX 字段数据、28 天、第 75 百分位。
- 因为老习惯只盯 FID 而忽略 INP；截至 2026 年 6 月，INP 是最难达标的 Core Web Vital。
- 抠 5ms 后端，3 秒 render-blocking 前端没人动。
- 加缓存不写失效，最后上线的是”数据 stale” bug，不是性能修复。
- 把首屏的 LCP 图片做成懒加载，LCP 反而变差。
- 没改前/改后度量，“性能工作”就只能停留在故事层面，没法证明。
常见问题
现在的 Core Web Vitals 阈值是多少？ 取真实访问第 75 百分位：LCP ≤ 2.5s、INP ≤ 200ms、CLS ≤ 0.1。三项都落在”良好”区间，这个 URL 才算通过。这是截至 2026 年 6 月 Google 公布的字段阈值。
为什么现在有 INP 题、却没有 FID 题？ INP（Interaction to Next Paint）在 2024 年 3 月 12 日取代 First Input Delay 成为 Core Web Vital。INP 衡量的是一次访问里所有交互的延迟，不只是第一次输入，而且它是多数网站至今仍过不了的那一项。
Lighthouse 显示 95，但 Search Console 说我不达标——哪个对？ Search Console。Lighthouse 是单台设备上的实验室模拟；Google 的过/不过用的是真实 Chrome 用户的 CrUX 字段数据，第 75 百分位、滚动 28 天。Lighthouse 用来调试，字段数据用来打分。
该往这些 Prompt 里粘代码还是粘数据？ 永远先粘数据。性能讲的是真实用户量到的东西，所以让模型推一份 Lighthouse 报告、一段 APM trace 或慢查询日志，才能给出有依据的答案；让它推一段代码描述，那就是在猜。
哪个 AI 模型最适合处理长性能 trace？ 带大上下文的推理档：Claude Opus 4.7 或 GPT-5.5（Thinking）。两者都支持 1M token 上下文，整份慢查询日志或 bundle 报告塞进去也不会被截断。