企业官网建设流程全解析

在 ComfyUI 里做 AI 视频生成，模型选择已经不只是“能不能生成”的问题，而是生成速度、可控性、参数量以及后处理链路怎么配合的问题。MiniMax H3 是社区近期比较关注的视频生成模型，配合 Turbo LoRA 可以把采样步数压缩到 4 步左右，再利用 LTX 高清放大工作流补足分辨率和平滑度，整套流程从输入分镜到导出成片，等待时间会明显缩短。这里按一条主线来拆解：先理解 MiniMax H3 和 Turbo LoRA 的配合原理，再梳理本地部署环境，然后逐步搭出一套“AI 自动写分镜 + MiniMax H3 极速生成 + LTX 高清放大”的 ComfyUI 工作流，最后用表格和排查清单处理最常见的报错。

1. MiniMax H3 和 Turbo LoRA 在视频生成链路里各自扮演什么角色

1.1 MiniMax H3 是生成器，不是万能的输出器

MiniMax H3 属于文本生成视频模型，输入是一段提示词，输出是一段连续视频序列。它的核心能力是理解“主体、动作、场景、镜头运动”这些语义，并把这些语义变成画面帧。在本地 ComfyUI 环境中，H3 的基础权重被加载到 Checkpoint 节点里，之后所有文本编码、参考图引导和采样去噪都围绕这套权重展开。

要注意，H3 本身决定的是内容质量，比如角色动作是否合理、镜头是否有运动感、画面是否接近真实光影。它不负责把分辨率无限拉高，也不负责把抖动抹平。很多初次使用的人误以为换一个更强的生成模型就等于拿到一条成品视频，实际上视频生成链路里还有采样步数、LoRA 强度、参考图权重、最后放大策略等多个变量共同影响结果。MiniMax H3 在其中扮演的是“负责语义和画面生成的基座模型”，后续的 Turbo LoRA 和 LTX 放大都是在它的输出之上做调整。

所以在搭建工作流之前，先建立一条认知：MiniMax H3 决定镜头里有什么，Turbo LoRA 决定生成要多快，LTX 高清放大决定输出画面有多锐。

1.2 Turbo LoRA 为什么能把采样步数压到 4 步

扩散模型生成视频时，通常需要经过几十次去噪迭代，每次迭代都在把带噪的隐空间向量逐步还原成清晰图像。步数越高，生成效果越完整，但推理耗时也线性增加。Turbo LoRA 的做法是在原模型权重基础上叠加一组经过蒸馏后的低秩适应矩阵，让模型在少量时间步内就能完成从噪声到清晰画面的映射。实际工作流里，配合 Turbo LoRA 之后采样步数可以降到 4 步左右，这就是“极速生成”的来源。

但 4 步不是随便设置的。它只有在模型权重、LoRA、采样器、调度器都匹配的情况下才有效。如果只把步数改小，不加载对应的 Turbo LoRA，画面会残留大量噪声，看起来像“没有清理干净的雪花点”。反过来，如果加载了 Turbo LoRA 却仍然使用 30 步采样，虽然不会报错，但画面可能会过曝或发灰，因为模型已经被蒸馏到适合短步数的状态，拉长步数反而破坏原有时间步分布。

另外，CFG（无分类器引导强度）也要跟着调。常见配合 Turbo LoRA 的工作流会使用接近 1.0 的 CFG 值，因为蒸馏后的模型更依赖自身语义理解，过高的 CFG 会放大噪声和伪影。不同采样器对 4 步采样的适应程度也不一样，社区工作流中常见的是 DPM++ 或 Euler 系列搭配对应调度器。实际部署时，如果报错或画面异常，优先检查这三个参数：步数、CFG、采样器。

1.3 为什么要再加 LTX 高清放大

MiniMax H3 在低步数、低分辨率下生成速度快，但画面细节可能不够，比如边缘轮廓发糊、背景纹理丢失、人物面部不够立体。LTX 高清放大工作流解决的是这个“生成之后”的增强问题。它本质上是把视频拆成连续帧，用 LTX 模型对每一帧做超分和修复，再按原帧顺序重新合成视频。

这里容易忽略的是“时序一致性”。如果只是对单帧逐张放大，帧与帧之间会出现亮度突变、纹理跳动，最终成片看起来像放大器在“呼吸”。所以实用的 LTX 放大工作流会引入面部锁定或参考帧校准，用首帧或指定参考帧的特征约束后续帧，防止放大过程中把角色脸改变形。社区中常说的“LTX 2.3 面部锁定”就是指这个组件，它的作用不是放大本身，而是让放大后的脸部保持连续。

