企业官网建设流程全解析

相信很多想做 AI 短视频、AI 漫剧或自制小短剧的朋友，最近都关注到了 MiniMax H3 相关的模型与工作流。网上关于“minimaxh3 上下文长视频工作流”的讨论不少，但资料非常零散，有的讲模型下载、有的讲 ComfyUI 部署、还有的一上来就贴长 JSON 节点图，结果绕了半天还是不知道“上下文”到底怎么串起来。

这篇文章我会从本地视频生成场景出发，完整拆解一套“上下文长视频工作流”的搭建思路，重点解决三个问题：一是如何在 ComfyUI 中加载和使用 MiniMax H3 这类模型；二是多镜头生成时如何保持一致的角色、场景和风格；三是如何把零散的几秒片段拼成逻辑连贯的小短剧。

如果你有一定 ComfyUI 基础，可以直接跳到第 3 节以后看工作流串联；如果你是纯新手，建议按顺序把基本概念过一遍，因为长视频工作流能不能跑通，很多时候不是模型不行，而是工作流设计有问题。

1. 背景与核心概念

1.1 为什么普通工作流生成不了“长视频小短剧”

很多 AI 视频模型单次生成时长都很短，常见的是 4 到 10 秒左右。你要自制一部小短剧，肯定不能只有一两秒的素材，而是需要多个镜头拼接。这里就出现第一个矛盾：模型单次生成能力有限，但短剧需要连续叙事。

有人会想：那我让模型一次生成一分钟不就行了？且不说显存、算力和推理时间是否允许，目前视频生成模型对长时程“剧情”的稳定表达能力还不够，很多模型生成到后半段会出现动作漂移、物体变形、角色“换脸”之类的问题。所以更稳妥的做法不是“让模型硬生成长视频”，而是把长视频拆成多个镜头，再用工作流把上下文一段一段传下去。

MiniMax H3 相关的社区整合包和 ComfyUI 节点之所以受到关注，一方面是因为它本身在多模态内容理解与视频生成上表现不错，另一方面是它可以在 ComfyUI 节点式环境里运行，方便通过不同节点做“前一个镜头结束画面 -> 后一个镜头起始画面”这类上下文传递。这是实现自制小短剧的重要基础。

1.2 什么是“上下文”长视频工作流

在 ComfyUI 这类节点工具里，“上下文”不是一个模糊概念，它具体指代生成每一个镜头时，模型能看到哪些额外信息。

如果你只是生成一个独立镜头，模型获得的上下文可能只有一段 prompt 文字。比如：

深夜便利店，店员站在收银台后，镜头缓缓推近。

这个镜头生成出来后，下一个镜头如果还让同一个店员出现，模型并不知道上一个镜头里这个店员长什么样。结果往往是：镜头 1 里的店员是黑短发，镜头 2 里可能变成了长发，穿的衣服也变了，甚至“性别”都变了。

所谓长视频工作流，就是要把“角色外形”“服装道具”“场景环境”“光线风格”等全局信息固化下来，同时把“上一镜头的尾帧画面”作为下一镜头的参考上下文输入模型。用公式表示：

下一镜头输入 = 全局角色/场景描述 + 上一个镜头尾帧 + 分镜 prompt

当每个镜头都能拿到这些信息时，最终拼接出来的短剧才会有连续感。

1.3 这个工作流适合谁

这篇文章适合下面几类读者：

• 想用 AI 批量制作短视频、短剧或漫剧的个人创作者。
• 已经用过 ComfyUI 文生图、图生视频，但还没理清多镜头串联原理的玩家。
• 需要为公司搭建可复用的“AI 视频生产流水线”的算法工程师或技术运营。
• 想了解 MiniMax H3 这类模型在本地 ComfyUI 中如何调度资源的人。

本文会围绕具体流程展开，涉及较多工程细节，但不会去虚构不存在的模型参数或官方发布信息。实际环境中，不同版本的模型封装、ComfyUI 自定义节点差异较大，我会尽量把思路讲清楚，再给出可调整的代码和配置。

