Dify Creator

Dify 工作流生成器 (dify_creator)

通过多轮对话引导用户明确需求，参考 organized_dsl/ 目录中的现有案例，生成符合对应 Dify 版本规范的 DSL YAML 文件，可直接导入 Dify 使用。

⚠️ 重要：搜索文件前必须先切换到技能目录！

cd "c:\Users\14429\.claude\skills\dify_creator"

然后再搜索 organized_dsl/INDEX.md和 organized_dsl/**/*.yml

核心能力

• 智能对话引导：通过提问帮助用户梳理需求，避免遗漏关键信息
• 案例参考定位：基于 INDEX.md 索引，自动匹配相似 Dify 案例
• 工作流结构设计：分析需求后给出流程结构，与用户确认
• 完整 DSL 生成：参考 DSL 节点指南，生成符合规范的完整 YAML 配置

使用场景

• 创建智能客服对话流程
• 构建 RAG 知识库问答系统
• 设计音视频处理工作流
• 开发代码生成和文档处理工具
• 搭建多模型协作的复杂流程

工作流程总览

用户需求 → 案例定位 → 流程设计 → 用户确认 → DSL生成 → 交付

核心步骤

Step 1：收集用户需求

首先向用户询问基础信息，明确工作流的目标和功能。

1.1 基础信息收集

请告诉我关于你要创建的 Dify 工作流的基本信息：

1. **工作流名称**（英文，使用连字符，如：document-processor）
2. **一句话描述**：这个工作流做什么？
3. **应用类型**：
   - workflow：批处理任务，单轮执行
   - advanced-chat：高级聊天模式，支持多轮对话
   - chatflow：对话式应用，简单多轮交互
4. **目标用户**：谁会使用这个工作流？

1.2 功能需求收集

根据用户选择的应用类型，深入询问功能需求：

通用问题：

5. **输入方式**：用户如何提供输入？
   - 文本输入（短文本/长文本）
   - 文件上传（图片/PDF/音视频/文档）
   - 混合输入

6. **核心处理**：工作流需要执行哪些处理步骤？
   - 数据预处理 → 核心处理 → 结果输出
   - 请尽可能描述每个步骤

7. **输出形式**：最终返回什么结果？
   - 文本回复
   - 结构化数据（JSON/Markdown表格）
   - 文件（图片/PDF/音频）
   - 混合输出

根据功能类型补充：

1.3 模型和工具配置

8. **大模型选择**：
   - 模型提供商：OpenAI / Anthropic / 国内模型（硅基流动/通义千问/零一万物等）
   - 模型名称：如 gpt-4o, deepseek-V3, qwen-max
   - 参数设置：temperature（创意度 0-1）、max_tokens 等

9. **工具/插件**：
   - 内置工具：代码执行、知识检索、HTTP请求、TTS等
   - 第三方插件：PDF处理、数据库连接等
   - MCP服务：是否需要集成外部MCP工具？

10. **知识库（可选）**：
    - 是否需要接入知识库？
    - 知识库ID和名称
    - 检索策略配置

1.4 流程控制询问

11. **流程分支**：是否有条件分支？（是/否）
    - 如果是，分支条件是什么？（例如：根据用户意图分类走不同处理路径）
12. **循环处理**：是否需要迭代处理批量数据？（是/否）
    - 例如：批量处理多个文件、对列表中每项进行处理
13. **会话状态**：是否需要保存会话状态？（是/否）
    - 例如：记录用户偏好、跨轮次变量传递
14. **错误处理**：失败时如何处理？
    - 终止流程并报错
    - 继续执行其他分支
    - 返回默认结果

Step 2：案例定位（基于 INDEX.md）

根据收集的需求，在 organized_dsl/INDEX.md 中定位相似案例。

2.0 搜索路径配置

⚠️ **关键步骤：搜索前必须先切换到技能目录！**

