Dify工作流实战：从需求稿自动生成功能测试用例的完整方案

Dify 这个东西，很多人第一反应是“搭个带知识库的对话机器人”，但真正用熟了以后，你会发现它最值钱的场景其实是把那些重复、琐碎、又特别吃经验的活儿给流程化。我最近一直在折腾的一个玩法是：把产品需求稿直接丢给 Dify，让它自动吐出功能测试用例。用下来最大的感受是，这活儿不是不能干，而是要想清楚怎么干。这篇就把我从零搭到实际跑通的完整思路、节点选型、提示词写法和踩坑记录都摊开来讲，希望能给正在用 Dify 做工程提效的同学一点参考。

先说结论：Dify 做“需求稿 → 测试用例”这件事，本质上是把“需求理解”和“用例设计”这两步交给大模型，但流程编排、输入约束、输出校验这些工程细节，决定它是玩具还是工具。尤其是要处理真实需求文档里那种“需求不明确”“边界条件缺失”“术语混乱”的问题，光靠一个 Chatflow 挂个大模型是不够的，得在 Dify 工作流里做分层处理。

1. 需求稿为什么能直接“喂”给 AI 生成测试用例

很多人觉得测试用例生成难，是因为用例本身不是“翻译需求”，而是“拆解需求”。一份需求稿里往往只有主流程描述，但测试人员要写的是主流程、异常流程、边界值、权限场景、数据组合、兼容性场景。AI 能干的，是把你喂进去的需求片段，按照你设定的规则去扩展成这些维度。

但这里有个前提：需求稿本身得“够格”。我试过直接丢一篇产品经理写的、只有几百字的 PRD，和丢一份带业务流程、字段规则、异常说明的完整需求文档，生成质量差了不止一个级别。Dify 工作流里做的第一步，其实不是“生成”，而是“判断输入质量”，这个在后面会说。

从实际效果来看，我自己跑通的路径是这样的：用户上传一份需求文档（Markdown、Word、TXT 都支持），上传完成后触发一个工作流，工作流先判断文档格式和长度，然后切片、提取关键字段规则，再把结构化结果拼进提示词，最后调用大模型按用例模板输出 JSON 格式的测试用例。整个过程从上传到出结果，一条主流程大概两到三分钟，成本基本就是大模型的 token 费用。

1.1 适合用这套流程的典型场景

不是说所有测试用例都适合让 Dify 生成，我跑下来的经验是，下面这几类场景收益最明显：

• 接口测试用例：需求稿里面对接口的入参、出参、鉴权方式描述得比较清楚时，生成效率极高，尤其是字段校验和状态码分支。
• 功能回归用例：版本迭代时需求变动点明确，可以让 AI 聚焦生成“变更影响面”相关的用例，不用把老用例全部重写。
• 表单类页面用例：涉及字段必填校验、长度限制、格式校验、联动关系的页面，AI 对这类规则性强的需求理解得最好。
• 商城、订单这类业务链路清晰的系统：有明确的状态流转和分支条件，AI 生成的用例覆盖度会比较完整。

相反，如果需求稿本身只有一句“优化用户体验，让页面更好看”，那不管工作流搭得多好，输出也是无米之炊。所以我在整个流程里专门加了一个“需求质量检查”的节点，低于阈值就直接返回补充建议，而不是硬生成。

2. 先想清楚用工作流还是 Agent，再动手搭

Dify 里面有两条路可以走：一条是 Chatflow/Workflow，一条是 Agent。很多人一上来就选 Agent，理由是“它能自己规划步骤”，但实际用下来，生成测试用例这种业务，固定流程明显优于自由规划。原因很简单：测试用例的产出格式必须稳定，步骤必须可控，token 消耗必须可预估，这些恰恰是 Agent 的弱项。

我的选择是 Workflow（工作流），而且是“文档上传触发”的工作流，不是聊天式输入。Dify 的老版本里用“Chatflow”也能做，但我更推荐纯 Workflow，因为用户不需要对话，只需要上传文件拿结果，纯 Workflow 的执行逻辑更简单，也更容易嵌入到内部工具平台里。

