企业官网建设流程全解析

MiniMax H3 这波热度，真正值得关注的不是“又出了一个能生成视频的模型”，而是围绕它出现的一整套内容生产方法：机甲 AI 女团、AI 漫剧、数字人、MV，这些玩法背后共用同一套能力——把视频模型从“单条抽卡”变成“角色化批量生产”。如果你正好想做一个固定形象的虚拟偶像，或者想用短剧形式做系列内容，这套流程比单纯堆提示词有用得多。

这篇文章适合两类人：一类是已经在用 ComfyUI 或类似工具跑过 AI 视频，想进一步提升成片稳定性的人；另一类是做自媒体、短剧、音乐可视化，需要固定角色和固定分镜风格的人。下面我会把环境准备、人设提示词、分镜表、批量生产、数字人落地和常见报错排查完整过一遍，重点说为什么这么做，而不只是怎么做。

1. H3 Remix 真正要解决的问题：角色一致性，而不是单条视频质量

1.1 为什么机甲 AI 女团比一般短视频更容易翻车

单条 AI 视频生成已经不难了。输入一句提示词，几秒钟后出来一段酷炫镜头，这类内容在社区里非常多。但“机甲 AI 女团”不是单条视频，而是一个系列内容：多个成员、多个场景、多段表演，最后还要拼成漫剧或者 MV。

系列内容和高光片段最大的区别，是观众会记住角色。上一集里面队长是银白色长发、红色瞳孔、穿蓝白色机甲战甲，下一集如果变成了黑色短发、紫色眼睛，整个 IP 就崩了。视频模型本身没有长期记忆，它只根据当前提示词和输入参考生成内容，不会自动记住“这是我的队长”。

这就是为什么很多人在单独生成时觉得效果惊艳，一旦做系列就完全没法用。不是模型能力不够，而是工作流里缺少“角色锁定”这个环节。你每次生成时，必须把角色的核心描述、参考图、风格关键词、负面提示词全部重新喂给模型，并且要保持高度一致。

1.2 Remix 在工作流里的实际定位：先锁定角色，再谈生成

Remix 这个功能在 H3 相关的玩法里很关键，但容易被误解。它不是用来“凭空创造一个新角色”，而是用来“基于已有素材做二次创作”。常见的用法是：先做出一张或几帧角色设定图，再通过 Remix 把设定角色放进新的场景、动作或情绪里。

这正好解决女团核心痛点。你可以先用文生图或者图生图的方式确定五个成员的初始设定，之后所有视频生成都围绕这些设定图展开，而不是每次都从零描述。Remix 的价值在于：让模型在“保持身份”的前提下“改变环境”。

所以我的建议是，不要一上来就追求什么逆天特效，先把一个角色在不同场景下的生成测试跑稳定。只有角色一致性问题解决了，漫剧、MV、数字人才有基础。

1.3 哪些人适合这套玩法，哪些人先别急着上

适合的人有三类。

第一类：已经能稳定跑通 AI 图片生成，想往视频方向扩展的内容创作者。第二类：想做连续短剧、漫剧，需要多个固定角色和固定画风的团队或个人。第三类：做数字人直播、知识博主分身、虚拟偶像演唱会的技术爱好者。

不适合的人也有三类的特征。

第一种，还没有跑通过任何 AI 视频生成，连基础提示词怎么写都还没搞清。第二种，不愿意整理素材，生成完不归档，每次都是临时找图、临时写词。第三种，期待“一键”真的就能什么都不管直接出成片。事实是，所谓一键，是把人设卡、分镜模板和 Skills 都提前做好之后，调用时才显得像一键。

2. 开始之前：本地部署、云端 API 和素材清单怎么选

2.1 本地部署的硬件底线和依赖检查顺序

如果你选择本地部署 H3 相关的模型和 ComfyUI 整合包，第一个要确认的不是功能列表，而是硬件能不能扛住。视频生成和图片生成不一样，它要同时处理空间和时间两个维度，显存占用会明显更高。

在常见环境下，我个人会建议至少满足以下条件再考虑本地跑：

• NVIDIA 显卡，显存 12GB 起步，16GB 以上会更从容。
• 系统内存 32GB 左右，低于 16GB 会在处理长视频时明显吃力。
• 磁盘剩余空间要充足，模型权重、中间缓存、输出视频都要占地方。
• 驱动和 CUDA 版本要和整合包要求一致，这一步最容易翻车。

低配机器能不能跑？能，但要把分辨率、生成时长和并发数都降下来。比如 4 秒 720p 可能勉强能跑，硬上 10 秒 1080p 就会爆显存或者生成速度慢到没法用。

检查顺序建议是：先看显卡驱动，再看 Python 和 PyTorch 版本，接着跑一次官方自带的小示例，最后才跑你自己的角色测试。很多人上来直接加载大模型，报错了也不知道是显卡问题、依赖问题还是模型文件不完整。