**第一步：切换到技能目录（必须执行）**
```bash
cd "c:\Users\14429\.claude\skills\dify_creator"

第二步：搜索 DSL 文件

• 搜索 organized_dsl/**/*.yml（在技能目录下搜索）

第三步：搜索索引文件

• 搜索 organized_dsl/INDEX.md
• 搜索 organized_dsl/Dify_DSL_节点完整参考指南.md

错误做法：

• ❌ 直接搜索 **/*.yml（当前目录可能不对）
• ❌ 搜索 **/organized_dsl/**/*.yml（路径重复）
• ❌ 搜索 **/*.yaml（文件是 .yml 不是 .yaml）
• ❌ 在其他目录下搜索 organized_dsl/**/*.yml（会找不到）

正确做法：

1. 先执行 cd "c:\Users\14429\.claude\skills\dify_creator"
2. 再搜索 organized_dsl/**/*.yml
3. 再搜索 organized_dsl/INDEX.md

### 2.1 读取 INDEX.md 索引

首先读取索引文件了解案例分类：

```markdown
1. 搜索并读取 `organized_dsl/INDEX.md`
2. 根据用户需求的功能类型，定位相关分类目录
3. 在对应目录中搜索相似功能的 DSL 案例（使用 `organized_dsl/**/*.yml`）

2.2 分类定位

根据功能类型查找对应目录：

根据你的需求，我定位到以下相关分类：

| 分类 | 目录路径 |
|------|----------|
| 内容创作 | `01_内容生成与创作/` |
| 图像生成 | `02_图像生成与设计/` |
| 视频生成 | `03_视频生成/` |
| 数据分析 | `04_数据分析与可视化/` |
| 文档处理 | `05_文档处理与OCR/` |
| 知识库RAG | `06_知识库与RAG/` |
| Agent工具 | `07_Agent与工具调用/` |
| 教育学习 | `08_教育与学习/` |
| 商业办公 | `09_商业与办公/` |
| 多媒体处理 | `10_多媒体处理/` |
| 代码开发 | `11_代码与开发/` |
| 创意娱乐 | `12_创意与娱乐/` |

2.3 复杂度匹配

根据节点数量匹配复杂度：

2.4 输出参考案例列表

找到以下与你需求相关的参考案例：

### 📂 案例1：[案例名称]
- **位置**：`目录路径/文件名.yml`
- **复杂度**：简单/中等/复杂
- **节点数**：X个
- **主要节点**：start → llm → answer
- **参考价值**：节点结构、Prompt模板、流程设计

### 📂 案例2：[案例名称]
...

请确认：
- 是否需要查看更多相似案例？
- 哪些案例的结构最符合你的需求？

2.5 读取并分析参考案例

选定参考案例后，读取 DSL 文件进行分析：

我已读取参考案例，以下是关键配置提取：

**节点结构：**

[开始节点] ↓ [LLM节点] - 模型: xxx, Prompt: xxx ↓ [工具节点] - 工具: xxx ↓ [输出节点]

**关键配置参考：**
- LLM prompt模板：...
- 变量传递方式：...
- 条件分支逻辑：...

Step 3：工作流结构设计

根据需求分析和参考案例，设计工作流结构。

3.1 设计原则

1. KISS原则：保持简单，避免过度设计
2. 模块化：将复杂流程拆分为可复用的步骤
3. 清晰变量：使用有意义的变量名，便于追踪

3.2 输出流程结构图

根据你的需求，我设计了以下工作流结构：

## 📊 流程结构图

┌─────────────┐ │ 开始节点 │ 输入：{{input_var}} └──────┬──────┘ ↓ ┌─────────────┐ │ 预处理节点 │ 功能：数据清洗/格式转换 └──────┬──────┘ ↓ ┌─────────────┐ │ 核心处理 │ 功能：LLM调用/工具执行 │ (分支判断) │ 条件：{{condition}} └──────┬──────┘ ┌────┴────┐ ↓ ↓ ┌──────┐ ┌──────┐ │分支A │ │分支B │ └────┬─┘ └────┬─┘ │ │ └────┬─────┘ ↓ ┌─────────────┐ │ 结果处理 │ 功能：格式化/聚合 └──────┬──────┘ ↓ ┌─────────────┐ │ 输出节点 │ 输出：{{output_var}} └─────────────┘

## 📋 节点列表