2. 环境准备与版本说明

2.1 硬件要求

长视频工作流比单张图片生成更吃显存，尤其是需要同时加载文本编码器、视频模型和 VAE 的时候。

如果你只是做 480p 左右、5 秒内的小镜头测试，建议显存不低于 16GB；如果要做 720p 或更长片段，建议使用 24GB 及以上显存。显存不足时，可以先降低生成分辨率，例如从 960x544 降到 832x480 甚至 768x432，先把流程跑通，再逐步提升画质。

操作系统方面，Windows 11 和 Ubuntu 22.04 都是常见环境。Windows 上注意显卡驱动和 CUDA 版本配套，Ubuntu 上还需要额外确认 ffmpeg、gcc 等系统依赖是否完整。

2.2 软件环境

ComfyUI 本身是一个基于 Python 的节点式 AI 绘图/视频生成工具。官方推荐使用独立虚拟环境安装，避免和系统 Python 环境冲突。

核心环境大致如下：

Python 3.10 或 3.11 PyTorch 2.x（需根据 CUDA 版本安装） ComfyUI 最新版本或社区整合包 FFmpeg（用于视频拼接与转码）

版本说明：以上版本需要根据你的项目实际情况调整，不同 ComfyUI 版本自带的节点 API 有差异。如果你使用的是秋叶整合包、绘世启动器或其他社区整合包，建议优先按整合包作者给出的 Python 环境来安装缺失依赖，不要随意升级全局 PyTorch，否则可能导致自定义节点不兼容。

2.3 模型目录放置

ComfyUI 加载模型时通常默认扫描ComfyUI/models目录下的子文件夹。如果你下载的是 MiniMax H3 的视频生成模型、VAE 文件和文本编码器，建议按下面的目录结构整理：

ComfyUI/models/ ├── diffusion_models/ │ ├── minimax_h3/ │ │ └── minimax_h3_video_model.safetensors ├── vae/ │ ├── minimax_h3/ │ │ └── minimax_h3_audio_vae_fp32.safetensors ├── clip/ │ ├── minimax_h3/ │ │ └── minimax_h3_text_encoder.safetensors └── custom_nodes/ └── ComfyUI-VideoHelperSuite/

为什么这里要单独强调目录结构？因为很多莫名其妙的报错都是“模型文件放了，但 ComfyUI 扫描不到”。

社区中有一个高频报错长这样：

Value not in list: vae_name: 'minimaxh3\\minimax_h3_audio_vae_fp32.safetensors'

这个报错通常不是模型文件损坏，而是 ComfyUI 的模型列表里根本没找到该文件名。可能原因包括：VAE 文件没有放在正确的目录；自定义节点需要扫描后重启才能刷新列表；模型文件名与节点内置关联不一致。遇到这个报错时，不要急着重新下载模型，先确认路径和文件是否存在，再在节点右侧下拉框中手动重新选择一次。

上面提到的ComfyUI-VideoHelperSuite是社区较常用的视频工具节点集合，主要处理视频加载、帧抽取、视频合并等操作。正式安装时请以你所用 ComfyUI 版本对应的安装说明为准。

2.4 安装缺失的自定义节点

导入别人分享的 ComfyUI 工作流时，经常会看到这样的提示：

请安装缺失的包以使用此工作流。要安装缺失的节点，请先在你的 Python 环境中运行...

这说明工作流在导出时包含了你本地没有安装的自定义节点。处理方式分两步：

第一步，根据工作流 JSON 里的节点类型名，找到对应的自定义节点项目名。

第二步，在 ComfyUI 的custom_nodes目录下执行安装命令。以 ComfyUI 自带的虚拟环境为例：

cd ComfyUI/custom_nodes git clone <节点项目地址> cd <节点项目目录> pip install -r requirements.txt

