AI测试用例生成流水线：知识库+工作流解决AI失忆问题

先说一个让我头疼很久的现象：AI 辅助测试用例生成这件事，单看第一轮效果都还不错，但只要需求稍微复杂一点——涉及历史缺陷、业务规则、字段边界、上下游依赖——模型就开始“失忆”。不是漏掉关键前置条件，就是一本正经地编造不存在的字段。试过几次之后我意识到，问题不在模型本身，而在我们给模型喂的上下文太随意了。纯粹靠一段 prompt 就想让 AI 产出稳定、可复用的工业级测试用例，基本是赌运气。

后来我换了一套思路：把“知识”和“流程”拆开，让知识库负责给 AI 提供长期记忆，让工作流负责把生成过程固化成稳定的流水线。这套方案跑通之后，用例生成不再是每次从零开始的聊天，而是一条可配置、可追溯、可评测的生产链路。这篇内容就围绕这套流水线的设计思路、关键环节、具体配置和踩坑记录展开，适合正在做 AI 测试提效、想搭知识库工作流、或者被“AI 生成用例质量不稳定”折磨过的测试工程师参考。

1. 为什么 AI 生成测试用例会“失忆”

先说个结论：大多数 AI 生成测试用例翻车，不是模型不够聪明，而是我们没有处理好“短期记忆”和“长期记忆”的关系。模型的上下文窗口是典型的短期记忆，给多少内容就只能看多少内容，一旦信息超出窗口，前面再重要的规则也会被挤掉。而知识库相当于长期记忆，工作流则负责在正确的时间把正确的记忆调出来。

1.1 上下文窗口的“短期记忆”局限

当你在对话框里上传一份需求文档，再贴上一堆历史用例，让 AI“参考这些内容生成测试用例”时，模型其实是在用有限窗口做高难度注意力分配。我实测过，超过一定长度后，模型很容易出现“只记得文档开头”“只记得最后几条要求”的情况，中间的边界条件全丢。更隐蔽的问题是，如果同时塞入多份文档，模型会把不同维度的知识混在一起，结果生成出的用例既不像 A 业务，也不像 B 业务。

所以，单纯扩大 prompt 长度是条死路。窗口再大也有上限，而且内容越长，推理质量和输出稳定性越差。我见过很多团队误以为“上下文越长越专业”，实际上 4k 和 128k 的模型在长上下文下的用例生成质量差异并不像参数上那么美好，甚至会因为注意力分散而出现更严重的幻觉。

1.2 知识库负责“长期记忆”，工作流负责“肌肉记忆”

知识库的价值在于，它把项目沉淀下来的规范、历史用例、缺陷报告、业务规则、字段字典，切成小块后做向量化和索引。AI 在生成用例的某个具体环节时，只检索当前这一步需要的知识，而不是把整个文件全塞进去。这就是 RAG（检索增强生成）的核心逻辑——让模型“按需查资料”，而不是硬背整本书。

工作流的价值则是把“查资料—思考—生成—校验”的过程固化下来。没有工作流时，每次生成都在依赖使用者的临场发挥：你这次写了不错的 prompt，下次换个同事操作，结果可能完全不一样。有了工作流之后，每个节点的参数、系统 prompt、知识库检索策略、输出格式都是固定的，即便是新人也能跑出质量稳定的用例。用大白话说：知识库是给模型补课，工作流是给模型定流程，二者缺一不可。

2. 整体设计：从“聊天问答”到“生成流水线”

我最初也尝试过直接写一个 Agent 让它自己决定怎么查资料、怎么生成，效果非常不可控。Agent 虽然能自主调用工具，但在测试用例生成这种需要严格遵循业务规则和边界条件的场景里，自由度越大，翻车概率越高。后来我改成“半自主”的流水线设计，把关键决策点固定住，只保留必要的灵活性。

2.1 流水线的四个阶段：需求解析、知识检索、用例生成、校验输出

我把流水线拆成四个固定阶段，每个阶段对应工作流里的一个或几个节点：

