Dify 入门实操：从零搭建一个能用的 AI 应用

如果只是听别人说“Dify 是一个低代码大模型应用平台”，大概率还是有点抽象。真正理解 Dify，最好的方式不是背概念，而是打开它，亲手创建一个应用，配置模型、写 Prompt、接知识库、调试效果，最后把它发布出去。

这篇文章就不写成说明书了。我会用更接近实操笔记的方式，讲清楚 Dify 是什么、能做什么，以及新手到底应该怎么一步一步用起来。

1. Dify 到底是什么

我第一次接触 Dify 时，对它的直观感受是：它像一个“AI 应用搭建台”。

如果不用 Dify，我们想做一个 AI 问答助手，通常要自己写不少代码：

• 调用大模型 API。
• 拼接 Prompt。
• 保存多轮对话历史。
• 接入知识库。
• 写接口给前端调用。
• 调试模型输出。
• 后面还要考虑发布、日志、变量、权限等问题。

Dify 把这些常见能力都做成了可视化配置。你可以像搭积木一样，把模型、Prompt、知识库、工具和流程拼在一起，快速做出一个能跑的 AI 应用。

所以我更愿意这样理解 Dify：

Dify 不是一个单纯的聊天机器人页面，而是一个帮你快速搭建、调试和发布 AI 应用的平台。

它适合两类人：

• 开发人员：用它快速验证 AI 应用原型，再通过 API 接入业务系统。
• 业务人员或产品人员：不用写太多代码，也能搭一个知识库问答、文案生成、流程助手。

2. Dify 里最常用的五类应用

进入 Dify 创建应用时，你会看到几种不同的应用类型。刚开始很容易纠结：我到底该选哪个？

其实可以先不用想太复杂。你只要看自己的需求属于下面哪一种。

你想做什么	推荐类型	举个例子
填一些信息，生成一段固定格式内容	文本生成应用	生成周报、邮件、宣传文案
像聊天一样持续问答	聊天助手	企业制度问答、产品客服
让 AI 自己判断要不要调用工具	Agent	查询数据库、查天气、调用业务接口
按固定步骤自动处理任务	Workflow	文档摘要、批量翻译、自动生成报告
一边聊天，一边按流程引导用户	Chatflow	智能导购、问诊引导、业务办理助手

下面我用几个实操例子把它们串起来。

3. 实操一：做一个“周报生成器”

这是最适合新手上手的例子。它不需要知识库，也不需要工具调用，只需要用户输入一些工作内容，然后让模型生成一篇结构清晰的周报。

第一步：创建应用

进入 Dify 后，点击创建应用，选择“文本生成应用”。

应用名称可以写：

周报生成器

这个应用的特点是：用户提交一次内容，系统生成一次结果。它不像聊天助手那样强调多轮对话，所以用文本生成应用就够了。

第二步：设计输入字段

接下来可以添加几个输入变量，让用户填写：

字段名	字段说明	示例
work_content	本周完成的工作	完成接口联调、修复登录问题
problem	遇到的问题	测试环境不稳定，联调多次中断
next_plan	下周计划	完成上线前回归测试

这样做的好处是，用户不用自己组织语言，只要把关键信息填进去，Dify 负责把这些变量交给模型。

第三步：编写 Prompt

可以写一个比较直接的 Prompt：

你是一个有经验的职场办公助手，请根据用户输入的信息，生成一份简洁、正式、条理清晰的工作周报。

本周完成的工作：
{{work_content}}

遇到的问题：
{{problem}}

下周计划：
{{next_plan}}

请按下面格式输出：

## 本周工作完成情况

## 遇到的问题

## 下周工作计划

## 总结

这里最关键的是变量。{{work_content}}、{{problem}}、{{next_plan}} 会在运行时被用户填写的内容替换掉。

第四步：调试效果

在调试窗口里输入：

本周完成的工作：完成用户登录接口联调，修复验证码过期问题，整理接口文档。
遇到的问题：测试环境偶尔无法访问，导致联调进度受影响。
下周计划：继续完成权限模块联调，并准备上线前测试。

如果生成的周报太啰嗦，就在 Prompt 里补一句：

每个小节控制在 3 条以内，不要写空话。

如果语气太随意，就补一句：

语言风格要正式，适合提交给部门负责人查看。

这就是 Dify 调试 Prompt 的基本方式：先跑起来，再根据输出慢慢调。

第五步：发布应用

效果满意后，点击发布。Dify 通常会提供两种使用方式：

• 直接通过 Web 页面访问。
• 通过 API 集成到其他系统。

如果只是团队内部使用，Web 页面就够了。如果要嵌入公司 OA、门户或自己的后台系统，就可以使用 API。