2.1 Workflow 节点编排的完整思路

我最终跑通的编排结构大致是：

1. 开始节点：接收一个文件变量（需求稿），同时接收几个非必填的参数，比如“测试重点范围”“是否包含接口用例”“用例输出语言”。
2. 文档解析与内容提取：把上传的文件转成文本，同时记录文件名和上传时间，方便后面拼上下文。
3. 内容分块：对超长文本做切片。这一步很容易被忽略，但非常关键，因为大模型上下文有限，而且长文本里信息密度低，全量塞进去后半段的需求经常被“淹没”。
4. 质量预检：用一次轻量模型调用，判断需求稿里是否包含功能描述、业务规则、异常分支、验收标准，返回一个质量评分。
5. 结构化抽取：将切片后的文本通过提示词抽取为“功能点列表”和“规则列表”，以 JSON 格式输出。
6. 用例生成主节点：把抽取结果、原始文档片段、用户指定的重点范围，一起拼进最终生成提示词，输出 JSON 数组。
7. 结果清洗与格式化：对模型输出做 JSON 修复。这一步兼职就是“屎山救火队”，因为不管是 GPT 还是 Claude，输出偶尔会带多余的解释性文字。
8. 结束节点：把清洗后的 JSON 以文件形式返回给用户下载。

这套流程看起来复杂，但每一步都是为了降低“不确定性”。测试用例要的是稳定，不是随机创意。

2.2 为什么每个节点都用“子工作流”封装

我强烈建议把“文档解析”“质量预检”“用例生成”分别做成了子工作流。Dify 的工作流编辑页面里，节点一多就会变得特别难维护，尤其是改动提示词的时候，经常要找半天。拆成子工作流以后，主流程看起来清爽，每个子流程还能独立测试。

举个例子，我的“质量预检”子工作流输入是文本，输出是 JSON 格式的评分和缺失项列表。“用例生成”子工作流输入是结构化抽取结果和原始片段，输出是 JSON 数组。这样主流程就像流水线一样，每一段都清晰。

3. 核心节点参数与提示词设计细节

这一节是本篇最“拿来即用”的部分。我直接把各个关键节点的参数和提示词模板整理出来，你拿去改改就能用。注意，Dify 版本迭代很快，我这里用的是目前社区版比较稳定的配置方式，如果你的界面略有差异，以你自己的版本为准。

3.1 文档解析节点的参数选择

Dify 里处理上传文件，工作流的“开始节点”要手动添加文件类型变量，注意要把“允许多文件”关掉，因为测试用例生成场景一次只需要一份需求稿。

变量配置参考：

接下来用“文档提取器”节点（Document Extractor）把文件内容取出来。这个节点在 Dify 1.x 的版本里叫法可能不一样，如果找不到，可以用一个简单的 HTTP 请求节点配合文件解析 API，但我建议优先用平台原生能力。

实际使用中，docx 格式的解析效果最好，Markdown 其次，PDF 经常出现表格乱掉的问题。如果你们的 PRD 是 PDF 格式，我建议在文档里先说明“请将表格内容截图或转成文字”，否则解析出来全是乱码，后面生成用例的质量根本没救。

3.2 超长需求如何做内容分块

长文本分块是整个流程里最容易被忽视的环节。我一开始图省事，直接把整个文档塞进提示词，结果 8000 字以上的需求文档，生成出来的用例后半段经常是在一本正经地“编”。

后来我改成按章节分块，每一块控制在 1500 到 2500 字之间，重叠 200 字，保证跨块的需求上下文不丢。Dify 工作流里可以用“文本处理”节点，选择“按分隔符切分”，分隔符配置成“#”，因为大部分 PRD 都用 Markdown 的标题层级。

分块之后，每块生成一次“局部用例”，最后再用一个汇总节点去重合并。这样做的好处是单个模型的注意力更集中，生成的用例更贴需求，代价是多几次模型调用，成本稍微高一点，但换来的是质量稳定。

3.3 质量预检是怎么用提示词实现的

