MiniMax H3 的提示詞怎麼寫？它的公式不在教學頁，在 API 裡

你想學 MiniMax H3 的提示詞，很自然會去官方文件找一頁叫 prompt guide 的東西。

網址確實有：/docs/guides/video-prompt。點進去，標題是 H3 Feature Highlights，內容是六個範例的展示牆——品牌片、視覺創作、短劇、電商、UI 動態、遊戲風格。每則給你一段 prompt、幾張參考圖、一支輸出影片。

沒有公式，沒有欄位表，沒有運鏡術語清單。

到這裡很容易得出一個結論：「MiniMax 沒有提示詞規範，隨便寫就好。」

這個結論是錯的，而且會讓你少用掉一半的控制力。 MiniMax 的規範確實存在，只是它不在 guides，在 API reference。而且有些規則嚴格到會直接覆蓋你在提示詞裡寫的東西。

這篇把三層都拆開：請求結構（真正的公式）、六則範例歸納出的文案形態、以及那 15 個具名運鏡指令。

圖片佔位：〈同一個需求的三層：request 結構、提示詞文案、運鏡指令〉

第一層：真正的公式是 content[]

先看 H3 的請求長什麼樣：

{
  "model": "MiniMax-H3",
  "content": [
    { "type": "text",      "text": "..." },
    { "type": "image_url", "image_url": { "url": "..." }, "role": "reference_image" },
    { "type": "video_url", "video_url": { "url": "..." }, "role": "reference_video" },
    { "type": "audio_url", "audio_url": { "url": "..." }, "role": "reference_audio" }
  ],
  "resolution": "2K",
  "duration": 5,
  "ratio": "adaptive"
}

看到 role 沒有？這就是公式。

role 只有五個值：

role	意思
first_frame	這張圖是第一幀
last_frame	這張圖是最後一幀
reference_image	這張圖是參考素材
reference_video	這段影片是參考素材
reference_audio	這段音訊是參考素材

字節跳動那邊要你在文字裡打出 <Subject_1>@<Image 1>、要你先寫「把影片 1 裡那個高個子定義為警察」，MiniMax 把同一件事做進了欄位。素材的職責由 role 承擔，所以文字裡你只要自然指名「圖片 2 裡的那個人」就好。

官方發布文的示範句正是這樣：

Reference the Hitchcock camera movement from Video 1, have the character in Image 2 sing, with the vocals matching Audio 3.

三份素材、三種用途、一句話，沒有任何符號。因為符號在 JSON 裡。

所以「MiniMax 沒有公式」的正確講法是：它的公式不是文案格式，是請求結構。

三條會咬人的硬規則

這三條寫在 API schema 裡，guides 完全沒提，但踩到就是報錯或靜默失效。

一、text 永遠必填。 就算你只是丟一張首幀圖想讓它動起來，也一定要給文字。少了直接 400：

invalid params, content must include a non-empty text item (prompt is required) (2013)

二、首尾幀和參考素材互斥。 官方原文：

Image-to-video and reference-to-video are mutually exclusive.

意思是——你不能一邊鎖定第一幀、一邊丟角色參考圖。 兩者只能選一邊。如果你的做法是「用參考圖鎖角色，再用首幀圖鎖構圖」，在 H3 上這條路是封死的，得改成先生一張圖、再拿那張圖當首幀。

三、比例在 image-to-video 下由圖片決定，你寫什麼都沒用。 官方原文說 ratio 恆為 adaptive，「傳其他合法值不報錯但被忽略」。

所以你在提示詞開頭寫 16:9，如果這是 image-to-video 任務，那三個字完全是裝飾。反過來，純文字生成時 ratio 必填而且不能是 adaptive。

第二層：提示詞的文案形態，由 role 決定

這裡有個很多人沒注意到的事：H3 的提示詞沒有單一文體。你放了什麼 role，文字就該用什麼語氣。

