Ref2VA 的参考标签体系：<Subject N> / <Picture N> / <Video N> / <Audio N> 怎么用

2026-08-09

用 MiniMax H3 的全参考模式（Ref2VA）时，最容易出现的困惑是：素材明明连上了，生成结果却像没看见它们。原因往往不在素材，而在提示词——Ref2VA 不是「把图丢进去，模型自己看着办」，它要求你在提示词里显式指名每一份素材扮演什么角色、被保留到什么程度、出现在画面的哪个位置。这套指名机制就是参考标签体系。

这篇把两边的口径拼起来讲：一边是 MiniMax 官方 h3-prompt-writing skill（仓库内 skills/h3-prompt-writing/references/ref-en.txt 与 SKILL.md，核对日 2026-08-09），另一边是 ComfyUI 官方 R2V 模板（Comfy-Org/workflow_templates 里的 templates/video_minimax_h3_r2v.json，核对日同为 2026-08-09，ComfyUI 对应版本 v0.31.0）。两边用的其实是同一套标签，只是文档分散在两个仓库里，很多人只看了一边。

四类标签，各管一件事

ref-en.txt 给出的标签只有四类，含义是官方原表：

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

这四类的划分标准不是「素材是什么格式」，而是「它在生成里承担什么职责」。<Picture N> / <Video N> / <Audio N> 指的是你交进去的那份文件本身；<Subject N> 指的是你从文件里抽出来的那个东西——一个人、一件衣服、一种画风。所以同一张参考图，既可以是 <Picture 1>（用来锚定某个镜头的构图），也可以从里面抽出 <Subject 1>（那张图里的主角，要出现在别的镜头里）。这两种用法解决的问题完全不同，混着写就会让模型不知道你要的是「照着这一帧画」还是「把这个人搬过去」。

官方对 <Subject N> 的适用范围列了四类：人/动物/物体、场景/背景/环境、服装/道具/界面/视觉特效、风格/动作/表情/姿态。注意后两类——它把「风格」「动作」「表情」也算作 Subject。也就是说，如果你想让目标视频沿用某段参考视频的运动感或某张图的画风，正确做法不是含糊地说「保持这种感觉」，而是把它定义成一个 <Subject N> 并写清楚特征。

六个章节的顺序是固定的

Ref2VA 的提示词是分章节的，官方给的顺序不可调换：

subject_definitions → summary → retention_analysis → detailed_description → overall_soundscape → non_diegetic_music

其中后两个字段与基础模式（T2VA / I2VA 那一套）共用：overall_soundscape 总结全片的环境音、动作物理音与非语言人声，non_diegetic_music 描述角色听不到、只有观众能听到的背景音乐。SKILL.md 的 Output Rules 明确要求保留字段名、章节顺序、标签与时间标注法，所以这些字段名要原样写，不要翻译成中文标题。

顺序固定背后有个更硬的约束：一旦某段内容被指派了标签，它在六个章节中的含义必须保持不变。 这句是原文强调的。实践上意味着你在 subject_definitions 里把 <Subject 2> 定义成「红色夹克」，就不能在 detailed_description 里让 <Subject 2> 变成穿夹克的那个人。标签是全篇的引用键，不是就近生效的临时别名。SKILL.md 在「避免」清单里也点名了悬空未定义的参考标签——正文里出现了 <Subject 3>，但 subject_definitions 里从来没定义过，这是明确要避免的写法。

subject_definitions：什么该单独占一行

subject_definitions 的职责是为后续需要单独追踪的每一项参考内容各起一行，说明这个标签指代什么、它的参考角色是什么、以及需要遵循的主要特征；需要交代来源时点明对应素材。

这里有一条容易被忽略但很省事的规则：如果某个 <Picture N> / <Video N> 只是用来标明另一项内容的来源、后面不会被单独分析或使用，就在那一项的定义里带过，不要单独占一行。

