用 AI 智能体发现并修复性能问题

给它喂真实的性能剖析(Profiling)数据,而不是靠猜;先提出假设再动手修复;并且始终做"前后"对比测量——否则智能体只是把行为"优化"没了。

没有测量数据就找不到问题

一个只听到"应用很慢"这句话的智能体,和没有堆栈跟踪(Stacktrace)就去调试 bug 一样,只能靠猜。给它喂真实的性能剖析输出:计时数据、火焰图(Flamegraph)导出、带有运行时间的数据库查询日志。具体的数字才能显示时间到底花在了哪里——而不是"感觉上"花在了哪里。

和调试 bug 一样:先让它列出可能的原因,按预估影响排序,再有针对性地测试其中一个。没有事先提出假设就做的优化,往往会用错地方——做得很快,但没什么效果。

每次优化都需要在相同条件下,分别在改动前和改动后做一次基准测试(Benchmark)。没有对比数字,你就无法确定一次改动是否真的有效果——只能感觉它"好像更快了"。

小的改动(一个循环、一条查询)实现起来很快,但往往效果有限。最大的收益通常来自架构层面的决策:N+1 查询问题、不必要的重复计算、缺失的缓存。智能体应该把这两类都指出来——并告诉你哪一类的影响更大。

智能体可以通过直接砍掉工作来让程序"变快"——跳过某个校验、让缓存返回过时数据而不是最新数据、把某个结果直接硬编码。这在基准测试里看起来很不错,但其实是一个正确性 bug。每次性能改动之后,都要检查结果是否依然正确,而不只是检查速度是否变快。

示例

提示词:"这是 /api/search 的性能剖析导出文件(附件)。列出造成这 800 毫秒延迟最可能的三个原因,按预估影响排序。先不要做任何改动。之后用同一个基准测试命令做前后对比测量,并运行现有的测试套件。"

🛠️ 练习——自己动手试试

找一个故意写得很慢的函数(比如一个嵌套循环或一个 N+1 查询),让智能体系统性地对它进行优化。

✅ 自查清单

小测验

在使用 AI 辅助做性能优化时,你应该特别留意哪个陷阱?