尧图网站建设 
1. 背景与核心概念1.1 为什么“长视频短剧”需要新工作流如果你做过几分钟以上的 AI 短剧大概率遇到过这几个问题角色长相不够统一、镜头之间的场景不连贯、人物说完上句后下一句口型对不上、或者生成了几十段素材却因为每段互相独立而无法串成一条完整故事线。传统 AI 视频生成工具往往按“单镜头”工作输入一段文字生成几秒钟的视频。单看每个镜头都不错但放到一条叙事线上就等于“各说各话”。要想做出一条有剧情推进、有场景切换、有人物情绪连续变化的短剧光靠零散单镜头生成是不够的必须把“全局设定”“剧本结构”“人物状态”“上下文衔接”纳入到一个完整流程中。MiniMax H3 这类具备较强长上下文能力的视频生成模型为解决这个问题提供了新思路。它可以在一次工作流中接收更完整的剧情描述、角色设定、镜头变化要求让生成结果不只是一个孤立片段而是能围绕某一段戏的整体语义来生成。换一句话说长上下文让模型从“看一句话拍一个镜头”升级成“看一整场戏拍一段素材”。1.2 MiniMax H3 是什么MiniMax H3 是 MiniMax 系列视频生成方向的一个模型/工具版本它的特点体现在几个方面支持更长文本输入可以一次性把角色设定、分镜描述、台词、氛围要求都放进去。面向视频生成链路输出比传统文本上下文更复杂的多帧内容。可以搭配音频模型使用生成带音效、配音或口型同步的视频素材。社区里也出现了本地 ComfyUI 工作流节点用于部署和调用 H3 模型。在短剧制作场景下它更像是“导演台”而非简单的“单镜头生成器”。你可以把整场戏需要的信息给进去模型在编码阶段就把握上下文相关性最后输出一段相对完整的镜头素材。要注意一点不同版本或者不同接入方式官方 API、云端工作台、本地 ComfyUI对“上下文”的定义略有不同。后面我们会讲到如何在这个差异下做工程设计。1.3 “上下文”和“工作流”在短剧制作中的含义先解释两个容易混淆的词。第一个是“上下文”。在短剧视频工作流里上下文并不仅仅指“把上一段剧本文字拼接到下一段”。它至少包含三层上下文层级内容作用全局上下文故事类型、人物设定、场景总览、美术风格保证所有生成片段处于同一个世界观内场次上下文当前这场戏的起因、目标、人物关系变化保证镜头之间有剧情推进逻辑镜头上下文上一个镜头画面、人物位置、动作方向保证相邻镜头剪辑时不出戏、动作衔接自然第二个是“工作流”。技术圈常说的 workflow可以是一套 API 调用编排也可以是一套节点式可视化流程例如 ComfyUI、Dify、n8n 里的工作流。对于做短剧的人工作流就是把下面这些任务串起来输入剧本拆解场次和分镜生成视频片段配音或提取音频拼接微调导出最终短剧1.4 本文你能学到什么这篇文章不讨论复杂的模型训练而是聚焦“用 MiniMax H3 能力构建长视频短剧工作流”。你会看到长视频短剧工作流的整体设计思路如何设计上下文结构让多个镜头保持一致如何借助 API 与本地 ComfyUI 两种方式进行工程落地完整的 Python 编排示例可参考改造音频 VAE、上下文溢出、节点缺失等高频问题的排查方法一套可以复用的短剧生产 SOP无论你是第一次接触 AI 短剧还是已经有 ComfyUI 基础想进一步做长视频这篇内容都应该能帮你减少很多试错成本。2. 整体工作流设计与模块拆分2.1 传统创作链路 vs AI 工作流链路我们先看传统 CG 短剧怎么制作。团队先有完整剧本再把剧本拆成分集、分场美术人员设计角色与场景导演团队做分镜脚本建模师制作三维资产动画师一帧一帧制作动作剪辑师再负责拼接和调色最后还有配音、音效流程。这条路质量高但成本很高、周期很长一个人基本无法完成。AI 短剧工作流要解决的就是这个矛盾。它不追求每帧达到电影级精细度而是用可控生成替代重复手工劳动。下面是一个常见的 AI 短剧生产链路剧本文件 | v 统一角色/场景/风格设定全局上下文 | v 拆场次把剧本变成一场一场的戏剧单元 | v 拆分镜把每一场拆成多个镜头描述 | v 构建镜头 Prompt 注入上下文标签 | v 逐段生成镜头视频可并行 | v 提取/生成音频、对白、口型 | v 镜头排序、片段拼接 | v 二次检查与导出从工程视角来看这个链路里最重要的不是某一步的 prompt 写得华丽而是每一步的数据格式统一。比如“角色 ID”在剧本阶段叫角色A在分镜阶段又叫male_hero到了 ComfyUI 节点里又变成一个 Lora 名称那整个流程就会断裂。2.2 工作流中的六个核心模块我们将短剧工作流拆成六大模块每个模块职责必须单一。剧本解析模块负责读取剧本文本按场景或场次切分。短剧通常按“场”进行统一管理每一场有地点、时间、人物、事件目标。可以用 LLM 做结构化抽取也可以手写 JSON。角色与场景设定模块维护一个统一设定库。例如角色名、外貌特征、声音特征、常用服装、性格基调场景名、环境描述、光线风格。这些内容会在多个镜头生成时反复引用。分镜生成模块根据“场次信息 设定库”生成一系列分镜。分镜一般包含画面描述、景别、运镜、时长、对白、音效、情绪关键词。视频生成模块调用 MiniMax H3 等视频生成 API 或本地节点把分镜描述和上下文注入进去生成一段段短视频素材。音频与口型模块对视频片段生成/叠加对白音频做音画同步。这部分与音频 VAE 相关在本地部署中最容易踩坑。组装与后期模块将视频序列按照分镜表顺序拼接处理转场、背景音乐、字幕等最后输出完整成片。2.3 数据流设计从“文本零散”到“结构化上下文”上面模块之间不是靠“人脑记忆”衔接而是要有一套结构化中间数据。我推荐的做法所有模块之间传递 JSON 数据结构而不是直接传递 raw 文本。比如一个场次的数据结构可以这样设计{ scene_id: SC002, location: 废弃车站月台, time: 夜晚, weather: 小雨, characters: [ { character_id: hero, name: 周延, emotion: 愤怒但克制, position: 画面左侧 }, { character_id: girl, name: 林小满, emotion: 恐惧, position: 画面右侧 } ], logline: 周延发现林小满偷偷报警后两人在月台对峙。, shots: [ { shot_id: SC002_SH001, type: 中景, duration: 6s, desc: 雨夜月台周延从远处走来脚步越来越快。, dialogue: 林小满电话是你打的吧, sound: 雨声、脚步声 }, { shot_id: SC002_SH002, type: 近景, duration: 5s, desc: 林小满低头握着手机身体微微发抖。, dialogue: 我……我只是不想看你去伤人。, sound: 雨声、轻微抽泣 } ] }为什么要这样设计因为长视频生成需要上下文一致性。当你要生成 SC002_SH002 时不能只把“林小满低头握着手机”这样的短句丢给模型而是要把整场戏的上下文、人物状态、场景设定都带进去。模型在长上下文约束下更容易把人物情绪、衣着、环境光线延续下来。3. 环境准备与版本说明3.1 你需要准备的环境不同开发目标使用的环境不同。做短剧工作流最常见是两类方式第一种云端 API 模式。不需要本地高性能显卡只需要 Python 环境和 API 密钥。适合快速测试和生产化批处理。你只需要关心请求参数和返回结果解析。第二种本地 ComfyUI 模式。适合想完全控制生成细节、不想经过云端服务的用户。通常需要较好的 NVIDIA 显卡并部署 MiniMax H3 相关节点。在版本选择上不同项目和不同社区整合包的依赖差异比较大我不能给你一个绝对固定的版本号。但下面环境组合是当前较常用的参考项目推荐环境操作系统Windows 10/11、Ubuntu 20.04 及以上Python3.10 或 3.11ComfyUI社区最新稳定版PyTorch与显卡驱动匹配的稳定版本显卡NVIDIA 12GB 显存起步建议 24GB 显存API 模式官方 SDK 或 requests 请求即可注意如果你是在 ComfyUI 里安装节点看到类似“请安装缺失的包以使用此工作流”的提示通常说明当前 Python 环境缺少该节点依赖的库。不要直接忽略应该按提示安装对应包。3.2 项目目录结构无论用哪种调用方式我都建议用一个清晰目录管理工程minimax_short_drama_workflow/ ├── config/ │ ├── settings.yaml # API/本地模型参数 │ └── characters.json # 角色设定库 ├── script/ │ └── drama_v1.md # 原始剧本 ├── data/ │ ├── scenes/ # 解析后的场次 JSON │ ├── shots/ # 分镜 JSON │ └── outputs/ # 生成视频输出 ├── workflow/ │ ├── build_context.py # 构造上下文 │ ├── generate_shot.py # 单镜头生成 │ ├── assemble_video.py # 视频拼接 │ └── utils.py # 通用工具 └── logs/ └── run.log这个结构的好处是逻辑清晰配置、剧本、中间数据、生成结果、脚本代码各自独立。出现问题时可以快速定位是哪一环出了问题。3.3 安装核心依赖用 API 方式时Python 核心依赖较少pip install requests pyyaml opencv-python-headless moviepy本地 ComfyUI 方式时通常不用 pip 直接安装全部节点而是安装 ComfyUI 主程序。打开 ComfyUI 自定义节点目录。将 MiniMax H3 相关节点项目 clone 到custom_nodes目录。重启 ComfyUI让主程序自动识别并安装依赖。cd ComfyUI/custom_nodes git clone https://github.com/example/minimax-h3-comfyui.git cd minimax-h3-comfyui pip install -r requirements.txt上面仓库地址是示意路径实际以你下载的整合包说明为准。社区整合包通常已经封装好了节点不需要你手动 clone但需要你有一定 ComfyUI 工作流操作基础。4. 上下文结构与提示词设计4.1 构造“分场上下文”在做长视频短剧时我最担心的是“模型忘记了站在什么场景里”。很多新手会把所有内容都堆到一个 prompt 里结果上下文长度超限或者信息互相干扰。正确做法设计一个可复用的上下文模板。我习惯把上下文分成三大块世界与风格块。比如“现代都市悬疑短剧写实电影风低饱和色调轻微手持摄影感”。角色与状态块。列出当前出场角色 ID、外貌、服装、当前情绪。镜前信息块。讲清楚这个镜头承接了上一个镜头的什么动作当前镜头要表达的目标。下面给出一个 Python 函数示例它会把结构化的分镜数据拼接成模型可接收的上下文文本。你需要按自己使用的模型/API 字段调整但核心思路可复用。# 文件路径workflow/build_context.py import json from typing import Dict, Any def build_global_context(settings: Dict[str, Any]) - str: 构造全局上下文整体故事风格、美术风格、世界观约束。 lines [ 【全局设定】, f剧名{settings.get(drama_name, 未命名短剧)}, f题材{settings.get(genre, 现代都市)}, f美术风格{settings.get(art_style, 写实电影风)}, f镜头风格{settings.get(camera_style, 手持纪实感)}, settings.get(extra_notes, ) ] return \n.join([line for line in lines if line]) def build_character_context(scene_data: Dict[str, Any], character_lib: Dict[str, Any]) - str: 构造角色上下文从角色设定库中取出当前出场角色的详细设定。 lines [【角色状态】] for character in scene_data.get(characters, []): cid character[character_id] profile character_lib.get(cid, {}) appearance profile.get(appearance, 未知外貌) costume profile.get(costume, 未知服装) emotion character.get(emotion, 平静) position character.get(position, 画面中央) lines.append( f角色[{cid}]{profile.get(name, cid)}。 f外貌{appearance}。服装{costume}。 f情绪{emotion}。位置{position}。 ) return \n.join(lines) def build_shot_context(scene_data: Dict[str, Any], shot_data: Dict[str, Any]) - str: 构造镜头上下文当前场次剧情 前序镜头摘要 当前镜头目标。 lines [ f【场次信息】{scene_data.get(scene_id, )}, f地点{scene_data.get(location, )}时间{scene_data.get(time, )}天气{scene_data.get(weather, 晴)}, f本场目标{scene_data.get(logline, )}, f【当前镜头】{shot_data.get(shot_id, )}, f景别{shot_data.get(type, 中景)}, f画面描述{shot_data.get(desc, )}, f台词/对白{shot_data.get(dialogue, 无)}, f音效要求{shot_data.get(sound, 无)}, ] return \n.join(lines) def compose_prompt(settings, character_lib, scene_data, shot_data) - str: 将全局上下文、角色上下文、当前镜头上下文拼成完整 Prompt。 parts [ build_global_context(settings), build_character_context(scene_data, character_lib), build_shot_context(scene_data, shot_data), ] return \n\n.join(parts)这里有两点解释character_lib是角色设定库例如characters.json它会为某个演员维持长期一致性。无论这个角色出现在第几场生成的描述都会以这套外貌为准。前序镜头摘要不是把之前所有视频帧都送进去。对很多模型而言最有效的方式是用文字描述上一步的画面状态让模型知道动作连贯方向。4.2 关于“长上下文”的工程处理长上下文虽好但它不是无限的。很多使用者在做几分钟视频时恨不得把整集剧本都塞进去。这会导致几个问题上下文窗口溢出报错比如“上下文用量满了”。无关信息过多导致模型注意力被稀释镜头反而不遵循核心指令。API 费用和延迟明显上升。因此在工程上我推荐“分页上下文”策略。用一个窗口处理全局持久信息另一个窗口处理场次临时信息。这个思路有点像写代码时的全局变量和局部变量def build_window_prompts(scene_list, character_lib, settings, max_shots_per_window3): 将连续多个镜头分成多个上下文窗口但保留全局设定。 避免单次请求过长。 windows [] current_window_shots [] current_window_dialogue [] for scene_data in scene_list: for shot_data in scene_data[shots]: # 简单规则累积对白达到一定长度就换窗口 current_window_shots.append(shot_data) current_window_dialogue.append(shot_data.get(dialogue, )) dialogue_text .join(current_window_dialogue) # 按镜头数或字符数分页 if len(current_window_shots) max_shots_per_window or len(dialogue_text) 600: window_prompt build_single_window( settings, character_lib, scene_data, current_window_shots ) windows.append(window_prompt) current_window_shots [] current_window_dialogue [] if current_window_shots: scene_data_ref scene_list[-1] windows.append( build_single_window(settings, character_lib, scene_data_ref, current_window_shots) ) return windows def build_single_window(settings, character_lib, scene_data, shots): lines [ build_global_context(settings), build_character_context(scene_data, character_lib), f【本窗口镜头数】共 {len(shots)} 个连续镜头, ] for s in shots: lines.append( f- {s.get(shot_id, )}{s.get(desc, )}。 f台词{s.get(dialogue, 无)}。 f音效{s.get(sound, 无)}。 ) return \n.join(lines)这种方法像是给模型装了一个“可滑动剧情记忆”最关键的信息始终在窗口内细节信息在进入新窗口前会保留摘要。这样即使用户使用的是云端 API也能让一批镜头输出结果更一致。4.3 短剧镜头 Prompt 案例以第 2 节中的SC002_SH001为例。如果直接发送生成请求Prompt 大概长这样【全局设定】 剧名《月台》 题材现代都市悬疑情感短剧 美术风格写实电影风低饱和色调轻微胶片噪点 镜头风格手持纪实感景深较浅 【角色状态】 角色[hero]周延。外貌30岁中等身材黑色中长外套眼神锐利右眉有一道浅疤。服装深灰色卫衣黑色长裤。情绪愤怒但克制。位置画面左侧。 角色[girl]林小满。外貌26岁长发清秀穿米白色毛衣。服装米白色毛衣深色半裙。情绪恐惧。位置画面右侧。 【场次信息】SC002 地点废弃车站月台时间夜晚天气小雨 本场目标周延发现林小满偷偷报警后两人在月台对峙。 【当前镜头】SC002_SH001 景别中景 画面描述雨夜月台周延从远处走来脚步越来越快。 台词林小满电话是你打的吧 音效雨声、脚步声可以观察到一个细节模型真正生成时不一定需要你把“废弃车站月台”在字段里反复出现很多次而是要保证“全局设定”里有场景风格“角色状态”里有角色定位“当前镜头”里有明确的镜头要求。这三层信息同时存在就是所谓的长上下文叙事能力。5. 完整实战用 Python 编排短剧镜头生成这一节我们实现一个能跑通的完整流程。由于 MiniMax H3 的 API 细节会随版本变化下面对 API 的请求部分保留为接口示意重点演示工程编排逻辑。你在实际使用时把generate_video_with_h3函数体内的请求参数替换为官方最新文档的字段即可。5.1 创建项目结构与配置先建立工程目录并把配置信息写进config/settings.yaml。# 文件路径config/settings.yaml drama_name: 月台 genre: 现代都市悬疑情感 art_style: 写实电影风低饱和色调 camera_style: 手持纪实感 api: # 云端 API 模式 base_url: https://api.example.com/v1 api_key: 替换为你的API密钥 model: minimaxh3 max_context_chars: 6000 local: # 本地 ComfyUI 模式 comfyui_url: http://127.0.0.1:8188 checkpoint_name: minimaxh3_v1.safetensors audio_vae_name: minimax_h3_audio_vae_fp32.safetensors steps: 305.2 读取配置与角色设定创建workflow/utils.py# 文件路径workflow/utils.py import json import yaml from pathlib import Path def load_yaml(path: str) - dict: with open(path, r, encodingutf-8) as f: return yaml.safe_load(f) def load_json(path: str) - dict: with open(path, r, encodingutf-8) as f: return json.load(f) def save_json(data, path: str) - None: Path(path).parent.mkdir(parentsTrue, exist_okTrue) with open(path, w, encodingutf-8) as f: json.dump(data, f, ensure_asciiFalse, indent2)创建config/characters.json{ hero: { name: 周延, appearance: 30岁中等身材黑色中长外套眼神锐利右眉有一道浅疤, costume: 深灰色卫衣黑色长裤 }, girl: { name: 林小满, appearance: 26岁长发清秀, costume: 米白色毛衣深色半裙 } }5.3 将剧本解析成场次与分镜实际项目中这一步可以用 LLM 自动抽取。为方便演示这里我们手工构造一个场次 JSON保存到data/scenes/sc002.json{ scene_id: SC002, location: 废弃车站月台, time: 夜晚, weather: 小雨, characters: [ { character_id: hero, emotion: 愤怒但克制, position: 画面左侧 }, { character_id: girl, emotion: 恐惧, position: 画面右侧 } ], logline: 周延发现林小满偷偷报警后两人在月台对峙。, shots: [ { shot_id: SC002_SH001, type: 中景, duration: 6s, desc: 雨夜月台周延从远处走来脚步越来越快。, dialogue: 林小满电话是你打的吧, sound: 雨声、脚步声 }, { shot_id: SC002_SH002, type: 近景, duration: 5s, desc: 林小满低头握着手机身体微微发抖。, dialogue: 我……我只是不想看你去伤人。, sound: 雨声、轻微抽泣 } ] }5.4 构造 API 生成脚本下面写一个视频生成编排脚本。核心逻辑是遍历每个分镜构造 Prompt调用 MiniMax H3 接口把返回的视频保存到data/outputs。# 文件路径workflow/generate_shot.py import time import requests from pathlib import Path from utils import load_yaml, load_json, save_json from build_context import compose_prompt def generate_video_with_h3(prompt: str, settings: dict, output_path: Path) - str: 调用 MiniMax H3 视频生成 API。 注意这是接口示意具体参数请以官方最新文档为准。 api_conf settings[api] headers { Authorization: fBearer {api_conf[api_key]}, Content-Type: application/json } payload { model: api_conf[model], prompt: prompt, # 不是所有接口都支持这些参数这里只是演示结构 duration: 6, resolution: 1280x720, fps: 24 } url f{api_conf[base_url]}/video/generate resp requests.post(url, headersheaders, jsonpayload, timeout30) resp.raise_for_status() data resp.json() # 模拟轮询异步任务 task_id data.get(task_id, demo_task) video_url poll_task_result(task_id, headers, api_conf[base_url]) video_bytes requests.get(video_url).content output_path.parent.mkdir(parentsTrue, exist_okTrue) output_path.write_bytes(video_bytes) return str(output_path) def poll_task_result(task_id: str, headers: dict, base_url: str, max_wait: int 120) - str: 轮询异步任务结果这里只示范结构。 for _ in range(max_wait): r requests.get( f{base_url}/video/task/{task_id}, headersheaders, timeout10 ) r.raise_for_status() status r.json().get(status) if status succeeded: video_url r.json()[output][video_url] return video_url if status failed: err_msg r.json().get(error, 未知错误) raise RuntimeError(f视频生成失败: {err_msg}) time.sleep(3) raise TimeoutError(等待任务完成超时) def main(): settings load_yaml(config/settings.yaml) character_lib load_json(config/characters.json) scene_data load_json(data/scenes/sc002.json) outputs_dir Path(data/outputs) save_json(scene_data, data/parsed_scenes/sc002.json) for shot in scene_data[shots]: prompt_text compose_prompt( settings, character_lib, scene_data, shot ) print(f正在生成镜头: {shot[shot_id]}) output_path outputs_dir / f{shot[shot_id]}.mp4 video_file generate_video_with_h3(prompt_text, settings, output_path) print(f镜头已保存: {video_file}) # 将生成结果记录到清单方便后续拼接 scene_data.setdefault(generated, []).append({ shot_id: shot[shot_id], file: str(video_file), prompt_len: len(prompt_text) }) save_json(scene_data, data/parsed_scenes/sc002_with_result.json) print(全部镜头生成完成) if __name__ __main__: main()你要特别留意几点compose_prompt是我们第 4 节实现的上下文拼接函数。它保证了每个镜头请求都带着“全局风格角色状态镜头目标”。poll_task_result是异步任务通用的轮询处理方式防止请求超时后任务丢失。输出文件命名直接使用shot_id有利于后续按顺序拼接。5.5 本地 ComfyUI 调用思路如果你不想走云端 API而是使用本地 ComfyUI 工作流思路也类似。你并不需要 Python 写一套完整 API只需要让 Python 脚本向 ComfyUI 的 WebSocket/HTTP 端口提交一个 workflow JSON。可以先用 ComfyUI 的节点界面把工作流搭好然后把workflow.json导出使用 ComfyUI API 格式提交。下面是一个提交工作流的通用示例# 文件路径workflow/submit_comfyui.py import json import requests def submit_workflow(workflow: dict, base_url: str http://127.0.0.1:8188): 向 ComfyUI 提交一个 workflow。 prompt_data workflow[prompt] response requests.post( f{base_url}/prompt, json{prompt: prompt_data}, timeout10 ) response.raise_for_status() result response.json() print(任务提交成功prompt_id, result.get(prompt_id)) return result.get(prompt_id)在这个工作流里面你同样需要把build_context.py生成的 Prompt 文本填入模型的text输入框。同时还需要注意checkpoint 等大模型文件需要放在 ComfyUI 对应模型目录。Audio VAE 文件需要放在音频 VAE 节点要求的目录。如果报错value not in list: vae_name: minimaxh3\\minimax_h3_audio_vae_fp32.safetensors意思是当前节点下拉列表里没有这个文件。多半是文件放错目录或者文件名大小写不匹配。5.6 视频拼接脚本镜头全部生成以后可以用 ffmpeg 或 moviepy 将视频按顺序拼接。简单起见我们直接用 moviepy。# 文件路径workflow/assemble_video.py from pathlib import Path from moviepy.editor import VideoFileClip, concatenate_videoclips def assemble_shots(video_dir: Path, output_path: Path) - str: 将多个分镜视频按照 shot_id 排序后拼接。 video_files sorted( list(video_dir.glob(*.mp4)), keylambda p: p.stem ) clips [] for video_file in video_files: # 如果原视频时长与分镜要求不一致也可以在此处做转场或变速 clip VideoFileClip(str(video_file)) clips.append(clip) final_clip concatenate_videoclips(clips, methodcompose) final_clip.write_videofile( str(output_path), fps24, codeclibx264, audio_codecaac, threads4, presetmedium ) return str(output_path) if __name__ __main__: result assemble_shots( video_dirPath(data/outputs), output_pathPath(data/final/short_drama_sc002.mp4) ) print(f成片已输出到: {result})真实项目中你还会处理片段之间的淡入淡出、叠化转场、字幕烧录。这些可以基于剪辑软件也可以在 Python 里继续扩展。关键是把分镜顺序和最终成片顺序对应起来。6. 常见问题与排查思路6.1 上下文用量满了怎么办现象提交请求时平台/工具提示“上下文用量已满”或“超出最大 Token 限制”。可能原因把所有历史镜头、超长剧本一次性追加进同一次请求。角色设定库没有做裁剪每个角色带着大段背景描述。前序镜头摘要过长没有经过压缩。解决思路排查点操作请求文本长度统计 prompt 字符数确认是否超出限制全局信息只保留会影响画面风格的字段删掉与当前镜头无关的角色历史镜头用一到两句摘要替代完整镜头原文代码逻辑使用第 4 节的分页窗口策略减小单次上下文# 查看 prompt 长度示例 python -c from workflow.build_context import compose_prompt; print(len(compose_prompt(...)))最稳定的做法不是不断降低文本长度而是在进入 API 前主动做压缩层。如果一个镜头的生成需要依赖前面 20 个镜头你应该让模型维护一个“剧情状态摘要”而不是把 20 个镜头全丢进去。6.2 ComfyUI 提示“请安装缺失的包以使用此工作流”现象加载别人分享的工作流模板时顶部红色提示缺包运行时报ModuleNotFoundError。原因工作流使用了自定义节点但这些节点并未安装到当前 ComfyUI 环境。排查步骤按下 Ctrl Shift L 或在节点管理器中查看缺失节点名称。到ComfyUI/custom_nodes目录检查对应项目是否存在。进入缺失项目目录执行pip install -r requirements.txt。完全重启 ComfyUI。特别是 H3 这类模型节点可能要求安装safetensors、transformers、torchaudio、einops等依赖。安装完之后最好确认一下 Python 环境是否和 ComfyUI 用的是同一个解释器。6.3 value not in list: vae_name 报错现象在 ComfyUI 节点里选择音频 VAE 时下拉列表里找不到minimax_h3_audio_vae_fp32.safetensors。可能原因模型文件没有放入正确的 VAE 目录。文件扩展名大小写不一致。节点读取目录路径发生错误。解决思路检查 ComfyUI 模型的目录结构。一般 VAE 相关文件要求放在models/vae而不是models/checkpoints。如果节点要求文件路径带有minimaxh3子目录你需要保持目录结构一致。ComfyUI/models/ ├── checkpoints/ │ └── minimaxh3/ │ └── minimaxh3_v1.safetensors └── vae/ └── minimaxh3/ └── minimax_h3_audio_vae_fp32.safetensors如果不确定打开 ComfyUI 节点的 py 文件查看它遍历的目录是哪几个。6.4 角色一致性差、换镜头后像换演员这个不是报错但比报错更让人头疼。原因多数是上下文里没有足够强的角色视觉锚点。比如你第一场写“黑色中长外套”第二场忘了写模型就默认给角色换了衣服。解决方法是把外貌特征字段做成“强制注入”。不要指望模型记得历史对话你要在每次请求里都带上视觉锚点。可以在config/characters.json中维护一个anchor_prompt字段作为角色外观硬约束。{ hero: { name: 周延, appearance: 30岁中等身材黑色中长外套眼神锐利右眉有一道浅疤, costume: 深灰色卫衣黑色长裤, anchor_prompt: A man in his early 30s with a sharp look, wearing a dark gray hoodie and a black long coat, short black hair, a visible scar above his right eyebrow. } }当模型支持英文提示或更细粒度提示时英文锚点有时更稳定。不过不要为了锚点牺牲中文剧本语义建议在脚本中同时保留中英文双字段。6.5 视频生成结果过短且无法拼成长剧现象每个镜头只能生成 5 到 10 秒拼成长片后节奏很怪镜头之间缺少衔接。原因长视频短剧并不等于“AI 一次性生成很长的一整段视频”而是通过工作流把叙事拆解成可生成的短视频片段再用工程手段保证连续性。解决思路单镜头时长不宜过长重点保证画面明确、动作单一。在分镜 JSON 中加入prev_shot_summary字段让后一镜头继承前一镜头的方向。拼接时增加转场例如叠化、匹配剪辑降低不同片段之间的跳跃感。在后期为整场戏统一配背景音乐和调色 LUT提升成片一致性。7. 最佳实践与工程建议7.1 为每一场戏建立“上下文快照”不要临时拼 Prompt。建议在开始生成一场戏之前先把该场所有需要的信息生成一个 JSON 快照文件。这个文件既方便回滚也方便后续排查为什么某镜头角色穿错了衣服。推荐快照结构{ scene_id: SC002, global_settings: { art_style: 写实电影风 }, character_snapshot: { hero: { appearance: 30岁黑色中长外套右眉浅疤, costume_in_this_scene: 深灰色卫衣黑色长裤 } }, previous_scene_summary: 第一场周延发现手机里有一段录音决定去月台质问林小满。, shots: [] }每次生成完一个镜头就把该镜头的实际画面描述更新到previous_scene_summary。做连续剧情时这种“滚动摘要”机制比把所有镜头都塞进上下文更实用。7.2 设置自动进度记录避免断点重来长视频生成过程中单镜头失败、接口超时、显卡显存不足都可能中断。如果脚本没有断点续传一旦第 10 个镜头失败前面 9 个镜头也要重新生成这对本地部署来说成本很高。可以在每次成功生成后把完成标记写入本地数据库或 JSON 文件# 文件路径workflow/track_progress.py import json from pathlib import Path PROGRESS_FILE Path(data/generation_progress.json) def mark_done(shot_id: str, video_path: str) - None: progress {} if PROGRESS_FILE.exists(): progress json.loads(PROGRESS_FILE.read_text(encodingutf-8)) progress[shot_id] video_path PROGRESS_FILE.write_text( json.dumps(progress, ensure_asciiFalse, indent2), encodingutf-8 ) def is_done(shot_id: str) - bool: if not PROGRESS_FILE.exists(): return False progress json.loads(PROGRESS_FILE.read_text(encodingutf-8)) return shot_id in progress然后在generate_shot.py主循环中增加判断for shot in scene_data[shots]: shot_id shot[shot_id] if is_done(shot_id): print(f跳过已完成镜头: {shot_id}) continue # 生成逻辑... mark_done(shot_id, output_path)这样即使中途任务中断下次重新执行也可以跳过已完成镜头节省大量时间。7.3 安全与最小权限原则短剧创作涉及上传剧本、角色设定、视频素材到云端 API。建议遵守以下边界不要上传未经授权的他人肖像、品牌标识、受版权保护的素材。使用 API Key 时不要硬编码在公共仓库里建议使用环境变量注入。涉及批量删除生成结果、覆盖原始文件时先备份到backup目录。在正式批量生成前用 1 个测试镜头验证 Prompt 效果再进行全量生成。export MINIMAX_API_KEY你的密钥在 Python 中读取import os api_key os.getenv(MINIMAX_API_KEY) if not api_key: raise RuntimeError(请先设置 MINIMAX_API_KEY 环境变量)7.4 镜头拼接时保留一条“剪片清单”很多人生成完视频后直接用文件名排序拼接。但实际创作中模型生成的某个镜头内容可能不够理想需要重拍。这时如果丢了“剪片清单”后期会非常混乱。我建议维护一个data/assembly_plan.json{ scene_id: SC002, plan: [ { order: 1, shot_id: SC002_SH001, file: data/outputs/SC002_SH001.mp4, duration: 6, transition: cut }, { order: 2, shot_id: SC002_SH002, file: data/outputs/SC002_SH002_retry.mp4, duration: 5, transition: dissolve } ] }有了这个清单你可以自由替换具体镜头文件而不改变叙事顺序。7.5 性能与成本控制短剧生成往往不是一次性的而是反复测试的过程。建议控制三个指标单个镜头重试次数。同一个镜头不要超过 3 次如果每次差异太大优先修改上下文而不是继续抽卡。分辨率档位。初剪阶段使用较低分辨率和步数确认剧情后再用高质量参数做最终输出。并发度。如果使用云端 API注意并发限制如果使用本地 ComfyUI队列任务过多可能导致显存溢出。8. 总结与下一步学习路线到这里你应该对 MiniMax H3 长视频短剧工作流有了一个系统性认识。我们从概念上区分了“上下文”和“工作流”从工程上拆出了剧本解析、角色设定、分镜生成、视频生成、音频、拼接这六大模块也通过一个模拟工程示例走通了从结构化场次数据到最终生成镜头的流程。代码本身不一定能直接复制后在你电脑上一次性跑通因为 MiniMax H3 的 API 参数、ComfyUI 节点名称、模型文件路径都在快速迭代。但本文真正希望你掌握的是那套可以迁移的上下文设计方法局部镜头始终携带全局风格、角色视觉锚点、当前剧情目标并把每次生成结果登记成一个可回溯的记录。下一步建议你分三条路径继续加深工具路径熟悉 ComfyUI 自定义节点安装、工作流导入、模型目录规范把第 5 节的视频生成逻辑映射成可视化节点。工程路径把分镜 JSON、上下文构造、视频生成、断点续传封装成独立 Python 模块做成一个可批量跑短剧分集的命令行工具。创作路径从一场两分钟的戏开始尝试记录不同 Prompt 上下文下生成画面的差别积攒你自己的短剧风格库和负面提示词库。在实际项目中先不要贪心做几十集的连续剧先把“单场戏、两个角色、三个镜头”跑顺。等你能稳定控制单场戏的角色一致性和人物状态再逐渐扩展到跨场次、跨集数才能真正驾驭长视频工作流。如果这篇文章对你有帮助建议先收藏备用后面实操遇到问题随时回来对照排查。 MiniMax H3 长视频短剧工作流：从上下文设计到工程落地
1. 背景与核心概念1.1 为什么“长视频短剧”需要新工作流如果你做过几分钟以上的 AI 短剧大概率遇到过这几个问题角色长相不够统一、镜头之间的场景不连贯、人物说完上句后下一句口型对不上、或者生成了几十段素材却因为每段互相独立而无法串成一条完整故事线。传统 AI 视频生成工具往往按“单镜头”工作输入一段文字生成几秒钟的视频。单看每个镜头都不错但放到一条叙事线上就等于“各说各话”。要想做出一条有剧情推进、有场景切换、有人物情绪连续变化的短剧光靠零散单镜头生成是不够的必须把“全局设定”“剧本结构”“人物状态”“上下文衔接”纳入到一个完整流程中。MiniMax H3 这类具备较强长上下文能力的视频生成模型为解决这个问题提供了新思路。它可以在一次工作流中接收更完整的剧情描述、角色设定、镜头变化要求让生成结果不只是一个孤立片段而是能围绕某一段戏的整体语义来生成。换一句话说长上下文让模型从“看一句话拍一个镜头”升级成“看一整场戏拍一段素材”。1.2 MiniMax H3 是什么MiniMax H3 是 MiniMax 系列视频生成方向的一个模型/工具版本它的特点体现在几个方面支持更长文本输入可以一次性把角色设定、分镜描述、台词、氛围要求都放进去。面向视频生成链路输出比传统文本上下文更复杂的多帧内容。可以搭配音频模型使用生成带音效、配音或口型同步的视频素材。社区里也出现了本地 ComfyUI 工作流节点用于部署和调用 H3 模型。在短剧制作场景下它更像是“导演台”而非简单的“单镜头生成器”。你可以把整场戏需要的信息给进去模型在编码阶段就把握上下文相关性最后输出一段相对完整的镜头素材。要注意一点不同版本或者不同接入方式官方 API、云端工作台、本地 ComfyUI对“上下文”的定义略有不同。后面我们会讲到如何在这个差异下做工程设计。1.3 “上下文”和“工作流”在短剧制作中的含义先解释两个容易混淆的词。第一个是“上下文”。在短剧视频工作流里上下文并不仅仅指“把上一段剧本文字拼接到下一段”。它至少包含三层上下文层级内容作用全局上下文故事类型、人物设定、场景总览、美术风格保证所有生成片段处于同一个世界观内场次上下文当前这场戏的起因、目标、人物关系变化保证镜头之间有剧情推进逻辑镜头上下文上一个镜头画面、人物位置、动作方向保证相邻镜头剪辑时不出戏、动作衔接自然第二个是“工作流”。技术圈常说的 workflow可以是一套 API 调用编排也可以是一套节点式可视化流程例如 ComfyUI、Dify、n8n 里的工作流。对于做短剧的人工作流就是把下面这些任务串起来输入剧本拆解场次和分镜生成视频片段配音或提取音频拼接微调导出最终短剧1.4 本文你能学到什么这篇文章不讨论复杂的模型训练而是聚焦“用 MiniMax H3 能力构建长视频短剧工作流”。你会看到长视频短剧工作流的整体设计思路如何设计上下文结构让多个镜头保持一致如何借助 API 与本地 ComfyUI 两种方式进行工程落地完整的 Python 编排示例可参考改造音频 VAE、上下文溢出、节点缺失等高频问题的排查方法一套可以复用的短剧生产 SOP无论你是第一次接触 AI 短剧还是已经有 ComfyUI 基础想进一步做长视频这篇内容都应该能帮你减少很多试错成本。2. 整体工作流设计与模块拆分2.1 传统创作链路 vs AI 工作流链路我们先看传统 CG 短剧怎么制作。团队先有完整剧本再把剧本拆成分集、分场美术人员设计角色与场景导演团队做分镜脚本建模师制作三维资产动画师一帧一帧制作动作剪辑师再负责拼接和调色最后还有配音、音效流程。这条路质量高但成本很高、周期很长一个人基本无法完成。AI 短剧工作流要解决的就是这个矛盾。它不追求每帧达到电影级精细度而是用可控生成替代重复手工劳动。下面是一个常见的 AI 短剧生产链路剧本文件 | v 统一角色/场景/风格设定全局上下文 | v 拆场次把剧本变成一场一场的戏剧单元 | v 拆分镜把每一场拆成多个镜头描述 | v 构建镜头 Prompt 注入上下文标签 | v 逐段生成镜头视频可并行 | v 提取/生成音频、对白、口型 | v 镜头排序、片段拼接 | v 二次检查与导出从工程视角来看这个链路里最重要的不是某一步的 prompt 写得华丽而是每一步的数据格式统一。比如“角色 ID”在剧本阶段叫角色A在分镜阶段又叫male_hero到了 ComfyUI 节点里又变成一个 Lora 名称那整个流程就会断裂。2.2 工作流中的六个核心模块我们将短剧工作流拆成六大模块每个模块职责必须单一。剧本解析模块负责读取剧本文本按场景或场次切分。短剧通常按“场”进行统一管理每一场有地点、时间、人物、事件目标。可以用 LLM 做结构化抽取也可以手写 JSON。角色与场景设定模块维护一个统一设定库。例如角色名、外貌特征、声音特征、常用服装、性格基调场景名、环境描述、光线风格。这些内容会在多个镜头生成时反复引用。分镜生成模块根据“场次信息 设定库”生成一系列分镜。分镜一般包含画面描述、景别、运镜、时长、对白、音效、情绪关键词。视频生成模块调用 MiniMax H3 等视频生成 API 或本地节点把分镜描述和上下文注入进去生成一段段短视频素材。音频与口型模块对视频片段生成/叠加对白音频做音画同步。这部分与音频 VAE 相关在本地部署中最容易踩坑。组装与后期模块将视频序列按照分镜表顺序拼接处理转场、背景音乐、字幕等最后输出完整成片。2.3 数据流设计从“文本零散”到“结构化上下文”上面模块之间不是靠“人脑记忆”衔接而是要有一套结构化中间数据。我推荐的做法所有模块之间传递 JSON 数据结构而不是直接传递 raw 文本。比如一个场次的数据结构可以这样设计{ scene_id: SC002, location: 废弃车站月台, time: 夜晚, weather: 小雨, characters: [ { character_id: hero, name: 周延, emotion: 愤怒但克制, position: 画面左侧 }, { character_id: girl, name: 林小满, emotion: 恐惧, position: 画面右侧 } ], logline: 周延发现林小满偷偷报警后两人在月台对峙。, shots: [ { shot_id: SC002_SH001, type: 中景, duration: 6s, desc: 雨夜月台周延从远处走来脚步越来越快。, dialogue: 林小满电话是你打的吧, sound: 雨声、脚步声 }, { shot_id: SC002_SH002, type: 近景, duration: 5s, desc: 林小满低头握着手机身体微微发抖。, dialogue: 我……我只是不想看你去伤人。, sound: 雨声、轻微抽泣 } ] }为什么要这样设计因为长视频生成需要上下文一致性。当你要生成 SC002_SH002 时不能只把“林小满低头握着手机”这样的短句丢给模型而是要把整场戏的上下文、人物状态、场景设定都带进去。模型在长上下文约束下更容易把人物情绪、衣着、环境光线延续下来。3. 环境准备与版本说明3.1 你需要准备的环境不同开发目标使用的环境不同。做短剧工作流最常见是两类方式第一种云端 API 模式。不需要本地高性能显卡只需要 Python 环境和 API 密钥。适合快速测试和生产化批处理。你只需要关心请求参数和返回结果解析。第二种本地 ComfyUI 模式。适合想完全控制生成细节、不想经过云端服务的用户。通常需要较好的 NVIDIA 显卡并部署 MiniMax H3 相关节点。在版本选择上不同项目和不同社区整合包的依赖差异比较大我不能给你一个绝对固定的版本号。但下面环境组合是当前较常用的参考项目推荐环境操作系统Windows 10/11、Ubuntu 20.04 及以上Python3.10 或 3.11ComfyUI社区最新稳定版PyTorch与显卡驱动匹配的稳定版本显卡NVIDIA 12GB 显存起步建议 24GB 显存API 模式官方 SDK 或 requests 请求即可注意如果你是在 ComfyUI 里安装节点看到类似“请安装缺失的包以使用此工作流”的提示通常说明当前 Python 环境缺少该节点依赖的库。不要直接忽略应该按提示安装对应包。3.2 项目目录结构无论用哪种调用方式我都建议用一个清晰目录管理工程minimax_short_drama_workflow/ ├── config/ │ ├── settings.yaml # API/本地模型参数 │ └── characters.json # 角色设定库 ├── script/ │ └── drama_v1.md # 原始剧本 ├── data/ │ ├── scenes/ # 解析后的场次 JSON │ ├── shots/ # 分镜 JSON │ └── outputs/ # 生成视频输出 ├── workflow/ │ ├── build_context.py # 构造上下文 │ ├── generate_shot.py # 单镜头生成 │ ├── assemble_video.py # 视频拼接 │ └── utils.py # 通用工具 └── logs/ └── run.log这个结构的好处是逻辑清晰配置、剧本、中间数据、生成结果、脚本代码各自独立。出现问题时可以快速定位是哪一环出了问题。3.3 安装核心依赖用 API 方式时Python 核心依赖较少pip install requests pyyaml opencv-python-headless moviepy本地 ComfyUI 方式时通常不用 pip 直接安装全部节点而是安装 ComfyUI 主程序。打开 ComfyUI 自定义节点目录。将 MiniMax H3 相关节点项目 clone 到custom_nodes目录。重启 ComfyUI让主程序自动识别并安装依赖。cd ComfyUI/custom_nodes git clone https://github.com/example/minimax-h3-comfyui.git cd minimax-h3-comfyui pip install -r requirements.txt上面仓库地址是示意路径实际以你下载的整合包说明为准。社区整合包通常已经封装好了节点不需要你手动 clone但需要你有一定 ComfyUI 工作流操作基础。4. 上下文结构与提示词设计4.1 构造“分场上下文”在做长视频短剧时我最担心的是“模型忘记了站在什么场景里”。很多新手会把所有内容都堆到一个 prompt 里结果上下文长度超限或者信息互相干扰。正确做法设计一个可复用的上下文模板。我习惯把上下文分成三大块世界与风格块。比如“现代都市悬疑短剧写实电影风低饱和色调轻微手持摄影感”。角色与状态块。列出当前出场角色 ID、外貌、服装、当前情绪。镜前信息块。讲清楚这个镜头承接了上一个镜头的什么动作当前镜头要表达的目标。下面给出一个 Python 函数示例它会把结构化的分镜数据拼接成模型可接收的上下文文本。你需要按自己使用的模型/API 字段调整但核心思路可复用。# 文件路径workflow/build_context.py import json from typing import Dict, Any def build_global_context(settings: Dict[str, Any]) - str: 构造全局上下文整体故事风格、美术风格、世界观约束。 lines [ 【全局设定】, f剧名{settings.get(drama_name, 未命名短剧)}, f题材{settings.get(genre, 现代都市)}, f美术风格{settings.get(art_style, 写实电影风)}, f镜头风格{settings.get(camera_style, 手持纪实感)}, settings.get(extra_notes, ) ] return \n.join([line for line in lines if line]) def build_character_context(scene_data: Dict[str, Any], character_lib: Dict[str, Any]) - str: 构造角色上下文从角色设定库中取出当前出场角色的详细设定。 lines [【角色状态】] for character in scene_data.get(characters, []): cid character[character_id] profile character_lib.get(cid, {}) appearance profile.get(appearance, 未知外貌) costume profile.get(costume, 未知服装) emotion character.get(emotion, 平静) position character.get(position, 画面中央) lines.append( f角色[{cid}]{profile.get(name, cid)}。 f外貌{appearance}。服装{costume}。 f情绪{emotion}。位置{position}。 ) return \n.join(lines) def build_shot_context(scene_data: Dict[str, Any], shot_data: Dict[str, Any]) - str: 构造镜头上下文当前场次剧情 前序镜头摘要 当前镜头目标。 lines [ f【场次信息】{scene_data.get(scene_id, )}, f地点{scene_data.get(location, )}时间{scene_data.get(time, )}天气{scene_data.get(weather, 晴)}, f本场目标{scene_data.get(logline, )}, f【当前镜头】{shot_data.get(shot_id, )}, f景别{shot_data.get(type, 中景)}, f画面描述{shot_data.get(desc, )}, f台词/对白{shot_data.get(dialogue, 无)}, f音效要求{shot_data.get(sound, 无)}, ] return \n.join(lines) def compose_prompt(settings, character_lib, scene_data, shot_data) - str: 将全局上下文、角色上下文、当前镜头上下文拼成完整 Prompt。 parts [ build_global_context(settings), build_character_context(scene_data, character_lib), build_shot_context(scene_data, shot_data), ] return \n\n.join(parts)这里有两点解释character_lib是角色设定库例如characters.json它会为某个演员维持长期一致性。无论这个角色出现在第几场生成的描述都会以这套外貌为准。前序镜头摘要不是把之前所有视频帧都送进去。对很多模型而言最有效的方式是用文字描述上一步的画面状态让模型知道动作连贯方向。4.2 关于“长上下文”的工程处理长上下文虽好但它不是无限的。很多使用者在做几分钟视频时恨不得把整集剧本都塞进去。这会导致几个问题上下文窗口溢出报错比如“上下文用量满了”。无关信息过多导致模型注意力被稀释镜头反而不遵循核心指令。API 费用和延迟明显上升。因此在工程上我推荐“分页上下文”策略。用一个窗口处理全局持久信息另一个窗口处理场次临时信息。这个思路有点像写代码时的全局变量和局部变量def build_window_prompts(scene_list, character_lib, settings, max_shots_per_window3): 将连续多个镜头分成多个上下文窗口但保留全局设定。 避免单次请求过长。 windows [] current_window_shots [] current_window_dialogue [] for scene_data in scene_list: for shot_data in scene_data[shots]: # 简单规则累积对白达到一定长度就换窗口 current_window_shots.append(shot_data) current_window_dialogue.append(shot_data.get(dialogue, )) dialogue_text .join(current_window_dialogue) # 按镜头数或字符数分页 if len(current_window_shots) max_shots_per_window or len(dialogue_text) 600: window_prompt build_single_window( settings, character_lib, scene_data, current_window_shots ) windows.append(window_prompt) current_window_shots [] current_window_dialogue [] if current_window_shots: scene_data_ref scene_list[-1] windows.append( build_single_window(settings, character_lib, scene_data_ref, current_window_shots) ) return windows def build_single_window(settings, character_lib, scene_data, shots): lines [ build_global_context(settings), build_character_context(scene_data, character_lib), f【本窗口镜头数】共 {len(shots)} 个连续镜头, ] for s in shots: lines.append( f- {s.get(shot_id, )}{s.get(desc, )}。 f台词{s.get(dialogue, 无)}。 f音效{s.get(sound, 无)}。 ) return \n.join(lines)这种方法像是给模型装了一个“可滑动剧情记忆”最关键的信息始终在窗口内细节信息在进入新窗口前会保留摘要。这样即使用户使用的是云端 API也能让一批镜头输出结果更一致。4.3 短剧镜头 Prompt 案例以第 2 节中的SC002_SH001为例。如果直接发送生成请求Prompt 大概长这样【全局设定】 剧名《月台》 题材现代都市悬疑情感短剧 美术风格写实电影风低饱和色调轻微胶片噪点 镜头风格手持纪实感景深较浅 【角色状态】 角色[hero]周延。外貌30岁中等身材黑色中长外套眼神锐利右眉有一道浅疤。服装深灰色卫衣黑色长裤。情绪愤怒但克制。位置画面左侧。 角色[girl]林小满。外貌26岁长发清秀穿米白色毛衣。服装米白色毛衣深色半裙。情绪恐惧。位置画面右侧。 【场次信息】SC002 地点废弃车站月台时间夜晚天气小雨 本场目标周延发现林小满偷偷报警后两人在月台对峙。 【当前镜头】SC002_SH001 景别中景 画面描述雨夜月台周延从远处走来脚步越来越快。 台词林小满电话是你打的吧 音效雨声、脚步声可以观察到一个细节模型真正生成时不一定需要你把“废弃车站月台”在字段里反复出现很多次而是要保证“全局设定”里有场景风格“角色状态”里有角色定位“当前镜头”里有明确的镜头要求。这三层信息同时存在就是所谓的长上下文叙事能力。5. 完整实战用 Python 编排短剧镜头生成这一节我们实现一个能跑通的完整流程。由于 MiniMax H3 的 API 细节会随版本变化下面对 API 的请求部分保留为接口示意重点演示工程编排逻辑。你在实际使用时把generate_video_with_h3函数体内的请求参数替换为官方最新文档的字段即可。5.1 创建项目结构与配置先建立工程目录并把配置信息写进config/settings.yaml。# 文件路径config/settings.yaml drama_name: 月台 genre: 现代都市悬疑情感 art_style: 写实电影风低饱和色调 camera_style: 手持纪实感 api: # 云端 API 模式 base_url: https://api.example.com/v1 api_key: 替换为你的API密钥 model: minimaxh3 max_context_chars: 6000 local: # 本地 ComfyUI 模式 comfyui_url: http://127.0.0.1:8188 checkpoint_name: minimaxh3_v1.safetensors audio_vae_name: minimax_h3_audio_vae_fp32.safetensors steps: 305.2 读取配置与角色设定创建workflow/utils.py# 文件路径workflow/utils.py import json import yaml from pathlib import Path def load_yaml(path: str) - dict: with open(path, r, encodingutf-8) as f: return yaml.safe_load(f) def load_json(path: str) - dict: with open(path, r, encodingutf-8) as f: return json.load(f) def save_json(data, path: str) - None: Path(path).parent.mkdir(parentsTrue, exist_okTrue) with open(path, w, encodingutf-8) as f: json.dump(data, f, ensure_asciiFalse, indent2)创建config/characters.json{ hero: { name: 周延, appearance: 30岁中等身材黑色中长外套眼神锐利右眉有一道浅疤, costume: 深灰色卫衣黑色长裤 }, girl: { name: 林小满, appearance: 26岁长发清秀, costume: 米白色毛衣深色半裙 } }5.3 将剧本解析成场次与分镜实际项目中这一步可以用 LLM 自动抽取。为方便演示这里我们手工构造一个场次 JSON保存到data/scenes/sc002.json{ scene_id: SC002, location: 废弃车站月台, time: 夜晚, weather: 小雨, characters: [ { character_id: hero, emotion: 愤怒但克制, position: 画面左侧 }, { character_id: girl, emotion: 恐惧, position: 画面右侧 } ], logline: 周延发现林小满偷偷报警后两人在月台对峙。, shots: [ { shot_id: SC002_SH001, type: 中景, duration: 6s, desc: 雨夜月台周延从远处走来脚步越来越快。, dialogue: 林小满电话是你打的吧, sound: 雨声、脚步声 }, { shot_id: SC002_SH002, type: 近景, duration: 5s, desc: 林小满低头握着手机身体微微发抖。, dialogue: 我……我只是不想看你去伤人。, sound: 雨声、轻微抽泣 } ] }5.4 构造 API 生成脚本下面写一个视频生成编排脚本。核心逻辑是遍历每个分镜构造 Prompt调用 MiniMax H3 接口把返回的视频保存到data/outputs。# 文件路径workflow/generate_shot.py import time import requests from pathlib import Path from utils import load_yaml, load_json, save_json from build_context import compose_prompt def generate_video_with_h3(prompt: str, settings: dict, output_path: Path) - str: 调用 MiniMax H3 视频生成 API。 注意这是接口示意具体参数请以官方最新文档为准。 api_conf settings[api] headers { Authorization: fBearer {api_conf[api_key]}, Content-Type: application/json } payload { model: api_conf[model], prompt: prompt, # 不是所有接口都支持这些参数这里只是演示结构 duration: 6, resolution: 1280x720, fps: 24 } url f{api_conf[base_url]}/video/generate resp requests.post(url, headersheaders, jsonpayload, timeout30) resp.raise_for_status() data resp.json() # 模拟轮询异步任务 task_id data.get(task_id, demo_task) video_url poll_task_result(task_id, headers, api_conf[base_url]) video_bytes requests.get(video_url).content output_path.parent.mkdir(parentsTrue, exist_okTrue) output_path.write_bytes(video_bytes) return str(output_path) def poll_task_result(task_id: str, headers: dict, base_url: str, max_wait: int 120) - str: 轮询异步任务结果这里只示范结构。 for _ in range(max_wait): r requests.get( f{base_url}/video/task/{task_id}, headersheaders, timeout10 ) r.raise_for_status() status r.json().get(status) if status succeeded: video_url r.json()[output][video_url] return video_url if status failed: err_msg r.json().get(error, 未知错误) raise RuntimeError(f视频生成失败: {err_msg}) time.sleep(3) raise TimeoutError(等待任务完成超时) def main(): settings load_yaml(config/settings.yaml) character_lib load_json(config/characters.json) scene_data load_json(data/scenes/sc002.json) outputs_dir Path(data/outputs) save_json(scene_data, data/parsed_scenes/sc002.json) for shot in scene_data[shots]: prompt_text compose_prompt( settings, character_lib, scene_data, shot ) print(f正在生成镜头: {shot[shot_id]}) output_path outputs_dir / f{shot[shot_id]}.mp4 video_file generate_video_with_h3(prompt_text, settings, output_path) print(f镜头已保存: {video_file}) # 将生成结果记录到清单方便后续拼接 scene_data.setdefault(generated, []).append({ shot_id: shot[shot_id], file: str(video_file), prompt_len: len(prompt_text) }) save_json(scene_data, data/parsed_scenes/sc002_with_result.json) print(全部镜头生成完成) if __name__ __main__: main()你要特别留意几点compose_prompt是我们第 4 节实现的上下文拼接函数。它保证了每个镜头请求都带着“全局风格角色状态镜头目标”。poll_task_result是异步任务通用的轮询处理方式防止请求超时后任务丢失。输出文件命名直接使用shot_id有利于后续按顺序拼接。5.5 本地 ComfyUI 调用思路如果你不想走云端 API而是使用本地 ComfyUI 工作流思路也类似。你并不需要 Python 写一套完整 API只需要让 Python 脚本向 ComfyUI 的 WebSocket/HTTP 端口提交一个 workflow JSON。可以先用 ComfyUI 的节点界面把工作流搭好然后把workflow.json导出使用 ComfyUI API 格式提交。下面是一个提交工作流的通用示例# 文件路径workflow/submit_comfyui.py import json import requests def submit_workflow(workflow: dict, base_url: str http://127.0.0.1:8188): 向 ComfyUI 提交一个 workflow。 prompt_data workflow[prompt] response requests.post( f{base_url}/prompt, json{prompt: prompt_data}, timeout10 ) response.raise_for_status() result response.json() print(任务提交成功prompt_id, result.get(prompt_id)) return result.get(prompt_id)在这个工作流里面你同样需要把build_context.py生成的 Prompt 文本填入模型的text输入框。同时还需要注意checkpoint 等大模型文件需要放在 ComfyUI 对应模型目录。Audio VAE 文件需要放在音频 VAE 节点要求的目录。如果报错value not in list: vae_name: minimaxh3\\minimax_h3_audio_vae_fp32.safetensors意思是当前节点下拉列表里没有这个文件。多半是文件放错目录或者文件名大小写不匹配。5.6 视频拼接脚本镜头全部生成以后可以用 ffmpeg 或 moviepy 将视频按顺序拼接。简单起见我们直接用 moviepy。# 文件路径workflow/assemble_video.py from pathlib import Path from moviepy.editor import VideoFileClip, concatenate_videoclips def assemble_shots(video_dir: Path, output_path: Path) - str: 将多个分镜视频按照 shot_id 排序后拼接。 video_files sorted( list(video_dir.glob(*.mp4)), keylambda p: p.stem ) clips [] for video_file in video_files: # 如果原视频时长与分镜要求不一致也可以在此处做转场或变速 clip VideoFileClip(str(video_file)) clips.append(clip) final_clip concatenate_videoclips(clips, methodcompose) final_clip.write_videofile( str(output_path), fps24, codeclibx264, audio_codecaac, threads4, presetmedium ) return str(output_path) if __name__ __main__: result assemble_shots( video_dirPath(data/outputs), output_pathPath(data/final/short_drama_sc002.mp4) ) print(f成片已输出到: {result})真实项目中你还会处理片段之间的淡入淡出、叠化转场、字幕烧录。这些可以基于剪辑软件也可以在 Python 里继续扩展。关键是把分镜顺序和最终成片顺序对应起来。6. 常见问题与排查思路6.1 上下文用量满了怎么办现象提交请求时平台/工具提示“上下文用量已满”或“超出最大 Token 限制”。可能原因把所有历史镜头、超长剧本一次性追加进同一次请求。角色设定库没有做裁剪每个角色带着大段背景描述。前序镜头摘要过长没有经过压缩。解决思路排查点操作请求文本长度统计 prompt 字符数确认是否超出限制全局信息只保留会影响画面风格的字段删掉与当前镜头无关的角色历史镜头用一到两句摘要替代完整镜头原文代码逻辑使用第 4 节的分页窗口策略减小单次上下文# 查看 prompt 长度示例 python -c from workflow.build_context import compose_prompt; print(len(compose_prompt(...)))最稳定的做法不是不断降低文本长度而是在进入 API 前主动做压缩层。如果一个镜头的生成需要依赖前面 20 个镜头你应该让模型维护一个“剧情状态摘要”而不是把 20 个镜头全丢进去。6.2 ComfyUI 提示“请安装缺失的包以使用此工作流”现象加载别人分享的工作流模板时顶部红色提示缺包运行时报ModuleNotFoundError。原因工作流使用了自定义节点但这些节点并未安装到当前 ComfyUI 环境。排查步骤按下 Ctrl Shift L 或在节点管理器中查看缺失节点名称。到ComfyUI/custom_nodes目录检查对应项目是否存在。进入缺失项目目录执行pip install -r requirements.txt。完全重启 ComfyUI。特别是 H3 这类模型节点可能要求安装safetensors、transformers、torchaudio、einops等依赖。安装完之后最好确认一下 Python 环境是否和 ComfyUI 用的是同一个解释器。6.3 value not in list: vae_name 报错现象在 ComfyUI 节点里选择音频 VAE 时下拉列表里找不到minimax_h3_audio_vae_fp32.safetensors。可能原因模型文件没有放入正确的 VAE 目录。文件扩展名大小写不一致。节点读取目录路径发生错误。解决思路检查 ComfyUI 模型的目录结构。一般 VAE 相关文件要求放在models/vae而不是models/checkpoints。如果节点要求文件路径带有minimaxh3子目录你需要保持目录结构一致。ComfyUI/models/ ├── checkpoints/ │ └── minimaxh3/ │ └── minimaxh3_v1.safetensors └── vae/ └── minimaxh3/ └── minimax_h3_audio_vae_fp32.safetensors如果不确定打开 ComfyUI 节点的 py 文件查看它遍历的目录是哪几个。6.4 角色一致性差、换镜头后像换演员这个不是报错但比报错更让人头疼。原因多数是上下文里没有足够强的角色视觉锚点。比如你第一场写“黑色中长外套”第二场忘了写模型就默认给角色换了衣服。解决方法是把外貌特征字段做成“强制注入”。不要指望模型记得历史对话你要在每次请求里都带上视觉锚点。可以在config/characters.json中维护一个anchor_prompt字段作为角色外观硬约束。{ hero: { name: 周延, appearance: 30岁中等身材黑色中长外套眼神锐利右眉有一道浅疤, costume: 深灰色卫衣黑色长裤, anchor_prompt: A man in his early 30s with a sharp look, wearing a dark gray hoodie and a black long coat, short black hair, a visible scar above his right eyebrow. } }当模型支持英文提示或更细粒度提示时英文锚点有时更稳定。不过不要为了锚点牺牲中文剧本语义建议在脚本中同时保留中英文双字段。6.5 视频生成结果过短且无法拼成长剧现象每个镜头只能生成 5 到 10 秒拼成长片后节奏很怪镜头之间缺少衔接。原因长视频短剧并不等于“AI 一次性生成很长的一整段视频”而是通过工作流把叙事拆解成可生成的短视频片段再用工程手段保证连续性。解决思路单镜头时长不宜过长重点保证画面明确、动作单一。在分镜 JSON 中加入prev_shot_summary字段让后一镜头继承前一镜头的方向。拼接时增加转场例如叠化、匹配剪辑降低不同片段之间的跳跃感。在后期为整场戏统一配背景音乐和调色 LUT提升成片一致性。7. 最佳实践与工程建议7.1 为每一场戏建立“上下文快照”不要临时拼 Prompt。建议在开始生成一场戏之前先把该场所有需要的信息生成一个 JSON 快照文件。这个文件既方便回滚也方便后续排查为什么某镜头角色穿错了衣服。推荐快照结构{ scene_id: SC002, global_settings: { art_style: 写实电影风 }, character_snapshot: { hero: { appearance: 30岁黑色中长外套右眉浅疤, costume_in_this_scene: 深灰色卫衣黑色长裤 } }, previous_scene_summary: 第一场周延发现手机里有一段录音决定去月台质问林小满。, shots: [] }每次生成完一个镜头就把该镜头的实际画面描述更新到previous_scene_summary。做连续剧情时这种“滚动摘要”机制比把所有镜头都塞进上下文更实用。7.2 设置自动进度记录避免断点重来长视频生成过程中单镜头失败、接口超时、显卡显存不足都可能中断。如果脚本没有断点续传一旦第 10 个镜头失败前面 9 个镜头也要重新生成这对本地部署来说成本很高。可以在每次成功生成后把完成标记写入本地数据库或 JSON 文件# 文件路径workflow/track_progress.py import json from pathlib import Path PROGRESS_FILE Path(data/generation_progress.json) def mark_done(shot_id: str, video_path: str) - None: progress {} if PROGRESS_FILE.exists(): progress json.loads(PROGRESS_FILE.read_text(encodingutf-8)) progress[shot_id] video_path PROGRESS_FILE.write_text( json.dumps(progress, ensure_asciiFalse, indent2), encodingutf-8 ) def is_done(shot_id: str) - bool: if not PROGRESS_FILE.exists(): return False progress json.loads(PROGRESS_FILE.read_text(encodingutf-8)) return shot_id in progress然后在generate_shot.py主循环中增加判断for shot in scene_data[shots]: shot_id shot[shot_id] if is_done(shot_id): print(f跳过已完成镜头: {shot_id}) continue # 生成逻辑... mark_done(shot_id, output_path)这样即使中途任务中断下次重新执行也可以跳过已完成镜头节省大量时间。7.3 安全与最小权限原则短剧创作涉及上传剧本、角色设定、视频素材到云端 API。建议遵守以下边界不要上传未经授权的他人肖像、品牌标识、受版权保护的素材。使用 API Key 时不要硬编码在公共仓库里建议使用环境变量注入。涉及批量删除生成结果、覆盖原始文件时先备份到backup目录。在正式批量生成前用 1 个测试镜头验证 Prompt 效果再进行全量生成。export MINIMAX_API_KEY你的密钥在 Python 中读取import os api_key os.getenv(MINIMAX_API_KEY) if not api_key: raise RuntimeError(请先设置 MINIMAX_API_KEY 环境变量)7.4 镜头拼接时保留一条“剪片清单”很多人生成完视频后直接用文件名排序拼接。但实际创作中模型生成的某个镜头内容可能不够理想需要重拍。这时如果丢了“剪片清单”后期会非常混乱。我建议维护一个data/assembly_plan.json{ scene_id: SC002, plan: [ { order: 1, shot_id: SC002_SH001, file: data/outputs/SC002_SH001.mp4, duration: 6, transition: cut }, { order: 2, shot_id: SC002_SH002, file: data/outputs/SC002_SH002_retry.mp4, duration: 5, transition: dissolve } ] }有了这个清单你可以自由替换具体镜头文件而不改变叙事顺序。7.5 性能与成本控制短剧生成往往不是一次性的而是反复测试的过程。建议控制三个指标单个镜头重试次数。同一个镜头不要超过 3 次如果每次差异太大优先修改上下文而不是继续抽卡。分辨率档位。初剪阶段使用较低分辨率和步数确认剧情后再用高质量参数做最终输出。并发度。如果使用云端 API注意并发限制如果使用本地 ComfyUI队列任务过多可能导致显存溢出。8. 总结与下一步学习路线到这里你应该对 MiniMax H3 长视频短剧工作流有了一个系统性认识。我们从概念上区分了“上下文”和“工作流”从工程上拆出了剧本解析、角色设定、分镜生成、视频生成、音频、拼接这六大模块也通过一个模拟工程示例走通了从结构化场次数据到最终生成镜头的流程。代码本身不一定能直接复制后在你电脑上一次性跑通因为 MiniMax H3 的 API 参数、ComfyUI 节点名称、模型文件路径都在快速迭代。但本文真正希望你掌握的是那套可以迁移的上下文设计方法局部镜头始终携带全局风格、角色视觉锚点、当前剧情目标并把每次生成结果登记成一个可回溯的记录。下一步建议你分三条路径继续加深工具路径熟悉 ComfyUI 自定义节点安装、工作流导入、模型目录规范把第 5 节的视频生成逻辑映射成可视化节点。工程路径把分镜 JSON、上下文构造、视频生成、断点续传封装成独立 Python 模块做成一个可批量跑短剧分集的命令行工具。创作路径从一场两分钟的戏开始尝试记录不同 Prompt 上下文下生成画面的差别积攒你自己的短剧风格库和负面提示词库。在实际项目中先不要贪心做几十集的连续剧先把“单场戏、两个角色、三个镜头”跑顺。等你能稳定控制单场戏的角色一致性和人物状态再逐渐扩展到跨场次、跨集数才能真正驾驭长视频工作流。如果这篇文章对你有帮助建议先收藏备用后面实操遇到问题随时回来对照排查。