第一阶段是需求解析。用户输入一段需求描述，工作流先用一个“解析节点”把需求拆成几个要素：功能模块、操作角色、核心业务规则、涉及的数据字段、异常场景等。这一步不是为了生成用例，而是把模糊的自然语言转成结构化信息，后续的检索和生成才能有明确的依据。

第二阶段是知识检索。根据解析出来的模块、字段、角色等要素，去知识库里检索最相关的规则、历史用例、缺陷记录和边界约定。这里要控制检索数量，不要贪多，一般取 3—6 条最相关内容即可。接得越多，模型越容易抓不住重点。

第三阶段是用例生成。把“需求解析结果 + 检索到的知识片段 + 生成规范模板”一起交给大模型，让它输出测试用例。这一步的 prompt 需要非常结构化，我会在第 4 部分详细说明。

第四阶段是校验输出。检查模型生成的用例是否有格式错误、是否重复、是否缺少必填字段，必要时还要做规则层面的字符串匹配，比如“用户名为空”“支付金额为负数”这些核心边界条件是否覆盖。校验不过就驳回重生成，或者标记为“待人工评审”。

2.2 选型：为什么用 Dify/Coze 这类编排平台，而非纯代码

我自己最早是用 Python 脚本直接调大模型 API，配合向量库自己写检索逻辑。好处是灵活，坏处是迭代慢：改一个检索参数要改代码，改一个 prompt 要重新部署，团队里的测试同学又看不懂代码，协作效率很低。

后来我换成了 Dify 和 Coze 这类工作流编排平台。它们具备几个关键能力：可视化编排节点、内置知识库管理、支持配置多种模型、提供 API 接口供现有测试平台调用。更重要的是，非开发人员也能自己调整节点里的提示词和参数，把“会写用例的测试专家”和“会调流程的技术人员”分开，两个角色可以并行协作。

如果你的团队已经有成熟的测试平台，也可以考虑用 Flowable 这类流程引擎或者其他更底层的方案。但我个人建议先别碰太重的工作流引擎做这种事——AI 生成流水线强调的是快速迭代和业务逻辑尝试，不是复杂的审批流程编排。轻量级工作流平台更合适，等逻辑完全稳定之后再考虑要不要长进内部平台。

2.3 不可省略的“人机协同”环节：哪些步骤必须人工介入

强调一个原则：AI 流水线负责“批量生成初稿”，而不是“直接可上线”。完全无人化的用例生成在多数业务场景里不现实，尤其在涉及资金、安全、数据合规的模块，AI 的推理能力还不足以替代人工判断。

我通常保留两个人工入口。第一个入口是需求解析后的确认：让测试工程师快速看一眼解析出的要素是否准确，如果 AI 把“支付金额”解析成“订单金额”，后续所有用例都会偏，这种错误越早发现成本越低。第二个入口是最终评审：AI 生成用例草稿后，由测试负责人批量导出到评审页面，逐条打标、修改、补充。保持“人审机器生成”的节奏，而不是“让机器自动入库”，这样既提升了效率，又保证质量和追溯性。

3. 知识库搭建：让 AI 具备“领域记忆”

知识库是整个流水线的根基。如果你直接拿着通用的“如何写测试用例”资料去建库，AI 生成的用例依然很空。真正有效的知识库，内容必须来自你的项目、你的业务、你的历史沉淀。

3.1 建库前的准备工作：收集规范、历史用例、缺陷库

第一步是盘点已有资产。我建的第一个知识库项目，收集了四类资料：业务需求文档、需求澄清记录、历年测试用例归档、线上缺陷库里的典型 bug 描述。注意不是把文件整个丢进去，而是先做“清洗”——删掉与测试无关的废话、重复内容、过期规则，把核心信息提炼成更小的知识块。

举个例子，一份 30 页的需求文档里，真正对测试用例有用的是十来条业务规则和字段约束，其余全是背景介绍和商业目标。建库时我会把业务规则提取成“模块—规则编号—规则内容—触发条件”的形式，存储为 markdown 或结构化文本。这样向量化之后的检索精度远高于直接切片整份文档。

