开源视频模型MiniMax-h3本地部署与Skill工作流实战

最近圈子里讨论度很高的一个话题，是开源AI视频生成模型。很多人看到“生成短剧”“生成漫剧”这些字眼，第一反应是：这不又是那种上传一段文字就吐出一段视频的玩具吗？真正做过内容生产的人会明白，单条视频片段好看没有用，能稳定批量地产出、角色不漂移、镜头能连成故事，才是能不能用来做短剧和漫剧的分水岭。

MiniMax-h3之所以值得关注，不完全是因为它被称为“开源界最强视频模型”这个标签，而是它提供了一个把视频生成能力掌握在自己手里的可能性。配合近期社区里流行的Skill机制，你可以把“写剧本、拆镜头、生成视频、整理素材”这一串动作封装成一个可复用的工作流。本文会把这件事拆开讲清楚：先说明开源视频生成模型到底值不值得本地部署，再讲清楚Skill在其中扮演什么角色，最后给出一个能跑通“剧本到成片素材”的最小实现思路。读完之后，你应该能判断自己的硬件和场景适不适合入坑，也能少走一些无效试错的路。

先给一个明确判断：把MiniMax这类开源视频模型部署到本地，真正的价值不在于“免费”两个字，而在于你可以把整个生成链路做成自己的流水线。云端视频生成服务确实方便，但镜头数量、调用频率、风格一致性、二次开发能力都受限。本地部署后，批量生成、自定义前后处理、和Agent工具链打通，全部由你自己控制。这篇文章就是沿着“模型部署 -> 服务封装 -> Skill工作流”这条线来讲。

1. 从“能生成视频”到“能批量出片”，差距在哪里

很多刚接触AI视频生成的人会有一个错觉：只要模型够强，输入剧本就能自动生成一条完整的短剧。实际上，当前AI视频生成的主流范式仍然偏“单镜头生成”，而不是“整片生成”。一个三分钟的短剧可能需要二十到四十个镜头，漫剧的分镜密度通常更高。每个镜头的生成都需要单独设计画面描述、镜头运动方式、景别和时长。就算模型能输出高画质片段，把这些片段串成叙事完整的剧集，仍然是一个典型的工程问题。

过去解决这个问题有两种常见路径。第一种是纯手工式：一个人坐在电脑前，把剧本一句句改成分镜提示词，逐个镜头丢进在线视频生成工具，生成完下载，再拖进剪辑软件里拼接。优点是没有额外开发成本，缺点是遇到生成效果不稳定的镜头就要反复抽卡，一个几分钟的短剧可能要消耗一个团队一整天的精力。第二种是云端API派：通过官方接口批量调用生成能力，但这类接口通常有配额限制、审核机制和使用成本，对于需要大量测试镜头风格的个人创作者来说，既不够灵活，也不容易做深度定制。

开源模型带来的变化发生在第三层：把生成引擎装在了自己机器上。这样做不只是省调用费，更重要的是你可以自由决定生成策略。你可以调整每个镜头的关键参数，可以让脚本根据前一个镜头的结果自动决定下一个镜头怎么生成，也可以在生成链路中插入角色一致性检查。这个时候，模型只是流水线里的一个环节，真正决定生产效率的是你有没有建立起一条可复用的工作流。

所以，这篇内容真正讨论的不是“哪个模型好看”，而是怎么把一个开源模型变成自己能掌控的视频生成基础设施。MiniMax-h3是当前这个方向上一个很有代表性的落点，但同样的思路也可以迁移到其他开源视频生成模型上。

2. 拆解MiniMax-h3：开源视频生成模型到底强在哪里

2.1 MiniMax-h3是什么

从公开信息来看，MiniMax-h3是MiniMax在视频生成方向上的一个开源模型版本。这里需要注意，它和我们熟悉的大语言模型（LLM）是两类东西。大语言模型处理的是文本序列，给定一段文字，输出新的文字；视频生成模型处理的是“文本条件 + 视觉信号”，给定一段画面描述，输出的是图像帧序列，合起来就是视频片段。

这类模型通常由两大部分组成：一个负责理解文本提示词并把它映射到视觉语义空间的文本编码器，以及一个负责生成帧序列的视频生成主干网络。生成结果的质量取决于训练数据和模型架构，但也不能忽略推理阶段的采样策略。开源意味着权重文件和推理代码是公开可获取的，你可以把它下载到自己的GPU服务器上运行，也可以基于它继续做微调或二次开发。

