Dify编排ComfyUI自动化漫剧流水线实战教程-知了AI

Dify 编排 + ComfyUI 执行：零代码搭一条”输入故事大纲、输出带音画漫剧”的自动化流水线

漫剧（AI 动态漫画短剧）正在成为内容赛道的新物种：一部一分钟的漫剧，按手工流程要做完扩写分镜、逐镜生图、图生视频、配音、剪辑合成五个环节，一个熟练创作者往往要耗上半天到一天。而其中绝大部分工作——写分镜表、填提示词、上传参考图、点生成、等出图、下载素材——本质上都是重复的流程性劳动。流程性劳动，恰恰是最适合交给自动化流水线的部分。

本文的核心思路是：用 Dify 做编排层（大脑），用 ComfyUI 做执行层（手）。Dify 负责理解故事大纲、扩写分镜、调度顺序、传递变量；ComfyUI 负责真正 Stable Diffusion / Flux 模型的出图计算；中间用 HTTP 请求节点把两者粘起来，再接上图生视频服务和 TTS 配音，最终形成一条”输入故事大纲、输出带音画漫剧半成品”的自动化流水线。全程不写一行工程代码，只需要在画布上连线、在节点里填参数。

下面从整体架构讲起，逐步落到每个节点的输入输出、ComfyUI API 的调用细节、分镜 JSON 的字段设计，最后给出选型对比、故障排查和常见问答。

一、为什么是 Dify + ComfyUI：分工逻辑与整体架构

1.1 编排与执行的职责切分

很多初学者会陷入一个误区：想用一个大模型”端到端”直接生成漫剧。实际上大模型擅长的是文本理解与结构化生成，不擅长的是确定性的多步骤流程调度。让 LLM 直接”生成一部漫剧”，它无法控制镜头数量稳定、无法等待图片生成完成、也无法在出图失败时自动重试。

正确的架构是把整条链路拆成两类节点：

编排类节点（Dify 内）：开始节点、LLM 分镜扩写节点、代码/参数转换节点、迭代节点、条件分支节点、模板拼接节点、结束节点。它们决定”什么顺序做什么”。
执行类节点（被编排的对象）：ComfyUI 出图、图生视频服务、TTS 配音。它们决定”具体怎么做”。

Dify 作为开源的大模型应用编排平台，提供了可视化 Workflow 画布，内置 HTTP 请求节点、代码节点、条件分支、变量传递和批量迭代能力——这五样正好覆盖了漫剧流水线的全部控制需求。ComfyUI 则是执行层的标准选择：它以节点图方式描述一次生图任务，支持 API 模式（/prompt 接口），可以把画布上调试好的工作流一键导出为 API 格式 JSON，外部程序通过 HTTP 提交任务并轮询结果即可。这意味着你在 ComfyUI 界面里调好的出图效果，可以原封不动地被自动化流水线复用，这是它相比裸写 SD WebUI 脚本最大的工程优势。

1.2 一图看懂：流水线节点拓扑

整条流水线的节点拓扑用文字描述如下（从上到下即执行顺序）：

开始节点：输入变量 story_outline（故事大纲文本）、episode_style（画风关键词）、shot_count（目标镜头数，如 12）。
LLM 分镜扩写节点：输入大纲与镜头数，输出结构化分镜 JSON（详见第四节）。
代码节点（参数规范化）：把 LLM 输出的 JSON 字符串解析、校验、补默认值，产出规范的数组变量 shots[]。
迭代节点（逐镜头循环）：遍历 shots[]，循环体内包含四个子节点——

4.1 LLM 提示词精修节点：把该镜头的场景描述转写成适配画风的正向/负向提示词；
4.2 HTTP 节点 A（提交 ComfyUI 出图）：POST 到 http://comfyui-host:8188/prompt，携带 API 工作流 JSON 与 client_id，返回 prompt_id；
4.3 HTTP 节点 B（轮询取结果）：循环 GET /history/{prompt_id}，直到拿到输出文件名；
4.4 HTTP 节点 C（图生视频）：把成图 URL 提交给图生视频服务，同步或轮询拿到短视频片段；
4.5 TTS 节点（配音）：把该镜头旁白文本转成语音文件；