3.2 文档解析与分块策略：PDF/Word/Markdown 如何处理

Dify 和 Coze 都支持直接上传 PDF、Word、Markdown，但解析效果参差不齐。Word 和 Markdown 相对好处理，PDF 如果带复杂表格或扫描件，经常会出现乱码、错位、丢字。我的经验是：复杂表格优先转成 CSV 或结构化文本后再入库，纯图片型 PDF 建议先做个 OCR 预处理，或者干脆人工转成 Markdown。

分块策略上，不要用默认的固定长度硬切。那种“每 500 字符切一块”的方式会把一个完整的业务规则拦腰截断，检索时拿到的是一半知识，AI 自然蒙圈。更好的做法是按语义边界切分，比如按标题、段落、表格行、规则条目来分块。Dify 里可以自定义分段标识符，我用过的比较顺的组合是：以“## ”“### ”作为一级二级分段点，同时设置最大块长度，遇到长段落再二次切分。

3.3 向量化与元数据设计：多用标签，少用全文检索

分块完成后，下一步是向量化。这一步的关键不是选哪个 embedding 模型，而是元数据设计。你给每个知识块挂的标签，决定了后续检索能不能精准过滤。

我强烈建议每个知识块都带这样几类元数据：所属模块、业务类型、适用场景、风险等级、来源文档、版本号。比如一条“用户名为空时提示‘请输入用户名’”的规则，可以打上“登录模块、账号体系、异常场景、P0、需求文档 v2.3”。这样流水线在检索时就可以先用元数据过滤掉无关模块，再在缩小后的集合里做向量相似度匹配。省时省力，还明显减少“检索到别的模块知识”的尴尬。

3.4 知识库维护：测试用例知识如何持续更新

知识库不是建完就完事了。需求文档会改版，缺陷会不断出现，旧规则会失效，如果不维护，AI 会拿着过期的知识一本正经地生成错误用例。我给自己定了个习惯：每两周做一次知识库增量刷新，把新增的需求变更、已关闭的典型缺陷、评审通过的优秀用例回流进去。

回流不是把文件重新上传一遍，而是把增量内容也按“分块—打标—向量化”的流程处理。如果平台支持“知识库版本”或“文件替换”，尽量保留历史版本，方便回溯哪些知识导致生成行为发生变化。另外，建议定期抽查检索召回结果：随机挑几条 query，看看检索出的 top5 知识块是否合理，这是最直接的知识库健康度检查方法。

4. 工作流编排：把生成过程变成稳定流水线

知识库解决“AI 知道什么”，工作流解决“AI 怎么做”。我把整个编排过程拆成四个核心节点，所有参数都尽量写死或做成可配置项，避免每个使用者拿着不同的思路乱调。

4.1 第一步：需求解析节点的设计与 prompt 写法

需求解析节点本质上是让大模型把用户输入的一句话或一段描述，转换成固定的 JSON 结构。我常用的输出结构包括：module、action、business_rules、data_fields、preconditions、scenarios。其中 business_rules 是后续检索的关键，我会要求模型列出原文里的明确规则，而不是自作主张补充。

系统提示词里可以强调“只做信息抽取，不做测试设计”。这一点很关键，因为一旦模型在解析阶段就开始生成用例，输出质量会非常不可控。准确的信息抽取比“显得聪明”重要得多。实测下来，把这个节点的 temperature 调到 0，能有效减少抽取字段的随机性，让每一次解析结果更一致。

4.2 第二步：知识检索节点——topK 与相似度阈值怎么调

知识检索节点要给模型提供相关资料。Dify 和 Coze 里都能设置检索数量 topK 和相似度阈值。这两个参数最需要调，也最容易踩坑。