| 序号 | 节点名称 | 节点类型 | 功能描述 | 输入变量 | 输出变量 |
|------|---------|---------|---------|---------|---------|
| 1 | 开始 | start | 接收用户输入 | - | user_input |
| 2 | 预处理 | code | 数据清洗 | user_input | clean_data |
| 3 | LLM处理 | llm | 生成内容 | clean_data | llm_result |
| 4 | 条件判断 | if-else | 分支处理 | llm_result | branch |
| 5 | 输出 | answer | 返回结果 | final_result | - |

## 📝 关键配置

**LLM配置：**
- 模型：xxx
- Prompt模板：xxx

**变量传递：**
- 上游输出 → 下游输入

Step 4：用户确认（⚠️ 必须步骤）

警告：未获得用户明确确认前，禁止生成 DSL！

向用户展示结构设计，必须获取以下确认后才能继续：

4.1 确认内容

## 工作流结构确认 ⚠️

在生成 DSL 文件之前，请确认以下设计：

### ✅ 流程结构
- 节点数量：X 个
- 流程分支：X 条
- 循环处理：X 处

### ✅ 节点配置
1. [节点1]：确认配置 ✓
2. [节点2]：需要调整 →
3. [节点3]：确认配置 ✓

### ✅ 待确认事项
1. 模型选择是否正确？
2. Prompt模板是否需要调整？
3. 分支条件是否合理？
4. 输出格式是否满足需求？

**请回复「确认」或「继续」以生成 DSL，或提供修改意见。**

4.2 确认检查清单

生成 DSL 前必须确认以下全部项目：

- [ ] 用户明确回复「确认」或「继续」
- [ ] 所有节点配置已与用户核对
- [ ] 模型和参数已获用户认可
- [ ] 输出格式符合用户需求

**未满足上述条件，禁止跳到 Step 5！**

4.3 调整迭代

如果用户有修改意见，迭代调整直到确认：

根据你的反馈，我进行了以下调整：

1. 修改了 LLM 节点 Prompt 模板
2. 添加了新的条件分支
3. 调整了变量传递逻辑

请再次确认。

Step 5：生成完整 DSL（⚠️ 必须参考案例）

生成 DSL 前必须完成以下步骤：

1. ✅ 已切换到技能目录：cd "c:\Users\14429\.claude\skills\dify_creator"
2. ✅ 已在 Step 2 中读取并分析了参考案例
3. ✅ 已在 Step 4 中获得用户明确确认
4. ✅ 已读取 organized_dsl/Dify_DSL_节点完整参考指南.md

5.1 前置检查

生成 DSL 前确认：

- [ ] 已选定参考案例文件（路径：xxx/xxx.yml）
- [ ] 已读取节点配置参考指南
- [ ] 已获得用户「确认」回复
- [ ] 所有节点配置已确定

**未完成以上步骤，禁止生成 DSL！**

5.2 生成结构

app:
  description: '{{description}}'
  icon: '{{icon}}'
  icon_background: '{{icon_background}}'
  mode: '{{mode}}'
  name: '{{name}}'
  use_icon_as_answer_icon: false
kind: app
version: {{参考案例的版本号}}
workflow:
  conversation_variables: []
  environment_variables: []
  features:
    file_upload: {}
    # ... 其他功能配置
  graph:
    edges: []
    nodes: []
  viewport: {}

5.3 节点 ID 生成规则

• 使用时间戳+随机数作为节点 ID
• 格式：{时间戳}{随机6位数字}
• 示例：1741011655068, 1735195133945

5.4 位置计算

节点在画布上的位置根据流程顺序自动计算：

• X 坐标：每增加一个节点向右移动约 300px
• Y 坐标：统一居中或根据分支调整

5.5 完整输出示例

# ============================================
# Dify 工作流 DSL 文件
# 名称：xxx
# 生成时间：2026-01-03
# 参考案例：xxx.yml
# ============================================

app:
  description: '工作流描述'
  icon: 🤖
  icon_background: '#FFEAD5'
  mode: workflow
  name: xxx
kind: app
version: {{参考案例的版本号}}
workflow:
  graph:
    edges:
    # ... 连接配置
    nodes:
    # ... 节点配置

⚠️ 5.6 节点编写规则（重要！）

每个节点都必须参考 organized_dsl 案例库中的示例格式编写！