代码节点（失败收集）：迭代结束后汇总成功/失败的镜头，生成 failed_shots[]。
条件分支节点：若 failed_shots 非空且重试次数未超上限，回到迭代节点只处理失败镜头（重试队列）；否则继续。
模板拼接节点：把所有镜头的视频、音频、字幕汇总成一份”交付清单 JSON”（含每个镜头的素材路径与元信息），供剪辑环节按清单自动合成。
结束节点：输出清单与统计信息（成功镜头数、重试次数、总耗时）。

这张拓扑图记在心里，后面每一节都是在给其中某个节点”填肉”。

二、前置准备：把 ComfyUI 变成一个可被调用的服务

2.1 开启 API 模式

ComfyUI 默认启动就带 HTTP 服务（通常在 8188 端口），API 模式不需要额外开关。关键是把你在界面上搭好的工作流导出为 API 格式：在 ComfyUI 界面的设置里打开开发者模式选项，然后在工作流菜单中选择”导出（API）”，得到一个 JSON 文件。这个 JSON 和界面文件的区别在于：它按节点 ID 组织，每个节点只有 class_type、inputs 两级结构，没有坐标等界面信息，是专门给程序调用的。

导出后，把其中需要动态替换的字段改写成占位逻辑。例如 KSampler 节点的 seed、正向提示词 CLIP Text Encode 节点的 text，流水线里每跑一个镜头都要替换它们。Dify 的 HTTP 节点支持在 JSON body 里插入变量，所以做法是：把 API JSON 存成 Dify 代码节点里的一个模板字符串，用代码节点做字符串替换（或用 json.loads 后改字段再 dumps），再传给 HTTP 节点。

2.2 三个必须搞懂的概念：client_id、prompt_id、history

这是整条自动化流水线最核心的 API 机制，务必理解：

client_id：调用方身份标识。你用 uuid4 生成一个随机串，在提交任务时放进 body 的 client_id 字段。它的作用是让 ComfyUI 知道”这个任务是谁提交的”，并用于 WebSocket 消息路由。即使你不用 WebSocket，也建议固定使用同一个 client_id，方便在队列里筛出自己的任务。
prompt_id：单次任务的唯一回执。POST /prompt 成功后返回的 JSON 形如 {"prompt_id": "xxxxxxxx-xxxx", "number": 3, "node_errors": {}}。后续所有轮询、取结果都以这个 ID 为钥匙。如果响应里出现 node_errors 非空，说明工作流 JSON 校验失败（通常是节点参数类型错了或模型名不存在），流水线应立即判定为”配置错误”而非”生成失败”——前者重试没有意义。
history：任务结果的存档。GET /history/{prompt_id} 返回该任务的状态与每个输出节点的产出文件。任务还在排队/执行时返回空对象或不含该 id 的结果；执行完成后，输出节点（如 SaveImage）的字段里会给出 filename、subfolder、type。

2.3 取图：三个接口配合使用

拿到 filename 之后，用下面接口下载成图：

GET http://comfyui-host:8188/view?filename={filename}&subfolder={subfolder}&type=output

工程上有三个要点：

轮询节奏：不要裸循环打接口。建议间隔 2 秒起，随任务时长线性放宽到 5 秒；同时设置总超时（例如 300 秒），超时后判定失败进入重试队列。
建议在 ComfyUI 里加一个 Queue Image 节点或改用 SaveImage 的自定义前缀：给输出文件名加 {prompt_id} 前缀，这样批量并发时不会因为同名文件互相覆盖。ComfyUI 的 SaveImage 支持 filename_prefix 参数，把 prompt_id 拼进去即可。
如果工作流是”先出图再放大”的多阶段结构，history 里会有多个输出节点，取图时要按节点 ID 精确取你想要的那个输出，别把中间图当成品。

三、Dify 画布搭建：五个关键节点的配置细节

3.1 开始节点与 LLM 分镜扩写节点

开始节点定义三个输入：story_outline（多行文本）、episode_style（下拉或文本）、shot_count（数字）。分镜扩写节点的系统提示词是整条流水线质量的天花板，建议包含四条硬约束：

