SingClaw5 Why
- 为什么很多项目上线就翻车？因为测试不充分，隐藏的问题没暴露。
- 为什么隐藏问题难发现？因为它们只在特定条件下触发——边界情况、异常输入、依赖故障。
- 为什么虾适合做试探？因为虾可以快速构造各种边界条件和异常场景来"打草"。
- 为什么要提前暴露？因为问题在测试阶段发现的修复成本是上线后的 1/10。
- 为什么叫"惊蛇"？因为蛇（问题）藏在草（系统）里，你不打它不出来。
养虾36计 · 第十三计
打草惊蛇
在养虾语境里，打草惊蛇不是打草，而是用虾做一次小规模试探，把隐藏的问题提前暴露出来——与其等上线后翻车，不如先"打一下草"看看有没有蛇。
What
打草惊蛇，就是在正式上线或大规模执行前，让虾用各种边界条件做一轮试探。故意给异常输入、故意断依赖、故意加压力——看系统在什么条件下会出问题。
Detail What
- 边界测试：空输入、超长输入、格式错误、特殊字符——虾一个一个试。
- 依赖故障模拟：如果 API 超时了会怎样？如果数据源返回空了会怎样？
- 压力测试：连续调用 100 次、并发 10 个请求——在压力下哪里最先崩？
- 回归验证：每次改代码后重跑一遍所有"打草"用例，确认没引入新蛇。
- 蛇的记录：每发现一个问题就记录下来，形成"已知蛇清单"，持续维护。
So What
打草惊蛇的本质是主动寻找问题而不是被动等待问题。大多数人的习惯是"没出问题就是好的"——直到出了大问题。虾可以帮你持续、低成本地"打草"，把蛇在它还小的时候就惊出来。越早发现，修复成本越低。
How（举一反三）
- 列出你系统中最脆弱的 3 个环节（最容易出问题的地方）。
- 为每个环节设计 5 个"打草"用例——异常输入、依赖中断、极端条件。
- 让虾定期（每次部署后、每周一次）自动跑这些用例。
- 任何一个用例失败就生成告警，附带失败条件和错误信息。
- 维护"已知蛇清单"——哪些问题已修复、哪些是已知风险、哪些需要监控。
举一反三：新策略上线前让虾用历史数据回测"打草"；新模板上线前让虾用各种边界内容"打草"；新流程上线前让虾模拟各种异常场景"打草"。正式出手之前，先打一轮草。