用 AI 做性能优化方案：先测量再优化

性能优化里常见的弯路是凭直觉猜瓶颈：花两周优化了一个只占 3% 耗时的模块，整体几乎没动。AI 能帮你把测量数据变成有优先级的方案，但它替代不了测量本身——先测量再优化，这个顺序不能反。顺序一反，后面所有动作都是在给猜想找证据。

测量排在优化前面

动手之前先回答三个问题：慢在哪一段、慢多少、和什么条件相关。端到端耗时分布，把整个链路拆开看各段各占多少；调用链追踪，定位到具体的函数或查询；条件对比，弄清是数据量大时慢、并发高时慢，还是特定请求慢。

这三个答案凑齐了，优化目标才算具体；缺了任何一个，后面所有方案都是在猜。AI 在这一步的角色是帮你设计测量：告诉它系统结构和怀疑点，让它列出该在哪些位置计时、该对比哪些条件，比一个人闷头想周全。测量数据本身也可以交给它做初步分析，把耗时分布整理成直观的占比表。

方案怎么排优先级

一个实用的排序式子：性能回报 × 把握 ÷ 改动成本。性能回报是这段占整体多少、优化空间有多大；把握是改了一定有效，还是只是可能有用；成本是改动范围、回归风险、需要的验证时间。

把候选方案逐项打分排序，排在前面的通常是收益明确、改动小的那几项，而不是听起来技术含量高的那个。让 AI 做这个排序时，要求它对每一项给出「为什么排在这里」的理由，理由站不住的方案直接淘汰。它顺口提到的方案，如果对应的测量数据不存在，一律标为「未验证」单独放。

一条能直接用的提示词

我的系统在{场景}下出现性能问题。已知的耗时分布是{分布数据}，调用链热点是{热点}，触发条件是{条件}。请帮我：一、按性能回报和改动成本排出优化优先级；二、为每一项说明预期性能回报和验证方式；三、指出哪些优化可能带来新的风险；四、列出我还缺少哪些测量数据。只基于我提供的信息分析，缺数据的地方直接标出来，不要推测。

末尾那句是关键。性能问题上 AI 容易犯的错，是在数据不足时给出看似完整的归因，把你的注意力带偏。让它承认「这里缺数据」，比让它硬给一个结论有用。

对比和验证的纪律

优化前后要用同一套基准对比，否则说不清到底有没有变快。每次只改一处，同时改多处就分不清哪一项起了作用。每次改动和数据都记录下来，有些优化只在特定条件下有效，换个场景可能失效。

让 AI 参与验证也有办法：把改动前后的两份基准数据都喂给它，让它标出差异和可疑点。人眼看耗时曲线容易忽略长尾，逐条对比能发现那些「平均值变好、尾部变差」的改动——这类优化对个别用户是灾难，只看均值会漏掉。

常见瓶颈的测量对照

这张表的用法：先按现象对号入座选测量手段，拿到数据再决定要不要往优化方向走，顺序不要倒。

它接不住的部分

AI 看不到你的运行时环境。缓存命中率、锁竞争、磁盘 IO，这些只有真实监控才有的信息它一概不知道，你给的数据里没有的瓶颈它发现不了。反过来，它也可能把相关性当因果：某段代码耗时高，未必是它慢，可能是上游传进来的数据就有问题。归因要靠你对系统的理解，AI 负责把归因过程组织清楚。写归因分析这件事有专门的方法，售后数据的分群归因思路可以直接搬到性能数据上。

性能优化速查

• 先测量再优化，顺序不能反
• 三个问题：慢在哪、慢多少、什么条件下慢
• 优先级 = 收益 × 把握 ÷ 改动成本
• 每次只改一处，同一套基准对比
• 缺数据时让它标出来，不许推测

三个常被问到的问题

• 没有链路追踪系统的小项目怎么办？：从日志加时间戳开始。在怀疑的函数前后记录耗时，跑几个典型请求，汇总数据再分析。粗糙的测量也比不测强，方向对了再上正规工具。
• AI 给的建议听起来都对，怎么取舍？：只看两点：改动范围有多大，验证成本有多高。两项都小的先做，做完用数据说话，有效保留，无效回滚，不要一次采纳一串建议。
• 平均值变快但偶尔有请求特别慢，算成功吗？：不算完成。长尾延迟往往指向另一类问题，比如锁竞争或缓存集中失效。把慢请求单独拉出来分析，均值和长尾要分开看。

这套流程跑通之后，数据还有别的用处：把一段时间的优化记录交给 AI 做复盘，数据与选题的总结法里的复盘结构可以参考；要向管理层汇报优化成果，给合伙人的年度经营总结那篇的汇报结构同样适用。