1. 背景

继续探索 Dify 的使用价值时，重点不只是“会启动、会点界面、会搭一个 demo”，而是逐步形成三层能力：

• 能判断 Dify 适合解决什么问题
• 能熟练使用 Dify 的核心能力完成真实业务场景
• 能基于 Dify 设计并落地可交付的 AI 产品应用

这份文档的作用，是把“学习 Dify”这件事从零散摸索，整理成 10 个更有顺序感、也更贴近产品落地的方向。

2. 先看 Dify 的核心使用价值

从产品角度看，Dify 的价值不只是“让你调模型”，而是把 AI 应用开发中最常见的几块能力整合到了一起：

• 快速搭建聊天型、工作流型、Agent 型应用
• 统一管理多模型与多供应商
• 提供知识库与 RAG 能力
• 用可视化方式编排复杂流程
• 让应用可被 API 化、嵌入到外部系统
• 提供日志、调试、观测和持续优化能力

真正值得掌握的，不是某个按钮，而是：

Dify 如何帮助你更快把 AI 能力变成产品能力。

3. 学习与构建的总原则

为了避免最后只留下碎片化功能印象，这里先记几条原则：

1. 每个方向都要有一个真实场景
2. 每个方向都要有一个最小可运行成果
3. 每个方向都要写一份自己的复盘笔记
4. 每学完 2 到 3 个方向，就做一个完整产品原型

最后真正要形成的，不是“知道 Dify 有什么功能”，而是：

我知道在什么业务里该用哪种 Dify 能力组合。

4. Dify、Coze、n8n 的区别

这三个产品经常被放在一起比较，但它们的核心定位并不相同。

4.1 先说结论

• 面向 AI 应用本身，尤其是带模型、知识库、Workflow、Agent 的产品时，Dify 更合适
• 面向 低门槛 Bot、Agent 试玩、渠道分发 时，Coze 更顺手
• 面向 系统集成、自动化编排、业务系统之间的数据流转 时，n8n 更强

简单说：

• Dify 更像 AI 应用平台
• Coze 更像 Bot / Agent 搭建平台
• n8n 更像自动化编排平台

4.2 Dify 的特点

Dify 的强项在于它把 AI 应用开发里最常见的几块能力放在了一套体系里：

• 模型管理
• Prompt 配置
• 知识库与 RAG
• Workflow
• Agent
• 日志与调试
• API 化输出

它更适合做下面这类事情：

• 企业知识助手
• AI 客服
• 面向内部团队的流程助手
• 带知识库和工作流的垂直应用
• 需要继续二次开发的产品

换句话说，Dify 更适合“把 AI 做成应用”。

4.3 Coze 的特点

Coze 的优势主要在于上手快、试错成本低、Bot 感更强。

它更适合：

• 快速搭一个对话 Bot
• 做轻量 Agent 试玩
• 快速验证一个内容型或互动型助手
• 更看重分发体验而不是底层掌控力的场景

但如果你要做企业内部系统、可控流程、复杂知识库或后续深度定制，Coze 往往会更早遇到边界。

换句话说，Coze 更适合“先把一个 Bot 跑起来”。

4.4 n8n 的特点

n8n 的核心强项并不在 AI 应用体验，而在系统连接和自动化。

它更适合：

• 打通第三方系统
• 做审批流、通知流、同步流
• 处理数据库、表单、消息、CRM、ERP 之间的数据流转
• 把 AI 当成流程中的一个步骤，而不是产品主体

如果一定要类比：

• Dify 的 Workflow 更偏 AI 任务流
• n8n 的 Workflow 更偏系统自动化流

所以很多场景里，Dify 和 n8n 不是替代关系，而是配合关系。

4.5 怎么选

从产品建设角度看，可以这样理解：

• AI 产品这条线，以 Dify 为主
• 系统自动化这条线，以 n8n 为主
• 轻量 Bot 试玩和渠道体验，可以参考 Coze

如果目标是做一个真正能交付的 AI 应用，Dify 通常比 Coze 更合适；如果目标是把 AI 嵌进现有业务系统的大流程里，n8n 往往要一起出现。

5. 10 个方向

5.1 方向一：掌握 Dify 的产品地图

学习重点

• Dify 的三类核心应用形态：聊天应用、工作流应用、Agent 应用
• 控制台的主要模块：Apps、Datasets、Tools、Plugins、Explore、Providers
• Web App、API、控制台三种使用视角

