Dify 使用避坑指南｜生产环境实测

在过去一年里，Dify 作为开源 LLMOps 平台，逐渐成为很多团队搭建 AI 应用、智能客服、知识库问答、Agent 工作流的首选工具之一。它的优势很明显：上手快、界面友好、支持多模型、内置知识库、工作流能力较强，并且能够通过 API 快速接入业务系统。

但如果你真正把 Dify 用到生产环境，就会发现：能跑起来和稳定跑好，是两回事。

很多问题在本地 Demo 或测试环境中并不明显，一旦进入真实业务场景，比如高并发访问、大规模知识库、多租户权限、复杂工作流、模型成本控制、数据安全审计等，坑就会逐渐暴露出来。

本文基于生产环境实测经验，系统整理 Dify 在部署、模型接入、知识库、工作流、权限、安全、性能、运维等方面的常见问题和避坑建议，希望能帮助你少踩坑、少返工。

一、先说结论：Dify 适合什么，不适合什么？

在正式展开之前，先给一个相对客观的判断。

1. Dify 适合的场景

Dify 非常适合以下类型的应用：

• 企业内部知识库问答
• 智能客服机器人
• 文档助手、合同助手、制度助手
• 基于表单或流程的 AI 工作流
• 简单 Agent 应用
• 原型验证和 AI 应用快速搭建
• 多模型统一接入和管理
• 非研发人员参与配置 AI 应用

如果你的目标是快速搭建一个可用的 AI 应用，Dify 的效率非常高。相比从零开发前端、后端、向量库、提示词管理、日志系统、模型接口，Dify 能节省大量时间。

2. Dify 不太适合的场景

但 Dify 并不是万能的，以下场景需要谨慎：

• 极高并发、强 SLA 的核心业务系统
• 对权限隔离要求极高的金融、政务场景
• 复杂多智能体协作系统
• 需要高度定制推理链路的应用
• 对数据链路、审计、合规有严格要求的系统
• 需要完全自研可控的企业级 AI 中台

这并不是说 Dify 不能用于这些场景，而是说如果你要这么用，就必须做大量二次开发、架构隔离和运维增强，不能只依赖默认配置。

二、部署避坑：不要把测试环境当生产环境

很多团队部署 Dify 时，第一步通常是使用官方 Docker Compose，一键启动：

docker compose up -d

这在测试环境没问题，但生产环境千万不要简单照搬。

1. Docker Compose 可以用，但要做生产级改造

官方 Docker Compose 更适合快速体验。如果用于生产环境，需要重点关注：

• 服务是否拆分部署
• 数据库是否独立
• Redis 是否独立
• 向量数据库是否独立
• 是否配置持久化存储
• 是否配置日志收集
• 是否配置服务监控
• 是否有备份机制
• 是否有资源限制
• 是否接入反向代理和 HTTPS

最常见的坑是：所有服务跑在一台机器上，数据库、Redis、向量库和应用服务混在一起。

一开始访问量小没问题，等到知识库文档变多、用户并发增加、Embedding 任务堆积时，整个系统会变得非常不稳定。

2. 数据库不要使用临时容器方案

Dify 依赖 PostgreSQL。如果生产环境仍然用 Compose 里的数据库容器，至少要保证：

• 数据目录挂载到稳定磁盘
• 定期备份
• 设置合理连接数
• 监控磁盘使用率
• 监控慢查询
• 配置自动恢复策略

更推荐的方式是使用独立 PostgreSQL，例如：

• 云厂商 RDS
• 自建高可用 PostgreSQL
• 独立数据库服务器

生产环境中，数据库一旦损坏或数据丢失，恢复成本很高。尤其 Dify 中包含应用配置、用户数据、对话记录、知识库元信息等，千万不能轻视。

3. Redis 不要只当缓存看

Dify 中 Redis 不只是简单缓存，还可能承担任务队列、会话、限流等相关能力。Redis 异常可能会导致：

• 工作流任务失败
• 文档处理任务异常
• 应用响应变慢
• 后台任务堆积
• 登录或会话异常

生产环境建议：

• Redis 独立部署
• 开启持久化或使用云 Redis
• 设置合理内存上限
• 配置淘汰策略
• 监控内存、连接数、慢命令
• 避免和其他业务共用同一个 Redis DB

4. 环境变量要统一管理

Dify 的配置高度依赖环境变量，例如模型服务地址、数据库连接、Redis 配置、Secret Key、文件存储、向量库配置等。

常见坑包括：