因此，MiniMax H3、Turbo LoRA、LTX 放大三者形成的是一个流水线：H3 负责内容生成，Turbo LoRA 负责让内容快速出来，LTX 负责把快速生成带来的画质缺口补上。

2. 本地部署前先对齐环境，否则后面工作流跑不起来

2.1 硬件要求与运行模式

本地部署视频生成模型，第一步先确认硬件能承载多少工作量。MiniMax H3 这类模型的推理压力主要在显存和 CUDA 计算单元上，CPU 虽然理论上可以运行，但视频模型需要处理大量连续帧，CPU 推理速度会慢到几乎不可用。热搜里经常有人问“能不能在 AMD CPU 上部署”，结论很明确：可以尝试，但不推荐作为主力运行方式。AMD 平台还需要额外确认 PyTorch 的 ROCm 版本是否支持当前显卡驱动，部署成本会高出不少。

建议按用途划分硬件要求：

“显存 8GB 能不能跑”取决于输入分辨率和帧数。把分辨率降到 640x360、长度控制在几十帧，8GB 是可以尝试的。但要注意，生成完还要交给 LTX 放大，放大阶段同样需要显存，所以显存规划要按整条工作流算，而不是只看生成节点。

2.2 ComfyUI 与自定义节点安装

ComfyUI 的安装路径比较多，原版项目、第三方整合包、系统级软件包都存在。这里推荐从 ComfyUI 的官方仓库开始，因为它能保证 Python 环境、依赖版本和插件兼容性更容易控制。下载解压后，用main.py启动，启动脚本会自动检查依赖。

视频生成工作流通常需要以下自定义节点类别：

• ComfyUI-Manager：统一管理缺失节点、模型资源、节点更新。
• ComfyUI-VideoHelperSuite（VHS）：处理视频加载、抽帧、合成、预览，是视频工作流的基础组件。
• 文本生成或 LLM 相关节点：用于接入 AI 自动写分镜，可以是本地 Ollama，也可以是远程模型服务。
• Turbo LoRA 加载相关节点：不同的工作流封装方式不同，有的直接使用 LoRA Loader，有的是组合节点。
• LTX 放大相关节点：用于对视频流逐帧放大和重建。
• 参考图或人脸锁定相关节点：用于多镜头角色一致性控制。

安装时不要一次性把搜索到的所有节点都装上。很多报错来自“节点 A 依赖节点 B，但没装 B”，Chaining 安装反而会引入版本冲突。最稳妥的做法是：先安装 ComfyUI-Manager，导入工作流 JSON 后，让 Manager 读取缺失节点列表，再按提示逐个安装。

2.3 模型文件放在哪里

ComfyUI 对模型文件路径有约定。传统 checkpoint 模型放在models/checkpoints，LoRA 放在models/loras，文本编码器放在models/clip，视频处理中间文件可以放在output目录下由工作流生成。工作流 JSON 中引用的是相对路径，例如models/checkpoints/minimax-h3-turbo.safetensors。

常见目录结构参考：

ComfyUI/ ├── main.py ├── models/ │ ├── checkpoints/ │ │ └── minimax-h3-turbo.safetensors │ ├── loras/ │ │ └── minimax-h3-turbo-lora.safetensors │ ├── clip/ │ │ └── ... 相关文本编码器文件 │ └── vae/ │ └── ... 视频 VAE 文件 ├── custom_nodes/ │ ├── ComfyUI-Manager/ │ └── ComfyUI-VideoHelperSuite/ └── output/ └── video_results/

不同来源的模型文件名可能不同，实际下载时要以模型仓库给出的清单为准。第一次启动 ComfyUI 后，Console 窗口会列出当前识别到的模型数量，如果某个模型没有被识别到，先检查文件是否放在正确目录，再检查文件是否完整。下载中断产生的不完整.safetensors文件不会在启动时报错，但加载时会直接失败。

2.4 环境准备检查清单

在导入复杂工作流之前，先跑一次最小验证：打开 ComfyUI 页面，加载一个基础 checkpoint，用默认的KSampler生成一张图片，确认 GPU 推理通路正常。这个检查能提前发现驱动、PyTorch、CUDA 三层问题，避免把环境问题误判成工作流问题。

可复用的环境检查清单：