这一节可能是很多人没想到的。我在正式生成用例之前，先让模型当一回“需求评审员”，判断需求稿质量。这步很关键，因为输入质量太差时，后面所有生成都是浪费时间。

质量预检提示词模板，我贴一下核心部分：

你是一名资深测试经理，正在评审一份需求文档。请判断文档中是否包含以下要素，并严格输出 JSON：

• has_function_desc：是否包含功能描述
• has_business_rule：是否包含业务规则或字段规则
• has_exception_branch：是否包含异常流程、错误提示或边界条件
• has_acceptance_criteria：是否包含验收标准
• missing_items：缺失要素的名称列表
• quality_score：0-100 的整数分数

只输出 JSON，不要输出解释。

然后在主流程里加一个条件分支：如果 quality_score 低于 60，直接返回“需求质量不足，请补充以下要素：{missing_items}”，不再执行后面的用例生成。这能省下大量无效的模型调用。

3.4 生成测试用例的主提示词写法

这是整个工作流的核心，也是我调了最久的部分。最开始我给的提示词很简陋，就是“根据需求写测试用例”，结果模型输出千奇百怪，有的用了 Given/When/Then 格式，有的写成了验收清单，根本不具备执行性。

经过反复调参，我现在的生成提示词框架是五段式：

1. 角色设定：你是某业务线的资深测试工程师，熟悉功能测试和接口测试。
2. 输入说明：本次需求来源、功能点清单、业务规则、用户指定测试重点。
3. 用例格式要求：输出必须是 JSON 数组，每个元素包含以下字段：case_id、case_title、precondition、test_steps、test_data、expected_result、priority、case_type。
4. 覆盖策略：主流程覆盖 + 异常流程覆盖 + 边界值覆盖 + 权限覆盖 + 数据组合覆盖。
5. 硬性约束：不得编写与需求无关的用例；不得编造需求中不存在的字段；每个用例的 expected_result 必须具体可校验；输出必须是合法 JSON。

其中“覆盖策略”这一段特别重要，你要明确告诉模型，每个功能点至少考虑“正常输入、异常输入、边界值、必填项校验、关联字段联动、重复提交、取消操作”这些角度。

这里贴一个简化的提示词示例：

你是资深测试工程师。请根据以下需求片段生成功能测试用例，按 JSON 数组输出。

功能点： {{function_points}}

业务规则： {{business_rules}}

要求：

1. 每个功能点输出至少 5 条用例，覆盖主流程、异常流程、边界值、权限、数据组合。
2. case_type 只能是 FUNCTIONAL 或 INTERFACE。
3. priority 只能是 HIGH、MEDIUM、LOW。
4. test_steps 必须是字符串数组，step by step。
5. expected_result 必须具体到页面提示或接口返回。
6. 只输出 JSON，不要输出 markdown 代码块。

