当前位置：首页 > news >正文

Dify实战指南：从零构建企业级AI应用，打通RAG与工作流

news 2026/7/1 3:28:56

如果你正在寻找一个能让你快速上手 AI 应用开发的平台，却苦于教程要么太浅、要么太散，那么这篇文章就是为你准备的。Dify 的出现，本质上解决了一个核心矛盾：AI 能力很强，但将其转化为稳定、可用的业务应用，中间隔着巨大的工程鸿沟。传统方式下，你需要处理模型 API 调用、Prompt 工程、上下文管理、知识库构建、工作流编排等一系列复杂问题，这足以让大部分非专业开发者望而却步。

Dify 的定位，正是填平这道鸿沟。它不是一个简单的 Prompt 调试工具，而是一个开源的、可视化的 AI 应用开发平台。你可以把它理解为一个“AI 应用的低代码/无代码 IDE”。它的价值不在于让你学会多少底层算法，而在于让你能像搭积木一样，将大语言模型、知识库、工具、逻辑判断等组件组合起来，快速构建出具备实用价值的 AI 应用。

然而，很多初学者在接触 Dify 时容易陷入两个误区：一是把它当作一个玩具，只停留在聊天界面的简单配置；二是被其“可视化”的表象迷惑，忽略了背后需要理解的 Agent、工作流、RAG 等核心概念，导致构建的应用不稳定、效果差。本文将带你穿透表象，从零开始，不仅教你如何部署和操作 Dify，更会深入其核心设计理念，并通过一系列贴近企业实战场景的案例，让你真正掌握用 Dify 搭建高可用 AI 应用的系统方法。读完本文，你将能独立规划并实现一个包含复杂逻辑和数据处理能力的 AI 应用原型。

1. Dify 的核心价值：它到底解决了什么痛点？

在深入技术细节之前，我们必须先搞清楚 Dify 为何而生。这决定了你学习它的投入产出比。如果你只是需要一个和 ChatGPT 类似的聊天界面，那么 Dify 对你可能过于“重型”。它的真正用武之地，在于以下三类场景：

痛点一：从“模型调用”到“应用交付”的工程化缺失直接调用 OpenAI 或国内大模型的 API 写几行代码很简单，但要把这个调用嵌入到一个完整的 Web 应用里，你需要考虑：用户会话如何管理？对话历史如何保存和载入？如何防止 Prompt 被注入攻击？如何对输出内容进行过滤或格式化？如何做 AB 测试？Dify 内置了这些生产级应用所需的“脚手架”，让你只需关注业务逻辑本身。

痛点二：复杂 AI 逻辑的可视化编排困难很多 AI 应用不是一问一答，而是包含多步骤决策。例如：“分析用户上传的财报 PDF，提取关键数据，与数据库中的历史数据对比，生成分析报告，并给出投资建议。” 用代码实现这个流程，需要串联多个模型调用、数据处理模块和条件判断，调试极其繁琐。Dify 的工作流功能，允许你通过拖拽节点的方式，直观地设计整个执行流程，大大降低了复杂 AI 智能体的开发门槛。

痛点三：私有知识库与模型结合的高成本RAG（检索增强生成）是让大模型“懂你”的关键技术。但自建 RAG 系统涉及文本切分、向量化、向量数据库检索、结果重排等多个环节，每一个环节都有技术选型和调优成本。Dify 提供了开箱即用的知识库功能，集成了主流的嵌入模型和向量数据库，你只需要上传文档，它就能自动完成后续所有流程，让你能快速构建基于私有知识的问答机器人。

因此，Dify 的目标用户非常明确：希望将 AI 能力快速集成到业务中的开发者、产品经理、业务分析师，以及中小型技术团队。它降低了 AI 应用的原型验证和初期开发成本。

2. 核心概念解析：Agent、工作流与知识库

要玩转 Dify，必须理解它的三个核心抽象，这比记住按钮位置更重要。

2.1 应用（Application）这是 Dify 中的顶级单元，代表一个完整的、可对外提供服务的 AI 应用。每个应用都有独立的配置、对话界面和访问 API。它可以是简单的对话机器人，也可以是复杂的工作流。

2.2 编排方式：对话型 vs 工作流型这是 Dify 应用的两大类型，决定了应用的构建范式。

