Dify实战指南：从Windows本地部署到企业级AI应用定制化开发

1. Dify 到底在解决什么问题

1.1 AI 应用定制化的"最后一公里"

先说个真实感受。我自己带团队做内部AI助手的时候，用大模型API写个Demo对话，一晚上就能跑通，看起来特别简单。但真要把这个Demo变成一个业务能用的定制化应用，事情就完全不一样了：知识库怎么接？多轮对话的状态怎么管理？用户问的问题怎么分流到不同的处理逻辑？谁在什么时候调用了哪个模型、花了多少钱？答错了怎么回溯？这些问题堆在一起，才是AI应用定制化的真正门槛。

Dify 之所以在圈子里火起来，恰恰是它把这些"最后一公里"的事做成了开箱即用的模块。它是一个开源的大语言模型应用开发平台，核心思路很直接：把模型接入、提示词编排、知识库检索、工作流设计、日志追踪这些环节，全部可视化、组件化。你要做的不是从零开始写代码，而是像搭积木一样，把业务逻辑用节点串起来。这个思路对做技术的人友好，对不太懂代码的业务同学更友好，因为大部分配置都在界面上完成。

我见过不少团队，早期都是自己写一套后端服务去调模型API，后来发现要维护的东西越滚越大，最终都转向了 Dify 这类平台。它解决的不是"能不能调模型"的问题，而是"怎么把一个模型调用变成真正可交付的定制化产品"的问题。

1.2 为什么不自研，而是选 Dify 这类平台

有人会问：我自己用 FastAPI 包一层模型调用，接个向量库，不也能做定制化应用吗？能，但要付出的成本远超你的预期。我列一下自研方案里最容易忽略的工作量：

• 多模型切换与密钥管理：不同供应商的 API 格式不同，要做统一封装和负载切换。
• 知识库全链路：文档解析、分段、嵌入、向量检索、引用溯源，每个环节都是坑。
• 可观测性：每轮对话的输入输出、模型耗时、Token消耗、错误日志，没有这些线上根本没法排查问题。
• 多租户与权限：不同部门、不同项目之间要隔离，光这一块就够一个后端团队忙一两个月。
• 可视化编排与快速迭代：业务方改一个流程，如果都要改代码重新发布，迭代效率会非常低。

Dify 社区版把这些能力都做进去了，而且支持本地部署。数据在自己服务器上，模型密钥也掌握在自己手里，这对很多做企业内部应用、政务项目、垂直行业应用的团队来说是硬性要求。你在本地把整套平台跑起来，团队内部共享使用，既保留了定制化能力，又不用从零重复造轮子，这是它最大的价值。

1.3 当前版本与生态概况

我写这篇文章时，社区版已经迭代到了 1.10 左右。这个版本最值得一提的就是多租户能力和工作流编排的稳定性。相比早期的版本，现在的应用类型更清晰：聊天助手、Agent、Chatflow 工作流、Workflow 自动化、文本生成，每种类型对应不同的使用场景。模型接入方面，OpenAI、通义千问、文心一言、DeepSeek、Ollama 本地模型等主流渠道都能直接配，知识库支持多种文档格式上传与切片，还内置了 Rerank 重排序能力。

整个平台部署方式也比较简单，主流是用 Docker Compose 拉起来。接下来的章节，我会从 Windows 本地部署开始，一步步带你走完从安装到上线一个完整定制化应用的整个过程。

2. 开学第一课：Windows 本地部署的完整过程与踩坑记录

2.1 部署前的环境准备：为什么绕不开 Docker Desktop

Dify 官方对 Linux 和 macOS 的支持最顺滑，但国内很多开发者的主力机器是 Windows。别担心，Windows 上部署并不难，核心是先装好 Docker Desktop。

我自己实测下来，Dify 的容器编排用的是 Docker Compose，所以环境准备阶段最重要的一件事就是把 Docker Desktop 装好，并确保它能正常运行。有几个安装细节我建议你留意：

