Dify 实战案例分享｜生产环境实测

在过去一年里，大模型应用从“概念验证”快速走向“业务落地”。很多团队最开始只是想做一个聊天机器人、知识库问答或者智能客服，但真正进入生产环境之后，很快会发现：提示词不是全部，模型也不是全部，工程化能力、数据治理、权限控制、成本管理、稳定性保障，才是决定一个 AI 应用能否长期运行的关键。

Dify 作为一个开源的大模型应用开发平台，提供了工作流、Agent、知识库、模型接入、API 发布、可视化编排、日志追踪等能力，比较适合团队快速搭建并迭代 AI 应用。本文结合一次真实生产环境落地经验，分享 Dify 在企业内部知识助手、智能客服分流、运营文案生成等场景中的使用方式、架构设计、上线过程、踩坑经验与优化建议。

一、项目背景：为什么选择 Dify？

我们的业务场景并不是单纯做一个“能聊天”的机器人，而是希望构建一套可以长期运行、支持多部门复用的大模型应用平台。最初团队面临几个典型问题：

1. 内部文档分散

   • 产品文档在飞书；
   • 技术文档在 Confluence；
   • 客服话术在知识库系统；
   • 运营活动说明在表格和群公告里。

2. 业务人员反复咨询同类问题

   • 新员工问制度；
   • 客服问产品规则；
   • 销售问报价口径；
   • 运营问活动细则。

3. 人工客服压力较大

   • 大量用户问题并不复杂；
   • 但需要人工判断属于售前、售后、技术支持还是投诉建议；
   • 高峰期响应延迟明显。

4. AI 应用开发效率低

   • 如果每个场景都由研发从零写接口、接模型、做权限、做知识库，成本非常高；
   • 业务部门希望可以参与提示词配置和流程调整；
   • 研发团队希望只维护底层能力，不想陷入大量重复需求。

在调研 LangChain、Flowise、Dify、自研平台等方案后，我们最终选择 Dify 作为第一阶段的落地平台。原因主要有以下几点：

• 上手成本低：可视化配置能力较强，业务人员经过培训后也能参与应用调整；
• 支持多种应用类型：聊天助手、文本生成、Agent、工作流都可以覆盖；
• 知识库能力内置：支持文档上传、分段、向量检索、召回配置；
• API 发布方便：配置好的应用可以直接通过 API 集成到内部系统；
• 日志和调试友好：可以查看用户输入、模型输出、Token 消耗、引用文档等信息；
• 开源可私有化部署：符合企业对数据安全和内网部署的要求。

二、生产环境部署方案

Dify 官方提供了 Docker Compose 部署方式，适合快速启动。但生产环境中，我们没有直接使用最简单的单机部署，而是根据业务规模做了相对稳妥的架构设计。

1. 基础架构

整体架构如下：

用户入口
  ├── 企业微信机器人
  ├── 内部管理后台
  ├── 客服系统
  └── 运营工具平台
        │
        ▼
API 网关 / 鉴权层
        │
        ▼
Dify API 服务
        │
        ├── Web 服务
        ├── Worker 服务
        ├── Redis
        ├── PostgreSQL
        ├── 向量数据库
        └── 对象存储
        │
        ▼
大模型服务
  ├── OpenAI / Azure OpenAI
  ├── 国内大模型 API
  └── 私有化模型服务

在生产环境中，我们重点关注以下组件：

如果只是内部试用，Docker Compose 足够。但如果要接入真实业务系统，就必须考虑：

• 服务是否可以横向扩展；
• 数据是否定期备份；
• 日志是否可追踪；
• 模型调用失败是否有降级策略；
• 接口是否有鉴权；
• 用户数据是否会被泄露；
• 成本是否可控。

2. 模型接入策略

生产环境中我们没有只依赖单一模型，而是按照场景区分模型：

这样做的好处是明显的：不是所有任务都需要调用最贵、最强的模型。比如“判断用户问题属于售前还是售后”这种分类任务，完全可以用低成本模型完成；而“根据产品资料生成一篇面向客户的解决方案”，则更适合使用能力更强的模型。

三、实战案例一：企业内部知识助手

1. 业务目标

第一个落地场景是企业内部知识助手。目标很明确：让员工可以通过企业微信或内部后台，直接询问制度、流程、产品规则、技术文档等问题。

典型问题包括：