topK 我一般设置在 4—8 之间。太少了容易漏知识，太多了模型会陷入“信息过载”，分不清哪些是当前需求真正要用的。相似度阈值则用来过滤不相关内容，常用的区间在 0.3—0.5 之间，具体取决于你选的 embedding 模型和知识块质量。如果检索结果经常出现无关内容，说明阈值太低；如果很多该召回的知识都没召回，说明阈值太高或者知识块分得太碎。

另外，务必开启“引用知识来源”之类的功能。后续人工评审时可以点击跳转到原始文档，确认为什么 AI 会这么做，这块知识是否可信。这个能力在排查“AI 生成了错误规则”时特别救命。

4.3 第三步：生成节点的 prompt 结构模板

这个节点的 prompt 是整个流水线里最重要的部分。我建议不要写段落式长文本，而是用结构化模板：

• 角色设定：说明你是某项目的资深测试工程师，熟悉等价类、边界值、场景法等测试设计方法。
• 任务背景：给出需求解析结果和知识检索结果，并明确告诉模型“以下内容仅作参考，不得编造不存在的规则”。
• 生成要求：包括用例编号命名规则、步骤描述格式、预期结果需包含具体提示信息、每个用例必须关联业务规则编号。
• 输出格式：用 JSON 数组，每个元素包含 module、case_title、preconditions、test_data、steps、expected_result、rule_id。

我还会在 prompt 末尾加一句强制约束：“如果检索到的知识不足以支撑某条用例，请输出 NOT_SUPPORTED 并在备注中说明，而不是猜测。”这一步能大大减少 AI 编造规则的幻觉。

4.4 第四步：输出校验节点——JSON Schema + 规则校验

生成节点的输出不能直接入库。我先接一个代码/校验节点，用 JSON Schema 校验结构完整性：字段是否齐全、类型是否正确、steps 是否为空、rule_id 是否存在于知识库的规则列表中。这些校验用 Dify 的代码节点或者 Coze 的代码块都能实现，我一般写一个几十行的 Python 函数，输入是模型输出，输出是检查结果。

校验不通过的情况分两类：一类是硬性格式错误，直接重试生成，并让模型参考第一条错误信息修正；另一类是逻辑性问题，比如“预期结果与步骤不一致”“用例重复”，这种我会打上“待人工评审”的标签，而不是反复让模型重写。经验是，一个节点最多重试 2 次，超过 2 次还失败，说明上游知识检索或需求解析有问题，应该到上游排查，而不是死磕生成节点。

5. 测试用例设计方法在工作流中的落地

很多测试同学问：工作流平台里到底怎么体现“等价类、边界值、场景法”这些设计方法？答案是通过 prompt 和校验节点写进去，让 AI 在生成过程中有意识地去套这些框架，而不是零散地“想一条写一条”。

5.1 等价类与边界值如何“翻译”给 AI

我在生成节点的 prompt 中会专门加一节“设计方法约束”，建议 AI 按以下顺序处理：先识别有效等价类和无效等价类，再对每个等价类的边界值单独生成用例。比如“优惠券金额需为 0—100 之间的整数”，AI 应该生成的边界用例包括：金额为 0、金额为 100、金额为 99、金额为 101、金额为 -1、金额为 1.5（非整数）、金额为空。这组用例刚好覆盖了有效边界、无效边界、特殊取值。

同时，在代码校验节点里我还会加一条规则：检查是否存在“最大合法值 +1”和“最小合法值 -1”这类相邻边界用例，如果没有就提示补充。这属于规则兜底，即使模型漏了，流程也能把它捞回来。相比完全依赖模型自己思考，这种“显式规则 + 自动检查”的方式稳定得多。

5.2 场景法与状态迁移法的实战结合

对流程型功能，比如“下单—支付—退款”这类多步骤业务，我会在需求解析节点里要求模型识别出核心场景链路，并在生成节点中提示“按主成功场景、备选场景、异常场景三个维度设计用例”。这里要注意，不要让 AI 只写单个步骤的用例，而是鼓励它生成“端到端”的场景用例，因为它可以从需求解析结果里拿到整条链路的业务规则。