• 修改 .env 后没有重启相关服务
• 多环境配置混乱
• 测试环境密钥误用于生产环境
• 生产环境暴露默认密钥
• 回滚版本时配置不兼容

建议至少建立三套配置：

• 开发环境
• 测试环境
• 生产环境

并使用配置管理工具或密钥管理系统，例如：

• Kubernetes Secret
• Docker Secret
• Vault
• 云厂商 KMS
• GitOps 配置仓库

注意：敏感配置不要直接提交到 Git 仓库。

三、模型接入避坑：不要只看能不能调用成功

Dify 支持 OpenAI、Azure OpenAI、Anthropic、Google、通义千问、智谱、DeepSeek、Moonshot、Ollama、自定义模型等多种模型接入方式。但生产环境最容易出问题的，恰恰是模型服务。

1. 国内环境要重点关注网络稳定性

如果你使用海外模型服务，例如 OpenAI、Anthropic，一定要考虑：

• 网络延迟
• DNS 解析
• 代理稳定性
• 请求超时
• API 限流
• 出口 IP 风控
• 合规风险

测试环境里单次请求成功，不代表生产环境稳定。真实用户并发访问时，模型服务抖动会直接影响用户体验。

建议：

• 配置多个模型供应商备用
• 设置合理超时时间
• 对关键应用增加降级策略
• 对高频应用使用国内可稳定访问的模型
• 对模型调用结果进行日志追踪
• 监控模型请求耗时、失败率和 Token 消耗

2. 模型参数不能全部使用默认值

Dify 提供了温度、最大 Token、Top-P 等参数配置。很多团队上线时直接使用默认参数，结果出现：

• 回复太发散
• 回复不稳定
• 长文本被截断
• 成本不可控
• 输出格式不稳定
• 多轮对话上下文过长

常见建议如下：

如果你的应用要求输出 JSON、表格、字段结构，建议降低 Temperature，并在提示词中明确格式要求。

3. 不同模型不要直接替换

很多人认为模型之间可以无缝切换，例如今天用 GPT-4o，明天换成 DeepSeek，后天换成 Qwen。实际生产中，这样很容易出问题。

不同模型在以下方面差异很大：

• 指令遵循能力
• 中文理解能力
• 长上下文处理能力
• 函数调用能力
• JSON 输出稳定性
• 对提示词的敏感程度
• 对知识库召回结果的利用方式
• 安全策略和拒答倾向

所以，模型切换前一定要做回归测试，至少覆盖：

• 正常问题
• 边界问题
• 敏感问题
• 长文本问题
• 多轮上下文问题
• 知识库无答案问题
• 格式化输出问题

不要只测试“你好”“介绍一下公司”这种简单问题。

四、知识库避坑：RAG 不是上传文档就完事

Dify 的知识库能力是很多人选择它的重要原因。但知识库问答质量不稳定，也是生产环境最常见的问题之一。

很多用户以为只要上传文档，就能获得一个准确可靠的知识库机器人。现实是：RAG 的质量很大程度取决于文档治理、切分策略、召回参数和提示词设计。

1. 文档质量决定问答上限

如果文档本身混乱，模型再强也救不了。常见问题包括：

• 文档版本混乱
• 内容重复
• 表格格式错乱
• OCR 识别错误
• 标题层级不清
• 文档中存在过期制度
• PDF 中大量图片无法解析
• 同一问题在不同文档中答案矛盾

上线知识库前，建议先做文档治理：

• 删除无效文档
• 合并重复内容
• 标注文档版本
• 明确生效时间
• 删除过期制度
• 将复杂表格转为结构化文本
• 为文档增加标题、章节和摘要
• 对重要文档人工校验解析结果

不要把 Dify 当成“垃圾文档回收站”。知识库质量差，用户最终会认为是 AI 不行。

2. 分段策略非常关键

知识库文档需要切分成片段后进行 Embedding。切分太短，语义不完整；切分太长，召回不精准，还会浪费上下文。

常见问题：

• 一个制度条款被切成两半
• 标题和正文分离
• 表格内容被拆散
• 多个无关主题混在一个片段
• 片段没有上下文导致模型误解

建议：

• 对制度类文档，按章节和条款切分
• 对 FAQ 类文档，按问答对切分
• 对产品手册，按功能模块切分
• 对接口文档，按接口维度切分
• 保留标题作为片段上下文
• 设置适当 overlap，避免上下文断裂

如果默认切分效果不好，可以考虑在上传前预处理文档，而不是完全依赖平台自动切分。