这条规则的价值在于它给了一个判断依据。很多人写 subject_definitions 时会机械地把每个输入槽位都列一遍，结果定义了一堆后面再没提过的 <Picture N>，既冗长又制造了噪声。正确的判断顺序是反过来的：先想清楚目标视频里哪些东西需要被单独追踪，为它们各起一行；至于这些东西从哪张图哪段视频来，在那一行里顺带说明即可。换句话说，条目数量由「需要追踪的内容」决定，不由「上传了几个文件」决定。

retention_analysis：四种取值是给你做取舍用的

retention_analysis 记录每一项参考内容出现在哪里，以及它是完全保留、部分保留、迁移还是复用（fully preserved / partially preserved / transferred / reused）。

这四个词看起来像文档术语，实际是四种不同的意图声明：

fully preserved：原样保留，不希望模型改动它的外观或内容。
partially preserved：保留一部分特征，其余允许变化——比如保留人物长相但换掉服装。
transferred：把某个属性从一处迁到另一处，典型是风格、动作、表情这类可以从素材上「剥离」的东西。
reused：直接复用，常见于素材本身被当作片段用进目标视频（音频复用尤其如此）。

写这一段的收益在于它逼你先想明白取舍。README 里 Ref2VA 那个示例的 summary 带了 [video editing + audio reference + audio reuse] 这样的任务标注，retention_analysis 里出现了 fully_preserved、partially_copy、reference 等取值——可见官方自己的产物也是先把「这次到底要保留什么」定性写下来，再往下写具体画面。如果你跳过这一段直接写 detailed_description，模型只能从描述文字里猜你的意图，而官方明确提醒过：ref2va 的输出对提示词措辞非常敏感，精确匹配参考标签、明确说明哪个参考驱动镜头的哪一部分，效果最好。

ComfyUI 侧：同一套标签，多一条「连接顺序」规则

ComfyUI 官方 R2V 模板（对应教程页 docs.comfy.org/tutorials/video/minimax/minimax-h3）用的是同一套标签体系，但多了一条工程上的约束：提示词里要按连接顺序引用输入，例如 <Picture 1>、<Video 1>、<Audio 1>，官方原文强调「in the exact order they were connected」，之后再描述目标画面、动作与声音。

这一点值得单独强调，因为它是两边体系的接缝所在。在官方 skill 的语境里，编号 N 是你写提示词时自己安排的；到了 ComfyUI 的节点图里，编号被节点连线的顺序决定了。R2V 模板的输入槽位是 ref_images / ref_videos / ref_video_audios / ref_audios 四组，你往 ref_images 上依次接的第一张、第二张图，就是提示词里的 <Picture 1>、<Picture 2>。所以在 ComfyUI 里改工作流时，调整连线顺序等于改动提示词语义——这是个反直觉的耦合点：节点图上一次看似无害的重新连线，可能让整段 subject_definitions 指向错的素材。

R2V 模板里还有几处与本篇直接相关的取值可以对照着看：UNETLoader 加载的是 minimax_h3_ref2va_pruned_int8_convrot.safetensors，模板说明特别强调它「is a different set of weights from the fl2va model used by the t2v/i2v templates」——想同时做 t2v/i2v 和 r2v，两个扩散模型文件都得下。MiniMaxH3ReferenceToVideo 节点上有个 ref_image_size 参数，match 会把参考缩放到生成分辨率、更快；max 保留最高 2048px 短边、identity 保真更强，代价是速度，官方给的原因是「reference tokens ride along every sampling step」（参考 token 会跟着每一个采样步）。这条原因也从侧面解释了为什么参考素材越多、上下文越重。

另外，截至 2026-08-09（ComfyUI v0.31.0）这版模板默认的调度器是 simple，但官方说明自己就写了：对这类参考密集的提示词，beta 或 normal 调度器往往比默认的 simple 表现更好。模板默认值和官方建议不一致，这不是笔误，是需要你自己动手改的一处。模板会随版本更新，动手前先看一眼你本地那份的默认值。

9 / 3 / 3 / 12：真正卡住你的是最后那个 12

参考输入的上限，MiniMax README 与 ComfyUI 模板说明是一致的：