• GPU 驱动是否正常，nvidia-smi能显示型号和显存。
• PyTorch 是否是 CUDA 版本，Python 中执行torch.cuda.is_available()应为True。
• ComfyUI 启动日志是否显示模型加载成功。
• ComfyUI-Manager 是否安装并能打开。
• VideoHelperSuite 是否包含视频合成所需的后端依赖，例如imageio-ffmpeg。
• 模型文件是否完整，LoRA 文件是否和 checkpoint 版本匹配。
• 输出目录是否有写入权限。

3. 搭建一条主工作流：AI 写分镜，MiniMax H3 生成，LTX 放大

3.1 工作流整体数据流

一条完整的“AI 自动写分镜 + MiniMax H3 + LTX 放大”工作流，节点数量通常在 20 个以上。直接从一个复杂的 JSON 起步容易迷失，正确做法是先理解数据流，再看每个节点负责什么。

数据流可以概括为：

主题文本 ↓ LLM 分镜节点（自动生成分镜 JSON） ↓ 分镜解析节点（逐镜头读取描述、时长、运动方式） ↓ 文本编码 + Ref2VA 参考图条件 ↓ MiniMax H3 Checkpoint + Turbo LoRA ↓ 采样器（4 步，低 CFG） ↓ 视频解码节点 ↓ LTX 高清放大节点 + 面部锁定 ↓ 视频合成与导出

这个链路和传统 ComfyUI 出图工作流最大的不同是：它多了一个“分镜 JSON”中间层。没有这个中间层，AI 只能生成单个镜头；有了它，整条视频可以拆成多个镜头，每个镜头用不同提示词和参考帧生成，最后拼接成片。

3.2 第一步：接入 AI 自动写分镜节点

ComfyUI 本身不内置“写分镜”功能，需要接入 LLM 节点。常见做法是安装支持 Ollama 或兼容 OpenAI API 格式的文本生成节点，在节点里配置模型名称和地址。

分镜节点需要“结构化输出”。不要让模型输出一大段散文，而是要求它输出 JSON 数组。JSON 的好处是后续节点可以按字段取值，比如遍历每个镜头的scene_desc作为正片提示词，读取duration_frames控制视频长度。

一个可参考的分镜生成 Prompt：

你是一名短视频导演。请根据主题生成一段 5 个镜头左右的分镜脚本。 输出格式必须是 JSON 数组，不要包含其他文字。每个元素包含以下字段： shot_no：镜头序号 scene_desc：画面内容描述，包含主体、动作、场景 camera_move：镜头运动方式，如固定、推近、拉远、左摇、右摇 duration_frames：帧数，按 24 帧每秒计算 emotion：情绪氛围 ref_frame：参考帧说明，布尔值，是否引用上一镜头尾帧 主题：一只猫在夜里穿过霓虹街道

实际输出可能有多余的json标记或注释，分镜解析节点需要做一次清洗。很多出错的场景不是模型写不出来，而是模型把 JSON 和解释文字混在一起，导致解析失败。

3.3 第二步：把分镜 JSON 转换成逐镜提示词

拿到分镜 JSON 之后，工作流需要遍历每个镜头，把它转换成一串 MiniMax H3 能理解的提示词。这个转换可以在工作流内置的脚本节点里完成，也可以用外部 Python 预处理，取决于你的工作流封装方式。

下面是一段示意性的 Python 解析逻辑，用于说明字段如何组合成提示词：

import json storyboard = json.loads(raw_storyboard_json) for shot in storyboard: prompt_parts = [] prompt_parts.append(shot["subject"]) prompt_parts.append(shot["action"]) prompt_parts.append(shot["scene_desc"]) prompt_parts.append(f"镜头运动：{shot['camera_move']}") prompt_parts.append(f"情绪氛围：{shot['emotion']}") # 如果该镜头需要参考上一镜尾帧，则拼接参考帧信息 if shot.get("ref_frame"): prompt_parts.append("保持与参考帧中角色和场景一致") final_prompt = "，".join(prompt_parts) print(f"Shot {shot['shot_no']}: {final_prompt}")

这里的关键是“组合语义”，不是简单拼接。画面描述、人物动作、镜头运动要放在固定位置，让模型知道哪段文本描述主体、哪段描述镜头。如果字段顺序忽前忽后，模型会混淆动作主体和背景信息，生成结果容易出现角色漂移。

3.4 第三步：MiniMax H3 视频生成节点

MiniMax H3 节点接收以下输入：

