企业官网建设流程全解析

如果你最近在折腾大模型应用，十有八九会听到 Dify 这个名字。作为一个开源的大模型应用开发平台，Dify 最吸引人的地方就是工作流功能：不用从零写服务、搭路由、管上下文，而是像画流程图一样，把提示词、知识库检索、参数处理、条件判断这些环节一个一个串起来。我第一次用 Dify 工作流的时候，心里其实挺没底的：节点一多，变量传参怎么搞？知识库结果怎么喂给模型？条件分支到底怎么接才不会报错？这篇教程就是写给同样困惑的新手，我会从核心概念讲起，再带你完整搭建一个“智能写作助手”工作流，最后把我在实际使用中踩过的坑和排查思路一并交底。看完你就能独立搭出自己的第一个 Dify 工作流，不用再去网上东拼西凑零散教程了。

1. Dify工作流新手入门：先搞清楚它到底解决什么问题

很多刚接触 Dify 的朋友，第一反应是“这不就是个可视化提示词工具吗”。说实话，我一开始也是这么想的，用几天之后才意识到，工作流真正解决的，不是“把提示词写得更漂亮”，而是“把多个 AI 能力稳定地编排成一条自动化流水线”。

1.1 为什么我建议新手直接选择工作流而不是从零写代码

过去做大模型应用，最常见的路径是自己写 Python 脚本：你要管理 API 密钥、拼提示词、处理返回的 JSON、处理超时重试；如果还要接知识库，又得自己做文本切块、向量化、检索排序，再手动把检索结果拼进上下文。这一套东西做下来，光基础设施就要写几百行代码，而且每次换一个模型服务商，对接逻辑几乎要重写一遍。

Dify 工作流把这些事情全部组件化了：模型接入有统一配置，知识库检索有现成节点，文本处理有代码节点和模板节点，条件分支能帮你自动分流。你要做的只是把节点拖到画布上，按顺序连起来，再把变量喂进去。对非技术背景的人来说，这是把想法变成 AI 应用的最短路径；对工程师来说，也能省掉大量重复劳动，把精力放在业务本身。

实际使用中，我见过做产品、做运营、做美术的朋友，用 Dify 工作流做竞品分析日报、小说角色卡生成、会议纪要清洗，效果都还不错。核心原因在于，工作流让“流程”本身就变成了可复用的产品，而不是藏在一堆代码里。别人看到的是一张清晰的流程图，而不是一段看不懂的脚本，协作和维护的门槛一下子就下来了。

1.2 工作流和Chatflow到底选哪个：先别急着动手

很多新手打开 Dify 创建应用时，第一眼就会看到两个容易混淆的类型：工作流（Workflow）和对话流（Chatflow）。这两个名字看起来很像，但适用场景差别很大。

判断标准很简单：如果你的应用是“给一段输入，吐出一个确定结果”，比如“把文章摘要成 5 条要点”“把一段会议录音转成格式化记录”，选工作流。如果你是做“像人一样来回聊天”的助手，需要记住用户上一轮说了什么，选对话流。

新手拿不准的时候，我建议先选工作流。因为工作流的调试思路更线性，变量逻辑更外显，不容易被“多轮上下文”这种概念绕晕。等工作流跑熟了，再去看对话流，你会发现大部分节点逻辑都是一样的，迁移成本很低。

2. 搭建工作流前必须掌握的5个核心概念

如果你直接打开画布就开始拖节点，十有八九会卡在“变量从哪来、输出到哪去”这个问题上。所以在动手之前，先把下面这 5 个核心概念搞清楚，后面会顺很多。

2.1 节点：工作流的最小执行单元

节点就像一个工位上的工序。每个节点负责一件具体的事：调模型、检索知识、算字数、做判断。常见的节点类型我用一张表总结了一下：

节点之间是严格的前后依赖关系：上游节点跑完，下游节点才能取到它的输出。这个设计虽然看着死板，但好处是流程非常可预测——报错时，你能直接定位到是哪道工序出了问题，而不是在几百行代码里大海捞针。

2.2 连线与画布：编排顺序决定执行顺序

