AI 生成测试用例的四阶进化：从 Prompt 工程到自进化
我们内部有个 AI 生成测试用例的小工具，是去年 QA 同学用 prompt 攒出来的。演示很惊艳，实际用起来大家的评价出奇一致：「生成的用例没错，但太泛，不如自己写。」它就这么不温不火地挂着，用的人越来越少。
最近研究了快手 KATE 的公开分享（AiDD 大会，他们研发 Agent 负责人讲的），一个「AI 生成测试用例」系统从 8% 生成率做到 70% 的完整历程。对照之下我瞬间明白我们的工具卡在哪了——而且更有价值的是，这条演进路径明显不只适用于测试用例，任何「生成型 Agent 产品」都会按同样的顺序撞墙。这篇把地图画出来。
他们对问题的定义就赢了一半
先看起点。多数团队（包括我们）做这类工具的动机是「AI 能写用例，省人力」。KATE 团队先掰开了数据：用例编写只占 QA 工时的 13%，执行占 38%——按直觉该先自动化执行。但他们继续往下挖，挖到了真瓶颈：资深 QA 和新手写的用例质量差 10 倍，本质是业务知识私有化，没沉淀成团队资产；历史缺陷的知识无法复用，同一个坑不同人反复踩。
所以他们真正立项要解的不是「写用例太慢」，是「用例质量依赖个人经验且经验不流动」。这个定义直接决定了后面 V3 的方向。产品失败的一半原因是解错了题,而解错题在立项那天就注定了。
四个版本的撞墙史
V1.0，Prompt 工程，生成率 8%。Few-shot 示例、场景化模板、输出强约束——所有你能想到的 prompt 技巧全用上，单 Agent 无外部工具。三面墙：长 PRD 理解衰减（超过 30K token 明显变差）、隐含业务规则缺失（PRD 里不会写「支付渠道 X 有并发限制」）、生成过程黑盒。我们的内部工具就停在这一阶。事后看,V1 失败的根源不是模型不行，是用单 Agent 一步吃下「PRD → 用例」全流程这个架构假设不成立。
V2.0，Multi-Agent 协作，生成率 15%，采纳率 55%。思路转变：不再让 AI 一步到位，而是复刻 QA 的真实工作结构——拆成需求分析、用例生成、Review 三个专用 Agent，加一个人工反馈环。生成率近翻倍。但新墙出现了：用例「正确但浅显」。结构对、覆盖了明面需求，就是抓不住那些真正会出 bug 的角落。
这面墙特别值得琢磨，因为它暴露了一个普遍误判：大家以为流程拆细了质量自然上去，实际上流程解决的是错误率，解决不了深度。深度的瓶颈在下一阶。
V3.0，知识工程，生成率 35%，采纳率 65%。关键一跃。体系化地给系统喂四类知识：PRD 等文本物料；原型图流程图等多模态物料；历史用例和历史缺陷（RAG 召回）——这条是灵魂，生成「支付」用例时自动检索出「支付并发扣款缺陷」的历史记录注入上下文，引导补齐对应测试点；以及业务私域知识，170 多个由业务方维护的规则模板。
看效果指标就知道这一跃的含金量：历史缺陷覆盖率从 12% 干到 76%，四项指标里增幅最大。整个案例最核心的判断也在这一阶成型——生成质量的上限由知识丰富度决定，而非 Prompt 精妙程度。V1、V2 优化的都是「怎么说」，V3 才补上「知道什么」。
V4.0，Agentic 自进化，生成率 70%。三条线：ReAct 自主决策循环；Review-Critique 自动评审——把人工 review 结构化成多维度反馈（覆盖完整性、场景完整性、步骤清晰度……）而不是 Yes/No；以及最精彩的 BadCase 规则库自进化：低质量产出被收集 → 提炼「为什么不好」的模式入库 → 同类场景自动召回纠正 → 单点规则聚合成通用规范。场景规则的维护周期从天级压到 5 分钟。全公司推广后累计生成用例 120 万条。
读过我 Loop Engineering 那篇的会认出来，BadCase 闭环就是那套「低质量产出变成下一轮燃料」的机制在垂直领域的实装。
对照完，我们的工具该怎么救
对照四阶诊断我们自己：卡在 V1 和 V2 之间——「正确但太泛」正是缺知识的标准症状。而我们此前的改进方向一直是继续雕 prompt，等于把 V3 的病当 V1 治，无用功。
所以救法清晰了：别动 prompt 了，先做知识资产化。我们领域里对应「历史缺陷库」的东西是什么？现成就有——bug 系统里几年的缺陷记录、线上事故复盘、客服工单里的问题模式。它们一直躺在那,只是从没被接进生成链路。这个改造已经排进下季度了，做完再来汇报效果。
顺手给不同领域的同行翻译一下「你的历史缺陷库是什么」：做客服 Agent 的，是历史工单和差评对话；做 SQL 生成的，是慢查询档案和错误查询集；做代码生成的，是 code review 意见和事故复盘。每个生成型产品都有自己的「缺陷考古层」，挖不挖，就是 35% 和 15% 的差距。
把 V3 搬回家的三个动作
「做知识工程」四个字说来容易，落到我们下季度的改造计划里，具体是三个动作，可能对同样卡在 V2 的团队有参考价值：
第一，先盘点再建设。把散落的知识源列清单：bug 系统（六年、约两万条记录）、线上事故复盘文档（一百多篇）、客服工单的问题分类。盘点时按「结构化程度 × 与生成场景的相关性」排优先级——bug 记录结构最好、相关性最高，第一期只做它，事故复盘第二期。贪多是这类项目最常见的死法。
第二，清洗比接入费劲，预算要倒着放。试点时抽了三百条 bug 记录人工看，能直接用的不到一半：大量记录只写了现象没写根因，还有些「已修复」的描述和实际修复对不上。我们的预算分配最后是清洗七成、检索链路三成——和直觉相反，但检索一堆脏数据只会更快地污染生成结果，KATE 案例里「历史缺陷覆盖 +533%」的前提是他们的缺陷库是有人维护的。
第三，从一个模块试起，用采纳率说话。全量铺开之前，选一个 bug 记录质量最好的模块做对照实验：同一批需求，接知识库和不接各生成一轮，让 QA 盲评采纳率。这个数字拿去说服团队扩大投入，比任何方法论布道都管用——V2 到 V3 的价值，得让它自己长在自家数据上。
一张诊断表
把四阶撞墙史压缩成一张自查表，收藏这个就够：
症状 病阶 药方
demo 惊艳、实际生成率个位数 V1 别雕 prompt 了，拆流程
结构对了但「正确得没用」 V2 知识工程：喂历史缺陷和私域规则
质量上来了但知识靠人肉维护 V3 BadCase 闭环，让系统消化自己的错误
多数团队的 AI 产品死在把 V3 的病当 V1 治。包括三个月前的我们。