• “报销发票抬头是什么？”
• “新客户开通试用账号需要什么流程？”
• “某产品的 API 调用频率限制是多少？”
• “售后工单超过 24 小时未处理怎么办？”
• “今年年假规则和去年有什么变化？”

2. 知识库建设

知识库并不是简单把文档全部上传就结束。我们在实际使用中发现，知识库质量直接决定问答质量。

最初我们把大量文档直接导入 Dify，结果出现了几个问题：

• 文档过长，分段不合理；
• 同一个问题在多个文档里有不同版本答案；
• 历史文档没有清理，导致模型引用过期规则；
• 表格类内容解析不稳定；
• 一些文档标题不清晰，检索召回效果差。

后来我们建立了一套知识库治理流程：

1. 按业务域拆分知识库

   • 人事制度知识库；
   • 财务流程知识库；
   • 产品规则知识库；
   • 客服话术知识库；
   • 技术接口知识库。

2. 统一文档格式

   • 每篇文档必须有明确标题；
   • 每个段落只描述一个主题；
   • 重要规则使用列表呈现；
   • 表格内容尽量转换成结构化文本；
   • 废弃内容必须标记或删除。

3. 设置知识责任人

   • 每个知识库指定业务负责人；
   • 定期检查过期文档；
   • 重大规则变更后同步更新；
   • AI 输出错误时可以追溯到具体文档。

4. 优化分段策略

   • 对制度类文档采用较短分段；
   • 对技术文档保留接口说明的完整上下文；
   • 对 FAQ 类内容使用一问一答格式；
   • 对流程类内容保留步骤顺序。

3. 提示词设计

我们给内部知识助手设置了比较严格的系统提示词。核心原则是：只基于知识库回答，不知道就说不知道，不允许编造。

示例提示词片段如下：

你是企业内部知识助手。
请根据检索到的知识库内容回答员工问题。
如果知识库中没有明确答案，请直接说明“当前知识库中未找到相关信息”，不要自行编造。
回答时请尽量简洁，并在必要时列出步骤。
如果问题涉及制度、金额、审批流程等敏感内容，请提醒用户以最新官方制度为准。

这个提示词看似简单，但在生产环境中非常重要。因为企业内部知识问答最怕的不是“不回答”，而是“自信地胡说”。对于流程、报销、合同、权限、客户承诺等问题，一旦 AI 编造答案，可能造成实际损失。

4. 上线效果

上线一个月后，我们统计了内部知识助手的使用情况：

需要注意的是，82% 的满意度并不意味着剩下 18% 都是错误答案，其中包括：

• 知识库没有相关内容；
• 用户问题表达不清；
• 多个部门规则冲突；
• AI 答案不够细；
• 引用文档过旧。

因此，后续优化重点并不是单纯换更强模型，而是持续治理知识库。

四、实战案例二：智能客服分流

1. 场景说明

第二个场景是客服系统中的智能分流。我们没有一开始就让 AI 完全替代人工客服，而是让它先做三个动作：

1. 判断用户问题类型；
2. 提取关键信息；
3. 推荐处理路径。

比如用户输入：

“我昨天刚续费，但是系统还是提示账号过期，麻烦帮我看一下。”

AI 需要识别出：

{
  "intent": "售后问题",
  "category": "账号/续费异常",
  "urgency": "中",
  "need_human": true,
  "extracted_info": {
    "time": "昨天",
    "issue": "续费后账号仍提示过期"
  }
}

然后客服系统根据结果自动分配给对应队列。

2. 为什么不直接让 AI 回复用户？

这是很多团队容易踩的坑。刚开始大家很兴奋，觉得既然 AI 可以回答问题，那就直接让它接管客服。但实际测试后我们发现：

• 用户问题中经常包含订单号、手机号、账号等敏感信息；
• 很多问题需要查询实时系统数据；
• AI 对业务边界不一定稳定；
• 如果回答错误，用户体验会变差；
• 某些投诉类问题必须人工介入。

所以我们采用了更稳妥的策略：AI 先做辅助，不直接做最终决策。

在生产环境中，AI 最适合先承担以下任务：

• 意图识别；
• 工单摘要；
• 用户情绪判断；
• 优先级评估；
• 推荐回复模板；
• 查询知识库并给客服参考。

3. Dify 工作流设计

在 Dify 中，我们通过工作流实现了客服分流逻辑：

用户输入
  ↓
敏感信息初步检测
  ↓
意图识别模型
  ↓
知识库检索
  ↓
规则判断节点
  ↓
输出结构化 JSON
  ↓
