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

Dify 工作流先做哪条先分清客服、回访、知识库、采购和集成你已经能打开 Dify 控制台也会拖几个节点但真到要落地时反而不知道第一条业务流该选哪一条。售后工单、客户回访、制度问答、采购询价、接口集成看起来都能用 Dify 做但每一种场景需要的画布、节点和验收方法并不一样。这篇文章只解决一个问题先帮你判断自己当前应该从哪一类 Dify 场景开始而不是继续平行收藏一堆“Dify 工作流示例”。如果 Docker、模型服务、Dify 控制台还没有跑通先不要急着选场景。环境层还没绿后面所有场景都会跟着乱。先看这篇排错Dify 跑不通时先按分层定位问题。知乎上也有同题Dify 跑不通时先按分层定位问题。先用问题把场景分桶很多人搜“Dify 工作流示例”“Dify 场景模板”“Dify 售后工单 Workflow”真正想要的不是再看一遍节点说明而是想知道今晚先做哪条业务流。这个判断如果一开始错了后面就会出现一个很常见的结果Dify 节点越拖越多应用看起来越来越复杂但真正放进业务里却用不起来。我更建议先把问题分成五个桶你现在遇到的问题先放进哪一桶默认更适合的画布工单分诊、投诉升级、客服多轮答复A 客服与售后Workflow回访纪要、跟单提醒、线索整理B 销售与回访Workflow部分入口可用 Chatflow制度问答、资料问答、答得像真的但没依据C 知识库与合规Chatflow Dify 知识库高风险场景加 Workflow询价准备单、标书初稿、比价、文档整理D 采购 / 标书 / 文档WorkflowHTTP 调不通、接 OA / 明道云 / CRM、当 AI 后端E 系统集成Workflow HTTP / 插件这里有一个很实用的判断如果你的输入字段相对稳定又需要多步分支还要把结果写回业务系统优先考虑 Dify 工作流。如果你主要是多轮澄清、连续对话和知识库问答暂时还不需要复杂回写可以先用 Chatflow。后面发现对话流程开始散、字段抽取不稳定、分支越来越多再考虑换 Workflow。画布选择可以先看这两篇Chatflow 还是 Workflow、Chatflow 用乱了何时换 Workflow。先把画布选对比后面多加几个节点更重要。Chatflow 和 Workflow 先分清Dify 里很多应用一开始都可以用 Chatflow 做因为它上手快适合对话和问答。问题是一旦你开始要求它按固定步骤办事比如先分类、再补字段、再判断是否升级、再写回系统Chatflow 就容易变得越来越乱。可以这样理解更适合 Chatflow更适合 Workflow多轮澄清固定多步处理知识库问答前台分类、抽取、分支、回写快速验证能不能问得动验证流程能不能稳定跑完对话为主业务流程为主输出不需要严格字段输出要给后续节点继续用如果你只是想让员工问制度、客户问产品资料、客服先做多轮澄清Chatflow 可以先跑起来。如果你已经开始关心字段名、枚举值、审批状态、接口返回、错误分支、业务系统回写就不要继续把所有东西塞进 Chatflow应该考虑 Workflow。一个简单判断是你有没有办法写出一张流程表。如果能写出“输入是什么、第一步做什么、第二步判断什么、第三步写回哪里”那它更像 Workflow。如果只能描述成“用户问什么我答什么中间可能继续追问”那它更像 Chatflow。A 客服与售后先处理分类、升级和补字段客服与售后场景适合放在 Dify 工作流里做因为它通常不是单纯回答一句话而是要判断问题类型、紧急程度、是否需要人工接管。只要你的问题类型能枚举或者至少能提供用户原话加一个业务字段比如订单号、产品线、渠道就可以先从这个桶开始。最小节点可以这样拆开始节点接收用户原话、订单号、产品线、来源渠道。分类节点判断问题类型、紧急度、是否需要升级。条件分支分成自动答复、补充字段、升级人工。可选 HTTP 节点写回工单系统或者通知企业微信群。结束节点输出给用户看的回复同时生成内部处理备注。验收时不要只看一次演示是否成功。至少要检查三件事。第一同一条应该升级的投诉连续跑几次都应该进入升级分支不能因为模型输出漂移而乱跳。第二缺少订单号、产品型号这类关键字段时流程要追问或明确失败不能编造订单状态。第三涉及退款、赔偿、处理时效时不能输出没有授权依据的承诺。如果你要做售后工单可以看售后工单分诊。如果你更关心多轮客服入口可以看客服多轮机器人。B 销售与回访先把散乱记录整理成可跟进任务销售和回访类场景的输入通常是一段不整齐的文本比如拜访记录、电话纪要、聊天记录、客户反馈。这里最容易犯的错误是让 Dify 只生成一段“看起来很像总结”的文字。真正有用的输出应该是下一步动作、责任人、时间提示、客户异议和待确认事项。这个场景可以从 Workflow 开始。如果前台需要先跟销售人员多轮补充信息也可以用 Chatflow 做入口再把整理好的文本送进 Workflow。最小节点可以这样拆开始节点输入原始纪要文本。抽取节点提取客户意向、主要异议、下次动作、责任人候选。校验节点检查字段是否齐全是否有虚构的约访时间或承诺。可选 HTTP 节点写入 CRM、明道云或表格。结束节点输出一份可复制的跟进清单。验收时重点看三件事。第一字段名要稳定比如next_action、due_hint、risk_point这些字段不能每次换名字。第二如果原文没有明确下次动作Dify 不能硬编一个“下周三回访”。第三涉及折扣、交付日期、费用承诺时如果原文没有依据就要标记为待人工确认。这个方向可以看客户回访整理。如果你想做销售跟单可以看销售跟单助手。C 知识库与合规能搜到不等于敢上线知识库问答是 Dify 很常见的入口但也是最容易让人误判的场景。文档能上传问题能回答并不代表这个应用可以给一线使用。真正要检查的是答案有没有依据召回片段是否对得上资料不足时会不会拒答。这个桶默认可以用 Chatflow Dify 知识库。如果是制度、合同、财务、合规类问题我建议再加 Workflow 做复核把“回答”“依据”“风险分级”“人工确认”拆开。最小节点可以这样拆知识库检索先做检索测试不要一开始就只看聊天效果。回答约束要求回答只能依据召回片段依据不足时明确说明。可选风险分级节点判断是否涉及制度解释、金额、审批、合同责任。结束节点输出答案、依据片段或者输出“依据不足需要人工确认”。验收时至少做三类题。第一高频问题要能打到预期片段。第二权限外、制度未规定、过期文件这类问题至少准备 5 条应该拒答的样例。第三换模型后要用同一批测试题回归检查拒答边界有没有塌掉。如果你现在是“上传了文档却搜不到答案”可以看上传文档却搜不到答案。如果你要通过接口管理知识库内容可以看知识库 API。这一桶最重要的判断是能搜到不等于敢上线。如果答案没有依据或者依据片段和结论对不上这个知识库问答应用就还不能直接交给业务人员用。D 采购、标书和文档不要假装一次生成终稿采购和标书类场景很适合用 Dify 工作流但目标要设对。它更适合先生成准备单、缺项清单、初稿大纲和比价表而不是一次生成可以直接盖章的终稿。只要涉及价格、合同条款、评分点和商务承诺就必须保留人工复核。最小节点可以这样拆开始节点输入需求说明、附件说明、历史报价或招标文件摘要。抽取节点提取必备项、缺项、商务风险、技术要求。可选知识库节点召回历史标书、合规条款或产品资料。整理节点生成询价准备单、标书初稿大纲或比价结构。结束节点输出人工可编辑的 Markdown 或表格。验收时要检查三件事。第一缺关键商务条款时要输出缺项列表不能假装材料齐全。第二比价场景里的价格字段必须能追溯到输入材料不能凭空补数字。第三把输出交给同事后对方应该能在 10 分钟内开始修改而不是从头重写。采购场景可以看采购询价准备单。标书方向可以看标书初稿整理。E 系统集成不要只看聊天框里的 200系统集成类场景最容易出现一种假象Dify 里看起来返回成功了业务系统却没有真正接住。比如 HTTP 节点显示 200但明道云、OA、CRM 或自建系统里写入重复、字段错位、失败没有提示。这个桶适合用 Workflow HTTP 节点或者 Workflow 插件。鉴权、密钥、幂等和错误处理最好放在后端不要把 Key 暴露在前端或对话日志里。最小节点可以这样拆开始节点接收业务系统推送字段最好带request_id。校验节点检查必填字段、枚举值、幂等键。LLM 或知识库节点生成结论、报告、分类结果或填表内容。HTTP 节点写回业务系统非 2xx 进入错误分支。结束节点输出业务系统能区分的成功或失败语义。验收时不要只测成功样例。第一故意制造非 2xx检查流程有没有兜底输出。第二重复提交同一个请求看会不会写出两条脏数据。第三检查 Key、Token、Cookie 这类敏感信息有没有出现在前端或日志明文里。如果你卡在 HTTP 节点可以看HTTP 节点调不通。如果 API 已经调通但系统里仍然不好用可以看API 通了系统仍不好用。如果你想把 Dify 放在第三方平台后面当 AI 后端可以看Dify 给第三方当 AI 后端。插件、OpenAPI 和 MCP 不要先抢戏外部数据接入现在有很多说法HTTP、OpenAPI、插件、MCP 都能听到。我的建议是先不要为了新词把流程做复杂。你应该先判断业务属于哪一桶再决定接入形态。可以先问三句话这个接口是谁维护的这个能力要不要做成可复用工具调用方是不是需要动态发现工具如果只是你自己维护的内部接口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 应用才不会停在演示阶段。