性能优化 Prompt：让 AI 像性能工程师一样定位瓶颈
把慢代码或慢查询粘进来并给出输入规模与耗时，AI 分析复杂度与瓶颈点，按「预期收益 / 风险」输出优化方案与改造后代码，附 before/after 基准对比。
发布 2026-06-21更新 2026-10-11核实 2026-10-11用法
把需要优化的代码粘进来。说明当前性能指标（耗时、内存）和目标。
什么时候用
- 已经有可复现的慢路径：能给出输入规模、耗时与内存，且能稳定复现。
- 瓶颈范围已经收窄到某个模块 / 某条查询：本模板的定位是定位与排序，不是全链路排查。
- 优化前需要和团队对齐「值不值得做」——按「预期收益 / 风险」排序的输出本身就是决策材料。
- 优化后要防回归：把 Before/After 基准固化成脚本，下次重构能立刻发现性能倒退。
什么时候别用
- 还没测过就让它优化——不给「当前表现」字段，AI 只能靠模式匹配猜，而真实瓶颈八成不在它猜的地方。先测，再来。
- 瓶颈在 I/O 与网络等待，但代码里看不出来（数据库锁、下游超时、磁盘争用）——这类要的是 profiling 与可观测性数据，不是代码改写。
- 性能问题其实是架构问题（单次请求拉全表、跨region调用）——局部优化改不动，得先动架构。
- 没有基准可复现——优化无法证伪，也无法防回归。先花 30 分钟写个可复现基准，再花 3 小时优化。
Prompt
你是一个性能优化专家。请分析以下代码的性能问题，并给出优化方案。
## 代码
{{粘贴代码}}
## 当前表现
- 输入规模：{{比如 10 万条数据}}
- 耗时：{{比如 15 秒}}
- 内存：{{比如 2GB}}
- 目标：{{比如 1 秒内完成}}
## 分析要求
1. **复杂度分析**
- 时间复杂度（大 O 表示）
- 空间复杂度
- 瓶颈在哪里（哪一行/哪个循环）
2. **优化方案**
- 按优先级排序（收益最大的排前面）
- 每个方案说明预期效果（时间/空间）
- 给出优化后的完整代码
3. **权衡说明**
- 优化后是否有 trade-off（可读性、内存换时间等）
- 是否需要额外依赖
## 输出格式
### 复杂度分析
- 当前：O(???)
- 瓶颈：第 X 行的 YYY 循环
### 优化方案
#### 方案 1：{{方案名}}（推荐）
- 预期效果：耗时从 15s → 0.8s
- 原理：...
- 代码：
```{{语言}}
// 优化后的代码
```
#### 方案 2：{{方案名}}（备选）
- ...
### Before / After 对比
| 指标 | 优化前 | 优化后 | 提升 |
|---|---|---|---|
### 注意事项
- 优化后需要更新的测试
- 需要注意的 edge case
常见优化模式
AI 会检查以下常见性能问题：
- O(n²) 循环 → 哈希表降为 O(n)
- N+1 查询 → JOIN 或批量查询
- 递归无记忆化 → 加 memo/cache
- 不必要的全量加载 → 分页/懒加载
- 字符串拼接 → 用 StringBuilder / join
- 重复计算 → 预计算 + 缓存
- 同步阻塞 → 异步/并发
为什么有效
- 先要测量再要优化：不给「当前表现」字段时，AI 会凭模式匹配猜瓶颈，而真实瓶颈八成不在它猜的地方。
- 要求按「预期收益 / 风险」排序：优化是排序问题不是枚举问题——列 10 个方案但排第一的那个收益只有 2%，等于白做。
- 强制给出验证方法：没有基准复现步骤的优化无法证伪，也无法在下次重构时防回归。
验收判据：怎么判断它给的优化方案能用
没有数字的方案一律打回。 看这六条：
| # | 判据 | 不合格的典型表现 |
|---|---|---|
| 1 | 瓶颈点定位到具体行 / 具体查询 | 只写「循环太多」「建议加缓存」，不给行号与查询 |
| 2 | 给出复杂度分析（优化前后） | 只有「会更快」，没有 O(?) → O(?) |
| 3 | 预期效果带数字 | 写「显著提升」而不写「15s → 0.8s」 |
| 4 | 方案按收益排序 | 列了 10 个方案但排第一的收益只有 2% |
| 5 | 明确写出 trade-off | 只说好处不说代价（内存换时间、可读性下降、新增依赖） |
| 6 | 给出可执行的复现与验证步骤 | 没有基准命令，「快没快」全靠感觉 |
最容易被忽略的是第 5 条。 性能优化本质上是用一种资源换另一种资源：缓存用空间换时间、异步用复杂度换吞吐、批量化用延迟换总量。只讲收益不讲代价的方案，通常在生产上会变成新的事故源（典型：加缓存后忘了失效策略，读到脏数据）。
验收的最后一关是「优化后行为是否不变」——性能改动最容易夹带逻辑变更。建议把本模板的输出再过一遍 安全重构 Prompt，确认外部行为没被顺手改掉。
变体 A / B / C
A · 只诊断不动手（评审用） —— 把「分析要求」第 2 条换成：
2. 只输出诊断与排序，不要给出优化后的完整代码。
每个方案必须标注：预期收益（数字）、实施成本（人日）、风险等级（low/mid/high）。
B · 慢查询专用（贴执行计划） —— 在「当前表现」里追加：
- EXPLAIN / EXPLAIN ANALYZE 输出：
{{粘贴真实执行计划，不要省略行数与耗时}}
B 是最值得用的变体。 让 AI 对着真实的执行计划分析，远比让它读 SQL 文本猜准——
rows估算与实际行数的偏差、Seq Scan还是Index Scan、有没有Sort溢出到磁盘，这些只有执行计划里有。配合 Cursor + MCP 操作数据库 可直接取到真实 EXPLAIN。
C · 前端 / 渲染性能专用 —— 把「当前表现」换成：
- 指标：LCP / INP / CLS 当前值与目标值
- 复现路径：{{URL + 操作步骤 + 设备 / 网络节流条件}}
- 已有 trace：{{Performance 面板或 Lighthouse 的关键节点}}
进阶（自动化）
把优化前后的基准固化成脚本，避免「我感觉快了」：
# 用 hyperfine 量化，结果进 CI artifact
hyperfine --warmup 3 --runs 20 "node bench/checkout.js" --export-json bench/before.json
# 改动后重跑并对比
node scripts/compare-bench.mjs bench/before.json bench/after.json
反例（AI 默认会写的烂版本）
默认输出：「建议加缓存」「可以用 Redis」「考虑异步化」——三条都对，但不知道加在哪、加完能快多少。
加了 prompt 之后：checkout.js:118 的 N+1 查询（每个订单一次 SELECT items），改为批量 IN 查询，本地 200 单基准从 1.8s → 240ms；风险：单次 SQL 变长，需确认 items.id 有索引。
延伸阅读
- SQL 查询生成 Prompt — N+1 查询和索引优化最常见
- 安全重构 Prompt — 优化后保证行为不变
- Cursor + MCP 操作数据库 — 让 AI 看真实 EXPLAIN 计划定位慢查询