安装完成后必须重启 ComfyUI，再重新导入工作流。不要装完节点不重启就直接刷新页面，很多节点列表加载是在启动阶段完成的。

3. 核心原理拆解：如何搭建上下文长视频生成链路

3.1 工作流设计本质：从“单镜头生成”到“分镜剧本生产”

搭建上下文长视频工作流时，不要一开始就陷入节点细节。建议先在脑海里把流程抽象成一条流水线：

1. 编剧层：把故事写成结构化的分镜脚本。
2. 全局上下文层：提取角色、场景、灯光、风格等固定信息。
3. 逐镜生成层：每个镜头带着全局上下文 + 参考帧 + 分镜描述去生成片段。
4. 拼接层：将所有片段按镜头顺序合并，并做必要的转场处理。

大多数人在 ComfyUI 里遇到的困难，都是因为把第 2 层和第 4 层忽略了。如果只把分镜 prompt 一排排生成，效果就像 PPT 一样，每页之间没有关联，最终拼出来也不是短剧，而是“连续图片展示”。

所以我建议，无论你最终用哪个具体节点实现，工作流中一定要有独立的“角色信息表”和“场景信息表”。它们的作用是保证每个镜头复用相同的角色外貌描述。

3.2 上下文有几种传递方式

在 ComfyUI 中，上下文传递通常由下面任意一种或几种组合完成。

• 文本上下文：所有镜头共享角色描述、服装描述、场景描述。这是成本最低、最容易实现的一致性约束。
• 图像上下文：将上一镜头的最后一帧作为下一镜头的“起始帧”或“参考图”。许多视频生成模型支持参考图引导，这种方式能显著提升角色一致性。
• 模型级上下文：通过训练 LoRA 或使用角色 embedding 固定人物特征。适合需要大量镜头且人物出现频率极高的短剧项目，但前期训练成本较高。

实际操作中，我的经验是“文本上下文 + 图像上下文”组合起来最实用。文本上下文保证大方向不出错，图像上下文把上一个镜头的空间构图、人脸特征和光影关系带给下一个镜头。

3.3 为什么要把“长剧本”拆成“分镜头 JSON”

如果你只用自然语言把整个短剧文本塞进提示词框，模型会面临两个问题：一是文本过长后容易被无关细节干扰；二是很难按照指定顺序逐镜生成。

考虑到很多朋友也会遇到 LLM Agent 中“上下文用量满了怎么办”的烦恼，视频生成工作流里更要控制“每步需要的信息量”，而不是一股脑把所有描述全部传给视频模型。我们需要把剧本格式化为结构化 JSON，例如：

{ "title": "深夜便利店", "scene": { "environment": "凌晨的便利店，白色日光灯，货架整齐，窗外下着雨", "lighting": "冷白光为主，窗外稍暗", "style": "电影感，自然肤色，35mm 镜头感" }, "characters": [ { "id": "lin", "name": "阿林", "appearance": "黑色短发，红色围裙，胸前有 24H 字样，左眼下方有一颗小痣", "clothes": "便利店员工制服" }, { "id": "guest", "name": "深夜顾客", "appearance": "穿黑色风衣，戴眼镜，头发被雨水打湿", "clothes": "黑色风衣" } ], "shots": [ { "shot_id": 1, "type": "establishing", "description": "雨夜便利店外观，霓虹招牌亮着，门口路灯下有积水倒影。", "duration_sec": 4 }, { "shot_id": 2, "type": "medium", "description": "阿林站在收银台后低头整理关东煮，顾客在玻璃门外收伞。", "dialogue": "（开门铃）欢迎光临。", "duration_sec": 5 }, { "shot_id": 3, "type": "closeup", "description": "阿林抬头看向顾客方向，表情带着一点惊讶。", "dialogue": "你……又加班到这么晚吗？", "duration_sec": 4 } ] }

这样拆分的好处是：每个镜头只需要把scene、characters和当前shot拼接成一段完整提示词，其他镜头的信息不必全部塞进去，大大减少了无用的上下文干扰。