输出必须是合法 JSON 数组，不要包 markdown 代码块、不要任何解释文字；
数组长度严格等于 shot_count，不许增删；
每个镜头的 scene_desc 用纯视觉语言描述画面（人物、动作、景别、光线），禁止出现心理描写；
相邻镜头的人物外貌描述保持一致（发色、服饰用词完全相同），这是保证出图角色一致性的第一道防线。

LLM 节点的输出模式建议直接选 JSON 结构化输出（Dify 支持指定 JSON Schema），从机制上杜绝”模型偷偷加一段抱歉的话导致 JSON 解析失败”的问题。

3.2 代码节点：参数规范化与兜底

即使有结构化输出，也建议加一个代码节点做兜底：json.loads 解析、逐字段校验类型、给缺失字段填默认值（如 camera 缺省为 “中景”、duration 缺省为 4 秒）、对超长字段截断。这个节点输出的 shots 数组是迭代节点的输入源。工程经验是：所有跨节点的数据契约都在代码节点里显式定义，不要信任上游任何节点的”自觉”。

3.3 迭代节点：逐镜头处理的并行度控制

把 shots 接入迭代节点，循环体里依次串接 4.1~4.5 五个子节点。Dify 的迭代节点支持设置并发数——这是整条流水线最需要克制的一个参数，直接展开讲：

如果 ComfyUI 和 Dify 部署在同一台机器、共用一张消费级显卡（显存 12~24GB），迭代并发建议设为 1，靠 ComfyUI 自己的队列排队即可。ComfyUI 本身就是串行执行队列的，Dify 侧并发开得再大也只是让请求堆在队列里，没有任何加速，反而会让轮询请求互相挤占。
如果 ComfyUI 部署在多卡机器或有多实例（用负载均衡前缀路由），并发数可以设为”实例数”，让多个镜头同时在多张卡上跑。
图生视频和 TTS 通常是外部 API 服务，不吃你本地显存，它们的瓶颈在配额和账单，可以适当放并发。

这背后是一条值得刻在脑子里的独到判断：自动化的瓶颈永远在显存不在代码。编排层写得再漂亮，一张 4090 每分钟也只能产出固定数量的图。流水线优化的优先级永远是：先榨干 GPU 利用率（减少空闲排队），再考虑加卡或换更快的模型，最后才轮到改代码。

3.4 HTTP 节点：提交与轮询的写法

HTTP 节点 A（提交）：方法 POST，URL http://comfyui-host:8188/prompt，body 为：

{
  "prompt": {{wf_json}},
  "client_id": "{{client_id}}"
}

其中 wf_json 是上游代码节点产出的、已替换好该镜头提示词与种子的 API 工作流 JSON。client_id 可以在开始节点生成一次（或用代码节点 str(uuid.uuid4())）全流程复用。

HTTP 节点 B（轮询）：这里有个实操技巧——Dify 的 HTTP 节点本身不带”轮询直到成功”的原生语义，推荐两种做法：

做法一（推荐）：在 ComfyUI 前面加一层极薄的轮询网关（哪怕是一个几十行的本地小服务，或用支持重试语义的反代），对 Dify 暴露一个”同步接口”：收到请求后内部提交任务、轮询 history、最后直接返回图片 URL。Dify 侧只需要一个普通 HTTP 节点，把重试复杂度收在网关里。
做法二：用 Dify 迭代/循环节点做”轮询循环”——HTTP 节点 B 查一次 history，条件分支判断返回里是否包含输出文件，未包含则进一个短暂等待（可用代码节点做空转或用支持延时的插件）再回到 B，超过 N 次则判失败。这个结构更”纯 Dify”，但画布会多出一块循环子图。

无论哪种做法，超时与重试策略必须显式设计，见第五节。

四、分镜 JSON：整条流水线的数据契约

4.1 字段结构示例

分镜 JSON 是 LLM 节点与所有执行节点之间的数据契约，字段一旦稳定就不要轻易改动。一个经过实战验证的结构如下：