• Docker Desktop 安装完成后，务必在 Settings -> General 里勾选 "Use the WSL 2 based engine"。如果你还没装 WSL2，它会提示你安装，这一步尽量不要跳过，WSL2 后端比 Hyper-V 后端在文件读写和内存管理上要稳得多。
• 在 Settings -> Resources 里，把内存至少调到 4GB 以上。Dify 的容器比较多，包括 API 服务、Worker 服务、PostgreSQL、Redis、Weaviate 或 Qdrant 向量库、Nginx 等，默认 2GB 内存很容易 OOM。
• 如果你机器上之前装过旧版 Docker Toolbox，建议先彻底卸载干净，否则端口映射和卷挂载都会出现奇怪的问题。

装完 Docker Desktop，验证一下环境。打开 PowerShell 或者 CMD，运行：

docker --version docker compose version

两个命令都能正常输出版本号，说明环境OK。

2.2 从压缩包到启动成功的全流程命令

Dify 的 GitHub Releases 页面提供了 Source Code 压缩包下载，大家搜"Dify releases"就能找到。下载解压后，你会看到一个 dify-main 文件夹，里面有个 docker 子目录，这个目录就是我们部署的入口。

打开 CMD 或 PowerShell，进入这个 docker 文件夹：

cd dify-main\docker

接着复制环境变量模板。这一步是很多人第一次部署时最容易漏掉的：

cp .env.example .env

Windows 下如果 cp 命令不可用，可以用copy .env.example .env代替。.env文件里包含了很多可配置项，端口、密钥、模型供应商的默认配置都在这里。

建议你先打开.env看一眼这两个关键配置：

EXPOSE_NGINX_PORT=80

如果 80 端口被你本机的其他服务占了，建议改成一个自定义端口，比如 8088，否则启动后 Nginx 会起不来。

还有一个容易被忽略的点：.env里的SECRET_KEY。如果你留空，Dify 会在首次启动时自动生成一个临时密钥，但容器重启后可能会导致 session 失效。最稳妥的做法是手动填一串随机字符串，比如可以用任意密码生成工具生成 32 位以上的随机值。

然后启动服务：

docker compose up -d

第一次启动会拉取很多镜像，包括 api、worker、web、postgres、redis、weaviate、nginx 等，耗时取决于网络情况，正常需要几分钟到十几分钟。镜像拉取完成后，查看状态：

docker compose ps

等所有服务的状态都变成 healthy 或 running，浏览器访问：

http://localhost

如果你改了端口，就访问http://localhost:8088。首次打开会进入管理员账号设置页，设置你的邮箱和密码，之后就进入主界面了。

2.3 部署时我实测过的高频问题

这里把大家问得最多、也是我自己踩过的几个问题集中说下。

问题一：docker compose 命令报错，提示 command not found 或者无法识别。

很可能是 Docker Desktop 没有正常启动，或者当前终端是新开的但 Docker 服务还没就绪。重新启动 Docker Desktop，等托盘图标变稳定后再试。另外注意，旧版本 Docker Desktop 用的是docker-compose（带横杠），新版本用docker compose（空格），两个都试一下。

问题二：首次启动后网页打不开。

先看容器状态，docker compose ps如果不是 all healthy，用docker compose logs -f nginx查看 nginx 日志。我遇到最多的情况是端口冲突，之前有团队内部工具占着 80 端口，Nginx 一直起不来。解决方式就是改EXPOSE_NGINX_PORT。

问题三：API 服务报数据库连接错误。

这个通常出现在升级或异常重启之后。老规矩，先看日志：

docker compose logs -f api

如果提示数据库还没初始化好，等一下再刷新页面。第一次启动时，api 容器会自动执行数据库迁移，耗时较长，页面显示 503 是正常的，耐心等 1-2 分钟再访问。如果一直起不来，检查是否内存不足，或者 .env 里的数据库密码配置和 postgres 容器不一致。

问题四：Windows 下 Docker 磁盘占用越来越大。

