Dify 工作流先做哪条？先分清客服、回访、知识库、采购和集成

Dify 工作流先做哪条？先分清客服、回访、知识库、采购和集成

你已经能打开 Dify 控制台，也会拖几个节点，但真到要落地时，反而不知道第一条业务流该选哪一条。
售后工单、客户回访、制度问答、采购询价、接口集成，看起来都能用 Dify 做，但每一种场景需要的画布、节点和验收方法并不一样。
这篇文章只解决一个问题：先帮你判断自己当前应该从哪一类 Dify 场景开始，而不是继续平行收藏一堆“Dify 工作流示例”。

如果 Docker、模型服务、Dify 控制台还没有跑通，先不要急着选场景。环境层还没绿，后面所有场景都会跟着乱。先看这篇排错：Dify 跑不通时，先按分层定位问题。知乎上也有同题：Dify 跑不通时，先按分层定位问题。

先用问题把场景分桶

很多人搜“Dify 工作流示例”“Dify 场景模板”“Dify 售后工单 Workflow”，真正想要的不是再看一遍节点说明，而是想知道今晚先做哪条业务流。这个判断如果一开始错了，后面就会出现一个很常见的结果：Dify 节点越拖越多，应用看起来越来越复杂，但真正放进业务里却用不起来。

我更建议先把问题分成五个桶：

这里有一个很实用的判断：如果你的输入字段相对稳定，又需要多步分支，还要把结果写回业务系统，优先考虑 Dify 工作流。
如果你主要是多轮澄清、连续对话和知识库问答，暂时还不需要复杂回写，可以先用 Chatflow。后面发现对话流程开始散、字段抽取不稳定、分支越来越多，再考虑换 Workflow。

画布选择可以先看这两篇：Chatflow 还是 Workflow、Chatflow 用乱了何时换 Workflow。先把画布选对，比后面多加几个节点更重要。

Chatflow 和 Workflow 先分清

Dify 里很多应用一开始都可以用 Chatflow 做，因为它上手快，适合对话和问答。问题是，一旦你开始要求它按固定步骤办事，比如先分类、再补字段、再判断是否升级、再写回系统，Chatflow 就容易变得越来越乱。

可以这样理解：

如果你只是想让员工问制度、客户问产品资料、客服先做多轮澄清，Chatflow 可以先跑起来。
如果你已经开始关心字段名、枚举值、审批状态、接口返回、错误分支、业务系统回写，就不要继续把所有东西塞进 Chatflow，应该考虑 Workflow。

一个简单判断是：你有没有办法写出一张流程表。
如果能写出“输入是什么、第一步做什么、第二步判断什么、第三步写回哪里”，那它更像 Workflow。
如果只能描述成“用户问什么我答什么，中间可能继续追问”，那它更像 Chatflow。

A 客服与售后：先处理分类、升级和补字段

客服与售后场景适合放在 Dify 工作流里做，因为它通常不是单纯回答一句话，而是要判断问题类型、紧急程度、是否需要人工接管。只要你的问题类型能枚举，或者至少能提供用户原话加一个业务字段，比如订单号、产品线、渠道，就可以先从这个桶开始。

最小节点可以这样拆：

1. 开始节点：接收用户原话、订单号、产品线、来源渠道。
2. 分类节点：判断问题类型、紧急度、是否需要升级。
3. 条件分支：分成自动答复、补充字段、升级人工。
4. 可选 HTTP 节点：写回工单系统，或者通知企业微信群。
5. 结束节点：输出给用户看的回复，同时生成内部处理备注。

验收时不要只看一次演示是否成功。至少要检查三件事。第一，同一条应该升级的投诉，连续跑几次都应该进入升级分支，不能因为模型输出漂移而乱跳。第二，缺少订单号、产品型号这类关键字段时，流程要追问或明确失败，不能编造订单状态。第三，涉及退款、赔偿、处理时效时，不能输出没有授权依据的承诺。

如果你要做售后工单，可以看：售后工单分诊。如果你更关心多轮客服入口，可以看：客服多轮机器人。

