先说一个让我头疼很久的现象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. 常见问题与排查技巧实录跑通一套流水线不难难的是让它稳定。下面这些问题都是我在实际搭建和使用过程中真实遇到过并解决的整理成速查表方便你遇到类似问题时直接对照。现象常见原因排查思路与解法检索到的知识不相关元数据过滤没生效或知识块语义切得不准先看召回结果的来源文档确认过滤条件再调整分块策略上下文超限检索到的知识块数量太多或单块过大减小 topK限制单块最大长度优先保证内容精度输出 JSON 解析失败模型输出夹杂解释文字或字段错乱强制明确 JSON 输出在生成节点前加 one-shot 示例校验失败后带错误信息重试用例重复度过高场景覆盖不足模型一直围绕同一规则生成在 prompt 里增加“必须覆盖不同业务规则编号”用去重节点做标题和步骤的相似度比对用例不切实际出现幻字段prompt 约束不够硬或知识库相关规则缺失在 prompt 里加“不得编造规则”对缺失知识输出 NOT_SUPPORTED并补充知识库人工评审修改量大生成质量底子差或知识库内容与业务不匹配建议先做“100 条用例抽样质量评审”定位是知识库问题还是 prompt 问题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 和评审人都看看“哪些内容被捡出来了”这种方式能快速帮你发现知识库的盲区。等知识库内容丰满、检索结果稳定之后再把阈值慢慢收紧。建知识库和调流程永远是一个不断试错的过程保持数据在流动比追求一次到位更实际。