3.4 提示词模板设计

拿到结构化的 JSON 后，还不能直接丢给视频模型，而是要有一套稳定的提示词模板。下面是一个可以调整的基础模板：

[风格]：电影感，写实风格，自然肤色，35mm 镜头感 [场景]：凌晨的便利店，白色日光灯，货架整齐，窗外下着雨 [灯光]：冷白光为主，窗外稍暗 [角色]：阿林，黑色短发，红色围裙，胸前有 24H 字样，左眼下方有一颗小痣，穿着便利店员工制服 [镜头内容]：阿林站在收银台后低头整理关东煮，顾客在玻璃门外收伞 [镜头景别]：中景 [镜头运动]：固定镜头，轻微推近 [时间]：4 秒

为什么要把画面信息拆成固定字段？因为在实际生成中，顺序混乱或字段缺失都可能导致角色特征丢失。如果你的模型是英文效果更好，可以在生成前先把中文模板翻译成英文，但字段结构保持统一，比如Style,Location,Lighting,Character,Action,Camera,Duration。

很多人在生成短剧时容易忽略“镜头运动”。但视频模型对镜头语言非常敏感。如果你在分镜脚本里写“特写”，又在生成时默认为“固定机位”，那最终成品会非常单调。建议分镜脚本里显式标注：

景别：远景 / 全景 / 中景 / 近景 / 特写 运动：固定 / 推近 / 拉远 / 左摇 / 右摇 / 跟随

这组信息是每个镜头 prompt 中很重要的一部分。

4. 完整实战案例：搭建 3 镜头小短剧工作流

4.1 工作流整体节点结构

为了避免直接抄一份不可运行的复杂 JSON，这里用文字 + 节点清单的方式把链路描述清楚。你可以在 ComfyUI 中按下面的顺序连接节点。

第一阶段：脚本装载

Load MiniMax Shot Script

推荐自己写一个简单的 Python 自定义节点，或直接用“文本节点 + JSON 解析节点”替代。该阶段输出每个镜头需要的 prompt、角色描述和输出文件名。

第二阶段：视频生成

MiniMax H3 Model Loader CLIP Text Encode Load Image 或 Load Video（用于读取上一镜头的参考帧/尾帧） MiniMax H3 Video Sampler / Inference Node VAE Decode

第三阶段：结果保存

VideoHelperSuite -> VHS_VideoCombine

保存节点会统一设置fps、format等参数。

整体节点连接思路如下：

1. 读取shot_index = 0的镜头脚本。
2. 把第 0 镜头的 prompt 输入到视频采样器。
3. 因为没有上一镜头，第 0 镜头的参考帧可以用空图或首帧提示词描述图代替。
4. 生成第 0 镜头视频后，保存视频并通过“取尾帧”节点抽出最后一帧图像。
5. 把第 1 镜头的 prompt 和上一镜头尾帧一起输入到视频采样器。
6. 重复执行直到所有镜头生成完毕。

4.2 自定义节点示例：读取分镜脚本

如果你熟悉 ComfyUI 自定义节点开发，可以实现一个简单的MiniMaxShotLoader节点。下面的代码是思路演示，正式使用时需要根据你的节点类型和模型要求适配。

# 文件路径：ComfyUI/custom_nodes/minimax_shot_loader/nodes.py import json class MiniMaxShotLoader: @classmethod def INPUT_TYPES(cls): return { "required": { "script_path": ("STRING", { "default": "script.json", "multiline": False }), "shot_index": ("INT", { "default": 0, "min": 0, "max": 9999, "step": 1 }) } } RETURN_TYPES = ("STRING", "STRING", "STRING", "STRING") RETURN_NAMES = ("shot_prompt", "global_context", "character_info", "output_name") FUNCTION = "load_shot" CATEGORY = "MiniMaxH3/Shot" def load_shot(self, script_path, shot_index): with open(script_path, "r", encoding="utf-8") as f: script = json.load(f) scene = script["scene"] characters = script["characters"] shot = script["shots"][shot_index] global_context = ( f"环境: {scene['environment']}; " f"灯光: {scene['lighting']}; " f"风格: {scene['style']}" ) character_info = "; ".join( f"{c['name']}: {c['appearance']}, 穿着{c['clothes']}" for c in characters ) shot_prompt = ( f"分镜内容: {shot['description']}; " f"景别: {shot['type']}; " f"时长: {shot['duration_sec']}秒" ) output_name = f"shot_{shot_index:03d}.mp4" return shot_prompt, global_context, character_info, output_name

