H3 Video Prompt Cn logo

H3 Video Prompt Cn

Community
swan7-py
h3-video-prompt-cn

为 T2VA / I2VA / FL2VA / L2VA / Ref2VA 编写 MiniMax H3 视频生成提示词(中文产出版 · 默认中文)。当需要将多模态需求改写为 H3 提示词结构、撰写 integrated_multimodal_description / overall_soundscape / non_diegetic_music、对齐关键帧、或为图像/视频/音频定义参考标签时使用。产出语言默认中文——描述内容(动作/场景/光影/声音)用中文书写,字段名、标签、占位符保持英文;仅当用户明确要求英文时才走英文产出。

Overview

Publisherswan7-py
RepositoryMiniMax-H3-Skills-Local
Skill nameh3-video-prompt-cn
Stars
66
Forks
5
Bundled files
19
Links
  • Markdown instructions

    A SKILL.md file the model loads on demand, so it only costs tokens when a request actually matches.

  • Works with any LLM

    AI skills are plain Markdown, not provider-specific code, so this works with GPT, Claude, Gemini, Grok, or a local model.

  • 19 bundled files

    Scripts, templates, and references the model can read while it works. Files are read-only and never executed.

  • Open source

    Published by swan7-py on GitHub. Read the source before you install it.

Installation

Install the H3 Video Prompt Cn AI skill in TypingMind to use it with any LLM, or drop it into another agent that reads SKILL.md.

1

Install in TypingMind

TypingMind installs a skill straight from its GitHub folder — it reads SKILL.md, bundles the resource files, and stores the result locally.

  1. Open the app and go to Plugins → Skills.
  2. Choose "Install from GitHub".
  3. Paste the skill folder URL below and confirm.
    https://github.com/swan7-py/MiniMax-H3-Skills-Local/tree/main/h3-video-prompt-cn
  4. Enable the skill in any chat where you want it available.
Plugins → Skills → Add skill → From GitHub URL, then paste the folder URL and press Continue.
2

Install in another agent

Any agent that reads the Agent Skills format can use this skill — copy the folder into that agent's skills directory.

Claude Code — .claude/skills
git clone --depth 1 https://github.com/swan7-py/MiniMax-H3-Skills-Local.git /tmp/MiniMax-H3-Skills-Local
mkdir -p .claude/skills
cp -r /tmp/MiniMax-H3-Skills-Local/h3-video-prompt-cn .claude/skills/h3-video-prompt-cn
Restart Claude Code after copying so it picks up the new skill.

Use it in TypingMind

Enable H3 Video Prompt Cn in any TypingMind chat and the model takes it from there. Its name and description sit in the system prompt, and the moment a request matches, the model loads the full instructions itself — you never invoke it by hand, and it costs no tokens until it is actually used.

The model loads H3 Video Prompt Cn on its own as soon as a request matches it.

Works with any AI model

AI skills are plain Markdown instructions rather than provider-specific code, so H3 Video Prompt Cn is not tied to the model it was written for. Install it once in TypingMind and use it with GPT-5, Claude, Gemini, Grok, DeepSeek, Mistral, Llama, or a local model you run yourself — all on your own API keys.

  • Loaded only when it is needed

    The system prompt carries just the name and description. The instructions are fetched on the first matching request, so an idle skill costs nothing.

  • Switch models mid-chat

    Because the skill is instructions rather than code, changing model does not break it — the next model reads the same SKILL.md.

Skill instructions

This is the SKILL.md content the model loads. Read it before installing — a skill is instructions your model will follow.

H3 视频提示词撰写

产出语言默认中文(中文产出版):描述内容用中文书写,字段名、标签、占位符保持英文。 核心机制:结构以官方英文规范 references/base-en.txt(基础模式)/ references/ref-en.txt(全参考模式)为准——它们是 H3 格式的权威契约,不翻译。中文产出版=按英文规范的要求,用中文散文去"填空";字段名、[Shot N]、At MM:SS.mmm、<Picture N>/<Video N>/<Subject N>、保留标记、标签、固定对齐句一律保持英文。base.txt / ref.txt 仅为人可读的中文渲染版,结构以 -en 英文文件为准。

工作流 (Workflow)

  1. 识别输入模式:T2VA、I2VA、FL2VA、L2VA,还是全参考 Ref2VA。
  2. 对于基础文本 / 关键帧模式,阅读 references/base-en.txt 并遵循其最终提示词结构。
  3. 对于全参考模式,阅读 references/ref-en.txt 并遵循其六段改写格式。
  4. 保留所选指南中的准确字段名、段落顺序、标签与计时标注。
  5. 产出语言默认中文(内容中文、结构标签英文);仅当用户明确要求英文时才走英文产出。

基础模式 (Base Modes)

  • T2VA:从文本构建完整的视听时间线。
  • I2VA:从首帧开始,并由此向前发展。
  • FL2VA:描述首帧与末帧之间的连续路径。
  • L2VA:推断一个合理的开头,并收束到给定的末帧。

按 references/base-en.txt 所示顺序使用 integrated_multimodal_description、overall_soundscape、non_diegetic_music。

全参考模式 (Full-Reference Mode)

Ref2VA 改写依次使用 subject_definitions、summary、retention_analysis、detailed_description、overall_soundscape、non_diegetic_music。参考标签在各段之间保持一致。

三条硬规则(2026-10-08 用户纠正 · 曾三次翻车,务必先读)

① summary 只讲剧情与参考关系。镜头走向只允许一句「层级概括」(如「一条连续长镜」「三镜交换」「约第 5 秒凝滞」);镜头运动细节——焦距 / 半径 / 高度 / 角度 / 速度 / 景别 / 摇幅 / 推拉变焦——一律只写进 detailed_description。

  • ✓(官方示例)[reference generation + audio reference] 目标视频展示 <Subject 3> 在 <Subject 1> 中吃饼干。<Subject 4> 带着 <Subject 2> 走进来,萨摩耶扑向饼干。这三镜的互动以 <Audio 1> 作为音色参考,并以一段罐头笑声收尾。
  • ✗(把 summary 写成镜头说明)…机位随即以恒定半径、恒定高度、恒定焦距、恒定速度顺时针绕完全冻结的她转满一整圈…
  • 自检:summary 内出现 DSL 直译的镜头变量 → 删掉、挪进 detailed_description。

② 参考图角色判据(正向):图片作首帧 / 末帧 / 关键帧 / 构图锚 → 独立成 <Picture N>;图片作角色 / 服装 / 环境 / 风格来源 → 内联进对应 <Subject N> 的定义里("…是 <Picture N> 中的…")。

  • 四视图角色卡属后者:写进 <Subject 1>,retention_analysis 只列 <Subject 1> / <Subject 2> 这两行。
  • ✗(把角色卡独立成条并当成视角)<Picture 1> ([Shot 1] 环绕的起点与终点视角): fully_preserved - 环绕自该正面视角起、回到该正面视角止。 ——独立成条=把它声明成构图锚;角色卡承载的是角色,镜头起点由 detailed_description 的文字交代。
  • 详解见 references/reference-image-roles.md;镜头层纪律见 references/camera-and-lora.md §一。