Dify 的日志和向量库数据都会以卷（volume）的形式存在 Docker 的虚拟磁盘里。建议在 Docker Desktop 设置里给虚拟磁盘设置上限，比如 64GB，同时定期执行docker system prune清理无用数据。如果做的项目比较多，也可以把 Weaviate/Qdrant 的数据卷单独挂载到外部盘，防止虚拟磁盘膨胀。

3. 理解 Dify 的底层抽象：应用、模型、知识库是怎么协同的

3.1 应用类型怎么选：直接决定你的搭建方式

部署完平台，下一步就是创建应用。我先强调一个新手最容易迷惑的点：Dify 里的"应用类型"不只是 UI 上的选择，它直接决定了底层流程引擎的能力边界。选错了，后面要推倒重来。

我自己常用的选择逻辑是：

如果只是做一个简单的内部知识问答，Chatbot 加知识库就够了；但如果要做一个"先判断意图、再选择知识库、最后调用工单系统"的智能客服，那就必须用 Chatflow 或 Agent。我的建议是：凡是想在对话过程中插入业务逻辑，想对用户问题做分类、路由、条件处理，就直接选 Chatflow。它兼容 Agent 的大多数能力，但又比 Agent 多了可视化编排的确定性。

3.2 模型供应商配置与系统提示词的设计

创建应用后，第一件事是配置模型。点击"编排"页面右上角的模型选择器，如果还没配置任何模型，系统会引导你去"设置 -> 模型供应商"里添加。

以配置 OpenAI 为例，需要填 API Key；如果用国内模型或本地模型，选择对应的供应商即可。个人开发阶段建议把多个模型都配上，比如主对话用一个大模型，Embedding 用另一个专门的嵌入模型，Rerank 用重排模型，这样能充分发挥 Dify 的分层设计。

模型配置好之后，系统提示词设计就变得特别重要。在 Dify 里，提示词不再是"塞给模型的一句话"，而是整个应用的行为准则。因为知识库检索、工作流执行都是围绕提示词展开的。我写过的最有效的系统提示词结构是这样的：

# 角色 你是某某企业的智能助手，负责... # 任务 1. 首先根据用户问题检索知识库... 2. 如果知识库中没有相关内容... 3. 回答时必须引用来源... # 限制 - 不要编造信息 - 如果不确定，明确告知用户

有一点要特别注意：在 Chatflow 中，不同节点有自己的提示词上下文，系统提示词写在"LLM 节点"里，而不像 Chatbot 那样在整体配置里写一次。这个差异很多新手没注意到，导致写了半天发现没生效。

3.3 一条最小可用 Chatflow 的诞生

我们来搭建一条最简单的 Chatflow：用户提问 -> 检索知识库 -> 大模型回答。

进入应用编排页面，选择 Chatflow 类型，你会看到画布上有几个节点。

开始节点：输入变量。默认会有sys.query，也就是用户的当前问题。这是 Chatflow 的起点。

知识检索节点：点击画布添加节点，选择"知识检索"。这里要关联一个你已经创建好的知识库，设定检索 TopK。我建议 TopK 先设 3 或 5，不要贪多，召回太多片段反而可能引入噪声。