3. Embedding 模型不要随便换

知识库索引依赖 Embedding 模型。很多团队前期使用一种 Embedding 模型，后期切换另一种，但没有重新构建索引，结果召回质量明显下降。

需要注意：

• Embedding 模型变更后，应重新向量化知识库
• 中文场景应优先选择中文表现稳定的 Embedding 模型
• 多语言场景要测试跨语言召回效果
• 不同 Embedding 模型维度可能不同，向量库配置也会受影响

对于中文企业知识库，建议重点测试：

• 同义词召回
• 缩写召回
• 专有名词召回
• 长问题召回
• 口语化问题召回
• 跨章节问题召回

4. Top-K 和相似度阈值需要调优

Dify 知识库一般会配置召回数量和相似度阈值。如果 Top-K 太小，可能漏召回；如果太大，可能引入噪声。相似度阈值太高，会无结果；太低，会召回无关内容。

建议做一个测试集，包括：

• 高频业务问题
• 用户真实问法
• 相似但不同的问题
• 文档中不存在答案的问题
• 需要多片段组合的问题

然后对不同参数组合进行测试，例如：

上线前至少要做几十到几百条问题的评测，而不是凭感觉调参数。

5. 要处理“知识库无答案”的情况

生产环境中，用户经常会问知识库不存在的问题。如果没有处理好，模型可能会胡编。

建议在提示词中明确：

• 只能基于知识库内容回答
• 如果知识库没有相关内容，必须说明无法确认
• 不得编造政策、价格、流程、联系方式
• 可以建议用户联系人工客服或相关部门

示例提示词：

你是企业知识库助手。请仅基于检索到的知识库内容回答用户问题。
如果检索内容不足以回答，请明确说明“根据当前知识库资料无法确认”，不要编造答案。
如果不同资料存在冲突，请指出冲突，并提示用户以最新正式文件为准。

这类约束非常重要，尤其是制度、合同、医疗、金融、法务等场景。

五、工作流避坑：复杂流程不要一口气堆到底

Dify 的 Workflow 能力很强，可以编排 LLM、知识库、条件分支、HTTP 请求、代码节点、变量处理等。很多团队一开始会很兴奋，把所有逻辑都塞进一个工作流里，最后导致维护困难。

1. 工作流越复杂，越需要模块化

生产中常见的“巨型工作流”问题：

• 节点数量过多
• 分支逻辑复杂
• 变量命名混乱
• 错误处理缺失
• 调试困难
• 修改一个节点影响全局
• 多人协作容易覆盖配置

建议按照模块拆分：

• 意图识别模块
• 参数抽取模块
• 知识库问答模块
• 外部接口调用模块
• 结果校验模块
• 输出润色模块
• 异常处理模块

如果工作流过于复杂，可以考虑将核心业务逻辑放到后端服务中，Dify 只负责 AI 编排和交互。

2. HTTP 节点必须设置超时和异常分支

很多工作流会调用外部系统，例如 CRM、ERP、工单系统、订单系统、搜索服务等。外部接口一旦慢或失败，整个工作流就会卡住。

建议：

• 设置合理超时时间
• 对接口失败进行兜底处理
• 区分 4xx 和 5xx
• 对返回数据做格式校验
• 不要把敏感 Token 暴露在前端
• 对接口调用做日志记录
• 对高频接口加缓存

尤其在客服场景中，如果工作流依赖订单查询接口，一旦接口异常，用户体验会非常差。

3. 代码节点要谨慎使用

代码节点非常灵活，但也带来风险：

• 运行异常难排查
• 输入输出格式不稳定
• 代码逻辑无人维护
• 安全边界不清晰
• 复杂代码难以版本管理

建议代码节点只用于轻量处理，例如：

• 字符串清洗
• JSON 字段转换
• 简单规则判断
• 数组过滤
• 时间格式处理

如果涉及复杂业务逻辑、数据库操作、权限校验、外部系统事务，最好放到独立后端服务中。

4. 工作流必须做版本管理

很多人直接在 Dify 页面上改工作流，改完就发布。问题是，一旦线上出问题，很难快速回滚到之前稳定版本。

建议：

• 重要工作流修改前先复制备份
• 记录每次修改原因
• 建立测试应用和生产应用
• 使用测试集回归验证
• 发布前进行人工审核
• 保留历史版本说明

如果团队规模较大，应建立类似软件发布的流程，而不是随意点击发布。

