1. 先搞清楚AI生成测试用例为什么总是“记不住事”近一年我试过不少AI辅助测试的方案最让人头疼的并不是AI不会写用例而是它总在“失忆”。你上午刚把登录模块的历史缺陷喂给模型下午让它生成新的登录测试用例时它依然会写出重复的、甚至和缺陷记录冲突的用例。你明明在提示词里写了“请参考附件文档”它却像没看见一样自顾自地输出一套通用模板。这种反复横跳是所有尝试用AI做测试的人都绕不开的坎。先说结论AI不是故意装傻而是你给它的信息组织方式不对。大模型本质上是一个“基于上下文做预测”的系统它所有的“记忆”都局限在这一次请求里。你传一段Prompt、几个附件它当场给你输出但下一次请求上下文清零上一轮的经验全部作废。这跟人不一样人干测试干久了会积累经验模型不会——除非你把经验主动喂给它。再往深一层说就算你把文档塞进Prompt里也会遇到两个问题。第一是上下文窗口限制一份需求文档动不动几十页塞不进去即便塞进去了模型处理长文本时对中间的细节关注度会显著下降容易出现“头尾记得、中间忘光”的情况。第二是内容组织问题需求文档里的信息密度很低大量篇幅在讲背景、讲团队计划真正和用例设计强相关的“业务规则”“边界条件”“异常路径”可能就那几句话模型根本抓不住重点。所以过去那种“把文档拖进对话框让AI一次性生成所有用例”的用法注定只能停留在Demo阶段离“工业级”差距很远。我的解决思路是两条线并行用知识库解决AI的“长期记忆”问题用工作流解决AI的“逻辑混乱”问题。知识库负责让AI在生成用例时能随时查资料、补背景工作流负责把用例生成拆成一段段可控的工序每段只做一件事做完了再进下一段。两条线合在一起就是一条可重复、可维护、可评估的AI测试用例生成流水线。这篇文章我就用一套自己实际搭过的流程来拆解里面所有步骤、参数、踩坑记录都是真实跑过的。适合测试开发、QA负责人、研发效能团队参考也适合那些正在用Dify、Coze这类工具搭AI应用但不知道该怎么落到测试领域的人。2. 知识库先行把团队的“脑内经验”沉淀成可检索的资产2.1 RAG到底在解决什么问题为什么它比“纯Prompt”靠谱知识库这个词这两年听得太多了但落到AI测试用例生成这个场景它本质上就是RAGRetrieval-Augmented Generation检索增强生成。通俗点讲AI在生成用例之前先去一个外部资料库里把相关信息捞出来捞完再结合这些信息去做生成而不是光凭它自己脑子里的那点“常识”硬编。这就好比新人测试入职先给他配一台能查内部Wiki的电脑他边查边写用例而不是要求他啥都不查、全靠脑补。这里有一个很关键的设计问题知识库不是简单地把文档扔进去就完事。真正决定AI能不能“用对”知识的是三件事——放什么内容、怎么切分、怎么召回。放什么内容取决于你要覆盖的测试场景。以我的实践来看一套能支撑工业级用例生成的知识库至少要包含五类素材产品需求文档、接口文档、历史缺陷记录、测试规范和业务术语表。这五类素材各有各的用途需求文档提供业务规则接口文档提供参数边界缺陷记录提供历史坑点测试规范约束用例格式术语表统一表述口径。如果团队有用户反馈积累那也建议放进去很多边界条件都是在用户抱怨里挖出来的。怎么切分是把文档变成长度适中的片段再向量化。切得太长片段里信息杂检索时命中噪音多切得太短片段里的上下文不完整AI看不懂前因后果。我一般把块长控制在500到800个token之间重叠区留100到150个token这样既能保证每个片段讲得清一个逻辑点又不会因为切得太碎让上下文断裂。很多平台默认是固定字数切块对代码和表格效果还行但对需求文档这种大段描述性文字最好自己调一下分隔符比如按标题、按章节层级来切。怎么召回是指用户提出生成用例的请求后系统怎么从知识库里挑出相关内容。最容易踩的坑是只用向量检索。向量检索擅长找“意思相近”的内容但不擅长精确匹配比如你搜“订单金额大于1000时报错”它可能把“钱包余额不足”这种语义相似但不相关的内容也捞出来。所以我在实际配置里一般用“混合检索”把向量召回和全文检索BM25结合起来再做一次重排把最相关的3到5个片段优先送到模型那边。这一步处理好AI输出的相关性会明显上一个档次。2.2 文档解析和入库这里面的细节直接影响检索质量知识库能不能建好入库前的工作比入库后重要得多。很多人直接把一份PDF拖进Dify或者Coze里隔天检索发现啥都搜不到十有八九是文档解析这一关没做好。以Word和PDF为例这两类文件是测试团队最常碰到的。Dify的“傻白甜”方式是对文档按页解析然后把每页文字直接切成块。遇到纯文本没毛病遇到带表格的接口文档就抓瞎了——表格一旦跨页一页的内容根本拼不成一个完整字段检索时自然缺斤少两。我自己的做法是文档入库前先做一次“预处理”把PDF用pdfplumber提取文字把Word用python-docx读取段落再手动把接口表格、用例模板这类结构化内容转成Markdown格式的条目最后再入库。另外一件事容易被忽略——给知识片段打好“元数据标签”。比如每个片段记录它属于哪个模块、是哪个版本的文档、属于“需求”“缺陷”还是“规范”。有了元数据后续在Dify或Coze里就能做元数据过滤。比如生成支付模块的用例时只召回支付相关的片段别把物流模块的历史缺陷也带进来。我见过很多人建了知识库但检索结果一团糟原因就是对过滤条件不敏感。元数据的价值在于可以大幅降低检索时的“背景噪音”让模型把注意力放在真正相关的知识上。进知识库这一步还要考虑版本。需求文档一直在变经常一个项目半月迭代三版。你要是图省事把新文档直接覆盖进去断点检索时模型可能拿到新旧混杂的内容生成的用例甚至会自相矛盾。我建议按版本号建多个知识库或者至少在元数据里标清版本和日期检索时通过过滤只取最新版本的内容。麻烦是麻烦一点但能让AI的输出质量稳定得多。2.3 从“堆文档”到“造血库”知识库要持续回流知识库最怕建完就躺平。测试这件事有个特点新用例执行完、新Bug验证完都会产生“新的经验”。如果这些经验不回流到知识库里知识库永远停留在“初始版本”时间越久价值越低。我在自己的流水线里加了一个“反馈回路”测试用例评审通过后人工手动点击“转录到知识库”把这条用例和它背后的需求规则一起存入知识库归类到“已验证用例”标签下线上出了问题排查出根因后也会把根因、触发条件、回归建议写成一条知识摘要存进知识库。这个动作看起来简单但它能让知识库随着项目演进自动“生长”。AI下次生成用例时就会自动参考之前验证过的用例和线上踩过的坑——这才是“告别失忆”的真正含义。这里也给个忠告知识库的质量比数量重要宁缺毋滥。放一百条高质量规则效果远好过放一万份灌水文档。无用的碎片太多检索时模型很容易被带偏。我一般要求团队每隔一个迭代就清理一次把过时的、被替代的、经确认无用的片段移除。3. 工作流编排给AI搭一副“逻辑骨架”3.1 为什么一条提示词搞定不了测试用例而需要“流程化”很多刚接触AI辅助测试的人会有一个疑问我用Copilot或者ChatGPT一句“帮我生成登录模块的测试用例”也能得到一份能看的列表为什么还要折腾工作流答案很简单一次性生成的用例只能算是“流程过了一遍”远达不到可用标准。你把完整的用例设计交给一个大Prompt它在生成时既要理解需求又要查知识库又要设计场景又要写前置条件、步骤、期望结果还要考虑边界值和异常路径——这些任务挤在一个上下文里模型会“注意力失焦”结果就是每条用例都浅尝辄止场景覆盖不全细节缺失格式混乱。把它拆成多个小节点每个节点专注一个任务反而每个任务都能做好。这就是工作流存在的意义。工作流不是花架子它是把“生成测试用例”这个复杂任务解构成一串有序的小工序每道工序有明确的输入、输出和校验标准。前面工序的结果是后面工序的输入任意一道出问题都能单独调试不会一锅粥。这和软件开发里的模块化是一个道理。3.2 测试用例生成的五段式拆解我自己设计的流水线把用例生成拆成了五个阶段需求解析、知识检索、场景识别、用例生成、质量校验。每个阶段在Dify里对应一个或多个节点实际跑起来一环扣一环。第一段需求解析。输入是产品需求文档/PRD原文或者产品经理的一句需求描述。这个节点的任务不是生成用例而是把需求里的“信息点”提取出来涉及的角色、操作入口、前置条件、核心业务规则、异常点。输出是一份结构化的“需求要素清单”。这一步很关键因为后续所有场景识别和用例生成都从这份清单里找依据。处理得不好后面全是空转。第二段知识检索。拿着第一段输出的清单去知识库里检索相关片段。比如清单里有“退款”“原路返回”就检索“退款”“原路返回”相关的历史缺陷、接口约束和业务规则。这个节点不生成内容只负责“捞料”然后把捞出来的片段整理成结构化的“参考上下文”传给下一段。第三段场景识别。这是我自己加的一个中间节点很多人会跳过它但我觉得它是整条流水线里性价比最高的节点。它的任务是基于“需求要素参考上下文”列出该需求的测试场景清单——什么正常流、什么分支流、什么异常流、什么边界条件。场景清单是“做什么”的规划不是具体的用例。有了这个中间产物人能非常方便地审核AI列的这些场景到底全不全有没有漏掉关键路径。如果AI在这里就出问题根本不需要等到生成用例才发现。第四段用例生成。把场景清单作为输入逐条展开成完整的测试用例。每个场景展开成一条或一组用例每条用例包含用例编号、标题、前置条件、测试步骤、测试数据、期望结果、优先级。这里对模型的要求是“格式严格”和“细节完整”我在Prompt里会明确要求优先级怎么定、步骤怎么写才可执行、期望结果要怎么量化。配合一个固定输出模板基本能保证格式稳定。第五段质量校验。生成完用例后加一道“验收”节点让模型按预设规则自查每条用例是否覆盖了需求中列出的业务规则是否包含至少一个异常输入或边界值验证前置条件和测试步骤是否逻辑完整期望结果是否有明确且不模糊的结论。如果抽查出用例覆盖不全、重复严重、格式混乱就标记为“不通过”退回给前面的节点重新生成。这一步虽然会多次调用模型但能显著提高最终输出可用性比起让测试人员拿一份半成品去逐条返工时间成本反而更低。3.3 每个节点的提示词和参数怎么调直接决定成败拆完阶段以后很多人以为工作流就“搭好了”结果一跑输出依然一团糟。问题多半出在节点级的提示词和模型参数上。先说模型参数。测试用例生成场景和闲聊不同需要的是稳定、一致、逻辑严密而不是发散和“创意”。所以我在所有生成节点里把温度temperature压到0.2到0.4之间top_p调到0.8左右。温度调低的好处是同样的输入产生了偏差小、结构稳定的输出这对测试用例这种强格式要求的任务特别重要。如果你用的是默认温度大概率会出现两种情况一是同一需求来回跑两次生成的用例差异很大二是模型会不断发挥写出一堆“复杂而冗余”的步骤让用例变得难维护。再说提示词。每段节点的提示词我强烈建议加入两个东西Few-shot示例和“遵循格式”的硬性约束。以场景识别节点为例我会在提示词里给出两个示例一个是输入“用户登录密码连续输错5次后锁定账号”时期望它输出“正常密码登录成功”“密码错误提示”“连续输错5次锁定”“锁定后正确密码也无法登录”“解锁后重新登录”“密码为空”“密码长度边界”等几条场景清单。另一个示例是输入带复杂业务规则的需求时期望它提炼出角色权限、状态流转、金额边界等维度。示例不在多在于精准。以用例生成节点为例我要求模型严格采用统一的模板输出用例编号模块_场景_序号用例标题一句话说清楚“什么条件下做什么操作、验证什么结果”前置条件涉及账号、环境、数据准备测试步骤编号列表每步是可执行的单一操作测试数据明确输入的参数值、边界值期望结果可验证的明确断言优先级P0/P1/P2/P3这个模板看起来很简单但一旦写在Prompt里并附上示例输出格式的稳定性会大幅提升解析和后续入库都会省很多事。3.4 人机协同不是一句口号而是流程里的“节点”工作流还有一个容易被忽视的好处可以把人的校验做成流程里的显式环节而不是事后救火。我在流程里加了一个“人工审批”节点位置在质量校验之后、用例入库之前。它的逻辑很简单——AI把生成的用例推到前端界面测试负责人可以逐条勾选“通过”或“需修改”修改意见可以写在备注里点击通过后用例才正式进入用例管理平台。这一步的作用是双重的。一方面它给AI输出加了一道安全网避免模型生成的“看似合理但实际不符合需求”的用例直接进入自动化脚本或测试执行环节。另一方面人工审批过程中产出的“修改意见”也是一批极有价值的训练数据可以定期汇总反过来优化Prompt和知识库内容。这是让流水线不断变聪明的核心机制。有人会觉得这多了一步麻烦事但从效果来看它的性价比非常高。我经历过完全不审AI生成用例的项目最后“用例确实生成了但就是不敢直接用”因为没有人能保证模型的输出一定正确。加了人工审批后虽然每次仍要花十几分钟过一遍但至少生成结果的可用率、可信度有了保障AI才真正能分担测试团队的工作。4. 流水线落地实战从需求到用例的一次完整跑通4.1 选型对比自研框架、Dify、Coze怎么选聊完了思路我们落到工具上。现在主流的低代码AI工作流平台基本是Dify和Coze争霸加上一部分团队会选择自研。我拿测试用例生成这个场景做个直观对比考量维度DifyCoze自研框架知识库能力原生支持可做混合检索和元数据过滤支持知识库但配置项偏少需要自行实现全套RAG链路工作流编排节点类型丰富支持分支、循环、变量引用节点丰富适合快速搭建但部分高级功能受平台限制完全自由但开发维护成本高适用场景适合企业级落地数据可控性强适合快速验证原型个人和中小团队友好适合需要深度定制、对数据安全要求极高的团队部署方式支持本地部署数据不出内网云端为主部分支持私有化但功能受限完全自主控制我个人目前最常用的是Dify。理由很简单一是我需要本地部署用团队内部的知识库和模型不把业务数据暴露给外部平台二是Dify的元数据过滤和混合检索正好满足我在知识库一节里提的诉求不用再单独开发一套检索逻辑三是它支持把工作流封装成API方便嵌套到内部测试平台里让测试人员不用打开Dify也能使用这条流水线。Coze则适合快速验证想法。如果你想先花两三天看看“AI生成测试用例”这套路到底适不适合你的团队用Coze搭个流程比Dify快得多。但如果你确定要长期用、频繁调参、对接内部系统还是早点上Dify这类可私有化的平台。4.2 用Dify搭建知识库从上传文档到召回调优下面我把实操步骤完整走一遍你跟着操作就能复现一条MVP流水线。第一步建知识库。在Dify里新建一个名为“XX模块测试知识库”的库然后在“设置”里选择Embedding模型。这里重点说一下Embedding模型的质量直接决定检索效果别用默认的轻量模型糊弄。我测试过好几款BGE系列和text-embedding-3系列的中文效果都能接受二选一即可。选好后可以顺便在“检索设置”里把召回模式切成“混合检索”并打开“重排序”开关。第二步上传文档。把预处理过的需求文档、接口文档、历史缺陷记录、测试规范按类别上传。注意如果是Dify的本地版上传时它会自己解析文本再切分如果你已经做过预处理建议上传Markdown或TXT格式不要继续上传原始PDF避免二次解析出问题。第三步检查切分效果。上传后挨个点开文档看它切出来的每个块是否语义完整、有没有切到表格中间、有没有把标题和正文割裂开。这一步花的时间不多但能避免后面频繁出现“检索不到”的问题。第四步配置元数据。Dify的元数据功能支持你在文档上传后给片段打标签比如“模块退款”“版本2.3”“类型缺陷”。这一步如果文档量大可以写脚本自动标注如果量不大用手工打标签也行后面检索的准确率提升非常明显。第五步召回测试。这是最容易忽略但也是最关键的一步。不要等整个工作流跑完才发现知识库召回了错误内容。直接在工作台最上方打开“知识库调试”输入“用户申请退款但订单已发货会走什么流程”、“登录密码连续输错怎么办”这类真实查询查看召回结果。如果命中的片段不是自己期待的就回调分块策略、检索模式或者重排模型参数直到命中率达到80%以上再往下走。4.3 用Dify编排工作流五段式流水线实操配置知识库就绪后开始搭工作流。Dify里新建一个“测试用例生成流水线”类型选“工作流”然后按下面的节点顺序连线。第一个节点“需求输入”用“开始”节点即可。为了让使用更方便我通常在这个节点放两个字段一个“requirement_text”接收需求描述/PRD文本一个“module_name”接收模块名范围限定好后续检索靠它做元数据过滤。第二个节点“需求解析”是LLM节点。模型推荐用GLM-4系列或qwen-plus这种中文理解强的模型温度设0.3。提示词的大致结构是你是资深测试分析师请从需求文本中提取涉及角色、核心场景、业务规则、边界条件、异常输入、系统约束。输出格式为JSON包含role_list、core_scenario_list、business_rule_list、edge_condition_list、exception_input_list。第三个节点“知识检索”用“知识检索”节点。在配置里选好我们刚建的知识库查询内容引用上一个节点输出的“业务规则和边界条件”字段。如果前面配置了元数据过滤在这里把模块名填进去强制只检索当前模块的片段。召回数量设5到8个就够了太多会引入噪声。第四个节点“上下文精炼”是可选的LLM节点作用是压缩知识库召回的长文本把和本次需求不相关的内容滤掉统一整理成一条“参考上下文”。这步能非常有效地提高后续生成的准确性尤其是知识库片段多、内容杂的时候。第五个节点“场景识别”接LLM节点输入是需求解析节点的结构化和参考上下文。提示词明确要求“列出该需求的测试场景清单覆盖正常流、备选流、异常流、边界条件不生成完整用例”并给两条Few-shot示例。第六个节点“用例生成”接LLM节点。注意这里要把场景清单拆成多条并发我一般用一个“迭代”节点包住“用例生成”的LLM节点让每条场景单独生成一组用例而不是所有场景塞进一个Prompt。分开生成的效果远好于一次性生成几十条既降低了模型上下文压力也让每条用例生成得更细致。各场景的生成结果再通过“变量聚合器”合并成一个列表。第七个节点“质量校验”接LLM节点把聚合后的用例列表喂进去按前面说的四条规则逐条审查输出“通过/不通过”和修改建议。最后一个节点“输出”把最终用例列表以Markdown表格形式输出同时在Dify的“对话流”版本里还可以在输出前加一个人工审核节点让负责人点击确认后才返回结果。实际使用中如果发现生成用例不对劲可以直接在审核节点里驳回写意见模型会按意见重新生成一次。4.4 一次完整跑通描述、参数、结果和消耗我随便用一个真实项目里的需求来演示一下流程效果。输入的需求描述是“用户在课程详情页点击‘立即报名’如果当前账号未登录跳转登录页登录成功后自动回到课程详情页并完成报名若课程名额已满提示‘满员’并允许用户点击‘缺货登记’若用户已是该课程学员不能重复报名。”这个需求跑完“需求解析”节点输出的要素清单大概是角色未登录用户、已登录用户、在册学员核心场景未登录报名、登录后自动报名、重复报名、满员登记业务规则只能是未报名用户才能报名满员不能报名未登录需先登录边界条件名额为0同一账号重复点击报名登录态过期“场景识别”节点在这个基础上输出了一份场景清单除了正常流还能看到“登录态过期后页面停留再提交会不会重复提交”“名额只剩1个时并发抢课只有一个成功”这类比较有价值的分支场景。“用例生成”节点通过迭代把上面每个场景展开成1到3条用例。比如“未登录报名”这一条场景会生成两条用例一条是“未登录点击报名跳转登录页登录后自动回到详情页并完成报名”另一条是“未登录点击报名跳转登录页在登录页取消登录返回后无报名动作页面不回退到订单确认”。期望结果里连“会员标识正确显示”“订单状态为已支付”这些细节都写得很清楚。整条流水线跑一次的时间取决于模型响应速度通常在3到6分钟之间消耗的token大概在6000到10000这个区间包含多次模型调用。对比一个测试人员平均花30分钟到1小时完成同等规模的需求用例设计时间优势还是很明显的。4.5 回流闭环让流水线“越用越聪明”流水线跑通了只是第一步。真正让整条流水线变成“工业级”的是那套我前面提到的回流闭环。实际的场景是这样的测试人员拿到AI生成的用例后开始评审有一部分用例被改过才能用还有一部分直接被删除。这时我建议团队把这些“被修改的用例”和“被删除的用例”单独记录下来每两到三个迭代做一次汇总分析。如果发现某个模块的用例老是“生成不到位”说明该模块对应的知识库内容覆盖不足需要补需求细节、补历史缺陷、补业务规则。把补过的内容再次入库下一轮流水线生成的用例质量就会明显提升。同样的逻辑适用于线上缺陷。线上出了Bug排查出根因后我要求在缺陷单里附一段“根因摘要”内容包括触发的业务路径、前置条件、导致的结果、如何回归。这些摘要积累到一定量由测试负责人筛选后存进知识库。下次如果需求里出现类似路径或参数检索节点会自动把这段历史经验召回生成的用例就会覆盖到“防止线上缺陷回归”的场景。这套闭环最核心的认知是AI流水线不是一次性交付物而是一个需要持续投喂和迭代的“活系统”。你越愿意花时间去建设和维护它的知识库、优化它的工作流它给你节省的人力时间就越多。5. 落地过程中的高频问题和排错实录5.1 检索不到内容、召回不准十有八九是这几个原因“检索不到”是所有用知识库的人第一个遇到的问题。我排查过大量类似案例原因高度集中在一块。第一个原因是文档切分出了问题。原始PDF、扫描件如果没先做OCR和文本提取入库后根本就不是可检索的文字而是图片底下的无效层。你搜索时当然什么都搜不到。遇到这种先把文档转成文本格式再入库。第二个原因是分段颗粒度和查询不匹配。比如你按“固定500字”硬切一个完整的“退款流程”可能被切成了三块每一块都没有提到完整的业务链路查“退款流程”时命中的内容自然支离破碎。我一般建议按章节/标题层级来切并配合重叠区让跨段落的语义能衔接起来。另一个高频问题是召回的结果“看似相关实则无用”。最典型的是用户搜“管理员修改商品价格”结果召回的全是“管理员登录”的内容。这个问题的根源是句子里“管理员”语义权重太高向量检索被这个关键词带跑了。解决办法有两个一是调整重排模型的配置提高重排的严格程度二是在Prompt里让“知识检索”节点优先使用名词短语和业务规则片段而不是动作描述或者干脆把这些词的检索权重调低。我在Dify里一般会开“重排序低位权重过滤”两个开关召回准确率能提高很多。5.2 生成的用例重复度高、质量差如何定位是哪个环节出了错还有一个常见问题流水线跑通了AI也确实生成了用例但用例之间大量重复或者每条用例都像套模板完全没体现需求细节。这种情况我认为主要问题出在场景识别节点。场景识别是整个流程的“咽喉”它列出的场景直接决定后面生成的用例内容。如果场景识别给出来的五条场景全是“正常流程换个数据跑一遍”那你后面再让AI生成用例也只能翻来覆去生成正常流用例。如果发现用例重复、覆盖不全第一件事不是调生成用例的提示词而是回去看场景识别的输出把场景维度不足的问题解决掉。实践中我也发现在场景识别阶段加入“角色、数据状态、交互入口、异常路径、边界值”五个强制维度能有效扩展场景覆盖面。举个例子光说“用户登录成功”是不够的要拆成“新用户首次登录、老用户多端登录、密码错误、账号锁定、验证码过期”等具体场景。模型一旦在场景识别阶段把这些角度的内容补全后面的用例生成质量自然会被带好。5.3 token消耗居高不下怎么把每一分钱花在刀刃上最后聊聊成本。有些团队跑了一两次流水线一看token账单心疼得不行立刻把项目砍了。其实成本这块是可以压的而且压成本的思路和优化质量并不冲突。首先尽量用更便宜的模型处理“中间任务”。需求解析、上下文精炼这两个节点并没有太强的生成能力要求你可以用跑得快的轻量模型把贵的大模型留给真正需要写用例和做校验的节点。这里有一个原则消耗token多且对语义理解要求不高的节点尽量往便宜模型上放。其次控制知识库召回片段条数和长度。召回8个片段和召回3个片段上下文长度差别巨大。如果你的重排模型足够优秀只需要3到5条高质量片段就够了多召回就是浪费。再其次在用例生成节点把场景拆开逐条生成虽然会多次调用模型但平均一次的输入输出长度远小于一次性生成几十条。如果场景特别多还可以用并发的办法同时跑多个场景的生成整体不会增加总token但能有效缩短等待时间。第三点是我的一个经验也是容易被忽略的检测中间输出。Dify有调试日志你可以看到每个节点到底消耗了多少token、用了多少上下文。跑几次后对比不同配置下的消耗记录很快就能找出哪一步是最浪费的。我见过有人为了“上下文完整”把整份需求文档都塞进用例生成节点的Prompt里结果一次调用就烧掉几万token而大部分内容根本用不上。优化方式是让“上下文精炼”节点承担“压缩”的任务用例生成节点只拿精炼后的关键信息。5.4 常见问题速查表问题现象排查思路处理建议知识库搜索不到内容看文档是否解析成功、文本是否可检索PDF先OCR转文本Word转Markdown后再入库检索出大量无关片段看切分粒度、元数据、重排配置按章节切分使用元数据过滤开启重排模型生成的用例全是正常流问题在场景识别节点给场景识别提示词加入角色、状态、异常、边界等多维度要求多条用例内容重复场景清单里出现大量相似场景在场景识别阶段加去重规则相似度高的场景合并后再进入生成节点输出格式不稳定提示词缺少严格格式约束用JSON或Markdown模板约束输出配合Few-shot示例用例步骤不可执行步骤描述太抽象缺少具体数据提示词中强调“每个步骤必须是单一可操作指令”并给出正例token开销大生成节点上下文过长引入上下文精炼节点召回条数设到3~5条用轻量模型跑中间任务知识版本冲突新旧文档混在同一个知识库按版本建多个知识库或通过元数据强制只取指定版本6. 再补一点真正让这条流水线“活”下来的几个习惯这套流水线在你自己的环境里落地后我建议你额外注意三件事。第一件事写Prompt的人要和执行测试的人持续对齐。流水线效果不好很多时候不是工具问题而是“提示词和模板里的优先级排序”跟实际团队关心的点不一致。比如你们团队最看重的是线上缺陷回归覆盖但你的Prompt里没强调AI自然也不会特别照顾。每个迭代结束后花一点时间复盘一下“这个迭代生成的用例里哪些是我们手改掉的”你就能发现Prompt需要调整的方向。第二件事不要迷信默认参数。Dify也好Coze也好官方默认参数主要适配通用问答场景并不适配测试用例生成。默认温度跑出来的用例发散性太强默认的检索方式对中文技术文档支持一般。你花半天时间把温度、top_p、检索模式、召回条数调一遍效果提升会非常明显这半天时间花得非常值。第三件事别把“全自动生成用例”当目标。我见过很多团队一开始就奔着“AI全自动生成并执行测试用例”去折腾几个月后反而不如人机协同效果好。在当前模型能力下AI最擅长的是“快速产出初稿覆盖常规路径提前识别可能遗漏的边界”而人最擅长的是根据业务直觉和经验做最终判断。把AI当“高级实习生”给它清晰的输入、检查它的输出、及时喂它反馈它就能越干越熟练指望它一步到位当“资深测试专家”大概率会失望。这套流水线在我自己的项目里从最初的需求分析到知识库搭建再到工作流编排、回流闭环前后迭代了四五轮。目前的稳定状态是新需求进来跑一遍流水线出初稿测试负责人花十几分钟人工审核和微调就能得到一份结构完整、覆盖较全、可以直接执行的测试用例集。对比之前从零开始手工设计用例每个需求的用例设计时间缩短了60%以上且对历史缺陷场景的覆盖率明显提升。这个事让我更确信一个判断AI在测试领域最务实的落地方式不是追求全自动而是把“经验沉淀流程固化人机校验”结合起来。希望能给正在做类似尝试的你一些可复用的参考。