MiniMax H3 提示词里的 `<d>` 标记、说话人 ID 与旁白怎么写

写 MiniMax H3 的提示词，画面部分其实是最好上手的——你把镜头、动作、运镜描述清楚，剩下的交给模型。真正会翻车的是有人说话的部分：谁在说、说的是哪句、这句是画内还是画外、跨镜头之后还是不是同一个人。MiniMax 官方在仓库里附带的 h3-prompt-writing skill（skills/h3-prompt-writing/references/base-en.txt）对这一块给的规则，比画面部分硬得多，几乎条条都是「必须这样写」而不是「建议这样写」。

这篇就把对白、说话人 ID 与旁白这一段拆开讲，顺带把一个很多人忽略的事实串进来：<d> 不是官方发明的一个排版符号，它是模型 tokenizer 里实打实的特殊 token。

先说清楚 <d> 到底是什么

截至 2026-08-09 的仓库 README，在讲 H3-Encoder 时提到一句：H3-Encoder 使用 Qwen3-VL-32B 的完整预训练权重，把其第 50 层的 hidden states 提供给 H3-Omni-Transformer，并且在 tokenizer 配置中新增了若干特殊 token，例如 <d>。README 紧跟着给出一条强制要求：使用 H3 时，必须用 H3 仓库提供的 tokenizer 与相关配置文件。

这两句话合起来，解释了一件平时不会想到的事：<d> 之所以要原样写、不能翻译成中文的「对白：」也不能换成引号，是因为它在 tokenizer 配置里是被专门登记过的特殊 token。官方并没有展开说改动它会以什么形式失败，但「必须使用本仓库提供的 tokenizer 与相关配置文件」这句要求本身已经说明：特殊 token 对不上就是个问题，不是可以将就的细节。

所以提示词写作规范里那句「必须逐字保留标签」，不是格式洁癖，它和加载哪份 tokenizer 是同一个问题的两面。

说话人 ID：(S1)、(S2)、(S1,S2)

base-en.txt 的规则很直接：说话、唱歌、或者发出画外人声的主体，使用稳定 ID (S1)、(S2)；当多个已经编号的说话人同时说或同时唱时，用复合 ID (S1,S2)。

有两条约束是判断依据，容易被略过：

第一，同一个说话人跨镜头保持同一个 ID。 也就是说 ID 是绑在「人」上的，不是绑在「这句台词」上的。第 1 个镜头里那位女士是 (S1)，切到第 4 个镜头她再开口，还得是 (S1)。很多人写着写着按出场顺序重新编号，等于告诉模型这是另一个人。

第二，从不发声的角色不给说话人 ID。 画面里站着三个人只有一个人说话，那就只有一个 (S1)，另外两位照常描述外貌与动作，但不编号。ID 系统是给声音用的，不是给出场人物做花名册。这一条反过来也能当自检用：如果你的提示词里出现了一个从头到尾没有台词的 (S3)，那多半是写错了。

首次出现要给足身份信息。 官方要求说话人第一次出现时，要从视听上下文给出足以确立稳定身份的信息，并且点名了可用的维度：角色类型、年龄、性别、是否在画面内、音高、音色、语速、口音。这里的关键词是「稳定」——后面几个镜头模型要靠这些线索保持同一把嗓子，所以第一次露面时越省，后面越容易漂。反过来，第二次、第三次出现就不必把这一串再抄一遍，ID 已经把身份接住了。

<d> 里面放什么、外面放什么

这是整节里最重要的一条分工规则，官方写得毫不含糊：

说话人的身份描述、ID、动作与表演方式写在 <d> 之外；<d> 里面只放语言标签与用户给的实际台词内容，必须逐字保留原始词句与标点，不许翻译或改写。

官方给的两个示例：

The young woman with a quiet, breathy voice (S1) says: <d>[English] I get off at the next station.</d>
The two children (S1,S2) shout together, <d>[English] Wait for us!</d>

看这两行的切法：嗓音是「quiet, breathy」、动作是「shout together」、ID 是 (S1) 和 (S1,S2)，全都在标签外面；标签里面只剩一个语言标签加一句原话。

这条规则的实用价值在于它给了你一个明确的落笔位置。写提示词时最常见的纠结是「这个人说得很急」该塞哪儿——按规则，表演方式属于外面。同理，「她一边说一边转身」也在外面。只要你想描述的东西不是台词本身的字面内容，它就不该进 <d>。

另外注意 <d> 内部那个 [English] 语言标签。SKILL.md 的输出规则里还有一条与之呼应：改写的章节用英文书写，但对白、歌词与画面可见文字保留原语言。也就是说描述用英文写，台词是什么语言就写什么语言，语言标签负责说明这一段是哪种语言。你要生成一句中文台词，正确做法是外面用英文描述说话人，<d> 里放中文原句，而不是把中文台词先翻成英文。

旁白：固定短语加一句嘴唇闭合

旁白是这套规范里唯一给了「确切短语」要求的地方：必须使用 says in an off-screen voiceover。不是「narrates」，不是「in a voiceover」，就是这一串。

而且官方还加了一条更反直觉的要求：每个旁白 <d> 块之后，必须紧接着说明对应的在场角色嘴唇保持闭合。示例是这样的：

The man (S1) says in an off-screen voiceover: <d>[English] I still remember that road.</d> while his lips remain completely closed.