注意我在第 6 条里专门写了“不要输出 markdown 代码块”，因为模型经常会把 JSON 包在 ```json 代码块里，后面解析环节还得额外清洗。

3.5 从“全量生成”改成“分批生成”之后，质量明显上升

最初我用一个节点生成全部用例，输出经常超过 2000 个 token，不仅慢，而且后半段开始“胡说”。后来我把用例生成拆成“分批”模式，每个功能点单独生成一轮，一轮最多生成 10 条用例，通过迭代循环把所有功能点跑完。

Dify 里目前没有内置的 for 循环节点，但有“迭代模式”可以用于批处理。我实际是把功能点列表先切分成数组，然后用“迭代”节点逐个处理。虽然搭建稍微麻烦一点，但生成质量稳定很多。

4. 实操过程中遇到的坑与排查方法

这一部分是我真正想分享的“干货中的干货”。网上关于 Dify 搭工作流的教程不少，但真正讲到“实际跑挂了怎么排查”的很少。我把这两个月自己遇到的高频问题分类整理一下，每个后面都附排查思路。

4.1 本地部署环节的问题

先说一下部署。如果不想数据出本地机器，最稳妥的方式是用 Docker 跑 Dify 社区版。社区版功能上已经够用，多租户、工作流、知识库这些核心能力都有。

部署流程网上已经有很多教程，我简单提几个关键注意点：解压后的项目目录里找到 docker 文件夹，在 docker 目录下打开命令行。第一次部署先执行cp .env.example .env，把示例配置复制成正式配置，然后执行docker compose up -d。整个过程大概十分钟左右。

镜像拉取失败这个问题出现频率极高。我遇到过的情况包括：网络波动导致拉取中断、镜像仓库被限流、docker compose 里指定的镜像版本不存在。排查思路是先把docker compose pull单独执行一遍，看具体是哪个镜像失败；如果是超时，就多试几次；如果一直失败，可以给 Docker 配置镜像加速，或者手动docker pull指定版本。这里注意版本一定要和 docker-compose.yml 里的 tag 完全一致，不能想当然拉 latest。

4.2 上传文件后工作流不触发

这个坑我一开始特别困惑，Dify 工作流配得好好的，但用户上传文件后流程就是不跑。后来发现原因很蠢：我在“开始节点”里把文件变量设成了非必填，导致系统认为用户可以直接跳过上传，所以不会等文件。

排查方法：进入工作流详情页，点击“运行”按钮，手动上传一份测试文档，查看“开始节点”的输入输出日志。如果文件变量是空的，就是变量配置的问题。把文件变量改成必填，重新发布版本，问题就解决了。

另一个可能原因是浏览器缓存了旧版本的工作流配置。Dify 里改完配置后要重新“发布”，发布后还要等几秒钟让新版本生效，最好是退出工作流页面重新进入，避免拿到旧的画布数据。

4.3 模型输出非法 JSON 的处理

这是最崩溃的坑。大模型输出 JSON 的时候，偶尔会在前面加一段“好的，我将开始生成测试用例”之类的话，或者末尾多一个逗号，甚至把 JSON 包在 markdown 代码块里。如果你的下游节点直接按 JSON 解析，工作流就挂在半路。

我的解决方案是在生成节点后面加一个“文本处理”节点，先做清洗：去掉所有以 ``` 开头或结尾的行，去掉第一行中文说明，然后尝试用json.loads解析，解析失败就截取第一个 [ 到最后一个 ] 之间的内容再解析一次。

如果清洗之后还是解析失败，我还在流程里加了一个兜底处理：把原始模型输出原样返回给用户，附带一句“生成内容格式异常，请调整需求描述后重试”。这样至少不会让用户卡死，用户也能知道自己输入的问题在哪。

4.4 生成用例质量“看起来对，但没法执行”

这是最考验经验的坑。所谓“没法执行”，指的是用例描述含糊，比如 test_steps 写“输入有效数据”，expected_result 写“系统校验并给出提示”——这种用例写了等于没写。

原因出在提示词的“覆盖策略”约束不够强，模型在偷懒。后来我在提示词里加了一条惩罚性约束：“test_steps 里的每一步必须包含具体数据值；expected_result 里必须给出具体的页面提示文案或接口返回值；抽象描述视为不合格输出。”加了这条以后，质量明显提升。

如果你希望对生成用例做自动化校验，可以在工作流里再接一个“用例质量检查”节点，让模型对生成结果打分，低于 70 分的自动重生成一次。这样相当于加了一层“自我修正”。

4.5 知识库在流程里的位置

有些同学会想：为什么不用 Dify 的知识库？把历史测试用例、公司测试规范传进去，让 AI 参考着写，不更贴合业务吗？

方向是对的，但我建议知识库不要放在“生成”节点前面，而是放在“生成”节点后面做“补充检索”。原因很简单：需求稿本身的信息密度已经很高，如果再把知识库内容拼进生成提示词，上下文过长反而干扰模型对需求的理解。更合理的做法是先生成用例，再用知识库里的历史规则或风格模板做一遍风格对齐。

我实际把知识库用在了“术语标准化”上：把我们业务里常见的字段缩写、叫法不一致的地方，整理成一张术语对照表放进知识库，生成后统一做一次术语替换。这个用法比“让 AI 参考老用例”实用得多。

