Dify 使用避坑指南｜零基础可学

在过去一年里，越来越多的团队开始使用 Dify 搭建 AI 应用：客服机器人、知识库问答、文本生成工具、工作流自动化、企业内部助手、数据分析助手等。相比从零写代码接入大模型，Dify 的优势很明显：可视化编排、快速接入模型、支持知识库、支持工作流、支持 API 发布，适合产品经理、运营、业务人员、创业团队以及没有深厚开发背景的人快速上手。

但也正因为 Dify 上手门槛低，很多初学者会在使用过程中遇到一些“看起来很简单，实际很容易踩坑”的问题。例如：知识库明明上传了文档，机器人却答非所问；工作流节点逻辑越搭越乱；提示词写了一大堆，效果反而更差；模型调用费用突然飙升；部署好了却访问不了；企业内部数据接入后又担心安全问题。

这篇文章会以零基础用户也能理解的方式，系统梳理 Dify 的使用思路、常见坑点、解决方法和最佳实践。读完之后，你应该能够更稳地搭建一个可用、可靠、可迭代的 AI 应用。

一、先理解 Dify 到底是什么

在使用 Dify 之前，最重要的是不要把它简单理解成“一个聊天机器人平台”。Dify 更准确的定位是：一个用于构建、调试、发布和运营 AI 应用的低代码平台。

它通常可以帮你做这些事情：

1. 接入大语言模型

   • OpenAI
   • Azure OpenAI
   • Anthropic Claude
   • 通义千问
   • 智谱
   • DeepSeek
   • Ollama 本地模型
   • 其他兼容 OpenAI API 的模型

2. 创建 AI 应用

   • 聊天助手
   • 文本生成应用
   • Agent 应用
   • 工作流应用

3. 管理知识库

   • 上传 PDF、Word、TXT、网页等资料
   • 文档切分
   • 向量化
   • 检索增强生成，也就是常说的 RAG

4. 编排复杂流程

   • 条件判断
   • 多模型协作
   • HTTP 请求
   • 变量传递
   • 代码节点
   • 外部工具调用

5. 发布和集成

   • Web App
   • API 调用
   • 嵌入网站
   • 与企业系统集成

所以，Dify 并不是一个“点几下就万事大吉”的工具。它降低了 AI 应用开发门槛，但并不会自动帮你解决业务逻辑、数据质量、提示词设计、成本控制和安全合规等问题。

二、避坑前提：不要一开始就追求“大而全”

很多新手第一次用 Dify，最容易犯的错误就是：一上来就想做一个“超级智能助手”。

比如希望它同时具备：

• 公司制度问答
• 销售话术生成
• 客户问题分析
• 数据报表解读
• 自动发邮件
• 自动查库存
• 自动下工单
• 自动生成合同
• 自动调用多个系统

看起来很美好，但实际很容易失败。因为 AI 应用不是功能越多越好，而是越明确越容易做好。

正确做法：先做一个小而清晰的场景

建议从以下场景开始：

一个好的入门目标应该满足三个条件：

1. 资料来源清楚
2. 用户问题范围可控
3. 答案质量容易判断

例如，“做一个能够回答公司请假制度的机器人”，就比“做一个公司全能 HR 助手”更适合新手。

三、坑一：知识库上传了，但回答仍然不准确

这是 Dify 新手最常遇到的问题之一。

很多人以为，只要把文档上传到知识库，AI 就一定能准确回答。实际上，知识库问答的效果取决于多个环节：

1. 文档本身质量
2. 文档切分方式
3. 向量模型质量
4. 检索参数设置
5. 提示词约束
6. 用户问题表达
7. 大模型生成能力

任何一个环节出问题，最终回答都可能不理想。

1. 文档质量差，知识库效果一定差

如果你的文档本身混乱，AI 很难准确回答。

常见问题包括：

• 文档里有大量口语化内容
• 标题层级混乱
• 同一个问题在多个地方有不同说法
• 旧制度和新制度混在一起
• 表格内容没有解释
• PDF 扫描件识别错误
• 文档里存在大量无关内容

例如，公司制度文档里同时写着：

员工每年可享受 5 天带薪年假。

另一个地方又写着：

工作满一年后享受 7 天年假。

如果没有明确适用条件，模型就可能随机引用其中一个答案，导致用户觉得“AI 胡说”。

