name	dify_creator
description	通过多轮对话引导用户确定需求，参考现有 Dify 案例，生成可直接导入 Dify 的工作流 DSL YAML 配置
license	CC BY-NC-SA 4.0
author	沐然

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	收集需求	需求文档
Step 2	案例定位	参考案例列表
Step 3	流程设计	流程结构图
Step 4	用户确认	确认反馈
Step 5	DSL生成	完整YAML文件

Step 1：收集用户需求

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

1.1 基础信息收集

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

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

1.2 功能需求收集

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

通用问题：

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

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

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

根据功能类型补充：

功能类型	补充问题
RAG问答	知识库来源？检索策略（关键词/向量）？召回数量？是否需要重排序？
音视频处理	音频提取？语音识别（ASR）？内容总结？字幕生成？
文档处理	PDF解析？内容提取？格式转换？OCR识别？
图像生成	文生图？图生图？风格迁移？是否需要多图组合？
数据处理	数据来源（API/数据库/文件）？分析维度？图表类型？
工具调用	使用哪些工具/插件？调用频率？是否需要MCP？
多模型协作	调用哪些模型？分工是什么？模型间如何传递信息？

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（会找不到）

正确做法：

先执行 cd "c:\Users\14429\.claude\skills\dify_creator"
再搜索 organized_dsl/**/*.yml
再搜索 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 复杂度匹配

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

复杂度	节点数	适用场景
简单	3-5个	单一功能，线性流程
中等	6-15个	多步骤处理，有分支
复杂	16+个	多模块协作，循环处理

2.4 输出参考案例列表

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

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

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

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

2.5 读取并分析参考案例

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

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

**节点结构：**

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


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

Step 3：工作流结构设计

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

3.1 设计原则

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

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 前必须完成以下步骤：

✅ 已切换到技能目录：cd "c:\Users\14429\.claude\skills\dify_creator"
✅ 已在 Step 2 中读取并分析了参考案例
✅ 已在 Step 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: {{参考案例的版本号}}  # ✅ 与参考案例保持一致

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

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

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

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

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

读取参考案例中的节点结构
- 打开对应的 DSL 文件
- 找到相同类型的节点配置
逐字段对比

字段参考案例生成结果是否正确
data.positionAbsolute false ?
data.selected false ?
height 52 ?
width 242 ?
... ... ...
标记差异并修正
- 发现任何差异，立即修正
- 不能确定的字段，参考案例使用原值

第三步：边连接检查

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

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

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

节点类型	检查重点
`variable-aggregator`	`output_type` + `variables` 数组（不是 outputs/formatter_template）
`end`	`type: end` + `outputs`（不是 type: answer）
`iteration`	`start_node_id` 指向 iteration-start
`llm`	`model.provider`, `model.name`, `prompt_template`
`http-request`	`authorization`, `body` 配置完整

第五步：检查报告

## DSL 检查报告

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

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

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

检查不通过的处理：

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


---

## 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: []               # 插件依赖

节点类型说明

节点类型	用途	关键配置
`start`	开始节点	variables（输入变量定义）
`llm`	大语言模型	model、prompt_template、vision、context
`answer`	Chatflow 直接回复	answer（输出模板），仅用于对话式应用
`knowledge-retrieval`	知识库检索	dataset_ids、query_variable_selector
`tool`	工具调用	provider_id、tool_name、tool_parameters
`code`	代码执行	code、code_language、outputs、variables
`http-request`	HTTP请求	method、url、authorization、body
`if-else`	条件分支	cases（条件判断）
`template-transform`	模板转换	template、variables
`assigner`	写入会话变量	items、write_mode
`variable-aggregator`	聚合多分支输出	variables、output_type（不是简单整合！）
`iteration`	⚠️ 循环处理	iterator_selector、output_selector、start_node_id（必填！）
`document-extractor`	文档提取	variable_selector、is_array_file
`agent`	智能体	agent_parameters、agent_strategy_name
`end`	Workflow 结束节点	outputs（输出变量），仅用于工作流

变量引用语法

# 引用格式：{{#节点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 失败版对比

对比项	✅ 成功版	❌ 失败版
版本	参考案例的版本	版本不一致
iteration-start	✅ 有	❌ 缺少
parentId	✅ 有	❌ 缺少
iteration_id	✅ 有	❌ 缺少
isInIteration 边	✅ 有	❌ 缺少
zIndex: 1002	✅ 有	❌ 缺少
output_type 格式	`array[object]`	错误格式
start_node_id	✅ 指向 iteration-start	❌ 缺少

❌ 常见错误

问题	说明
缺少 iteration-start	迭代必须有专门的 start 子节点，不是"内置"的
缺少 parentId	迭代内部节点无法识别归属哪个迭代
缺少 iteration_id	迭代无法正确管理内部节点
缺少 zIndex: 1002	迭代内部边渲染层级错误
output_type 格式错误	必须是 `array[object]`

迭代边连接类型

类型	说明	是否用于迭代
`custom`	普通连接	❌ 迭代外
`true`	条件为真	❌
`false`	条件为假	❌
`isInIteration`	迭代内连接	✅ 必须用这个

Edge 连接类型

类型	说明	示例
`custom`	普通连接	source → target
`true`	条件为真分支	if-else → true
`false`	条件为假分支	if-else → false
`custom_case_id`	自定义分支	if-else → 自定义case_id
`isInIteration`	循环内连接	iteration内节点连接

使用示例

示例：翻译工作流

用户需求：

名称：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. 案例复用策略

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

2. 流程设计原则

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

3. DSL 编写检查清单

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

4. 测试验证建议

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

错误处理

错误类型	处理方式
需求不完整	提示用户补充缺失信息
流程逻辑错误	指出可能的循环引用或断链
节点配置错误	提供修正建议
变量引用无效	列出可用的变量选项
案例定位失败	扩大搜索范围或手动设计

参考资源

📂 案例目录结构

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+

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