[
  {
    "shot_id": 1,
    "scene_desc": "雨夜的旧式天台，少年背对镜头望向城市霓虹，风衣下摆被风掀起，低头可见湿漉漉的水泥地面反光",
    "camera": "远景，仰角",
    "character": "少年阿澈，黑色短发，深蓝色风衣，白色围巾",
    "dialogue": "这座城市……真的还会有人记得我吗？",
    "narration": "三年前的那个雨夜，是阿澈最后一次站在这座天台上。",
    "sfx": "雨声，远处车流声",
    "duration": 4,
    "style_tags": "cinematic, rain, night, neon",
    "negative_tags": "blurry, extra fingers, text, watermark",
    "seed": null
  }
]

4.2 每个字段为什么存在

shot_id：全流程主键。提交 ComfyUI 时拼进 filename_prefix、写进交付清单，失败重试时靠它定位。
scene_desc 与 character 分离：出图提示词 = 角色固定描述 + 场景动态描述。分开存才能在提示词精修节点里”角色描述原样保留、场景描述自由发挥”，这是低成本维持角色一致性的关键结构。
dialogue（角色台词）与 narration（旁白）分离：两者走不同的 TTS 音色（台词用角色音色、旁白用讲述者音色），混在一起后期没法分轨。
duration：图生视频的时长参数；TTS 合成后如果音频比视频长，流水线应按”音频时长 + 0.5 秒”覆盖该值，这个覆盖逻辑放在代码节点里。
seed：默认 null 表示每次随机；但当你人工挑中某张构图特别好的图想固定复刻时，把 seed 回填进分镜 JSON，重跑就是确定性输出。seed 字段是”自动生成”与”人工干预”之间的握手协议。
style_tags / negative_tags：由开始节点的 episode_style 全局生成一次，逐镜头只做微调，避免 LLM 每个镜头重新发挥导致画风漂移。

4.3 交付清单：流水线的最后一公里

所有镜头处理完后，模板拼接节点输出一份交付清单 JSON，形如：

{
  "episode_id": "ep007",
  "shots": [
    {
      "shot_id": 1,
      "status": "success",
      "image": "output/ep007_s1_9f3a.png",
      "video": "output/ep007_s1.mp4",
      "audio": "output/ep007_s1.wav",
      "duration": 4.2,
      "subtitle": "三年前的那个雨夜，是阿澈最后一次站在这座天台上。"
    }
  ],
  "failed_shots": [],
  "stats": { "total": 12, "retried": 1, "elapsed_sec": 486 }
}

剪辑环节（无论是剪映的批量草稿脚本，还是 ffmpeg 命令）只需要读这份清单按 shot_id 顺序拼接即可。让流水线输出”清单”而不是”一堆散文件”，是它真正接入下游生产的关键设计。

五、失败重试与并发：产能的决定性设计

5.1 失败分类：先分清”重试有用”和”重试没用”

把失败分成三类，处理策略完全不同：

瞬时失败（网络抖动、HTTP 5xx、ComfyUI 显存临时不足 OOM）：值得重试。策略是指数退避——第一次等 5 秒、第二次等 15 秒、第三次等 45 秒，最多 3 次。
结果性失败（出图成功但图片质量差、图生视频结果画面崩坏）：机器判定不了好坏，进”人工复核队列”。交付清单里标记 status: "needs_review"，不要让流水线自作主张重跑浪费显存。
配置性失败（node_errors 非空、模型名不存在、工作流 JSON 结构错误）：重试毫无意义，应立即中断整条流水线并报错，而不是默默烧完 12 个镜头的配额。

实践中可以在代码节点里用一个简单的判定函数给失败打上这三类标签，条件分支节点据此分流。

5.2 失败重试队列的实现

Dify 画布上的实现方式：迭代节点结束后，代码节点汇总出 failed_shots（重试次数未达上限的失败镜头数组）→ 条件分支判断”非空且 retry_round < 3″→ 为真则进入第二个迭代节点（复用同一套子流程，输入只有失败镜头），并把 retry_round 加一；为假则进入交付清单拼接。失败重试设计比成功路径更决定产能——一条 12 镜头的漫剧，按行业常见出图成功率 85%~95% 算，几乎每集都会有 1~2 个镜头需要重跑；如果重试要靠人工发现、人工重跑，流水线的”自动化”就名存实亡了。

5.3 并发控制与显存保护

除了迭代节点的并发数，还有三个显存保护手段：