解决方法

在上传知识库之前，最好先对文档做一次清洗：

• 删除过期内容
• 删除重复内容
• 给每个章节加清晰标题
• 对表格增加文字说明
• 把长篇 PDF 拆成多个主题文档
• 将重要规则整理成 FAQ 格式
• 明确适用范围和生效时间

一个简单但有效的原则是：

你自己读起来越清楚，AI 检索和回答的效果越好。

四、坑二：文档切分设置不合理

Dify 在处理知识库文档时，通常会将长文档切分成多个片段。因为大模型不能每次都读取整本文档，只能从知识库中检索相关片段，再结合问题生成答案。

如果切分过大，会导致片段包含太多无关信息，检索不精准。

如果切分过小，又可能把完整语义切断，模型只拿到一半信息，回答自然不完整。

举个例子

原文是：

员工入职满一年后可享受年假。工作满一年不满十年的，每年享受 5 天年假；工作满十年不满二十年的，每年享受 10 天年假；工作满二十年以上的，每年享受 15 天年假。

如果切分过小，可能变成：

员工入职满一年后可享受年假。

另一个片段是：

工作满一年不满十年的，每年享受 5 天年假。

当用户问“我工作 12 年有几天年假？”时，如果只检索到第一个片段，就无法得到准确答案。

建议设置

对于普通中文知识库，可以参考：

• 切分长度：500～1000 字
• 重叠长度：50～150 字
• 标题结构清晰的文档：按标题切分
• FAQ 文档：按问答对切分
• 法规、制度、合同类文档：适当增大切分长度

当然，不同场景需要测试。不要迷信某个固定参数。

最佳实践

上传文档后，一定要做检索测试：

• 输入真实用户可能提出的问题
• 查看命中的知识片段是否相关
• 如果命中片段不对，优先调整文档和切分
• 不要一上来就改提示词

很多时候，回答不准不是模型不行，而是根本没有检索到正确内容。

五、坑三：提示词写得越长，效果越差

很多人认为提示词越详细越好，于是写出一大段规则：

你是一个专业、严谨、热情、友好、耐心、细致的智能客服，你需要根据知识库内容回答用户问题，不允许胡说，不允许编造，不允许输出无关内容，如果用户问题不清晰，你要追问，如果用户情绪不好，你要安抚，如果用户问到不属于知识库的内容，你要拒绝……

这类提示词并非完全没用，但如果堆得太多，容易出现几个问题：

1. 模型抓不住重点
2. 规则之间互相冲突
3. 输出变得机械
4. 消耗更多 Token
5. 影响知识库内容的使用

好提示词的核心

对于知识库问答类应用，提示词重点不是“夸角色”，而是明确：

• 回答依据
• 回答边界
• 输出格式
• 不确定时怎么办
• 是否允许补充常识
• 是否需要引用来源

示例提示词

你是一个公司制度问答助手。请严格根据知识库内容回答用户问题。

要求：
1. 如果知识库中有明确答案，请用简洁中文回答。
2. 如果知识库中没有相关内容，请回答：“当前资料中未找到相关规定，建议咨询 HR。”
3. 不要编造制度、日期、金额、流程。
4. 如果问题缺少必要信息，请先向用户追问。
5. 回答时尽量列出关键条件，例如适用对象、生效时间、申请流程。

这个提示词不长，但边界清晰，适合新手使用。

六、坑四：把 Dify 当成“万能搜索引擎”

Dify 的知识库问答本质上通常是 RAG，也就是“检索增强生成”。它不是传统数据库查询，也不是百分百确定性的搜索系统。

很多用户会问类似问题：

• “帮我找一下所有提到报销的条款”
• “统计一下文档里出现了多少次某个词”
• “把所有客户投诉按类型分类并计算比例”
• “找出合同中所有风险条款并排序”

这些问题有些可以做，但不一定适合直接用普通知识库问答完成。因为 RAG 更擅长回答“与某个问题相关的局部内容”，不擅长对整个文档集合做全量扫描和精确统计。

正确理解 RAG 的适用范围

适合 RAG 的问题：

• “请假需要提前几天申请？”
• “报销发票有什么要求？”
• “产品 A 支持哪些接口？”
• “员工转正流程是什么？”

不太适合普通 RAG 的问题：

