这两年做质量保障，最让我头疼的不是需求改版，也不是环境不稳定，而是“测试用例怎么又快又好地写出来”。新功能上线前，一条条手写用例，翻需求文档、查接口定义、对照历史规则，重复劳动特别重。后来我试着把知识库和工作流结合起来，用AI搭建了一套工业级测试用例生成流水线，才算真正把这块的效率提上来。这篇内容就围绕“知识库+工作流+AI测试用例生成”展开，说说我是怎么一步步把“让AI写测试用例”这件事做成一条稳定、可复用、可监控的流水线。适合正在做测试设计、质量保障的QA同学，也适合想用RAG和工作流工具解决实际问题的研发同学。
先说结论：单纯让AI“写”测试用例，效果很不稳定。真正管用的是把“业务知识”和“生成流程”拆开，知识库负责记住历史规范，工作流负责控制生成节奏，AI只做最后一公里的理解和创作。这个思路，就是整套流水线的底座。
1. 为什么AI写的测试用例总让人哭笑不得
1.1 “失忆症”到底是怎么来的
大模型本身是一个“无状态”的推理引擎。你问它一次问题，它会基于你给的上下文和它的参数化记忆来作答，但它不会天然记住你上周给它看过的PRD细节，也不会自动继承昨天刚确认的某个业务规则。这种“失忆”和“记性差”的阶段，在测试用例生成场景里会放大成几个具体毛病：
- 上下文窗口有限。长PRD塞不进去，塞进去之后被中间内容截断，模型只记得开头几章，后面的业务规则直接丢失。
- 规则优先级混乱。需求文档里经常出现“特殊情况下做X处理”“老用户走旧逻辑”这类表述，模型如果不知道哪条规则优先，就会生成自相矛盾的用例。
- 历史经验不可复用。同一个模块，一季度上线过类似功能，当时发现过边界条件。模型不知道这些经验，第二轮生成时照样踩坑。
- 术语不一致。接口字段叫“userId”，需求文档里写“用户ID”，模型可能生成“user_id”“用户标识”“会员ID”，导出用例后QA还得手工统一。
这些问题本质上不是“提示词写得不好”，而是模型缺少“稳定、可追溯、可更新的记忆层”。这时候知识库的作用就体现出来了：它不是简单地把文档丢给AI，而是把测试用例生成需要用到的业务规则、历史经验、术语定义全部结构化存储，让AI在生成前按需检索，拿到的每一条知识都有出处、有版本、有模块归属。
1.2 单纯调Prompt为什么走不通
很多团队一开始的思路是“多写点提示词，把规则写详细”。我也试过，效果短期能提升，但长期不可维护。举个例子，你给Prompt里写了一堆业务规则，过两周业务调整了，你要改Prompt，还要重新测一遍所有生成质量。而且Prompt越长，模型越容易忽略中间内容——业界叫“lost in the middle”。与其把所有规则塞进Prompt，不如让Prompt保持精简，只负责定义“输出的格式和推理的边界”，把具体业务知识交给知识库去检索。
这就引出一个关键判断：AI测试用例生成，瓶颈不在“写”，而在“组织输入”。工作流要解决的，正是“怎么把合适的知识在合适的时机送到AI面前”。
2. 知识库到底该存什么、怎么存
2.1 别把知识库当成垃圾桶
我见过不少团队建知识库，什么文档都往里扔，结果检索出来的内容牛头不对马嘴。工业级的知识库，关键在于分层和分类。针对测试用例生成场景，我把知识库拆成四类：
- 需求知识库：PRD、业务说明、用户故事，重点是原始需求和行为描述。
- 接口与协议知识库：接口文档、字段定义、错误码、时序图，重点是技术约束。
- 历史用例库：已经评审过的、线上验证过的存量测试用例，重点是老模块的覆盖模式。
- 规范与模板库：公司内部的测试用例模板、命名规范、优先级定义、特殊场景规范。
四类知识分开存，而不是混在一个数据集里。为什么要分开？因为检索时的用途不一样。生成新用例时，如果同时检索到PRD片段和历史用例片段，模型容易把旧用例细节当成新需求来用，造成“张冠李戴”。分开后，我在工作流里可以控制检索来源，比如“历史用例只作为风格参考，不作为功能依据”，这样生成结果会更可控。
2.2 Word、PDF、Excel解析的真实坑
知识库里最常见的就是Word和PDF文档。解析这块踩坑最多，我踩过的几个典型问题在下面：
- PDF表格解析丢失：很多PRD的表格被解析成纯文本后，列与列之间的对应关系完全丢失。比如字段表格变成了“字段名 类型 必填 说明”的流水文本，模型无法判断“是否必填”对“字段A”的约束。
- 页眉页脚混入正文：公司内部文档页眉通常带“机密”“项目名”“版本号”，如果不去除，检索时这些高频词会干扰相似度计算，导致召回结果偏差。
- 扫描件和图片型PDF：OCR如果不做，检索直接失败；做了OCR，精度又影响后续。
- 多级标题层级丢失：文档目录和标题层级没保留，模型无法区分“2.1 规则详情”和“3.1 规则详情”哪个是新规则。
针对解析，目前稳妥的做法是用Unstructured、PyMuPDF这类工具做分层解析，先识别页面结构，再按标题层级分段。分段参数是知识库建设里最需要调的核心变量，我用的经验值如下：
- chunk_size（块大小）：一般设置在500-800字之间。太小则上下文太碎，模型读不出完整规则；太大则检索命中后context过长，浪费token，还容易掺入无关信息。
- chunk_overlap（重叠量）：设置在80-150字。保证被切开的句子和段落不丢失关键信息。
- 强制分隔符：在Markdown标题、列表项、表格行处强制分段，优于按字符数硬切。
有一个参数容易被忽略：embedding模型的文本上限。比如用OpenAI的text-embedding-3-small，最大输入是8191个token；用BGE等开源模型则要看具体配置。如果chunk_size设置超过embedding模型上限，超出部分会被截断，检索效果直接打折。所以建库前先确认嵌入式模型的规格。
2.3 元数据决定检索的“边界”
工业级的检索不能只靠语义相似度，还得靠元数据过滤。每条知识都得有属性标签，我常用的几个：文档ID、模块名称、版本号、知识类型（需求/接口/历史用例/规范）、上架时间、适用环境。
这个设计在实践里很有价值。比如生成“退款”模块的用例时，工作流可以先通过元数据把检索范围锁定在“模块=退款”“知识类型=需求/接口”“版本>=当前迭代”，再执行向量检索。缩小候选集之后，召回准确率会明显提升。很多工作流平台（比如Dify、Coze）都提供了元数据过滤能力，后面实操部分我会详细说。
3. 工作流才是“流水线”的灵魂
3.1 先把流水线拆成节点，再动手搭
建流水线之前，最忌讳一上来就拖节点。我习惯先把“需求文档进来、用例文件出去”这个过程拆成几步，每步定义清楚输入输出：
- 需求输入：上传或选择PRD、接口说明。
- 文本清洗：去掉页眉页脚、编辑批注、无关跳转链接。
- 内容切片：按标题层级和段落结构切块，打上模块标签。
- 知识检索：根据模块和关键词，从知识库召回最相关的规则片段。
- 组装上下文：把召回结果按“需求片段+接口片段+规范片段”重组，控制总长度。
- 引导生成：给模型明确的用例格式、优先级规则和覆盖要求。
- 质量校验：检查必填字段、用例编号、预期结果完整性。
- 导出分发：生成结构化用例文件，推送到测试管理平台。
这个流程里，AI只出现在“引导生成”和“部分校验”环节，其他环节都是确定性逻辑。这样安排的好处是：可调试、可监控、可部分回退。比如检索效果不好，我可以单独优化检索节点，不用把整条链路推倒重来。
3.2 用什么工具搭：Dify、Coze还是自研
目前主流的工作流工具有Dify、Coze（扣子）、n8n等，实际选型我建议按需来：
- Dify：偏向“企业私有化知识库+可视化工作流”，支持本地部署，知识库管理能力较强，适合公司数据不能出内网的场景。它允许创建数据集、设置元数据、做召回测试，工作流里也有知识检索节点。我在这套流水线里主要用Dify。
- Coze（扣子）：插件生态丰富，适合快速验证创意和接入第三方服务。如果需求变化快、想快速做一个Demo看效果，Coze上手很快。但要注意它的知识库在免费版会有一些使用限制，适合原型验证。
- n8n：偏自动化集成，适合做跨系统的复杂编排，比如测试用例生成后自动创建缺陷单、自动通知评审群。
- 自研代码：如果团队已经有用Python/Java写的测试工具链，直接用LangChain或自建RAG链路也是可行的，灵活度最高，但要自己维护。
我的建议：第一版用Dify或Coze快速跑通，验证“知识库+工作流”的组合效果；等确认方向没有偏差，再根据集成深度决定是否过渡到自研链路。没见过一个团队第一版就自研还能快速见效的。
3.3 关键节点的“为什么”
工作流里有两个节点我要单独讲一下，因为它们最容易踩坑。
第一个是“文本清洗”。我们公司的PRD经常混合了当前版本和废弃方案，AI如果读到废弃章节，生成的用例就会包含旧逻辑。清洗节点里我做了两个规则：一是把“不再使用”“已废弃”“历史遗留”等关键词所在的段落从检索候选里剔除；二是通过正则把版本号和修订记录统一提取为元数据，不参与语义检索。这样能显著减少“死灰复燃”的旧规则。
第二个是“多路召回”。只靠向量检索，经常出现“语义相近但业务不符”的问题。比如“输入金额”这个词，向量检索召回了“充值金额”的规则，但当前模块是“退款金额”，两者虽然语义相近但业务逻辑完全不同。我在工作流里加了一个混合召回节点：一路向量检索，一路关键词检索（精确匹配“退款”“金额”等术语），然后做“取并集后按相关性排序”。实测混合召回对比单纯向量召回，命中准确率提升约30%。
4. 工业级用例的“质检关”：怎么让AI不胡说
4.1 测试设计方法如何嵌入生成任务
光有知识库还不够，模型没有“测试思维”，生成的用例就只是“需求的复读”。工业级用例必须体现设计方法：等价类、边界值、场景法、判定表等。我的做法不是靠模型悟，而是在工作流里显式注入测试设计约束。
举个例子，需求里写了“充值金额范围为1-10000元”，好的测试用例设计者会想到这些用例：
- 合法有效类：1元、10000元、500元
- 非法无效类：0元、-1元、10001元
- 边界值：1元和10000元本身就是边界，还要测0.99、1.01、9999.99、10000.01
- 类型异常：空值、小数、字母、特殊字符
- 业务冲突：账户冻结状态发起充值、超过单日限額
这套思维要用Prompt模板写进“引导生成”节点，并配合知识库检索到的具体业务规则，比如“账户冻结”的判据来自接口文档。这样才能生成既符合通用测试理论、又不脱离具体业务的用例。
4.2 加一个“自检Agent”做质量门禁
生成完用例不能直接入库。我在工作流里加了一个“用例自检Agent”，它对同一条需求做二次推理，检查生成结果是否满足我预设的质量标准。常见的检查维度有：
- 用例标题是否包含“前置条件-操作步骤-预期结果”三要素
- 预期结果是否具体可验证，而不是“界面显示正常”这种模糊表述
- 用例编号是否符合命名规则
- 是否有重复用例
- 是否覆盖边界值和异常场景
自检Agent的做法很简单：把生成结果回传给同一个大模型，加上检查清单Prompt，要求它把发现的问题以JSON格式输出，不合格的用例会被打回重写。这个过程本质上是让模型做一次“自我反思”。注意，自检Agent的温度参数要设得比生成Agent低，比如0.1，这样它更容易发现问题而不是自由发挥。
4.3 防幻觉的几个土办法
防幻觉不能只靠写“别乱编”这种提示词。我总结出三个在实际业务中有效的手段：
- 强制溯源：Prompt里要求每条用例必须引用知识库来源片段编号（比如“规则来源：PRD-3.2.1”或“接口字段：refundAmount”）。如果某条用例没有来源，就让校验节点标记为“待人工确认”，而不是直接丢弃。
- 限制生成范围：明确告诉模型，只基于工作流传到上下文里的知识生成，不要使用训练阶段的外部记忆。这个约束在知识库的Prompt模板里写死。
- 业务矛盾检测：在工作流里嵌入一个“矛盾检查”节点，把新生成的用例规则和已有历史用例的规则做一致性比对，发现“旧规则说X，新用例写Y”的情况就打标记，交给评审人确认。
这三种方法不能100%杜绝幻觉，但能把幻觉率压到可用级别。我的实测数据：没有溯源约束时，AI生成用例里约15%的断言引用不存在；加上溯源约束后，降到3%左右。
5. 从零搭建这套流水线的完整实操过程
下面我拿一个具体场景走一遍：用Dify本地部署，搭建“退款功能测试用例生成流水线”。假设我们已经有一份退款功能PRD、一份退款接口文档、若干历史用例。
5.1 建库实操
第一步，在Dify中创建“知识库-退款需求”，上传PRD文档。上传时选“分段设置”，我手动把chunk_size设为600、overlap设为100，分段标识符按“###、##、换行”切分。这个配置对大多数PRD都适用。
第二步，创建“知识库-退款接口”，上传接口文档。这个数据集的元数据字段设为“模块=退款”“接口名=refund/create”。
第三步，确认检索测试效果。在Dify的知识检索测试页里，输入“退款金额超过原订单金额怎么处理”，看返回的片段是否包含规则说明。如果没召回，先检查分段设置是否把那段规则切掉了，再检查embedding模型的相似度阈值，一般0.2-0.3之间是比较合适的初始值。
5.2 编排工作流实操
在Dify中新建工作流，按以下顺序拖节点：
开始节点：输入参数为“需求文档”“目标模块”。
文本提取节点：解析用户上传的文档，得到纯文本。注意Dify文档提取节点对PDF扫描件支持一般，扫描件建议先走OCR。
知识检索节点：添加两个检索节点，分别从“退款需求”库和“退款接口”库召回。检索关键词用“目标模块+核心业务动作”，TopK设为6。
上下文组装节点：这个是关键。我用一个Python节点，把两个知识检索结果按“需求规则在前、接口定义在后”拼接，截断总长度在4000字以内，留出生成空间。
LLM生成节点：输入上面组装的上下文，Prompt模板如下：
你是一名资深测试工程师，请根据以下需求规则和接口定义，生成该模块的功能测试用例。要求：
- 覆盖正常流程、异常流程、边界值、空值、特殊字符。
- 每条用例包含用例编号、模块、优先级、前置条件、测试步骤、预期结果、规则来源。
- 不得编造需求规则以外的业务逻辑。
- 以Markdown表格输出。
LLM校验节点：把生成的Markdown表格回传，检查职责和必填字段，不合格则要求模型修改。
输出节点：以文本形式输出最终用例。
这里有一个值得强调的细节：LLM生成节点的temperature建议设为0.2，低温度能让输出更服从格式指令；知识检索节点的TopK不要贪大，我测试过TopK=10时，填充上下文过多，模型反而“挑花了眼”，生成用例质量下降。
5.3 第一次跑的实测效果
我第一次用这套工作流生成退款模块用例，输入PRD和接口文档后，得到31条用例。人工审下来，有效用例24条，冗余3条，缺边界值场景4条。对比我之前纯手工编写的28条用例，数量上超过，但边界场景确实有漏。我把校验节点强化，在Prompt里显式列了“金额、数量、日期、状态枚举必须测边界”，第二轮跑出来33条，人工确认有效用例29条，基本达到可直接评审的水平。
5.4 从“可用”到“好用”的调优
第一次跑通只是开始。后续我做了几个调优，让流水线真正“工业级”：
- 在知识库里录入评审通过的历史用例，把“优质历史用例”标记为高权重知识，让模型生成时参考其结构。
- 把经常出错的需求术语（比如“用户ID”与“userId”）加入术语表，写入知识库和Prompt，减少字段名混乱。
- 将输出格式从Markdown表格改成JSON结构，方便下游测试管理平台自动解析。
改完之后，整套流水线的端到端耗时从手工写用例的平均4小时降到了15分钟以内，人工参与强度大幅下降，参与内容也从“逐条编写”变成“评审和补漏”。
6. 常见问题排查与避坑心得
6.1 知识库检索不到内容的五个原因
- 分段过小，把完整规则切碎了，导致关键词分散。解决：调大chunk_size或检查分隔符。
- 元数据过滤过严，比如“模块=退款”写成了“模块=退款模块”，大小写或命名不一致。解决：检查数据集属性和过滤字段匹配。
- 相似度阈值设得过高。解决：阈值先放开到0.2，跑一轮检索测试再收紧。
- 文档本身是扫描件或图片型PDF，没有走OCR。解决：解析阶段加OCR步骤。
- embedding模型不匹配，比如建库时用的模型和检索时用的模型是不同版本。解决：统一模型，重跑向量化。
6.2 生成质量不稳定的排查清单
- 上下文被截断：组装节点拼接后超过模型上下文长度，优先裁剪历史用例部分，保留需求规则。
- 检索结果跑题：检查输入给检索节点的关键词是否和当前模块一致。
- 温度过高：生成节点温度过高会导致格式漂移，统一把生成温度调到0.2-0.3。
- 输出格式约束不足：Prompt里要明确定义格式和字段，否则再强的模型也会发挥。
6.3 我踩过的一个元数据坑
之前我在Dify里按“模块=充值”过滤知识库，结果召回结果里还是混入了“提现”模块的规则，排查了半天发现是数据集上传时，元数据值我填的是“充值/提现”而不是“充值”，过滤匹配不上，规则被Dify当成“未设置元数据”直接放行。后来我养成了一个习惯：每条知识上传后，都做一次“过滤抽查”，用模块关键字手动检索一遍，确认过滤规则真的生效，再继续往里喂数据。
这个坑其实很有代表性，说明元数据建设不是一个“配好就不动”的工作，而是需要随业务变化持续维护的治理工程。
最后再分享一个实用的细节
搭建这套流水线之后，我最大的体会是：AI做测试用例，真正难的从来不是“让模型学会设计用例”，而是“让模型每次都在同一套稳定的规则和知识约束下做设计”。知识库给了模型“记忆”，工作流约束了模型的“行为边界”，二者组合起来，AI才从一个“偶尔灵光一现的助手”变成一个“可预期、可评审、可迭代的生产工具”。
再补充一点个人建议：流水线跑通后，记得把“人工评审后修改的用例”定期回灌到知识库里。这是知识库质量持续提升最关键的一步，很多团队建好库就不管了，过一个月回头再跑，生成质量和第一周差别不大，原因就是知识没有持续更新。这个动作会让你第二个月、第三个月的生成效果稳步往上走，时间越长，这套知识库+工作流的复利价值就越明显。