2.2 开源视频模型的三个能力层级

判断一个开源视频模型够不够用，我习惯把它拆成三个能力层级来判断。

第一层是单镜头画质。这个镜头到底清不清晰、主体形态是否自然、画面构图是否符合描述。这层能力是模型最直观的体现，也是评测视频里最容易被夸大的部分，因为模型提供方通常会选效果最好的片段做演示。

第二层是语义跟随能力。也就是模型能不能理解复杂的提示词，比如“主角从画面左侧走入，镜头缓慢推进，背后是下雨的街道，霓虹灯反射在地面积水上”。语义跟随差一点的模型会忽略镜头运动，或者把场景元素画错。

第三层是角色与场景一致性。短剧、漫剧这类叙事内容最依赖这一层。同一个角色在第一集和第二集里长得像不像？同一间房间在不同镜头里布局是否接近？这一层能力往往不是单靠提示词就能解决的，需要靠合理的分镜设计、固定随机种子、参考图控制等手段配合。

这正好呼应了全文的观点：MiniMax-h3能不能算“最强”，取决于你拿它跑哪一类任务。单镜头静态画质强的模型，不一定在角色一致性上更好。更务实的做法是找一个风格贴合内容方向的开源模型，把测试集固定下来，逐一验证上述三层能力。

2.3 “开源界最强”这个说法该怎么看

这里要澄清一点。当我们说“开源界最强AI视频模型”时，是一句面向话题传播的简化表述。严谨一点说，在不同评测维度、不同风格数据下，结论可能完全不同。如果你准备做写实风格的短剧，你会更关注人物姿态自然度和镜头连贯性；如果你做二次元漫剧，你会更关注线条稳定性和上色风格统一度。不存在一个模型在所有维度上都碾压其他模型。

对开发者来说，“最强”这个词更值得转化成两个问题：它的权重和推理代码是否真的开放？它的模型协议是否允许我用在工作流里，甚至做商用分发？后面这个问题在实际项目中往往比单帧画质更关键。

有一个需要特别强调的安全边界：标题里经常出现的“破限制”，不少人会理解成绕过模型的生成限制或破解付费墙。这不是本文讨论的事，也不应该去尝试这类操作。真正可行的“破限制”，是把生成链路从单一在线平台的限制中搬出来，通过本地部署和服务化，让镜头数量、批量生成节奏、自动重试策略都由你自己控制。这才是把精力花在部署和工作流上的真正原因。

2.4 部署的现实约束

开源视频模型和开源大语言模型在部署上的最大区别是资源消耗。文本模型可以在消费级显卡上跑，视频模型通常需要更大的显存、更高的显存带宽，以及更长的推理时间。所以在计划本地部署之前，先确认自己的机器条件。具体需要多少显存、什么架构的GPU，要以模型仓库的官方说明为准，不要只看网上的压缩教程。一个稳妥的开局思路是：先在在线Demo或租用的云端GPU上跑一批镜头，确认生成风格满足内容需求，再决定是否投入本地硬件。

3. 本地部署不是终点，Skill工作流才是关键

3.1 传统短剧生成流程为什么让人崩溃

如果只用一句话描述传统AI短剧生产的问题，那就是“每个环节都要人肉盯”。编剧写完剧本后，得有人把它拆成符合镜头语言的场景描述；拆完之后，每个镜头都要人工输入到视频生成工具；生成出来的视频如果角色不像，得重新调整提示词再生成一遍；最后把可用片段下载下来，在剪辑软件里按叙事顺序排列。整个过程里，真正的创意劳动被大量重复性操作稀释了。

3.2 什么是Agent，什么是Skill

要解决这个痛点，需要借助Agent和Skill这套工具思路。

Agent可以理解为一个能调用工具、能执行多步骤任务、能根据中间结果调整计划的AI执行体。它不再是一问一答的聊天框，而是给一个目标，由它分解步骤去完成。

Skill则是Agent可以加载的一套“领域知识包”，通常包含流程说明、提示词模板和辅助脚本。可以这样类比：Agent像一个能力强但缺少行业经验的新员工，Skill就是一份把某个岗位的关键SOP沉淀下来的操作手册。员工阅读操作手册后，就能按标准流程把事情做出来。