客服系统接收并分配

其中最关键的是输出格式控制。我们要求模型必须输出固定 JSON 字段，方便后端系统解析。

提示词中明确规定：

请严格输出 JSON，不要输出 Markdown，不要输出解释。
字段包括：intent、category、urgency、need_human、summary、suggested_action。
如果无法判断，请将 intent 设置为 unknown。

生产测试中，模型偶尔还是会输出多余文本。为了解决这个问题，我们在后端增加了 JSON 解析校验。如果解析失败，则自动重试一次；如果仍失败，则走默认人工队列。

4. 效果与收益

智能分流上线后，最明显的收益是客服首响效率提升。系统能够在用户提交问题后自动完成初步判断，减少人工查看和转派时间。

实际收益包括：

• 工单分类准确率稳定在 85% 左右；
• 高峰期人工分单压力明显降低；
• 客服可以更快看到用户问题摘要；
• 简单问题可直接推荐标准话术；
• 投诉和紧急问题更容易被提前识别。

当然，这个场景也有局限。比如用户表达非常模糊时，AI 很难准确判断；如果业务规则频繁变化，知识库和提示词也需要同步更新。

五、实战案例三：运营文案生成

1. 场景说明

第三个场景是运营文案生成。运营团队经常需要写活动标题、推文开头、短信文案、弹窗提示、商品介绍等。过去这类需求虽然不复杂，但会消耗大量时间。

我们基于 Dify 创建了多个文本生成应用：

• 活动标题生成器；
• 小红书风格文案助手；
• 短信营销文案助手；
• 产品卖点提炼工具；
• 用户通知优化工具；
• A/B 测试文案生成器。

2. 模板化输入

相比开放式聊天，运营文案生成更适合模板化输入。比如活动标题生成器要求用户填写：

• 活动主题；
• 目标用户；
• 产品卖点；
• 文案风格；
• 字数限制；
• 是否需要包含数字；
• 是否需要突出优惠。

这样模型输出会更加稳定，也更容易控制质量。

示例输入：

活动主题：618 会员限时折扣
目标用户：已注册但近 30 天未购买用户
产品卖点：会员专属价、限时优惠、赠送积分
文案风格：直接、有吸引力
字数限制：20 字以内

示例输出：

1. 618会员专享价，限时回归福利
2. 错过再等一年，会员折扣限时开抢
3. 老用户专属福利，618限时省更多
4. 会员限时特惠，积分好礼一起拿
5. 30天未购？这次福利别再错过

3. 生产中的质量控制

运营文案生成看起来风险较低，但也需要控制：

• 不能夸大优惠；
• 不能承诺不存在的权益；
• 不能使用违规广告词；
• 不能包含敏感词；
• 不能生成与品牌调性冲突的内容。

因此我们加入了两层机制：

1. 提示词约束

   • 不得使用“最强”“第一”“永久有效”等绝对化表达；
   • 不得承诺未提供的信息；
   • 不得编造价格、折扣、库存；
   • 输出必须符合品牌语气。

2. 人工审核

   • AI 生成内容只作为草稿；
   • 正式投放前必须由运营人员确认；
   • 高风险渠道需要法务或品牌审核。

上线后，运营团队反馈最明显的价值不是“完全替代写作”，而是提升初稿产出速度。过去想标题可能需要半小时，现在几分钟就能拿到多个方向，再由人工筛选优化。

六、生产环境中的关键经验

1. 不要迷信模型能力

很多问题不是模型不够强，而是输入信息不清楚、知识库质量差、业务规则冲突。生产环境中，大模型应用的稳定性往往来自系统设计，而不是单纯来自模型参数。

比较有效的做法是：

• 把复杂任务拆成多个步骤；
• 用工作流限制模型自由发挥；
• 对关键输出做格式校验；
• 对高风险场景设置人工确认；
• 对模型回答增加引用来源；
• 对异常情况设置兜底逻辑。

2. 知识库需要持续运营

知识库不是一次性工程，而是持续运营工作。建议建立以下机制：

如果没有知识治理，再好的 RAG 系统也会逐渐失效。

3. API 集成要有鉴权和限流

Dify 应用发布 API 后非常方便，但生产环境一定不能裸奔。建议在 Dify 前面增加统一 API 网关，处理：

• 用户身份认证；
• 应用权限控制；
• 调用频率限制；
• IP 白名单；
• 请求日志；
• 异常告警；
• 成本统计。