类型	上限
参考图像	≤ 9 张
参考视频	≤ 3 段，每段 2–15 秒，总时长 ≤ 15 秒
参考音频	≤ 3 段，每段 2–15 秒，总时长 ≤ 15 秒；音频必须伴随图像或视频输入，不能作为唯一输入
混合输入合计	所有输入类型加起来最多 12 个文件

单看前三行会以为最多能给 9+3+3=15 个文件，但第四行把总数压到 12。这个差额意味着：素材配比是要提前规划的。想用满 9 张图，就只剩 3 个名额分给视频和音频；想用 3 段视频加 3 段音频，图片名额就只有 6 个。ComfyUI 的节点图不会替你算这笔账，等到运行时才发现超限，前面连的线就白连了。

音频那条附加条件也值得留意：音频不能作为唯一输入，必须伴随图像或视频。所以「只给一段音频，让模型配画面」这个用法在 Ref2VA 下走不通。

一个必须说清楚的前提

照这套规则手写提示词，是官方给的替代路径，不是官方工作流本身。H3 的三个模块里，H3-Context-IR 负责把复杂的多模态输入精炼成模型好理解的中间表示，README 明确说它对最终输出质量至关重要，强烈建议要么把它接进生成流程，要么按 Prompting Guidance 自建上下文处理系统——而这个模块未包含在本次开源发布中，只提供 API。同样未开源的还有负责 2K 重生成的 H3-Regenerate-2K。开源的是中间那层 H3-Base，产出 768p 结果。

所以结论要说得准确一些：把标签体系写规范，是在做 Context-IR 本来替你做的一部分工作，但不等于能得到与官方 API 相同的结果。

还有一层要分开看：ComfyUI 侧用的是 Comfy-Org/MiniMax-H3 的量化权重（扩散模型带 pruned_int8_convrot，文本编码器带 nvfp4_awq），MiniMax 官方发布的 checkpoint 精度是 BF16。两边权重形态不是一回事，评估效果时不要把两边的结果混为一谈——这里没有任何公开对比数据可以引用，我们也不做效果判断。

落笔前的自检清单

四类标签各归其位：文件本身用 <Picture N> / <Video N> / <Audio N>，从素材里抽出的可见内容用 <Subject N>。
六个章节按 subject_definitions → summary → retention_analysis → detailed_description → overall_soundscape → non_diegetic_music 的顺序写，字段名原样保留。
全篇没有悬空标签：正文里出现的每个标签，subject_definitions 里都能查到。
只做来源标注、后面不再单独使用的素材，并进对应条目里，不单独占行。
retention_analysis 对每一项都给了 fully preserved / partially preserved / transferred / reused 四选一的定性。
在 ComfyUI 里：连线顺序与提示词编号对得上；文件总数没超过 12；改过连线之后回头核一遍提示词。

标签体系本身不难，难的是把「我到底要保留什么、改动什么」想清楚再动手。官方那句「对措辞非常敏感」不是客套话，它的潜台词是：这套格式承载的是你的意图，写含糊了，模型只能替你猜。

延伸阅读

本文依据 MiniMax H3 官方仓库（github.com/MiniMax-AI/MiniMax-H3）的 README、模型配置文件与官方 h3-prompt-writing skill 文档整理，核对日 2026-08-09。本文内容为官方仓库口径，未在本机部署或调用过 H3。模型、部署方式与许可条款以官方最新说明为准。ComfyUI 侧依据 ComfyUI 官方仓库（github.com/Comfy-Org/ComfyUI）的 README、release notes 整理，对应版本 v0.31.0，为官方文档与源码口径，非本机实测，参数与默认值随版本变动，请以官方文档与 python main.py --help 的实际输出为准。ComfyUI 侧的模型文件与工作流信息来自 docs.comfy.org 的官方教程与 Comfy-Org/workflow_templates 仓库的模板文件。许可条款请以官方 LICENSE（MiniMax H3 Community License Agreement）原文为准，本文不构成法律意见。