• “统计所有文档中每个部门出现的次数”
• “找出所有合同的截止日期并生成表格”
• “检查 500 份合同是否都有违约条款”

如果你需要后者，建议结合：

• 工作流
• 代码节点
• 数据库
• 表格处理工具
• 专门的文档解析流程

七、坑五：工作流越搭越复杂，最后自己也看不懂

Dify 的工作流功能很强大，但也很容易被滥用。新手经常会搭出一个像“蜘蛛网”一样的流程：几十个节点、多个条件分支、变量到处传，最后出了问题不知道从哪里排查。

常见错误

• 没有先画流程图，直接在 Dify 里拖节点
• 节点命名随意，例如“LLM1”“LLM2”“节点3”
• 每个节点都塞很多任务
• 没有中间结果检查
• 条件分支过多
• 变量名称混乱
• 没有异常处理

推荐方法：先设计，再搭建

在搭建复杂工作流前，先用文字写清楚：

1. 用户输入是什么？
2. 系统需要补充哪些信息？
3. 每一步输出什么？
4. 下一个节点依赖什么变量？
5. 如果失败怎么办？
6. 最终输出格式是什么？

例如，一个“客户投诉分类工作流”可以拆成：

1. 接收用户输入的投诉文本
2. 判断投诉是否完整
3. 提取客户姓名、联系方式、产品名称、投诉原因
4. 对投诉类型分类
5. 判断紧急程度
6. 生成客服处理建议
7. 输出结构化结果

节点命名建议：

• 提取客户信息
• 判断投诉类型
• 评估紧急程度
• 生成处理建议
• 格式化最终结果

不要使用：

• 节点1
• 测试
• LLM
• aaa
• 临时

好的命名会极大降低后期维护成本。

八、坑六：没有控制模型成本

很多人刚开始使用 Dify 时，只关注效果，不关注成本。等到真正上线后，才发现模型调用费用比预期高很多。

成本通常来自：

• 输入 Token
• 输出 Token
• 知识库召回内容
• 多轮对话历史
• 工作流中多次调用模型
• 使用高价模型
• 用户频繁测试
• API 被异常调用

成本失控的典型场景

假设一个工作流中有 5 个 LLM 节点，每个节点都使用高性能模型，并且每次都带上长知识库上下文。用户问一次问题，实际可能调用 5 次模型。看起来只是“一次对话”，实际成本可能是普通聊天的数倍甚至十几倍。

控制成本的方法

1. 不要所有节点都用最贵模型

   • 简单分类任务可以用便宜模型
   • 复杂推理任务再用高性能模型

2. 限制输出长度

   • 不需要长篇大论时，设置最大输出 Token
   • 提示词中明确“回答不超过 300 字”

3. 减少无意义上下文

   • 不要把无关历史对话全部传入
   • 不要召回过多知识片段

4. 上线前压测

   • 模拟真实用户问题
   • 估算平均每次调用成本
   • 预估日调用量和月费用

5. 设置调用频率限制

   • 防止接口被恶意刷
   • 防止内部用户误操作

九、坑七：忽视模型选择

不同模型的能力差异很大。很多新手看到 Dify 支持很多模型，就随便选一个。结果有些模型适合中文，有些适合代码，有些适合长文本，有些适合函数调用，有些本地模型成本低但效果不稳定。

选择模型时要看什么

1. 中文能力 如果主要面向中文用户，优先选择中文表现好的模型。

2. 上下文长度 如果要处理长文档、长对话，需要关注上下文窗口。

3. 推理能力 复杂分析、规划、多步骤任务需要推理能力更强的模型。

4. 工具调用能力 Agent 或工作流中需要调用工具时，模型是否稳定输出结构化参数很重要。

5. 成本 高性能模型不一定适合所有节点。

6. 响应速度 客服、网页助手等场景对速度敏感。

推荐思路

• 初期测试：选一个稳定的大模型
• 知识库问答：选择中文和遵循指令能力较强的模型
• 简单分类：选择低成本模型
• 复杂推理：选择高性能模型
• 私有化场景：考虑本地模型，但要接受调优成本

不要只问“哪个模型最好”，而要问：

在我的场景里，哪个模型效果、速度和成本最平衡？

十、坑八：知识库不更新，答案却要求永远正确