这个节点的作用是帮助你管理镜头脚本，避免手动复制粘贴错角色描述。加载后，ComfyUI 上会多出一组字符串输出，你可以直接把它们连到提示词拼接节点或视频采样器。

4.3 提示词拼接节点示例

ComfyUI 原生自带一些文本拼接节点，如果你不想再写一个自定义节点，也可以使用 ComfyUI 的Text Concatenate节点。但长视频项目里，我更推荐自己维护一个“字段模板”，防止某次修改漏掉characters字段。

下面继续用 Python 自定义节点演示：

class MiniMaxPromptBuilder: @classmethod def INPUT_TYPES(cls): return { "required": { "global_context": ("STRING", {"forceInput": True}), "character_info": ("STRING", {"forceInput": True}), "shot_prompt": ("STRING", {"forceInput": True}), "resolution": ("STRING", {"default": "832x480"}), "fps": ("INT", {"default": 24, "min": 8, "max": 60}) } } RETURN_TYPES = ("STRING",) RETURN_NAMES = ("final_prompt",) FUNCTION = "build" CATEGORY = "MiniMaxH3/Prompt" def build(self, global_context, character_info, shot_prompt, resolution, fps): final_prompt = "\n".join([ "[全局场景]" + global_context, "[角色信息]" + character_info, "[本镜任务]" + shot_prompt, "[画幅]" + resolution, "[帧率]" + str(fps) + "fps", ]) return (final_prompt,)

有些模型对纯文本 prompt 中的换行敏感，如果你遇到模型忽略 prompt 后段内容的情况，可以把换行改成逗号分隔，也可以全部转成英文。小结：提示词拼接节点的职责是“按模板组装”，不要在这个节点里做复杂逻辑。

4.4 参考帧上下文节点：取上一镜头尾帧

在 ComfyUI 中，如果使用 VideoHelperSuite，你可以生成视频后，用VHS_VideoInfo获取视频帧信息，再用VHS_VideoPatch或帧采样节点取出尾帧。

一个简单思路是：保存视频时同时把最后一帧导出为 PNG 图片，路径统一为reference_frames/shot_000.png。下一个镜头读取这个 PNG 作为图片参考。

如果你用的是图生视频模型节点，那么通常会有一个reference_image或start_image输入口。把 PNG 图片接入这个输入口，就能实现跨镜头的图像上下文传递。

4.5 生成第 0 个镜头

对于全剧的第 0 个镜头，没有上一镜头尾帧引用。此时可以：

• 使用空的灰度图或纯黑图作为首帧。
• 使用剧本第 0 镜头的“关键画面描述”先生成一张静态图，再把静态图作为视频生成的首帧。

我通常偏向第二种方式，因为空首帧会让初始画面存在随机性。尤其是短剧第一个镜头往往是环境空镜或主角登场，先确定首帧画面，再生成视频，能减少不必要的返工。

4.6 逐镜生成与上下文传递流程

实际操作时，如果你不想频繁修改shot_index参数，可以在 ComfyUI 外部写一个 Python 脚本，通过调用 ComfyUI API 批量提交不同参数。下面的示例代码展示如何按镜头顺序循环提交工作流：