• 文本编码器产出的 prompt embedding。
• 参考图条件（如果有 Ref2VA 参考模式），通常是图像张量或视频首帧。
• 采样器参数，包括步数、CFG、采样器、调度器。
• LoRA 加载器，将 Turbo LoRA 权重叠加到 H3 权重上。

节点参数中，最影响成片效果的是这一组：

不要一上来就追求 4 步、CFG 1.0 全部照搬。如果当前模型版本和 Turbo LoRA 不是同一个版本，4 步生成结果很可能翻车。建议先用默认参数跑一个镜头，确认画面稳定后，再逐步把步数降到 4，观察画面是否有明显噪声。

3.5 第四步：LTX 高清放大与面部锁定

MiniMax H3 节点输出的是低分辨率视频序列，送到 LTX 放大节点后，LTX 会按帧处理。放大节点一般有scale_factor、tile_size、overlap、denoise几个参数。

LTX 放大容易踩的坑是放大倍数过高。一次性把分辨率放大 2 倍以上，容易产生过度锐化和呆板感。推荐先放大 1.5 倍到 2 倍，再用低强度去噪平滑一次。面部锁定组件则通过参考帧的面部特征约束放大过程中的面部生成，避免“脸被越放越不像”。在分镜式视频中，每个镜头都可以把上一镜头的尾帧作为参考，这样切换镜头后角色外观能保持一致。

4. Ref2VA 全能参考模式与提示词编写规范

4.1 参考模式解决什么问题

多镜头视频最怕角色不一致。MiniMax H3 单镜头生成时，画面里的人物是模型临时绘制的；到第二个镜头，如果不提供任何参考，模型会重新想象一个人物，外观通常对不上。Ref2VA 全能参考模式的作用，就是把某一张图或某一帧作为参考条件，和文本提示一起参与生成，从而约束主体外观、服装、场景风格。

参考模式不是越强越好。参考权重过高，动作会被“锁死”，模型太依赖参考帧导致运动不自然；权重过低，参考帧又起不到作用。实际项目中，先固定参考权重在中位值，再根据第一个镜头的输出微调。观察重点是人物轮廓是否保留、动作是否能自由延展。

4.2 提示词结构模板

MiniMax H3 对提示词的解析并不复杂，但结构清晰能显著提高成功率。推荐按以下顺序组织提示词：

主体 + 外观特征 + 动作 + 场景 + 镜头运动 + 光照 + 风格 + 参考说明

例如：

一个穿红色连帽卫衣的年轻女孩，背对着镜头走在潮湿的夜市街道上， 雨滴落在伞面上，镜头从她身后缓慢推近，霓虹灯光洒在积水路面上， 电影感，浅景深，保持与参考帧中人物和服装一致

这个提示词的优点是每个语义块都有明确分工，模型不会把“镜头推近”理解成人物动作。如果提示词只有一个简单句子，生成结果的随机性会显著增大。

4.3 分镜之间的提示词衔接

分镜脚本里，相邻镜头的提示词不是孤立的。要保证画面连续，后一个镜头的提示词里应该包含对前一个镜头关键信息的引用。下面是一个两镜头示意：

[ { "shot_no": 1, "subject": "一个穿红色连帽卫衣的年轻女孩", "action": "站在十字路口抬头看路灯", "scene_desc": "夜晚街道，霓虹灯光从左侧打来，小雨，地面有积水", "camera_move": "固定镜头", "duration_frames": 48, "emotion": "迷茫", "ref_frame": false }, { "shot_no": 2, "subject": "同一个穿红色连帽卫衣的年轻女孩", "action": "转身向镜头方向走来", "scene_desc": "同样的雨夜街道，霓虹灯光从左侧打来，身后十字路口可见", "camera_move": "缓慢拉远", "duration_frames": 72, "emotion": "坚定", "ref_frame": true } ]

第二个镜头里的“同一个”“同样的雨夜街道”“身后十字路口可见”都是在补充一致性信息，再配合ref_frame: true引用上一镜头尾帧，成片时会比完全独立生成的两个镜头连贯得多。

4.4 提示词编写常见错误

常见的错误写法至少有三类：第一，只写主体不写动作，比如“一个女孩”，模型只能输出任意动作；第二，把镜头运动写在动作里面，比如“镜头跟随女孩”，模型可能误解成女孩自己在运动；第三，提示词过短且过度依赖负面提示词，视频模型对负面提示词的支持和图像模型不同，不能假设所有节点都会正确解析负面词。

