“为啥应用慢”是性能问题里最糟的提问。好的回归 Prompt 要点出指标（p50 / p99 / TTFB / LCP）、diff 窗口，禁止猜测——只要 file:line 证据和 benchmark 数。
适合哪些场景
处理性能告警的值班、追慢 PR 的 lead、上线前要过 Core Web Vitals 的独立开发。
什么时候不建议这样写 Prompt
没有 baseline 数字别用。“慢”没数据浪费所有人时间。也别用 dev 环境性能下结论——要测生产。
Prompt 结构公式
每个性能回归 Prompt 都要带这六个要素：
- 角色：AI 扮演谁（SRE / Release Captain / staff 工程师 / QA Lead）。
- 上下文：技术栈 / 分支 / 失败日志 / diff / dashboard URL。
- 目标：一个具体可交付物——根因、checklist、计划、ticket 列表、runbook。
- 限制：AI 不能做什么（别自动修、别瞎造文件路径）。
- 输出格式：编号清单、markdown 表格、JSON、unified diff、可运行代码。
- 示例 / 信号：1-2 条”好输出”示例，或反例。
这套 Prompt 适合用在哪
- diff 窗口 p99 回归 triage
- 单 PR 的 bundle size 回归
- 慢接口里的 N+1 排查
- React render storm
- DB 查询计划变化
12 个可直接复制的 Prompt 模板
1. p99 diff triage
p99 latency on `{endpoint}` jumped {fromMs}ms → {toMs}ms between `{oldSha}` and `{newSha}`. List 5 likely causes in priority order. For each: (a) suspicion strength, (b) one file:line or query to inspect, (c) one cheap check. Don't propose fixes yet.可替换变量： endpoint, fromMs, toMs, oldSha, newSha
2. PR 性能风险扫描
Scan this PR diff for perf risks: (1) New synchronous I/O in hot path, (2) Loops calling DB / fetch inside, (3) New large dep imported eagerly, (4) React re-render expansion (new context, unstable deps), (5) Missing index for new query. file:line + severity.3. N+1 猎人
In the function `{functionName}` at `{filePath}`, identify N+1 patterns: (a) Loops calling DB / fetch, (b) Promise.all over single-item fetches, (c) Recursive accessors hitting ORM lazy fields. For each: rewrite as a single batched call, with code.可替换变量： functionName, filePath
4. bundle size 回归
Bundle grew from {oldKb} → {newKb} KB. Identify the top 3 contributors: (1) New direct deps and their size, (2) Tree-shake failures (default imports from a library that ships ESM), (3) Polyfill bloat (target browser change?). Output: a fix per item.可替换变量： oldKb, newKb
5. React render storm 诊断
Component `{component}` re-renders {nRenders} times per interaction. Diagnose: (1) Unstable prop identity (objects / arrays created in render), (2) Context provider value not memoized, (3) Parent state too coarse, (4) useEffect dep that changes each render. Output: cause + minimal fix.可替换变量： component, nRenders
6. DB query plan 回归
Query plan for `{query}` changed: was index seek + nested loop, now is sequential scan + hash join. Diagnose: (1) Statistics stale (ANALYZE recently?), (2) Cardinality estimate off, (3) New column / index hint mismatch, (4) Parameter sniffing. Output: most likely + ANALYZE / pg_stat_user_indexes command to confirm.可替换变量： query
7. 冷启动回归
Serverless function `{fnName}` cold start went {fromMs} → {toMs} ms. Diagnose: (1) Bundle size grew, (2) New top-level imports, (3) New connection at boot, (4) New env var fetch. Output: top 3 by likelihood + a 5-min experiment.可替换变量： fnName, fromMs, toMs
8. TTFB / LCP 回归
LCP on `{pagePath}` went {fromMs} → {toMs} ms. Walk the waterfall: (1) Server response time, (2) Critical CSS / JS blocking, (3) Image / font payload, (4) Layout shift forcing re-render. Pick the dominant cause.可替换变量： pagePath, fromMs, toMs
9. 内存增长回归
Service RSS grew from {oldMb} → {newMb} MB. Diagnose: (1) New cache without eviction, (2) Closures retaining large objects, (3) Listener leaks (no removeListener on unmount / restart), (4) Buffer pools sized too large. file:line.可替换变量： oldMb, newMb
10. 慢测试回归
Test suite went from {fromMin} → {toMin} min. Identify: (1) Specific test files that grew, (2) Setup / teardown bloat, (3) Real timer / sleep introduced, (4) Parallelism reduction. Output: 3 specific cleanups.可替换变量： fromMin, toMin
11. 性能修复 benchmark 计划
Before fixing, design a benchmark: (1) Minimal reproducible scenario, (2) Metric (median + p99), (3) Sample size, (4) Baseline run command. After fix, re-run same benchmark. Don't fix without baseline numbers.12. “慢但能接受”决策
A regression is real but small ({deltaMs}ms). Decide: (1) Is the absolute number above target? (2) Is the user impact measurable (conversion / bounce)? (3) Is the fix more expensive than the regression? Output: SHIP / FIX / REVERT + one-line rationale.可替换变量： deltaMs
容易踩的坑
- 没 baseline 就开始优化。
- p50 / p99 不分——修法完全不同。
- 相信 dev 环境性能——线上热路径完全不同。
- N+1 没修就先加缓存。
- bundle split 之前不量哪些是 preload / lazy。
- React 一切都 memo——开销反而增加。
- 读 deploy diff 之前就开查——回归多半是代码不是基建。
优化技巧
- 永远锚定到 指标 + 样本数 + diff 窗口。
- p99 修法和 p50 不同，分开处理。
- React 用 Profiler trace，别靠 log 猜。
- DB 用
EXPLAIN ANALYZE抓修改前后 plan。 - benchmark 至少跑 3 次，方差能藏住回归。
- 缓存是最后手段，不是首选。
- 回归和修复都写进复盘，下个人才不会再踩。
实操加深
使用这些 prompt 时，不要只替换一个主题词就直接交付。围绕「性能回归审计 Prompt：12 个 p99 急救模板」先补齐受众、渠道、长度、语气、参考样例、禁止样式和成功标准，再让模型输出 2 个不同版本做横向比较。好的结果应该能被另一个人直接复用，而不是只有顺滑但空泛的表达。
如果输出看起来像通用模板，下一轮要增加一个真实场景、一个反例和一个可检查指标，例如点击率、转化动作、字数、平台限制或品牌禁区。这样改出来的内容才更像可用资产，而不是一次性的灵感草稿。
FAQ
- 回归多大才值得管？: 推到 p99 超 SLO 就要管。低于 SLO 看修复成本。
- 上线前要彻底优化吗？: 达到 Core Web Vitals 目标就发，过早过度优化浪费时间。
- React.memo 总是安全的吗？: 不是——props 不稳定（对象 / 数组 / 回调）时反而更慢。
- 怎么找 DB 索引缺口？:
pg_stat_user_indexes看无用索引，pg_stat_user_tables看顺序扫描多的表。 - AI 能读火焰图吗？: 能读文本 trace 和 profiler JSON；图形火焰图需要 vision 模型。
- 什么时候上 perf budget CI gate？: 同一种回归到过生产两次后。之前手动检查够用。