qishizhe/ai-series-comfyui-handbook

Fork 0

Files

T

qishizhe 9eef175633 docs: add video route selection and verified ComfyUI workflow tutorials

2026-10-29 15:06:10 +08:00

13 KiB

Raw Permalink Blame History

16｜现有工作流拆解与搭建练习

返回知识库目录 · 生成方式选择 · 工作流搭建与排错

本章用你已有项目说明“画面意图如何落到节点和连线”。案例是《明天的来电》的 S01 图生视频图，以及较早项目中的 Wan 5B 研究图。本轮只读检查，不提交渲染、不修改旧项目工作流。

资料核查：2026-10-29。服务器当时可访问，报告 ComfyUI 0.39.0；这些是本次环境快照，不是其他机器的安装要求。

1. 先把四种“验证通过”分开

层级	本例的证据	能说明什么	不能说明什么
文件与历史	S01 保存 API 与历史真正执行的图完全相等；记录为 success、completed=true	这份图确实曾被成功执行	当前所有依赖仍与当时完全一致
当前节点接口	对16个节点逐个核对实时 schema，必填输入与引用输出类型未发现错误	当前节点存在，接线声明相容	张量尺寸、数值稳定性和内容质量一定正确
当前模型列表	本例5个模型或 LoRA 文件均在对应 loader 的可选列表中	文件名当前可被 loader 识别	每种量化、LoRA组合或硬件执行都已重新测试
本轮实际生成	未提交新任务	本章没有消耗一轮新生成来证明效果	原参考图片现在仍可加载、任意新尺寸都能成功

具体节点、连线、模型与验证边界保存在工作流接口核对.json。它是审计记录，不是可以直接提交的工作流。

2. 实际文件在哪里

下列链接指向制作电脑上的原项目，不随这个文档仓库打包；在别的电脑阅读时，需要使用自己的工作流与输入素材。

S01 的 GUI 工作流：打开画布学习16个节点和19条连线。
S01 的 API 工作流：学习程序实际执行的字段与引用。
S01 的执行历史：核对真正执行的图与输出状态。
S01 的作业记录：对应项目的作业状态。

学习时先复制成自己的新版本，再替换首图和镜头描述。原执行文件可以继续作为历史依据。

3. 为什么说这次执行的是图生视频

看这条真实连线：

LoadImage（ID 1，输出0：IMAGE）
  → MiniMaxH3ImageToVideo（ID 104）的 first_frame 输入

首图接入 first_frame，因此本次是首帧 I2V。判断依据是输入职责和实际连线，不是文件名、模型名或工作流标题。本手册所举的 Wan2.2 TI2V-5B 支持文字或图片模式，也不能据此判断某一次执行没有接图。首图提供起始视觉依据，不锁定未见背面、完整三维结构或后续动作时序；转身、环绕和交接仍须审片。

本次接口中，MiniMaxH3ImageToVideo 的必填项是 clip / vae / prompt / width / height / length，first_frame / last_frame 是可选图片输入。接口上的“可选”只描述字段要求；切到另一种模式，还应确认所选权重、模板与整个流程支持该任务。官方提供了不同模式模板，适合用来做准确对照。Comfy H3 官方指南

4. 把16个节点分成六组读

4.1 主模型与加速分支

UNETLoader 6
  → LoraLoaderModelOnly 121
      ├→ BasicGuider 16
      └→ BasicScheduler 9

主模型负责生成，模型专用的 Turbo LoRA 改变这里的 MODEL 流。该图用的是 ModelOnly loader，CLIP 分支没有经过它；不要因为普通图片教程里出现了 LoraLoader，就给这里补一个并不存在的 CLIP 改动。

这份 LoRA 的用途是本项目的加速组合，没有证据说明它是为片中角色训练的身份 LoRA。减少步数必须与对应权重和采样方案相容；不能把“8步”当作随便换模型后仍成立的质量承诺。

4.2 文本、首图与视频潜空间

CLIPLoader 13 ────────────────┐
VAELoader 11（视频VAE）───────┼→ MiniMaxH3ImageToVideo 104
LoadImage 1（首图）───────────┘       ├ 输出0：CONDITIONING → Guider 16
                                      └ 输出1：LATENT → Sampler 14