在编码领域，已经有很多类似的例子，比如Claude Code里的专用Skill，让AI在接手代码任务时自动加载相应的编码规范、测试流程和工具脚本。放在视频生成场景里，思路完全一致：把“剧本 -> 分镜 -> 生成视频 -> 校验输出”这个过程写成Skill，Agent在收到“帮我生成一部三分钟漫剧”的指令时，不再凭空猜测，而是按Skill里的步骤和脚本执行。

3.3 MiniMax-h3 + Skill 的组装逻辑

把MiniMax-h3和Skill组合起来，整个系统分成了四层。

第一层是推理引擎，也就是本地部署好的MiniMax-h3模型。它负责接收一个镜头描述，生成对应的短视频片段。这一层通常是一个独立的GPU进程。

第二层是服务封装。为了让上层脚本能方便地调用模型，需要把它封装成HTTP接口。前端脚本只需要发送一个包含提示词和参数的请求，不需要关心模型内部加载了多少个检查点。

第三层是Skill定义。这一层规定了完整的生产流程：分析剧本、切分镜头、为每个镜头生成结构化提示词、调用第二层的服务、保存结果、生成物料清单。

第四层是Agent调度。用户只需要说清楚要做什么类型的内容、多长、什么风格，Agent按Skill里的步骤依次执行。

这种分层架构的好处是每一层都可以独立替换。今天底层跑的是MiniMax-h3，明天换成其他开源模型，只要第二层接口约定不变，上层Skill不用改；今天用Claude Code，明天换成其他支持Skill的Agent工具，只要Skill目录和脚本符合通用约定，也能低成本迁移。

3.4 “一键免废生成”的真实含义

不需要像以前那样逐个镜头手工生成，也不按镜头次数付费，这就是“一键免废成片”的实指。需要付出的实际成本是本地GPU的算力、电费，以及搭建第一版工作流的开发时间。这个交换到底划不划算，取决于你的使用频率。只偶尔生成几条短视频，使用在线工具更方便。如果一个月要产出几十集短剧、漫剧，或者要大量测试分镜风格，本地部署加Skill工作流的价值就会快速显现。

4. 本地部署：环境规划、模型准备与服务化

4.1 整体部署思路

为了保证文章里的操作步骤不依赖某个特定模型版本，这里给出的是一种通用流程。MiniMax-h3或其他开源视频生成模型的具体安装命令，请以它的官方仓库README为准。下面的内容重点演示如何用“服务化”思路把模型跑成一个可调用的HTTP接口。

先看整体架构：

剧本文本 | v Skill 脚本（拆分镜头、构造提示词） | v HTTP 请求（POST /generate_shot） | v 本地推理服务（加载 MiniMax-h3 权重） | v 视频帧序列 -> 编码为 mp4 文件

4.2 检查硬件环境

模型推理前，先确认GPU环境可用。下面三个命令分别查看显卡、CUDA驱动状态和磁盘空间。

nvidia-smi

free -h

df -h /workspace

如果执行nvidia-smi能列出GPU型号和显存信息，说明驱动可用。如果看不到GPU，先检查驱动是否安装、容器是否映射了GPU设备。接下来确认Python环境和推理框架。

python --version pip list | grep torch

具体版本的匹配规则以模型官方文档为准。视频模型对PyTorch和CUDA版本的组合比较敏感，直接按照仓库要求的版本安装最稳妥，不建议擅自升级到最新版。

4.3 获取模型和基础推理代码

以Hugging Face（或国内镜像）为常见来源，克隆模型仓库或用git lfs拉取权重文件。如果你在中国大陆网络环境下，可以考虑使用国内开源镜像站来加速，具体域名不同项目有差异，请参考模型卡页面说明。

git lfs install git clone https://huggingface.co/YourOrg/MiniMax-h3-Example cd MiniMax-h3-Example pip install -r requirements.txt

这里用YourOrg/MiniMax-h3-Example只是一个占位符，真实仓库地址请以官方公告为准。请特别留意权重文件和推理代码发布的来源，认准官方账号或官方认证的镜像组织，避免下载到修改过、捆绑了恶意代码的“破解版”权重。

4.4 把推理进程封装成HTTP服务

模型代码通常自带命令行推理示例，但这不适合当工作流接口。更推荐封装一个常驻内存的HTTP服务，避免每个镜头都重新加载一次权重。

这里用一个Flask服务示例说明封装方式。假设模型仓库里已经有一个VideoGenerator类，提供generate(text_prompt, duration, seed)方法。现在要做的就是把它包成一个Web服务。

