H3 提示词的三个核心字段：对齐指令、字段顺序与 Ref2VA 的分工

2026-08-09

很多人第一次看 MiniMax H3 的提示词示例，反应是”这也太长了”。一段本该两句话说清的画面描述，被拆成对齐指令、镜头编号、时间戳、说话人 ID、三个下划线命名的字段，看着像在填表而不是在写创意。

看久了会发现，它确实就是在填表。H3 的提示词不是一段自然语言描述，而是一份有固定章节的结构化文档。理解它的关键不是记住每条规则，而是先搞清楚：哪几个部分是模型必须拿到的，哪几个部分是可以省的，以及为什么这些字段名一个字都不能改。

下面全部依据 MiniMax 官方仓库 MiniMax-AI/MiniMax-H3 里自带的 h3-prompt-writing skill（skills/h3-prompt-writing/），核对日期 2026-08-09。我们没有部署过 H3，也没有发起过任何一次生成请求，讲的是官方文档口径。

先把这套东西的来源定位清楚

官方 README 给的安装命令是这一条：

npx skills add https://github.com/MiniMax-AI/MiniMax-H3 --skill h3-prompt-writing

README 说明 h3-prompt-writing 是本仓库附带的九个 skill 之一，另外八个是风格化的视频生成 skill，比如 minimalist-product-ad-generator、3d-animation-short-generator、brand-promo-video-generator 等等。那八个我们只取到了文件名和目录结构，没有读过正文，所以这篇不谈它们的内容。

真正要读的是 h3-prompt-writing 目录下 references/ 里的两份指南，它们的分工是硬性的：

文件	覆盖范围
`references/base-en.txt`	文本模式与关键帧模式，也就是 T2VA / I2VA / FL2VA / L2VA
`references/ref-en.txt`	全参考模式 Ref2VA

这个分工值得先记住，因为它直接决定了你该按哪套章节结构写。两份指南给的是两套不同的输出骨架：base-en.txt 那套是”对齐指令 + 三个核心字段”，ref-en.txt 那套是六个章节的长表。如果你手上有参考视频却照着 base-en.txt 的三字段写，或者只是纯文生视频却硬套 Ref2VA 的六段式，都属于走错了门。

仓库里同时提供了 .claude/skills/h3-prompt-writing/ 与 .agents/skills/h3-prompt-writing/ 两套同内容目录，还有 skills-lock.json。也就是说这套指南本来就是给 agent 读的，人工照抄只是其中一种用法。

五种输入模式：分的不是风格，是你手上有什么

SKILL.md 给出的五种模式定义如下：

模式	含义
T2VA	从文本构建完整的视听时间线
I2VA	从首帧出发，向前发展
FL2VA	描述首帧到尾帧之间的连续路径
L2VA	推断一个合理的开头，最终收束到给定的尾帧
Ref2VA	全参考模式

判断依据很简单：模式不是你挑的，是你手上的素材决定的。 没图就是 T2VA，只有一张首帧就是 I2VA，只有一张尾帧就是 L2VA，首尾都有就是 FL2VA，有参考图/视频/音频要”复用其中的内容”才走 Ref2VA。

base-en.txt 对其中两种的定义更精确，这一层是理解整套结构的关键：I2VA = T2VA 主体 + 首帧对齐指令 + 从首帧向前发展的视觉路径；FL2VA = T2VA 主体 + 首尾帧指令 + 从首帧到尾帧的连续路径。

换句话说，I2VA 和 FL2VA 并不是另外三种写法，它们的躯干就是 T2VA，只是在最前面多加了一行对齐指令，并且在描述里明确路径的起点和终点。这解释了一个常见的困惑：“我给了首帧，是不是就不用写画面了？“不是，主体描述一行都不能少，首帧只是把时间线的 0 秒钉死了。

对齐指令：一行文字，三条原文，一个两位小数

对齐指令的作用是告诉模型”你给我的参考图对应目标视频的哪一时刻”。这一部分 T2VA 没有，直接从三个核心字段开始写。其余三种模式各有一条固定文本。

I2VA 固定使用：

For the target video, at 0.00 seconds into the target video, <Picture 1> (from [Shot 1]) is fully referenced.

FL2VA 固定使用：

How the reference pictures align with the target video — Picture 1 (from Shot 1) aligns with the 0.00-second mark of the target video; Picture 2 (from Shot N) aligns with the S.SS-second mark of the target video.

L2VA 固定使用：