ComfyUI 侧队列天然串行：单卡部署时信任 ComfyUI 队列即可，Dify 侧并发设 1，让所有镜头排队，这是最稳的方案。
错峰提交：出图与图生视频交替进行——镜头 1 出图时，镜头 0 的图正在外部服务做图生视频，本地 GPU 不空转。
模型不频繁切换：一集漫剧尽量固定用同一个 checkpoint 和 LoRA 组合。ComfyUI 换模型会触发显存卸载/加载，频繁切换的等待时间可能比生成本身还长。

六、横向对比：编排工具选型与工时账

6.1 Dify vs n8n vs Coze 扣子编排工具选型对比

维度	Dify	n8n	Coze 扣子
定位	开源大模型应用编排平台，LLM 友好	通用自动化工作流工具，连接器生态庞大	托管式 Agent/工作流平台，开箱即用
可视化画布	有，Workflow 支持迭代、分支、变量传递	有，节点类型极多	有，上手门槛最低
LLM 能力	原生内置，支持结构化输出、知识库	需接外部 LLM 节点，能力靠插件拼装	原生内置，模型选择丰富
自部署能力	支持，数据与密钥完全自持	支持，社区版功能完整	主要为云端托管，自部署能力有限
HTTP 调用 ComfyUI	HTTP 节点 + 代码节点可覆盖	HTTP Request 节点成熟，重试机制原生	依赖插件市场，灵活度受限
适合谁	想把 LLM 应用与生成管线一体化的团队	已有大量 SaaS 连接需求的自动化用户	个人创作者快速验证想法

结论：如果你的流水线核心是”LLM 理解 + 自有 GPU 集群执行”，Dify 的开源属性和 LLM 原生设计最匹配；如果重头戏是调度各种第三方 SaaS，n8n 更顺手；纯个人玩票、不想管服务器，Coze 上手最快。

6.2 手工流程 vs 自动化流水线工时对比

环节	手工流程（单集 12 镜头）	自动化流水线	性质变化
分镜扩写	1~2 小时（人写分镜表）	约 1 分钟（LLM 扩写 + 人工抽查）	从创作变为审核
逐镜出图	3~4 小时（逐镜填提示词、点生成、挑图）	自动排队执行，人只复核	从操作变为抽检
图生视频	1~2 小时（逐张上传、等结果）	自动提交与轮询	完全无人值守
配音	1 小时（逐段合成、命名、对轨）	TTS 节点按分镜自动产出	完全无人值守
失败镜头处理	随缘，常常漏掉	重试队列自动跑完	从遗漏风险变为确定性保障
合计	约 6~9 小时	机器执行约 30~60 分钟 + 人工审核约 30 分钟	产能提升一个数量级

注意自动化并没有消灭人工，而是把人工从”操作员”重新定义为”质检员”：挑图、修崩坏镜头、调音画节奏，这些审美判断仍然属于人。

七、独到见解：三个反直觉的工程判断

7.1 编排工具的价值是把 SOP 变成可执行文件

很多团队已经有成熟的漫剧制作 SOP，但 SOP 躺在文档里，依赖每个操作员的记忆和自觉，执行质量随人员波动。Dify 画布的真正价值不是”省了写代码”，而是把 SOP 变成一份可视化、可版本管理、可回放审计的可执行文件：提示词沉淀在节点里，处理顺序固化在连线里，质量约束写在代码节点的校验逻辑里。新人接手不再是”跟老员工学一周”，而是看懂一张画布。从这个意义上说，编排工具是内容工厂的”工艺图纸”，而 ComfyUI 工作流 JSON 是”工装夹具图纸”，两者合起来才构成可复制的内容生产线。

7.2 自动化的瓶颈永远在显存不在代码

再次强调这个判断，因为它决定了你优化精力的分配方向。流水线跑起来之后，你会很快发现：代码层的耗时（LLM 扩写、JSON 处理）加起来不到 5%，95% 的时间在等 GPU。所以别把力气花在把编排图”优化得更优雅”上，先回答三个问题：GPU 利用率有没有空窗？出图模型是不是该换更快的？多卡了没有？显存问题想清楚了，代码只是几行胶水。

7.3 失败重试设计比成功路径更决定产能