推荐做法是把“镜头运动”单独提出来，放在提示词后半段，并为每个镜头准备 15 到 30 个词的基础描述。段落太长也不好，核心信息会被淹没。

5. 跑通后如何验证生成结果

5.1 预期输出

完成工作流搭建后，先不要追求完美成片，而是验证“链路是否通”。预期结果可以用一张表描述：

如果某个阶段没有达到预期，不要跳到下一步去改，先定位是上游问题还是下游问题。比如角色不一致，可能是参考帧权重问题，也可能是分镜 JSON 里缺少一致性描述。

5.2 日志与错误信息怎么看

视频工作流出错时，ComfyUI 的 Console 窗口和浏览器界面的红色提示会给出最直接的线索。常见关键字：

• model not found：模型路径错误或文件不存在。
• OutOfMemoryError：显存不足。
• missing nodes：工作流引用了未安装的节点，通常后面会列出节点名。
• cannot import name：自定义节点依赖项冲突。
• prompt executed in xxx seconds：说明整条图执行成功。

看到报错不要马上改代码。先按顺序检查：缺节点 → 缺模型文件 → 参数不匹配 → 显存不足 → 提示词问题。大多数 ComfyUI 视频工作流跑不通，都不是模型能力问题，而是节点环境问题。

5.3 质量检查清单

成片质量检查建议按这个顺序过一遍：

• 每个镜头是否都能找到对应分镜描述，有没有出现镜头内容完全偏移。
• 动作是否自然，有没有撕裂、瞬移、穿模。
• 人物和场景风格是否全片一致，尤其是不同镜头之间。
• 脸部是否稳定，放大后有没有“换脸”或过度锐化。
• 镜头之间衔接时，运动方向和构图是否连贯。
• 音频如果有，是否跟镜头时间轴对得上（如果工作流包含 TTS 或配音节点）。

这个清单也可以作为团队协作时的验收依据，避免你只说“效果不对”，却说不出是哪一层的问题。

6. 常见问题与排查链路

6.1 报错“请安装缺失的包以使用此工作流”

这是导入别人工作流时最常看到的提示。完整信息通常是：“请安装缺失的包以使用此工作流。要安装缺失的节点，请先在你的 Python 环境中运行……”

这个错误的本质是：工作流 JSON 里引用了一个当前环境不存在的自定义节点。排查顺序：

1. 把报错信息里的节点名复制出来，去 GitHub 或 ComfyUI-Manager 查找真正对应的仓库，不要直接搜一个相似名字就装。
2. 打开 ComfyUI-Manager，选择 “Install Missing Custom Nodes”，让它扫描当前工作流缺什么。
3. 安装后重启 ComfyUI，Console 窗口重新加载节点。
4. 如果节点手动安装过但仍然报错，检查是否装到了错误的 Python 环境。用整合包启动时，ComfyUI 使用的 Python 环境通常位于安装目录下，不是系统全局 Python。

预防方式：别人分享的工作流 JSON 只包含节点引用和参数，不包含运行环境。导入前先看工作流描述里有没有列出依赖清单，没有就一步步安装，不要一次装完整包。

6.2 CUDA 显存不足

现象是生成到一半报torch.cuda.OutOfMemoryError。常见原因有三个：分辨率太高、视频帧数太长、LTX 放大阶段显存峰值超限。视频生成的显存占用不是线性增长，采样和放大都可能瞬间拉起大量显存。

处理优先级从低到高：

• 把 batch_size 改回 1。
• 降低 width 和 height。
• 缩短单镜头的duration_frames。
• 打开模型 offload，让不再使用的节点释放显存。
• 在 LTX 放大节点中减少 tile 尺寸。
• 使用 bf16 或 fp16 精度，如果当前节点支持。

不要一上来就换 GPU，先观察是哪一步峰值最高。

6.3 4 步生成画面偏灰或噪声重

现象是所有镜头都生成了，但画面像蒙了一层雾，人物边缘有一圈噪点。绝大多数原因是 Turbo LoRA 没有真正生效，或者参数不匹配。

检查项：

• LoRA Loader 是否连接到了 H3 checkpoint 之后。
• lora_strength 是否过低，建议先在 0.8 左右测试。
• CFG 是否太高，尝试降到 1.0 到 1.5。
• 采样器和调度器是否和模型推荐一致，4 步采样对采样器选择比 30 步更敏感。
• checkpoint 版本是否和 LoRA 版本相同，跨版本叠加 LoRA 往往出现怪异纹理。

