同一句話餵兩個模型：Seedance 把結構寫進文字，MiniMax 把結構寫進協定

把兩家的官方提示詞文件並排打開，第一印象會騙你。

字節跳動那邊，Seedance 2.0 的提示詞指南是一份四萬多字的文件。基礎公式、進階公式、主體定義語法、分鏡規範、動作寫法、運鏡建議、約束詞模板，最後還附十二個失敗症狀的排錯方法——包括「接點跳幀時，前一段影片剪掉 6 幀、後一段剪掉 1 幀」這種已經算是剪輯教學的東西。

MiniMax 那邊，網址叫 video-prompt 的那頁標題是 H3 Feature Highlights，內容是六個範例的展示牆。

看到這裡的自然結論是：一家有規範，一家沒有。

這個結論是錯的。 MiniMax 也有規範，只是它不住在同一層——它住在 API 裡。而一旦你意識到這件事，兩家的差異就從「誰比較認真寫文件」變成一個更有意思的問題：結構應該長在文字裡，還是長在協定裡？

同一件事，兩種住法

拿最具體的一件事來比：告訴模型「這張圖負責角色，那段影片負責運鏡」。

Seedance 的做法：寫進提示詞文字。

Define the woman wearing a red dress and a straw hat in Image 1 as Subject 1

還有更緊的綁定寫法 <Subject_N>@<Image_N>。而且它要求你之後每次提到她，都要沿用同一個標籤——換一次稱呼，模型就可能當成另一個人。

MiniMax 的做法：寫進 request schema。

"content": [
  { "type": "text",      "text": "..." },
  { "type": "image_url", "image_url": {...}, "role": "reference_image" },
  { "type": "video_url", "video_url": {...}, "role": "reference_video" }
]

role 是一個 enum，只有五個合法值：first_frame、last_frame、reference_image、reference_video、reference_audio。素材的職責由欄位承擔，所以文字裡只要自然指名就好。官方發布文的示範句就是這樣寫的：

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

一句話，零符號。

這個差別不是風格問題，是後果問題。 把 Seedance 提示詞裡的 Subject 1 打成 Subject l，可能不會觸發格式錯誤，卻讓素材指派走樣。MiniMax 的 role 若不是合法 enum 值，則屬於 API 參數錯誤。

協定可以抓一部分格式錯誤；文字指令是否被正確理解，兩家都還得檢查輸出。

第二個反轉：運鏡上，MiniMax 比較嚴格

這條和多數人的直覺相反，我也是讀到 API reference 才發現。

Seedance 的運鏡說明是這樣寫的：

The model has a strong understanding of camera movement terms, so you can directly use standard camera movement terminology, such as "medium shot, close-up, wide shot, slow push-in, smooth lateral tracking, fixed shot."

such as。舉例，不是清單。它沒告訴你總共支援哪些，只說「像這樣的」。（1.0 指南那句 such as Tracking Shot, Pan Left/Right, Truck Left/Right 也是同樣的開放式寫法，兩代一致。）

MiniMax 的 API reference 則直接給你一張封閉表，標題逐字是 Supported 15 camera commands：

[Truck left] [Truck right] [Pan left] [Pan right] [Push in] [Pull out] [Pedestal up] [Pedestal down] [Tilt up] [Tilt down] [Zoom in] [Zoom out] [Shake] [Tracking shot] [Static shot]

還附用法規則：

• 同一個 [] 內多個指令同時生效，例如 [Pan left,Pedestal up]，建議上限 3 個；
• 指令按出現順序執行，例如 "...[Push in], then...[Push out]"；
• 自然語言也行，但explicit commands yield more accurate results。

順帶一提，這兩家在「一鏡幾種運鏡」上的建議剛好相反：Seedance 2.0 說單鏡只給一種，多了會讓畫面不穩；MiniMax 說一個括號內最多三個同時生效。