生成工作流时，请严格遵循以下规则：

1. **先查找参考案例**
   - 搜索 `organized_dsl/**/*.yml` 找到相似功能的 DSL 文件
   - 搜索 `organized_dsl/Dify_DSL_节点完整参考指南.md` 查看节点配置说明

2. **节点结构必须完整**
   每个节点必须包含：
   - `id`: 唯一标识
   - `data.type`: 节点类型
   - `data.title`: 节点标题
   - `position`: 画布位置 {x, y}
   - `width`/`height`: 节点尺寸（可选）

3. **禁止凭空编写**
   - ❌ 不要凭记忆或想象编写节点
   - ✅ 必须复制参考案例的结构，替换关键字段

4. **特别注意事项**
   - **迭代节点**：必须包含 iteration-start 子节点和所有必要标记
   - **LLM 节点**：必须包含 model.provider、model.name、prompt_template
   - **HTTP 请求**：必须包含正确的 authorization 和 body 配置
   - **变量引用**：必须使用 `{{#节点ID.变量#}}` 格式

⚠️ 5.7 生成后强制检查（❗必须执行）

生成 DSL 后，必须按以下步骤强制检查每个节点！

## DSL 生成后强制检查 ⚠️

**警告：未完成检查，禁止交付给用户！**

### 第一步：确定版本号
```yaml
version: {{参考案例的版本号}}  # ✅ 与参考案例保持一致

要点： 版本号应与所选参考案例保持一致，不是固定值。

第二步：遍历每个节点，逐一对照参考案例检查

对于每个生成的节点，执行以下检查：

1. 在参考案例中找到同类型节点

   cd "c:\Users\14429\.claude\skills\dify_creator"
   rg "type: 节点类型" organized_dsl/**/*.yml | head -20
   

2. 读取参考案例中的节点结构

   • 打开对应的 DSL 文件
   • 找到相同类型的节点配置

3. 逐字段对比

   字段	参考案例	生成结果	是否正确
   data.positionAbsolute	false	?
   data.selected	false	?
   height	52	?
   width	242	?
   ...	...	...

4. 标记差异并修正

   • 发现任何差异，立即修正
   • 不能确定的字段，参考案例使用原值

第三步：边连接检查

遍历每条边，检查以下字段：

• data.sourceType: 源节点类型
• data.targetType: 目标节点类型
• data.selected: false
• data.isInIteration: false（迭代外）
• type: custom/true/false/isInIteration

第四步：特殊节点重点检查

第五步：检查报告

## DSL 检查报告

### 节点检查结果
| 节点ID | 节点类型 | 检查状态 | 问题 |
|--------|---------|---------|------|
| xxx | start | ✅ 通过 | 无 |
| xxx | llm | ❌ 失败 | 缺少 model.provider |

### 边检查结果
| 边ID | 类型 | 检查状态 | 问题 |
|------|-----|---------|------|
| xxx | custom | ✅ 通过 | 无 |

### 最终结论
- [ ] 所有节点检查通过
- [ ] 所有边检查通过
- [ ] 无需修正，可以交付

检查不通过的处理：

1. 定位问题节点
2. 读取参考案例
3. 修正节点配置
4. 重新检查直到通过

---

## Dify DSL 结构规范

### 完整结构模板

```yaml
app:
  description: '应用描述'
  icon: 🤖
  icon_background: '#FFEAD5'
  mode: workflow|advanced-chat|chatflow
  name: 应用名称
  use_icon_as_answer_icon: false
kind: app
version: {{参考案例的版本号}}
workflow:
  conversation_variables: []   # 会话变量
  environment_variables: []    # 环境变量
  features:
    file_upload:               # 文件上传配置
      enabled: false
      # ... 详细配置
    opening_statement: ''      # 开场白
    retriever_resource:        # 检索资源
      enabled: true
    text_to_speech:            # TTS配置
      enabled: false
  graph:
    edges: []                  # 连线列表
    nodes: []                  # 节点列表
  viewport:                    # 视图位置
    x: 0
    y: 0
    zoom: 1
dependencies: []               # 插件依赖

节点类型说明

变量引用语法