对话型应用：类似于 ChatGPT，以多轮对话为核心。其核心是Prompt 编排。你通过设计系统 Prompt、用户输入模板，并可以插入“上下文”、“变量”等来构建一个智能对话助手。它适合客服、顾问、聊天伴侣等场景。
工作流型应用：以自动化流程为核心。它由多个节点（Node）通过线（Edge）连接而成，形成一个有向图。每个节点代表一个操作，如“读取变量”、“调用模型”、“条件判断”、“调用代码工具”、“查询知识库”等。它适合数据分析、内容生成流水线、自动化决策等场景。

2.3 关键组件

模型供应商：Dify 本身不提供模型，而是连接器。你需要配置如 OpenAI、Azure OpenAI、通义千问、DeepSeek 等模型的 API 密钥和端点。
提示词：与模型沟通的指令。Dify 提供了强大的提示词编辑器，支持变量插入（{{variable}}）、上下文引用，并可以进行可视化调试。
知识库：Dify 的 RAG 实现。你创建知识库，上传文档（支持 txt、pdf、word、excel、ppt 等），Dify 会将其切片、向量化并存储。在应用中可以将其作为“上下文”或“工具”来调用，使模型能基于你提供的资料回答问题。
工具：扩展模型能力的函数。Dify 内置了如“联网搜索”、“文本提取”等工具，更重要的是支持自定义工具。你可以通过 Python 代码或 API 请求的方式，让模型获得获取天气、查询数据库、调用内部系统等能力。
Agent：在 Dify 中，Agent 不是一个独立的类型，而是一种能力。无论是对话型还是工作流型应用，当你为模型配置了“工具”能力，并设置了工具调用策略（如让模型自主决定是否及何时调用工具），这个应用就具备了 Agent（智能体）的特性，可以主动使用工具完成任务。

理解这些概念后，你就会明白，在 Dify 中构建应用，就是在组合这些“乐高积木”。

3. 环境准备与部署：选择适合你的方式

Dify 支持多种部署方式，对于学习和开发，我们强烈推荐Docker Compose 部署，这是最简洁、跨平台且易于管理的方式。

3.1 基础环境要求

操作系统：Linux (推荐 Ubuntu 20.04+)、macOS 或 Windows (需安装 WSL2)。
Docker：版本 20.10.0 或更高。
Docker Compose：版本 v2.0.0 或更高。
硬件：最低 4GB RAM，推荐 8GB 或以上。CPU 核心数影响知识库处理速度。如需本地运行嵌入模型，需要更多资源。
网络：能够访问 Docker Hub 和所选用模型供应商的 API（如 OpenAI、国内大模型）。

3.2 使用 Docker Compose 快速部署这是官方推荐的一键部署方案，包含了 Dify 后端、前端、数据库等所有组件。

获取部署脚本：打开终端，执行以下命令下载最新部署文件。

cd /opt # 或你希望安装的目录 sudo curl -o /opt/dify-docker-compose.yaml https://raw.githubusercontent.com/langgenius/dify/main/docker/docker-compose.yaml sudo curl -o /opt/.env https://raw.githubusercontent.com/langgenius/dify/main/docker/.env.example

配置环境变量：编辑.env文件，最关键的是配置数据库密码和外部访问地址。

sudo vim /opt/.env

找到并修改以下关键配置（其他可暂时保持默认）：

# 设置一个强密码 POSTGRES_PASSWORD=dify_strong_password_123 # 将 localhost 改为你的服务器 IP，或如果你只在本地访问，可保持 localhost APP_WEB_URL=http://localhost:3000

启动 Dify：在包含dify-docker-compose.yaml和.env的目录下运行：
```
sudo docker compose -f dify-docker-compose.yaml up -d
```
这个命令会拉取镜像并启动所有服务。
验证部署：等待几分钟后，在浏览器访问http://你的服务器IP:3000。如果看到 Dify 的初始化设置页面，说明部署成功。你也可以通过命令查看容器状态：
```
sudo docker compose -f dify-docker-compose.yaml ps
```
所有服务状态应为Up (healthy)。

3.3 初始化设置首次访问 Web 界面，你需要：

创建管理员账号（邮箱和密码）。
填写团队名称。
最关键的一步：配置模型。在“模型供应商”设置中，添加你计划使用的模型。例如，添加 OpenAI，并填入你的 API Key 和 Base URL（如果你使用第三方代理）。你也可以配置多个模型供应商，方便后续切换。

至此，你的 Dify 开发环境已经就绪。

4. 第一个应用：构建一个“会议纪要生成助手”

我们从最简单的“对话型应用”开始，目标是创建一个能根据对话录音文本，自动生成结构化会议纪要的助手。

4.1 应用创建与基础配置

