1. 从“垃圾”到“可用”为什么单次AI生成的测试用例不靠谱干了九年手动编写测试用例的活儿我决定用AI来解放生产力。最初的设想很简单把用户故事User Story扔给大语言模型让它直接吐出一套可以直接自动化执行的测试用例。第一版工具就是这么干的——一个API调用看起来一切顺利。直到我试图把它的输出直接喂给Playwright脚本时问题才像潮水般涌来。模型生成的测试步骤里写着“验证系统工作正常”。在Playwright里这行字毫无意义。系统是什么怎么算“正常”另一个步骤是“输入有效数据并提交”。哪个字段什么数据算“有效”提交后页面应该变成什么状态这些关键信息一概缺失。我这才恍然大悟单次AI生成本质上是在把测试用例编写当成创意写作。它追求的是文本的流畅和结构的完整看起来像那么回事。但测试用例是工程制品是给机器和工程师看的蓝图。它需要的是具体的值、可验证的断言以及能让自动化工程师无需二次沟通就能直接翻译成代码的精确步骤。当输出看起来“合理”却无法执行时它就成了精致的垃圾。于是我推倒重来设计了一个三阶段的生成流水线。质量评分从勉强及格的4-5分稳定跃升到了8-9分。这中间的差距就是工程思维与文本生成思维之间的鸿沟。2. 单次生成的结构性缺陷为什么提示工程救不了它很多人包括最初的我会把AI生成质量不佳归咎于提示词Prompt写得不够好。我花了数周时间像个炼金术士一样反复调整提示词调整语气、增加约束、提供更详细的例子。但收效甚微。问题的根源不是提示词而是单次生成这个结构本身存在无法克服的缺陷。当你要求一个LLM在一次生成中同时完成“理解需求”、“设计测试”、“输出规范”这三项任务时它必然会顾此失彼。就像一个同时要写代码、做单元测试、写文档的工程师每件事都只能做到表面。具体到测试用例生成单次输出的“垃圾”通常表现为以下几种形式2.1 模糊的断言与缺失的覆盖这是最常见的问题。模型会生成诸如“验证结果正确显示”这样的断言。对于自动化脚本来说这是无法执行的。正确的断言应该是“验证搜索结果列表的第一项标题包含关键字‘Playwright’”或者“验证订单总金额显示为$150.00”。另一个致命问题是覆盖不全。一个包含8条验收标准Acceptance Criteria的用户故事单次生成可能只输出3-4个测试用例剩下的需求被完全忽略。这会导致严重的测试遗漏失去了自动生成的核心价值。2.2 无差别的优先级与占位符数据单次生成的所有测试用例优先级往往都被标记为“P1 - 高”。这在实际项目中毫无指导意义。当持续集成CI流水线因某个测试失败而中断而你只有10分钟修复时你首先需要运行的是那些覆盖核心业务流程的P1测试而不是所有测试。此外模型喜欢使用描述性语言而非具体数据。它会写“输入一个有效的电子邮件地址”但自动化脚本需要的是一个实实在在的字符串比如test.userexample.com。这个“有效”的定义格式正确、未被注册、属于白名单域名等被完全丢失了。2.3 合并的场景与缺失的上下文为了追求输出的简洁或受限于token长度模型经常会把多个独立的验收标准合并到一个测试用例中。例如将“验证登录成功”、“验证登录失败后显示错误信息”、“验证记住我功能”三个场景糅合在一个“测试用户登录”的用例里。一旦这个测试失败排查问题将变得异常困难因为你无法快速定位是哪个具体的需求未被满足。更深层的问题是单次生成缺乏足够的上下文。它只看到了用户故事的描述却看不到相关的技术栈约定例如项目使用React组件按钮的测试ID命名规范是>