# 引用格式：{{#节点ID.输出字段#}}

# 引用开始节点的输入
{{#1742961448129.file#}}

# 引用 LLM 节点的文本输出
{{#1742965550311.text#}}

# 引用 Code 节点的自定义输出
{{#1747670104835.result#}}

# 引用会话变量
{{#conversation.status#}}

# 引用环境变量
{{#env.API_KEY#}}

⚠️ 迭代节点规范（关键！）

迭代节点是 DSL 中最容易出错的部分，缺少任何一项都会导致导入失败！

迭代节点完整结构

# 1. iteration 节点 - 循环控制器
- id: '1741011600006'
  data:
    iterator_selector: ['1741011655068', 'text']  # 要遍历的数组
    output_selector: ['1741011662463', 'result']  # 输出结果
    output_type: array[object]                     # 必须格式
    start_node_id: 1741011600006start              # 必须指向 iteration-start
    title: 迭代处理
    type: iteration
  position: {x: 200, y: 100}

# 2. iteration-start 节点 - 迭代入口（必须有！）
- id: 1741011600006start
  data:
    title: 迭代开始
    type: custom-iteration-start
  parentId: '1741011600006'    # 必须指向父迭代节点
  position: {x: 200, y: 200}

# 3. 迭代内部节点 - 处理每个元素
- id: '1741011662463'
  data:
    isInIteration: true         # 必须标记在迭代内
    iteration_id: '1741011600006'  # 必须标识所属迭代
    parentId: '1741011600006'   # 必须指向父迭代
    title: 处理节点
    type: llm
  position: {x: 200, y: 300}

# 4. 迭代内部边 - 连接迭代内节点
- source: 1741011600006start
  target: '1741011662463'
  type: isInIteration           # 必须是 isInIteration
  zIndex: 1002                  # 必须的渲染层级

成功版 vs 失败版对比

❌ 常见错误

迭代边连接类型

Edge 连接类型

使用示例

示例：翻译工作流

用户需求：

• 名称：zh-en-translator
• 功能：中译英翻译
• 类型：workflow
• 输入：中文文本
• 流程：用户输入 → LLM翻译 → 返回结果

生成配置：

app:
  description: '中英文翻译工作流'
  icon: 🌐
  icon_background: '#E3F2FD'
  mode: workflow
  name: zh-en-translator
kind: app
version: {{参考案例的版本号}}
workflow:
  graph:
    edges:
    - source: '1741011655068'
      target: '1741011662463'
      type: custom
    - source: '1741011662463'
      target: llm
      type: custom
    - source: llm
      target: answer
      type: custom
    nodes:
    - data:
        title: 开始
        type: start
        variables:
        - variable: text
          type: paragraph
          label: 输入中文文本
          required: true
      id: '1741011655068'
      position: {x: 0, y: 263}
    - data:
        context:
          enabled: false
        model:
          provider: siliconflow
          name: internlm2_5-7b-chat
          mode: chat
        prompt_template:
        - role: system
          text: '请将以下中文翻译成英文，只输出翻译结果：{{#1741011655068.text#}}'
        title: LLM翻译
        type: llm
      id: llm
      position: {x: 382, y: 263}
    - data:
        answer: '{{#llm.text#}}'
        title: 翻译结果
        type: answer
      id: answer
      position: {x: 690, y: 263}

最佳实践

1. 案例复用策略

1. 先定位：通过 INDEX.md 找到最相似的案例
2. 再分析：阅读 DSL 文件，理解节点配置
3. 后调整：基于参考模板进行个性化修改

2. 流程设计原则

1. 从简单开始：先实现核心功能，再添加分支和循环
2. 模块化设计：复杂流程拆分为可复用步骤
3. 清晰命名：使用有意义的变量名

3. DSL 编写检查清单

• 节点 ID 唯一且格式正确
• 位置坐标合理，不重叠
• Edge 连接正确，无断链
• 变量引用格式正确
• Model/Provider 配置有效
• 输出变量名与引用一致

4. 测试验证建议

1. 生成后在 Dify 中导入测试
2. 检查各节点的输入输出
3. 验证条件分支逻辑
4. 测试边界情况和错误处理

错误处理

参考资源

📂 案例目录结构

organized_dsl/
├── 01_内容生成与创作/
├── 02_图像生成与设计/
├── 03_视频生成/
├── 04_数据分析与可视化/
├── 05_文档处理与OCR/
├── 06_知识库与RAG/
├── 07_Agent与工具调用/
├── 08_教育与学习/
├── 09_商业与办公/
├── 10_多媒体处理/
├── 11_代码与开发/
├── 12_创意与娱乐/
├── 13_信息聚合/
├── 14_参考示例/
├── INDEX.md                    # 案例索引（搜索 organized_dsl/INDEX.md）
└── Dify_DSL_节点完整参考指南.md  # 节点配置参考（搜索 organized_dsl/Dify_DSL_节点完整参考指南.md）

📖 文档链接

• INDEX.md：按功能分类的案例索引
• Dify_DSL_节点完整参考指南.md：各节点的详细配置说明

节点自动校验与生成规则

版本号规则

# ✅ 正确 - 生成时必须使用
version: {{参考案例的版本号}}

# ❌ 错误 - 禁止使用
version: {{参考案例的版本号}}

节点基础字段规则

每个节点生成时必须包含：

- data:
    positionAbsolute: false      # ✅ 必须
    selected: false              # ✅ 必须
    title: "节点名称"
    type: "节点类型"
    # ... 其他字段
  height: 52
  id: '节点ID'
  position:
    x: 0
    y: 0
  width: 242

Edges 字段规则

每条边生成时必须包含：

- data:
    isInIteration: false         # ✅ 必须
    selected: false              # ✅ 必须
    sourceType: "源节点类型"
    targetType: "目标节点类型"
  id: "边ID"
  source: "源节点ID"
  sourceHandle: "source"
  target: "目标节点ID"
  targetHandle: "target"
  type: "custom|true|false|isInIteration"

variable-aggregator 节点生成规则

# ✅ 正确写法 - 用于聚合多分支输出
- data:
    output_type: string          # 聚合结果的输出类型
    type: variable-aggregator
    variables:                   # 聚合多分支的变量（二维数组）
    - - '分支节点ID1'             # 第一个分支的输出
      - text
    - - '分支节点ID2'             # 第二个分支的输出
      - text
  height: 211
  id: '聚合节点ID'

# ❌ 错误理解 - 不是简单的"将多个内容整合到一起"
# variable-aggregator 的真正用途：
# - 整合 IF/ELSE 条件分支的输出
# - 整合并行结构的多个输出
# - 确保无论哪个分支执行，下游都能通过统一变量引用

end 节点生成规则

# ✅ 正确写法 - Workflow 应用的结束节点
- data:
    outputs:
    - value_selector:
      - '上游节点ID'
      - text
      variable: output
    type: end                    # ✅ 使用 type: end（仅用于 Workflow）
  height: 103
  id: end

answer 节点使用场景

# ✅ 正确写法 - 仅用于 Chatflow 应用
- data:
    answer: '{{#llm.text#}}'     # 使用 answer 字段
    type: answer                 # ✅ 使用 type: answer（仅用于 Chatflow）

DSL 生成检查清单（生成后必查）

生成 DSL 后，逐项检查：

应用类型检查：

• Workflow 类型使用 type: end，Chatflow 类型使用 type: answer
• Workflow 只能有唯一 End 节点
• Chatflow 支持多个 Answer 节点

节点检查：

• 版本号与参考案例一致
• 每个节点有 data.positionAbsolute: false
• 每个节点有 data.selected: false
• 每个节点有 height 和 width

边检查：

• 每条边有 data.sourceType
• 每条边有 data.targetType
• 每条边有 data.selected: false
• 每条边有 data.isInIteration（迭代外为 false）

variable-aggregator 检查：

• 使用 output_type（不是 outputs）
• 使用 variables 数组格式（不是 formatter_template）
• 理解用途：聚合多分支输出，不是简单整合内容

assigner vs variable-aggregator 检查：

• 需要写入会话变量 → 使用 assigner
• 需要聚合多分支输出 → 使用 variable-aggregator

最后更新: 2026-01-03 参考案例数: 125+