登录 Dify，点击“创建新应用”，选择“对话型应用”。
输入应用名称，如“会议纪要生成助手”。
进入应用编排界面。

4.2 提示词工程这是应用的大脑。在“提示词编排”区域，我们编写系统指令。

你是一个专业的会议秘书，擅长从杂乱的对话文本中提取关键信息，并生成结构清晰、语言精炼的会议纪要。 请根据用户提供的会议对话文本，生成一份包含以下部分的会议纪要： 1. 会议主题 2. 会议时间（如原文未提及，请标注“未提及”） 3. 参会人员 4. 讨论要点（分条列出，每条需包含议题和结论） 5. 待办事项（分条列出，明确负责人和截止时间） 6. 下次会议安排 要求： - 纪要语言正式、简洁。 - 所有信息必须严格基于用户提供的文本，不得编造。 - 如果某项信息在文本中无法推断，请明确标注“未明确”。 用户提供的对话文本如下： {{input}}

关键点：

{{input}}是一个变量。当用户使用时，他们输入的内容会自动替换到这里。
我们定义了清晰的输出结构，让模型“照章办事”。

4.3 添加上下文与变量为了让提示词更灵活，我们可以定义更清晰的变量。

在“上下文”区域，点击“添加变量”。
创建一个名为meeting_text的变量，标题为“会议对话文本”，描述为“请输入完整的会议对话录音转文字文本”。
回到提示词编辑框，将{{input}}改为{{meeting_text}}。这样，前端会生成一个名为“会议对话文本”的输入框，对用户更友好。

4.4 模型与参数调优在右侧配置区：

选择模型：根据你的配置，选择一个合适的模型，如 GPT-3.5-Turbo 或 GPT-4。
调节参数：
- 温度：设置为 0.3-0.5。生成会议纪要需要稳定性和准确性，不宜太高。
- 最大 Token：根据你的输入文本长度和预期输出长度调整，可先设为 2000。

4.5 预览与发布

点击右上角“预览”按钮，在右侧预览区，在“会议对话文本”框中粘贴一段模拟的会议对话，点击“发送”。检查生成的纪要是否符合格式要求。
调试满意后，点击“发布”。发布后，应用就拥有了一个独立的访问链接和 API 接口。

至此，一个基础的 AI 应用已经构建完成。用户可以通过 Web 界面或 API 来使用它。

5. 进阶实战：构建智能客服工单分类工作流

现在我们来挑战一个更复杂的“工作流型应用”。场景是：用户提交一段文字描述的问题，系统需要自动判断问题类型（如“账号问题”、“技术故障”、“账单咨询”、“产品建议”），并提取关键实体（如订单号、用户名、错误代码），最后生成一封标准格式的客服内部工单。

5.1 工作流设计思路这个流程无法通过单次对话完成，需要多个步骤：

文本理解与分类：调用大模型，分析用户输入，识别问题类别。
实体提取：从文本中提取关键信息。
工单生成：根据分类和实体，填充工单模板。
路径判断：如果是紧急故障，可能需要触发额外警报。

5.2 创建工作流

点击“创建新应用”，这次选择“工作流型应用”，命名为“智能客服工单分类”。
进入可视化工作流编辑器。

5.3 节点编排我们从左到右拖拽节点并连接。

节点1：开始（Start）
- 类型：开始。
- 配置：添加一个用户输入变量，命名为user_query，描述为“用户问题描述”。

节点2：问题分类（LLM）

类型：大语言模型。
连接：从开始节点的user_query变量连接到本节点的输入。

提示词配置：

你是一个客服问题分类专家。请将用户的问题严格分类到以下类别之一： 【账号问题】- 登录、注册、密码修改、账号冻结。 【技术故障】- 软件报错、功能无法使用、页面崩溃、性能问题。 【账单咨询】- 费用疑问、扣费异常、发票申请、套餐升级。 【产品建议】- 功能建议、用户体验反馈。 【其他】- 不属于以上任何一类。 只输出类别名称，不要输出任何其他解释。 用户问题：{{user_query}}

输出变量：将输出命名为issue_category。

节点3：实体提取（LLM）

类型：大语言模型。
连接：从开始节点的user_query变量连接到本节点输入。

提示词配置：

请从以下用户问题描述中，提取出关键实体信息。 请以纯JSON格式输出，包含以下字段（如果不存在则为空字符串）： - order_number: 订单号 - username: 用户名 - error_code: 错误代码 - contact_info: 联系方式（电话/邮箱） 用户问题：{{user_query}}