5. 成本控制、权限配置与落地建议

走到这一步，工作流已经能跑通了，但真要推到团队里用，还有三个现实问题要解决：成本、权限、推广方式。

5.1 Token 成本怎么算才靠谱

我的经验是，一份 3000 字左右的需求文档，走完整套流程（质量预检 + 分块抽取 + 分批生成 + 汇总）大体会消耗一万到两万 token。按目前主流大模型 API 的价格，一份需求稿的成本大概在几毛到几块钱之间，具体看选用的模型。

如果成本敏感，我建议质量预检和结构化抽取用小的模型，比如速度和价格都占优的轻量模型，而用例生成用最强模型。Dify 工作流里不同节点可以配置不同模型，这一点非常实用，我强烈建议活用。

另外一个省钱技巧是：把“需求稿质量太差”的情况尽量挡在前面。质量预检直接挂掉低质量输入，能省掉后面所有节点的调用费用。所以质量预检节点的提示词值得反复打磨，它是整个流程性价比最高的节点。

5.2 让交付结果更像“测试资产”而不是“AI 聊天记录”

用工作流生成完用例后，很多人的第一版输出就是一段 JSON 或者一片 Markdown 表格，看起来能用，但距离真正可执行还差一步。我落地的时候，在流程末端加了一个“格式化导出”节点，把 JSON 转成带编号、带优先级、带步骤描述的规范化文档，这样测试同学拿到手可以直接复制进用例管理工具。

这里我有个小心得：不要试图让 AI 直接输出“符合公司内部测试平台导入规范的 Excel 格式”，因为不同团队的模板差异太大，你会陷入无休止的提示词调优。更稳的做法是输出标准 JSON，然后用一段简单的 Python 脚本或者 Dify 里的模板节点转成 Excel。数据层和展示层解耦，后面改模板就不用动工作流。

5.3 安全合规与数据边界

如果你们公司对数据安全要求比较严，本地部署 Dify 是更好的选择。Dify 社区版支持本地部署，模型接入可以用本地化部署的开源模型，也可以用云上 API，但要注意：上传到工作流的需求文档会作为提示词内容发送给模型供应商。如果需求里有敏感的未公开业务信息，需要提前和合规团队确认。

我在团队内部推广时，明确规定了哪些类型的需求可以上传、哪些不能。比如涉及用户个人信息的详细字段规则，会先做脱敏再上传。这个边界一定要从一开始就定清楚，不然流程上线以后很容易出合规事故。

5.4 从“个人工具”到“团队平台”的三步走

最后聊聊推广方式。我发现最好的路径不是让测试人员自己学搭建，而是由我搭好一个标准工作流，开放给团队使用，再根据大家的反馈持续调优。

第一步，是建立“可信度”。一开始大家都不信 AI 能写用例，我就先用几个维护得比较好的模块做试点，把生成结果和人工编写的用例放在一起评审，让团队看到确实能覆盖到关键点。

第二步，是建立“反馈闭环”。Dify 工作流本身不太适合做复杂的后台管理，所以我加了一个简单的人工反馈节点：用例生成后在末尾附一个“哪些用例不准确？请填写原因”的文本框。这些反馈定期导出，用来调优提示词。

第三步，才是把工作流接入到其他系统里。比如内部的需求管理平台，用户在需求详情页点一下按钮，调用 Dify 工作流 API，自动生成用例并回传到需求关联的测试计划里。到这一步，它就已经变成一个正式的测试提效工具了。

根据我个人的实际经验，整个从零到一跑通，最花时间的不是搭建工作流，而是调提示词和建立团队使用习惯。前者考验的是你对测试用例设计的理解，后者考验的是你的推动力。如果你能把这两个环节打通，Dify 在测试用例生成这件事上确实是能实打实省时间的。最后再分享一个小技巧：哪怕工作流搭好了，也建议大家定期把新生成的用例和手工用例做一次对比评审，因为需求描述方式会变，提示词也需要跟着迭代，别指望一次搭完一劳永逸。