官方 API 文件給的三則範例，文體完全不同：

純文字生成——寫場景：

Epic space-opera theatrical teaser: a female captain stands alone before a massive observation window as the last fleet gathers and jumps away in a blinding flash, the bridge shaking, leaving her behind.

有首幀圖——寫修改指令：

Pull focus to the people in the background and add more steam to the ramen bowl.

（把焦點拉到背景的人，湯麵再多加點蒸氣。）

看清楚，這句話完全沒有描述畫面裡有什麼。因為畫面已經在圖裡了，你要寫的是「改哪裡」，像給後期的一張便條。

有參考素材——寫台詞與素材指派：

Character speaks: Follow the wind, live free. Leave worries behind, enjoy the moment. Voice timbre follows reference audio 1.

順帶注意最後那句：role 明明已經標成 reference_audio 了，文字裡還是又用序數指了一次「參考音訊 1」。這是官方自己的寫法——schema 負責綁定，文字負責說明你要拿它的哪個面向（這裡是音色，不是內容）。

那六則範例：作品級 brief 的形態

video-prompt 頁那六則屬於第三種情境——完整作品的 brief。把它們排在一起，會浮出一組常見段落。

先講清楚：以下六段是本文從官方範例歸納的，不是官方發布的公式。

段落	在做什麼	官方範例原文
規格	時長和比例	15s, 16:9.
素材分工	每份素材負責什麼	Image 1: mood, setting, film grain. Image 2: character. Image 3: bag. Image 4: ending logo.
核心故事	整段講完，不切鏡	Core story: on a desert highway beside a vintage car, the woman takes a black bag from the trunk, shares a brief quiet moment with the man, then leaves.
調性	這支片給人的感覺	Tone premium and cool
剪輯感	節奏快慢、剪點密度	edit agile and fashion-forward
聲音	要聽到什麼	Sound: kitchen ambience plus the creature's soft electronic hums.

這不是在描述一個畫面，是在交一份 brief。而且它有反例——第六則遊戲範例整段都是第一人稱鏡頭描述，既沒規格前置也沒素材分工。所以六段是常見形態，不是必填欄位。

幾個實務重點：

素材分工要指名。 Image 1: mood, setting, film grain. Image 2: character.——一張一行、一張一個職責。role 告訴模型「這是參考圖」，文字告訴它「參考這張的哪一面」。兩層都要。

核心故事整段講完，不切鏡。 沒有「鏡頭 1」「鏡頭 2」，因為 H3 發布文列架構時有一條 Native multi-shot modeling（原生多鏡頭建模）——多鏡頭是模型內建能力，API 裡也根本沒有分鏡欄位。切點交給它。

調性報一個大家都知道的坐標。 ReelShort / DramaBox feel: dark romance, danger, destiny. 這句很值得抄：它不描述畫面，它報一個品類。一句話省掉五十個形容詞，而且比堆「電影感、夢幻、史詩、超寫實」有效——那四個詞互相打架。

剪輯感是你唯一還握著的節奏控制桿。 你不寫分鏡，但你可以寫「節奏偏慢、切點少」或「緊湊、高衝擊」，模型的切分決定會跟著變。

聲音要寫，因為它本來就會出聲。 H3 的音訊是原生立體聲、和影像一起生成，官方說人聲／音效／音樂三者聯合建模不分離。你不寫，它也給——只是那是它猜的。

第三層：15 個具名運鏡指令

這是整份文件最被埋沒的東西。

MiniMax 的 API reference 裡有一張封閉的運鏡指令表，明文寫著 Supported 15 camera commands：

類型	指令
橫移 Truck	[Truck left]、[Truck right]
搖鏡 Pan	[Pan left]、[Pan right]
推拉 Push	[Push in]、[Pull out]
升降 Pedestal	[Pedestal up]、[Pedestal down]
俯仰 Tilt	[Tilt up]、[Tilt down]
變焦 Zoom	[Zoom in]、[Zoom out]
晃動 Shake	[Shake]
跟拍 Follow	[Tracking shot]
固定 Static	[Static shot]