第一次读到会觉得多此一举——都说了是画外音了，还要再交代一遍嘴不动？可以从架构那一侧理解这条要求的位置：README 讲 H3-Omni-Transformer 时说它是联合预测视频与音频的 latent，画面与声音出自同一次预测而不是两条独立管线。旁白要的恰恰是「有人声、无口型」这种画音不一致的组合，官方把「嘴唇保持闭合」写成必须紧跟在旁白 <d> 块之后的硬要求，等于要求你把这份不一致显式说出来，而不是指望模型自己猜。官方没有给出违反这条会发生什么的说明，但既然它被写成规则，就按规则来。

顺带说一句：旁白同样要走 ID 系统。上面的例子里旁白者是 (S1)，因为他确实发声了——ID 的判据是「发不发声」，不是「在不在画面里」。

台词跨切点：<scenetrans> 与 <cutoff>

一句台词或一段歌词横跨镜头切点，是很常见的剪辑手法，H3 给了专门的标签：

• 同一句台词或歌词跨越切点时，在两段的衔接处使用 <scenetrans>，并明确说明音频跨切点延续；
• 台词被视频结尾截断时使用 <cutoff>。

这两个不是一回事，判断很简单：声音后面还有画面接着，用 <scenetrans>；声音说到一半整个视频没了，用 <cutoff>。

光有标签还不够，官方要求「明确说明音频跨切点延续」，并给了四种可用的连续性表述：

官方给出的表述	字面直译
continues seamlessly across the cut	无缝地跨过这个切点继续
continues uninterrupted into the next shot	不中断地进入下一个镜头
carries over from the previous shot	从上一个镜头延续过来
remains audible across the transition	在整个转场期间保持可闻

四条都是官方原表给的，右列只是字面直译，官方并没有说明它们之间有什么差异。真要说区别，也只是叙述视角不同——carries over from the previous shot 是站在新镜头里往回指，另外三条是站在切点上往前说。所以别指望换个说法就有质变，挑一条能把你这处衔接讲准的就行。

真正要记住的是：<scenetrans> 和连续性表述是配套的，只丢一个标签而不说明音频延续，等于只标了位置没说要干什么。

画面文字：英文双引号，逐字不翻译

横幅、招牌、标签、字幕、霓虹灯这类画面里可见的文字，规则同样是硬的：放进英文双引号里，逐字保留原文与标点，不许翻译。官方示例直接给了个中文的：

A red neon sign reading "营业中" glows above the doorway.

这里的双引号和 <d> 是一类东西——都是给模型划边界的记号，只不过一个划的是「要被念出来的内容」，一个划的是「要被画出来的字形」。既然是逐字渲染，引号里就别写中文全角引号、别加书名号、别自作主张改成更顺眼的写法。

落笔前的一份自检

把上面几条压成可以逐项过一遍的清单：

1. 每个开口的角色有没有 ID？有没有给从不发声的角色也编了号？
2. 同一个人在不同镜头里的 ID 是不是同一个？
3. 每个 ID 第一次出现时，身份线索（角色类型/年龄/性别/是否在画面内/音高/音色/语速/口音）够不够撑起后面的镜头？
4. <d> 里面是不是只剩语言标签加原话？表演方式、动作、嗓音描述有没有误塞进去？
5. 台词有没有被翻译或润色过？画面文字有没有被翻译？
6. 旁白是不是用了 says in an off-screen voiceover 这个确切短语，并且后面紧跟着嘴唇闭合的说明？
7. 跨切点的台词有没有 <scenetrans> 加连续性表述？被结尾截断的有没有 <cutoff>？
8. 所有标签是不是原样保留、没有被翻译成中文标签？

SKILL.md 的输出规则里还有一条兜底要求：保留字段名、章节顺序、标签与时间标注法。对白这一节的所有标签都在「必须保留」的范围内。

两点必须说清的限制

第一，这套写法是官方给的规则，不是效果承诺。 h3-prompt-writing skill 提供的是格式规范与写作指南，官方并没有给出「这样写比那样写效果好多少」的对比数据，本文也没有做过任何生成验证。所以上面每一条的价值在于「不违反官方约定」，而不是「照做画面就会变好」。

第二，自己按规范写提示词，和调用官方 API 不是同一条路。 README 里负责把用户意图整理成这套结构化提示词的 H3-Context-IR 模块目前并未开源，官方给的替代路径是让你按「Prompting Guidance」自行构建上下文处理系统。这意味着你手写出来的提示词哪怕格式完全合规，也不等于能得到与官方 Context-IR 流程相同的结果——中间那层处理逻辑，我们看不到。

如果你要在自己的工程里做提示词生成，比较务实的做法是把这些规则固化成模板与校验：ID 唯一性、<d> 内外分工、旁白短语与嘴唇闭合是否成对出现、跨切点标签是否配了连续性表述。这几项都能用字符串规则检出来，比靠人眼在长提示词里数标签可靠得多。

延伸阅读

• 为什么必须用 MiniMax H3 自带的 tokenizer：从 H3-Encoder 的接口说起
• H3 的 2K 为什么不是超分：H3-Regenerate-2K 的 in-context 重生成读法
• MiniMax H3 的原生立体声是怎么做出来的：H3-AudioVAE 与音视频联合预测

---

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