# 文件路径：server/video_service.py import os import tempfile from flask import Flask, request, jsonify, send_file # 实际使用时，根据模型仓库的接口调整导入路径 # from minimax_h3_example import VideoGenerator app = Flask(__name__) generator = None def load_model(): global generator # 这里只是示例，真实模型加载参数以官方代码为准 generator = VideoGenerator( model_path=os.environ.get("MODEL_PATH", "./weights"), device="cuda" ) @app.route("/health", methods=["GET"]) def health(): return jsonify({"status": "ok"}) @app.route("/generate_shot", methods=["POST"]) def generate_shot(): data = request.get_json() prompt = data.get("prompt", "") duration = float(data.get("duration", 3.0)) seed = int(data.get("seed", 42)) if not prompt: return jsonify({"error": "prompt is required"}), 400 try: output_path = os.path.join(tempfile.gettempdir(), f"shot_{seed}.mp4") generator.generate(prompt=prompt, duration=duration, seed=seed, output_path=output_path) return send_file(output_path, mimetype="video/mp4") except Exception as exc: return jsonify({"error": str(exc)}), 500 if __name__ == "__main__": load_model() app.run(host="0.0.0.0", port=8000)

这段代码里的VideoGenerator是占位实现，你在实际项目中需要替换成模型仓库自带的生成器类。这里真正重要的是接口约定：/health用于探活，/generate_shot接收JSON里的prompt、duration、seed参数，返回一个视频文件。

启动服务的方式：

export MODEL_PATH=/path/to/weights python server/video_service.py

启动后，在另一个终端发一个测试请求：

curl -X POST http://127.0.0.1:8000/generate_shot \ -H "Content-Type: application/json" \ -d '{"prompt": "一个穿着白色连衣裙的女孩走在雨后的街道上，镜头从侧面缓慢推进", "duration": 3, "seed": 20250101}'

如果服务返回的是mp4文件或“file saved”相关成功信息，说明本地推理服务已经跑通。

这个环节真正容易踩坑的地方是模型加载阶段。很多视频生成模型在加载权重时会消耗大量显存，如果服务器上同时有多个GPU进程，要先确认显存占用。可以用nvidia-smi监控，如果加载过程报CUDA Out Of Memory，优先降低进程并发数，或者把推理分辨率先调小验证逻辑。

5. 用 Skill 封装“短剧/漫剧一键生成”工作流

本地推理接口已经就绪，现在到了最有价值的部分：把整套生成流程封装成Skill。

5.1 Skill设计核心：从剧本到分镜的拆解

既然要做短剧或漫剧，就不能只生成一个孤立的视频镜头。Skill必须能理解“剧本”这种叙事文本，把它分解成多个可生成的镜头。

一个最小可用流程如下：

1. 读取用户输入的剧本或故事概述。
2. 把剧本按叙事段落拆成场景，再按动作拆成镜头。
3. 为每个镜头生成结构化的画面描述，包含主体、动作、环境、天气/光线、镜头运动、景别。
4. 调用第4章封装的/generate_shot接口生成视频。
5. 把所有输出文件写入一个以作品名命名的目录，并生成物料清单。

5.2 Skill目录结构

下面是一个建议的Skill目录布局。这个结构借鉴了当前主流的Agent Skill机制：一个SKILL.md描述使用场景，多个辅助脚本处理具体任务。

ai-video-generator/ ├── SKILL.md └── scripts/ ├── split_screenplay.py └── generate_shot.py

在实际的Agent工具中，Skill一般放在指定目录，例如Claude Code的~/.claude/skills/或项目级.claude/skills/目录下。具体方法请查阅你所用Agent工具的Skill文档，不同工具加载机制略有差异。

5.3 编写 SKILL.md

SKILL.md是这个Skill的说明书，也是Agent理解何时该用它的关键。文件前半段是YAML格式元数据，后半段是详细的工作流程指导。

--- name: ai_video_generator description: 用于生成短剧、漫剧、短视频分镜。当用户要求把剧本、故事、小说章节生成视频镜头，或希望批量创作视频素材时，使用该技能。 ---

然后是正文部分，用来告诉Agent执行标准：