六、提示词避坑：不要把提示词当一次性文案

提示词是 AI 应用的核心资产之一。在生产环境中，提示词不是写一段“你是一个智能助手”就结束了。

1. 提示词需要结构化

一个好的提示词通常包括：

• 角色定义
• 任务目标
• 输入说明
• 输出格式
• 约束条件
• 禁止事项
• 示例
• 异常处理方式

例如知识库客服助手可以这样设计：

角色：你是某公司的官方客服助手。

任务：根据知识库内容回答用户关于产品、价格、售后和流程的问题。

约束：
1. 只能基于知识库内容回答。
2. 不得编造价格、政策、承诺和联系方式。
3. 如果资料不足，请说明无法确认。
4. 回答要简洁、礼貌、可执行。
5. 如果用户情绪激动，要先安抚再回答。

输出要求：
- 使用中文回答。
- 分点说明。
- 如涉及流程，按步骤输出。

结构化提示词的好处是更容易维护、评测和迭代。

2. 提示词不能过长过杂

很多团队在提示词里塞入大量规则，结果模型反而执行不稳定。尤其当提示词包含互相冲突的规则时，模型会表现异常。

例如：

• “回答要简洁”同时要求“详细解释所有背景”
• “不得输出推测”同时要求“给出可能原因”
• “必须引用知识库”但又允许“自由发挥”
• “必须用 JSON 输出”但又要求“自然语言说明”

提示词要尽量清晰，避免冲突。如果规则很多，建议按优先级排序。

3. 要建立提示词评测集

提示词调整不能只凭主观感觉。建议准备固定问题集，每次修改后测试：

• 标准问题
• 长问题
• 模糊问题
• 诱导问题
• 无答案问题
• 敏感问题
• 多轮上下文问题
• 输出格式要求问题

这样才能知道提示词是变好了还是变差了。

七、权限与安全避坑：不要默认所有人都可信

Dify 常用于企业内部，但“内部系统”不等于安全。尤其当它连接知识库、业务接口、客户数据时，权限和安全必须重点关注。

1. 应用权限要分级

不同用户角色应有不同权限：

• 普通用户：只使用应用
• 业务管理员：维护知识库和提示词
• 开发人员：配置工作流和接口
• 系统管理员：管理模型、密钥和环境
• 审计人员：查看日志和使用记录

不要让所有人都有管理员权限。很多事故并不是黑客攻击，而是内部误操作。

2. API Key 要妥善管理

如果通过 Dify API 接入业务系统，API Key 一旦泄露，可能导致：

• 被恶意调用产生模型费用
• 获取敏感对话数据
• 调用内部工作流
• 绕过前端权限控制

建议：

• API Key 定期轮换
• 不在前端代码中暴露 Key
• 对调用来源做限制
• 对接口调用做限流
• 记录调用日志
• 泄露后能快速禁用

3. 知识库内容要做权限隔离

这是生产环境中很容易忽视的问题。

假设你把人事制度、财务制度、销售资料、客户合同都放进一个知识库，普通员工可能通过提问间接获取不该看到的信息。

建议：

• 按部门或角色拆分知识库
• 不同应用绑定不同知识库
• 敏感文档不要进入通用知识库
• 对查询结果做权限校验
• 对高敏数据进行脱敏
• 明确知识库维护责任人

如果业务要求严格权限控制，可能需要二次开发，而不能只依赖默认能力。

4. 对话日志可能包含敏感信息

用户在使用 AI 助手时，经常会输入：

• 手机号
• 身份证号
• 客户姓名
• 合同编号
• 订单信息
• 内部业务数据
• 账号密码
• 医疗或财务信息

这些内容可能被记录在对话日志中。生产环境需要明确：

• 日志保存多久
• 谁可以查看日志
• 是否需要脱敏
• 是否允许导出
• 是否用于模型训练
• 如何满足合规要求

对于高敏场景，建议在入口处做敏感信息识别与脱敏。

八、性能与成本避坑：上线后才发现贵，已经晚了

AI 应用和传统应用最大的不同之一，是每次调用都有模型成本。尤其多轮对话、知识库召回、工作流多节点调用，很容易让成本快速上升。

1. 监控 Token 消耗

生产环境必须监控：

• 单用户 Token 消耗
• 单应用 Token 消耗
• 单次请求平均 Token
• 总调用次数
• 模型费用
• 异常高消耗用户
• 不同工作流节点消耗

常见的高成本来源：