有一個誠實的邊界要講清楚：那張 15 指令表官方掛的是 MiniMax-Hailuo-2.3、MiniMax-Hailuo-2.3-Fast、MiniMax-Hailuo-02、T2V-01-Director、I2V-01-Director 這些模型，沒有在 H3 的端點重列。H3 指南只寫了小寫的 e.g., [pan], [zoom], [static]。所以能講的是「方括號是 MiniMax 跨世代的家族慣例，完整詞彙表 documented 在 Director／Hailuo 線」，不能講「H3 支援這 15 個」。

但即便如此，「MiniMax 的運鏡指引比較薄」這個印象仍然是錯的。它只是沒放在你會去找的那一頁。

第三個差異：分鏡權，這個是真的不一樣

前兩條是「結構住在哪一層」的問題。這一條是真正的立場分歧。

Seedance 的分鏡專章寫得很直白，還附正反例。反例：

A man runs nervously down the street, and the scene feels very cinematic.

正例：

Shot 1：街巷側拍，男人慢慢起跑，帶著急促的呼吸感。 Shot 2：男人撞翻水果攤，鏡頭快速晃動，給到他驚恐的臉部特寫。 Shot 3：男人翻過矮牆消失，鏡頭緩緩後拉，定格在空蕩的街道。

MiniMax 那邊，同樣的內容會寫成一段 Core story:，然後模型自己決定切幾刀、哪裡切。它的 API 沒有獨立分鏡欄位，但仍有文字欄位可描述鏡頭；範例未逐鏡標記，不等於禁止你寫。

這也呼應了它的產品說明：H3 發布文列預訓練範式時，有一條是 Native multi-shot modeling（原生多鏡頭建模）。多鏡頭是模型內建能力。

差別在官方示範如何分配切鏡工作。 Seedance 教你逐鏡寫；MiniMax 的這組 brief 範例把切點留給模型。

換到 H3，輸入方式也變了

翻舊端點會看到一個 H3 已經沒有的參數：prompt_optimizer。

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

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

H3 的 v2 端點完全沒有這個參數，長度上限放寬到每個 text 7000 字元。主體參考也從獨立的 S2V-01 端點加獨立的 subject_reference[] 欄位，收斂成 content[] 裡的一個 role。

發布文鼓勵使用者 describe their intent directly in natural language。對寫 Prompt 的人來說，文字空間變大，素材也放進同一套結構裡，故事與參考圖可以一起安排。

還有一個不太體面但很重要的差異

Seedance 的文件承認失敗。

它白紙黑字寫「目前無法 100% 避免生成字幕」，然後給三個降低機率的方法，包括「如果業務允許，優先生成橫幅，橫幅出字幕的機率明顯低於直幅，之後再裁成直幅」。它寫雙胞胎問題無法完全避免，還給了一句全局約束句。它寫續接影片會畫質衰減、多次續接會疊加、臉部特別容易出色塊。它寫中文多音字容易念錯，建議用同音常用字代替——例子是把「螭龍山」改寫成「吃龍山」。

本文查閱的 MiniMax 文件沒有同等的生成排錯專章。它有的是 API 錯誤碼——400 參數錯、402 餘額不足、422 敏感內容、429 限流。那些是協定層的失敗，不是生成層的失敗。

換句話說：MiniMax 會很明確地告訴你「這個請求不合法」，但不會告訴你「這個請求合法，可是你會遇到什麼」。

對創作者來說，Seedance 那一頁其實比公式值錢。公式教你怎麼寫，失敗清單告訴你哪裡會撞牆、撞了往哪走。

一張表收掉