# AI 视频生成工作流 ## 目标 把一段叙事文本拆分为多个镜头脚本，并调用本地部署的视频生成服务，批量生成MP4视频素材。 ## 步骤 1. 阅读用户提供的剧本，识别主要角色、场景、情节推进。 2. 使用 split_screenplay.py 将剧本拆分为结构化的镜头JSON文件。 3. 逐个读取镜头JSON，使用 generate_shot.py 调用本地服务。 4. 将生成文件保存到 `./output/<project_name>/` 目录，并在该目录生成 `manifest.json` 物料清单。 5. 如果某个镜头生成失败，连续重试2次，并记录错误原因。 ## 注意事项 - 每个镜头的 prompt 必须包含主体、动作、环境、镜头运动。 - 同一剧集中，若角色重复出现，保持角色外观描述一致。 - 生成前先调用 /health 接口检查服务是否在线。

5.4 镜头拆分脚本 split_screenplay.py

这个脚本的作用是把一段自然语言剧本转成结构化的镜头JSON。实际项目中可以接入兼容OpenAI格式的大模型接口来完成语义解析，下面给出框架代码。

# 文件路径：ai-video-generator/scripts/split_screenplay.py import json import sys def load_playwright_text(file_path): with open(file_path, "r", encoding="utf-8") as f: return f.read() def build_shot_structures(script_text): """ 这里用最简逻辑演示分镜过程。 真实场景下建议调用大模型来解析剧本，按场景和动作拆分。 """ paragraphs = [p.strip() for p in script_text.split("\n") if p.strip()] shots = [] for idx, para in enumerate(paragraphs): shot = { "shot_id": idx + 1, "narration": para, "prompt": f"{para}，电影感构图，高细节", "duration": 3.0, "seed": 1000 + idx } shots.append(shot) return shots def main(): script_file = sys.argv[1] output_file = sys.argv[2] if len(sys.argv) > 2 else "shots.json" text = load_playwright_text(script_file) shots = build_shot_structures(text) with open(output_file, "w", encoding="utf-8") as f: json.dump({"shots": shots}, f, ensure_ascii=False, indent=2) print(f"拆分完成，共 {len(shots)} 个镜头，结果保存在 {output_file}") if __name__ == "__main__": main()

5.5 单镜头生成脚本 generate_shot.py

这个脚本读取分镜JSON，逐个调用本地HTTP服务。这里默认使用的是第4章定义的/generate_shot接口。

# 文件路径：ai-video-generator/scripts/generate_shot.py import json import os import sys import time import requests def call_generate_shot(prompt, duration, seed, service_url): resp = requests.post( f"{service_url}/generate_shot", json={"prompt": prompt, "duration": duration, "seed": seed}, timeout=(10, 120) ) resp.raise_for_status() return resp.content def main(): shots_file = sys.argv[1] output_dir = sys.argv[2] service_url = os.environ.get("VIDEO_SERVICE_URL", "http://127.0.0.1:8000") os.makedirs(output_dir, exist_ok=True) with open(shots_file, "r", encoding="utf-8") as f: data = json.load(f) manifest = [] for shot in data["shots"]: shot_id = shot["shot_id"] prompt = shot["prompt"] duration = shot["duration"] seed = shot["seed"] output_path = os.path.join(output_dir, f"shot_{shot_id}.mp4") try: content = call_generate_shot(prompt, duration, seed, service_url) with open(output_path, "wb") as f: f.write(content) manifest.append({ "shot_id": shot_id, "file": output_path, "status": "success" }) print(f"[成功] shot_{shot_id} -> {output_path}") except Exception as exc: manifest.append({ "shot_id": shot_id, "file": output_path, "status": "failed", "error": str(exc) }) print(f"[失败] shot_{shot_id}: {exc}") time.sleep(1) manifest_path = os.path.join(output_dir, "manifest.json") with open(manifest_path, "w", encoding="utf-8") as f: json.dump(manifest, f, ensure_ascii=False, indent=2) print(f"物料清单已生成: {manifest_path}") if __name__ == "__main__": main()

把两个脚本组合起来，执行流程就可以用两个命令完成。先拆镜，再生成：

python ai-video-generator/scripts/split_screenplay.py screenplay.txt shots.json

python ai-video-generator/scripts/generate_shot.py shots.json ./output/my_first_drama

到这里，“一键生成”的骨架已经成立：后面只要让Agent读一次SKILL.md，它就会自动完成这个过程，不需要每次手工敲命令。

6. 运行验证与效果检查

服务启动后，先做一次单人单镜头的冒烟测试。执行下面的命令，确认服务状态和接口返回都正常。

curl -X GET http://127.0.0.1:8000/health