为什么重要

这一方向解决的是“认知地图”问题。如果连产品地图都不清楚，后面很容易把 Dify 误用成“带 UI 的模型调试器”。

实践任务

• 从零创建 3 个最小应用：Chat、Workflow、Agent
• 分别记录它们的配置入口、调试方式、发布方式
• 画一张自己的 Dify 功能地图

可产出的产品雏形

• 企业知识问答助手
• 流程化客服助手
• 工具调用型业务 Agent

5.2 方向二：掌握模型接入与模型选择

学习重点

• Provider、Model、Credential 的关系
• 聊天模型、Embedding 模型、Rerank 模型的分工
• 不同模型在速度、成本、稳定性、上下文长度上的差异

为什么重要

很多 AI 产品失败，不是流程不会搭，而是模型选型混乱，导致成本高、效果差、响应慢。

实践任务

• 至少接 2 类不同供应商模型
• 让同一个应用支持不同模型切换
• 记录不同模型在同一任务上的效果和成本差异

可产出的产品雏形

• 成本敏感型客服机器人
• 高质量内容生成助手
• 多模型 A/B 测试平台

5.3 方向三：掌握 Prompt 与应用配置

学习重点

• 系统提示词设计
• 对话开场白、建议问题、参数调节
• 变量输入与输出结构
• 输出格式约束

为什么重要

Prompt 仍然是 AI 产品体验的第一层。Dify 只是降低了集成成本，但不会替你自动完成产品表达。

实践任务

• 为 3 类任务分别写 prompt：问答、改写、结构化提取
• 让应用输出可控 JSON
• 设计一套自己的 prompt 迭代记录方法

可产出的产品雏形

• 文档摘要助手
• 合同要点提取器
• 市场调研结构化分析助手

5.4 方向四：掌握知识库与 RAG

学习重点

• 文档导入
• 切片策略
• 检索配置
• 召回与重排
• 命中测试与效果评估

为什么重要

如果你想做企业级应用，RAG 基本是绕不过去的。没有知识库能力，很多场景只能停留在“泛问答”。

实践任务

• 用一组真实文档做一个知识库
• 对比不同切片策略和召回效果
• 做一次命中测试和答案质量复盘

可产出的产品雏形

• 企业内部知识助手
• 产品文档问答系统
• 售后知识库检索助手

5.5 方向五：掌握 Workflow 编排

学习重点

• Start、LLM、If/Else、Knowledge Retrieval、Code、HTTP Request、Answer 等常见节点
• 分支、循环、变量传递、错误处理
• 把单轮问答升级为多步骤任务链

为什么重要

Workflow 是 Dify 最能体现平台价值的部分。它让 AI 应用从“一个模型回复”升级为“可编排的业务流程”。

实践任务

• 搭一个包含检索、判断、调用外部接口、输出结果的 workflow
• 至少使用一次条件分支
• 至少使用一次外部 HTTP 请求

可产出的产品雏形

• 工单分流助手
• 销售线索预处理助手
• 报告自动生成流程

5.6 方向六：掌握 Agent 与工具调用

学习重点

• Agent 模式和 Workflow 模式的差异
• 内置工具与外部工具的接入方式
• 什么时候适合让 Agent 自主选择工具，什么时候不适合

为什么重要

Agent 很容易看起来“很聪明”，但如果工具边界和任务边界不清晰，就会不稳定。熟练掌握这一方向，才能做出真正可用的业务 Agent。

实践任务

• 搭一个带 2 到 3 个工具的 Agent
• 比较同一场景下 Agent 与 Workflow 的差异
• 记录失败样例，分析是 prompt、工具还是任务定义的问题

可产出的产品雏形

• 智能运营助手
• 数据查询助手
• 多工具执行型办公 Agent

5.7 方向七：掌握外部系统集成

学习重点

• Web App 嵌入
• API 调用
• 对外暴露服务能力
• 与业务系统、表单系统、CRM、工单系统等结合

为什么重要

真正的产品价值不在 Dify 控制台里，而在它能否嵌入你的业务链路。

实践任务

• 用 API 调一个你在 Dify 中创建的应用
• 把 Web App 嵌入一个简单页面
• 设计一个“用户输入 -> Dify -> 外部系统”的小闭环

可产出的产品雏形

• 网站嵌入式客服机器人
• 内部业务表单智能助手
• 与企业系统打通的 AI 服务接口