• 提示词过长
• 上下文轮数过多
• Top-K 设置过大
• 工作流多次调用大模型
• 使用高价模型处理简单任务
• 用户恶意刷接口
• 输出长度不受限制

建议对不同任务使用不同模型。例如：

• 意图识别用小模型
• 复杂推理用强模型
• 文本润色用中等模型
• Embedding 用专用模型
• 简单分类可用规则或传统算法

2. 控制上下文长度

多轮对话很容易把历史上下文越积越长，导致：

• 成本增加
• 响应变慢
• 模型遗忘重点
• 输出质量下降
• 超出上下文窗口

建议：

• 限制历史轮数
• 对长对话做摘要
• 不必要时关闭多轮上下文
• 对用户输入长度做限制
• 对知识库召回内容做压缩

并不是上下文越多越好。对客服类应用，保留最近几轮往往已经足够。

3. 设置限流和配额

上线后一定要防止滥用，包括无意滥用和恶意滥用。

建议配置：

• 单用户每日调用次数
• 单 IP 调用频率
• 单应用 Token 上限
• 失败重试次数限制
• 并发请求上限
• 异常用户封禁机制

如果 Dify 默认能力无法满足，可以在网关层或业务后端做限流，例如：

• Nginx
• API Gateway
• Kong
• APISIX
• 自研鉴权服务

九、日志与监控避坑：没有监控就没有生产环境

很多团队上线 Dify 后，只关注“页面能不能打开”。但生产环境真正需要监控的是完整链路。

1. 至少监控这些指标

应用层：

• 请求量
• 响应时间
• 错误率
• 并发数
• 用户活跃数

模型层：

• 模型调用次数
• 模型响应时间
• 模型失败率
• Token 消耗
• 各模型成本

知识库层：

• 召回耗时
• 召回命中率
• 无答案比例
• 用户负反馈问题
• 文档处理状态

基础设施层：

• CPU
• 内存
• 磁盘
• 网络
• PostgreSQL 连接数
• Redis 内存
• 向量库状态
• Celery 或后台任务积压情况

2. 日志要能定位问题

当用户反馈“AI 回答不对”时，你需要能够追踪：

• 用户原始问题是什么
• 命中了哪些知识片段
• 模型输入 Prompt 是什么
• 模型输出是什么
• 工作流走了哪个分支
• 外部接口返回了什么
• 是否触发了异常处理
• 最终响应耗时是多少

如果这些信息缺失，排查问题会非常困难。

3. 建立反馈闭环

知识库类应用上线后，一定要收集用户反馈，例如：

• 点赞/点踩
• 无答案反馈
• 错误答案反馈
• 人工补充答案
• 高频未命中问题

然后定期进行：

• 补充知识库
• 优化文档切分
• 调整召回参数
• 修改提示词
• 更新工作流逻辑

AI 应用不是一次性上线，而是持续运营。

十、升级避坑：不要盲目追新版本

Dify 更新频率较快，新版本通常会带来新功能和修复，但生产环境不能盲目升级。

1. 升级前必须看 Release Note

重点关注：

• 数据库迁移
• 配置项变更
• 模型供应商配置变化
• API 兼容性
• 工作流节点变化
• 知识库能力变化
• 已知问题

不要看到有新版本就直接拉镜像重启。

2. 建议建立灰度环境

升级流程建议：

1. 备份数据库和配置；
2. 在测试环境升级；
3. 验证核心应用；
4. 测试知识库问答；
5. 测试工作流；
6. 测试 API 调用；
7. 检查日志和性能；
8. 低峰期生产升级；
9. 升级后观察至少 24 小时。

如果是核心业务应用，建议保留回滚方案。

3. 插件和自定义能力要特别注意

如果你使用了自定义模型供应商、插件、外部工具、二次开发接口，升级后可能出现兼容问题。一定要提前验证，不要假设新版本完全兼容旧配置。

十一、生产环境推荐实践清单

下面给一份比较实用的上线检查清单。

1. 基础设施

• [ ] PostgreSQL 独立部署并定期备份
• [ ] Redis 独立部署并配置监控
• [ ] 向量数据库持久化存储
• [ ] 文件存储使用稳定方案
• [ ] 配置 HTTPS
• [ ] 配置反向代理
• [ ] 配置日志采集
• [ ] 配置资源限制
• [ ] 配置服务健康检查

2. 模型服务

• [ ] 模型供应商稳定可用
• [ ] 设置请求超时
• [ ] 设置备用模型
• [ ] 监控 Token 消耗
• [ ] 评估不同模型输出质量
• [ ] 控制高价模型使用范围
• [ ] 配置失败降级策略