输出变量：将输出命名为entity_json。

节点4：工单生成（LLM）

类型：大语言模型。
连接：将issue_category和entity_json作为变量输入到此节点。

提示词配置：

你是一名客服工单系统。请根据以下信息生成一份标准的客服内部工单。 【问题分类】：{{issue_category}} 【提取的实体信息】：{{entity_json}} 【原始用户描述】：{{user_query}} 工单格式： ====== 客服工单 ====== 分类：[此处填写问题分类] 紧急程度：[自动判断，技术故障为“高”，其他为“中”] 提交时间：[系统当前时间] 用户描述摘要：[用一句话概括用户问题] 关键信息： - 订单号：[order_number] - 用户名：[username] - 错误代码：[error_code] - 联系方式：[contact_info] ====================== 请严格按照上述格式输出，不要添加任何额外内容。

输出变量：将输出命名为ticket_content。

节点5：条件判断（IF/ELSE）
- 类型：如果/否则。
- 连接：从问题分类节点连接到本节点的条件输入。
- 条件配置：设置条件为issue_category等于技术故障。
节点6：发送警报（HTTP请求/工具）
- 类型：HTTP 请求（这是一个自定义工具）。
- 连接：从条件判断节点的“是”分支连接到此节点。
- 配置：这里模拟一个内部告警 API。你需要配置一个请求（可在测试时使用httpbin.org/post这样的测试端点）。
  - URL:https://your-alert-system.com/api/alert
  - Method:POST
  - Headers:Content-Type: application/json
  - Body:{"category": "{{issue_category}}", "query": "{{user_query}}", "level": "HIGH"}
- 这个节点演示了如何将 AI 工作流与外部系统集成。
节点7：结束（End）
- 类型：结束。
- 连接：将工单生成节点的输出ticket_content连接到本节点，作为最终输出。同时，从条件判断的“否”分支也连接到本节点。

5.4 调试与运行

点击右上角“调试”按钮。
在调试面板输入user_query，例如：“我的订单#ORD-20240601-001 支付成功了，但页面一直显示待付款，错误代码好像是 5001，快帮我看看！”
点击“运行”，你可以看到工作流一步步执行，每个节点的输入输出都会显示。检查issue_category是否为“技术故障”，entity_json是否提取正确，ticket_content格式是否工整，以及是否触发了“发送警报”分支。
调试无误后，发布应用。

通过这个工作流，你将深刻理解 Dify 如何将复杂的 AI 逻辑可视化、模块化。你可以在此基础上继续扩展，比如加入“知识库查询”节点，让系统先检索已知解决方案库，再决定是否生成工单。

6. 核心功能深入：知识库与 RAG 实践

知识库是 Dify 的杀手锏功能，用于构建基于私有数据的问答系统。

6.1 创建与配置知识库

在左侧导航栏进入“知识库”，点击“创建”。
填写名称，如“公司产品手册”。
关键选择：索引方式。
- 高质量：分段更智能，检索精度高，适合正式文档。处理速度稍慢。
- 经济：分段较简单，处理速度快，适合对精度要求不高的海量文本。
- 初次使用建议选择“高质量”。
嵌入模型：选择用于将文本转换为向量的模型。如果你使用 OpenAI，可以选择text-embedding-3-small。如果希望在本地运行，可以选择开源的BAAI/bge-small-zh-v1.5等模型（需在设置中配置本地嵌入模型端点）。

6.2 文档处理与分段策略上传一份 PDF 产品手册。Dify 的处理流程是：

解析提取：将 PDF 中的文本和表格内容提取出来。
文本分段：这是影响 RAG 效果的核心。Dify 会根据你选择的“分段规则”将长文本切分成小块。
- 建议：在“知识库设置 -> 分段规则”中，可以自定义分段大小和重叠窗口。例如，设置分段最大 Token 为 500，重叠 Token 为 50。重叠可以避免一个关键信息被切分到两个段落的边界而丢失。
向量化：使用你选择的嵌入模型，为每个文本段生成一个向量（一组数字），并存入向量数据库（Dify 默认使用 PGVector）。
构建索引：完成向量存储，支持快速检索。

6.3 在应用中集成知识库有两种主要方式：

作为上下文（对话型应用）：在提示词编排的“上下文”区域，添加“知识库”上下文。当用户提问时，系统会自动从知识库中检索最相关的几个段落，插入到 Prompt 中，让模型基于这些内容回答。
作为工具（工作流型应用）：在工作流中添加“知识库检索”节点。你可以更精细地控制检索行为，比如设定检索条数、相关性分数阈值，并将检索结果作为变量传递给后续的 LLM 节点。