③ 参考标签的编号一经指定就全局不变;四个段落都可以用 <Picture N>,但不得在某一段里新起编号。

  • 官方依据(references/ref-en.txt):summary「uses the previously defined <Subject N>, <Picture N>, <Video N>, <Audio N> labels…Do not introduce new reference labels in this section」;detailed_description「Inserts <Subject N>, <Picture N>, <Video N>, <Audio N> at their first appearance and where their roles apply」。
  • 即:<Picture 1> 在 subject_definitions 里定义成什么,后面所有段落里就还是那个东西,不换号、不重排。编号漂移(同一张图在不同段落变成 <Picture 2>)才是真错误。
  • 写法上仍建议:讲剧情与状态优先用 <Subject N>(它是"人/物/环境",语义更贴),讲帧本身(这里是首帧、那里是末帧、构图对齐这张)才用 <Picture N>。这是可读性偏好,不是禁令。
  • ✗ 反例(真正的错误):subject_definitions 里写 <Picture 1> 是首帧,detailed_description 里却出现 <Picture 2> 指同一张图。
  • ✓ <Subject 1> 立在床边的地板上/<Subject 1> 的面容与整套汉服在这一刻清晰可见;参考关系在 subject_definitions(<Subject 1> 是 <Picture 1> 四视图角色卡中的少女…)与 retention_analysis 里说清。
  • ⚠️ 一条实测备注,不是规则:把 <Picture N> 写进正在描述运镜的句子里,个别批次会让模型把构图往那张图拽。如果出现构图被拽住,先试着把该处换成 <Subject N>;这是排障手段,不要反过来升格成禁令。

阅读 references/ref-en.txt 了解标签规则、保留分析与完整示例。创意机制可从 references/creative-dna-library.md 提取。

当目标是「把定稿技能卡做成招式动画」时,另读 references/card-derived-animation.md(卡片锚点取中间高点帧、锚点写"经过"不写"构成"、不写定格与放缓、主体与法术同频、连续演化写一段)。

当一段里要打多个目标(多块目标物、多个方向、需要明确布局与可读性)时,另读 references/multi-target-and-hit.md(数量写死、方位写死、布局落到空间关系、露出主体忌遮挡)。

当目标是「把这批参考素材的运动迁到自建的角色 / 场景上」时(保留参考视频的动作、机位、硬切与节奏,外观是新建的),另读 references/motion-transfer.md(零动作白描、运动几何七维归属、<Video N> 定义升格、收口句、⭐ 字数配额与精简边界、光流四判据+残余的"时间轴被压缩"问题)。注意它与下一类的区别:成片出来后源视频的画面内容不在里面。

当目标是「把源视频里的某个对象替换 / 修改成参考图的样子」时(人物身份、整个人物、服装配饰、手持物体、场景背景、画内文字 Logo、材质表面、光照影调,以及移除与新增),另读 references/editing-and-replacement.md(三归属维度——外观 / 运动几何 / 光学——、遮罩形态检测、七个不可省模块、目标类型→槽位速查表、可见行为四组、R1/R2/R3 尺寸规则、摘要固定首句与任务类型标记)。成片出来后源视频的画面内容仍然在里面。

整条「定稿卡 → 招式动画」管线(六步 + 崩坏症状速查)见 xianxia-cinematic-video-director 的 references/skill-card-animation-pipeline.md。

视频参考(<Video N>)三玩法 —— 2026-10-22 实测

挂了参考视频(<Video N>)时,先读 references/video-reference-modes.md。 三玩法的官方定义与四种保留标记语义以 references/ref-en.txt 为准;那份文件只补实测判据与写法模板,不重复官方定义。

你要做的事前缀关键纪律
直接改源片(换人 / 换装 / 换风格 / 换渲染)[video editing]保守定律:保留必须限定到几何与运动,外观明确写"重新绘制";风格类改动必须挂关键帧参考,否则失效
从源片末帧往后接[video continuation]必须挂末帧关键帧锚,否则生成段开头多出约 1 秒前置片段;续写只改动作与内容,改机位无效
只借机位 / 剪辑 / 节奏[reference generation]<Video 1> 标 weak_reference
把源片动作迁移到新主体[reference generation]<Video 1> 标 attribute_transfer 并声明"运动与机位唯一来源",逐镜写"逐帧沿用"
换人物(character swap)[video editing]见该文件 §六:guide-latent 路线一致性最好;源片强特征(头发)会回流,发型必须几何可执行句 + 逐镜点名

⚠️「风格转换」一词两义:给源片换皮= video editing;拿源片风格造新片= reference generation。开写前先问清是哪种。

合规:上表提到的关键帧锚可以 <Picture N> 独立成条(属首帧 / 末帧 / 关键帧锚用途);后续段落的写法见硬规则 ③(编号全局不变,不新起编号)。

镜头 / 参考图 / 交付格式 —— 四条 2026-10-05 实测补充

做运镜类镜头(推拉摇移环绕航拍 POV 双人机位…)时,按这个顺序读:

文件什么时候读核心内容
h3-camera-motion-lib(独立 skill)要写镜头运动的句子时,第一个读它⭐ H3 运镜提示词库:7 个运镜族 + 核心纪律 + LoRA 台账 + 现实边界,每条给可直接粘贴进 detailed_description 的中文镜头句与实测状态(✅/🟡/❌)。不依赖 camera DSL——DSL 降级为可选校验,两者冲突时以库的「实测」一栏为准
references/camera-and-lora.md要决定挂不挂 LoRA,或查变量纪律速查变量纪律(摇镜不写焦距 / 推拉必写焦距锁定 / 变焦用"变焦");**LoRA 优先级:专用 > 不加 > Jojocodex(仅特定情况)**+触发词台账;起手景别的现实预期(镜头句本体见上一行的库)
references/reference-image-roles.md有多张参考图时构图锚 vs 内联定义(独立成条=构图锚,会被拉回它的构图);环境一律 weak_reference;环境写"描述式"不写"清单式"(清单会把画面推宽);<Picture N> 只进 subject_definitions;首帧锚定的取舍
references/writing-order.md每条提示词动笔第一句之前书写顺序铁律:画面里"先出现的东西"写在最前面;遮挡/揭示、跨越/甩镜/航拍、POV 三类起手写法
references/output-template.md每次交付交付格式模板(参考图映射 / 生成设置 / 推荐 LoRA / 节拍 / 六段提示词 / 提交前须知 / 待跑后核对)
references/negation-guard.md交付前自检否定式两级闸门(L1 词表 + 白名单)、正向化替换表、落地方式与脚本接口
references/audio-reference.md挂 <Audio N> 参考音频时⭐ 角色形象先验 > 音色参考(reference 的根本机制)+「F0 对了 ≠ 音色被复刻」的判定陷阱;四种关系标记的实测基线(含 partially_copy 区间控制失效);Sx 编号须与接线顺序一致(三线同号);台词约束不可省;过肩镜头与正向单人约束;<d> 豁免白名单
references/video-reference-modes.md挂 <Video N> 参考视频时(editing / continuation / reference generation 三种)⭐ 三玩法判据与选型表;editing 保守定律(保留限定到几何与运动 + 外观"重新绘制");风格类改动必须挂关键帧参考否则失效(纯文字无效,杠杆:关键帧 > 风格图内联 > 风格 LoRA);动作迁移 attribute_transfer 写法模板("运动与机位唯一来源" + 逐镜"逐帧沿用");continuation 必挂末帧锚(否则开头多约 1s 前置片段)+机位重构无效;换人两路线(guide-latent v1.1 推荐 / 适配器 v1.5 需更强约束)+源片强特征回流的四条写法;retention_analysis 括号写法(括号只属该段、<Audio N> 不带、只放「范围」不放「角色」、括号内禁全角冒号、A/B 四套须完全一致)
references/cut-and-timing.md源片有硬切 / 叠化,要定镜数与切点时逐帧 124 帧定五件事(几镜 / 切点在第几帧 / 过渡方式 / 每镜机位 / 每镜景别写数字);At MM:SS.mmm 必写且写真实值不补偿(省掉 At 第二刀会整刀丢失);每个切点都要 cut on action(紧贴 At 之后第一句,按源片实际状态写、不绑"第一帧");转场语法(硬切五种动词 / 叠化与划像需明说 / 闪光切等无语法位 / 只改距离优先用镜头运动)——这部分与任务类型无关,任何 H3 提示词都适用;节拍稀疏优先(多个 cut on action 时自然稠密);失败模式速查
references/motion-transfer.md要把参考视频的动作 / 机位 / 硬切迁到别的角色或场景上时零动作白描(别把动作写成可表演的台词)+运动几何七维逐镜归属位置/朝向/轮廓/位移与速度/姿态/占位体积/接触关系;<Video N> 定义升格;收口句;⭐ 字数配额:2622→1701→1416 字 ⇒ 运动能量 0.73→1.52→1.65、r 0.14→0.44→0.50(单调),但砍掉场景外观会让赛博朋克退化成普通公园 ⇒ 取向 1500–1700 字;光流四判据与残余的"时间轴被压缩"问题
references/editing-and-replacement.md要替换 / 编辑源视频里的某个对象时(换脸换人换服装换物体换背景换文字换材质换光照、移除、新增)三归属维度(外观←参考素材/运动几何←源视频/光学←源视频环境);遮罩形态检测(半透明 R≈80 为默认路径);七个不可省模块(REBUILD / LIGHT / SYNC / PERFORMANCE / OCCLUSION / FIT / SEAM / NO_ADDED_EVENT);目标类型→槽位速查表;可见行为四组必须带同节奏约束;尺寸冲突 R1 保持占位(默认)/ R2 忠于参考 / R3 折中;摘要固定首句与任务类型标记

镜头句精简纪律 —— 没装运镜库时的兜底(2026-10-09 更新)

⭐ 写任何镜头运动的句子时,第一个查 h3-camera-motion-lib(H3 运镜提示词库,专家包内的独立 skill)。 它按运镜族给出可直接粘贴进 detailed_description 的中文镜头句+实测状态(✅/🟡/❌)+推荐 LoRA+坑, 不依赖 camera DSL——DSL 降级为可选校验,两者冲突时以库的「实测」一栏为准。 本文只保留精简核心纪律(够你在没装那个库时不踩坑),完整版一律以库为准。

精简核心纪律(六条,2026-10-09 校准):

  1. 变量纪律:摇镜不写焦距;推拉必写「焦距全程锁定在同一档位」;变焦用"变焦"表达 + 机位恒定;横移写「镜头朝向全程锁定」;升降写「镜头姿态全程保持水平」;翻滚必写方向。
  2. 书写顺序:画面里先出现的东西写在最前面(遮挡 / 揭示先写前景遮挡物;跨越甩镜航拍先写门洞枝叶高空全景;POV 主体不入画、不写景别区间)。
  3. 时刻与配速:用官方语法 At MM:SS.mmm,配速=At 起点–结束点两个时刻;禁止「在 3 秒时间内…」这类自造时长短语;时刻会漂移约 ±1s,动作先后次序要用文字兜底。
  4. 整圈环绕:圈数与时长必须同时给——圈数靠「转满一整圈 + 末了回到正面」的收束句,配速靠起止时刻。只给圈数→转多圈或中途停;只给时长→不转或转不完。(写"快速"会让速度词压过收尾句,实测冲过正面转第二圈。)
  5. 环境写"描述式"不写"清单式":逐一点名"柱列 / 地砖 / 宫灯必须可见"会把画面推宽;改成一句"主体所处的环境是什么"即可。它是止损手段不是锁半身手段(实测主体放大 2.4–3×,仍 0/3 达腰部以上);真要锁取景 → 用 I2VA 真实首帧。
  6. <Picture N> 编号全局不变:编号一经在 subject_definitions 指定,四段里就都是同一张图,不换号、不新起编号。summary 与 detailed_description 都可以引用它(官方规范允许);讲剧情与状态优先用 <Subject N> 是写法偏好,不是禁令。

LoRA 一句话:专用 > 不挂 > Jojocodex(仅特定情况)。 ⚠️ Dutch Angle Slider 权重即倾角:1 ≈ 20°,常用 2.0(旧记"1.0≈1°、要 10–20"是错的)。

构图可执行性 —— 把形容词变成模型能执行的东西(2026-10-26 实跑沉淀)

共同根源:模型会把形容词当事实渲染。你对它说的每个修饰语,它都要想办法画出来,而它理解的"画法"往往是你没预料的那一种。下面五条是同一原理的五个实例。

① 开写前先声明运行模式

本批跑的是 Ref2VA(六段) 还是基础模式(三字段 integrated_multimodal_description)?写错整套作废。 批次文件开头写一行 模式:Ref2VA [keyframe completion],与工作流节点对齐后再落笔。

② 两套命名空间,起始编号不同

命名空间起始实例出现在哪
提示词标签1<Picture 1> <Subject 1> <Audio 1>六段正文里
接线端口0ref_image_0 ref_audio_0工作流 JSON 的 inputs 键

写提示词从 1 数,接端口从 0 数。混用会导致挂图错位且报错信息不指向真正原因。

③ 比喻动词会被按字面执行

写 hovering(悬停)→ 指针真的浮在盘面上方,尖端落在两格刻度之间。要表达"即将触碰",只能用物理证据:

  • 贴平:lies flush against the surface
  • 底面接触:its underside in contact with it
  • 影子:throws a shadow directly beneath itself, and that shadow touches X at its own tip

影子相接是"两者共面"的硬证据,比任何形容词都可靠。判据:想表达"挨着 / 贴着 / 即将碰到",就写"接触 + 影子落在正下方"。

④ 微距必须锁"画面里只有什么"

只写"极限微距"而不锁边界,模型会自己补背景——实测把一块表盘补成了带地平线和落日的白墙。