# 文件路径：run_short_drama.py import json import requests COMFYUI_API_URL = "http://127.0.0.1:8188/prompt" workflow = json.load(open("workflow_api.json", encoding="utf-8")) for shot_index in range(3): shot_node_id = "5" # 替换为你工作流中 MiniMaxShotLoader 节点的 id workflow[shot_node_id]["inputs"]["shot_index"] = shot_index if shot_index > 0: reference_node_id = "12" # 假设 reference 已经从上一镜头输出图更新 workflow[reference_node_id]["inputs"]["image"] = ( f"reference_frames/shot_{shot_index - 1:03d}.png" ) response = requests.post(COMFYUI_API_URL, json={"prompt": workflow}) print(f"submit shot {shot_index}, response: {response.text}")

这个脚本只是一个批处理示例。由于不同工作流的节点 id 完全不同，你需要先打开 ComfyUI 的“开发者模式”，导出 API 格式的 workflow JSON，再根据节点实际 id 修改。

4.7 拼接与后处理

所有镜头生成完成后，你可以用 FFmpeg 做简单的顺序拼接：

ffmpeg -f concat -safe 0 -i filelist.txt -c copy output.mp4

其中filelist.txt内容如下：

file 'outputs/shot_000.mp4' file 'outputs/shot_001.mp4' file 'outputs/shot_002.mp4'

如果每段视频的编码参数不同，直接 concat 可能失败，此时可以统一转成相同编码后再拼接：

ffmpeg -i shot_000.mp4 -c:v libx264 -r 24 -pix_fmt yuv420p tmp_000.mp4 ffmpeg -i shot_001.mp4 -c:v libx264 -r 24 -pix_fmt yuv420p tmp_001.mp4 ffmpeg -i shot_002.mp4 -c:v libx264 -r 24 -pix_fmt yuv420p tmp_002.mp4

然后再使用 concat 方式拼接。

如果你希望镜头之间带有淡入淡出或交叉溶解效果，可以加入xfade滤镜。但要注意，滤镜会重新编码整个视频，耗时较长。对短剧草稿而言，先硬切看节奏，等剧情确认后再做转场可能效率更高。

5. 常见问题与排查思路

5.1 常见报错速查表

5.2 “生成上下文不生效”怎么排查

这是自制短剧时最容易出错的地方。

首先，查看你的提示词拼接节点。你可以在工作流里加一个文本显示节点，把最终传给模型的final_prompt打印出来，确认角色信息确实拼接进去了。

其次，查看参考图路径。如果你手动指定了上一镜头的参考图，请确认文件存在且不是上一版本的旧图。很多“上下文不生效”是因为参考图路径写错了，模型实际拿到的是一个随机噪声图或空图。

最后，有的视频生成模型并不支持参考图强约束，它只是把参考图当作一种风格提示。遇到这种情况时，可以考虑用 LoRA 锁定角色。这也是为什么长视频项目里，如果角色出现频率很高，建议额外训练一个角色 LoRA。

5.3 不建议盲目叠加“深度控制”以外的额外节点

很多新手看到别人工作流里有一堆 ControlNet、IPAdapter，就也跟着全部叠加，结果视频生成速度慢到无法接受，还容易出现互相冲突。

ControlNet 类节点适合控制构图、姿势、边缘，但如果只是短剧里比较简单的“收银台前整理东西”这类动作，不一定需要 ControlNet。上下文参考帧已经提供了足够的构图约束。我的建议是：先跑通最简工作流，确认上下文链路有效后，再逐步添加辅助控制节点。

6. 最佳实践与工程建议

6.1 建立“角色卡”和“场景卡”文件

在一个长期更新的短剧项目中，不要只在 prompt 里写中文描述，建议单独建立一个项目目录：

my_short_drama/ ├── script/ │ └── drama.json ├── prompts/ │ ├── characters.md │ ├── scene.md │ └── style.md ├── reference_frames/ ├── outputs/ └── workflows/

