AI 怎么做性能测试呢?

最近跟同行聊天，发现大家一提到“AI + 性能测试”，第一反应往往是：能不能让 AI 帮我自动写脚本、自动发压？

说实话，这个方向我也想过。

折腾了一圈 AI 之后，想和和大家分享一点的是：AI 在性能测试里最核心的价值，绝非替代工具去发压，而是当你的“全链路排查军师”。

1. 为什么说发压这事，轮不到 AI 来做？

压测最怕的是什么？最怕不确定性。

你说压 1000 并发，就得稳稳当当压 1000 并发。这种纯体力、要求极度精准的活，是传统工具的死穴和强项。像大家常用的 k6、JMeter 或者线上引流用的 GoReplay，人家写死了底层逻辑，指哪打哪，稳如老狗。

要是让 AI 来发发看？大模型本质上是个概率模型，脾气阴晴不定，其生成的请求带有随机性。这种不确定性在性能测试里就是风险。

所以，让传统工具去干脏活累活（制造压力），让 AI 来干烧脑的活（分析瓶颈），才是正道。

做过压测的都知道，最痛苦的永远不是把压力打上去的那一刻，而是系统崩溃或变慢之后：接口响应响应时间（RT）飙升，网关开始报 504。这时候你得像个猴子一样在好几个系统之间切来切去——看 Grafana 曲线、跳到云控制台看数据库 IOPS、去服务器抓应用日志，顺便还要确认压测机自己是不是先熔断了。

这一套折腾下来不仅头大，最惨的是还容易产生“误判”。比如看到数据库连接超时，很多人第一反应就是：“完蛋，数据库被打满了，加配置吧！”结果花大价钱加了配置，复压还是挂。最后发现，根本不是数据库的问题，而是下游某个微服务的线程池满了，或者是 Linux 的文件句柄数（ulimit）没调对。

这种“跨系统看图、连串证据、破案”的过程，才是 AI 真正的本领所在。

很多人试过把截图和日志发给 AI，结果 AI 只能回复一堆“正确的废话”，比如：“我看你 CPU 有点高，建议优化一下”。这在生产环境毫无用处。

想要 AI 给出硬核答案，核心不是给它自由，而是“约束它”。我们在设计性能分析 Skill（技能提示词）的时候，必须死死卡住它：

现在行业里，已经有团队把“压测”和“AI 诊断”缝合在一起了。如果你想直接上手研究或者抄作业，可以参考这几个垂直领域的开源硬货：

这个开源项目直接把 AI 注入到了压测链路里。它不只干看图的事，而是直接对接了 JMeter 等引擎。它的 Skill 核心是“动态调压与实时根因建议”。它会一边看着压测的 TPS 曲线，一边用 AI 模型计算下一次应该加压多少，并在系统扛不住时，直接吐出具体的性能瓶颈定位。

在 Kubernetes 分布式环境里，Keptn 引入了自动化性能评价（Quality Gates）。它的 Skill 能够自动分析压测前后的 Prometheus 指标变化，不需要人肉去比对。通过声明式的配置，AI 会自动给出当前版本的性能表现是“通过”、“警告”还是“拒绝”。

老牌 APM 引入了针对追踪（Tracing）和性能指标的 AI 异常检测 Skill。在大流量压测时，它的 AI 组件会实时学习指标的基线（Baseline），一旦由于压测导致某个微服务调用拓扑中的 RT 异常突刺，AI 会自动标记并输出根因分析报告，直接告诉你哪条 Trace 变慢了。

如果你不想改动现有系统，可以用 Playwright 写个脚本，在压测结束时自动登录 Grafana 截图，再把图丢给视觉大模型（如 GPT-4o 或 Claude 3.5 Sonnet）。这种低侵入方式对老系统极度友好，虽然偶尔会看错坐标轴，但用来自动化生成“复盘报告草稿”非常高效。

AI 在性能测试里的真正价值，不是让我们变懒，更不是一键搞定所有事。

最靠谱的落地姿势依然是：