How the reference pictures align with the target video — <Picture 1> (from [Shot N]) aligns with the S.SS-second mark of the target video.

其中 N 是实际最后一个镜头的序号，S.SS 是有效视频时长，必须精确到两位小数。

这里有三处容易翻车，都值得单独拎出来：

第一，两位小数不是排版洁癖。 写 8 或 8.0 都不符合指南要求，得写成对应的两位小数形式。这套提示词里所有时间标注都是同一个路数——镜头切点写成 At 00:03.500 这样的形式，对齐指令写成 S.SS——时间在 H3 的提示词里是被当作可解析的字段处理的，不是给人看的说明文字。凡是格式上”看起来无所谓”的地方，先按原样写，别自作主张简化。

第二，指令必须是最终提示词的第一行，之后空一行再写核心字段。 不是放在开头附近，是第一行；不是紧接着写下一段，是中间要有一个空行。这条在 base-en.txt 里是明写的。

第三，L2VA 的指令里，N 是最后一个镜头的序号，不是 1。 尾帧对应的是片尾，所以它引用的是 [Shot N]，对齐到 S.SS 秒。而 I2VA 那条引用的是 [Shot 1]、对齐到 0.00 秒。这两条一头一尾，抄错了方向，等于把时间线接反。

另外注意 FL2VA 那条的写法和另外两条不完全一致——它用的是不带尖括号的 Picture 1、Shot 1，I2VA 与 L2VA 那两条用的是 <Picture 1>、[Shot 1]。这是官方原文的样子，抄的时候原样保留就好，不要”顺手统一一下”。

三个核心字段：顺序固定，各管一层声音

对齐指令写完、空一行之后，就是三个核心字段，顺序固定：

integrated_multimodal_description: [Shot 1] ...

overall_soundscape: ...

non_diegetic_music: ...

职责划分是这样的：

字段	职责
`integrated_multimodal_description`	沿时间线描述画面、动作、镜头、说话人、对白、演唱与场景内音频
`overall_soundscape`	总结全片的环境音、动作物理音、非语言人声
`non_diegetic_music`	描述角色听不到、只有观众能听到的背景音乐

第一次读的人最容易问的问题是：既然第一个字段已经包含了”场景内音频”，为什么还要单开两个声音字段？

分界线是”这个声音在故事世界里存不存在”，这正是 non_diegetic（非叙事性）这个词的字面含义。角色说的话、脚步声、雨声、店里放的收音机，都是故事世界内部的声音，所以前两个字段管；片子的配乐、情绪铺垫用的弦乐，角色是听不到的，只有观众听得到，归 non_diegetic_music。

而前两个字段之间的分界，是”随时间变化”和”贯穿全片”。integrated_multimodal_description 是沿时间线走的，第几秒切镜、谁在说话、说了什么，都挂在这条线上；overall_soundscape 是全片层面的总结，描述整体的环境音底噪、动作物理音和非语言人声，不绑定到具体时刻。

按这个划分，写的时候顺序是有实际意义的：先把时间线铺完，再回头总结全片声场，最后决定要不要配乐。反过来先想配乐，往往会写出一堆无法落到时间线上的形容词。

为什么字段名一个字都不能改

SKILL.md 的 Output Rules 明确要求：保留字段名、章节顺序、标签与时间标注法。这三个下划线命名的字段名必须原样保留，不许翻译成中文，不许改成更顺眼的名字。

只说”规范要求”其实说服不了人。更有说服力的依据在模型这一侧：H3 在 tokenizer 配置里新增了特殊 token，比如对白标记 <d>。也就是说，提示词里这些看起来像标记语言的东西，有一部分是被 tokenizer 当作独立 token 认下来的，不是普通文本。对白必须写在 <d> 里面，正是因为它是对白边界的标记；同理，官方明确要求使用 H3 时必须用 H3 仓库提供的 tokenizer 与相关配置文件——特殊 token 对不上就会出问题，具体会出什么问题官方没有展开，我们也不做推断。

<d> 的用法本身也有相当硬的规矩：说话人的身份描述、ID、动作与表演方式写在 <d> 之外，<d> 里面只放语言标签和用户给的实际台词内容，且必须逐字保留原始词句与标点，不许翻译或改写。官方给的示例形如：

The young woman with a quiet, breathy voice (S1) says: <d>[English] I get off at the next station.</d>

同一句台词或歌词跨越切点时用 <scenetrans>，台词被视频结尾截断时用 <cutoff>。这几个标签也是同一个道理——原样保留，别翻译成中文标签。

