MiniMax H3 的提示词为什么难写很多用过视频生成模型的开发者都有类似体验同一个主体描述换一种写法生成结果可能是“忠实执行”和“完全自由发挥”两种极端。问题往往不在模型本身而在于提示词没有按照模型能稳定理解的维度去组织。MiniMax H3 这类视频模型要做的是把一段文本转换成有时间轴、有镜头运动、有主体一致性的连续画面它和 ChatGPT 式对话提示词需要的信息粒度完全不同。解决这个问题的工程化方式是做一个可复用的 Promp t Skill基于官方提示词规范整理出固定结构、可变槽位、约束规则和评分标准再用 A/B 实测不断修正。这篇文章会从“为什么难写”讲起给出一套可以直接改用的 H3 Prompt Skill 模板演示一次完整的 A/B 实测过程最后说明如何把单条提示词沉淀成可持续维护的提示词资产。1. 为什么 MiniMax H3 提示词特别难写先拆解“听话”1.1 视频提示词和对话提示词的信息粒度不一样对话模型的提示词本质上是给模型一段意图、背景和约束模型输出的是文字结果。你写“帮我写一份活动策划”模型理解的是“用户想要一篇结构完整的方案”它不需要在物理世界里还原任何画面。视频生成模型不一样。模型收到提示词后要在潜在空间里生成连续帧每一帧都要有主体、动作、位置、光影、镜头关系。提示词里的每个词都可能被解释成一个可见的视觉元素。词越模糊模型的选择空间越大“自由发挥”的概率也就越高。所以 MiniMax H3 的提示词不能只写“想要什么感觉”而要写“画面里发生了什么、镜头怎么动、光线从哪来、主体长什么样、哪些元素绝对不能出现”。这就是第一层认知转变把提示词从“意图描述”改成“画面执行方案”。1.2 H3 这类视频模型需要控制的是画面发生的事从社区工作流和部署资料看MiniMax H3 常见的使用方式包括文本生成视频、参考图转视频ref2va 全能参考模式、导演台分镜控制以及通过 ComfyUI 集成到本地工作流中。无论走哪条路径提示词要覆盖的控制维度是接近的。核心维度可以拆成七块主体谁在画面里长什么样穿什么在什么位置。动作主体做什么动作顺序是什么情绪状态是什么。场景环境拍摄场地、背景、是否有其他人物或道具。镜头运动固定机位还是推拉摇移景别如何变化。光线光源类型、方向、强度、阴影情况。风格写实、广告、电影感、动画感等视觉基调。节奏与时长动作快慢、镜头停留时间、是否慢动作。使用参考图模式时主体描述必须和参考图保持一致。比如参考图里人物穿红色卫衣提示词却写“蓝色外套”模型就会在两者之间产生冲突结果既不像图也不像词。这个矛盾在 A/B 实测里非常常见后面会专门讲。1.3 “99% 听话”先要给一个可打分定义“听话”是一个模糊感受不能直接用来指导调优。要让它变成可验证的工程指标需要先定义评分维度。我在实测中把“听话程度”拆成六项每一项按 1 到 5 分打分评分维度含义常见扣分现象主体一致性生成画面的主体是否和描述一致人物服装变化、出现多余人物、主体被遮挡动作符合度动作是否按描述执行且顺序正确动作没发生、顺序颠倒、加入了未描述动作镜头符合度镜头运动方式和景别是否匹配描述说推进却横移、景别混乱、画面剧烈抖动场景连续性背景、道具、空间关系是否稳定背景跳变、空间透视错误、道具消失风格贴合度光影、色彩、质感是否贴近目标风格写实变动画、广告质感缺失、色调偏移约束执行度负向约束是否被遵守出现水印、出现禁止元素、文字乱入有了这六项每条提示词的“听话程度”就不再是感觉而是一组分数。每次修改只动一个变量重新跑分就能知道哪条改动真正有效。这也是后续 A/B 实测的基础。2. 把提示词当成工程问题Prompt Skill 的组成和官方规范的关系2.1 为什么“想好一句话再写”不可靠很多人写视频提示词习惯在对话框里临时组织一句话比如“一个女孩在白色背景前慢慢走过镜头推进光线柔和像广告一样好看不要有水印。”这句话信息量不小但模型很难稳定执行原因有三个。第一所有维度被揉在一个长句里模型对语义权重的判断是概率性的每次生成可能侧重不同的词。第二“像广告一样好看”是主观感受没有落到光影、质感、镜头语言这些可见要素上。第三这句话没有版本概念这次跑得好下次改一个字可能就崩了但你没有记录是哪里的问题。临时提示词无法迭代因为每次修改都是重新开始没有基线。2.2 Prompt Skill 结构固定角色、可变槽位、规则、示例、评分Prompt Skill 的核心思路是把提示词写作从“每次现场发挥”改成“填表 规则校验”。先定义一个 Skill 文件里面包含固定结构、可变槽位、约束规则和评分方式每次生成视频时按槽位填内容。下面是一个可供改写的 H3 Prompt Skill 骨架skill_name: h3_video_prompt version: 0.1 target_model: MiniMax H3 role: 视频画面描述编译助手 input_slots: subject: { type: string, required: true, desc: 主体唯一锚定描述 } action: { type: string, required: true, desc: 主事件动作 附加动作上限 } environment: { type: string, required: true, desc: 场景环境与空间关系 } camera: { type: string, required: false, desc: 镜头运动 景别变化 } lighting: { type: string, required: false, desc: 光源方向、强度、阴影 } style: { type: string, required: false, desc: 视觉风格与质感 } duration_hint: { type: string, required: false, desc: 节奏、时长、慢动作提示 } structure_order: - subject - action - environment - camera - lighting - style - negative rules: - 每个维度只写一个短句维度之间用分号分隔。 - 主体描述必须包含唯一锚定信息例如服装颜色、姿态、空间位置。 - 动作只写一个主事件附加动作不超过两个。 - 景别术语和镜头运动术语不能混用。 - 提示词最后追加负向约束。 negative_constraints: - 禁止出现多余人物 - 禁止文字、水印、logo - 禁止镜头剧烈抖动 - 禁止肢体结构变形 examples: - note: 棚拍慢动作人像示例 output: 一只穿红色连帽卫衣的年轻女性站在纯白摄影棚中央... scoring: dimensions: [subject_consistency, action_accuracy, camera_compliance, scene_continuity, style_adherence, constraint_execution] scale: 1-5这个 YAML 文件本身不直接交给 MiniMax H3它是给写提示词的人或自动化流程用的。你可以把它放在提示词管理工具、项目文档里甚至让 LLM 按这个 schema 生成提示词。关键点是Skill 把“怎么写”和“写什么”分开结构是稳定的内容是可变的。2.3 官方规范怎么用先对齐维度再补措辞MiniMax 官方发布过面向视频生成模型的提示词规范社区里也流传着大量整理版本。不同版本表述有差异但核心维度大体一致主体、动作、场景、镜头运动、光线、氛围、风格。官方规范真正有价值的不是某个句子而是它对维度的拆分方式。官方规范里推荐用分号或逗号把不同维度隔开而不是把所有信息揉成一个长句。这背后的原因是模型对句内结构的解析要稳定得多分号能降低维度之间的语义粘连。比如“女孩转身镜头推进背景是白色棚拍”比“一个女孩在白色背景前转身镜头推进背景白色”更容易被执行。所以在做 Prompt Skill 时第一步不是编造花哨的形容词而是把官方规范的维度固化成语义槽位。措辞优化放在第二步而且要用实测验证不要凭感觉。注意官方规范会随模型版本更新而调整。每次 MiniMax H3 升级后先重跑一遍测试矩阵确认旧 Skill 仍然有效再决定是否更新。3. 搭一个最小可用的 H3 Prompt Skill模板、填充、生成3.1 先确认测试环境动手之前先确认自己在哪个环境里跑测试因为学习环境、开发环境、生产环境的操作路径完全不同。环境典型操作特点学习环境官方 Web 端或提示词社区工具单条生成上手快、不需要额外资源、适合验证结构开发环境调用官方 API 或云端工作流批量生成需要管理密钥、参数、日志适合 A/B 实测本地环境ComfyUI 集成加载模型权重本地推理需要 GPU 资源和显存规划适合高频实验社区里常提到 MiniMax H3 的 ComfyUI 整合包和本地部署方案具体参数量和显存要求要按实际模型发布说明确认不同版本差异很大。本地部署可以先跑通一条工作流再逐步叠加参考图、导演台这些能力不要在第一步就追求全功能。3.2 定义一个带槽位的提示词模板先给一个纯文本模板不依赖任何工具直接复制到任何支持中文输入的生成入口里使用主体描述主体唯一锚定信息包括人物特征、服装、位置、朝向。 主体动作主事件动作附加动作不超过两个动作顺序明确。 场景环境拍摄场地、背景空间、是否允许出现其他人物。 镜头运动固定还是运动推进或横移景别如何变化。 光线说明光源方向、强度、阴影硬软、背景明暗。 风格指向写实、广告、电影、动画等视觉基调。 负向约束禁止出现的元素逐条列出。每个槽位后面都说明了填写要求。实际填充时把冒号后的说明文字替换成具体内容然后按顺序拼接。3.3 写一个填充实例棚拍慢动作情绪人像用一个具体场景展示填充过程。目标画面是一个穿红色连帽卫衣的年轻女性在白色摄影棚里做慢动作情绪表演。主体描述一个穿红色连帽卫衣的年轻女性站在纯白摄影棚中央正面朝向镜头双手自然下垂 主体动作她缓慢抬起右手摸向脸颊动作轻柔眼神克制全程保持慢动作 场景环境干净白色棚拍空间无其他人物无道具 镜头运动固定机位缓慢推进景别从全景过渡到中近景 光线说明柔光照明面部无硬阴影背景均匀明亮 风格指向商业广告摄影质感写实风格浅景深 负向约束禁止文字水印禁止出现其他人物禁止镜头剧烈抖动禁止手部变形。从实测角度看MiniMax H3 对中文支持整体稳定但也有一部分生成结果在中英文提示词下表现不同。建议在 A/B 测试时加入一个变量对照中文版和英文版的结果不要默认哪个更好。英文版示例A young woman in a red hoodie stands at the center of a pure white studio, facing the camera; she slowly raises her right hand to her cheek, soft and restrained, in slow motion; clean white studio space, no other people, no props; fixed camera slowly pushing in from full shot to medium close-up; soft lighting, no hard shadows, even bright background; commercial photography look, realistic, shallow depth of field; no text watermark, no other people, no shaking, no distorted hands.这里要注意槽位顺序不要随意改。主体在动作之前、动作在场景之前可以让模型先建立“谁在哪儿”再理解“发生了什么”。顺序颠倒后虽然每个槽位内容没变但生成稳定性会下降。4. A/B 实测同一段画面两种提示词写法差在哪4.1 实验设计一次只改一个变量A/B 实测的目的是验证“Skill 结构化写法”是否真的比“自由描述写法”更听话。实验设计遵循三条原则同一组随机种子和生成参数只改提示词。每组提示词跑三次取稳定表现不拿单次结果下结论。每次只改一个变量如果同时改结构又换主题分数差异无法归因。在参考图模式下A/B 两组必须使用同一张参考图否则主体一致性本身就存在差异。4.2 两组对照提示词第一组是自由描述风格把所有意图写在一个长句里拍一个穿红卫衣的女孩在白色背景前慢慢走过来镜头往前推光线柔和像广告一样好看不要有水印手别拍坏。第二组是 3.3 里的 Skill 结构化提示词按槽位顺序拼接。两组表达的画面意图接近但组织方式完全不同。后者把“女孩”“动作”“背景”“镜头”“光线”“风格”“负向”拆成了独立子句并且用分号隔离。4.3 评分结果与原因分析每组跑三次按六个维度打分取中间值评分维度自由描述组 ASkill 结构组 B主体一致性24动作符合度24镜头符合度25场景连续性34风格贴合度24约束执行度24为什么差距明显拆开看A 组“镜头往前推”没有写景别变化模型可能理解为推进也可能理解为突然拉近“像广告一样好看”没有落到光线、质感、浅景深这些可执行元素上模型只能主观发挥“手别拍坏”过于口语模型不能稳定理解成“手部结构要正常”。B 组把每个维度变成了可执行的简明指令。“固定机位缓慢推进景别从全景过渡到中近景”是标准的镜头语言“柔光照明面部无硬阴影背景均匀明亮”是可验证的光线条件“禁止手部变形”是明确的负向约束。模型的可选择空间被压缩结果自然更稳定。4.4 用实测结果反向修正 SkillA/B 实测得到的不是最终答案而是下一轮调优的起点。第一次实测后我做了三处修正给 Skill 增加language_hint槽位记录本次使用中文还是英文方便对比语言变量的影响。把“禁止手部变形”升级为“禁止肢体结构变形、禁止手部异常弯曲”因为实测中手部问题在不同动作下表现不同。增加一条规则动作描述中动词必须具体不使用“感觉”“好像”这类模糊词。修正后Skill 从 v0.1 升到 v0.2。每次修正只改一个点然后重新跑完整评分表记录新分数。这样 Skill 的版本和效果是挂钩的而不是凭记忆拍脑袋。注意不要因为一次 A 组效果好就否定结构化也不要因为 B 组失败一次就放弃 Skill。单次生成有随机性至少要三轮以上再判断结构是否有效。5. 调优过程中最容易踩的五个坑5.1 坑 1主体没有唯一锚定现象提示词写“一个女孩在街上走”生成结果中女孩子始终在变甚至每几帧换一套衣服。原因“一个女孩”只定义了性别和年龄没有给出任何可识别的锚定信息。模型在每一帧生成时都要重新决定“这个女孩长什么样”前后帧缺乏强约束于是出现漂移。处理给主体补充至少三个可辨识锚点比如“穿红色连帽卫衣”“黑色短发”“站在画面左侧”。在参考图模式下还要确保锚点和参考图一致。锚点越具体主体一致性分数越高。5.2 坑 2一个镜头塞进多个事件现象提示词写“她转身、坐下、拿起杯子、看向窗外”结果生成画面动作混乱或者只完成了其中一个动作。原因视频片段的时间和帧数是有限的一个镜头承载三四个连续事件模型要在有限时间内压缩所有动作必然牺牲动作的准确性和顺序。处理一个镜头只写一个主事件附加动作控制在两个以内。例如把上面的提示词改成“她在窗边缓缓坐下目光落向桌上的杯子”。如果确实需要多事件就拆成多个镜头在导演台或分镜脚本里分别控制。5.3 坑 3景别术语和镜头运动术语混用现象提示词里写“推拉镜头中景慢慢靠近”生成结果观众分不清是机位在动还是画面被缩放观感像“数字变焦”。原因推拉摇移跟是镜头运动全景、中景、近景是景别两个体系混在一个句子时模型可能执行其一而忽略其二。处理把景别和运动分开写。“固定机位缓慢推进景别从全景过渡到中近景”就是清晰表达机位固定、镜头在推、景别在变。不要写“推拉镜头加特写”这类混合表达。5.4 坑 4负向约束缺失或者写得互相冲突现象只写正向描述生成结果里出现水印、多余人、文字乱码或者在负向约束里同时写“禁止出现手机”和“禁止人物手持任何物体”模型无法同时满足。原因负向约束不是越多越好也不是越少越好。缺失会让模型自由加入元素过度且冲突的约束会让模型在生成时陷入矛盾两端都执行不好。处理负向约束只保留和当前画面强相关的元素控制在三到五条。比如棚拍人像场景写“禁止水印、禁止多余人物、禁止手部变形、禁止镜头抖动”就够了不需要把所有可能元素都列一遍。5.5 坑 5把提示词当成参数列表堆词现象严格按槽位填了一大段包含几十个形容词结果画面元素过多主体不突出。原因Skill 是写作脚手架不是最终输出。槽位里的每个词都会被模型理解成视觉元素堆砌“唯美、高级、梦幻、通透、质感”这类形容词反而稀释了主体和动作的权重。处理填充时优先保留能被执行的信息主体锚点、动作动词、空间关系、镜头术语、光线条件、风格关键词、负向约束。形容词每类保留一到两个即可删掉那些不产生画面差异的修饰词。6. 一条“不听话”视频的排查路径6.1 从现象倒推原因视频生成结果“不听话”不要直接重写整个提示词。先按现象定位是哪个环节出问题。现象优先检查常见原因处理建议主体漂移或服装变化主体槽位是否包含唯一锚点锚点不足或与参考图冲突补充颜色、发型、位置锚点确认参考图一致动作没执行或顺序错动作槽位是否只有一个主事件动作过多、动词不具体压缩为单个主事件使用具体动词镜头运动不对镜头槽位是否混用术语景别和运动混写分离景别和镜头运动明确机位场景跳变场景槽位是否明确空间关系背景描述缺失写清楚场地、背景、空间位置光线风格不符光线槽位和风格槽位是否冲突形容词堆砌、无光线条件写光源方向、强度、阴影、明暗出现多余元素负向约束是否覆盖当前场景约束缺失或冲突增加或精简负向约束保持一致性排查顺序建议是输入是否正确、路径和参数是否匹配、主体是否锚定、动作是否单一、镜头术语是否规范、负向约束是否合理最后再考虑模型版本差异。大部分问题在前五步就能定位。6.2 建立测试记录矩阵高质量调优依赖记录。每条提示词的测试结果都值得登记下面是一个可以直接复用的记录表日期Skill 版本提示词版本语言Seed参数主体一致性动作符合度镜头符合度场景连续性风格贴合度约束执行度现象记录2025-01-10v0.1B2中文101默认445444手部小范围变形2025-01-10v0.2B3中文202默认445445变形消失整体稳定记录的价值不在当下而在几周后。当你积累了五十条记录就能看出哪些槽位、哪些措辞、哪些负向约束对 MiniMax H3 最有效。6.3 迭代节奏一次只改一个变量最常见的调优错误是同时改结构、改措辞、换参考图结果分数变化后根本不知道是哪个改动起了作用。推荐的迭代方式是先固定主体和场景只改动作槽位验证动作表达方式。再固定动作只改镜头术语验证镜头执行力。最后调光线和风格验证视觉一致性。每一轮至少跑三次记录中间值。这样迭代看起来慢实际是收敛最快的路径。7. 从“一条提示词”升级成“可维护的提示词资产”7.1 Skill 版本管理Prompt Skill 和代码一样需要版本管理。语义化版本号可以这样约定v0.x结构未稳定调整槽位、规则、顺序。v1.x结构稳定只改示例和各槽位的推荐措辞。v2.x能力扩展例如新增参考图模式专用槽位、导演台分镜模板。每次版本变更都要在变更说明里写清楚改了什么、为什么改、实测分数变化。这样团队协作时每个人都知道当前 Skill 是基于哪轮测试定下来的。7.2 学习环境和生产环境的差别关注点学习环境生产环境目标验证结构、找提示词规律批量稳定产出、控制成本操作单条生成、人工评分API 批量调用、自动记录结果排错直接重写提示词保留日志、保存生成参数变更随意尝试走版本变更流程先灰度后全量异常忽略偶发失败记录错误码、失败样本形成统计模型升级不影响学习升级后立即重跑测试矩阵生产环境里提示词不是一次性输入而是资产。每条上线前都要有测试记录、版本号和回退方案。模型升级、参数调整、参考图更换都可能改变提示词的表现旧记录就是回退和对比的依据。7.3 扩展方向第一个方向是多镜头一致性。单镜头提示词稳定后可以在导演台里把多个镜头组合起来用参考图和统一的主体锚点保证角色跨镜头一致。第二个方向是团队 Skill 库把验证过的槽位模板、负向约束清单、评分表沉淀成团队共享文档新人直接按模板填槽减少试错成本。第三个方向是回归测试每次 MiniMax H3 发布新版本或官方提示词规范更新时重跑一遍历史测试矩阵确认旧 Skill 仍然有效再决定是否升级版本号。最终值得记住的是一条测试闭环用结构化的方式组织提示词用可打分的维度定义“听话”用 A/B 实测验证每处改动用测试记录沉淀可复用的经验。下一次 MiniMax H3 生成结果不符合预期时不要急着怀疑模型先检查主体是否有唯一锚定、动作是否只有单主事件、镜头术语是否清晰、负向约束是否和画面强相关。这四步检查完大部分“不听话”都能定位到原因。