2.2 云端 API 和本地 ComfyUI 整合包的取舍

是走云端 API 还是本地部署，没有绝对答案，取决于你的使用频率和成本敏感度。

如果你只是做几条尝鲜视频，云端 API 更方便，不用折腾环境，注册后拿 Key 就能用。缺点也很明显：长任务要等排队，批量生成时单条成本会累积，而且你要把图片、提示词全部传到服务端，素材管理会稍微受限。

如果你要做系列化内容，尤其是漫剧和 MV 这种动辄几十个镜头的项目，本地 ComfyUI 整合包更合适。它能让你把工作流保存下来，方便批量修改参数，也方便后续接 Skills 做自动化。缺点是需要你自己维护环境，遇到依赖冲突要会排查。

我见过不少人两边都用：先用云端确认提示词和风格方向，确定下来之后再用本地批量产出。这个思路比较务实。

2.3 开工前必须准备好的四类素材

开工前把素材整理好，能少走很多弯路。建议准备四类东西。

第一类：角色设定图。每个成员至少一张正面全身、一张半身特写，背景越干净越好，方便模型识别角色本体。机甲类角色要特别注意：胸甲、肩甲、核心能源装置这些标志性部件不要频繁更换设计。

第二类：音乐或音频参考。做 MV 时，要提前确定歌曲的时长、节奏和段落结构。分镜是跟着音乐走的，不是视频生成完再配乐。

第三类：台词或歌词文本。AI 漫剧涉及对话，歌词涉及口型对应，文本要提前写好并分好句。

第四类：分镜脚本。哪怕是简单的几行字，也能帮你减少大量试错。后文会专门讲分镜表怎么写。

3. 机甲女团提示词：人设卡、外观描述和风格锁

3.1 人设卡的结构：身份、外貌、服装、性格、标志动作

提示词工程听起来高大上，但在女团角色这个场景里，核心就一件事：让模型在每次生成时都“记住同一个角色”。最好的办法不是随机写一大段描述，而是先建立每个人物的人设卡。

一个可复用的人设卡可以包含以下字段：

人设卡示例：

角色名：星野 身份：MED-01 女团队长 外貌：银白色长发，高马尾，红色瞳孔，右眼角有一颗小痣 服装：白蓝相间机甲战甲，胸口六边形能量核心，右肩有队长徽章 性格：冷静果断，语速偏快，情绪激动时瞳孔会发光 标志动作：右手举到胸前，掌心凝聚蓝色光点 常见语气：坚定、简洁，偶尔带一句俏皮话

写人设卡的两条经验：

第一，外貌描述要尽量具体，避免“漂亮”“帅气”这类主观词。模型不理解“酷”，但理解“机甲、金属质感、蓝白配色、高马尾”。

第二，把最核心的 20 到 30 个词固定下来，每次生成时都原样复制，不要这次写“银白长发”，下次写“白色短发”。微小的描述差异，经过模型放大后就是明显的外貌变化。

3.2 机甲元素的描述方式：别堆形容词，要写结构

机甲类角色最容易出的问题是：单独看每个镜头很帅，连续看几段就发现机甲细节一直在变。原因是用词太泛。

比如“炫酷机甲”这种描述，模型每次给出的都是不同的机甲设计。正确做法是描述结构：

• 头部：头盔式面甲，露出眼睛部分，额头有 V 型灯带
• 躯干：紧身战斗服外覆盖轻甲，胸口有六边形能量核心
• 手臂：前臂装甲明显加厚，手背有能量导管
• 腿部：大腿外侧有推进器，膝盖有关节护甲
• 配色：蓝色为主，白色为辅，能量部位用青色发光

把部件描述固定下来，比堆十个风格形容词有效得多。这也是为什么人设卡里要单独拆出“服装”一栏，不要和整体外貌混在一起。

3.3 负面提示词和种子：保持同一个角色不“变脸”

除了正面描述，还要维护一份负面提示词，把经常破坏画面稳定性的内容写进去。比较通用的是：多余的手指、变形的手、文字水印、脸部变形、多只眼睛、服装突变。机甲场景还要加一条：部件错位。

种子值也很重要。同一个设定和同一个种子，生成的画面会更接近。如果你在测试时发现某个镜头特别满意，记录下种子和完整提示词，后面做系列内容时可以作为参考基准。

这里有个容易被忽略的点：负面提示词并不是越多越好。写太多反而会干扰模型对主体内容的理解。建议维护一个不超过十项的负面词清单，针对自己角色最容易出的问题做增减。

注意：不要把所有希望都放在负面提示词上。面部和服装一致性最好的解决办法依然是参考图，提示词只是辅助锁定方向。