固定句式:The frame contains only X and Y.

⑤ 含人物的镜必须写景别锁

  • 只写"略前倾" → 被放大成深鞠躬(首帧相似度 0.549)
  • 只写"取到胸口" + 一堆微距式细节 → 被推成大特写,天空全丢(0.404)
  • 补上景别锁后:0.9986 / 0.9950

固定句式:取景与首帧一致:他全身入画,自头顶到鞋底完整可见,头顶距画面上缘约一成,脚下与画面下缘之间留出一段空地,地平线横在中景。

推论:描述视线与姿态的词会直接决定体态。写"视线落在身前地面"会诱导前倾弯腰——想让他站着,就别提"看地面"。

⑥ 有读数的物体必须写角度关系

写"两根针以不同角度放射" → 模型给任意角度。实测四张钟面里三张读不出目标时刻(11:20 / 12:18 / 10:15)。

必须写:离竖直方向偏几度、谁在谁的左边、收成多窄的 V。

⑦ 跨镜连续性清单(交付前逐镜核对,任一项不符即穿帮)

#项本项目实例
1同一道具的结构件数巨钟两根针,五个含钟镜头必须一致
2有无可读文字盘面无数字,只有一圈放射刻度
3读数状态所有钟面都停在午夜前一分(窄 V 落在盘顶)
4全片唯一的例外只有铯钟一场是冷调,其余全暖橙

音频时间线对齐(带对白音频的 Ref2VA)

当输入包含对白 / 人声音频(<Audio N>)时,先转写音频,再设定分镜时间戳——这是 Ref2VA 带音频时最常见的失败点:说话人错位(角色 A 在画面中说话,而音频已切到角色 B)。

  • 音频优先(Audio-first):运行 Whisper(faster-whisper,模型 small)获取每条语料的起止时间戳与说话人 ID(可区分时用 S1/S2)。将同一说话人连续的语料合并为"话轮";话轮之间的间隙即自然的切分点。将每个 [Shot N] At MM:SS.mmm 锚定到这些话轮边界——不要凭空猜测。注意:Whisper 可能听错数字 / 人名(如"心之星"→"星之星");时间戳可靠,内容请用用户原始文本。
  • 粗对齐,不要紧对齐:分镜切点应大致匹配音频中说话人切换的边界(±0.5–1s 即可),但不要逐帧精确绑定。在每句中间的停顿处切、或删掉所有时间戳让模型自由发挥,都会让节奏变差。
  • 硬规则——禁止说话人错位:绝不让"角色 A 在画面中说话的分镜"与"音频中角色 B 实际在说话的片段"重叠。核对每个 [Shot N] 的时间区间与在该区间内实际发声的说话人(S1/S2)一致。

挂 <Audio N> 参考音频时,另读 references/audio-reference.md —— 那里有四种关系标记的实测基线、Sx 编号与接线顺序必须三线同号(Subject N = S N = Audio N)、台词约束不可省(简化 <Audio N> 定义时最易踩)、以及正向单人约束与过肩镜头两种「锁定单一说话人」的写法。

