不写一行代码也能搭 AI 应用？Dify 从安装到知识库 RAG 全打通

前面咱们用 LangGraph 手撸了一堆 Agent 代码，State、节点、边、Interrupt…… 爽是爽，但你有没有想过：如果产品经理想自己搭一个 AI 应用，总不能让她去写 Python 吧？

这就是 Dify 出场的原因。老哥给它一句最直白的定位：Dify 就是不写代码的 LangGraph。可视化界面，拖拽节点，把大模型、提示词、知识库、工作流、Agent 和外部工具拼成完整的 AI 应用。这篇咱们从安装一路打到知识库 RAG，所有配置直接复制就能用。

一、Dify 是个啥，和 Coze 怎么选

Dify 是开源的生成式 AI 应用构建平台，核心功能一览：

表格

Dify 和 Coze 怎么选？快速做个能发到微信 / 飞书的聊天机器人、不想管服务器 → Coze；要企业知识库、AI 能力嵌进自己系统、数据留内网 → Dify。 技术团队倾向 Dify（开源可控 + API 生态），业务团队倾向 Coze（零代码 + 多渠道分发）。

二、Docker 部署 Dify

Dify 不是单个容器，完整运行需要 Web、API、Worker、数据库、Redis、向量数据库等多个服务，靠 Docker Compose 统一管理。

准备条件：Win10/11、启用硬件虚拟化、装好 Docker Desktop（WSL2 后端）、Git。然后：

# 1. 克隆 Dify 仓库，进入 docker 目录
cd dify/docker

# 2. 复制环境配置
cp .env.example .env

# 3. 启动（-d 后台运行，第一次要拉镜像，慢一点正常）
docker compose up -d

# 4. 看容器状态
docker compose ps

# 5. 看日志（Ctrl+C 退出，不会停容器）
docker compose logs -f

# 6. 停服务 / 重启
docker compose down
docker compose restart

老哥踩坑提醒：

• 启动前关掉梯子，不然镜像拉取容易报错；
• 如果报 "连不上 Docker"，说明 Docker Desktop 没启动；
• 浏览器访问 http://localhost/install 创建管理员账号；
• 别乱删数据目录和数据卷，否则账号、应用、知识库全丢。

三、项目一：营销文案生成器

登录后进 Studio，创建一个 "工作流" 应用，叫营销文案生成器。用户输入产品信息，应用输出标题 + 正文 + 卖点 + 行动引导语。

3.1 输入变量（开始节点）

表格

3.2 System Prompt（粘贴到 LLM 节点）

你是一位资深营销文案策划，擅长根据产品信息和发布平台特点撰写高转化率文案。

## 任务
根据用户提供的产品信息，撰写一篇适配指定发布平台的营销文案。

## 产品信息
– 产品名称：{{product_name}}
– 产品特点：{{product_features}}
– 目标用户：{{target_audience}}
– 发布平台：{{platform}}
– 文案风格：{{tone}}

## 规则
1. 必须严格基于产品特点撰写，禁止虚构价格、认证、销量、用户评价等产品未提供的事实。
2. 文案风格必须匹配用户选择的"{{tone}}"，不得混入其他风格。
3. 必须适配"{{platform}}"平台的阅读习惯和排版特点：
– 小红书：标题带emoji、分段短、多用话题标签
– 公众号：标题有信息量、正文有小标题、结尾有行动引导
– 朋友圈：口语化、短段落、像朋友推荐
– 短视频：口播感、前3秒抓注意力、节奏快
– 电商详情页：卖点清晰、突出规格和使用场景
4. 面向"{{target_audience}}"说话，不要用他们不关心的术语。
5. 如果产品信息不完整，基于已有信息撰写，不要编造缺失内容。

## 输出格式
请按以下结构输出：

### 标题
（一个吸引点击的标题，符合平台风格）

### 正文
（200-400字的正文，分段清晰）

### 核心卖点
（3条以内，每条一句话）

### 行动引导语
（一句引导用户下单/咨询/点击的话）

注意：{{product_name}} 这些变量不要手打，要用 Dify 界面的变量选择器插入。插入前记得打开 Jinja 开关 —— 不然模型收到的就是字面量 {{product_name}}，一脸懵。

3.3 模型参数

表格

3.4 测试用例

表格

四、项目二：简历分析助手（结构化输出）

光输出一大段文字，程序没法接着处理。Dify 的 LLM 节点支持结构化输出，让模型按定义好的 JSON Schema 返回字段。

4.1 输入变量

表格

4.2 System Prompt

你是一位资深技术招聘官，负责分析简历与岗位的匹配程度。

## 简历内容
{{resume_text}}

## 目标岗位
{{target_position}}

## 岗位要求
{{job_requirements}}

## 分析规则
1. 匹配分数（match_score）为0-100的整数，综合以下维度加权：
– 核心技能匹配（35%）
– 工作经历相关度（25%）
– 项目经验匹配（20%）
– 行业经验（10%）
– 教育背景与证书（5%）
– 简历完整度（5%）

2. 严格区分三类信息：
– 明确事实：简历中直接写明的技能、经历、项目
– 合理判断：基于事实得出的匹配评价
– 未知信息：简历中没有提到的，不得猜测或补充

3. 简历未提及的能力（如英语等级、管理经验），标记为"未提供"，不要假设。

4. 优势和差距都必须基于简历原文和岗位要求，不要泛泛而谈。