预期返回{"status":"ok"}。接着用一张简单的分镜JSON做全流程测试，不要一开始就拿整部短剧去压测。

判断成功的标准有两条。第一，manifest.json里所有镜头的status都是success。第二，用视频播放器打开生成的MP4文件，画面内容与镜头描述匹配，时长与设置基本一致。

如果失败，第一步不是改Skill脚本，而是先确认本地服务是否还活着。查看服务进程所在终端有没有报CUDA错误、超时信息。第二步用最小请求测试接口本身，排除上层脚本的问题。按这个顺序排查，通常能快速定位问题发生在服务层还是工作流层。

7. 常见问题与排查方法

以下是本地部署视频模型和搭建Skill工作流时最高频的几类问题，整理成排查表：

8. 最佳实践与合规提醒

8.1 不要把“开源”等同于“完全自由”

拿到一个开源模型后，第一件事不是急着部署，而是读许可证。开源视频模型的授权条款差异很大，有的允许商业使用，有的只允许研究用途；有的允许对权重做微调再分发，有的明确限制派生模型。MiniMax-h3的具体条款要以官方仓库LICENSE文件为准。如果准备做付费短剧内容，更要提前审核这些条款，避免内容上线后产生授权纠纷。

8.2 生成内容的合规使用

AI生成的视频内容，尤其是人物、场景高度接近真实世界时，要注意发布平台的AI生成内容标识要求。做漫剧时也要确保角色设计不侵犯他人著作权、肖像权。关于深度合成内容的管理规定，不同地区和平台要求不同，稳妥的做法是在发布时主动标注AI生成，并对内容素材来源做记录。

8.3 用“种子+模板”控制角色一致性

角色一致性是叙事类视频最核心的体验指标。一个很实用的策略是在拆分脚本时，把角色的外观固定成一段描述模板，并分配到同一批固定种子。在SKILL.md的注意事项中也可以写明：同一角色出现时，描述必须复用模板原文，不能随意改写。否则模型会把“穿白色连衣裙的女孩”和“白衣女孩”理解为两个不同形象，导致主角不断“换脸”。更专业的做法是引入参考图控制网络，但基础版本先用提示词模板和固定种子就能获得明显改善。

8.4 工程化建议

本地视频生成任务通常比较耗时，建议在工程上做好三件事。

第一，日志。每个镜头的请求参数、耗时、输出路径、成功与否都记录到结构化日志里，方便分析失败规律。第二，缓存。相同seed和相同prompt的镜头不需要重复生成，用文件的MD5或参数构建缓存键，命中缓存直接复制文件。第三，重试策略。视频生成是一类随机性较强的任务，偶发失败是正常现象。对失败镜头可以使用不同重试次数，如果连续失败，再进入人工检查，避免无限循环烧卡。

# 把服务地址固定写入环境变量，避免每个终端都设置一次 echo 'export VIDEO_SERVICE_URL=http://127.0.0.1:8000' >> ~/.bashrc source ~/.bashrc

9. 总结与后续学习方向

这篇文章想讲清楚的核心问题很简单：AI视频生成要真正服务短剧、漫剧生产，关键不在某个模型的单帧效果有多惊艳，而在于你能否把“剧本 -> 分镜 -> 镜头生成 -> 素材管理”这个过程变成一套稳定可控的流水线。MiniMax-h3这类开源模型负责提供生成能力，HTTP服务化负责把能力变成可编程接口，Skill负责把专业流程固化成标准操作步骤。三者拼在一起，才算是迈进了“一键成片”的门槛。

看完文章，建议按这个顺序动手练习：先租一台云GPU跑通一个视频生成模型，不改任何工程代码，只体验不同提示词对画面结果的影响；然后按第4章把模型包成HTTP接口；接着按第5章写一个最小Skill，先支持“简单剧本 -> 固定种子 -> 批量生成”；最后再渐进引入角色模板、重试策略、缓存机制。

下一阶段值得深入的方向有三块：一是角色一致性的高级控制方案，比如参考图控制、LoRA微调；二是镜头拼接的自动化，让生成出来的片段能按叙事节奏自动选优、排序；三是Agent调度策略的优化，让AI在跑完整条流水线的过程中自动处理异常镜头，而不是到某个环节就停下来等人。这些方向一旦走通，开源AI视频模型的应用空间会从“生成素材”扩大到“参与完整创作流程”。建议先收藏这篇文章，真正开始部署的时候再对照着做，能少踩不少坑。