状态迁移法适合订单状态、审核状态这类强状态机业务。我通常在知识库里预置一份状态流转图描述文本（比如“待支付—已支付—已发货—已完成—已取消”），然后让 AI 检验每条状态转换的合法性和非法性。比如“已发货状态能不能直接取消”，规则如果没定义，AI 就输出 NOT_SUPPORTED 并进入评审环节，而不是自己臆造。

5.3 如何防止 AI 生成“表面正确”的无效用例

AI 生成用例最容易踩的坑是“看起来很专业，实际上根本不可执行”。比如步骤写“输入非正常手机号”，但没说具体是 11 位数字以 13/15/18 开头之外的情况，还是 10 位数字，还是空字符串。不是 AI 没能力说清楚，而是 prompt 没要求它说清楚。

我在生成节点的 prompt 里明确要求：每个用例的 test_data 必须是可执行的具体值或明确的取值规则，steps 必须包含前置条件、操作步骤、输入数据，预期结果必须包含系统反馈的具体提示信息。同时我会在人工评审页面把“含模糊词汇”的用例自动打标，比如“非正常”“非法”“其他”“不存在”等词，提醒评审人重点确认。这套“模糊词打标”机制帮我们过滤掉了大量无效用例，效果立竿见影。

6. 常见问题与排查技巧实录

跑通一套流水线不难，难的是让它稳定。下面这些问题都是我在实际搭建和使用过程中真实遇到过并解决的，整理成速查表，方便你遇到类似问题时直接对照。

6.1 知识库检索不准，问题可能不在向量模型

很多人遇到检索不准就先换 embedding 模型，但大多数时候问题出在文档分块和元数据设计上。我调试过最典型的一个案例：某模块的业务规则都写在同一个文件里，默认分块后，不同章节的内容混在一起，检索手机号规则时把支付金额规则也带出来了。后来按“章节—小节—规则条目”重新分块，准确率立刻上去了。

建议你先做一次“检索抽样测试”：准备 5—10 条典型 query，逐个检查知识库召回的前 5 条内容，看看哪些是相关、哪些是误召回。如果误召回集中在某个文件或某个标签，优先优化那部分的分块和标记。换模型反而可能引入新的差异，不必要轻易动。

6.2 上下文超限与知识碎片化，怎么平衡

知识块太小，检索精度高，但一个完整规则可能被切断；知识块太大，信息完整，但容易带入无关内容。我通常用“最小完整语义单元”作为分块大小：一个规则条目、一个数据字典表格、一个小节，都不拆开；如果超过平台单块上限，再按句子边界切。

另外，上下文超限还有一个常见来源：把多个知识块全部拼进 prompt。我建议按照“召回顺序+相关度分数”截取前 N 块，并去除与当前字段无关的内容。很多工作流平台支持在检索节点的后续节点里做“知识过滤”，别忽略这个功能，它比在生成节点反复强调“只看相关内容”更有效。

6.3 模型输出的格式问题，用“错误反馈重试”解决

工作流平台里，模型输出的 JSON 经常出现多一个逗号、少一个引号、多出注释文字之类的问题。直接让模型重试往往还是同样的错误。我的做法是：在代码校验节点里返回具体错误信息，比如“第 5 个 JSON 对象缺少 expected_result 字段”“steps 必须为数组”，然后把错误信息拼回生成节点让模型修正。这种带反馈的重试，成功率远高于简单说“请重新输出”。

如果连续两次重试仍然失败，我建议直接中止流程并把原始输出转发给人工处理，而不是无限循环。无限重试浪费 token，也容易把流程卡死，在工业级场景里成本很难接受。

6.4 用例覆盖不均衡，如何在流程层面兜底

模型生成用例时往往集中在它认为“重要”的规则上，冷门规则容易被忽略。我在生成节点之后增加了一个“覆盖检查”节点：先把需求解析得到的 business_rules 列表提取出来，再统计生成的用例里 rule_id 覆盖了哪些，没覆盖的规则会提示“该规则未生成任何用例，是否需要补充”。这一步可以做成自动触发，也可以做成评审时的人工提醒，取决于你对自动化程度的期望。