4. 实操二：做一个“培训资料问答助手”

第二个例子更贴近企业场景。假设我们有一批培训文档，希望员工可以直接提问，比如：

MCP 是什么？
Dify 的五类应用有什么区别？
FastAPI 适合用来做什么？

这种场景就适合使用“聊天助手 + 知识库”。

第一步：创建聊天助手

创建应用时选择“聊天助手”，应用名称可以写：

培训资料问答助手

聊天助手适合多轮问答。比如用户先问“Dify 有哪些应用类型”，接着又问“哪种适合做客服”，模型需要理解上下文，这就比文本生成应用更合适。

第二步：创建知识库

进入知识库模块，上传培训资料。比如：

01_Transformer架构.md
05_Prompt提示词.md
07_MCP入门.md
13_Dify五类应用.md

上传后，Dify 会对文档进行解析、切分和索引。后面用户提问时，它会先从知识库里找相关片段，再把这些内容交给模型生成回答。

这里有个实用经验：文档标题和层级越清晰，知识库效果通常越好。比如 Markdown 文档里有明确的 #、##、表格和列表，检索效果会比一大坨没有结构的文本好很多。

第三步：把知识库接到应用里

回到“培训资料问答助手”的配置页面，找到上下文或知识库相关配置，把刚才创建的知识库添加进来。

这个动作可以理解为告诉 Dify：

用户问问题时，先去这些资料里找答案，再让模型组织语言。

第四步：写系统提示词

知识库问答最怕模型“瞎编”。所以 Prompt 里一定要写清楚回答边界。

可以这样写：

你是一个企业内部培训资料问答助手。

请优先根据知识库检索到的内容回答用户问题。

回答要求：
1. 如果资料中有明确答案，请用简洁自然的语言回答。
2. 如果资料中没有相关内容，请直接说明“当前资料中没有找到明确说明”。
3. 不要编造资料中不存在的结论。
4. 如果问题涉及多个概念，请分点说明。

这段 Prompt 不复杂，但非常重要。它相当于给模型划了边界。

第五步：测试几个真实问题

不要只测一个问题。建议至少准备三类问题：

第一类是资料里明确有答案的问题：

Dify 的五类应用分别是什么？

第二类是需要对比的问题：

Workflow 和 Chatflow 有什么区别？

第三类是资料里可能没有答案的问题：

Dify 最新版本的价格是多少？

第三类问题尤其重要。一个好的知识库助手，不只是会回答知道的问题，还要在不知道时不乱说。

第六步：优化回答风格

如果回答太像教科书，可以在 Prompt 里加：

回答要像同事之间解释问题一样自然，不要使用过于生硬的定义式表达。

如果回答太散，可以加：

回答时先给结论，再用 3 到 5 个要点解释。

如果回答太长，可以加：

默认回答控制在 300 字以内，除非用户要求详细说明。

Dify 的好处就在这里：你可以边测试边改 Prompt，不需要每次都改代码重新部署。

5. 实操三：做一个“数据库查询助手”

前两个例子主要是生成和问答。再进一步，我们可以让 Dify 调用外部工具，比如查询数据库。

这个场景适合用 Agent。

假设用户想这样问：

数据库中有多少名学生？
张三的数学成绩是多少？
哪个班级平均分最高？

模型自己并不知道数据库里的数据，所以它需要调用一个查询工具。

第一步：准备外部工具

在真实项目里，这个工具可以是一个 HTTP API，也可以是 MCP Server 暴露的工具。

比如我们有一个工具叫：

query

它接收一个参数：

query: 用户的自然语言查询需求

返回数据库查询结果。

工具的效果可以理解成：

输入：数据库中有多少名学生？
输出：{"count": 42}

第二步：创建 Agent 应用

在 Dify 中创建应用，选择 Agent。

Agent 和普通聊天助手的区别是：Agent 可以根据任务自己决定是否调用工具。用户问普通知识问题时，它可以直接回答；用户问数据库问题时，它会调用查询工具。

第三步：添加工具

在 Agent 的工具配置里，添加外部工具或 MCP 工具。

如果是 MCP 工具，大致流程是：

1. 配置 MCP 服务地址。
2. 让 Dify 发现这个服务暴露了哪些工具。
3. 选择 query 工具。
4. 确认工具参数说明是否清楚。

工具描述一定要写得让模型看得懂。比如：

当用户想查询学生、课程、成绩、班级等数据库信息时，调用该工具。
参数 query 填写用户的原始查询问题。

这个描述不是写给人看的，也是写给模型看的。模型会根据它判断什么时候该调用工具。

