Dify 工作流最容易被低估的一步，是上线前测试。很多人搭完流程后，只拿一个正常问题试一下，能回答就发布。结果真实用户一来，问题写法变了、资料没命中、分支走错、人工审核没触发，最后不是乱答，就是漏处理。
如果你把 Dify 当成一个可交付的 AI Agent 或自动化应用，就不能只做“能不能跑通”的测试，而要写一组覆盖常见输入、异常输入和业务边界的测试用例。相关基础可以先看 AI智能体与自动化专题 和 老达AI实践专题，本文重点讲上线前怎么验收。
为什么 Dify 工作流需要测试用例
Dify 的价值在于把大模型、知识库、条件分支、HTTP 请求、变量和人工节点串起来。也正因为节点多，问题不一定出在模型回答本身。一个看似“AI 答错了”的问题，可能是输入变量没传对，也可能是知识库召回不到，还可能是条件分支把客户问题分到了错误路径。
测试用例的作用，就是把这些风险提前暴露出来。它不需要复杂到软件测试工程级别，但至少要让你知道：哪些问题会进入哪个分支，哪些资料会被召回，哪些场景必须转人工，失败时用户会看到什么。
之前我写过 Dify工作流日志排查 和 Dify工作流变量设计。这篇可以理解为上线前的检查表：先用测试用例把流程压一遍，再决定要不要发布给真实用户。
第一类：正常输入用例，确认主路径能跑通
正常输入不是随便问一句，而是选择业务里最高频、最应该答对的问题。比如你做的是本地商家的客服知识库，可以准备这些用例：
- 用户问营业时间，期望命中门店基础资料。
- 用户问价格套餐，期望返回标准报价，并提示以门店确认价为准。
- 用户问预约方式，期望引导留下手机号或跳转表单。
- 用户问售后问题，期望进入售后分支或人工确认节点。
每条用例都要写清楚“输入、期望分支、期望资料、期望回答”。不要只写“问一下营业时间”。如果没有期望结果，测试就会变成主观判断：感觉回答差不多，就算过了。
第二类：改写输入用例，测试用户说法变化
真实用户不会按照你的知识库标题来提问。同一个意思，可能会写成“几点关门”“晚上还能去吗”“周末开不开”“今天营业吗”。如果 Dify 工作流只在标准问法下表现正常，上线后很快会暴露问题。
建议每个高频问题至少准备 3 种改写：
标准问法：你们周末营业吗？
口语问法：周六周日能不能去？
模糊问法：我明天晚上过去有人吗？
期望结果：
都应该命中营业时间资料；
如果日期不明确，需要说明常规营业时间，并提示用户确认具体日期。这类测试能看出知识库分段、提示词和检索设置是否稳定。如果改写后经常答偏，可以回到 Dify知识库命中率优化 里提到的分段、元数据和测试问题集重新调整。
第三类：分支路径用例，确认条件没有走错
Dify 工作流一旦加入条件分支，就不能只测最终回答，还要测路径。比如客户咨询可以分成售前、售后、投诉、无关问题、人工转接。每条路径至少要准备一条正例和一条边界例。
| 用例类型 | 输入示例 | 期望路径 | 检查重点 |
|---|---|---|---|
| 售前咨询 | 你们这个套餐多少钱？ | 报价说明 | 是否引用最新价格资料 |
| 售后问题 | 昨天买的服务不满意怎么办？ | 售后处理 | 是否提示人工确认 |
| 投诉风险 | 我要退款并投诉你们 | 人工接管 | 是否避免自动承诺赔偿 |
| 无关问题 | 帮我写一篇作文 | 拒答或引导 | 是否保持业务边界 |
如果分支判断依赖模型分类，测试时要特别关注边界例。模型分类不是 100% 稳定，越涉及退款、投诉、医疗、法律、金额承诺，越应该让人工审核提前介入。相关设计可以参考 Dify人工审核工作流。
第四类：知识库召回用例，检查资料是否真的被用到
很多 Dify 应用看起来接了知识库，但回答时其实主要靠模型常识。测试时要检查三件事：是否召回到正确文档，是否引用了正确片段，是否没有编造知识库之外的内容。
可以给每条知识库测试加一个“证据要求”：
输入：标准套餐包含哪些服务？
期望召回：套餐说明文档 / 标准版服务范围
期望回答：列出服务项，但不能增加文档里没有的承诺
失败判定：回答里出现额外赠品、额外折扣或未授权服务如果工作流面向客户交付，我建议保留一份测试记录。里面记录输入、命中文档、回答结果和是否通过。以后客户更新资料时，可以用同一组用例回归测试，避免今天修好一个问题，明天又让另一个高频问题答偏。
第五类：失败兜底用例，确认出错时不失控
上线前必须故意制造几类失败：知识库无答案、HTTP 请求超时、用户输入为空、用户输入太长、敏感问题、格式不符合要求。目的不是让流程永远不报错，而是确认失败时有体面的兜底。
一个可接受的兜底回答，至少应该做到三点：
- 不编造：不知道就说明需要人工确认。
- 不承诺：不要自动答应退款、赔偿、合同条款或价格优惠。
- 可继续：给用户一个下一步，比如补充信息、留下联系方式、转人工。
如果流程里接了 n8n、CRM、飞书或外部 API，也要测试接口失败时会不会重复提交、漏发通知或把半成品结果发给客户。AI 自动化交付真正麻烦的不是“失败”，而是失败后没人知道。
一份可复用的 Dify 测试用例表
你可以用下面这张表作为最小版本：
| 字段 | 填写方式 |
|---|---|
| 用例名称 | 例如：营业时间咨询、退款投诉、无资料问题 |
| 输入内容 | 用户可能真实输入的一句话 |
| 期望分支 | 售前、售后、人工、拒答、知识库问答等 |
| 期望资料 | 应该命中的知识库文档或接口字段 |
| 通过标准 | 回答准确、边界清楚、没有编造、下一步明确 |
| 失败处理 | 转人工、提示补充信息、记录日志、暂停自动执行 |
如果只想快速上线，也至少准备 10 条：5 条高频正常问题、2 条改写问题、1 条投诉或高风险问题、1 条知识库无答案问题、1 条接口或工具失败问题。少于这个数量，很容易只测到演示场景，测不到真实交付。
老达点评
Dify 工作流的上线质量，不是看演示时回答得多漂亮，而是看遇到普通用户、模糊问题、边界情况和工具失败时还能不能稳住。测试用例就是把这些情况提前摆到桌面上。
对个人站长、小团队和 AI 副业交付来说，测试用例还有一个额外价值：它能让客户看到你不是随便搭了一个机器人，而是在按业务风险验收。交付包里多一张测试用例表，往往比多堆几个节点更有说服力。