提示词在104里与所需输入一起处理。它不仅输出条件，也准备带视频时间维度的潜空间；因此普通文生图中一个 EmptyLatentImage 不能不经模型适配地替代这个节点。

4.3 采样器不是一个“神奇黑盒按钮”

ID / 节点	交给采样过程的是什么	本图设置或来源
15 `RandomNoise`	起始噪声	`noise_seed`
16 `BasicGuider`	模型与条件形成的引导	模型来自121，条件来自104输出0
17 `KSamplerSelect`	采样算法对象	`res_multistep`
9 `BasicScheduler`	采样噪声级别序列 SIGMAS	`simple`、8 steps、denoise 1.0
14 `SamplerCustomAdvanced`	综合上述对象处理潜空间	初始 latent 来自104输出1

这里的 BasicGuider 只有模型与 conditioning 输入，没有普通正负提示成对输入。照搬其他模型的“加一个负向分支”并不能自动改善它。要按当前模型官方流程决定负向条件和引导方式。

4.4 一份采样结果，分别解出视频与声音

SamplerCustomAdvanced 14（输出0）
  ├→ VAEDecode 10 + 视频VAE 11 → IMAGE 帧批次 ┐
  └→ VAEDecodeAudio 23 + 音频VAE 24 → AUDIO ─┴→ CreateVideo 91

两个解码器取自同一采样结果，使用各自的 VAE。这里不能把音频 VAE 当作视频 VAE 使用，也不能把视频分支换成普通图片模型的 VAE。更不能把这条联合音视频路径推广为所有视频模型都具备原生音频。

4.5 封装和保存是两个职责

CreateVideo 91（帧、音频、24fps）
  → SaveVideo 92（文件名前缀、容器/编码设置）

CreateVideo 把输入组合成 VIDEO，SaveVideo 才是这个例子中的保存终点。构图、角色一致性与对白质量仍要观看输出，文件存在不代表内容合格。

5. 节点 ID、输出 slot 和参数怎样对应

以下是从本例抽出的教学片段，省略了其余节点，并替换了原提示词；不能单独提交运行：

{
  "104": {
    "class_type": "MiniMaxH3ImageToVideo",
    "inputs": {
      "clip": ["13", 0],
      "vae": ["11", 0],
      "first_frame": ["1", 0],
      "prompt": "这里填写自己的镜头描述",
      "width": 960,
      "height": 544,
      "length": 192
    }
  }
}

"104" 是这个图里的节点 ID，不是所有 H3 图固定使用的编号。
class_type 指具体节点实现，不能随意改成界面中文标题。
["13", 0] 表示13号节点的第0个输出，slot 从0起数。
width: 960 是直接填写的参数，不是连线。
本图104的第0输出是 CONDITIONING，第1输出才是 LATENT。两者如果接反，数字格式看似合法，类型却不相容。

GUI 文件还包含画布坐标、连线、控件与分组。修改 GUI 后，重新导出 API 比按猜测修改 widgets_values 的位置顺序更可靠。模型文件名、输入图与节点版本也要一起记录。Comfy 工作流概念

6. 本例参数只能当作基线记录

项目	该次图内的值	学习时注意
主模型	`minimax_h3_fl2va_pruned_int8_convrot.safetensors`	量化、架构和 loader 兼容需要对应环境验证
加速 LoRA	`minimax_h3_fl2v_turbo_8step_v1.0_comfyui_bf16.safetensors`，strength 1.0	名称和强度都属于这个组合
文本编码器	`qwen3vl_32b_minimax_h3_nvfp4_awq.safetensors`，type=minimax	名字含 CLIP 的 loader 不代表内部一定是传统 CLIP 模型
视频 VAE	`minimax_h3_video_vae_fp16.safetensors`	和音频 VAE 分开
音频 VAE	`minimax_h3_audio_vae_fp32.safetensors`	不替代视频解码器
尺寸 / 帧数	960×544，192帧	不等于最终剪辑输出尺寸；帧数约束按具体模型确定
封装帧率	24fps	192÷24是名义8秒，实际文件时长需媒体探测
采样设置	8步、res_multistep/simple、denoise 1.0	不外推为通用最快配置