特别是接入外部用户场景时，必须防止恶意刷接口导致模型费用飙升。

4. 成本控制非常重要

大模型应用上线后，成本很容易被忽视。我们实际遇到过测试人员批量导入长文档、用户连续提问、提示词过长导致 Token 消耗偏高的情况。

可采取的成本控制措施包括：

• 不同场景使用不同模型；
• 控制上下文轮数；
• 限制单次输入长度；
• 优化知识库召回数量；
• 精简系统提示词；
• 对低价值请求使用小模型；
• 对异常高频用户限流；
• 定期查看 Token 消耗报表。

5. 日志追踪决定排障效率

当用户反馈“AI 回答错了”时，不能只看最终回答，还要追踪完整链路：

• 用户原始问题是什么；
• 检索到了哪些知识片段；
• 模型实际输入了什么上下文；
• 模型输出了什么；
• 是否命中了旧文档；
• 是否存在提示词冲突；
• 是否是模型幻觉；
• 是否是业务规则本身不清晰。

Dify 的日志功能对排查问题很有帮助，但如果业务系统也接入了 AI，最好将用户 ID、会话 ID、应用 ID、请求时间、模型名称等信息统一记录，方便跨系统追踪。

七、踩坑总结

1. 文档越多不代表效果越好

很多人认为把所有文档都丢进知识库，AI 就会变聪明。实际情况恰恰相反，如果文档重复、过期、冲突，模型更容易答错。

知识库建设要追求“准确、清晰、可维护”，而不是单纯追求数量。

2. 提示词不能解决所有问题

提示词可以约束模型行为，但不能代替业务规则。如果希望模型稳定输出结构化结果，除了提示词，还需要：

• 工作流节点控制；
• 输出格式校验；
• 异常重试；
• 后端兜底；
• 必要时使用规则引擎。

3. 不要让 AI 直接处理高风险决策

涉及合同、财务、法律、投诉、医疗、安全等场景时，AI 最好作为辅助工具，而不是最终决策者。生产环境中应明确 AI 的角色边界。

4. 业务人员必须参与

AI 应用不是研发部门单独能做好的。研发可以负责部署、接口、安全和平台能力，但知识库内容、业务规则、回复口径必须由业务人员参与维护。

5. 上线前必须做真实问题测试

不要只用理想问题测试。上线前应收集真实用户问题，包括：

• 表达不完整的问题；
• 带错别字的问题；
• 多意图混合问题；
• 情绪化问题；
• 超出知识库范围的问题；
• 含敏感信息的问题；
• 需要实时查询的问题。

这些问题更能暴露生产环境中的真实风险。

八、推荐的上线流程

结合本次实战经验，一个比较稳妥的 Dify 应用上线流程如下：

需求梳理
  ↓
场景风险评估
  ↓
知识库整理
  ↓
应用原型配置
  ↓
提示词与工作流设计
  ↓
内部测试
  ↓
真实问题集评测
  ↓
灰度上线
  ↓
日志分析与问题修复
  ↓
正式上线
  ↓
持续运营

其中“真实问题集评测”和“灰度上线”非常关键。不要因为 Demo 效果好就直接全量上线。大模型应用在演示环境中往往表现惊艳，但生产环境中会遇到大量边界问题。

九、结论：Dify 适合什么样的团队？

经过生产环境实测，我们认为 Dify 非常适合以下团队：

• 希望快速搭建大模型应用，但不想完全从零开发；
• 有多个业务部门需要 AI 能力支持；
• 希望业务人员参与提示词和流程配置；
• 需要私有化部署或内部知识库问答；
• 希望通过 API 将 AI 能力集成到现有系统；
• 正在探索智能客服、知识助手、内容生成、流程自动化等场景。

但也要客观看待，Dify 不是万能方案。它可以显著降低大模型应用开发门槛，但生产落地仍然需要工程能力、数据治理能力和业务运营能力。尤其在复杂系统集成、高并发调用、严格权限控制、模型精细评测等方面，仍然需要研发团队做额外建设。

最终，我们对 Dify 的定位是：它不是简单的聊天机器人搭建工具，而是一个适合快速验证和持续迭代的大模型应用平台。

如果团队能够做好知识库治理、应用权限、日志追踪、成本控制和人工审核机制，Dify 完全可以支撑一批真实生产环境中的 AI 应用。真正决定项目成败的，也并不是“用了哪个模型”或“用了哪个平台”，而是是否把 AI 应用当成一个需要持续运营的产品来建设。