输出规则 (Output Rules)

  • 对白 / 歌词必须使用 <d>[Language] ... </d> 标签(铁律):说话人身份、ID、动作与语气放在 <d> 之外;<d> 内部只放语言标签与逐字原始口语——不翻译、不改写、不追加英文翻译。示例:<d>[Chinese] 今天的星星,好像比昨天暗了一点点。</d>
  • 音频复用模式(fully_copy)——绝不再合成:<Audio N> 作为最终音轨复用时,只描述谁说话、何时说话、口型跟随音频;不添加语气/韵律/停顿/情绪指令(会触发再合成导致语音糊掉)。
  • 改写段落用中文书写;对白、歌词与可见场景文字保留原始语言(歌词保留中文原文,外文对白 / 歌词保留其原文)。
  • 按构图、主体、环境、动作、镜头、声音,以及参考内容出现的精确时点来描述每个分镜。
  • 避免剧情摘要、未解析的参考标签,以及与请求时长不符的计时。
  • 提示词正文内不使用 markdown 装饰符号(2026-10-01 用户定规):**加粗**、# 标题、- 列表、表格、反引号等一律不写进实际发送的提示词块。理由两条:① H3 的格式契约里没有 markdown 强调这一项,模型把这段当纯文本读,** 属于官方规范明确要求剔除的"装饰性标点"(remove repeated tildes, emoji, bullets, and repeated or decorative punctuation);② 虽说 token 代价极小(实测 15s 提示词里 46 个 ** 仅约 46 tokens、占 1.2%),但"契约里没有的东西别塞进去"——它要么被无害忽略、要么变成句子流里的噪声,两种都不划算。
    • 强调改用「语序与句位」:把关键名词放句首、把结构逐条写死、跨镜元素每镜各写一遍——效果比符号稳。
    • .md 交付文件里、提示词块以外的加粗可以保留(节奏表 / 编排说明 / 素材清单 / 提交建议),那部分不参与发送,纯为阅读。
    • 写完后自检:sed -n '/^\``text/,/^```$/p' 文件 | grep -c '**'` 应为 0。

分镜 / 批次 / 参考图 约定(Shot · Batch · Reference)

被上游设计 skill 调用生成视频提示词时,统一遵循以下定义与硬规则(设计 skill 无需各自重定义,直接引用本节即可)。

概念

  • 分镜(Shot):最小叙事 / 视觉单元,等价于本 skill 提示词里的 [Shot N]。每个分镜自带时长,由分镜设计任务决定如何切分。
  • 批次(Batch):一次 H3 生成单元 = 一组符合本 skill 结构(T2VA / I2VA / Ref2VA / FL2VA / L2VA)的提示词,可包含多个分镜(≥1)。一个批次即一次在 H3 节点提交生成的单位;一个批次 = 一个输出文件。

硬规则

  1. 批次时长上限由设备决定,且应在分镜设计前确定:在每个设计 skill 的「简报 / 起始门」先问用户「本次一次生成几秒?」可选 5s / 10s / 15s(或用户指定值),记为批次时长上限并贯穿到分镜设计步骤。分镜设计任务据此把分镜设计在批次内,而非事后强切。
  2. 分镜时长一般 ≤ 批次时长(设计期遵守,本步不重切):分镜是创作单元,由分镜设计任务按叙事 / 视听决定,设计期就已遵守批次时长上限(一般单镜 ≤ 上限)。本步(视频提示词)只负责打包:把设计好的分镜按时长累加归入批次(同批次各镜时长之和 ≤ 批次时长上限),不重新切分已设计的分镜。仅当某个分镜本身在设计期就 > 批次时长上限(偶发),才在生成层做「机械分段」:将该分镜切成多个生成子段(如 Shot 3 → 3a / 3b),但不改动分镜的创意内容与音频时序——该分镜的音频跨子段连续,仅生成层拼接。
  3. 参考图只用占位符,禁止写路径 / 目录:最终提示词中,参考资产一律用 <Picture N> / <Video N> / <Audio N> 占位符指代(定义见 Full-Reference Mode)。严禁在提示词里写入任何图像 / 视频 / 音频文件的绝对或相对路径、文件夹目录。占位符 → 实际文件的映射由用户在 H3 节点侧按端口完成。
  4. 一个批次一个文件(不合并):不要把所有分镜塞进一份文档。每个批次输出为【一份独立文件】(建议命名 batch_01.md、batch_02.md…),文件内含该批次全部分镜的 H3 提示词 + 端口 / 顺序 / 时长 / 分辨率设置建议。这样便于逐批次修改与重跑。
  5. motion-context 在连续批次的衔接边界问(H3 跨段运动连续机制):当一段连续镜头 / 序列跨多个批次生成时(如某分镜因超上限被机械分段为 3a / 3b,或相邻批次要拼成同一连续场景),在批次与批次的衔接处先问用户「是否使用 motion-context?」——它用于保持跨段运动 / 音频连续,但带来副作用:① 衔接处中间 22 帧会被重复(22 ÷ 24fps ≈ 0.917 秒);② 提示词时间标注上,第一段(首批次)保持不变,第二段及之后的各段需整体后延 0.917 秒(其 [Shot N] At MM:SS.mmm 时间戳在原始衔接点基础上 +0.917s)。若不使用 motion-context,则按标准衔接(无 22 帧重复、时间标注无需后延)。注意:motion-context 是「批次衔接」闸门,不是「切分单镜」闸门——单镜的设计切分不由它触发。
  6. 批次自含——提示词内禁止跨批引用(见下一节)。

调用方(设计 skill)应在「简报 / 起始门」先问批次时长上限并贯穿分镜设计;「视频提示词」步骤落实:把设计好的分镜按时长累加打包为批次(同批之和 ≤ 上限,一个批次一份 batch_XX.md),不重切分镜;仅当分镜本身超上限时在生成层做机械分段(音频跨段连续);motion-context 在连续批次的衔接边界问(启用则第 2 段起 22 帧重复 + 时间标注后延 0.917s、第 1 段不变);参考图使用 <Picture N> 占位符而非文件路径。无论上游分镜怎么设计,本步保证:每个批次 ≤ 批次上限;分镜创意与音频时序不被强切破坏。

批次自含 —— 禁止跨批引用(2026-10-01 用户反复纠正 · 铁律)

H3 每个批次都是独立生成:模型看不到上一批的成片,也不知道存在"上一段"。任何指向前一批的措辞都是无效文本,且会让本批丢掉关键状态(写"承接上一段的高速飞行",模型既接不上、也没被告知"他此刻在飞")。

禁止写法(提示词块内一律不出现):

  • 承接上一段的高速飞行 / 承接上一段 / 延续上一段 / 接着上一镜 / 如上 / 同上
  • 双翼自上一段展开后持续保持展开(把他批的结果状态当成本批的前提)
  • 承接上一段的音色 / 电子脉冲(overall_soundscape / non_diegetic_music 里同样禁)

正确做法——把上一批的「结果状态」改写成本批能独立表述的「开场状态」:

❌ 跨批引用✅ 自含写法
承接上一段的高速飞行,他仍在疾飞他在高空贴着云海高速掠行,长发与长氅被疾风向后扯成直线
双翼自上一段展开后持续保持展开双翼在他背后展开着,随他的甩臂与抬臂摆动
承接上一段的疾速电子脉冲推进开场即起的疾速电子脉冲持续推进

判据一句话:把"上一段"这三个字删掉后,这句话还能不能独立成立?不能 → 重写成本批自己交代的画面。

  • 例外:retention_analysis 里的 (出现于 [Shot N]) 是本批内部镜号索引,正常写法,不属跨批引用。
  • 批次之间的实际衔接(硬切/角度区分/是否挂首帧图)属分镜设计,写在批次文件的块外说明里,不进提示词块。
  • 顺带自查:承接 / 上一段 / 上一镜 / 如上 / 延续 这几个词,写完 grep 一遍,块内应为 0。
  • 反向同样禁(2026-10-01 二次踩坑):下一段 / 下一镜 / 下批 / 作下一段首帧 也是跨批引用——告诉模型"这个视频要为下一段服务",而模型不知道下一段。末帧图只写「视频以 <Picture N> 为末帧收束」;它要作下一段首帧这件事,写在批次文件的块外衔接说明里。同理禁写「该图同时作下一段首帧」「为下一段留出起手」。

否定式描述禁用令(H3 没有负面提示词)

H3 没有负面提示词字段,也不理解「没有」。写「没有什么」会让那个东西更容易出现——模型抓住名词就画出来。

硬规则:

  1. subject_definitions、retention_analysis、detailed_description、overall_soundscape、non_diegetic_music 里禁止裸否定(no X / without X / never X / X-free / 不要偏灰)。
  2. 要去掉某个元素,删掉提到它的整句,而不是补一句否定。
  3. 表达「空/无」改正向状态描写:no cars on the street → an empty street。
  4. 纠正颜色/风格只写正向目标值(bright pale ice-blue),不写「不要偏灰偏绿」。
  5. 一个分镜只描述这一个分镜要展示的那一样东西,不捎带别的卖点(实测:胸标镜头顺带写拉链,模型生出「手摸门襟/拉拉链」动作)。
  6. 写完全局自查 no / never / without / -free / 不 / 没有 / 无,命中按两级判定复核,不要一律删。
  7. 交付前必须过「否定式闸门」(机械检查,见 references/negation-guard.md):不/没有/无 + 运动或状态词 = L1 硬拦,一律改写成正向句; 不要用朴素的字符级子串拦截(见到"不"就拒会误伤"不同位置""不仅")——必须"词表 + 白名单"两级判定。

两级判定:裸否定(禁) vs 替换式否定(安全)

  • 裸否定=点名不想要的东西却不给替代物 → 禁(模型抓名词就画)。
  • 替换式否定=「弃用旧属性 + 显式指定新属性」,结构固定为先点名旧属性、紧跟「改为/换成/而是」给出新属性 → 安全,实战有效。
写法判定
»<Picture 1> 中粉色睡衣不保留,角色改为穿着<Subject 2> 的牛仔外套«✅ 安全
»服装与鞋子不沿用<Picture 1>,改为穿着由 <Picture 2> 定义的汉服造型«✅ 安全
»with no ring, no loop«❌ 裸否定(实测长出大圆环)
»不要偏灰、不要偏绿«❌ 裸否定(实测强化灰绿)
»不要出现中文«❌ 裸否定

判据一句话:否定后面有没有紧跟「改为 / 换成 / 而是」?有 → 安全;没有 → 改掉或删掉。

正向形容词不算违规:matte、flat、plain、clean、quiet、bare、empty 是正向写法;被禁的是「no / never / without + 名词」指名否定。

「恒定陈述」也归硬拦(2026-10-05 运镜测试补充)

保持不变 / 固定不变 / 始终不变 / 全程不变 / 恒定不变 不属"点名旧属性"那一类,但同样以否定兜底—— 语义上没给出该维度的取值,读起来仍是"某个可以变的东西"。

✗✓ 正向写法
机位保持在原地不动 / 机位本身不移动机位位置全程固定在同一点
机位只横向侧移、不摆转机位沿横向侧移,镜头朝向全程锁定在同一方向
机位平滑漂浮、没有晃动机位平滑漂浮,画面全程平稳顺滑
镜头焦距保持不变焦距全程锁定在同一档位
…的位置与大小保持不变…的位置与大小全程恒定
定格不动定格在同一瞬间的形态上

⚠️ camera DSL 的 negative clarifier 必须按本表转写——The camera stays in place. / with no shake / does not turn / The focal length stays the same. 这些英文否定句直译就是裸否定。完整对照表见 references/negation-guard.md §三 与 references/camera-and-lora.md §一。

待验证假设:稳定镜头里写"不晃动",可能反而诱发抖动(提到 X 会提高 X 的出现概率)。目前无可靠量化指标(相机抖动只能目视),要验证只能做同镜同种子对照。

替换 / 编辑类四条判据(2026-10-25 定稿)

  1. 保留但移位 → 独立成 <Subject>:片中把某物「取下 / 移开」、成片里它仍然可见(眼镜拿在手里)→ 必须编号,并写明此刻在哪;主体外观串里不写它,改写「他的脸是裸露的」。否则一脸一副 + 手里一副。
  2. 待清除物件 → 不编号,写进 <Video 1>:眼镜、墨镜、耳麦、耳机、耳返、帽子、手持麦、烟、包……凡成片里不该出现的「身外之物」都按这一类处理。写法:在源片里,X(可多件并列)标记为待重建区域,成片里该位置由 Y 取代,并把 <Video 1> 的 retention 从 fully_preserved 降为 partially_preserved。理由:<Subject N> 只代表「目标视频中实际会用到的内容单元」,且 retention 标记只有四个固定值、没有「删除」项(自造 removed 属违规)。清单要列全(耳返、手表、戒指、烟最易漏),替代物要写具体,围绕该物件的动作要么一并删、要么改成替换。
  3. 待删物件不能进主体指代:本片只替换其中的「带着耳麦的歌手」 等于要求保留耳麦。指代只写保留类特征(位置 / 服装 / 体型)。
  4. 删除用动词:本段删除 X + 只剩 Y 有效;不保留 / 没有 / 不出现 无效(不出现 还是 L1 硬拦)。写完用 [^。;]{0,18}(?:不|没)[^。;]{0,18} 扫一遍,应为空。

背景零描述:场景、灯光、光位、色彩与背景全部严格沿用 <Video 1> 对应时刻。不写光点 / 星芒 / 灯束 / LED / 光斑 / 观众席 / 场馆类型——写了就会被画出来(实测背景亮度 33.7→61.7、饱和度 0.042→0.132)。

参数优先于措辞:段内自编镜头、背景被重画、首帧画出参考图版式,先查 turbo 权重(换人类建议 ≥0.9);降 turbo 去「油」会牺牲参考贴合度。实测 7 镜 / 5 秒在 turbo 0.9 下可用。

参考图含「同物体多状态 / 多实例」→ 按位置拆 subject(Ref2VA 铁律)

一张 <Picture N> 参考图里若出现同一个物体的两种或以上状态并排(如一把折扇同时画了「收拢态」和「展开态」、同一角色两套服装并排、同一道具正/侧两面同框),绝不能把它写成单一 <Subject M>:模型会在图里看到多个实例,于是自行"补出"一把多余的扇子 / 一件多余的道具。本会话实测:单一 subject 指向同一张含两态的图 → 成片凭空多生成一把扇子。

硬规则:

  1. 每个状态各定义一条独立 <Subject M>,并显式锚定它在图里的位置(left / right / top / bottom / front / side)。
    • ✅ »<Subject 3> is the closed merged form of the folding fan — the shut fan shown on the LEFT of <Picture 3>: its folded ribs and closed silhouette follow the left merged-state fan in <Picture 3>; this subject is the fan BEFORE it opens.«
    • ✅ »<Subject 4> is the fully opened form of the same fan — the opened fan shown on the RIGHT of <Picture 3>: its spread ribs and surface artwork follow the right opened-state fan in <Picture 3>.«
    • ❌ »<Subject 3> is the elegant folding fan whose shape and artwork come from <Picture 3>«(单一 subject 指向含两态的图 → 必多生一把)
  2. 叙事衔接写清"态→态"转换:让前一 subject(闭合态)射出 / 演化成后一 subject(展开态);尾帧若复用某状态的图(如 Picture 4 = 展开扇满屏),明确写 the opened fan of <Subject 4>,不要笼统写 "the fan from <Picture 3>"。
  3. <Subject N> 与 <Picture N> 是两套独立命名空间:可同时有 <Subject 4> 与 <Picture 4>,互不冲突;歧义全靠"位置锚定"消除。
  4. 该纪律适用于一切"一图多体":同角色多套服装并排、同道具正/侧视并排、同道具双态(如剑的 不发光态 / 发光态、扇的 收拢态 / 展开态)、同武器多形态等,一律按位置拆 subject,并在各自定义里注明"何时用哪一态"。

隔空操控 / 非接触施法 的动词纪律

描述"施法让道具自行飞出 / 展开 / 旋转"时,手势动词决定模型是否画出"手握道具":

  • ✅ 用 point / extends a finger and points a light gesture toward X / a single finger forward —— 表达"隔空一点",手与道具不接触。
  • ❌ 用 flick / 挥 / 弹 / gives X a flick —— 模型理解为"手触道具并拨动",会生成角色握住道具的画面(本会话实测:写"轻轻一弹扇子"→ 成片里手抓着扇子)。
  • 配套写法:扇子/剑等出场用 launches off on its own / streaks through the void / snaps open on the wing,强调"自行"而非"被手握着动"。

手势粒度不可控 —— 精细手部动作会被抹平(2026-10-01 实测)

H3 不解析手指数量 / 手形:写 双指并拢 / two fingers held together / 捏诀 / 剑指,成片仍恒定渲染为"单指伸出向前一点"。

  • 实测:片头 S1S2 写「另一只手双指并拢向扇子用力一点」,两次实跑均为单指一点。
  • 硬规则:非接触施法 / 指物一律用最粗的手势语义(a single finger extended forward, pointing),不要指望措辞区分手指数量或捏诀。
  • 要表达"更用力 / 更郑重":改从身体层面加码——侧身(turns his body to one side)、沉肩、袖袍甩动、下颌与眼神,或加强光效强度(蓄能更亮、法术核心更炽烈),而非抠手指细节。

风格统一 / 长镜合并 / 参考链 实战要点

  • 统一风格做全量替换 + 残留自查:切换整体画风(如写实→超现实赛博朋克)时,旧风格词(如 pure white void)要整段替换,再 grep 自查无旧词残留——局部替换会留尾巴导致风格串味。
  • 长镜合并前先确认显存预算:单条长镜头在设备显存上限内可合并(如 5080 16GB 上 13s / 328 帧跑完余 ~9GB,无需机械分段);只有超预算才拆批。合并后若中段注意力漂移(细节弱化 / 悬空物体不稳),再回退分段。
  • 参考图只用原始真源:身份走四视图卡、服装走设计图,不拿 AI 生成中间稿当参考图——级联派生会让油感逐级累积、一致性逐级漂移。

单条时长承载量 —— 别把动作塞过量(2026-10-01 实测)

  • 经验值:5s 单条约承载 2 个动作节拍(≈1 次转场/穿场 + 1 次主体揭示或跟随),即 ~2.5s/拍。塞第 3 个独立动作,模型会来不及做、停在已有状态里收尾。
  • 实测:片头 S3(5s)写了 ①穿扇面 ②后拉揭示主体平飞 + 侧前方跟拍 ③拧身起转——前两拍出来,第 3 拍(转身)完全不呈现,成片一直停在飞行态。
  • 换算:节拍越多、单拍时长越宽(长镜施法段可 ~3–4s/拍);要"多一拍"就得给足时长——S1S2 要 15s 才够 4 拍,S4 合并到 10s 走 ~4–5 拍。
  • 对策(二选一,别硬塞):①删掉最不关键的那一拍;②把该拍单独拆成一段、给足时长。

参考命名与保真度 纪律(2026-10-01 用户纠正)

  • 不写内部状态词:给参考资产命名时直接写名字——天鹅翼 / 冰雷剑 / 年轻男性 / 深靛紫长氅;不要写「定稿 / 最终版 / 第 N 版 / B 款」这类项目内部状态词,模型不理会「定稿」。示例改写:<Subject 3> 是<Picture 3>(天鹅翼定稿)的机械双翼 → <Subject 3> 是<Picture 3> 中的天鹅翼。资产类型(四视图卡 / 设计图)可保留,但同样不必写成「(…)」括注。
  • fully_preserved 只是保真声明,不控制形变 / 硬度:规范定义 = 该参考的「定义特征在成片里被完整保留」(与官方示例里"狗的毛/耳/尾 are retained"同机制),不含"硬 / 固定 / 不动"语义,不会把机械翼、道具"僵化"。要「柔韧 / 弹性 / 轻灵」的观感,改的是 detailed_description 的动作与材质用词(加回弹、颤动、尾缘轻摆、轻若浮羽等),不是把 fully_preserved 降级为 partially_preserved(后者反而让形态漂移)。

跨镜持续元素必须「每镜再点名」(2026-10-01 实测)

H3 按镜生成:只写一次「出现 / 展开 / 亮起」的元素,会在后续镜头里丢掉——模型把它当成那一镜的一次性动作。规范 §4 明文:"Continue using the same label in later shots without redefining what the label represents."

  • 硬规则:要跨镜持续的元素(翅膀、披风、光环、手持道具…)必须在三处齐全——① subject_definitions 定义里写明"展开 / 出现后各镜持续保持";② retention_analysis 的 (出现于 [Shot …]) 覆盖全部相关镜;③ 每个镜头的 detailed_description 正文里再次点名该 <Subject N>。只做①②、正文漏点名,模型照样会在那一镜丢掉它。
  • 实测:S4 只把 <Subject 3> 翅膀写在 [Shot 1](展开),[Shot 3] 正文完全没点名 → 后段翅膀消失(用户实测反馈)。
  • 顺带绑定身体:贴在角色身上的持续元素(翼、披风)要写"翼根 / 根部与背部相接、随身体动作摆动",否则会被当成游离物飘走。

大型附属物必须写「显式尺度倍数」(2026-10-01 实测)

只写"展开双翼 / 翼板铺开",模型会按人体配件的比例去渲染 → 翼偏小、贴着背像装饰件。要它有"巨大感",必须在 subject_definitions 里给出可量化的倍数关系,并在正文各镜补一处画面占幅参照。

  • 写法:单侧翼展与他身高相当,展开后两翼总跨度约为他身高的 2.5 倍,翼尖向外远远越过他的头顶与腰侧的轮廓之外,双翼面积约等于他身体面积的数倍——他整个人被展开的双翼挟在中间、显得小巧。
  • 正文补参照(每镜一句,别只写在定义里):翼尖直接冲出画面左右边缘、翼面高出他的肩背许多、单片羽板弦长比躯干还宽、双翼掠成两片巨大的白色光面。
  • 仍偏小时的退法:① 机位放宽、直接让翼尖出画("出画"本身就传达"大到框不住");② 倍数往极端写("接近身高的 3 倍"比"略大于身高"更易被采纳)。
  • 同理适用:披风拖尾、光环、法阵、巨剑等一切"本该压过人体体量"的附属物。
  • 特写镜必须把「接入点」框进画面(2026-10-01 实测):纯翼面 / 纯道具的局部特写里没有身体参照,模型会把附属物移栽到错误部位——实测翅膀"像长在手上"。修法:① subject_definitions 写明"根端嵌入哪个解剖部位(肩胛骨 / 背部)、与身体连成一体";② 局部特写改成背视 / 过肩机位,画面下方或边角始终带到接合处(肩胛 + 一截背幅 + 颈后发丝);③ 若仍错位,把接合处放在画面上三分之一、并让肢体(双臂双手)离开附属物所在区域入画。

道具交接 / 朝向 / 破坏形状 的三条写法(2026-10-02 实跑修正)

成片反馈出三类一致性错误,成因都是只写了结果、没写结构与次序:

实跑症状根因修法
剑凝成后手握住了剑身而不是剑柄镜头没跟随道具移动,画面只框住局部加镜头跟随句:镜头随即随剑向后微微退开半步、把整把剑完整收进画面,再给部件次序:自下而上依次是手 → 短握柄 → 护手 → 剑身 → 剑尖
举剑时剑尖朝下(写了"剑尖朝上"仍反)"朝上/朝下"是形容词,模型会忽略改成部件次序 + 最高/最低点:剑柄握在手里、是整把剑最低的一段,护手之上是晶体剑身,剑身竖直向上立着,剑尖是整把剑最高的那一点
山被劈成两半,与 X 形剑气对不上破坏结果没跟着攻击形状走破坏形状必须复刻攻击形状:X 形剑气 → 各留下一道斜切痕(左上→右下 / 右上→左下),交叉处最深,沿切痕裂开、自交叉点向外崩开

通用做法:

  1. 道具定义里就给出部件次序(自下而上 / 由近及远),并写明握持部位:他握持时手指收拢扣在护手下方那一段短握柄上,剑身自护手之上向前伸出、与手掌分开——避免"握住剑身"这类错握。
  2. **朝向一律用"次序 + 最高/最低/最远点"**表达,不要只写"朝上 / 朝下 / 指向 X"。
  3. 破坏结果 = 攻击形状的镜像:斩击是几道、什么交叉角度,裂口就是几道、什么交叉角度。
  4. 抽象施法动作建立不了因果(2026-10-02 实跑):写"持扇手臂轻轻一送 → 空气被撕开",成片裂口根本没出现。模型不知道这个结果是谁、怎么造成的。必须给四步:
    • 起势(举过头顶 / 抬臂蓄势)——让动作有来源
    • 轨迹(自上下笔直一劈)——把"一送"换成有方向、有落点的动词
    • 中间态(关键)(划过之处先裂开一道细细的朱红光线)——从无到有的结果会被模型整段跳过,必须先有一个可见的中间态
    • 结果(沿这道线自上而下撕开、张开成竖直裂口,走向 = 挥劈轨迹) 并在后一镜回指一句"这道裂口就是方才那道朱红光线张开后的样子",把中间态与结果锁成同一件事。 判据:把动作词盖住,还能不能看出这个结果是谁造成的?不能 → 补起势与中间态。

特效类元素必须给「结构层」,不能只给颜色(2026-10-01 实测)

剑气 / 刀光 / 光束 / 火焰 / 能量波这类特效,只写颜色词("冰蓝发光 + 紫色电弧")会被渲染成一条纯色光带或一块光斑——有色彩、无质感,用户反馈"只有颜色、不够酷炫"。必须按"层"来写,每层给一个画面里能直接找到的名词。

  • 六层写法(以剑气带为例):① 芯 = 一根最亮的白蓝光芯(中心线);② 束 = 一束密集的锯齿状电弧光丝扭绞成带,电弧沿带身分叉、扭结、周期性跳出带缘(结构主力,代替单薄的一条边光);③ 彩 = 蓝紫渐变 + 从带缘外跳的紫色分叉电弧;④ 壳 = 缠在带体上的半透明冰晶片层,转向时折射棱光;⑤ 屑 = 沿带飞散的尖棱冰晶碎片;⑥ 衰减 = 近端最亮、远端渐隐;另给宽度锚(近端 ≈ 武器宽)。
  • "有结构"的最好来源是形态参考图:从一张已跑通的成品图里裁出特效局部当 <Picture N>(本项目道具纹样的继承就是这么做的),再配一句 形态与质感按<Picture N>。比纯文字堆形容词稳得多。
  • 仍渲染成纯色光带时:把"束状锯齿电弧 / 冰晶片层 / 尖棱碎片"三样在正文里各写死一遍,或把该参考图提到参考列表第一位。

特殊标记 (Special Tokens · MiniMax Extra Tokens)

已发布的 MiniMax-H3 分词器(基于 Qwen)保留了这些固定的特殊标记。其 ID 由发布的分词器冻结——不要重新编号、改写或拼写错误。包裹对白、歌词、字幕或标记截断时逐字使用。

标记ID用途
<d> / </d>151669 / 151670对白定界符。将对白包为 <d>[Language] ... </d>(铁律——见输出规则)。
`<lyrics_start>/<
`<caption_start>/<
`<cutoff>`

规则:

  • 在对白 / 歌词 / 字幕标记内部,只放逐字的原始内容(对 <d> 与歌词加 [Language] 标签)。不要翻译、改写或追加翻译。
  • 说话人身份、动作与语气放在标记之外。
  • 这些标记被分词器当作字面标记消费;拼写错误(如 <lyrics_start> 少了 |)会破坏解析。

提升效果的技巧 (Tips for Better Results)

  • 始终让描述总时长匹配请求视频长度(4–15 秒)。
  • 保持参考标签一致(<Picture 1>、<Video 1>、<Audio 1>)贯穿每一段。
  • 偏好具体的视觉与音频细节,而非 "cinematic"、"beautiful" 这类抽象词。
  • 使用关键帧(I2VA / FL2VA / L2VA)时,清楚说明首帧和/或末帧如何与时间线连接。

官方口径参考

官方规范之外,官方 skill 的使用说明正文(工作流 / 基础模式 / 全参考 / 音频时间线 / 输出规则 / 特殊标记 / 技巧 / 参考索引,共 8 章)已归档为两份参考文件:

文件内容
references/official-guide-cn.md官方 8 章的中文对照版
references/official-guide-en.md官方 8 章的英文原文

官方规范原文是 references/base-en.txt(基础模式)/ ref-en.txt(全参考模式),与本文件同目录。 用途:核对官方口径、或需要纯净结构时查阅——写提示词仍以本文判据为准。

Bundled files

The model reads these on demand while the skill is loaded. They are exposed as readable files and are never executed.

Frequently asked questions

What does the H3 Video Prompt Cn AI skill do?

为 T2VA / I2VA / FL2VA / L2VA / Ref2VA 编写 MiniMax H3 视频生成提示词(中文产出版 · 默认中文)。当需要将多模态需求改写为 H3 提示词结构、撰写 integrated_multimodal_description / overall_soundscape / non_diegetic_music、对齐关键帧、或为图像/视频/音频定义参考标签时使用。产出语言默认中文——描述内容(动作/场景/光影/声音)用中文书写,字段名、标签、占位符保持英文;仅当用户明确要求英文时才走英文产出。

Why use H3 Video Prompt Cn on TypingMind?

Because you install it once and use it with any model. H3 Video Prompt Cn is plain Markdown rather than provider-specific code, so the same skill runs on GPT-5, Claude, Gemini, Grok, or a local model — and you can switch model mid-chat without it breaking. TypingMind runs on your own API keys, so you pay providers directly instead of a per-seat subscription, and your skills and chats stay in your own storage.

How do I install H3 Video Prompt Cn in TypingMind?

Open Plugins → Skills → Install from GitHub in TypingMind and paste https://github.com/swan7-py/MiniMax-H3-Skills-Local/tree/main/h3-video-prompt-cn. TypingMind reads its SKILL.md and bundles its files and installs it as a skill you can enable per chat.

Which AI models can use H3 Video Prompt Cn?

Any model you connect in TypingMind. AI skills are plain Markdown instructions rather than provider-specific code, so GPT, Claude, Gemini, Grok, and local models can all load this skill when a request matches it.

How many AI models can I use with H3 Video Prompt Cn?

As many as you like. As long as a model supports skills, you can use H3 Video Prompt Cn with it — GPT, Claude, Gemini, Grok, DeepSeek, Mistral, Llama and more — all on TypingMind with your own API keys.

Is the H3 Video Prompt Cn AI skill free?

It is published on GitHub by swan7-py. Check the repository for licensing terms. You only pay your own AI provider for the tokens you use.

What are AI skills?

An AI skill is a reusable instruction bundle that teaches an AI model how to do one specific task. It follows the open Agent Skills format: a SKILL.md file with a name and description, plus any scripts, templates or reference files the model may need. The model reads the instructions only when your request matches the skill, so an installed skill costs nothing until it is used.

How are AI skills different from plugins or MCP servers?

A plugin or MCP server gives a model new tools to call — code that runs somewhere and returns a result. An AI skill gives the model knowledge and process instead: how to approach a task, which steps to follow, what good output looks like. Skills are plain Markdown, so they need no server, no API key and no runtime, and they work with any model.

View all

Set up your own AI workspace now

Get notified about new features and future giveaways by subscribing to our newsletter 👇