企业官网建设流程全解析

如果你已经跟完了这个系列的前六篇，Dify 在你手里应该已经不是一个陌生词了：装好了 Docker 版，建过一两个会聊天的助手，也大概摸过知识库的入口。但说实话，真正让 Dify 和普通聊天框拉开身位的东西，是"AI工作流"这个功能——一个能在画布上通过拖拽连线、把大模型能力编排成固定流程的可视化编辑器。这篇我们直接从零到一搭一个文本摘要器：把一段长文章丢进去，几秒钟吐出干净的中文摘要。全程不写一行代码，从新建应用、拖节点、连线、调参、发布，到把工作流接给外部系统，一次性讲清楚。适合刚入门的同学照着重做，也适合已经玩过对话应用、想了解工作流模式的开发者换个思路。

1. 动手前先搭好环境：两种部署形态怎么选

1.1 云端版还是本地版，取决于你要拿它干什么

开始搭工作流之前，先回答一个绕不开的问题：你在哪跑 Dify？

如果你只是想快速验证"拖拽连线到底好不好用"，或者准备给团队做内部工具、做个给客户演示的 Demo，我建议直接用 Dify 官方提供的云服务。不需要关心服务器、Docker、域名证书这些东西，注册完就有完整的编辑器，模型供应商也帮你预设好了，打开就能拖节点。这篇文章里的所有步骤，云端版和社区版的操作路径几乎一样。

但如果你是公司内部要做数据敏感的信息处理，或者想完全控制模型请求的链路，那自部署更合适。社区版部署不算复杂，官方文档给的 Docker Compose 方式属于比较省心的路径，几台有 Docker 的机器就能跑起来。大概长这样：

git clone https://github.com/langgenius/dify.git cd dify/docker cp .env.example .env docker compose up -d

看似简单，但自部署的坑通常不在 Dify 本身，而在于前置条件。内存建议给到 8G 以上，否则多个服务同时跑起来容易把宿主机拖垮。另外，很多人部署完在浏览器访问时报证书相关错误，页面打不开。这时候先去检查入口层配置的证书链是否完整，再看服务器系统时间是否准确——证书校验失败有一半以上是这两种原因，而不是 Dify 本身的问题。第一次上手的话，云端版会少踩很多这种环境坑。

1.2 认识工作流编排页：节点、连线和变量

登录进 Dify 之后，你会看到"工作室"或者"应用"列表这样的入口。工作流的编排页和搭建积木类似：左侧是一堆可以拖进画布的节点，中间是空白的编排区域，右侧是当前选中节点的配置面板。

节点可以理解为"处理单元"。一个节点接收上游数据，做一件具体的事，然后把结果交给下游。开始节点负责定义整个流程的输入参数，LLM 节点负责调用大模型做推理，结束节点负责把最终结果输出给用户。中间那一根根连线，决定的是数据的流向，而不是代码里的函数调用顺序。你在画布上把 A 节点拉到 B 节点旁边，连上线，A 的输出就会变成 B 的输入。