第四步：写 Agent 提示词

可以这样写：

你是一个学校数据查询助手。

当用户询问学生、课程、成绩、班级相关数据时，请调用数据库查询工具获取结果。

回答要求：
1. 不要凭空猜测数据库内容。
2. 如果工具返回为空，请说明没有查询到相关数据。
3. 如果工具返回的是结构化数据，请用自然语言解释给用户。
4. 回答要简洁，不要暴露内部 SQL 或工具调用细节。

第五步：调试工具调用

可以先问：

数据库中有多少名学生？

观察 Dify 的调试日志，看 Agent 是否调用了 query 工具。

如果没有调用，通常是工具描述不够明确，或者 Prompt 没有告诉模型“数据库问题必须调用工具”。

可以继续测试：

张三的数学成绩是多少？

理想流程应该是：

用户提问
  ↓
Agent 判断需要查询数据库
  ↓
调用 query 工具
  ↓
拿到查询结果
  ↓
组织成自然语言回答

第六步：注意安全边界

数据库查询助手看起来很酷，但也要小心。建议一开始只做查询，不要直接开放修改、删除、插入数据的能力。

更稳妥的做法是：

• 查询工具只允许 SELECT。
• 删除、修改、写入操作拆成单独工具。
• 高风险操作增加人工确认。
• 记录用户问题、生成 SQL 和执行结果，方便排查。

Agent 很灵活，但灵活不等于什么都交给它。业务边界还是要由系统设计来保证。

6. 实操四：用 Workflow 做一个“文档摘要流程”

如果一个任务步骤非常固定，我通常不建议一上来就用 Agent。因为 Agent 的特点是自主决策，而固定流程更需要稳定。

比如我们要做一个文档摘要工具，流程就是：

用户输入文档
  ↓
提取重点
  ↓
生成摘要
  ↓
输出待办事项

这种场景就适合 Workflow。

第一步：创建 Workflow 应用

创建应用时选择 Workflow。

它不会像聊天助手那样一直对话，而是更像一个自动化流程。用户输入一次，流程按节点一步步执行，最后输出结果。

第二步：配置开始节点

在开始节点中添加输入变量：

变量名	类型	说明
document	文本	用户粘贴的文档内容

第三步：添加 LLM 节点提取重点

第一个 LLM 节点可以叫：

提取关键信息

Prompt 可以写：

请阅读下面的文档，提取其中最重要的信息。

文档内容：
{{document}}

请输出：
1. 核心主题
2. 关键事实
3. 涉及的时间、人员、任务

第四步：添加第二个 LLM 节点生成摘要

第二个 LLM 节点可以接收上一步的输出，然后生成更适合阅读的摘要：

请根据以下关键信息，生成一段 300 字以内的摘要。

关键信息：
{{上一步节点输出}}

要求：
1. 语言自然。
2. 先说结论，再说细节。
3. 不要加入原文没有的信息。

实际在 Dify 里，变量需要从节点输出中选择。你不用手写很复杂的变量路径，通常在编辑器里点选即可。

第五步：添加待办事项提取节点

再加一个 LLM 节点：

请从下面内容中提取待办事项。

内容：
{{document}}

如果没有明确待办事项，请输出“无明确待办事项”。

输出格式：
- 待办事项
- 负责人
- 截止时间

第六步：配置结束节点

结束节点可以输出两个结果：

• 摘要。
• 待办事项。

这样用户拿到的结果就不是一段混杂文本，而是结构清楚的处理结果。

7. Workflow 和 Agent 到底怎么选

很多人会卡在这里：一个任务既能用 Agent，又能用 Workflow，那到底怎么选？

我的经验是：

如果步骤是固定的，用 Workflow。

比如：

上传文档 → 摘要 → 提取关键词 → 输出结果

这个流程每次都一样，Workflow 更稳。

如果步骤是不固定的，用 Agent。

比如：

用户可能问成绩，也可能问课程，也可能问班级统计

这时需要模型自己判断下一步做什么，Agent 更合适。

如果既要聊天，又要流程控制，用 Chatflow。

比如智能导购：

先问预算
再问用途
再问品牌偏好
最后推荐商品

用户体验是聊天，但背后流程必须可控，这种就适合 Chatflow。

8. 一个完整的 Dify 使用流程

不管做哪类应用，我建议都按下面这个顺序来。

第一步：写清楚需求

先用几句话写明白：

这个应用给谁用？
用户会输入什么？
系统要输出什么？
有没有不能做的事情？

如果这一步没想清楚，后面很容易越配越乱。

第二步：选择应用类型

按这个规则选：