企业知识会变化：制度会更新，产品会迭代，价格会调整，流程会修改。如果知识库长期不维护，AI 输出过期答案是必然的。

常见问题

• 上传文档后就不管了
• 新旧文档同时存在
• 文档标题没有版本号
• 不知道哪些内容已失效
• 用户反馈错误后没人处理

建议建立知识库维护机制

至少做到：

1. 文档命名规范

   • 员工手册_2025版
   • 报销制度_2025-03-01生效
   • 产品A使用说明_v2.3

2. 定期检查

   • 每月或每季度检查一次
   • 删除过期文档
   • 更新核心政策

3. 错误反馈机制

   • 用户可以反馈“答案不准确”
   • 管理员定期查看日志
   • 根据真实问题补充 FAQ

4. 高风险内容人工确认

   • 法务
   • 财务
   • 医疗
   • 投资
   • 人事处罚
   • 合同条款

AI 应用不是一次性项目，而是一个需要持续运营的产品。

十一、坑九：没有看日志，不知道问题出在哪里

Dify 提供了调试和日志能力，但很多新手并不重视。遇到回答错误，只会说“模型不行”。实际上，你需要通过日志判断问题出在哪个环节。

排查思路

当回答不准确时，按以下顺序检查：

1. 用户问题是否清晰

   • 问题太宽泛？
   • 缺少关键条件？

2. 知识库是否命中正确片段

   • 检索结果是否相关？
   • 是否漏掉关键文档？

3. 提示词是否约束明确

   • 是否允许模型自由发挥？
   • 是否要求基于知识库？

4. 模型是否遵循指令

   • 是否编造？
   • 是否忽略上下文？

5. 输出格式是否符合要求

   • 是否需要 JSON？
   • 是否需要表格？

如果知识库没有命中正确内容，就不要先怪模型；如果知识库命中了但模型仍然胡编，才需要优化提示词或更换模型。

十二、坑十：忽略安全和权限

如果只是个人学习，安全问题可能不明显。但一旦接入企业资料，就必须认真考虑。

需要关注的安全问题

• 是否上传了敏感客户信息
• 是否包含员工隐私
• 是否包含合同金额
• 是否包含账号密码
• 是否包含内部系统地址
• 是否允许外部用户访问
• API Key 是否泄露
• 不同部门是否应该访问不同知识库

基本建议

1. 不要上传不必要的敏感信息 能脱敏就脱敏。

2. 区分测试环境和生产环境 不要在测试阶段直接使用真实客户隐私数据。

3. 控制访问权限 不同应用对应不同用户群体，不要一个机器人回答所有内部资料。

4. 保护 API Key 不要把 Key 写进公开代码仓库，也不要发到群聊里。

5. 高敏场景加人工审核 比如合同、医疗、金融、法律建议，不能完全依赖 AI 自动输出。

十三、零基础上手 Dify 的推荐流程

如果你是第一次使用 Dify，可以按照下面这个流程来：

第一步：选择一个简单场景

推荐：

• 公司制度问答
• 产品说明书问答
• 常见问题客服助手
• 文案生成工具

不要一上来做复杂 Agent。

第二步：准备高质量资料

把文档整理成结构清晰的形式：

标题：报销制度

一、适用范围
本制度适用于全体正式员工。

二、报销时间
员工应在费用发生后 30 天内提交报销申请。

三、发票要求
发票抬头必须为公司全称，且金额与实际消费一致。

四、审批流程
员工提交申请后，由直属主管审批，再由财务复核。

第三步：创建知识库并测试检索

上传文档后，不要急着发布。先测试：

• “报销需要多久内提交？”
• “发票抬头有什么要求？”
• “谁审批报销？”
• “实习生能不能报销？”

看检索片段是否准确。

第四步：创建聊天助手

配置提示词，例如：

你是企业内部制度问答助手。
请根据知识库回答员工问题。
如果知识库没有答案，不要编造，请提示用户咨询相关部门。
回答应简洁、准确，必要时列出步骤。

第五步：用真实问题测试

不要只用标准问题测试，也要测试用户可能会问的口语化问题：

• “我这个月出差的钱啥时候能报？”
• “发票开错抬头还能报吗？”
• “我过了一个月才报销可以吗？”
• “找谁签字？”

第六步：优化文档和提示词

如果回答不准，先看检索结果：