这里最需要建立的心智模型是"变量"这回事。节点和节点之间传数据，不是复制粘贴，而是通过变量引用。比如你在开始节点里定义了一个叫text的输入字段，在 LLM 节点的提示词里就能用类似{{#start#.text}}这种写法把它引进来。实际动手时不需要背这个语法，Dify 的输入框旁边有变量选择器，鼠标点选上游节点里的字段就行。但明白了这套引用逻辑，你后面读别人导出的工作流模板（DSL 文件）时，就能一眼看懂这流程到底是怎么串起来的。

顺带说一下，工作流支持导出和导入。设计好的流程会变成一个 DSL 文件，发给同事就能在他那边复现。但很多人导入时遇到过版本不兼容的提示，这个我放到最后专门讲。

2. 核心三步：用开始、LLM、结束节点拼出文本摘要器

2.1 创建空白工作流

第 1 步，进入工作台，点击"创建空白应用"。这时候系统会让你选应用类型，这里选"工作流"，而不是"聊天助手"。

聊天助手类应用和工作流应用的区别，本质上是一个偏向自由对话、一个偏向固定流程。聊天助手适合开放式问答，用户问什么模型就答什么；工作流则适合"输入什么、做什么处理、输出什么都是可预期的"这种场景。文本摘要器天然适合工作流：输入是文章，中间是模型摘要处理，输出是摘要文本，整个过程是可以被明确定义的。

新建的应用可以起个简单的名字，比如"文本摘要器"。创建完会自动进入工作流编排页，页面上已经帮你放好了一个开始节点和一个结束节点，中间是空白的画布，等着你自己把处理逻辑补上。

2.2 配置开始节点：确定输入格式

点击画布上的开始节点，右侧会出现字段配置。在默认情况下，Dify 会给开始节点预置一个查询字段（sys.query）和文件上传字段。但我们要做的是文本摘要器，直接让用户填一大段文章，所以我习惯在开始节点里新增一个输入字段，名字叫text，类型选"段落"或者"长文本"。

之所以新增一个字段而不是直接用默认的查询字段，是为了语义更清晰。sys.query这个名字在后续的流程日志、API 调试里看到时，总会让人犹豫"这到底传的是什么内容"。你自己定义一个text字段，整个流程的可读性会好很多。字段类型要注意：如果打算处理长文章，一定选"段落"或"长文本"类型，不要选"文本"，因为单行文本类型在部分版本里会对长度有限制，粘贴一大段文章时容易出问题。

配置完开始节点，整个工作流的"入口"就定了。用户之后在 WebApp 里看到的表单、通过 API 提交过来的参数，都会以这个字段为基准。

2.3 配置 LLM 节点：把文章交给模型

从左侧节点面板里拖一个"LLM"节点到画布上，位置放在开始节点右边，然后把开始节点到 LLM 节点的线连上。

点开 LLM 节点配置文件，第一步是选择模型。前提是你已经在"设置—模型供应商"里接好了至少一个可用模型。我刚上手时用的是gpt-4o-mini这类性价比型模型，摘要这种任务不需要顶配模型也能有很好的表现。

接下来是提示词，这是决定摘要质量的关键。我的做法是把指令放在"系统提示词"区域，把文章内容放在"用户消息"区域，通过变量引用把开始节点的text传进来。一段非常简洁但是够用的提示词长这样：

系统提示词你是一个专业的文本摘要助手。请用中文输出不超过 300 字的摘要，保留原文的关键结论、核心数字和专有名词。不要添加原文没有的观点，不要输出评价性语言，直接输出摘要正文。

用户消息请对下面的文章生成摘要： {{#start#.text}}

注意那个{{#start#.text}}，在编辑器里你可以直接输入，也可以点输入框旁边的变量选择器，从开始节点里选text字段。如果用户消息里只有一段文字没有指令，模型可能不知道要干嘛；如果指令和文章混在一起没做分隔，模型又可能把指令本身当成文章内容。用系统提示词区分角色、用户消息里放任务和文章，是最不容易出错的组合。

2.4 接上结束节点：把结果吐出去

LLM 节点配置完成后，把它和结束节点连上线。

点开结束节点，它的配置里有一个或多个输出字段。默认情况下结束节点会有一个输出，你把它的引用指向 LLM 节点的输出字段就行。在变量选择器里选择 LLM 节点，然后选它的文本输出，结束节点就会把模型生成的摘要作为整个工作流的最终返回结果。

到这里，一个最小可用的文本摘要器已经跑通了。整个过程确实用不了 5 分钟：拖一个 LLM 节点、写一段提示词、连两根线、指一下输出字段，全部结束。这时候你可以点右上角的"运行"按钮，在弹出的测试面板里粘贴一段长文，运行之后就能在结束节点里看到摘要结果。

3. 决定摘要质量的细节：提示词模板与模型参数

3.1 结构化提示词：让模型知道边界

很多刚开始用工作流的人会有一个误区：提示词随便写写，反正"大模型能理解"。实际跑几次你就会发现，摘要质量不稳定的根源，往往不是选错了模型，而是提示词里没有把边界说清楚。

我过一个反例：如果系统提示词只有一句"请帮我总结这段文章"，模型输出可能附带"以下是这篇文章的摘要：""本文主要讲述了……"这类废话，甚至会把原文里的观点重复一遍再补一句"我认为"。但你把输出要求写清楚之后，模型的行为会立刻收敛。

我实际在用的摘要提示词模板，核心是三块：角色定义、处理要求、输出限制。角色定义让模型知道自己以什么身份处理任务；处理要求规定它关注哪些信息，比如"保留关键结论、核心数字和专有名词"；输出限制则告诉它不该做什么，比如"不要输出评价性语言""直接输出摘要正文"。千万别小看这最后一条，很多人写提示词从不写"不做什么"，模型就会自由发挥。

3.2 模型选择：摘要这种活儿不需要太贵的模型

文本摘要属于典型的"中等难度、高频率"任务，不需要大模型展示太复杂的推理能力，但对输出的准确性和格式稳定有要求。所以在模型选型上，我会推荐一些响应快、成本可控的型号。

实际操作中，你不需要把所有模型都配一遍。选一个综合表现不错的先用起来，之后对质量不满意再切换对比。我个人的偏好是先配 2-3 个不同供应商的模型，这样在 LLM 节点里切换对比时不需要改任何代码，直接下拉框换一下就行，非常方便。

3.3 温度与最大 Token：摘要任务的稳定开关

LLM 节点的参数区域里，有两个值值得花时间理解：温度和最大 Token。

温度控制的是模型的随机性。摘要这个任务讲究忠实于原文，不需要太多创意发挥，所以我一般把温度调到 0 到 0.3 之间。温度太高的话，模型可能每次跑出来的摘要重点都不一样，甚至自己脑补一些原文没有的内容。温度调到接近 0，同一篇文章多次运行得到的结果会稳定很多。

最大 Token 控制的是输出长度上限。如果你要求摘要不超过 300 字，理论上 300 字换算成 Token 大约在 400 到 500 之间，但考虑到模型可能用更长的表达方式，我建议把最大 Token 设置在 800 以上。设得太死容易在摘要写到一半时被截断，结尾会非常突兀。宁可多留一点余量，也不要让结果变成半截文章。

3.4 长文本怎么办：第一步先把边界定清楚

模型都有上下文窗口限制，比如某些模型的窗口是 128K Token，听起来很大，但如果是几万字的文章直接丢进去，仍然可能装不下，或者装下了但响应速度明显变慢。

文本摘要器第一步适合处理什么量级的文本？以我自己的经验，几千字到一万字左右的文章，直接传给模型是没问题的。如果你后面需要处理更长的内容，方向不是把整个文档塞给一个 LLM 节点，而是先做切分，分段生成摘要，再把多个摘要合并成最终结果。Dify 里可以配合文本处理节点或者知识库检索来实现这个效果。这些作为进阶方向，你了解到"分段摘要"这个词就行，后面可以再展开聊。

4. 跑通之后的发布：测试调试、生成 WebApp、接入 API

4.1 先点运行：认真观察每个节点的输入输出

一个常见误区是，工作流只要"看起来连对了"就算完成，结果一运行就报错。其实 Dify 的调试体验做得挺直观，问题的关键是你得养成"运行后看节点状态"的习惯。

点右上角的"运行"按钮，会弹出一个表单，表单里的字段就是你在开始节点里定义的输入。填上测试文本，点执行，整个工作流会从前到后依次跑一遍。每个执行过的节点上会显示输入和输出的预览，你可以逐个点开查看：开始节点的输出对不对，LLM 节点的输入是不是正确引用了文章内容，结束节点的输出是不是想要的摘要格式。

如果某个节点报错，画布上该节点会变成红色，点进去能看到具体的错误提示。最常见的有三类：一是变量引用不对，系统提示找不到某个字段；二是模型供应商的网络不通或者 Key 校验失败；三是文章超出模型窗口导致请求失败。看到错误先不要慌，顺着节点顺序一个点一个点排查，大多数问题一眼就能定位。

我自己的排查习惯是：先看开始节点，确认输入值确实传进来了；再看 LLM 节点，确认提示词里引用的变量没有拼写问题；最后看结束节点，确认输出字段引用正确。变量引用这关，我强烈建议在输入框里用变量选择器点选，不要手动敲双大括号，手敲很容易漏一个字段名。

4.2 保存并发布：让工作流真正变成别人能用的东西

调试通过之后，别忘了点"发布"。这是工作流区别于对话应用的一个重要节点。

发布之后，Dify 会为这个工作流生成一个可访问的 WebApp 地址。打开的界面类似一个简单的表单工具，用户在里面粘贴长文，点击提交，就能拿到摘要结果。这对于给团队内部做一个实用小工具来说已经非常够用了。你不用管前后端部署、数据库、接口鉴权，Dify 全部帮你搞定了。

更重要的是，工作流的发布和传统软件部署不一样。你改了工作流之后，再次点发布就会立即生效，不需要停服、不需要重新构建镜像。实际工作中，我经常是白天用 WebApp 跑着，晚上改一下提示词再发布，用户的访问链路完全无感知。这种"改完即生效"的体验，是用代码自己搭一个摘要服务很难比的。

4.3 API 接入：把工作流变成后端接口

WebApp 适合给人用，但如果你的项目是要把摘要能力集成到自己的产品里，那就需要走 API。

Dify 的每个应用都有自己的 API 访问入口。在应用详情页的"API 访问"标签页里，你可以创建 API 密钥。工作流应用的调用接口是/v1/workflows/run，请求体大致长这样：

curl -X POST 'https://your-host/v1/workflows/run' \ -H 'Authorization: Bearer app-xxxxxxxx' \ -H 'Content-Type: application/json' \ -d '{ "inputs": { "text": "这里放你希望摘要的文章内容" }, "response_mode": "blocking", "user": "test-user" }'

注意inputs里的字段名要和开始节点里定义的保持一致。你定义的是text，这里就传text。response_mode可以选blocking，等待全部结果生成后返回；也可以选streaming，让摘要结果像打字机一样流式输出。前者实现简单，后者用户体验更好，按你的产品场景取舍。

4.4 密钥管理的几个提醒

API 密钥的问题值得多说一句，因为我在项目里见过不少直接在前端代码里写死密钥的例子。Dify 生成的app-开头的密钥，本质上是后端的访问凭证，只应该存放在你自己的服务端。如果你的产品前端要直接调用摘要接口，正确的做法是你自己写个后端转发层，把密钥留在服务端，前端只和你自己的后端通信。

另外密钥也不是永久不变的。如果发现密钥疑似泄露，或者团队成员离职，第一时间去 API 访问页面吊销旧的、重建新的。Dify 的密钥粒度是应用级的，一个应用一个密钥，做权限隔离很方便。

5. 再加点东西：变量聚合、人工审核与高频报错排查

5.1 给摘要器加个"聚合输出"：摘要加关键词加字数

如果你觉得单纯的摘要不够用，还可以让工作流一次输出更多内容。这里就轮到变量聚合器上场了。

变量聚合器的用法很直白：接收多个变量，把它们组合成一个结构化对象，再交给下游节点。比如你想让摘要器的输出变成"摘要 + 关键词 + 原文字数"三段式结果，可以这样做：

• 在 LLM 节点旁边再拖一个 LLM 节点，提示词让它只输出 5 个关键词。
• 拖一个代码执行节点，用 Python 统计原文字数，一个len(text)就能搞定。
• 拖一个变量聚合器，把摘要文本、关键词列表、字数统计这三路结果聚合起来。
• 结束节点的输出不再直接引用最初的 LLM 节点，而是引用变量聚合器的输出。

这样在 WebApp 或者 API 返回结果里，就能一次性拿到结构化数据，而不是只有一段干巴巴的摘要。这个思路还可以继续扩展：摘要、翻译、情感分析都可以并行跑成多个 LLM 节点，最后统一聚合输出。

5.2 加人工审核节点：让用户在流程里填内容

很多人搜索"Dify 人工介入后怎么让用户填内容"，其实就是想在工作流执行到某一步时，停下来等用户补充信息。这个需求在 Dify 里有现成的节点支持，不需要写代码。

在 LLM 节点之后、结束节点之前，你可以插入一个人工审核类的节点。当流程执行到这个节点时，WebApp 端会停住，向用户展示一个表单或者确认界面，用户填写完成后，流程才继续往下走。

这个能力在实际业务中非常实用。比如公司内部的合同摘要流程，模型生成摘要初稿之后，需要法务确认一下再流转。人工审核节点就是那个"法务确认的闸门"，用户可以在界面上直接修改摘要内容，把修改后的内容作为最终输出。如果你熟悉代码实现，这个功能本质上是一个异步暂停、等待外部输入后再恢复的机制，但 Dify 把它封装成了拖拽节点，极大地降低了集成成本。

5.3 汇总几个高频报错：从 SSL 到插件配置

最后把我在使用过程中遇到最多的几个报错集中总结一下，方便你遇到类似问题时快速定位。

DSL 版本不兼容是很多刚接触 Dify 的人容易卡住的地方。你导出的工作流文件里自带一个 schema 版本号，如果这个版本号高于你当前系统的支持版本，系统就会拒绝导入。有些教程会让你用文本编辑器把版本号改低，这个操作对小版本差异可能有效，但如果新旧版本之间的节点类型差异很大，硬改版本号只会导致导入成功后部分节点无法解析。最稳妥的方式，始终是把你自己的系统升级到和模板相同的版本，或者在旧系统里照着模板结构重新搭一遍。

Unstructured API 的报错主要涉及到文件类型的文档处理。Dify 本身不会直接解析 PDF 和 Word 里的内容，它需要调用额外的文档解析服务来提取文本。如果你把文件直接传进工作流而没配置对应的文档解析插件，就会看到这个错误。解决方案是在插件市场安装对应的文档处理插件，或者更简单粗暴一点，先把文件转成纯文本再传给工作流。

5.4 一个排查顺序的建议

工作流报错时，最忌讳的是"对着红色节点一顿瞎改"。我自己踩过几次坑后，总结出一个固定的排查顺序：先确认输入，再审提示词，最后查模型。输入不对，后面全白搭；提示词写错，模型再好也白搭；模型本身配置有问题，就回到模型供应商页面去做连通性测试。按这个顺序走，90% 的报错能在两轮之内解决。

最后分享一个我自己用下来的小习惯：工作流越是复杂，越要保留一份最新的 DSL 导出文件。每次给工作流做较大改动前，先导出一份当前版本存起来。这一步的成本几乎为零，但能让你在大改之后后悔时一键回到可用状态。另外，LLM 节点里的模型最好指定具体的版本号，不要用"最新版"这种自动追踪的选项，否则同一条流程可能因为上游模型调整而悄悄改变行为。这不是技术难点，但很多从零搭工作流的人最容易漏掉的就是"可回滚"这三个字。