維度	Seedance 2.0（字節跳動）	MiniMax H3
結構住在哪	提示詞文字	request schema
素材綁定	<Subject_N>@<Image_N>、define … as …，需預先宣告並全篇沿用	role 欄位，五個 enum 值；文字只要自然指名
打錯了會怎樣	文字中的素材標記錯誤可能不報錯	不合法的 schema 值會報參數錯誤；正文錯字未必
運鏡詞彙	such as …（開放式舉例）	H3 舉例 [pan]、[zoom]、[static]；15 指令表屬 Hailuo／Director 線
單鏡運鏡數	2.0 建議 1 種	H3 未重列；Hailuo／Director 文件建議同一 [] 內 ≤ 3 個
分鏡	你寫（Shot 1 / 2 / 3 專章）	模型內建（Native multi-shot modeling），API 無此欄位
時間	明說精確秒數不穩，勿硬限	duration 是必填整數參數；比例在 i2v 下強制 adaptive，寫在文字裡無效
提示詞會不會被改寫	本文查閱文件未提供 optimizer 開關	legacy 預設 true；H3 未公開此參數，內部是否改寫不能由此判定
約束詞／negative	專章＋模板句	無
失敗排除	12 個症狀，操作級步驟	只有 API 錯誤碼

所以哪一家比較好？

這個問題問錯了。

比較有用的問法是兩個：

一、這支片的執行層決策，我想不想自己下？

「執行層」指切點在哪、每鏡多長、鏡頭怎麼動、哪個角色在哪一鏡用哪張參考圖。Seedance 假設你會下這些決定，所以給你語法和欄位；MiniMax 的這組範例以意圖描述為主，API 則另管素材與生成參數。

• 有非成立不可的敘事順序（先看到手機熄掉、才抬頭、最後車才過去），或要跨鏡維持同一角色同一套服裝——你需要分鏡權。
• 調性驅動的片子（品牌片、氛圍片、電商展示），切點只要好看不突兀——把執行層交出去反而省事。

二、我希望我的錯誤在哪一層被抓到？

這一題比較少人問，但更實際。結構住在協定層，你會在送出前就被擋下來——text 沒填直接 400，首尾幀和參考素材混用直接失敗。文字內部的素材指派或鏡頭要求即使通過請求檢查，也可能在輸出時走樣。

兩種都不是免費的。 協定層嚴格代表你要先讀懂 schema；文字層寬鬆代表你要自己當自己的 linter。

一個實用的收尾

寫提示詞之前，先把腦中那支片分成兩堆：

意圖層——這支片在講什麼、給誰看、什麼調性、多長、聽起來像什麼。 執行層——切幾刀、哪裡切、鏡頭怎麼移、每鏡誰在畫面裡、哪張素材鎖哪個特徵。

意圖層兩家都要。差別在執行層：Seedance 要你連這層一起寫進文字，MiniMax 把一部分收進 schema、一部分收進模型。

然後很現實的一件事是——你的意圖層寫得爛，兩家都救不了你。 公式的價值在於它會逼你把欄位填完；schema 的價值在於它會擋下不合法的請求。但沒有任何一層會提醒你「你沒說清楚自己要什麼」。那個空缺不會報錯，只會被模型安靜地補上。

模型可以幫你決定鏡頭怎麼切。它不能幫你決定你想拍什麼。

延伸閱讀

• MiniMax 這邊怎麼寫：〈MiniMax H3 的提示詞怎麼寫？它的公式不在教學頁，在 API 裡〉
• Seedance 這邊怎麼寫：〈Seedance 2.0 提示詞怎麼寫？從主體、動作到運鏡的實用指南〉

官方資料來源

所有對比主張以兩家可公開閱讀的英文官方文件為準：Seedance 側依 BytePlus 的 Seedance 2.0 系列提示詞指南；MiniMax 側依其 v2／legacy API reference、開發者指南與 H3 發布文。15 運鏡指令的適用模型為 Hailuo／Director 線，官方未在 H3 端點重列，本文未宣稱 H3 支援。 繁體中文用語為本文自行對譯。

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

• Seedance 2.0 series prompt guide（BytePlus，英文）
• Create Video Generation Task（MiniMax v2，H3 端點）
• Create Text-to-Video Generation Task（MiniMax legacy，含 15 運鏡指令表）
• Video Generation（MiniMax 官方指南）
• MiniMax H3: An Open Model Breaking the Boundaries Between Tasks and Modalities（發布文）