按“参数匹配 > LoRA 加载 > 采样器选择”顺序排查，大概率能定位问题。

6.4 多镜头角色不一致

分镜工作流最常见的失败模式是“每个镜头都好看，但不像同一个人”。原因包括：分镜 JSON 中缺少一致性描述，Ref2VA 参考权重太低，或者没有传入上一镜头的参考帧。

处理建议：

• 在提示词中明确写“同一个角色”“服装和发型一致”。
• 打开 Ref2VA 参考模式，并把第一镜头的尾帧传给第二镜头作为参考。
• 适当提高参考条件权重，但不要一次拉满，以 0.05 为步长调试。
• 如果角色是现实人物，考虑在放大阶段加入面部锁定，强化面部特征。

角色一致性不是单个节点的能力，而是提示词、参考帧、放大三个环节共同作用的结果，单独调整某一环往往不够。

6.5 LTX 放大后视频抖动或脸部变形

放大后画面抖动，说明放大过程没有保持时序一致性。常见原因是放大时逐帧独立处理，忽略了上一帧和下一帧的关系。

处理方式：

• 降低放大倍数，先用 1.5 倍测试。
• 增大放大节点的 overlap 重叠区域，让相邻帧之间有更多重合信息。
• 启用面部锁定或参考帧约束。
• 对放大后的序列做一次轻微去噪，平滑帧间抖动。
• 如果问题仍然存在，把视频拆成多段分别放大，再拼接，而不是整段一次性放大。

7. 生产环境使用建议与可复用清单

7.1 学习环境与生产环境的差别

学习环境里，能跑通就是成功。生产环境里，还需要考虑批量任务稳定性、参数可回滚、日志可追踪、模型版本可复现。两者的差别可以用一张表概括：

生产环境里，模型升级是最危险的操作。某个节点的更新可能不兼容现有工作流 JSON，升级后全部批量任务从“能跑”变成“报缺节点”。建议把工作流 JSON、节点版本、模型文件三者锁定为一个版本组，发布前先在小批量上验证。

7.2 参数配置外置

视频工作流的参数非常多，不建议把分辨率、步数、CFG、LoRA 路径写死在节点里。可以把它们集中到一个配置文件中，例如：

{ "model": { "checkpoint": "models/checkpoints/minimax-h3-turbo.safetensors", "lora": "models/loras/minimax-h3-turbo-lora.safetensors", "lora_strength": 0.8 }, "sampling": { "steps": 4, "cfg": 1.0, "sampler": "dpmpp_2m", "scheduler": "karras" }, "video": { "width": 640, "height": 360, "fps": 24, "max_frames": 72 }, "ltx": { "scale_factor": 1.5, "tile_size": 512, "overlap": 8, "face_lock": true }, "output_dir": "output/video_results" }

这样每次批量生成都附带一份参数记录，排错时能清楚知道当前结果是由哪组参数产生的。同时这也为将来 API 化调用留下基础。

7.3 上线前检查清单

以下内容可以直接复制为日常操作的检查清单：

• 模型文件和 LoRA 文件已放入正确目录，校验大小符合预期。
• 工作流 JSON 中没有缺失节点提示。
• 先用单镜头跑通，确认 MiniMax H3 能输出视频。
• 再验证 4 步采样是否真的无噪声，必要时调回更高步数。
• 检查 Ref2VA 参考模式下多镜头角色是否一致。
• LTX 放大后无抖动和脸部变形。
• 输出目录命名规范，包含任务 ID 和时间戳。
• 参数配置文件随任务一起归档。
• 显存峰值记录下来，避免批量任务叠加时 OOM。
• 记录 ComfyUI 和关键自定节点版本，方便回滚。

7.4 扩展方向

这条工作流还可以继续扩展。比如把分段生成的多个镜头通过视频合成节点拼接，加入转场效果；把 TTS 生成的旁白和字幕与镜头对齐；把整个流程封装成 API，在前端输入主题后自动返回成片；也可以把分镜 JSON 存入数据库，形成可复用的素材库。

对新手的练习建议是：先从单一镜头跑通 MiniMax H3 + Turbo LoRA，确认速度达到预期；再手动编写两个镜头的 JSON，验证参考帧衔接；最后才接入 AI 写分镜节点。分镜自动化和视频生成是两套系统，混在一起调试时很难判断问题出在哪一端。一次只引入一个变量，这是排查复杂工作流最有效的方式。