6.4 效果调优技巧

检索前：优化文档质量。上传前尽量清理格式混乱、无关的内容。好的原料是成功的一半。
检索中：调整“Top K”值（返回最相关的几条）和“相似度阈值”。如果答案总是遗漏细节，可以增大 Top K；如果答案包含无关信息，可以提高相似度阈值。
检索后：在 Prompt 中明确指令。例如：“请严格根据以下参考信息回答问题。如果参考信息中没有相关内容，请直接回答‘根据现有资料，我无法回答这个问题。’” 这可以大大减少模型“胡编乱造”的情况。

7. 高级特性：自定义工具与 API 集成

当内置功能无法满足需求时，自定义工具让你可以连接任何外部系统。

7.1 通过 Python 代码创建工具假设我们需要一个查询内部用户信息的工具。

进入“工具”页面，点击“创建自定义工具”。
选择“通过代码创建”。
填写工具基本信息（名称、描述）。

编写工具函数：

from typing import Dict, Any import requests def get_user_info(user_id: str) -> Dict[str, Any]: """ 根据用户ID查询用户基本信息。 Args: user_id (str): 用户的唯一标识符 Returns: Dict[str, Any]: 包含用户姓名、邮箱、注册时间的字典 """ # 这里替换为真实的内部API调用 # 示例：response = requests.get(f'https://internal-api.example.com/users/{user_id}', headers={'Authorization': 'Bearer xxx'}) # 为演示，我们返回模拟数据 mock_data = { "user_id": user_id, "name": "张三", "email": "zhangsan@example.com", "registration_date": "2023-01-15" } # 模拟API延迟 import time time.sleep(0.5) return mock_data

定义输入参数：在 UI 上添加一个名为user_id，类型为string的参数。
定义输出格式：描述工具返回的 JSON 结构。
保存后，这个工具就可以在应用编排中被模型调用了。当用户问“用户U12345的信息是什么？”时，模型可以自主决定调用这个工具来获取真实数据。

7.2 通过 API 创建工具如果你已有现成的 HTTP 服务，这种方式更简单。

选择“通过 API 创建”。
填写 API 的 URL、方法（GET/POST）、Headers（如认证信息）。
定义请求参数（Query、Body）与用户输入变量的映射关系。
定义如何解析 API 响应，提取出模型可读的内容。

7.3 工具调用策略在应用编排的“模型”配置区域，可以设置：

自动：模型自行决定是否及何时调用工具。这是 Agent 的典型模式。
手动：在调试或特定流程中，由开发者在工作流中明确指定调用某个工具。

8. 部署与运维：从开发到生产

8.1 应用发布与分享

Web 访问：发布后的应用有一个公开 URL，你可以将其嵌入到网站或分享给他人。
API 集成：每个应用都提供标准的 OpenAI 格式的 API 接口，方便集成到你的后端系统、移动应用或第三方工具中。你可以在“应用概览 -> API 访问”中找到 API Key 和端点。

8.2 监控与日志

对话日志：在“日志与标注”中，可以查看所有用户与应用的对话历史。这对于分析效果、发现 Bad Case 至关重要。
标注与改进：你可以对模型的回答进行“好评”或“差评”，并为差评提供“预期回答”。这些数据可以用于后续的提示词迭代优化，甚至用于微调模型。
性能监控：关注 Token 消耗、响应时间等指标，优化成本与体验。

8.3 数据安全与权限

团队协作：Dify 支持创建团队，并分配不同角色（所有者、管理员、编辑者、参与者），实现项目协同开发。
知识库隔离：确保知识库的访问权限与应用权限对齐，防止数据泄露。
API 密钥管理：妥善保管模型供应商的 API Key，并在 Dify 中配置时注意不要泄露。生产环境建议使用环境变量管理密钥。

8.4 备份与升级

数据备份：定期备份 Docker 卷中的数据，特别是 PostgreSQL 数据库卷，其中存储了所有应用配置、知识库向量和对话记录。
```
# 备份数据库（示例，需根据实际容器名调整） docker exec -t dify-db pg_dump -U postgres dify > dify_backup_$(date +%Y%m%d).sql
```

版本升级：关注 Dify 官方 Release。升级前务必阅读更新日志，并在测试环境验证。升级命令通常如下：

cd /opt # 拉取最新镜像 docker compose -f dify-docker-compose.yaml pull # 重启服务 docker compose -f dify-docker-compose.yaml up -d