4. 分镜设计：把 MV 和 AI 漫剧拆成可执行的镜头表

4.1 分镜的最小单位：景别、时长、动作、台词

做 AI 视频和拍真人视频最大的不同，是你不能在现场指挥演员，你只能在生成前把所有要求写清楚。所以分镜脚本必须足够细，细到每个镜头单独生成都不会跑偏。

一个最小的 AI 分镜表字段大概是这样：

注意，画面内容要写“发生了什么”，不要写“好帅”“炸裂”这类情绪评价。模型能处理的是可视的动作和场景。

4.2 MV 分镜和漫剧分镜的差异

MV 和漫剧的分镜逻辑不一样，不能共用一个模板。

MV 是跟着音乐走的。你需要先听音乐，标出前奏、主歌、副歌、间奏的起止时间，再分配镜头。副歌部分通常需要全景和大动作镜头，主歌部分多给半身景和特写，间奏可以插入空镜或队员独舞。分镜表里要增加“音乐段落”这一列，方便对照。

AI 漫剧则是跟着叙事走的。它更接近“动态漫画加配音”，重点是台词、对话节奏和情节推进。漫剧分镜要额外考虑：这组镜头表达什么信息，观众能不能看懂逻辑。建议按“场景—对话—反应—动作”来拆，而不是按音乐段落拆。

实际做的时候，可以先做一个总表，再拆成两份分镜头表，分别给 MV 和漫剧使用。

4.3 用分镜 Skills 固定自己的叙事模板

如果你要做多集内容，每集都重新写分镜表会很累。这时候把常见结构固化成 Skills 模板，就能明显提速。

比如一个“标准漫剧八镜头模板”可以是：

1. 场景建立镜头（远景）
2. 角色入场镜头（全景）
3. 两人对话正反打（中景）
4. 反应特写（近景）
5. 冲突动作镜头（全景）
6. 事件结果镜头（中景）
7. 主角回应特写（近景）
8. 悬念收尾镜头（远景）

MV 模板也可以用类似方式固化，比如“前奏空镜—主歌独唱—副歌群舞—间奏独舞—第二段主歌—最终副歌—结尾定格”。

把这些模板存成文档，每次做新内容时复制出来改细节，而不是从零开始，效率会高很多。这也是“Skills 下载”这类玩法的本质：它不是魔法，是把经验结构化。

5. 从单条测试到批量生产：数字人和 MV 的落地顺序

5.1 第一次测试只做一件事：跑通一条 4 秒镜头

无论你的目标多宏大，第一次测试都不要贪多。我建议第一次只做一条 4 秒镜头，用一个角色、一个场景、一个动作。

为什么是 4 秒？

第一，4 秒接近短视频平台单镜头可用的最短时长，试出来能用就直接进素材库。第二，短镜头生成速度快，试错成本低。第三，4 秒能暴露大部分技术问题，比如动作是否穿帮、画面是否跳变。

测试时把参数记录下来：模型版本、采样步数、时长、分辨率、种子、提示词全文。这一步看着麻烦，但能省掉之后大量重复测试。

5.2 批量生成必须解决的三件事：命名、队列、失败重试

单条跑通之后，接着就是批量。批量最忌讳的就是“一次性把二十个镜头全部提交，然后不管了”。

批量生成前，先把命名规则定好。推荐格式：

剧名_集数_场次_镜头号_版本号

例如：

med01_ep01_s02_shot03_v2.mp4

这样命名有几个好处：方便排序、方便对照分镜表、方便多版本对比。如果你只用一个通用名字，后面全部镜头堆一起，根本分不清哪个是哪个。

第二个要解决的是队列。不要一次性把任务全部塞进去，建议分批提交，比如一次三到五个镜头。好处是：如果提示词或参数有问题，你只浪费了三到五个镜头的生成时间，而不是全部任务都产出废片。

第三个是失败重试。批量任务一定会遇到失败，可能是超时、显存溢出、输出路径错误。不要盲目重跑，先看日志判断失败原因。如果是输入问题，重跑多少次都一样。

5.3 数字人场景的特殊要求

如果把这套流程用到数字人，不管是直播还是短视频出镜，要注意几个额外问题。

第一是口型同步。歌词或台词文本必须按句切分，每句话的长度要匹配对应视频段落的时长。文本切分不对，口型对不上，后段全部白做。

第二是表情管理。普通人说话是有表情变化的，AI 数字人最怕全程面无表情。分镜表里要给每个数字人镜头配上情绪词：微笑、严肃、惊讶、挑眉。然后把这些情绪词写进提示词，不要只写“她在说话”。

第三是动作幅度。数字人直播时动作太大会显得不自然，动作太小又会像木偶。一般在独白镜头，动作幅度控制在小幅度的手势即可，比如抬手、点头、轻微侧身。剪到副歌或转场时再放大动作。

