性能优化 Prompt：让 AI 像性能工程师一样定位瓶颈

用法

把需要优化的代码粘进来。说明当前性能指标（耗时、内存）和目标。

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%，等于白做。
• 强制给出验证方法：没有基准复现步骤的优化无法证伪，也无法在下次重构时防回归。

进阶（自动化）

把优化前后的基准固化成脚本，避免「我感觉快了」：

# 用 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 计划定位慢查询