用AI写接口测试，发现它特别喜欢走捷径。
不管业务多复杂，丢过来的一定是一大坨平铺直叙的脚本，或者curl。你让它用Hurl、JMeter这类有结构的声明式工具，它反倒经常给你整出语法错误。
一开始我还真琢磨，是不是干脆全用脚本凑合得了？但冷静下来想想，这事儿怪不到语言头上。根本原因是，如果没有明确的工程规范去约束，AI的默认行为就是“怎么快怎么来”，产出的必然是毫无结构、没法复用的一次性代码。一旦业务改了，这些测试比业务代码死得还快。
工具选型的纠结背后，其实是我们在AI时代对“测试工程化”的失控。
既然不能指望AI自由发挥，那就回到老路子，老老实实设计测试用例。等价类、边界值、CRUD矩阵，一套组合拳打下来，用例看着倒是挺丰满。
但跑完之后心里还是不踏实。传统清单是静态的，你能测出“传空值报500”，但你测不出“Redis挂了导致缓存击穿”，也测不出“MQ重复投递把表里的数据写重了”。想靠一份固定的测试清单去覆盖所有的动态时序、分布式异常，基本上是在刻舟求剑。
后来我顺手翻了下之前的代码审查清单，突然反应过来一件事：咱们平时的代码审查和自动化测试，其实是“两张皮”。
比如审查清单里明确写了“调外部接口必须加超时和熔断”，但写测试的时候，我们有针对“外部接口超时”写压测脚本去验证吗？大概率没有。审查只能靠人眼或者静态扫描去“看”，没有转化成可执行的代码去“证伪”。光审查不测试，等于光说不练；光测试不审查，等于盲人摸象。
想通这一层，思路就变了。我们需要的不是人工去一条条抠测试用例，而是一个翻译机制：把审查规则，自动“翻译”成测试代码。
顺着这个思路，其实可以搭一个轻量级的“风险规则引擎”。它的核心逻辑不再是传统的“扫代码找关键字”，而是基于上下文的必然推导：识别技术选型与业务场景 -> 映射对应领域的风险清单 -> 输出审查项 + 自动生成对应的测试脚本。
简单说，就是**“因为你用了X技术/做了Y功能，所以你必须审查Z，并且必须跑对应的测试”**。这套规则得按域来分：
- 技术组件层：识别到项目引入了Redis做缓存 -> 触发“穿透/击穿”风险清单 -> 输出审查提示（加布隆过滤器）+ 生成海量无效Key的Mock压测脚本。
- 架构层：识别到设计上涉及跨微服务的数据修改 -> 触发“分布式一致性”风险清单 -> 输出审查提示（对账/补偿机制）+ 生成模拟网络分区或下游宕机的混沌测试。
- 业务核心层：识别到链路涉及库存扣减或金额计算 -> 触发“资损/超卖”风险清单 -> 输出审查提示（分布式锁/事务校验）+ 生成高并发下的属性测试（无论怎么并发扣减，库存绝不能是负数，让框架去疯狂扰动）。
这套东西不需要一步到位搞个大系统。可以先把它做成AI Coding的上下文插件：需求阶段预检风险，写代码时作为约束提示，提PR时自动核对风险清单，CI流水线里直接把生成的测试跑一遍。
AI时代，写代码的成本越来越低，但“怎么保证写得对”的成本反而越来越高。与其纠结AI该用什么工具写测试，不如把精力花在梳理规则上。把审查和测试打通，让每一项技术选型和业务设计背后，都有对应的自动化脚本在死死兜底。这才是质量体系真正该有的样子。