用法規則也是明文：

• 組合：同一個 [] 內放多個指令會同時生效，例如 [Pan left,Pedestal up]。建議上限 3 個。
• 序列：指令按出現順序執行，例如 "...[Push in], then...[Push out]"。
• 自然語言也可以，但官方直說——explicit commands yield more accurate results（明確指令的結果更準確）。

官方範例 prompt 逐字：

A man picks up a book [Pedestal up], then reads [Static shot].

這比字節跳動那邊還嚴格。 Seedance 的運鏡說明用的是 such as（舉例，非窮舉），而 MiniMax 直接給你一張 15 個的封閉清單，還告訴你怎麼組合、上限幾個。

但這裡有個誠實的邊界，你一定要知道

這張 15 指令表官方是掛在 MiniMax-Hailuo-2.3、MiniMax-Hailuo-2.3-Fast、MiniMax-Hailuo-02、T2V-01-Director、I2V-01-Director 這些模型下的，不是 H3。

H3 的指南只寫了一句：

add camera motion instructions (e.g., [pan], [zoom], [static]) directly after key descriptions to guide the camera work.

小寫、e.g.、三個例子，跟那張 Title Case 的 15 指令表不是同一個寫法。

所以誠實的結論是：方括號運鏡是 MiniMax 跨世代的家族慣例，完整詞彙表寫在 Director／Hailuo 線的端點上；H3 是不是照單全收，官方沒說。 值得試，但別當保證。

一個歷史線索：H3 拿掉了 prompt 優化器

翻舊端點還會看到一個有趣的東西：prompt_optimizer。

Whether to automatically optimize the prompt. Defaults to true. Set to false for more precise control.

預設 true。 也就是說在舊世代模型上，你寫的提示詞預設會先被一個優化器重寫過，除非你主動關掉。舊世代的提示詞長度上限也只有 2000 字元。

H3 的 v2 端點完全沒有這個參數，長度上限則放寬到每個 text 7000 字元。

這條線索把整個產品立場串起來了：MiniMax 從「你隨便寫，我幫你改寫」變成「你直接講清楚，我不動你的話」。發布文那句 describe their intent directly in natural language，配上這個參數的消失，才算完整。

你能用的規格

項目	值
模型名	MiniMax-H3（文件內部代號 Hailuo-03）
端點	POST /v2/video_generation
輸出解析度	2K（目前唯一值，必填）
輸出時長	必填整數，4–15 秒
比例	adaptive／21:9／16:9／4:3／1:1／3:4／9:16
Prompt 長度	每個 text item ≤ 7000 字元
首／尾幀圖	各 ≤ 1 張
參考圖	≤ 9 張，邊長 256–5760 px，比例 0.4–2.5
參考影片	≤ 3 段，每段 2–15 秒且總長 ≤ 15 秒，MP4／MOV
參考音訊	≤ 3 段，WAV／MP3，不可單獨送出
素材來源	public URL／mm_file://{file_id}／Base64 data URI
Request body	≤ 64 MB

mm_file://{file_id} 值得單獨提一句：它可以指向你先前一次生成的輸出。要做接續、要把第一支的最後一幀拿來當第二支的起點，不用先下載再上傳。

還有一個錯誤碼要有心理準備——422：

video description contains sensitive content (1026)

（最後對照日期：2026-08-01。規格會隨版本變動，以官方文件為準。）

一份可以直接改的模板

雨夜車站，參考生成模式（role=reference_image ×2 ＋ reference_audio ×1）：

12s。

圖片 1：主角外觀——深藍雨衣、黑色短髮、提舊皮箱的年輕女人，取她的臉與服裝。圖片 2：老火車站月台，取空間配置與冷暖光比例。音訊 1：取環境音質地，作為全片底噪，不作人物台詞。