字段名的情况是不是也走 tokenizer 这一层，官方文档没有说明，我们不替它推断。但能确定的有两条：<d> 这类标记在 tokenizer 配置里确实有对应的特殊 token；Output Rules 又把字段名、章节顺序、标签与时间标注法一起点名要求保留。改动它们的收益完全没有依据可查，代价却可能落在你看不见的那一层，那就没有必要去赌。

Ref2VA 走的是另一套骨架

如果你的输入里有参考图、参考视频或参考音频，那么上面这套三字段结构就不适用了，要按 ref-en.txt 的六段式写，章节顺序同样固定：subject_definitions → summary → retention_analysis → detailed_description → overall_soundscape → non_diegetic_music。

可以看出来，最后两个字段和基础模式是重合的，前面四段是 Ref2VA 独有的。它引入了四类参考标签：

标签	含义
`<Subject N>`	从参考素材中抽象出的、可在目标视频中复用或修改的可见内容
`<Picture N>`	作为具体目标帧或镜头规划锚点的参考图像
`<Video N>`	提供剪辑源、续写起点或整片时间结构的参考视频
`<Audio N>`	被复制或被参考的音频信号

官方原文强调：一旦某段内容被指派了标签，它在六个章节中的含义必须保持不变。 retention_analysis 这一段则要记录每一项参考内容出现在哪里，以及它是完全保留、部分保留、迁移还是复用。

这篇不展开六段式的细节，只提醒一点：<Picture N> 这套标签在基础模式的对齐指令里也出现了。同一套标签体系横跨两份指南，所以真正需要区分的不是”标签怎么写”，而是”我该按三字段还是六段式组织全文”。

一条必须说清的边界：自建流程不等于官方结果

最后这一条，比上面所有格式规则都重要。

按 README 的系统总览，H3 由三个模块组成，其中 H3-Context-IR 并未包含在本次开源发布中——它负责把复杂的多模态输入深度理解并精炼成模型易于理解的中间表示，官方对它的评价是对最终输出质量至关重要，因此强烈建议要么把它接进你的生成流水线（走 API），要么按 Prompting Guidance 自建一套上下文处理系统。

h3-prompt-writing 这套 skill 正是后面这条路。这意味着：照这套规则手写或用 agent 生成结构化提示词，是官方给出的替代路径，不等于能得到与官方 API 相同的结果。 官方文档给的是写法规则，没有给任何效果对比数据，我们也没有做过任何测试，所以这里不存在”自己写能达到几成”的说法——这个问题目前没有可引用的答案。

对应到实际决策，大概是这么个分岔：

你要复现官方工作流的行为、或者需要 2K 输出（那要走同样未开源的 H3-Regenerate-2K），那就得走官方 API；
你要在本地跑开源的 H3-Base，那么前面这层上下文处理就得自己补上，h3-prompt-writing 是官方指路的做法；
无论走哪条，提示词的结构规则是同一套，这也是为什么值得先把格式吃透——它是两条路的公共部分。

另外提一句发布状态与能力的区别：这类”官方支持但本次没开源”的模块，在 H3 里不止一处。看到 README 说系统具备某项能力时，要顺手确认一下对应模块的开源状态，两者不是一回事。

落笔前的自检清单

按 base-en.txt 写完一份基础模式提示词，可以对照下面几条过一遍：

模式选对了吗——有没有图、有几张、是首帧还是尾帧，决定了要不要写对齐指令、写哪一条；
T2VA 不写对齐指令，其余三种各有固定原文，抄的时候连标点一起抄；
对齐指令是第一行，后面跟一个空行；
S.SS 写成两位小数，N 指向实际最后一个镜头；
三个字段名原样保留、顺序不变；
对白只放在 <d> 里、逐字保留原文，身份与表演描述放在外面；
手上有参考素材的话，别用这套，去看 ref-en.txt 的六段式。

规则看着琐碎，但它们全都指向同一件事：这份提示词是按官方规定的骨架填出来、再喂给模型的结构化输入，不是写给人看的分镜脚本。凡是拿不准的地方，回 skills/h3-prompt-writing/references/ 翻原文，比自己推测靠谱。

延伸阅读

本文依据 MiniMax H3 官方仓库（github.com/MiniMax-AI/MiniMax-H3）的 README、模型配置文件与官方 h3-prompt-writing skill 文档整理，核对日 2026-08-09。本文内容为官方仓库口径，未在本机部署或调用过 H3。模型、部署方式与许可条款以官方最新说明为准。