1.1 Dify是什么：给搭建者的工作台定位

1.1 Dify 是什么：给搭建者的工作台定位

Dify 是一个开源的大模型应用开发平台：把提示词编排、知识库检索、工作流引擎、Agent 工具调用和应用服务化（WebApp、API、监控日志）装进同一套可视化工作台。它是 LangChain 这类编排库的"上楼"，也是裸调模型 API 的"减负"——定位一句话：你在工作台上搭应用，它在底层替你做工程。

本节是整条流水线的第一站：先看一段"不用平台"的裸代码，把痛点摸实，再对照 Dify 替你承担的职责，最后划清哪些事仍然要你自己干。它直接通向 1.2 节的形态选型——不知道平台边界，选型就是瞎选。

先看不用平台的日子

产品需求很简单：一个能查公司退换货政策的客服。你决定直接调某家模型的聊天补全接口，第一版代码大概长这样：

import requests

# 第一版：把系统提示词、用户问题、历史对话拼成一个请求
def ask(question, history):
    payload = {
        "model": "gpt-4o-mini",          # 模型名写死在代码里
        "messages": (
            [{"role": "system", "content": "你是电商客服，只回答退换货政策问题。"}]
            + history                      # 历史要自己拼、自己截断
            + [{"role": "user", "content": question}]
        ),
        "temperature": 0.3,
        "stream": True,                    # 流式要自己解析 SSE 分片
    }
    r = requests.post("https://api.example.com/v1/chat/completions",
                      json=payload, headers={"Authorization": "Bearer sk-xxx"},
                      stream=True)
    for line in r.iter_lines():            # 逐行剥掉 data: 前缀再拼 JSON
        if line.startswith(b"data: "):
            print(line[6:].decode())       # 省略：JSON 解析、错误重试、超时
​

三天后需求升级：要能查政策文档（检索增强）、要记住用户是会员还是普通用户（变量）、要对外提供网页和接口（服务化）、老板要看每天花了多少钱（观测）。上面这段代码会膨胀成一个完整的小型系统。这里每一行膨胀，对应 Dify 工作台上的一个现成模块：

平台替你做的四类工程

把表格收拢成四类职责，这是本节最想留下的骨架。

**其一，编排层。**提示词不再是代码里的字符串，而是面板上的模板；变量（{{query}}、自定义表单字段）有独立的定义区；模型换了，改一个下拉框，不用动"代码"。编排的产物在 Dify 里叫 DSL——一份描述应用结构的 YAML，可以导出、导入、进版本库。这一点常被低估：它意味着你在界面上"画"的东西是可资产化的配置，不是一次性点击记录。

# 一份聊天助手 DSL 的骨架（导出后的片段，可进 Git 管理）
app:
  mode: chat-app            # 应用形态：聊天助手
  name: 小艺-电商客服
model:
  provider: openai          # 供应商与模型，切换只改这两行
  name: gpt-4o-mini
  completion_params:
    temperature: 0.3
prompt_template:
  - role: system
    text: 你是电商客服小艺，只回答退换货政策问题。   # 提示词即配置
dataset_configs:
  retrieval_model: hybrid   # 知识检索策略也在配置里
​

**其二，知识检索层。**文档上传、分段、向量化、检索、把命中片段塞进上下文并标注引用，全链路开箱即用。第 4 章会专门拆开它，这里只需要记住：没有平台时，这部分通常是团队自研时间黑洞。

**其三，服务化层。**点一下"发布"，得到一个自带界面的 WebApp、一段可嵌入外部网站的代码、一组 REST API（每种应用形态都有对应端点）。会话管理、流式响应、应用级密钥都在里面。你在第 7 章会用它把小艺接进帮助中心。

**其四，观测层。**每次对话的完整记录（输入、输出、命中的知识片段、token 消耗、耗时、用户反馈）都自动落库。调提示词时可以逐条对比，出问题时可以回放现场。自研方案里这些都要自己埋点。

哪些事平台不替你干

把 Dify 当全能外包会摔跤。三件事仍然归你：内容质量（提示词写得好不好、文档干不干净，平台无能为力）；模型选型与预算（用什么模型、愿意花多少钱，是业务判断）；边界安全（应用权限、数据合规、密钥发放策略，第 7 章展开）。另外要清楚它的代价：高度封装意味着定制受限——想改检索算法的底层实现、想在会话中插自定义中间件，就会开始与平台的抽象搏斗。这时正确姿势不是魔改平台，而是先用 API 把能标准化的部分交付出去，再评估是否需要更底层的框架。

⚠️ 常见坑：把 Dify 当"提示词托管工具"用——建个应用、填个系统提示词、接上模型就完事。这样用它自然不如直接调 API 顺手，也体会不到平台价值。判断你是否用对了 Dify，看一件事：你的应用里有没有"随业务变化的结构"（知识要更新、流程要分支、工具要增减）。有，平台价值才成立。

💡 关键直觉：Dify 的本质是把"大模型应用的运维态"产品化了。写代码交付的是功能，Dify 交付的是一个可以长期被非程序员调参、看日志、换模型的运行时。

本节要点回顾

• 定位一句话：工作台上搭应用，底层有人做工程——四类职责是编排、检索、服务化、观测；
• DSL 是分水岭：界面操作最终沉淀为可版本化的 YAML 配置，这是"平台"区别于"玩具"的标志；
• 自研对照表：同一需求自研约四周以上的工程量，在 Dify 里对应五个现成模块；
• 平台不做的事：内容质量、模型与预算决策、安全合规，仍是你自己的活；
• 适用判据：应用里有随业务变化的结构，才值得上平台。

下一节面对五个应用形态按钮，你将用三个判断问题把"小艺"的形态定下来。