characters.md记录每个角色的长相特征、服装、口头禅、性格标签。生成每个镜头时，都从这些文件读取，而不是临时在 ComfyUI 里改文字。这样可以防止你改了一个镜头的 prompt，后面所有镜头角色跟着漂移。

6.2 先固定风格语言

如果你确定要做“电影感写实”风格，所有镜头都要用同一组风格词，比如：

cinematic lighting, realistic skin, natural color, 35mm lens

不要在第 1 个镜头写 “写实”，第 2 个镜头写 “realistic”，第 3 个镜头写 “照片级真实”。中英文混用往往不是问题，但如果风格描述不一致，模型对风格的理解会产生波动。

6.3 使用 Seed 控制的技巧

视频生成中的seed是一个容易被忽略的上下文参数。

• 每个镜头独立生成时，不同 seed 会导致镜头间画面构图差异变大。
• 如果你希望镜头整体色调接近，可以固定多个镜头使用同一全局 seed，再通过修改 prompt 中的动作描述来产生内容变化。
• 如果一个镜头的画面很好但动作不对，可以固定 seed，只微调 prompt，而不是完全随机重跑。

对于批量出片，建议把 seed 记录到文件名中，例如：

shot_001_seed_12345678.mp4

这样方便排查“为什么同一个 prompt，两次生成差异巨大”的问题。

6.4 小步验证：先出 3 秒测试，不要一口气跑长片段

长视频工作流的预算消耗是很高的。如果你是第一次搭建，不要直接跑 10 秒或 15 秒片段。建议先做如下测试矩阵：

1. 单镜头生成：分辨率 832x480，3 秒，1 个角色。验证模型加载和基础生成是否正常。
2. 两镜头串联：第 0 镜生成后取尾帧，第 1 镜用尾帧+角色卡生成。验证上下文传递是否有效。
3. 三镜头连贯测试：验证生成时间和角色一致率。
4. 全片批量生成：确认脚本循环逻辑无误后，再批量跑全片。

这个顺序能帮你把“工具链问题”和“剧本/提示词问题”分开。如果两镜头串联时角色不一致，先不要急着改剧本，而应该检查角色卡或参考帧是否生效。

6.5 注意安全合规与版权边界

最后也是非常重要的一点：AI 视频生成工具不要用来制作违背法律法规、侵犯肖像权或包含不良导向的内容。涉及真实人物肖像的短视频项目，务必要获得授权；涉及品牌商标的，也要谨慎使用。企业项目尤其要注意模型许可协议，不要在未确认商用条款的情况下直接用于商业发行。

另外，批量生成会产生大量素材文件。建议定期清理临时帧、失败输出，保留有代表性的样片和最终成片。磁盘空间不足往往是长视频项目容易踩的坑，一个 3 秒 480p 视频可能在几十 MB 到几百 MB 不等，如果反复生成几十次，占用空间会上升得很快。

7. 总结与后续行动

这篇文章的核心不是告诉你某一条具体节点线，而是帮你建立一个可复用、可排查的上下文长视频工作流框架。

你要记住的关键点有三个：第一，不要试图让模型一口气生成长视频，而是做分镜式生产；第二，每个镜头都携带全局角色/场景/风格上下文，并通过上一镜头尾帧进行图像上下文衔接；第三，工作流要能基于结构化 JSON 批量执行，而不是每次手动复制 prompt。

对你自己的项目而言，最值得马上去做的事情是：只拿一个 3 分钟都能看完的超短剧情，先写一个包含 3 到 5 个镜头的 JSON 脚本，然后去 ComfyUI 里把最简链路跑通。不要一开始就挂一堆 ControlNet、IPAdapter 或复杂转场逻辑。链路通了之后，再逐渐增加角色 LoRA、多分支动作生成和配音。

如果本文对你有帮助，可以顺手收藏备用。你在搭建 MiniMax H3 或类似视频生成模型的长视频工作流时遇到什么坑，欢迎在评论区把报错和你的节点截图发出来，大家一起排查，效率会比一个人翻 issue 高很多。