5.8 方向八：掌握观测、调试与优化

学习重点

• 应用日志
• Workflow 调试
• 消息与会话回看
• 错误定位
• 输出质量与成本优化

为什么重要

不会调试，就无法把 demo 变成产品。AI 产品最大的难点之一就是“上线后如何持续优化”。

实践任务

• 追踪一个失败会话的完整链路
• 分析一次错误回答的成因
• 对一个已有应用做 3 次迭代优化并记录前后差异

可产出的产品雏形

• 可持续迭代的客服助手
• 可量化优化的知识问答应用
• 有观测能力的企业内部流程机器人

5.9 方向九：掌握多租户、权限与交付视角

学习重点

• 工作区与账号角色
• 应用发布边界
• 数据与权限隔离
• 面向团队交付而不是个人试验的配置方式

为什么重要

如果你想基于 Dify 做企业交付或内部平台化建设，这一方向决定你能否从“个人玩具”走向“团队可用”。

实践任务

• 以“团队协作”角度重新配置一个应用
• 列出应用、知识库、模型凭证的权限边界
• 设计一份交付清单：模型、知识库、流程、监控、权限

可产出的产品雏形

• 企业内部 AI 平台试点方案
• 部门级知识助手交付包
• 面向客户的私有化部署应用方案

5.10 方向十：从功能组合到产品设计

学习重点

• 场景识别
• 用户旅程
• 输入输出设计
• 成本与稳定性权衡
• MVP 设计

为什么重要

真正能让你“掌握 Dify”的，不是把 10 个功能都点过，而是你能基于 Dify 做出有明确用户价值的产品。

实践任务

• 选 3 个真实业务问题做产品草图
• 每个草图明确：目标用户、输入、输出、主流程、失败处理、衡量指标
• 选其中 1 个做 MVP

可产出的产品雏形

• AI 销售助手
• AI 法务助手
• AI 培训助手
• AI 数据分析助理

6. 推荐掌握顺序

如果把“熟练掌握 Dify，并能构建产品应用”作为主线，这个顺序更顺：

1. 方向一：产品地图
2. 方向二：模型接入
3. 方向三：Prompt 与应用配置
4. 方向四：知识库与 RAG
5. 方向五：Workflow 编排
6. 方向六：Agent 与工具调用
7. 方向七：外部系统集成
8. 方向八：观测、调试与优化
9. 方向九：权限与交付
10. 方向十：产品设计与 MVP

这个顺序背后的逻辑很简单：

• 先学“会搭”
• 再学“搭复杂”
• 再学“接系统”
• 最后学“做成产品”

7. 建议你做的 3 个阶段项目

第一阶段：单点能力项目

目标：快速熟悉 Dify 核心模块。

建议做：

• 一个聊天应用
• 一个知识库问答应用
• 一个带 HTTP 请求的 workflow

第二阶段：组合能力项目

目标：掌握能力组合。

建议做：

• 一个“知识检索 + 分支判断 + 工具调用”的工作流应用
• 一个“Agent + 工具”的业务助手

第三阶段：产品化项目

目标：从可运行走向可交付。

建议做：

• 一个面向真实部门或真实业务角色的 MVP
• 同时补齐：权限、日志、优化、成本控制、嵌入方式

8. 熟练掌握 Dify 的判断标准

如果你已经能做到下面这些事，基本可以认为你不只是“会用”，而是开始具备“构建 Dify 产品应用”的能力了：

• 能独立选择应用形态：Chat、Workflow、Agent
• 能独立接模型、调 Prompt、配知识库
• 能设计一个多步骤的 workflow
• 能判断什么时候该用 Agent，什么时候不该用
• 能把应用嵌入业务系统或通过 API 提供服务
• 能分析日志并持续优化效果
• 能围绕真实用户需求做出 MVP

9. 总结

探索 Dify 的使用价值，最重要的不是记住多少功能点，而是建立一个判断框架：

• 这个场景是问答型、流程型，还是 Agent 型
• 需要模型能力，还是需要知识库能力
• 需要单轮调用，还是需要可编排流程
• 需要控制台内使用，还是要嵌入外部系统
• 目标是做 demo，还是做产品

当你沿着这 10 个方向推进时，你最终收获的就不只是“会用 Dify”，而是：

能用 Dify 快速识别场景、搭出原型、验证价值，并逐步把 AI 能力做成产品能力。