Minimax H3 发布后社区里最热门的话题并不是“这个模型能生成多好看的画面”而是“为什么用 H3 生成视频时提示词怎么写都差一口气”。我在本地 ComfyUI 里把 H3 从加载权重到跑通完整生成流程走了好几遍也对比了官方提示词 skill 在开启和关闭两种情况下的输出差异。结论很直接H3 的提示词体系不能沿用 Stable Diffusion 或 Midjourney 的思路它本质上是由一层多模态语言模型来理解用户描述再交给扩散模型去生成画面官方 skill 就是专门给这层语言模型看的“导演指令模板”。这篇文章会围绕 H3 为什么需要 skill、skill 如何安装和使用、效果如何验证、以及本地部署时最常出现的 OOM 与 skill 不生效问题展开适合正在本地部署 H3、想通过 ComfyUI 跑通视频生成的开发者。1. 为什么 H3 的提示词不能继续沿用 SD/MJ 的思路1.1 H3 的架构决定了输入不是“形容词堆叠”H3 属于 LLM Diffusion 的混合架构。用户输入的文本会先经过一层多模态大语言模型模型把这段文本理解成主体、动作、场景、运镜、氛围等多个维度然后才把理解结果交给扩散模型生成帧序列。也就是说提示词必须先满足语言模型对信息结构的要求而不是单纯把形容词堆满。传统文生图工作流里常见的 “huge, hyper-detailed, best quality” 这类堆砌式描述在 H3 里往往只是噪音。H3 底层由 LLM 主导理解一组混乱的形容词会让它展开成不确定的镜头语言。比如你写 “a beautiful woman standing in the wind, cinematic, masterpiece, 8k”模型可能完全不知道镜头应该固定还是推进人物应该居中还是偏左风的强度应该多大这些模糊信息最后会反映成构图不稳定、主体漂移。从实现角度看很多 ComfyUI 工作流里H3 的文本前端节点会直接接收 prompt并按照预置模板进行解析。如果模板不存在或者为空模型会退回一种默认行为表现为主体不稳定、运动幅度小、构图随机。这就解释了为什么同一个模型在 A 那里效果炸裂在 B 那里却频频崩坏很多时候不是模型问题而是提示词处理链路没有对齐。1.2 普通提示词在 H3 上的典型失效表现如果继续按照 SD/MJ 的思路写提示词在 H3 上通常会看到几类问题运动幅度小视频更像静态图加上一点缓慢位移。主体在画面中位置漂移镜头语言混乱。画面里的文字渲染出现乱码或变形。同一提示词不同 seed 生成结果差异巨大构图、光线、动作都不稳定。多物体交互时经常丢失零件比如手、道具、背景元素数量对不上。这些现象并不是模型能力不行而是文本输入没有给出足够强的结构约束。H3 需要的是场景、主体、动作、镜头、光影、氛围等维度的信息甚至需要指明时间线画面开头是什么状态中段发生了什么变化结尾停在哪里。普通提示词很难承载这种结构除非你手动把所有信息组织好。1.3 官方 skill 解决的问题把一句话变成导演分镜官方 skill 是一段专门给底层语言模型看的指令文本。它不直接参与扩散采样而是在语言模型把用户输入转成最终 prompt 的过程中改变输出格式和内容分布。skill 开启后用户只需要提供一句简短的创作意图模型会按照 skill 中约定好的角色、目标、输出格式把意图扩展成一段包含主体、环境、构图、运镜、运动规则、负面提示词的完整提示词。扩散阶段拿到的输入因此变得更完整、更一致成片稳定性自然提高。这里有一个很容易误解的点skill 不是“更好的提示词语法”而是一个系统级的处理规则。它约束的是底层语言模型如何对待用户输入决定了模型从你的一句话里提取哪些信息、补全哪些细节、最后输出成什么格式。所以它和普通提示词是两层东西不能简单替换。2. skill 是什么和普通提示词有什么区别2.1 skill、系统提示词、用户提示词的分工可以把三者理解成同一个请求里的三个角色用户提示词用户这次想要什么比如“一只机械鸟在城市上空盘旋”。系统提示词模型应该以什么身份、按什么规则处理用户输入这是 skill 最常见的存在形式。模型输出经过 skill 处理后得到的正负提示词、分镜描述或其他结构化文本。很多人看到 ComfyUI 工作流里有一段很长的英文模板就以为是普通提示词直接把它塞进用户输入框结果生成内容里出现了大量洋无关的说明性文字。实际上那段模板应该放在系统通道而不是用户内容通道。用一句话概括用户提示词提供内容skill 决定处理方式模型输出决定扩散采样的实际输入。2.2 skill 里通常包含哪些内容不同版本的官方 skill 结构会有差异但通常都会覆盖以下几类信息内容模块作用角色定义告诉底层语言模型自己是视频导演、摄影指导或分镜师输入解析规则说明用户输入可能不完整需要补充细节扩写规则要求补全主体、环境、光线、镜头、运动等信息正负提示词格式规定最终输出必须包含正向描述和负面描述镜头控制约定定义镜头类型、运镜方式、运动速度和景别输出结构约定规定最终文本的字段顺序方便下游节点解析这些模块共同决定了 language model 从用户简短输入中扩展出来的内容长什么样。如果你拿到一段 skill 却没有角色定义或者输出格式说明那它大概率是被截断或改写过的不完整版本效果会明显打折。2.3 在网页端、API、本地 ComfyUI 三种场景下如何安装skill 的安装方式取决于你使用 H3 的入口。目前最常见的三种入口是网页端/导演台、API、本地 ComfyUI。网页端和导演台一般不需要手动安装 skill。官方平台会把 skill 内置到提示词处理链路中用户只需要理解输入框背后的规则不需要自己去维护模板文件。如果你发现网页端和本地 ComfyUI 的同一句提示词效果不一样很大原因是两边的 skill 版本或处理链路不同。API 场景下skill 通常作为 system prompt 注入。调用时需要有一个字段专门承载系统指令另外有一个字段承载用户输入。把 skill 误放到 user 字段里模型会把它当成生成内容的一部分最终输出的提示词可能变成一堆不自然的规则朗读。本地 ComfyUI 场景则相对自由。你可以把 skill 保存为单独的 .md 或 .txt 文件在提示词节点或自定义的 PromptBuilder 节点中读取也可以把 skill 文本直接粘贴到工作流的系统提示词输入框里。推荐使用文件方式方便版本管理和多人协作。2.4 安装前先确认版本和来源这里需要特别强调来源问题。H3 模型发布后网络上出现了大量整合包和 skill 分享贴其中一部分下载链接来源不明可能存在模型文件被改动、skill 版本不匹配、可执行脚本夹带恶意代码等风险。建议优先从模型卡、官方仓库或维护者长期保持的镜像渠道获取以下内容H3 权重文件配套的 VAE 和文本编码器官方读取到的 skill 原文对应 ComfyUI 自定义节点的版本说明拿到文件后至少用sha256sum或CertUtil校验一次文件哈希确认和发布方提供的值一致。不要因为下载速度慢就随意换源也不要直接运行来源不明的压缩包内的脚本。注意skill 文件通常要求 UTF-8 编码Windows 下用记事本保存时不要默认选 ANSI否则中文注释或特殊符号会在加载时乱码导致模板解析失败。3. 在 ComfyUI 里从零装好 H3 和 skill并跑出第一段视频3.1 准备模型文件与依赖进入 ComfyUI 工作流之前先把文件放对位置。不同整合包目录可能略有不同核心目录大致如下ComfyUI/ models/ checkpoints/ # 单文件权重 diffusion_models/ # 拆分的扩散模型 text_encoders/ # 文本编码器 vae/ # VAE 文件 custom_nodes/ # 自定义节点 input/ # 输入图片或视频 output/ # 生成结果H3 的权重文件放在哪个目录取决于你使用的加载器节点。比如有的节点用 Unet Loader 加载 diffusion model有的节点直接读 CheckpointLoader。安装前先看自定义节点 README 中给出的目录约定不要想当然。模型下载完成后做三个基础检查nvidia-smi df -h /path/to/ComfyUI sha256sum your-h3-checkpoint-filenvidia-smi可以确认显卡驱动是否识别、显存剩余多少df -h确认磁盘空间是否足够存放模型和生成结果哈希校验确认权重没有在下载过程中损坏。很多人跳过这一步后面遇到加载失败或者生成花屏才回来排查浪费时间。3.2 把 skill 文件接入提示词节点在 ComfyUI 目录下新建一个专门存 skill 的文件夹例如ComfyUI/models/h3_skills/把 skill 文本命名为h3_director_skill_v1.md放进这个目录。随后在自定义节点的提示词构建器中选择这个文件。如果工作流里是一个普通的 CLIP Text Encode 节点没有 system/prompt 分离这时候有两种处理方式把 skill 和用户输入拼接成一段文本再传入 CLIP Text Encode。使用支持 system 与 user 分离的提示词节点比如社区常见的 PromptBuilder 或 LLM 类型节点。后者更接近官方设计意图。拼接方式虽然也能跑但 skill 和用户内容混在一起后续想调试“skill 有没有起作用”会很难。下面是一个简化的工作流节点示意用于说明结构关系{ class_type: PromptBuilder, inputs: { system: h3_director_skill_v1.md, user_prompt: 一只机械鸟在雪后城市上空盘旋 } }这里的system字段指向 skill 文件user_prompt是用户输入。实际节点名称和字段名会因整合包版本而不同但核心思想一致skill 走系统指令通道用户描述走内容通道。初次跑通时建议使用节点自带的最小示例工作流不要一上来就在复杂到页面上铺满几十个节点的模板上改。先用最简链路验证模型能出片再逐步加入控制层。3.3 组装一条最小生成链路一个最小可运行的 ComfyUI 链路通常长这样加载 H3 扩散模型。加载文本编码器或前端 LLM 节点。读取 skill 并接收用户输入。生成正负提示词。设置种子、步数、分辨率、帧数等采样参数。进入采样器生成 latent。使用 VAE decode 得到视频帧。用视频合并节点输出成片。关键点在于第 3 步到第 4 步之间。如果 skill 真的生效从模型侧输出的扩写文本应该出现明显结构化特征。为了确认这一点你可以在工作流中增加一个预览文本节点把模型生成的提示词打印出来再决定是否送入采样器。以下是一段用于说明调用逻辑的 Python 示例不需要在 ComfyUI 中直接执行但能帮助你理解 skill 是怎么参与调用的# 示意逻辑实际 ComfyUI 节点内部流程因版本不同而异 def build_h3_prompt(skill_text, user_prompt): messages [ {role: system, content: skill_text}, {role: user, content: user_prompt} ] # 调用 H3 的文本前端得到扩展后的正负提示词 expanded call_h3_text_frontend(messages) return expanded再强调一次不要照着这段代码去造节点实际节点内部实现是另一套流程。这里的价值是帮助你理解 skill 在整条链路中的位置。3.4 从生成结果反推 skill 是否生效生成完成后不要只盯着第一帧好不好看H3 的价值主要在运动所以要按下面几个维度验证扩写文本是否包含固定结构。如果 skill 生效模型输出应该有明确的正提示词、负提示词、镜头描述等字段。成片是否具有更明显的运镜。开了 skill 之后画面通常会出现推拉、环绕、跟随等镜头运动而不是人物原地微动。多 seed 的一致性是否提高。同一个用户输入换不同 seed主体身份、场景氛围、构图方向应该保持相对稳定。文字渲染是否正确。如果场景里有牌匾、交通标志、屏幕文字英文和中文的渲染正确率应当明显提升。推荐用同一条用户输入分别跑 skill 开启和关闭两组对比。每组各生成 2 到 4 个 seed观察差异。这一步能帮你建立“哪部分变化来自模型、哪部分变化来自 skill”的判断能力比盲目调参数有用得多。4. skill 的核心逻辑拆解字段、正负提示词与扩写链路4.1 一个可参考的 skill 结构示意官方 skill 的原文需要从模型卡获取。这里给出一个结构示意帮助你理解它是如何组织的实际使用时请以官方文件为准不要直接拿这段示意当完整 skill 用。[ROLE] 你是资深导演和视频分镜师。 [GOAL] 根据用户描述生成适合视频扩散模型的正负提示词。 [POSITIVE PROMPT] 主体身份、外观细节、空间位置 环境场景、天气、光线 镜头景别、运镜方式、运动速度 交互物体间的动作关系、时间线变化。 [NEGATIVE PROMPT] 主体变形、肢体异常、文本乱码、 画面闪烁、水印、过度平滑。 [OUTPUT FORMAT] Positive: ... Negative: ...这段示意体现了 skill 的三个核心能力角色约束、内容补全、格式输出。角色约束决定了模型用导演视角看问题内容补全决定了它从短句扩展到哪些维度格式输出决定了下游节点能否可靠解析。4.2 正提示词里哪些信息最影响成片对 H3 来说正提示词里影响最大的不是“风格词”而是以下几类信息主体和空间关系。谁在哪里做了什么画面内怎么分布。环境和光线。是白天还是夜晚是否有雾、雨、雪光从哪个方向来。运镜方式。固定镜头、推近、拉远、跟拍还是环绕速度如何。时间线变化。画面从 A 状态开始中间经过什么结尾停在什么位置。文字内容。如果画面里需要出现招牌、海报、屏幕文字最好直接写清楚内容。用户输入里这些信息越充分skill 的扩写压力越小。反过来如果用户只写一个“机械鸟在城市上空盘旋”skill 会自行补全环境、光线、运镜效果虽然也可以但自由度更大和你心中的画面可能产生偏差。4.3 负提示词和输出格式约束负提示词的作用是告诉扩散模型在采样时尽量避免哪些视觉特征。常见类别包括类别示例主体质量肢体扭曲、面部变形、多根手指文本渲染乱码文字、错误拼写画面稳定性闪烁、抖动、拉伸变形水印痕迹网络水印、字幕残留、边缘伪影负提示词并不是越多越好。很多负面描述之间会相互冲突过度堆砌反而可能抑制正常画面细节。官方 skill 中给出的负面列表通常是经过测试的稳定版本建议保留。输出格式约束决定了最终字符串长什么样。如果 skill 要求输出Positive: ...和Negative: ...那么前端节点就可以按照这两个字段做解析。一旦 skill 被修改成缺少格式标准的自定义版本下游解析就可能失败表现成“提示词很完整但生成效果突然变差”。4.4 修改 skill 的边界与风险skill 可以改但要注意边界。常见风险是过度压缩用户输入。skill 把关卡细节全部交给模型自由发挥导致输出内容与用户意图偏离。破坏输出格式。删掉字段分隔符或改掉字段名导致下游解析失败。引入跨模型干扰。把 LTX-2.5、H2 或者其他模型的 skill 直接套到 H3 上模板和模型训练时的期望格式不一致效果反而退化。推荐做法是在官方 skill 基础上先做小范围参数调整比如增删负提示词类别、修改镜头偏好、调整用户输入补充规则。每次只改一项固定 seed 做对比。等验证稳定后再改下一项。注意不同视频模型的 skill 不能直接互换。H3 的 skill 结构是围绕 H3 的 LLM 文本前端设计的LTX-2.5 或 H2 的 skill 即使看起来相似内部约定可能完全不同。5. 本地跑 H3 最容易遇到的坑从 OOM 到 skill 失灵5.1 常见问题速查表先给一张速查表适合从现象快速定位问题方向问题现象常见原因检查方式处理建议加载模型时显存不足权重文件超过显存空间nvidia-smi查看显存占用更换 fp8 或量化版本降低并发任务VAE decode 阶段 OOMregular decode 峰值显存高查看日志报错位置开启 tiled VAE降低分辨率或 batchskill 不生效skill 没进 system 通道查看模型输出的扩写文本检查节点连接和文件读取路径生成画面全黑或花屏VAE 文件缺失或权重损坏校验哈希重启工作流重新下载正确 VAE中文提示词乱码文件编码不是 UTF-8用编辑器查看原文件另存为 UTF-8模型加载报 shape mismatch配置文件与权重版本不匹配查看完整报错信息匹配模型发布时的 config 版本生成视频运动幅度小skill 未开启或提示词结构松散对比开/关 skill 输出检查是否读取正确 skill 文件这张表不能覆盖所有情况但可以覆盖大多数本地部署者刚开始跑 H3 时频繁遇到的方向性问题。5.2 显存不足重点分析 vae decoding 阶段爆显存32G 显存跑 H3 是社区里非常常见的配置但不是一劳永逸。当生成分辨率较高、帧数较多或 batch 大于 1 时VAE decode 阶段会产生与 latent 尺寸相关联的大量中间张量显存峰值经常在解码阶段出现。最典型的报错语句是ran out of memory when regular vae decoding看到这条日志时优先检查三件事VAE 解码节点是否启用了 tiled 模式。tiled VAE 会把解码图切成小块逐块处理峰值显存显著下降。生成分辨率是否超过当前显存承受范围。先降到 512 或 576 级别试跑确认能出片后再逐步提高。采样器 batch size 是否为 1。多 batch 会成倍放大解码阶段的显存占用。可以使用下面的命令实时观察推理过程中的显存变化watch -n 1 nvidia-smi观察显存占用在哪个阶段快速上涨可以帮你判断瓶颈是在模型加载、采样还是 VAE 解码。如果确认是 decode 阶段优先改解码方式而不是盲目调整模型加载参数。5.3 skill 不生效先查调用链而不是重新生成skill 不生效的典型表现是模型输出看起来和普通提示词没什么区别成片运动幅度依然很低或者生成内容里直接出现了 skill 的规则文本。排查顺序建议如下确认 skill 文件内容是否被真正读取。查看节点日志或输出文本看是否出现 skill 中的标志性行比如角色定义、输出格式。确认 skill 位于 system 通道。如果节点只支持拼接式输入检查拼接顺序是否让 skill 内容跑到了用户输入之后。确认用户提示词没有覆盖 skill 指令。某些自定义节点会把用户输入重复传入系统提示词导致 skill 被冲刷。对比开启和关闭 skill 时的扩写文本。如果两份文本完全一致说明 skill 根本没有进入该链路。通常问题都出在第 1 和第 2 步也就是文件路径错误或通道接错而不是模型不支持 skill。5.4 模型权重损坏与版本不匹配下载被中断是 H3 权重文件损坏的最常见原因。大文件下载时建议使用支持断点续传的下载工具下载完成后立即做哈希校验。模型文件的 config 与权重不匹配时加载阶段通常会抛 shape mismatch 或缺少 key 的异常。看到这类报错不要尝试自己改 config优先从模型发布的原始仓库确认权重版本再检查自定义节点是否更新到支持该版本的 commit。整合包之间也存在兼容性差异。某个节点在 A 整合包中运行正常换到 B 整合包后可能因为依赖版本不同而报错。遇到这种情况把报错日志和自定义节点的版本信息一起记录再对比两个整合包中该节点的 commit 版本通常能定位到原因。5.5 建议的排错顺序清单本地部署 H3 时遇到问题不要急着重装整合包按照下面的顺序排查检查硬件状态确认显存、磁盘、驱动、温度正常。确认文件位置正确模型、VAE、文本编码器、skill 都放在节点期望的目录。确认文件完整性哈希校验模型权重和关键配置。确认节点版本兼容查阅 README 中支持的模型版本。使用最小工作流复现问题排除复杂节点干扰。查看完整日志定位报错发生在加载、采样还是解码阶段。修改一个变量保留其他变量重新跑一次对比。记录成功和失败的工作流、参数、提示词、seed 和日志作为后续排查依据。这套顺序同样适用于其他大模型和多模态生成程序的排错核心思路只有一个先把问题隔离到一个可复现的最小场景再逐项排查。6. 把 skill 用出稳定效果的实践建议6.1 用户输入怎么写给模型一个可扩写的小骨架实际使用中用户输入的质量直接决定了 skill 的上限。好的用户输入不需要写很长但必须给模型提供几个关键信息点。不好的写法一只鹰飞过天空较好的写法一只机械翅膀的灰鹰从废墟顶部起飞镜头跟随鹰穿过雾中的城市光线从云层缝隙斜射下来结尾停在摩天楼广告牌前两者的区别在于后者提供了主体状态、起始位置、运镜方向、环境光线、运动终点五个信息点。skill 在这五个点之上做扩展输出内容会更接近用户意图。6.2 采样参数和 seed 策略H3 的生成结果对 seed 非常敏感。做任何提示词或 skill 对比实验时务必保持 seed 固定。修改了 skill 之后先固定 seed 看单张效果确认改善后再换多个 seed 验证稳定性。社区里常说的“二采”通常指固定提示词和参数、更换 seed 生成多份候选后筛选。这是一种面向高随机性模型的出片策略不是每次都要用。如果同一段提示词已经在多数 seed 上表现稳定说明提示词和 skill 的配合已经基本可用可以直接批量出片。采样参数不要生搬硬套。不同整合包中步数、引导系数、噪声调度器的实现可能不同最稳妥的方式是先用节点默认值跑通再在固定 seed 前提下每次调整一个参数观察画面变化。6.3 本地工作流与云端导演台如何选择本地 ComfyUI 适合调试、批量实验和自定义控制你可以完全掌握模型和提示词之间的交互细节。云端导演台适合快速出片和长视频场景官方环境已经完成 skill 和参数调优不需要担心依赖问题。效率建议是先用本地环境和 skill 做小规模实验确定提示词结构和参数基线再把稳定的提示词迁移到云端批量生成。如果云端效果和本地不一致优先检查两边 skill 版本和模型版本是否一致而不是怀疑模型能力。6.4 多人协作时的 skill 版本管理如果你不是一个人使用 H3而是团队协作skill 要像代码一样做版本管理。建议把以下内容全部纳入版本控制skill 原文文件记录修改时间和修改人。模型权重文件名和哈希值。ComfyUI 自定义节点的版本信息。一份可工作的示例工作流。生成视频时把 seed、采样参数、skill 版本一起写入输出文件名或元数据。这样几个月后回看一条视频仍然能复现当时的生成条件。对创作者来说可复现性比单次效果更重要。6.5 下一步可以研究的主题如果这篇文章的内容你已经全部跑通下一步可以从以下几个方向继续深入学习 H3 底层 LLM 文本前端的输出解析机制理解正负提示词如何映射到扩散采样。对比 H2、H3、LTX-2.5 等模型的提示词模板差异建立自己的“提示词格式敏感性”判断。研究多镜头和多场景工作流把 skill 从单镜头提示词扩展到分镜一致性控制。在本地搭建更完整的评估方法比如固定指标对比运动幅度、主体一致性、文字准确率。把 H3 和 skill 看作一个整体权重决定模型能做什么提示词 skill 决定模型把用户意图理解成什么。先在官方 skill 基础上跑出一批稳定输出再根据你自己的创作场景慢慢微调。可以从最常使用的一段视频需求开始记录提示词、seed、参数和成片逐渐建立自己的质量基线。本地部署的价值正在于此你可以完全控制这条链路而不必在每次失败时重新猜测提示词写错了哪里。