3. 知识库

• [ ] 文档已治理
• [ ] 文档版本明确
• [ ] 切分策略已验证
• [ ] Embedding 模型稳定
• [ ] 召回参数已调优
• [ ] 无答案策略已配置
• [ ] 建立用户反馈机制
• [ ] 敏感文档已隔离

4. 工作流

• [ ] 节点命名清晰
• [ ] 变量命名规范
• [ ] HTTP 节点有超时
• [ ] 异常分支完整
• [ ] 外部接口有鉴权
• [ ] 工作流有备份
• [ ] 发布前经过测试
• [ ] 核心逻辑不过度依赖代码节点

5. 安全合规

• [ ] 管理员权限最小化
• [ ] API Key 未暴露
• [ ] 日志访问有权限控制
• [ ] 敏感数据已脱敏
• [ ] 知识库按权限隔离
• [ ] 有审计记录
• [ ] 有数据删除和备份策略

6. 运维监控

• [ ] 监控请求量和错误率
• [ ] 监控模型调用耗时
• [ ] 监控数据库和 Redis
• [ ] 监控后台任务队列
• [ ] 配置告警
• [ ] 建立问题排查流程
• [ ] 定期复盘用户反馈

十二、一个比较稳妥的落地架构建议

如果你计划在企业生产环境使用 Dify，可以参考下面的架构思路：

用户 / 业务系统
      |
API Gateway / Nginx / 鉴权层
      |
Dify Web / API 服务
      |
--------------------------------
| PostgreSQL 数据库             |
| Redis                         |
| 向量数据库                    |
| 文件存储 OSS / S3 / MinIO     |
--------------------------------
      |
模型服务层
      |
OpenAI / Azure / 通义 / DeepSeek / 私有模型 / Ollama
      |
外部业务系统
CRM / ERP / 工单 / 搜索 / 数据库服务

关键原则是：

• Dify 不直接裸露在公网；
• 模型 Key 不暴露给前端；
• 数据库和 Redis 独立部署；
• 知识库和文件存储要可备份；
• 网关层做鉴权、限流和审计；
• 外部业务接口由后端服务统一管理；
• 生产和测试环境严格隔离。

十三、常见问题总结

1. Dify 可以直接用于生产吗？

可以，但不建议使用默认测试部署方式直接上生产。需要针对数据库、Redis、向量库、文件存储、监控、安全、备份做生产级改造。

2. 为什么知识库回答经常不准确？

通常不是单一原因，可能包括：

• 文档质量差
• 切分不合理
• Embedding 模型不适合
• 召回参数未调优
• 提示词约束不足
• 用户问题过于模糊
• 模型本身能力不足

需要从“文档治理—召回—生成—反馈”完整链路排查。

3. 工作流应该尽量做复杂吗？

不建议。工作流适合做 AI 编排，但不适合承载所有复杂业务逻辑。复杂逻辑最好放在后端服务中，Dify 通过 HTTP 节点调用。

4. 怎么降低模型成本？

可以从以下方面入手：

• 缩短提示词
• 控制上下文轮数
• 限制输出长度
• 降低 Top-K
• 简单任务使用小模型
• 对高频结果做缓存
• 设置用户配额和限流
• 监控异常调用

5. 升级 Dify 要注意什么？

升级前必须备份，先在测试环境验证，再生产发布。重点关注数据库迁移、API 兼容性、工作流配置、知识库索引和插件兼容问题。

十四、结语：Dify 是好工具，但不是银弹

Dify 的价值在于，它大幅降低了 AI 应用开发门槛，让团队可以快速完成从想法到上线的过程。对于知识库问答、智能客服、工作流助手等场景，它确实非常高效。

但生产环境不是 Demo。真正上线后，你会面对稳定性、成本、安全、权限、日志、评测、反馈、升级等一系列工程问题。

如果只把 Dify 当成一个“上传文档就能问答”的工具，大概率会踩坑；如果把它当成一个 LLMOps 平台，并围绕它建立完整的工程化体系，Dify 就能发挥很大价值。

最后给出一句实践总结：

Dify 适合快速搭建 AI 应用，但生产环境一定要按工程系统来治理。文档要治理，提示词要评测，工作流要版本化，模型要监控，权限要隔离，数据要备份。

只有这样，Dify 才能从一个好用的低代码工具，真正变成企业可持续运营的 AI 应用平台。