5. 改进建议要具体、可执行，针对差距逐条给出。

4.3 结构化输出 JSON Schema

在 LLM 节点找到 "输出变量"→ 开启 "结构化输出"→ 点击 "配置"→ 从 JSON 导入：

{
"type": "object",
"properties": {
"match_score": {
"type": "number",
"description": "综合匹配分数，0-100的整数"
},
"skill_match": {
"type": "number",
"description": "核心技能匹配度，0-100"
},
"strengths": {
"type": "array",
"items": {"type": "string"},
"description": "候选人优势列表，每条基于简历事实"
},
"gaps": {
"type": "array",
"items": {"type": "string"},
"description": "与岗位要求的差距列表"
},
"missing_info": {
"type": "array",
"items": {"type": "string"},
"description": "简历中未提供但岗位可能关注的信息"
},
"suggestions": {
"type": "array",
"items": {"type": "string"},
"description": "针对差距的改进建议"
},
"summary": {
"type": "string",
"description": "一句话总体评价，不超过100字"
}
},
"required": ["match_score", "strengths", "gaps", "suggestions", "summary"]
}

字段设计原则： 需要计算 / 排序的用 Number（match_score: 85），别用带百分号的字符串；多条内容用 Array；重要字段设必填；结构尽量扁平。

4.4 模板转换节点（Jinja2）

结构化 JSON 适合程序处理，但人看着累。加一个模板转换节点，把 JSON 渲染成 Markdown 报告 —— 不调模型、不花 Token、输出稳定。

先把 LLM 节点的 structured_output 设为模板输入，命名为 analysis，然后填模板：

# 简历分析报告

## 综合匹配度：{{ analysis.match_score }} / 100

### ✅ 候选人优势
{% for s in analysis.strengths %}
– {{ s }}
{% endfor %}

### ⚠️ 存在差距
{% for g in analysis.gaps %}
– {{ g }}
{% endfor %}

### ❓ 待补充信息
{% if analysis.missing_info and analysis.missing_info | length > 0 %}
{% for m in analysis.missing_info %}
– {{ m }}
{% endfor %}
{% else %}
– 无
{% endif %}

### 💡 改进建议
{% for sug in analysis.suggestions %}
{{ loop.index }}. {{ sug }}
{% endfor %}

4.5 输出节点（双输出）

表格

这样设计的好处：人看报告，程序拿 JSON，一份数据两种用法。

4.6 测试输入

简历内容：王明，3年Java开发经验。熟悉SpringBoot、MySQL和Redis，参与过电商订单系统开发，负责接口设计和性能优化。
目标岗位：Java后端开发工程师
岗位要求：3年以上Java经验；熟悉Spring Boot、MySQL、Redis；具备分布式系统和性能优化经验。

测试时重点看： 必填字段全不全？match_score 是不是数值？技能是不是来自简历原文而不是模型编的？简历内容很少时模型会不会虚构经历？

五、项目三：员工制度问答助手（知识库 RAG）

直接问大模型 "忘记打卡多久能补卡"，它不知道你们公司制度，会瞎编。这就是知识库要解决的问题。

5.1 RAG 流程

用户提问 → 知识检索节点召回相关分段 → LLM 基于分段+问题生成答案

5.2 知识库配置

表格

索引方式怎么选？ 高质量索引调 Embedding 模型做向量检索，语义相似就能召回，要花 Embedding 的钱；经济索引提取关键词做倒排索引，不花钱但对同义词不敏感 —— 用户说 "补卡" 它可能找不到 "补登记"。生产环境用户经常用口语，优先高质量索引。

5.3 RAG Prompt

这个项目用 Chatflow（不是 Workflow），因为客服问答是多轮对话。LLM 节点的 Prompt：

你是公司内部的制度问答助手。请根据检索到的制度资料回答员工问题。

## 员工问题
{{sys.query}}

## 检索到的制度资料
{{#context#}}

## 规则
1. 答案必须严格基于上面的制度资料，不得使用资料以外的知识编造制度条款。
2. 如果资料中没有相关内容，直接回答："抱歉，未在制度库中找到相关规定，建议联系HR部门咨询。"不要猜测。
3. 回答时请包含：结论、适用条件、办理时限、审批角色。
4. 引用制度时注明来源（如"根据《员工考勤管理制度》第X条"）。
5. 如果制度资料之间有冲突，说明冲突并建议人工确认。
6. 不要把相似但不同的条款当成答案。
7. 回答用简洁的口语，不要照搬制度原文的长句。

{{#context#}} 是知识检索节点输出的引用变量，通过变量选择器插入，不要手打。

老哥强调：第 2 条无答案策略是企业场景的底线。 知识库没找到时，必须让模型明说 "不知道"，而不是让它自由发挥编制度 —— 编错制度比不回答更可怕。

5.4 流程结构

开始(sys.query) → 知识检索(查员工制度库) → LLM(基于检索结果回答) → 直接回复

老哥收尾

到这里，你已经用 Dify 跑通了三个应用：营销文案生成器、简历分析助手、员工制度问答。记住一条主线：

Dify 把 "写代码" 变成了 "拖节点 + 写 Prompt + 配参数"。模型是大脑，变量是数据管道，知识库是外接记忆，工作流是流程控制。

下一篇咱们讲进阶：工作流里怎么做条件分支和问题分类、怎么调外部 HTTP API、怎么做多轮对话记忆、怎么搭一个能自己选工具的 Agent，最后怎么发布上线。