6. 常见问题排查：先看输入，再改参数

6.1 视频动作前后不一致

“动作前后不一致”和“视频视频动作不一”，是社区里反馈比较多的一个问题。现象是同一个镜头里，明明是同一个人，手部动作或者身体姿态在几秒钟内突然变化。

排查顺序：

1. 先看输入参考图。参考图是否统一，角色姿态是否复杂。姿态越复杂，模型越容易在运动过程中“重建”人物，导致变形。
2. 再看运动幅度。运动幅度越大，越容易不一致。先降低动作幅度，验证稳定性。
3. 再检查时长。单人特写镜头 4 秒内变化不大，拉到 8 秒以上就很容易漂移。
4. 最后才考虑改参数，比如降低运动强度、增加参考帧约束。

这里最容易犯的错是：一看到动作不一致就疯狂改模型参数。其实多数情况下是输入参考图和运动幅度的问题。

6.2 画面风格漂移

风格漂移指的是：第一秒还是机甲赛博风，第三秒突然变成了偏写实的风格。

主要原因一般有三个：

1. 风格词汇在提示词里权重不稳定，被场景描述覆盖了。
2. 种子值变化导致画面基底变化。
3. 参考图里混入了风格不统一的图片。

处理方式也很直接。第一，把风格词固定放在提示词的最前面，比如“机甲风格、蓝白配色、青色调光、高对比度”。第二，保持种子值不变，只修改场景部分。第三，检查参考图，确认所有参考图都来自同一套角色设计，不要混用其他风格图片。

6.3 卡住、无输出、速度异常慢

如果任务卡住，不要急着杀进程，先看日志。日志会告诉你卡在哪一步。

常见原因和对应排查：

排查的总原则是：先确认输入和路径，再改参数。很多人上来就把所有参数都换一遍，这样反而找不到根因。

注意：如果本地部署报错信息里出现依赖相关的关键词，优先检查 PyTorch、CUDA 和 ComfyUI 版本是否匹配，这个比重装模型要常见得多。

7. 把提示词和分镜整理成自己的 Skills 资产

7.1 Skills 目录的标准结构

把一次性的提示词变成可复用资产，最有效的方法是建立 Skills 目录。目前社区里常见的 Skills 组织方式，是用 Markdown 文件承载工作流说明和提示词模板。

一个机甲女团项目的 Skills 目录可以参考：

mecha-girl-group/ ├── SKILL.md ├── character-cards/ │ ├── captain.md │ ├── member-01.md │ └── member-02.md ├── storyboard-templates/ │ ├── mv-verse-chorus.md │ └── drama-episode.md └── prompt-libraries/ ├── mecha-style-base.md ├── lighting-presets.md └── negative-prompt-common.md

SKILL.md 是这个包的入口，一般写清楚：这个 Skill 解决什么问题、需要哪些输入、输出是什么、怎么使用。character-cards 存人设卡，storyboard-templates 存分镜模板，prompt-libraries 存通用提示词。

这种结构的好处是：新项目可以直接复制整个目录，改掉人设卡就能复用整套工作流。

7.2 版本管理和素材归档习惯

做系列内容不能只靠记忆力。每改一次人设卡，都应该存一个新版本，不要覆盖原有文件。

建议至少保留两层版本记录：

• 角色设计版本：v1、v2、v3，记录每次修改的时间和原因。
• 分镜模板版本：每套模板记录合适的内容类型和之前跑通的效果。

素材归档可以按集数建目录，里面再分成input、output、review三个子目录。review目录放审核或自检后的意见，方便下一批生成时对照。

这些习惯不复杂，但能避免一个很现实的问题：半个月后你想复用某个角色设计，却找不到当初那套提示词和参考图，只能重新试。

7.3 从一次性生成到系列化 IP 运营

当你把人设卡、分镜表、提示词库和 Skills 都整理好，再回头看“一键生成”，就会明白它真正的含义：所有变量都被你提前控制好了，模型只是执行器。

到了这个阶段，你可以做几件更有价值的事：

• 把整套 Skills 分享给团队其他成员，让大家用同一套角色标准，而不是每人写各自的提示词。
• 把测试成功的镜头按场景归档，建立自己的视频素材库，后续做混剪和宣传片可以直接调用。
• 根据实际生成结果反向优化人设卡，比如发现某个角色的机甲细节经常被画错，就把这部分描述改得更细更稳定。
• 将漫剧、MV、数字人三条产品线拆成三套独立 Skills，共用角色卡，但分镜逻辑各自独立。

踩过几次坑之后你会发现，很多翻车现场不是模型能力不够，而是前置环境、角色锁定和输入材料没有处理干净。把这些基础工作做扎实，MiniMax H3 Remix 这套玩法才能真正从“炫技”变成可持续的内容生产方式。