• 单次生成：文本生成应用。
• 多轮问答：聊天助手。
• 自主调用工具：Agent。
• 固定自动化流程：Workflow。
• 对话式流程引导：Chatflow。

第三步：配置模型

根据任务选择模型和参数。

一般可以这样理解：

• 要稳定、准确：温度低一点。
• 要创意、多样：温度高一点。
• 要输出长文：最大输出长度设大一点。
• 要客服问答：回答风格要通过 Prompt 限制好。

第四步：写第一版 Prompt

第一版 Prompt 不用追求完美，但要包含四件事：

角色：你是谁？
任务：你要做什么？
输入：你会拿到哪些信息？
要求：输出格式和限制是什么？

比如：

你是一个企业内部知识助手。
请根据用户问题和知识库内容回答。
如果知识库中没有答案，请说明没有找到明确依据。
回答要简洁，必要时分点说明。

第五步：接入知识库或工具

如果只是普通生成，可以跳过这一步。

如果要基于资料回答，就接知识库。

如果要查数据库、查接口、调业务系统，就接工具。

这里要记住一句话：

知识库负责“知道资料里的内容”，工具负责“去外部系统做事”。

第六步：用真实问题测试

测试时不要只问标准问题，要问真实用户会问的问题。

比如知识库助手要测：

这个制度适用于谁？
如果我忘记提交怎么办？
你刚才说的第二点能展开讲讲吗？
资料里有没有提到审批时间？

Agent 要测：

查一下张三的成绩。
哪个班平均分最高？
把刚才的结果再按分数排序。

测试越接近真实场景，应用越容易落地。

第七步：看日志，改 Prompt，改配置

Dify 的调试日志很有用。你可以看：

• 模型拿到了哪些上下文。
• 知识库召回了哪些片段。
• 工具有没有被调用。
• 每个节点输入输出是什么。
• 哪一步开始跑偏。

不要只盯着最终答案。很多问题从日志里一眼就能看出来，比如知识库没召回、变量没传对、工具描述太模糊。

第八步：发布

调试差不多后，就可以发布。

发布后常见用法有两种：

• 直接把 Dify 应用页面给用户使用。
• 通过 API 接入自己的系统。

如果只是内部试用，先用页面就很好。等流程稳定了，再考虑 API 集成。

9. 新手最容易踩的几个坑

9.1 一开始就想做万能助手

很多人第一次用 Dify，会想做一个什么都能干的 AI 助手。结果 Prompt 很长，工具很多，知识库也很杂，最后效果反而不稳定。

更好的方式是先做小：

先做“培训资料问答”
再做“培训资料问答 + 生成学习总结”
再做“问答 + 工具调用 + 流程处理”

9.2 Prompt 写得像口号

比如只写：

你是一个智能助手，请认真回答用户问题。

这种 Prompt 太空了。模型不知道要依据什么回答，也不知道输出什么格式。

更好的写法是：

你是公司内部制度问答助手。
请优先依据知识库内容回答。
如果没有依据，请明确说明无法确认。
回答控制在 300 字以内，必要时分点说明。

9.3 知识库文档质量太差

知识库不是魔法。如果原始文档混乱、标题不清楚、内容过期，模型回答也很难稳定。

上传知识库前，最好先整理文档：

• 标题清楚。
• 段落不要太长。
• 表格和列表尽量规范。
• 删除重复和过期内容。

9.4 工具描述太模糊

Agent 调工具时，非常依赖工具描述。

不好的描述：

查询数据。

好的描述：

当用户询问学生、课程、成绩、班级统计等学校数据库信息时，调用该工具。参数 query 填写用户原始问题。

描述越清楚，模型越容易在正确时机调用工具。

10. 总结

Dify 的核心价值，不是让我们少写几行调用大模型的代码，而是让 AI 应用开发变得更可配置、更可调试、更容易交付。

如果你刚开始学 Dify，我建议按这个顺序练：

1. 先做一个文本生成应用，比如周报生成器。
2. 再做一个聊天助手，比如培训资料问答。
3. 然后接知识库，让回答基于自己的资料。
4. 再尝试 Agent，让它调用一个外部工具。
5. 最后学习 Workflow 和 Chatflow，把复杂流程可视化编排出来。

这样学下来，Dify 就不再是一个抽象的平台名，而是一套很具体的工作方法：

明确需求 → 选择应用类型 → 配置模型 → 编写 Prompt → 接知识库或工具 → 调试 → 发布

真正做 AI 应用时，最重要的也不是把所有功能都用上，而是选对应用类型，把输入、输出、流程和边界设计清楚。Dify 给我们的，就是一个把这些想法快速变成可运行应用的地方。