画布上画一条成功路径只要一下午，但让流水线在真实生产中”过夜不崩”，靠的是失败路径的完备性：瞬时失败指数退避、配置失败立即熔断、质量失败进人工队列、失败镜头带上下文（原 seed、原提示词、重试次数）进重试队列。一个只有成功路径的流水线是 demo，一个失败路径完备的流水线才是产线。判断一个团队自动化成熟度的最好方法，就是问”镜头失败了你怎么办”，而不是看它的画布多漂亮。

八、FAQ

8.1 搭建这条流水线需要会编程吗？

核心链路不需要。Dify 画布上的 LLM 节点、HTTP 节点、迭代节点、条件分支都是可视化配置；唯一的例外是两三处代码节点，用于 JSON 解析校验和字符串替换，每处十几行 Python，照着本文第四节的示例改即可。会读 JSON、会改模板字符串，就够用了。

8.2 本地部署还是云端服务？

取决于两件事：数据敏感度和显卡。大纲、剧本属于未发布内容，对泄密敏感的团队应选择 Dify 与 ComfyUI 全自部署（同一内网最好，HTTP 调用延迟低且不暴露公网）。图生视频和 TTS 这类你自己没有模型的能力，用云端 API 即可，注意在清单里记录好素材归属。个人学习阶段完全可以一台带 12GB 以上显存的本地机器跑通全链路。

8.3 显存不够怎么并发？

优先级从高到低：① 保持 Dify 迭代并发为 1，信任 ComfyUI 队列串行，这是零成本方案；② 缩小出图分辨率，先出小图确认构图，选中后再走一次放大工作流；③ 使用更省显存的模型或量化版本；④ 多卡/多实例部署 ComfyUI，Dify 侧并发设为实例数，并用轮询网关分发。不要用”提高 Dify 并发数”去硬怼单卡——请求只会堆队列，显存反而可能因为轮询与提交风暴出问题。

8.4 某个镜头生成失败了怎么重试？

流水线内置三级处理：HTTP 层瞬时错误按指数退避自动重试 3 次；仍失败的镜头被代码节点收集进 failed_shots，条件分支触发失败重试迭代，只重跑失败镜头并保留原分镜上下文；三轮后仍失败的标记为 needs_review 留给人工。人工修好提示词或回填 seed 后，把该镜头单独喂回流水线重跑即可，不影响其他镜头。

8.5 怎么保证不同镜头里角色长得一样？

四层手段叠加：① 分镜 JSON 里 character 字段固定角色外貌描述，逐镜头原样拼进提示词；② LLM 分镜提示词中明确要求相邻镜头外貌用词一致；③ ComfyUI 工作流里接入固定角色 LoRA 或参考图（IPAdapter 类节点），这是效果最好的一层；④ 人工挑图时只挑角色过关的镜头，并把对应 seed 回填，保证被复用的镜头稳定。指望某一层单独解决一致性是不现实的，必须叠满。

8.6 这套流水线的扩展方向有哪些？

三个方向最实际：① 加字幕节点——TTS 结果配合音频时长自动生成 SRT，写进交付清单；② 加配乐与音效轨——用 sfx 字段驱动音效素材检索，自动铺底；③ 多集批量化——外层再套一个迭代节点遍历”整季大纲”，逐集调用现有流水线，把 Dify 应用从”单集生成器”升级为”制片厂”。另外，当某天节点逻辑复杂到画布难以维护时，把这一套翻译成自写 Python 脚本（ComfyUI 的 API 完全支持脚本化调用）是自然的演进路径——编排工具帮你验证了 SOP，脚本只是换个载体执行它。

结语

Dify + ComfyUI 这条流水线，本质上是把漫剧制作从”手工作坊”改造成”标准产线”：故事大纲是原料，分镜 JSON 是在制品的工艺单，ComfyUI 和各类生成服务是机床，交付清单是出厂检验单。搭建它的过程不需要你成为程序员，但需要你像工程师一样思考——先定义数据契约，再设计失败路径，最后才打磨成功路径的体验。把这三件事的顺序摆对，你的自动化流水线就能稳定地在一夜之间，把大纲变成一部部带着音画的漫剧。

THE END