B 销售与回访：先把散乱记录整理成可跟进任务

销售和回访类场景的输入通常是一段不整齐的文本，比如拜访记录、电话纪要、聊天记录、客户反馈。这里最容易犯的错误，是让 Dify 只生成一段“看起来很像总结”的文字。真正有用的输出应该是下一步动作、责任人、时间提示、客户异议和待确认事项。

这个场景可以从 Workflow 开始。如果前台需要先跟销售人员多轮补充信息，也可以用 Chatflow 做入口，再把整理好的文本送进 Workflow。

最小节点可以这样拆：

1. 开始节点：输入原始纪要文本。
2. 抽取节点：提取客户意向、主要异议、下次动作、责任人候选。
3. 校验节点：检查字段是否齐全，是否有虚构的约访时间或承诺。
4. 可选 HTTP 节点：写入 CRM、明道云或表格。
5. 结束节点：输出一份可复制的跟进清单。

验收时重点看三件事。第一，字段名要稳定，比如 next_action、due_hint、risk_point 这些字段不能每次换名字。第二，如果原文没有明确下次动作，Dify 不能硬编一个“下周三回访”。第三，涉及折扣、交付日期、费用承诺时，如果原文没有依据，就要标记为待人工确认。

这个方向可以看：客户回访整理。如果你想做销售跟单，可以看：销售跟单助手。

C 知识库与合规：能搜到不等于敢上线

知识库问答是 Dify 很常见的入口，但也是最容易让人误判的场景。文档能上传，问题能回答，并不代表这个应用可以给一线使用。真正要检查的是：答案有没有依据，召回片段是否对得上，资料不足时会不会拒答。

这个桶默认可以用 Chatflow + Dify 知识库。如果是制度、合同、财务、合规类问题，我建议再加 Workflow 做复核，把“回答”“依据”“风险分级”“人工确认”拆开。

最小节点可以这样拆：

1. 知识库检索：先做检索测试，不要一开始就只看聊天效果。
2. 回答约束：要求回答只能依据召回片段，依据不足时明确说明。
3. 可选风险分级节点：判断是否涉及制度解释、金额、审批、合同责任。
4. 结束节点：输出答案、依据片段，或者输出“依据不足，需要人工确认”。

验收时至少做三类题。第一，高频问题要能打到预期片段。第二，权限外、制度未规定、过期文件这类问题，至少准备 5 条应该拒答的样例。第三，换模型后要用同一批测试题回归，检查拒答边界有没有塌掉。

如果你现在是“上传了文档却搜不到答案”，可以看：上传文档却搜不到答案。如果你要通过接口管理知识库内容，可以看：知识库 API。

这一桶最重要的判断是：能搜到，不等于敢上线。
如果答案没有依据，或者依据片段和结论对不上，这个知识库问答应用就还不能直接交给业务人员用。

D 采购、标书和文档：不要假装一次生成终稿

采购和标书类场景很适合用 Dify 工作流，但目标要设对。它更适合先生成准备单、缺项清单、初稿大纲和比价表，而不是一次生成可以直接盖章的终稿。只要涉及价格、合同条款、评分点和商务承诺，就必须保留人工复核。

最小节点可以这样拆：

1. 开始节点：输入需求说明、附件说明、历史报价或招标文件摘要。
2. 抽取节点：提取必备项、缺项、商务风险、技术要求。
3. 可选知识库节点：召回历史标书、合规条款或产品资料。
4. 整理节点：生成询价准备单、标书初稿大纲或比价结构。
5. 结束节点：输出人工可编辑的 Markdown 或表格。

验收时要检查三件事。第一，缺关键商务条款时，要输出缺项列表，不能假装材料齐全。第二，比价场景里的价格字段必须能追溯到输入材料，不能凭空补数字。第三，把输出交给同事后，对方应该能在 10 分钟内开始修改，而不是从头重写。

采购场景可以看：采购询价准备单。标书方向可以看：标书初稿整理。

E 系统集成：不要只看聊天框里的 200