LLM 节点：添加"LLM"节点，选择模型，然后在提示词里引用前面节点的输出。比如在系统提示词里写"基于以下知识库内容回答用户问题"，然后把知识检索节点的输出变量用{{#knowledgeRetrieval.result#}}的方式插入用户提示词。

直接回复节点：最后连接"直接回复"节点，把 LLM 节点的输出{{#llm.text#}}作为回复内容。

这条链路跑通后，你就拥有一个带知识库增强的定制化问答助手了。整个操作全程可视化，不需要写后端代码。我自己给团队做内部政策问答时，从创建应用到上线一共花了不到半小时，后续调提示词、换知识库也都是在界面完成，效率比纯代码方案高得多。

4. 工作流的进阶玩法：从线性到条件分支

4.1 工作流节点的心智模型

Chatflow 和 Workflow 真正强的地方，是可以把业务逻辑做成流程图。你需要先理解每个节点的定位，才知道什么时候该用哪个。我按自己的使用频率给常用节点做个分类：

• 开始节点：定义整个工作流的输入。Chatflow 里固定有sys.query，Workflow 里可以自定义多个输入字段。
• LLM 节点：大模型调用单元。重要的不是"调用模型"这个动作，而是它既可以做对话生成，也可以做信息抽取、分类、格式化输出。
• 知识检索节点：融合知识库内容。
• 问题分类器：按用户问题内容分到不同分支，本质上是让模型做意图判断。
• 条件分支节点：类似代码里的 if/else，通过变量比较决定走哪条路径，不消耗模型调用，免费且稳定。
• 代码执行节点：支持 Python 和 Node.js，用来做数据清洗、格式转换、调用第三方接口前的预处理。
• HTTP 请求节点：调用外部系统的 REST API。
• 模板转换节点：用 Jinja2 语法把多个变量拼成一段文本。
• 变量聚合器：把多个节点输出合并成一个变量。
• 迭代节点：对列表数据循环处理。
• 直接回复 / 结束节点：把结果返回给用户。

核心心智模型是：每个节点都是纯函数式的，输入变量 + 处理逻辑 = 输出变量。你在画布上看到的每根线，都代表数据流的方向，而不是代码执行的先后顺序。

4.2 用条件分支实现业务规则

我举个例子，团队内部要做一个"IT 支持助手"，用户问题可能是"怎么重置密码"，也可能是"我的电脑蓝屏了怎么办"，甚至可能是"今天天气怎么样"。这些问题的处理策略完全不同：

• 知识库里有标准答案的，走知识检索 + LLM 回答。
• 不在知识库范围内的，转人工或者给一个兜底回复。
• 闲聊类问题，直接让模型自由回答。

用 Chatflow 怎么实现？

第一步，用问题分类器节点把用户问题分成三类：it_faq、unknown、chitchat。问题分类器的本质是让大模型做一次低成本分类，输出一个类别标识。

第二步，添加三个分支，分别对应三种分类结果。分类结果作为条件分支的判断依据。it_faq分支走知识检索 + LLM；unknown分支走一个模板节点，输出"该问题已转人工，请稍后"；chitchat分支走一个 LLM 节点，让模型自由回答，不检索知识库。

第三步，三个分支最终汇聚到一个直接回复节点。

这套流程跑通后，你的应用就不再是"一个模型 + 一个知识库"的线性结构了，它变成了一个真正按业务规则运行的定制化系统。后面想加新类别，直接在分类器和分支里加即可，不用改代码，也不用重新发版。

4.3 代码节点与 HTTP 节点：把 Dify 接进你的业务系统

很多团队用 Dify 做定制化应用时会遇到一个类似的问题：AI 的回答需要触发真实业务动作，比如创建工单、查询订单状态、发送通知。这时候就要用到 HTTP 请求节点和代码执行节点。

我做过一个合同问答助手，用户问"我的合同审批到哪一步了"，大模型从问题里提出合同编号后，需要调用内部 OA 系统查询审批状态。实现方式是：

先用参数提取节点（或 LLM 节点）从用户问题中提取出合同编号，然后 HTTP 请求节点调用 OA 系统的查询接口：

GET /api/contract/{contract_number}/approval Authorization: Bearer {{#custom_token#}}

拿到接口返回值后，因为 OA 返回的是 JSON，而用户问的是自然语言，还需要用 LLM 节点把 JSON 翻译成一段人能读懂的答复。如果返回结果里有多个字段需要清洗，也可以用代码执行节点先做一下数据处理：

def main(response: str) -> dict: import json data = json.loads(response) return { "status": data.get("status", "未知"), "current_node": data.get("current_approver", "未知"), "history": data.get("approval_history", []) }

这里有三个经验想分享：

• 对外部系统调用的鉴权信息，不要直接写死在提示词里，环境变量里配置好，再通过变量引用。
• HTTP 请求节点要设置合理的超时时间，我一般设 10 秒，接口超时后走一个失败分支，给用户一个"系统繁忙"的兜底。
• 外部系统返回的数据结构经常不稳定，最好在 HTTP 请求后加一个代码节点做健壮性处理，避免因为一处字段不存在导致整个节点报错。

5. 知识库流水线实战：RAG 效果的关键在于细节

5.1 分段策略分不好，召回质量直接拉垮

知识库是很多 AI 定制化应用的核心，但也是效果差异最大的环节。我见过同样的文档，有人喂进去回答准确率 90%，有人只有 50%，问题基本出在分段策略上。

Dify 创建知识库时，会让你选择分段模式。通用模式下，可以设置分段长度和分段重叠长度。分段长度指每一段文本包含多少 token，分段重叠指相邻两个分段之间重叠多少内容。为什么需要重叠？因为如果一段内容恰好在某个句子中间被切断，下一段开头缺失了上下文，检索召回时就会漏掉关键信息。

我的经验是：普通业务文档，分段长度定 300 到 500，重叠长度 50 到 100。太长，检索定位不精准，模型一次性塞入的上下文冗余过多；太短，语义不完整，召回效果差。如果文档是标准化的工单记录、FAQ 列表，可以把分段调小一点；如果是制度文件、研究报告这类长文，分段调大一点。

还有一个容易被忽略的设置叫"清洗"规则。Dify 支持自动清洗，比如去掉多余换行、URL 等。这些选项在创建知识库时一定要开。真实文档里的噪音远比你想的多，一个多余的空格都可能让向量检索效果打折。

5.2 索引与嵌入：高质量 vs 经济的选择逻辑

Dify 创建知识库时会让你选索引方式：高质量和经济学。这里我强烈建议默认用高质量，除非你的文档数量极大且对效果要求不高。

高质量模式会调用 Embedding 模型对每个分段做向量化，存入向量数据库。这样检索时可以用向量的语义相似度进行匹配，也就是不仅能匹配关键词，还能匹配语义相近的表述。经济模式只做关键词索引，部署成本和调用成本低，但检索效果比较弱。比如用户搜"怎么报销"，如果文档里写的是"费用申请流程"，经济模式可能召回不到，高质量模式可以。

Embedding 模型选哪个？如果部署的是本地环境，我建议选支持中文效果好的模型，比如通义千问的 text-embedding-v3 或 BGE 系列模型。模型一旦选好，最好固定下来，不要频繁更换。因为更换 Embedding 模型意味着所有知识库分段都需要重新向量化，数据量大时耗时比较长。

5.3 混合检索 + Rerank：让回答质量上一个台阶

如果你发现纯向量检索的召回结果里总混着不相关的内容，或者相关文档排不到前面，那大概率需要开启混合检索 + Rerank。

Dify 的检索模式里可以选择"混合检索"，同时使用向量检索和全文检索，然后把两者的结果合并。这个策略的好处是：向量检索抓住语义相似的内容，全文检索抓住关键词完全匹配但向量距离未必近的内容，两者互为补充。

合并后的结果列表还需要重排序，这就是 Rerank 模型的作用。Rerank 会对召回的候选片段重新打分，把和用户问题真正相关的内容排到最前面。在我的实测里，开启 Rerank 之后，回答精准度的提升非常明显，尤其是那些问题描述和文档表述不完全一致的场景。

Dify 界面里配置 Rerank 的入口在知识库的"检索设置"或应用编排的"知识检索"节点中。配置好 Rerank 模型后，知识检索节点会自动把检索结果经过重排再输出给 LLM。注意，Rerank 会额外消耗一定费用和延迟，但对质量要求高的场景，这个成本完全值得。

5.4 政务知识库这类场景的实践体会

结合热词里提到的"政务 RAG 知识库"，我多说几句。政务类项目和我之前做的企业内部知识库有一个显著区别：对答案的准确率、权威性和溯源要求极高。用户问的是政策条款，模型不能自由发挥，回答必须能对应到原始文件。

在这类场景里，我建议：

• 知识库文档来源标注清晰，分段时保留文件名、章节号、发布时间等元数据，便于引用来源。
• LLM 提示词中强制要求"仅基于知识库内容回答，并在回答末尾列出参考文档名称"。
• 开启检索结果引用功能，前端展示来源链接，让用户能点击查看原文。
• 知识库更新要有明确流程，政策文件更新后要重新上传并清理旧版本，避免模型引用过期内容。

政务场景通常还会要求本地化部署和权限隔离，Dify 社区版支持私有化部署，配合多租户功能就能为不同科室划分独立工作区。这一点在下一章展开讲。

6. 从个人开发到团队协作：多租户、权限与升级维护

6.1 社区版多租户与工作区机制

Dify 社区版从早期版本开始就有工作区（Workspace）机制，到了 1.10 版本，多租户能力明显增强。一个 Dify 实例可以创建多个工作区，不同工作区之间在应用、知识库、成员、模型配置上是隔离的。

这个机制对团队使用非常关键。我给一个事业单位做过一套系统，里面涉及人事、财务、行政三个部门，每个部门的知识库和应用完全不能互通。如果没有多租户机制，就得分别部署三套 Dify，维护成本高得多。有了工作区隔离，一个实例统一管理，数据层面天然分开。

具体操作上，系统管理员在"管理后台"可以创建工作区、邀请成员、分配角色。常用角色有：

• 工作区所有者：管理该工作区的一切，包括成员权限、模型配置、应用发布。
• 普通成员：能创建和编辑应用，但不能管理其他成员。
• 只读成员：只能查看已经发布的应用，适合业务方体验和测试。

这里要提醒一点：在多租户环境下，模型供应商密钥建议在"模型供应商"里统一配置，而不是每个成员各自填自己的 Key，否则密钥容易泄露且无法统一统计成本。

6.2 日常维护与在线升级：Windows 环境怎么做

Dify 社区版迭代速度很快，新功能、新模型支持、Bug 修复都会在下一次版本更新里体现。如果一直是旧版本，会错过不少好用的能力。但升级这件事做不好，容易把线上环境搞挂。

我自己的升级习惯是这样的：先备份，再升级，先在一个测试环境验证没问题，再操作生产环境。

如果你是 Docker Compose 部署，手动升级流程大致如下：

# 进入 docker 目录 cd dify-main\docker # 停止服务 docker compose down # 备份旧数据：确认卷的存在，备份整个 docker 目录和相关卷数据 docker volume ls | grep dify # 备份 .env cp .env .env.backup # 拉取新代码（如果是 git clone 的方式） git pull origin main # 如果你是从 GitHub releases 下载压缩包的方式： # 1. 先把整个 dify-main 目录重命名备份 # 2. 解压新版压缩包 # 3. 把旧版本 docker 目录下的 .env 复制到新版本对应位置 # 重新构建并启动 docker compose up -d --build

系统提示是否执行数据库迁移，通常 api 容器启动时会自动执行。启动后查看日志：

docker compose logs -f api docker compose logs -f worker

这两个服务是 Dify 的核心，日志正常输出说明升级成功。

6.3 我升级过程中遇到的数据兼容问题

我在一次从 0.6 升到 0.8 的经历中栽过跟头：升级后知识库检索返回的结果全部为空。查了半天发现，新版本对向量数据库的结构有变更，旧知识库的索引需要重建。解决办法是在"知识库 -> 索引设置"里手动触发重新嵌入，让所有分段重新向量化。

这个经验之后，我每次升级前都会做两件事：

• 先读 Release Notes，看是否有破坏性变更，特别是向量库、数据库结构相关的调整。
• 升级后在测试环境跑几条典型问答，对比升级前后的回答效果，确认知识库返回正常再切生产。

还有一个容易被忽略的问题：升级后，模型供应商的配置项可能会变化，比如某些旧版本的模型名在新版本里被替换了。升级后进入"模型供应商"界面检查一下，看看是否有标红的配置项，重新选择模型即可。

7. 三个月实战后的经验沉淀

7.1 最值得投入精力去研究的几个方向

做了几个项目之后，我越来越觉得，Dify 这类平台的上手门槛其实不高，真正拉开差距的是下面这几件事：

第一，可观测性意识。Dify 自带日志和历史记录功能，能查看每一轮对话的完整输入输出、走的哪些节点、调用了哪个模型。这个能力很多人没用起来。建议每次调试应用时，养成看日志的习惯，尤其是判断"回答变差是因为提示词问题、知识库召回问题还是模型问题"时，日志会给你明确的线索。

第二，提示词的系统化管理。在 Dify 里改提示词太方便了，方便到有些人会随手乱改，导致效果忽好忽坏。我现在的做法是：每次调整提示词之前，先复制原版本到工作区的"标注"或外部文档里，记录调整原因和效果对比，相当于给提示词做版本管理。

第三，成本控制。多个模型并存时，成本差异非常大。我建议按场景做模型分级：复杂任务用强模型，简单任务用低成本模型。Dify 里的模型配置可以在不同节点设置不同模型，完全可以实现"分类用便宜模型，生成用昂贵模型"的降本策略。

第四，知识库的持续更新。知识库不是建好就不用管了。业务手册、政策文件、FAQ 都在变，我的习惯是每个月对知识库做一次巡检，清理失效文档，增加新文档，重新做分段评估。如果不持续维护，知识库的回答准确率会随着时间逐渐下滑。

7.2 我踩过的几个具体坑

第一个坑：温度参数调太高导致 RAG 回答飘了。

有段时间做智能客服，发现同样的知识库，回答质量上不去。排查到最后是 LLM 节点的温度设置成了 0.9。对知识库问答场景，温度过高会让模型在检索结果之外自由发挥，产生"幻觉"。现在我做 RAG 类应用，温度一律设 0.1 到 0.3，既保准确性，又保一定自然度。

第二个坑：知识库更新策略不对，脏数据污染了结果。

有一次文档更新时，我直接把新版本传上去，旧版本没有删除。结果包含新旧两套政策的知识库，模型回答时可能引用旧政策。政务类文档更新尤其要注意：上传新版的同时，停用或删除旧版，或者通过多知识库分组做好版本隔离。

第三个坑：工作流条件分支的边界条件没想清楚。

条件分支节点里如果变量为 null，或者字符串空格没处理，分支会走到默认路径。有一次用户问题没有提到任何合同编号，参数提取节点返回空值，结果 HTTP 请求节点带着空参数调外部系统，返回了一堆无效信息。现在的做法是：在 HTTP 请求前加一个代码节点做参数校验，发现空值直接走兜底分支。

7.3 一些给新手的实用建议

如果看到这里你已经准备开始在 Dify 上做自己的应用，我给你三个最实在的建议：

• 先用 Chatflow 做一个小而完整的场景，别上来就搭大而全的复杂工作流。把一条链路跑通，你才能体会到 Dify 的核心设计逻辑，后面添功能就顺了。
• 把系统提示词当作产品需求来写，多轮迭代。好的提示词不是一次写出来的，是基于日志反馈不断调整出来的。
• 善用 Dify 的"发布"能力，每个版本发布前先保存为草稿，做好新旧版本对比，再发布到生产。这样出问题还能随时回滚。

我在几个项目里测试下来，Dify 真正高效的地方在于：它把 AI 应用定制化中 80% 的重复性工作——模型接入、知识库、工作流、权限管理——都收敛到了一次部署、可视化配置里。你省下来的时间和精力，完全可以投入到最核心的业务逻辑调优上。这也是为什么我现在向身边团队推荐 AI 应用落地路线时，第一个提到的平台就是它。