核心故事：深夜大雨剛停的月台，主角站在黃線後方等車，聽見列車聲後回頭望向入口 [Pan right]；列車進站時風掀起她的雨衣下襬，她往後退了半步 [Push in]。她沒有上車。

調性：寫實電影感，冷藍為主，鎢絲燈帶少量暖黃反光，低飽和；日本鐵道電影那種安靜的感覺。

剪輯：節奏偏慢，切點少，讓等待的時間感留住。

聲音：雨聲、列車由遠到近的軌道聲、月台廣播模糊人聲；沒有配樂。

注意這份沒有寫比例——因為參考生成模式下 ratio 選填，而且我打算讓它自己判斷。如果改成純文字生成，ratio 就變成必填而且不能寫 adaptive。

送出前的檢查清單

結構層

1. content[] 裡有沒有一個非空的 text？（必填，少了直接 400）
2. 有沒有把 first_frame 和 reference_image 混在一起？（互斥，會失敗）
3. 這是純文字生成嗎？是的話 ratio 必填且不能是 adaptive。
4. 這是首幀圖生成嗎？是的話你寫的比例會被忽略，別浪費字。

文案層

1. 文體對得上 role 嗎？有首幀圖就寫修改指令，不要重新描述整個畫面。
2. 每份素材有沒有說明你要取它的哪一面？
3. 調性有沒有一個明確坐標，而不是四個互相打架的形容詞？
4. 剪輯節奏有沒有交代？沒有的話，切點就完全交給模型了。
5. 聲音要不要管？不管就是接受它自己配。

這種寫法什麼時候會咬你

切點不是你決定的。 如果你的片子有一個非成立不可的敘事順序——先看到手機熄掉、才抬頭、最後列車才過去——模型可能把順序調換，或把三件事壓成一個連續動作。而且你重抽時很難指著說「第二鏡錯了」，因為你根本沒定義第二鏡。

同一個問題在 Seedance 那邊是用 Shot 1 / Shot 2 / Shot 3 解掉的。兩家的取捨完全相反，值得單獨講一篇：見〈同一句話餵兩個模型：Seedance 把結構寫進文字，MiniMax 把結構寫進協定〉。

沒有約束詞這一層。 Seedance 有專章教你怎麼寫「不要字幕、不要 logo、不要浮水印」，甚至有一句全局約束專治「同一個角色被生成兩次」。MiniMax 的文件沒有這一層——你只能在正面描述裡把話講滿，出了問題也沒有官方的排錯清單可查。

最後

「官方沒寫教學」和「官方沒有規範」是兩件事。

MiniMax 的規範散在 API reference 的欄位描述裡——role 的五個值、i2v 與 r2v 的互斥、ratio 在不同模式下的三種行為、15 個具名運鏡指令。這些東西比一份 prompt 公式硬得多，因為它們是會報錯的。

而 guides 那頁六個範例教你的，是另一件事：當結構都交代完之後，剩下那段話要怎麼講。 那段話講不清楚，schema 再嚴謹也救不了你。

官方資料來源

規格、content[] 結構、role 定義與硬約束依 MiniMax v2 API reference；15 運鏡指令依 t2v／i2v 端點的 prompt 欄位描述（適用模型為 Hailuo／Director 線，H3 未重列）；產品立場與架構描述依 H3 發布文。六段結構是本站從官方六則範例歸納的，官方未以公式形式發布。

最後對照日期：2026-08-01。

• Create Video Generation Task（v2，H3 端點，含完整 OpenAPI schema）
• Create Text-to-Video Generation Task（legacy，含 15 運鏡指令表）
• Image-to-Video Task（legacy，含 15 運鏡指令表）
• Video Generation（MiniMax 官方指南）
• H3 Feature Highlights（網址為 video-prompt）
• MiniMax H3: An Open Model Breaking the Boundaries Between Tasks and Modalities（發布文）