系统集成类场景最容易出现一种假象：Dify 里看起来返回成功了，业务系统却没有真正接住。比如 HTTP 节点显示 200，但明道云、OA、CRM 或自建系统里写入重复、字段错位、失败没有提示。

这个桶适合用 Workflow + HTTP 节点，或者 Workflow + 插件。鉴权、密钥、幂等和错误处理最好放在后端，不要把 Key 暴露在前端或对话日志里。

最小节点可以这样拆：

1. 开始节点：接收业务系统推送字段，最好带 request_id。
2. 校验节点：检查必填字段、枚举值、幂等键。
3. LLM 或知识库节点：生成结论、报告、分类结果或填表内容。
4. HTTP 节点：写回业务系统；非 2xx 进入错误分支。
5. 结束节点：输出业务系统能区分的成功或失败语义。

验收时不要只测成功样例。第一，故意制造非 2xx，检查流程有没有兜底输出。第二，重复提交同一个请求，看会不会写出两条脏数据。第三，检查 Key、Token、Cookie 这类敏感信息有没有出现在前端或日志明文里。

如果你卡在 HTTP 节点，可以看：HTTP 节点调不通。如果 API 已经调通，但系统里仍然不好用，可以看：API 通了系统仍不好用。如果你想把 Dify 放在第三方平台后面当 AI 后端，可以看：Dify 给第三方当 AI 后端。

插件、OpenAPI 和 MCP 不要先抢戏

外部数据接入现在有很多说法，HTTP、OpenAPI、插件、MCP 都能听到。我的建议是，先不要为了新词把流程做复杂。你应该先判断业务属于哪一桶，再决定接入形态。

可以先问三句话：

1. 这个接口是谁维护的？
2. 这个能力要不要做成可复用工具？
3. 调用方是不是需要动态发现工具？

如果只是你自己维护的内部接口，HTTP 节点或自定义工具往往就够了。
如果要封装成更标准的工具能力，插件形态会更合适。
如果是 Agent 需要动态发现和调用工具，再认真评估 MCP，不要为了赶概念一开始就上复杂度。

这部分可以看：OpenAPI vs 插件 vs MCP。

原则很简单：先定场景，再定验收，再选接入方式。反过来容易变成节点很炫，但业务接不住。

10 分钟选场景清单

如果你现在还不知道第一条 Dify 工作流该做什么，可以按这个清单走一遍：

• 我已经能登录 Dify 控制台，模型最小调用也成功。如果 Docker 和模型还没跑通，先按分层把环境查绿。
• 我有稳定输入。至少能写出字段名、问题类型或可枚举状态，而不是只有一句“帮我做智能客服”。
• 我需要多步分支吗？如果需要分类、升级、缺字段追问，优先考虑 Workflow。
• 我需要回写 CRM、工单、明道云、OA 或自建 API 吗？如果需要，就按系统集成的思路设计验收。
• 这个场景涉及制度、金额、合同、承诺吗？如果涉及，知识库依据和人工复核要优先于话术漂亮。
• 我能把自己的场景放进 A、B、C、D、E 其中一个桶吗？
• 我只先打开这个桶里 1 到 2 篇相关文章，不要同时平行收藏十篇相似内容。
• 我写下 Dify 版本号，以及这个场景里最不能胡说的一条边界。

三句话就能帮你快速缩小范围：有没有稳定输入字段？要不要多步分支？要不要回写业务系统？
这三句话答完，基本就知道该先用 Chatflow 还是 Workflow，也知道第一条业务流该放在哪一桶。

你真正能带走的判断

Dify 工作流不要从“我想拖哪些节点”开始，而要从“我到底要解决哪条业务”开始。
客服与售后看分类和升级，销售与回访看任务清单，知识库与合规看依据和拒答，采购与标书看缺项和可编辑初稿，系统集成看回写、鉴权和失败语义。
先定做哪条业务，再选 Chatflow 或 Workflow，最后才是拖节点。这样做出来的 Dify 应用，才不会停在演示阶段。