在 Dify 的画布上，节点之间靠拖拽连线连接。连线是有方向的，数据只能从上游节点流向下游节点。你可以从节点右侧的圆点，拖到下一个节点的左侧输入端，一条线就建立起来了。

一个经常被新手忽略的调度规则是：如果一个节点接了多个上游连线，它会等全部上游节点都执行完才会开始运行。这有点像开会，必须等所有相关人到了才开得起来。

另外，工作流本质上是一个有向无环图，对新手来说，先别想着在画布上绕回形成环。虽然市面上有些可视化工具支持循环，但工作流里的循环一旦设置不当，很容易造成重复执行和费用失控。先把线性流程跑通，再去碰迭代和循环，会安全得多。

2.3 变量：数据在工作流里流动的唯一方式

如果说节点是工序，变量就是工序之间传送的物料。Dify 工作流里的变量有两种来源：一种是开始节点定义的输入变量，比如“主题”“风格”“字数”；另一种是节点执行后产生的输出变量，比如 LLM 节点生成的“文章正文”，代码节点算出的“总字数”。

在配置节点时，你会经常看到类似{{#节点ID.输出变量#}}这样的引用。这是一种模板语法，意思是“把某个节点的某个输出变量的值，插入到当前位置”。在界面上，Dify 提供了插入变量的按钮，点开就能看到当前节点可引用的变量列表，选中后会自动生成正确的引用。

这里有个新手最容易犯的错：手写变量引用。节点 ID 是系统生成的唯一标识，一长串字符，手打几乎必错。永远用界面上的插入按钮，不要自己敲。

2.4 系统变量与自定义输入：分清哪来哪去

开始节点是工作流的“门面”。别人通过 API 调用你的工作流时，传什么参数、参数是什么类型，完全由开始节点决定。在开始节点里，你可以定义文本、段落、下拉选择、数字、文件等类型的输入变量。

除了自定义输入，Dify 还会根据运行环境注入一些系统变量，比如用户 ID、会话 ID、上传的文件列表等。不同应用类型能使用的系统变量不完全一样，你在插入变量时，面板里就能看到哪些可用。

理解这两者的区别很重要：对外交互看开始节点，对内处理看各节点的输出变量。写提示词的时候，你会频繁引用开始节点的输入变量，比如主题、风格、目标字数；而中间环节的产物，比如大纲、检索结果、最终文章，则来自各个节点的输出。

2.5 调试面板：拿到每个节点的运行日志

Dify 工作流最让我喜欢的地方，就是它有一个非常直观的调试面板。配置完流程后，点击右上角的“运行”按钮，系统会要求你填入开始节点定义的输入值。填完点运行，整条链路会依次执行。

运行结束后，你可以点开任意一个节点，查看它的输入数据、输出数据、消耗的 token 和运行耗时。如果某个节点报错，错误信息也会在这里显示。这一步非常重要，别嫌麻烦，每加一个节点就先运行一次，确认这个节点输出正确，再继续往下接。等全部节点拖完再一次性联调，出了问题往往要排查很久，效率很低。

3. 手把手案例：用Dify工作流搭一个“智能写作助手”

下面进入实操环节。我会用 Dify 工作流搭一个完整的“智能写作助手”：输入主题、风格和目标字数，自动生成一篇结构完整的文章，并且自动检查字数是否达标，不达标就触发扩写。这个案例覆盖了 LLM 节点、知识检索、代码节点、条件分支、模板节点和结束节点这几种核心能力，做完一遍，你基本就能应对大部分常见场景了。

3.1 先画出流程草图：写清楚每个环节要什么

我习惯在动手拖节点之前，先在纸上画一个流程草图。千万别小看这一步，Dify 画布虽然直观，但如果没想清楚数据从哪来、到哪去，拖到一半一定会乱。

这个智能写作助手的流程图大致是这样：

开始（topic / style / target_length） → LLM节点：生成大纲 → 知识检索：按主题检索素材 → LLM节点：根据大纲+素材+风格写全文 → 代码节点：统计字数 → 条件分支：字数是否达标 ├─ 是 → 结束节点A（输出原文） └─ 否 → LLM节点：扩写补充 → 结束节点B（输出扩写稿）

这里有两个关键取舍。第一，我把“写作”拆成了“生成大纲”和“撰写全文”两步，每一步的提示词都很简单，模型更容易稳定输出，不会一上来就写飞。第二，我用代码节点做字数检查，而不是让模型自己判断字数，因为模型统计字数非常不可靠，而且为了数数还会消耗不必要的 token。

3.2 创建应用并配置开始节点

打开 Dify 控制台，进入“工作室”，点击“创建应用”，应用类型选择“工作流”，名字可以叫“智能写作助手”。

进入画布后，第一步是配置“开始”节点。点击开始节点，添加三个输入变量：

• topic：类型选“文本”，必填，用来接收写作主题。
• style：类型选“下拉选择”，选项填“科技干货 / 生活随笔 / 商业分析”，默认值选“科技干货”。
• target_length：类型选“数字”，默认值填 800，用来接收目标字数。

变量名我建议都用英文小写加下划线，比如target_length，千万别用中文或带空格的名字。这个细节现在看不出差别，等你在代码节点里写 Python、或者需要精确引用变量时，你会感谢自己当初这个习惯。

3.3 用LLM节点生成大纲：学会插入变量

从节点列表里拖一个 LLM 节点到画布上，把开始节点的右侧圆点连线到 LLM 节点的左侧输入端。点开 LLM 节点，在模型列表里选择你已经接入的模型。

提示词区域可以这样配置：

你现在是一名资深内容编辑。根据下面的主题和风格，生成一份文章大纲。 主题：{{#start.topic#}} 风格：{{#start.style#}} 要求： 1. 大纲分为引言、主体、总结三个部分； 2. 每部分给出至少2个具体要点； 3. 只输出大纲，不要多余解释。

注意，这里的{{#start.topic#}}只是我在文档里的简写，实际画布里请点击右侧“插入变量”按钮，从列表里选择开始节点对应的变量，系统会自动生成正确的引用。不要手动输入花括号。

配置完后，在 LLM 节点的输出变量区域，把输出命名为outline_text，方便后续引用。然后先运行一次，确认这个节点能正常输出大纲，再继续下一步。

3.4 接入知识库检索：给生成提供外部依据

为了让生成的文章更有信息量，我在这里加一个知识检索节点。前提是你已经在 Dify 里创建过知识库，并上传了参考文档，比如行业报告、公司资料或者你平时的写作素材。Dify 会自动完成文档切块和向量化，这一步操作很快，但在决定检索效果时很关键。

拖一个“知识检索”节点到画布，把开始节点也连到它上面。在节点配置里：

• 检索输入：选择{{#start.topic#}}，也就是用写作主题去知识库里找相关片段。
• 知识库：选择你准备好的那个。
• top_k：设为 3。含义是召回多少条片段，太少素材不够，太多又容易超出模型上下文。
• 相似度阈值：设为 0.3 到 0.5 之间。阈值太高容易一个结果都检索不到，太低会混入大量无关内容。

知识检索节点的输出是一个数组，里面包含命中的文本片段和对应的相关度分数。你可以在调试面板里直接看这个节点的输出，确认内容是否贴合主题。

一个进阶技巧是：把知识检索节点的输入从“主题”改成上一步的大纲outline_text，检索会更有针对性。案例里为了演示主流程，我先用主题查询，你完全可以根据业务需要灵活调整。

3.5 用LLM节点撰写全文：把大纲、素材和风格合起来

拖第二个 LLM 节点到画布，同时把“大纲生成”节点和“知识检索”节点都连到它上面。前面说过，多上游连线不会导致节点跑两次，Dify 会等所有直接上游节点执行完，再开始运行当前节点。

这个 LLM 节点的提示词我这样写：

你是一名资深写作助手。请根据下面的主题和风格，围绕大纲完成一篇完整文章。 主题：{{#start.topic#}} 风格：{{#start.style#}} 目标字数：{{#start.target_length#}} 大纲： {{#outline.outline_text#}} 参考资料（仅供理解，不要大段复制）： {{#knowledge.result#}} 要求： 1. 结构清晰，小标题自然； 2. 语言符合所选风格； 3. 尽量接近目标字数。

把输出变量命名为article_text。运行调试一次，看看生成的文章质量如何。如果文章完全没用到知识库内容，先检查提示词里是否真的插入了{{#knowledge.result#}}，再确认知识检索节点的输出有没有内容。

3.6 用代码节点统计字数：确定性的活别让模型干

接下来拖一个“代码执行”节点，放在“全文撰写”节点后面。代码节点支持 Python 和 Node.js，我这里用 Python。

在代码节点里，声明一个输入变量article_text，指向{{#full_write.article_text#}}（这里的full_write是撰写节点的 ID 简写，实际配置时从变量列表选择即可）。再把输出变量声明为total_chars，类型为数字。

代码部分非常简单：

def main(article_text: str) -> dict: cleaned = article_text.replace(" ", "").replace("\n", "").replace("\r", "") return {"total_chars": len(cleaned)}

运行节点，你就能在输出里看到total_chars的值。为什么字数统计一定要用代码节点？因为大模型数数非常不可靠，你让它“估算一下字数”，它经常给出一个相差很远的数字，而且每次调用都要花钱。代码执行是确定性的、免费的、毫秒级的。以后你再遇到任何“能被规则算清楚”的逻辑，都优先丢给代码节点。

3.7 条件分支处理字数不达标的情况

拖一个“条件分支”节点，连接在代码节点后面。配置条件：total_chars >= {{#start.target_length#}}。这里要注意，两个比较变量的类型都必须匹配。total_chars是数字，开始节点里的target_length也要定义成数字，否则条件判断会报错。

条件分支会产生两条路径：

• TRUE 路径：字数达标，直接把article_text作为最终结果。
• FALSE 路径：字数不达标，进入一个 LLM 扩写节点。

扩写节点的提示词可以这样写：

请扩写下面的初稿，在保留原意的基础上补充更多细节、案例和数据，让文章更充实，目标字数约：{{#start.target_length#}}。 初稿： {{#full_write.article_text#}}

扩写节点的输出变量设为expanded_text。接下来，在 TRUE 路径的最末端接一个结束节点 A，在扩写节点后面接结束节点 B。两个结束节点里都配置一个名为final_article的输出变量，A 节点把它指向article_text，B 节点把它指向expanded_text。

这种“分支结尾”的做法是新手最容易卡住的地方。Dify 允许一个流程有多个结束节点，运行时走到哪条分支，就返回哪个结束节点的结果。只要输出变量名字保持一致，调用方就不用关心内部走的是哪条路径。

3.8 联调与发布：从调试面板到API全流程

现在做一次完整联调。点击“运行”，填一个测试主题，比如“如何做项目复盘”，风格选“商业分析”，目标字数填 1000。观察节点依次执行，重点看知识检索是否有命中、字数统计的total_chars是否合理、条件分支走了哪条路径。如果走的是 FALSE 路径，说明扩写节点也正常工作了。

联调通过后，点击“发布”。发布后进入“API 访问”页签，生成 API 密钥，你就可以在外部系统里通过 API 调用这个工作流了。请求体里传的字段就是开始节点定义的输入：topic、style、target_length。返回里的data.outputs.final_article就是最终文章。

这里提醒一句：每次在工作流里改了配置，都必须重新点发布，线上 API 才会用到新版本。否则你以为改好了，其实线上跑的仍然是旧逻辑，这种情况我遇到太多次了。

4. Dify工作流新手最容易踩的6个坑，以及排查技巧

这一节是我最想写给新手看的。下面这些问题，几乎每一个都是我或者身边朋友在 Dify 工作流上真实踩过的，整理成速查表放在这里。

4.1 Dify工作流新手高频报错速查表

4.2 排查技巧实录：从变量传参到模型限流

踩过几次坑之后，我总结出一套自己的排查顺序：先看失败节点的输入，再看输出，最后才看代码。很多时候，问题根本不在“怎么写的”，而在“传进来的变量根本不是你以为的那个值”。

在画布上，如果一个节点运行失败，节点右上角会出现明显的错误状态。点进去，通常能看到具体的错误信息，比如超时、连接失败、类型不匹配。这个信息比你在画布上瞎猜有用得多。

另一个很实用的技巧是“隔离法”：当你怀疑某个中间节点有问题，就在它后面临时接一个结束节点，直接输出它本身，这样你能清楚看到它的返回值，排除后续所有节点的干扰。排查完再删除临时节点。这个方法看似笨拙，但在节点连成一大片时，真的能救命。

另外，调试运行同样会消耗真实 token，尤其是“知识检索后接长文本生成”这种链路，一次完整跑下来费用并不低。我现在的习惯是用短文本先把流程逻辑跑通，基本没问题了再拿长文本做最终联调。这样既节省费用，排查问题也更快。

再补充一点：模型服务商一般都有并发限制。如果你的工作流调用量比较大，Dify 端也会出现排队情况。建议在外部代码里做指数退避重试，或者把调用请求分散到不同时段，避免高峰期的限流影响线上业务。

5. 进阶方向：工作流还能这么扩展

把第一个工作流跑通之后，你可能会觉得不过瘾，想把更多业务塞进工作流里。下面这几个思路是我个人实践中总结出来的，能帮你走得更稳。

5.1 把复杂任务拆成多个工作流

我现在越来越少做超过 10 个节点的大工作流了。原因很简单：节点一多，任何一个环节改动都可能影响后面一串逻辑，调试成本指数上升。我更倾向于把一个大任务拆成几个单一职责的小工作流，再用外部代码或 HTTP 请求节点把它们串起来。

举个例子，一个完整的“竞品分析日报”可以拆成：素材采集工作流、信息去重工作流、报告生成工作流。每个工作流单独测试、单独发布，出了问题只改一个，不用牵一发动全身。

5.2 代码节点能帮你省下多少成本

代码节点天然适合做所有确定性的数据处理。我经常用它来做这些事：抽取 JSON 里的某个字段、统一日期格式、去除重复项、正则替换、计算字数、计算调用费用。这些逻辑放到代码节点里只是几行标准库的事，但如果硬塞给大模型，不仅结果可能出错，还要为每次调用付费。

一条很实用的原则：能确定计算的，就不要让模型猜。把确定性逻辑从 LLM 节点中剥离出去，你不仅能省下大量 token 费用，还能让整体的响应速度明显提升。

5.3 上线不是终点：日志监控与版本管理

工作流发布之后不代表一劳永逸。API 日志页面要经常看，关注调用量、失败率和平均耗时。如果某天失败率突然上升，多半是模型服务不稳定，或者知识库里的文档被改坏了。

Dify 支持保存历史版本。我的习惯是线上始终固定在一个稳定版本，新版本在草稿里改，联调通过后再发布。出现意外时，可以快速回滚到上一个稳定版本。别觉得自己用不上这个功能，等你线上跑一段时间，就知道“能回滚”三个字有多重要。

5.4 成本与性能的取舍

同一个工作流里，完全没必要所有 LLM 节点都用同一个大模型。分类、摘要、结构化提取这类简单任务，用轻量模型就够了；只有长文生成这种高质量任务，才值得动用更强的模型。把轻量任务放到轻量模型上，成本能差好几倍，效果差距却不大。

知识检索的top_k也不要一味调大。检索内容越多，提示词越长，token 成本越高，响应也越慢。对大多数写作场景，3 条高质量片段的效果，远好于 10 条低质量片段拼出来的大杂烩。

说回我自己，刚开始接触 Dify 工作流那阵子，最大的教训就是想一口吃成胖子。第一次搭工作流就塞了十几个节点，结果一大半时间都在排查变量引用。后来学乖了：先做最小可跑通版本，再一点一点加条件分支、加工具、加迭代。这个思路放到任何 AI 工作流上都适用。如果你照着这篇教程搭出了第一个智能写作助手，接下来不妨试着把“扩写”改成“多版本生成后人工筛选”，或者把知识检索换成 HTTP 调用外部搜索能力，玩法一下就打开了。先在调试面板里把每一步跑明白，你离熟练也就不远了。