关注 霍格沃兹软件测试开发 公众号，回复「资料」, 领取人工智能测试开发技术合集
一个真实的“AI压测翻车”复盘，血的教训换来的8条铁律
2026年7月16日，上午10:23。
我盯着Grafana面板上那条直线往下砸的CPU曲线，手里的美式咖啡差点洒在键盘上。
“所有服务全部超时，登录和支付模块同时挂了。”
运维老张在群里艾特我的时候，我正悠哉悠哉地看昨天跑完的自动化测试报告。我心里还想着，这AI Agent真他娘的好用，一晚上把回归用例全跑完了，还顺手帮我生成了测试数据。
然后我就笑不出来了。
故障持续了整整7个小时。
原因？我让AI同时测了登录和支付。
今天这篇文章，我不跟你扯什么高大上的“AI驱动测试”、“智能体工作流”。我就老老实实复盘一下，我是怎么把公司服务器搞崩的，以及你该怎么避免踩这个坑。
先说结论，你可能不信
很多人觉得AI跑测试，无非就是替代手工点鼠标，或者替代写代码。
大错特错。
AI Agent跑测试，相当于你同时雇了100个刚毕业的实习生，而且这100个人完全不沟通，各干各的，还都觉得自己特别聪明。
我这次翻车，就是栽在这三个字上：
并发、数据、锁。
事情是怎么发生的？
我们团队上个月刚把WorkBuddy和Hermes Agent接进来。说实话，一开始确实爽。
你只要说一句“帮我测一下登录功能”，WorkBuddy就会调起Hermes Agent，自动拆解任务、生成用例、执行脚本、输出报告。我这种干了七八年测试的老油条，头一回觉得“明天可能要失业”。
然后就飘了。
那天我寻思着，既然登录能测，支付也能测，那为什么不一起测呢？
我对着WorkBuddy说了一句：
“帮我并行执行登录模块和支付模块的全量回归测试，越快越好。”
AI很听话。
太听话了。
翻车全过程复盘
第一阶段：蜜糖期（上午10:00-10:15）
AI同时起了20个并发线程跑登录，又起了20个并发线程跑支付。
登录和支付共用一套用户体系，这是第一个雷。
AI很聪明地自动生成了1000个测试账号，然后用这些账号同时去做两件事：
- 登录用例里：登录、登出、刷新token
- 支付用例里：下单、支付、查询订单
问题出在哪？
登录用例跑完一个账号，会把这个账号的token刷新一遍。支付用例跑着跑着，突然发现token失效了，于是自动重试登录。
重试登录又触发了登录模块的防暴力破解机制——同一个IP一秒钟发了200次登录请求。
WAF直接给我封了。
第二阶段：崩溃期（上午10:16-10:30）
WAF封禁的瞬间，登录模块开始返回503。
AI检测到异常，自动启动了“重试+降级”策略——这是Hermes内置的容错机制，本来是好事。
但它降级的方式是：用更短的间隔重试。
好家伙，本来一秒200次，现在一秒冲进去500次。
同时，支付模块里的订单状态机被搞乱了。一个账号在10秒内同时发起了3笔支付，但登录token已经被刷新了两次，导致支付回调的时候带的是旧token。
订单系统的分布式锁直接被打爆。
Redis连接数飙升到8000+，连接池耗尽。
然后就是连锁反应：
支付挂了 → 订单回调超时 → 消息队列积压 → 消费者线程全被阻塞 → 应用服务器线程池满 → 健康检查失败 → K8s自动重启Pod
Pod刚起来，又被AI的流量冲垮。
一天重启了47次。
第三阶段：排查期（上午10:30-下午2:00）
这期间我干了三件事：
- 先停了所有AI测试任务——结果发现停不掉，因为任务已经下发到Hermes的执行队列里了，WorkBuddy只是下发指令的，不负责中断。
- 手动把Hermes的进程kill了——世界安静了。
- 开始看日志。
日志里最扎眼的一条：
[WARN] Hermes Agent: Task "login_regression" and "payment_regression"
share same test data pool. Potential data contention detected.
AI自己都检测到数据竞争了，但它没有停下来，而是选择“尽力执行”。
这不能怪AI。是我给它配的Prompt里有这么一句：
“遇到问题时，尝试自动修复并继续执行。”
“自动修复”的意思是——绕过问题，而不是解决问题。
于是AI的“修复”方案是：跳过token校验，直接用session_id硬怼。
结果就是一堆脏数据写进了订单表。
技术深挖：为什么登录和支付不能一起测？
你可能觉得，不就是两个模块并行跑吗？Jenkins上不也经常并行跑任务？
区别在于：AI是“自适应”的。
普通的自动化脚本，每一步都是写死的。登录脚本就是登录脚本，支付脚本就是支付脚本，它们不会“越界”。
但AI Agent会。
Hermes在执行支付用例时发现token过期，它会自动生成一段代码去重新获取token。获取完token之后，它还会“好心”地把这个新token更新到公共数据池里，方便其他任务复用。
问题来了：登录模块那边正在用旧token跑用例，突然发现数据池里的token变了，于是它也自动去刷新了一遍。
两个Agent在互相抢数据池的控制权。
这就像两个人在同一个白板上写字，A写了1，B擦掉改成2，A发现不对又改回1，B又改回2……
最终结果是白板花了，谁都看不清。
我是怎么解决的（临时方案）
下午2点，我做了这几个操作：
1. 数据池隔离
给登录和支付各自分配独立的测试数据池，账号不共用。登录用账号段10001-11000，支付用20001-21000。
2. 关闭AI的自动修复能力
在WorkBuddy的Prompt里加了硬约束：
“检测到异常时，立即暂停任务并通知人工，禁止自动重试。”
3. 限流
在API网关层对测试流量做了限流，测试来源IP每秒最多100个请求，超过的直接返回429。
4. 手动清理脏数据
写了条SQL把订单表里今天10点以后status=0且金额为0的记录全删了——一共删了3700多条。
做完这些，服务在下午2:30左右恢复。
但彻底恢复稳定，一直等到下午5点多——因为消息队列里的积压消息，消费者跑了将近3个小时才消化完。
复盘：8条血的教训
这次事故之后，我给自己和团队立了8条规矩。希望你用不上，但最好存一下：
1. 永远不要让AI同时操作“共享状态”的模块
登录和支付共用了用户token，这就是共享状态。共享状态必须有隔离，否则AI的“智能”会放大冲突。
做法：每个测试任务分配独立的数据空间，互不干扰。
2. AI的“自动修复”能力要分级开放
不是所有场景都适合自动修复。我现在的分级：
- 网络超时 → 允许重试（最多3次）
- 数据异常 → 立即暂停，通知人工
- 接口报错 → 记录日志，继续执行其他用例
- 性能瓶颈 → 自动降级（降低并发数）
3. 测试数据要“染色”
每个AI生成的测试数据，都要带上任务ID的标签。这样出问题了能快速定位是哪条指令产生的数据，也方便回滚清理。
4. AI测试任务必须有“熔断器”
我现在的配置：
- 错误率超过10% → 自动暂停
- 单接口响应时间超过3秒 → 自动降并发
- Pod重启超过3次/10分钟 → 全局暂停所有AI任务
5. 永远保留“手动kill”的通道
WorkBuddy和Hermes再方便，也要有一个不依赖任何AI组件的紧急停机按钮。我现在的方案是写了一个Shell脚本放在跳板机上，执行就是pkill -f hermes，简单粗暴但有效。
6. 压测环境和生产环境必须彻底隔离
这次最惊险的是——测试流量差点打穿了生产环境的Redis，因为测试环境的Redis和生产共用了一个实例（只是DB不同）。
现在我已经把测试环境的Redis、MySQL、MQ全部独立部署，连网络都做了VPC隔离。
7. AI生成的测试代码要经过“静态审查”
我加了一条规矩：所有AI生成的测试脚本，在正式执行前必须先过我的人工审查。
不追求100%覆盖，但至少要看一眼它要调用哪些接口、生成多少数据、并发度是多少。
这次教训是：我没看就让它跑了。
8. 给AI设置“业务安全边界”
有些操作AI永远不能做：
- 不能调用真实的支付接口（只能用Mock）
- 不能往生产库写数据
- 不能修改线上配置
- 不能发真实的短信/邮件
这些我现在写进了WorkBuddy的System Prompt里，硬约束。
最后说几句心里话
我不是来黑AI的。
恰恰相反，我现在依然每天在用WorkBuddy和Hermes。它们帮我节省的时间，比我手动写脚本不知道快了多少倍。
但工具越强，使用工具的人责任越大。
AI Agent不是魔法棒。它不会自动理解“登录和支付共用一个token池会死锁”这种业务层面的隐式约束。
它会做的事情是：你让它做什么，它就拼尽全力去做，哪怕是把你服务器搞崩。
所以关键不在于要不要用AI，而在于——
你怎么给它画边界，怎么给它设规矩，怎么在它失控的时候能一秒摁住它。
这就是我们这一代测试开发工程师的新课题。
别让你的AI，成为下一个“把服务器搞宕机一整天的凶手”。
这是我的真实经历改编。如果你也在用AI Agent做测试自动化，欢迎加我微信一起交流踩坑经验。
本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。
推荐阅读：在 OpenCode 中接入本地模型：Ollama 部署与配置完全指南OpenCode 这玩意儿最近挺火。GitHub - 掘金
