你有没有遇到过这种情况让AI大模型帮你生成测试用例开头它还能按需求点老老实实地列写到后面就开始凭“想象”发挥把业务逻辑改得面目全非甚至前后两条用例互相矛盾。这不是模型智商不够而是AI“失忆”了——它把最开始喂给它的需求细节忘得一干二净。我做测试平台也有几年了类似的问题遇到过太多次。后来我把思路从“给大模型写更长的提示词”换成“给大模型建知识库、配工作流”用RAG知识库做长期记忆用可编排的工作流把生成动作固化成一条流水线才终于把用例生成的稳定性拉到了能上生产的水平。这篇内容适合想在企业里落地AI辅助测试的同学看尤其是质量保障工程师、测试开发以及正在评估AI Agent能不能进测试流程的团队。你会看到三件事知识库怎么搭才能让AI记住项目里的业务细节工作流怎么编排才能让生成结果稳定可控以及两者如何组合成一条真正复用的流水线。不聊玄的全是能直接抄作业的干货。1. 先聊聊AI生成测试用例为什么总在“翻车”1.1 AI“失忆”的本质上下文窗口与注意力漂移大模型本质上是一个“短时记忆很强的临时工”。你给它一段需求文档它能理解眼前这几千字能照着写出像模像样的用例但只要输入一长、对话轮次一多它就开始“忘事”。这不是产品缺陷而是大模型的运行机制决定的Transformer架构的注意力机制对长上下文的处理是有限度的你塞进去的内容越多模型越容易把注意力分散到无关信息上关键约束反而被淹没。我拿生活中例子解释一下你让一个实习生做一个订单系统的回归测试他刚看完第一页需求时记得很清楚但项目文档有30页他翻到第20页时已经忘了第3页里“优惠券不能和满减同时使用”这种核心规则最后按自己的理解写出了完全相反的用例。大模型也是这么“飘”的。这个现象在测试用例场景里尤其致命。用例生成要求逻辑严谨、边界清晰、前后一致而大模型在上下文过长时的注意力漂移恰好会把最关键的边界条件和业务规则丢掉。这就是我说的AI“失忆症”。1.2 为什么堆提示词解决不了“失忆”问题有人会想那我每次把需求文档、历史用例、测试规范全部塞进提示词里不就行了理论上可以实际跑通不了。普通模型的上下文窗口虽然已经到了128K甚至200K但长上下文不等于高质量上下文输入超过一定长度后检索和推理的准确率都会明显下降你塞进去的“背景知识”反而会成为模型输出的噪声。更现实的问题是成本。每轮对话都把所有文档塞进去Token消耗直接爆炸一次生成上万字的需求文档加上用例库成本就是普通提示词的几十倍。而且同一个需求换个人来问模型给出的结果完全不一样输出没有可复现性。这在工程上是没法接受的。所以传统提示词方案顶多算demo不是“工业级”。“工业级”在我理解里有四个硬标准可复现同样输入产出一致性高的结果、质量稳定不靠运气生成、可审计能追溯每步判断依据、成本可控长期跑得起。要做到这四点就必须把“知识记忆”和“任务执行”拆开分别用知识库和工作流去解决。2. 知识库给AI装上不会失忆的“长期记忆”2.1 知识库里到底该放什么很多人搭知识库把所有文档一股脑传上去就完事了结果检索出来一堆无关内容AI反而被带偏。知识库不是垃圾桶它对内容有很强的“结构化要求”。以测试用例生成场景为例我通常建议至少沉淀这几类内容需求与产品文档PRD、原型说明、变更记录接口文档与系统架构说明服务依赖、字段定义、状态机流转历史测试用例尤其是线上验证过、覆盖率高的优质用例缺陷库与复盘记录典型Bug、线上事故复盘、根因分析公司测试规范与模板用例格式、命名规则、回归重点这里有个容易忽略的点历史用例库和缺陷库比需求文档更能激发模型的“测试直觉”。模型见多了真实Bug的长相才知道哪些边界条件容易踩坑。你光给一份PRD它只能生成“看起来正确”的用例给一堆缺陷案例它才能生成“真正能发现问题”的用例。2.2 文档解析、切片与向量化最容易被忽视的细节知识库的底层是RAG检索增强生成核心链路是“文档解析→切片→向量化→存储→检索”。很多人以为辛苦在上传其实真正的效果差异藏在前三步。我自己踩过最深的坑是Word和PDF解析。PDF里的表格直接扔给解析器出来经常是乱码和错位的单元格Word里带页眉页脚切出来全是无效文字。处理这类问题我现在的做法是先用专门的文档解析服务把PDF/Word转成Markdown再把表格单独抽出来确认结构最后才进入切片阶段。不同平台的内置解析器效果差别很大一定要实测同一个文档在不同解析器下的输出。切片策略同样讲究长短都不行。切太长一段里混合了多个语义主题检索命中时噪声大切太短一个完整的业务规则被拦腰截断模型看不到事件的来龙去脉。我的经验值是按语义边界切每个片段控制在256到512个字符同时让相邻片段保留128字符左右的重叠。重叠是为了防止规则正好被切断属于一个不贵但很有效的补丁。向量化模型的选择也影响很大。中文业务文档场景国际商用模型的向量维度高但中文语义理解未必比国内模型好我试下来bge-m3、m3e这些中文友好的Embedding模型在业务术语匹配上反而更稳。向量化后建议把“模块、版本、文档类型”这些信息写进元数据Metadata这样检索时可以按条件过滤比如只搜“订单模块的历史缺陷”。知识库内容一旦上了规模没有元数据过滤检索质量会很难控制。2.3 检索策略混合检索和重排序带来的实打实提升知识库搭好之后真正的考验是“查得准不准”。纯向量检索在中文业务文档上经常有奇怪的问题业务术语“优惠券核销”和“优惠券结算”语义接近但向量距离可能很远导致漏召回反过来两个毫无关系的句子在向量空间里距离很近导致误召回。这都跟训练数据有关不是调Prompt能解决的。我现在的标配是“混合检索Rerank重排”。混合检索就是关键词检索BM25和向量检索同时跑再把结果合并去重。关键词负责精确匹配专有名词、接口名、类名向量负责语义泛化两者互补。合并后的结果再用Rerank模型按相关性重排一遍把最相关的片段排到前面再交给大模型。这套组合在中文业务文档上比纯向量检索大概能提升二三十个百分点的检索准确率不夸张。检索参数上topK我一般设5到8太少了会漏太多了会把无关内容喂给模型干扰判断。知识库这块Dify、FastGPT、AnythingLLM这些开源工具都内置了混合检索和Rerank能力Coze这类云端平台也提供了知识库模块如果你只是想快速验证直接用平台自带功能就够了等量级大了再考虑自研向量库。3. 工作流编排让用例生成变成一条稳定的流水线3.1 自由对话和编排流水线的差距有了知识库AI能“记住”了但如果只是让用户对着聊天框说“帮我写用例”结果依然不可控。自由对话的问题在于用户问法不一样模型就给你不一样的处理路径。有时候它先分析需求再写用例有时候它直接列列表上一次是Markdown表格下一次可能是纯文本同一个需求换几种问法产出格式千奇百怪。“自由对话适合探索需求固定工作流适合批量生产。”这条判断标准在测试场景里非常适用。用例生成是一个高度重复、需要标准化产出的任务它天然适合用流水线来做。工作流的本质就是把“大模型自由发挥”变成“节点按顺序执行”每个节点有明确的输入、输出和校验规则任一步骤出错都能定位。我拿后厨类比一个餐馆如果所有菜都让同一个大厨从头做到尾这个厨师的水平和当天心情就决定了出品质量。但如果是西式厨房每个工位只负责一道工序——切菜、煎制、摆盘、出餐检查——每一环都可控、可优化。工作流也是这个逻辑把“解析需求”“检索知识”“生成用例”“格式化输出”拆成独立节点哪个环节出问题就改哪个环节不用推翻重来。3.2 一套最小可落地的流水线长什么样我设计过一版最简但能直接用的测试用例生成流水线节点结构如下开始节点接收用户上传的需求文档或PRD文本需求解析节点LLM提取功能点、业务规则、测试范围输出结构化JSON知识检索节点按功能点逐个从知识库检索相关历史用例、缺陷记录和测试规范用例生成节点LLM结合功能点和检索结果生成覆盖正反边界例的测试用例格式化节点把生成结果转成统一模板输出Markdown表格或Excel文件结束节点返回生成的用例集附上引用的知识来源这套流水线的关键是“先解析、再检索、后生成”。很多人的失败在于上来就让模型生成模型对需求理解都不深自然写不出好用例。先让LLM把需求里的功能点全部列出来相当于做了一次“题目拆解”后面再逐个功能点生成用例覆盖度会高很多。知识检索节点按功能点分别检索比把整个需求文档一次性丢进去检索质量高。因为每个功能点对应不同的业务模块分开检索可以拿到更精准的上下文。例如订单系统的PRD里有“下单”和“退款”两个功能分开检索“下单历史缺陷”和“退款历史缺陷”各自命中的用例都比混在一起检索精准。用例生成节点的提示词设计有讲究我下面给一份可复用的模板核心约束是“禁止臆造”、“必须引用检索内容”、“必须包含异常流”。3.3 参数配置温度、检索条数和模型怎么定调用大模型生成测试用例时第一个要调整的参数就是temperature。这个参数控制随机性数值越高输出越有“创意”数值越低输出越保守稳定。测试用例生成是强稳定需求我的建议是temperature设置在0.1到0.3之间最高不要超过0.4。我实测过把temperature从0.7降到0.2之后同样的输入两次生成用例的一致性能从六七成提升到九成以上。topP参数一般保持默认0.3到0.5就行不用过度调。检索条数我前面说了topK建议5到8。还有两个容易被忽略的配置超时时间和重试机制。LLM接口在高并发时经常超时建议把单次调用超时设到60秒以上并配置自动重试两到三次重试时加一点指数退避。模型选型方面如果预算允许优先选上下文窗口大、指令跟随能力强的模型。生成需求解析我用大杯型号生成单个功能点用例用标准杯型号把昂贵模型的调用控制在关键节点上。现在很多平台支持模型路由可以让简单节点用便宜模型复杂节点用好模型长期跑下来能省下不少成本。4. 实操实录Dify上从零搭建用例生成流水线4.1 前置准备选平台、攒数据、定规范市面上能搭知识库和工作流的平台不少我以Dify社区版为例讲实操因为它的知识库模块和工作流编排功能门槛够低支持本地部署数据可以不出去。Coze、FastGPT的操作逻辑类似看懂了Dify其他平台基本可以触类旁通。动手之前先把数据攒齐。别急着上传先按我前面说的五个类别整理需求文档、接口文档、历史用例、缺陷复盘、测试规范。第一次搭建不需要追求全把当前正在做的核心业务的资料收齐就够了后面再逐步扩展。同时要定好“用例输出规范”。我推荐在知识库里放一份公司测试规范文档明确规定用例必须包含“编号、模块、前置条件、测试步骤、测试数据、预期结果、优先级”这样模型在生成时有了参照模板。你给模型看什么样的格式它就更容易生成什么格式。这一步很多人不做结果模型凭空造格式后面的格式化节点很难收拾。4.2 知识库搭建上传、切片、检索验证一把梭在Dify里创建知识库把整理好的文档传上去。上传时注意PDF先确认表格解析是否正常Word文档建议先转成Markdown再传如果文档里带大量截图截图里的内容是模型看不到的需要在文档里补上对应文字描述否则检索就漏了。切片策略按我前面说的方案设置按语义分割每段256到512字符重叠128字符。Embedding模型选中文效果好的模型。开启混合检索。上传完成之后不要急着接工作流先在知识库里用几个典型问题测试检索效果。我试过最典型的验证方法是拿PRD里的原句当作查询比如“用户下单时使用优惠券是否允许与满减叠加”看知识库能不能把对应的历史规则和缺陷记录排在前面。如果检索结果不准先调整切片大小再检查是否需要加元数据过滤实在不行再换Embedding模型。记住一个原则检索不对后面全白搭。4.3 工作流编排从PRD到用例的完整节点设计在Dify里新建工作流按我前面说的六个节点依次搭建。需求解析节点我用的提示词模板大致如下你是资深测试架构师。请从以下需求文本中提取测试范围输出JSON格式包含 1. 功能点列表每个功能点用一句话描述 2. 业务规则列表从需求中识别出的约束和边界条件 3. 异常场景提示需求中可能隐含的风险点 4. 测试优先级建议 需求文本 {{input}}这个节点的作用是把非结构化的需求文本转成结构化的功能点列表给后面的检索和生成提供索引。注意输出格式要定义成JSON后面节点才能做解析。知识检索节点拖进来把上游解析出的功能点列表作为检索查询逐个检索。Dify支持在知识检索节点里设置检索数量和相关性阈值我的经验值是至少命中两条以上有效内容这里的检索结果会作为后续生成节点的上下文。用例生成节点的提示词我这样写你是资深测试工程师。请严格按照以下要求编写测试用例 - 仅基于提供的需求片段和知识库检索结果编写不得臆造需求未提及的字段或接口 - 每条用例必须包含用例编号、所属模块、前置条件、测试步骤、测试数据、预期结果、优先级 - 覆盖范围必须包含正常路径、边界值、异常流、业务规则验证 - 如果知识库中有对应历史缺陷记录必须设计回归用例覆盖该缺陷场景 功能点{{feature}} 需求片段{{requirement}} 知识库检索结果{{knowledge}}最后加一个格式化节点把大模型输出转成统一的Markdown表格。Dify的模板节点可以用Jinja2语法把JSON数据渲染成表格格式。这样最终输出是干净的表格不是大模型随手写的样式。4.4 效果评估用数据说话别凭感觉流水线跑通后必须量化评估效果否则你不知道下一步该优化什么。我常用的指标有四个需求覆盖率生成的用例是否覆盖了PRD里的全部功能点和关键规则、用例可执行性步骤是否明确、数据是否完整、预期是否可判定、漏测率对照历史缺陷检查流水线是否覆盖了已知Bug场景、人工返工率用例需要修改多少才能进测试执行。其中最容易拉开差距的是漏测率。我建议把历史缺陷库先拆成训练集和验证集用验证集里的真实缺陷来验证流水线能不能生成覆盖它们的用例。我第一次跑通这套流水线时需求覆盖率能做到90%以上但漏测率还是不理想后来发现原因是知识库里的缺陷记录写得太简略模型检索到片段后无法理解当时的场景。把缺陷记录补上“复现步骤根因分析对应模块”之后漏测率才明显降下来。这说明知识库的内容质量比工作流节点设计更能决定效果天花板。5. 上线之后常见故障排查与避坑速查表5.1 检索结果不准先别改模型如果生成的用例看起来“答非所问”大多数时候不是模型的问题而是检索召回的结果不对。我遇到这类问题会按这个顺序排查先看知识库里测试几个查询的命中结果是否准确不准确则调整切片长度和重叠值切片过长导致语义混杂先改这个再检查是否缺少元数据过滤导致跨模块内容涌进来最后才考虑换Embedding模型或调整检索模式。有一个很典型的坑query描述太长时向量检索的效果反而会下降。比如你拿着整个功能点的描述去检索而不是拿核心术语去检索召回结果经常偏掉。我现在会让知识检索节点先把输入压缩成几个关键词再拿去检索效果明显更稳。5.2 用例格式乱、重复高、幻觉多怎么办格式乱的原因通常是生成节点没有看到规范模板。解决办法就是在知识库里放一份“用例编写规范”并在提示词里明确指定输出格式。重复高的原因往往是多个功能点检索到了同一段上下文生成的内容自然趋同。可以在提示词里加一行“如果已生成过相同或相似的测试步骤允许合并去重不要重复输出”。幻觉是测试场景最不能忍的问题。AI编造一个不存在的接口名、一个不存在的状态码走查时才能发现那这条流水线就是负资产。我的做法是在生成节点提示词里加“禁止臆造需求未提及的系统字段与接口”同时把知识库里的接口文档切片做得更细让检索能够命中到具体的接口定义给模型一个“事实锚点”。5.3 成本、延迟和稳定性工业级的硬门槛跑通Demo很容易跑上生产很难。三个槛成本、延迟、稳定性。成本上建议给所有LLM节点加缓存相同输入命中缓存就直接返回能省下很可观的Token费用。延迟上不要把每次请求都做成同步等待批量生成用例的需求可以走异步任务队列后台跑完再通知取结果。稳定性上线上必须配置重试和降级模型供应商偶尔会超时或限流我的做法是配置两个模型供应商主供应商异常时自动切到备用供应商。另外日志和审计必须有。一条用例是谁在什么时间基于什么检索内容生成的要能追回来。不要觉得这只是合规要求在实际调试中日志能帮你快速定位是哪一步出了问题省下来的时间远超搭建日志的投入。这也是“工业级”和“玩具级”的分界线。5.4 权限与数据安全最后一道防线测试用例背后是真实的业务规则和潜在的漏洞信息知识库里的PRD、接口文档也都是公司的核心资产。权限控制必须从前端到后端全线覆盖谁能看知识库、谁能调工作流、生成的用例落在哪里都要有明确控制。尤其是在使用云端大模型API时注意脱敏代码用户名、密码、密钥这类信息在上送前必须用变量替换。企业内部有多条产品线时知识库最好按项目隔离避免A项目的查询混入B项目的文档。这个用Dify这种平台很容易实现属于“配置一下就能做”的事情。很多团队一开始觉得麻烦等到出了事故才后悔。安全这件事不用讲太多道理越早做越好。我个人在实际操作中的体会是搭知识库和工作流的难点从来不在技术而在“把隐性知识显性化”这个过程。测试专家脑子里那些“这个模块之前踩过坑”“这个状态流转容易出错”的经验如果不沉淀成文档AI再怎么调参也学不会。把老同事脑子里的东西变成知识库里的条目这套流水线的价值才能真正发挥出来。最后再分享一个小技巧调试阶段任何生成质量问题都先查知识库检索结果检索结果对了生成质量基本就对了这个顺序能帮你省掉大量无效调参的时间。