改变分辨率、时长、量化或 LoRA 都可能改变内存和数值行为。已经成功过的8秒图，也不能证明任意长片段或多人动作都稳定。

7. 新手照着怎样练搭建

这是练习安排，不会因阅读本章自动排队任务。

先读闭环。 在 GUI 副本里从保存节点逆着线走，找出帧、声音、采样、条件和模型的来源。能回答每条线是什么类型，再动手删改。
替换首图与描述。 在界面上传自己的图片，让 LoadImage 使用服务端实际收到的文件；远程 Linux ComfyUI 不能直接读取 Windows 的 F:/... 路径。
保留已知基线。 起初保持对应模板的模型、编码器、VAE、采样器与调度参数；尺寸和帧数调整也遵守模型限制。
只更改一个创作变量。 比较相同构图下静止、缓慢转头、一次递物等动作，不同时更换模型、首图、运镜、步数和 LoRA。
记录运行与画面。 检查任务完成、文件可播放、时长与声音，并观看关键动作、首尾帧和前后镜连续性。
再添加一项功能。 需要另一种控制时，选择该模型支持的参考、首尾帧或控制模板；需要放大时在输出路径另加明确阶段，分别验证。
保存两个格式与依赖。 画布版用于打开编辑，API版用于程序调用；记录它们对应同一版本。

如果想练纯文生视频，另开官方 T2V 模板，确认未接首帧、尾帧或参考图／视频等视觉输入，且当前路径确为文字驱动，再和 I2V 做同一镜头任务的对照。不要把这份已接首图的图改个文件名就当作 T2V 基线。

8. Wan 5B 的本地参考为什么不能与 H3 混接

本地 Wan 参考 API的路径是：

UNETLoader → ModelSamplingSD3 → KSampler → VAEDecode → VHS_VideoCombine
CLIPLoader → 正向/负向 CLIPTextEncode ────→ KSampler
LoadImage → Wan22ImageToVideoLatent ──────→ KSampler.latent_image
Wan2.2 VAE ───→ 视频 latent 准备与 VAEDecode

这也是 I2V：LoadImage 接到了 start_image。图中使用 Wan2.2 5B、对应的 Wan2.2 VAE，以及 UMT5 编码器；它与 H3 的条件处理、采样组织和音频路径不同。本地保存版使用 VHS 输出，官方当前示例也可采用其他保存节点；不要因输出节点不同就把整个模型链混换。Wan2.2 官方教程

同目录的竖屏候选图仍含 REPLACE_WITH_UPLOAD_RETURNED_PATH.png。它不能原样运行，81帧设置也不能借后来73帧的成片记录冒称已经验证。学习时区分“研究候选”“真实提交图”“成功输出”，保留每一步的证据。

9. 复制前的五个检查问题

这张图实际是文生、首图驱动，还是参考驱动？输入线在哪里？
我想锁定的是身份、首帧、动作还是镜头路线，当前输入方式真的约束了它吗？
模型、编码器、VAE、加速 LoRA、采样路径是否属于兼容的一套？
改图后能从保存终点追到完整输入吗？图片、视频和声音类型是否匹配？
我的“可用”证据到哪一层：只有能打开、接口通过、跑完过，还是已经观看并验收？

10. 依据与边界

原项目 GUI、API、作业和历史文件：本章节点 ID、连线与已执行证据的直接来源。
本轮工作流接口核对：当前节点与模型列表的只读核实，不代表新渲染成功。
Comfy H3 官方指南：模板模式与多模态工作流入口。
Comfy Wan2.2 官方教程：5B 文／图双模式与模型组件的对应关系。
Comfy 工作流概念：节点、类型、连线和保存。

本章没有重分发模型或输入图片，没有新建可直接执行的完整工作流。上面的图示和片段用于教你读懂和搭建；真正运行时，以完整模板、实机接口与自己的素材为准。

13 KiB Raw Permalink Blame History Unescape Escape