Dify工作流DSL生成器

手工搭工作流为什么会出错

在 Dify 编辑器里，节点、连线、坐标和变量引用都是靠拖拽和点击产生的隐式状态。当你想把这些流程复制到另一个实例，或者用版本管理、CI 的方式批量生成应用时，图形界面就帮不上忙了——导出的 DSL 字段形状严格、版本间差异明显，手改 YAML 恰好是最容易出错的地方。

这个技能怎么工作

给一句自然语言描述，输出可直接导入的 .dify.yml（或 .dify.json）。

• 需求澄清：描述里包含输入输出、处理逻辑和足够细节就直接执行，否则最多追问 3 轮
• 节点路由：覆盖 Start、End、Answer、LLM、知识检索、代码、HTTP、条件分支、变量聚合、迭代、文档抽取、模板、问题分类、参数提取、工具共 15 类节点，字段规范放在 references/nodes/
• 版本对齐：生成前读取 references/config.yml 的 dsl_version，只使用目标版本已支持的节点类型和字段
• 图结构组装：按固定规则生成节点 ID、连线 ID、边类型和网格坐标，起始节点位于 {x: 80, y: 282}
• 三条执行路径：只生成 DSL、创建应用、更新应用（更新前先导出旧 DSL 备份）

容易翻车的 schema 细节

• 变量形状不统一：Code、LLM、模板转换用对象，聚合器用裸嵌套列表，文档抽取用扁平字符串数组
• memory 只属于 chatflow 的 LLM 节点，workflow 模式必须省略
• 迭代容器要在 data 内和外层都设尺寸，子节点需声明 parentId、isInIteration 和 zIndex: 1002
• End 的 outputs 是列表，Code 的 outputs 是字典，两者形状不能互换
• 模型名必须是真实存在的名字（如 deepseek-chat），虚构名称会导致 provider 校验失败

生成前会先给出 DSL 设计方案供确认，确认后才写文件或调用接口；涉及 Admin API 的部署另有规范约束。