9. 常见问题与排查指南

在学习和使用 Dify 过程中，你可能会遇到以下典型问题。

问题现象	可能原因	排查方式	解决方案
应用访问页面一直加载或白屏	1. 前端服务未启动成功 2. 网络问题 3. 浏览器缓存	1. 检查 Docker 容器状态`docker compose ps` 2. 查看前端容器日志`docker logs dify-web` 3. 打开浏览器开发者工具，查看 Console 和 Network 标签报错	1. 重启服务`docker compose restart` 2. 清除浏览器缓存或使用无痕模式 3. 确保`APP_WEB_URL`配置正确
模型调用失败，报“API Key 无效”或“网络错误”	1. API Key 填写错误或过期 2. 网络无法访问模型供应商 3. 额度不足	1. 在 Dify “设置-模型供应商”中检查 Key 和 Base URL 2. 在服务器上使用`curl`测试能否访问模型 API 端点 3. 登录模型供应商后台检查额度	1. 重新生成并填写正确的 API Key 2. 配置网络代理或使用国内可访问的模型 3. 充值或更换模型
知识库文档处理失败，一直显示“处理中”	1. 文档格式复杂或损坏 2. 嵌入模型服务异常 3. 向量数据库连接问题	1. 查看知识库处理日志（应用日志） 2. 尝试上传一个简单的 txt 文件测试 3. 检查嵌入模型配置和容器状态	1. 尝试将文档转换为纯文本或 PDF 再上传 2. 重启 Dify 服务 3. 检查`.env`中关于向量数据库的配置
工作流运行到某个节点卡住或报错	1. 节点配置错误（如变量名错误） 2. 外部 API 工具调用超时或失败 3. 条件判断逻辑有误	1. 使用工作流“调试”功能，逐步运行，查看每个节点的输入输出 2. 检查 HTTP 工具节点的 URL、参数是否正确 3. 检查 IF/ELSE 节点的条件表达式	1. 修正变量引用（注意大小写） 2. 在外部测试 API 接口是否正常 3. 简化复杂条件，分步测试
应用响应速度非常慢	1. 模型 API 本身响应慢 2. 知识库检索的 Top K 值设置过大 3. 服务器资源（CPU/内存）不足	1. 在模型供应商处检查状态 2. 检查知识库检索配置 3. 使用`docker stats`查看容器资源占用	1. 尝试更换响应更快的模型 2. 适当减小 Top K，或优化分段策略 3. 升级服务器配置，或限制并发请求

10. 最佳实践与项目规划建议

10.1 提示词设计原则

角色扮演：开头明确赋予模型一个角色（“你是一个资深架构师”）。
结构化输出：使用 Markdown、JSON、XML 等格式要求输出，便于后续程序解析。
少样本示例：在 Prompt 中提供一两个输入输出的例子（Few-Shot Learning），能极大提升模型在复杂任务上的表现。
明确边界：告诉模型“能做什么”和“不能做什么”，减少幻觉。

10.2 工作流设计原则

模块化：一个节点只做一件事。例如，将“分类”和“提取实体”分开，而不是用一个复杂的 Prompt 完成所有事。这样更易于调试和复用。
错误处理：关键节点后考虑添加“判断”或“重试”逻辑。例如，HTTP 请求失败后，是重试、跳过还是返回默认值。
变量命名清晰：使用user_query,final_answer,extracted_entities这类有意义的名称，而不是var1,var2。

10.3 项目启动 checklist在开始一个正式的 Dify 项目前，先明确以下几点：

目标：这个 AI 应用要解决的具体业务问题是什么？成功的衡量标准是什么？
数据：是否需要知识库？数据来源是否合规、质量如何？
流程：用户与应用的交互流程是怎样的？用流程图画出来。
模型选型：根据任务复杂度、响应速度、成本预算选择模型（如 GPT-4 效果更好但贵且慢，GPT-3.5-Turbo 性价比高）。
集成点：是否需要与外部系统（如 CRM、数据库）交互？如何保证安全？

Dify 的强大在于它将 AI 应用的构建从“黑盒艺术”部分转变为了“白盒工程”。它不能替代你对业务的理解和对 AI 原理的认知，但它能将这些认知快速、可视化地转化为可运行、可迭代、可交付的软件。从今天开始，选择一个你业务中小而具体的痛点，用 Dify 尝试构建第一个解决方案，你会发现自己与强大 AI 能力之间的距离，比想象中近得多。

查看全文

http://www.jsqmd.com/news/1099938/