• 没检索到：优化文档、切分、关键词
• 检索到了但答错：优化提示词或换模型
• 回答太啰嗦：限制输出格式
• 回答太死板：调整语气要求

第七步：小范围发布

先给 3～10 个真实用户试用，收集反馈，而不是直接全公司上线。

第八步：持续迭代

根据日志和反馈补充：

• 常见问题
• 新制度
• 用户口语表达
• 标准回答格式

十四、Dify 应用上线前检查清单

上线前可以对照这个清单：

场景与边界

• [ ] 应用目标是否明确？
• [ ] 用户群体是否明确？
• [ ] 哪些问题可以回答，哪些不能回答？
• [ ] 是否设置了无法回答时的兜底话术？

知识库

• [ ] 文档是否清洗过？
• [ ] 是否删除过期内容？
• [ ] 是否有清晰标题？
• [ ] 是否测试过检索结果？
• [ ] 是否有版本管理？

提示词

• [ ] 是否要求基于知识库回答？
• [ ] 是否禁止编造？
• [ ] 是否规定输出格式？
• [ ] 是否说明缺少信息时要追问？

模型与成本

• [ ] 是否选择合适模型？
• [ ] 是否限制最大输出长度？
• [ ] 是否估算调用成本？
• [ ] 是否避免无意义多节点调用？

安全

• [ ] 是否处理敏感数据？
• [ ] 是否控制访问权限？
• [ ] API Key 是否安全保存？
• [ ] 是否有人工审核机制？

运营

• [ ] 是否有人负责维护知识库？
• [ ] 是否查看日志？
• [ ] 是否收集用户反馈？
• [ ] 是否定期优化？

十五、几个实用小技巧

1. 用 FAQ 提升问答效果

对于客服、制度、产品说明类场景，FAQ 往往比长文档更有效。

示例：

问：员工报销需要在多久内提交？
答：员工应在费用发生后 30 天内提交报销申请，逾期可能需要额外说明原因。

问：发票抬头写错了怎么办？
答：原则上发票抬头必须为公司全称。如抬头错误，请联系开票方重新开具。

这种结构非常利于检索。

2. 重要内容重复表达一次

如果某些规则非常关键，可以在文档中用“摘要”或“关键规则”再次强调。

例如：

关键规则：
- 报销申请应在费用发生后 30 天内提交。
- 发票抬头必须为公司全称。
- 报销需经过直属主管和财务审批。

这样能提高命中概率。

3. 输出格式越明确，结果越稳定

如果你希望模型输出表格，就直接要求：

请用 Markdown 表格输出，包含：事项、要求、注意事项。

如果希望输出 JSON，就给出字段：

{
  "category": "问题类型",
  "priority": "优先级",
  "suggestion": "处理建议"
}

4. 不要让一个节点做太多事

一个 LLM 节点最好只完成一个明确任务：

• 分类
• 提取
• 总结
• 生成
• 判断

任务越单一，结果越稳定，也越容易调试。

5. 用真实用户语言测试

用户不会总是按照文档标题提问。比如文档里写“年假申请流程”，用户可能问：

• “我想休年假咋弄？”
• “请年假找谁批？”
• “年假能不能明天请？”
• “我还剩几天年假？”

测试时一定要覆盖这些口语化表达。

十六、总结：Dify 好用，但不能“无脑用”

Dify 的价值在于让普通人也能快速构建 AI 应用，但它并不是魔法工具。想让 Dify 真正发挥作用，需要理解几个关键原则：

1. 场景越清晰，成功率越高
2. 知识库质量决定问答上限
3. 检索结果比提示词更重要
4. 提示词要清晰，不要堆废话
5. 工作流要先设计，再搭建
6. 模型选择要看场景，不要盲目追求最强
7. 上线前必须考虑成本、安全和维护
8. AI 应用需要持续迭代，不是一劳永逸

如果你是零基础用户，建议从一个简单的知识库问答助手开始，先把“资料整理、知识库检索、提示词约束、测试反馈”这几个基本环节跑通。等你熟悉了 Dify 的工作方式，再逐步尝试工作流、Agent、API 集成和企业级部署。

真正好用的 AI 应用，不是靠一次配置完成的，而是在不断测试、观察、修正和优化中打磨出来的。Dify 降低了起点，但最终效果仍然取决于你对业务、数据和用户需求的理解。