7. 从“能跑”到“工业级”：质量度量与持续优化

流水线搭建完成只是第一阶段，后面更重要的运行观测和持续优化。如果连“当前生成的用例到底好不好”都说不出来，那这套系统就永远停在“能跑”的阶段。

7.1 用例生成的四个衡量指标

我日常会盯着四个指标：

第一个是“用例可执行率”，也就是不需要改直接能拿去执行的比例。这个指标最直观地反映 prompt 和知识库的质量，低于 60% 说明流程存在问题。

第二个是“知识命中率”，也就是生成的用例是否有效引用了知识库规则。我会通过 rule_id 字段统计有多少缺失映射，如果缺失率高，说明知识库的规则覆盖和检索还不够好。

第三个是“无效用例率”，重点看有多少用例因为模糊表达、不可执行、纯凑数被打回。这个指标和“模糊词打标”“人工评审”强相关，能反映 AI 在测试设计逻辑上的真实水平。

第四个是“人工评审耗时”，统计生成 100 条用例需要评审多久。这是效率指标，如果比原来纯手写耗时还长，说明流水线引入的复杂度大于收益，必须回头优化。

7.2 反馈闭环：把评审结果回流到知识库

评审修改的记录不能白白丢弃。我习惯在测试平台里为每条用例打上“来源”“是否由 AI 生成”“人工修改了什么”三个字段，定期把这些修改记录汇总成新的知识块入库。例如评审人把“输入 10 位手机号”改成“输入 11 位手机号且首字符为 1”，这就是一条宝贵的边界规则，应该回流到知识库，让 AI 下次生成时自动吸收这次修正。

除此之外，缺陷库里的新 bug 也应该形成知识增量。一个线上反馈“金额为 0 时还能提交成功”，把它整理成一条“金额必须大于 0，等于 0 时应阻断提交并提示”的规则，入库后 AI 再遇到同类需求就会主动生成对应用例。这才是真正意义上“越用越聪明”的持续优化机制。

7.3 落地节奏建议：MVP 试点再推广

不要想着一次性搭出覆盖所有业务线的完美流水线。我建议先选一条规则清晰、历史资产充足的业务线做 MVP，比如登录注册、订单状态流转，先把知识库、工作流、评审流程完整跑通。这一步的目标不是省多少时间，而是验证“AI + 人工评审”的模式能不能稳定运转。

MVP 稳定后，再逐步扩大范围。每接入一条新业务线，都要回到第 3 部分的知识库搭建流程，重新清洗和打标该业务线的文档规则。这个阶段最大的瓶颈不是技术，而是知识库内容的整理维护，需要测试同学和业务方一起参与，不能只靠 AI 团队闭门造车。等到两三条业务线都跑出稳定指标，再考虑和现有测试平台深度集成，把 API 输出接进来，变成真正意义的生产流水线。

我个人在实际操作中体会最深的一点是：不要把这套系统当成“替代测试工程师的 AI”，而要当成“一个永远记得住规则、还能按固定流程批量出稿的实习生”。它最大的价值不是凭空写出多天才的用例，而是把项目里那些散落的需求文档、历史用例、缺陷记录，变成可检索、可复用、可追溯的工程资产。流水线搭好之后，AI 负责把重复劳动干完，人工只需要做判断题和补充题，这才是“工业级”的真正含义。

最后再分享一个小技巧：如果你的知识库刚起步，内容还不够全，别急着追求高相似度阈值。先用较低阈值多召回一些候选知识，让 AI 和评审人都看看“哪些内容被捡出来了”，这种方式能快速帮你发现知识库的盲区。等知识库内容丰满、检索结果稳定之后，再把阈值慢慢收紧。建知识库和调流程永远是一个不断试错的过程，保持数据在流动，比追求一次到位更实际。