MiniMax 海螺圖片生片實戰技巧：70/30 提示詞法則與運動控制

為什麼寫實短劇創作看重 MiniMax H3

本文由 Say Action 團隊撰寫。推薦與分析基於短劇制作中的工作流銜接與實操經驗，不代表獨立第三方基準測試。

在快節奏的豎屏短劇制作周期中，AI 影片生成經常遇到一個關鍵痛點：人物在對白中的微表情僵硬、面部塑料感重以及動作失真。MiniMax H3（即海螺 AI）在短劇創作者圈子中備受青睐，主要得益於其出色的面部微表情還原度、布料物理褶皱質感以及光影層次的一致性。人物眨眼、呼吸起伏、眼神流轉等細腻情緒，能夠自然融入鏡頭，避免傳統模型常見的“融臉”或“假面”雜質。

這種表現力讓 MiniMax H3 在逐鏡制作中與可靈（Kling）或 Seedance 形成明確分工。可靈更擅長複雜的肢體大幅度打斗與大纵深運鏡調度，Seedance 擅長多圖參考綁定與長鏡頭跟蹤，而 MiniMax H3 則在近景、特寫以及細腻情感對白鏡頭中表現尤為穩定。當輸入一張構圖清晰、光影高質感的高清起始幀時，其擴散引擎能充分尊重原有畫面的皮膚紋理與服裝質感，不會出現盲目的風格漂移。

在 Say Action 畫布中，成熟創作者通常採用模块化的節點連接工作流。劇組無需指望一條提示詞一鍵憑空生成整段戲，而是先在分鏡行中調用圖像模型（如 Nano Banana）生成高精度的靜幀關鍵幀，核準人物造型與機位角度後，將該圖像節點連入 MiniMax H3 影片生成節點。這種將靜態美術確立與動態物理演進解耦的做法，是短劇工業化交付的坚實基礎。

圖片生片的 70/30 提示詞法則

圖片生片中最常見的操作失誤是提示詞重複堆砌。新手往往在影片提示詞框中把人物衣服、房間裝潢、環境色調重新詳細寫一遍。當模型試圖把文字指令與輸入圖的既有像素逐一強行匹配時，反而會在擴散潛空間中產生計算衝突，導致人物肢體畸變、背景解體或服裝瞬間變色；而若只輸入笼統的動作詞，又極易引發非預期的機位晃動。

作為推薦的經驗法則，70/30 提示詞法則正是為了緩解這一衝突而建立的實用編寫結構。整段提示詞中，建議將約 70% 的篇幅與註意力用於錨定輸入圖的靜態特徵——明確承接已有角色的服裝輪廓、主光源方向與背景影調；剩餘約 30% 則用於限定動態運動包絡——精準描述演員的肢體微動作、視線方向以及攝影機運動限制。在這一建議下，避免在圖片生片提示詞中憑空新增未建置的新道具或突兀轉場。

對比兩組實操提示詞的差異即可直觀看出效果。粗糙的文學化寫法：“唯美電影感4k，穿綠色長裙的美女在雨中哭泣，鏡頭旋轉推近”，極易產生五官融化與構圖失控。遵循 70/30 法則的提示詞寫法為：“繼承首幀畫面：身穿祖母綠丝绸衬衫的年輕女性，側逆光輪廓，淺景深。動態指令：左眼眶緩緩滑落一滴泪水，微微咽口水，視線低垂看向手中的手機屏幕；固定機位中近景，攝影機保持鎖定靜止。”這種寫法為擴散模型設定了極度清晰的時空幾何邊界。

在撰寫涉及運動描述的提示詞時，專業短劇創作者應優先選用具體的物理微動作動詞，而非抽象情緒形容詞。輸入“愤怒”、“絕望”往往導致模型生成夸張扭曲的怪異鬼臉；而使用“微咬後槽牙”、“胸口深呼吸一次”、“頭部向右微側 5 度”等具體動詞，則能讓模型沿着明確的物理軌跡推演運動。在 9:16 豎屏短劇中，正是這些克制的微動作維持着人物表演的真實感。

關鍵底層規則：API 首尾幀與參考圖不可混用

在 Say Action 畫布底層，MiniMax 渠道適配器嚴格執行官方接口約束。創作者最常遇到的報錯之一，便是在啟用了首尾幀模式的同時還試圖塞入角色參考圖。在 MiniMax 官方影片生成接口實現中（對應 video-provider-minimax.ts），一旦檢測到首幀（first_frame）或尾幀（last_frame）模式生效，若同時傳入常規參考圖（reference_image），系統將立即拦截並抛出錯誤（minimaxMixedFrames）。

這一約束背後有着嚴谨的擴散模型數學原理。當影片模型執行首尾幀生成式插值時，起始圖和終止圖已經構成了整個時空去噪過程的確定性邊界條件（Dirichlet 邊界）。此時若強行註入浮動的多角度參考圖，潛空間將接收到互相矛盾的特徵向量，導致中間過渡幀產生嚴重的人物特徵均化畸變與面部融化。

因此，在 Say Action 畫布中規划短劇鏡頭時，團隊必須在兩個清晰的模式之間二選一。模式 A 為“單起始幀圖片生片”：僅向 First Frame 插槽輸入一張基準關鍵幀，完全依赖純運動提示詞引導動作延展；模式 B 為“首尾幀生成式鏡頭過渡”：分別輸入起始關鍵幀與終止關鍵幀，由模型推演兩張構圖之間的物理過渡軌跡。在任何一種模式下，都不要把額外的角色設定表強行連入當前影片節點。

保持畫布節點連線的干净規範，可以杜絕批量排隊出片時的意外報錯。在分鏡表中批量提交生成任務前，創作者可在檢查面板中核對連線狀態。一旦發現某個影片節點既連了尾幀又連了人物角色庫節點，應立即斷開多餘連線。尊重底層的接口規則，是保證短劇工業化流水線平穩運行的前提。

用高清關鍵幀錨定主體防止面部崩壞

在圖片生片的生產鏈條中，生成影片的時間連續性上限嚴格受制於輸入圖的清晰度與穩定性。如果輸入的起始幀本身帶有運動模糊、噪點雜質或面部五官輪廓不清，MiniMax 擴散模型在生成前 20 幀時就會迅速放大這些瑕疵，導致演員面部逐漸扭曲、融解。要在連續多集短劇中保持角色特徵不崩，必須在動態生成前把靜態錨點做到極致。

在 Say Action 畫布內，標準做法是先使用 Nano Banana 或 FLUX 圖像節點生成高質量靜幀，仔細核對人物眼神視線、服裝紋理以及背景景深是否達到交付標準。切勿直接使用低碼率影片截圖或未精修的草稿墊圖充當首幀。一張邊缘锐利、光影分明的高分辨率肖像圖，能為影片擴散網絡提供無歧義的空間幾何先驗。

偶發的非預期攝影機漂移，也是破壞短劇鏡頭質感的常見元凶。MiniMax H3 對環境描寫詞十分敏感；如果在提示詞中寫了“狂風吹拂大树”或“波涛汹湧的海浪”，模型很容易誤判需要伴隨晃動的機位推拉。為了在對白戲中徹底鎖死機位，必須在提示詞最前端寫入明確的控鏡指令，例如 static locked-off medium close-up（固定機位中近景）、tripod mount（三腳架固定）或 camera holds stationary position（攝影機保持靜止）。

最後，創作者應在畫布中落實嚴格的人工質檢（QC）節點。當一批影片節點渲染完成後，優先审閱前半秒的動態預覽，確認人物面部對稱性與視線方向是否符合分鏡表要求。若發現某鏡頭存在輕微變形，只需在該節點上微調動作幅度提示詞或替換起始幀單獨重拍，無需重跑整段分鏡，將積分消耗精準控制在單鏡粒度。

分辨率、時長取舍與積分核算

在商業化豎屏短劇制作中，合理平衡算力成本與排期交付至關重要。Say Action 中的 MiniMax H3 適配器提供了 768P（快速預演與試拍）與 2K（成片交付）兩檔標準分辨率選項，單鏡頭支援 4 至 15 秒離散時長調節。根據分鏡表的不同情緒強度為各鏡頭分配合適的生成規格，既能保障成片質量，又能大幅節約制作積分。

下表展示了 Say Action 畫布中 MiniMax H3 的官方公開參數、物理穩定性評估與推薦的使用階段配置。

在 Say Action 中，提交生成任務前系統會清晰顯示預估消耗積分，計費公開透明。當上游模型服務明確返回失敗或發生終端網絡超時，平臺會自動退回預留積分（上游明確返回失敗時會退回預留積分；網絡狀態不明確的任務先保留待核對狀態，避免重複結算。）。對於選擇自帶 API Key（BYOK）的創作者，上游模型費用直接由用戶向 MiniMax 供應商結算，平臺不加收模型標記費用（BYOK 支援配置自有 API 地址、模型密鑰和自定義 Header。使用 OneAPI、NewAPI 等中轉站時，需要選擇與其實際接口匹配的 OpenAI、Gemini 或 Claude 協議，並核對模型 ID 及圖像、影片接口支援情况；不是所有中轉站和私有協議都能直接使用。BYOK 模型調用不加收平臺模型費用、不扣平臺生成積分，但工作空間服務和上游模型費用仍分別收取。），工作空間訂閱服務費獨立計算。

針對 60 到 90 秒的單集短劇，行業公認最高效的制作策略是“兩階段出片法”。第一階段：將分鏡表全部 10 至 14 個鏡頭統一設為 768P、5 秒時長進行首輪批量生成，快速導入剪輯軟件排軸合板；第二階段：鎖定最終剪輯點後，僅將其中 3 至 4 個核心情感爆發或特寫鏡頭切換至 2K 重新渲染替換。這一策略既保證了預算的高效利用，又確保了核心高光鏡頭的影視級畫質。

MiniMax 官方 API 接口參數核實於 2026-10-11；平臺積分預估與扣減以生成弹窗為準，任務失敗自動返還積分。

連接自帶模型與第三方中轉站

喺模型渠道設定填寫 Base URL 同 API Key，按供應商文件設定協議、模型 ID 同所需 Header。先確認文字生圖、圖片轉影片等功能，再開始生成；接口路徑、解像度同首尾幀參數以實際渠道為準。未支援嘅渠道可提交適配申請，申請唔代表已相容。

BYOK 支援自訂 API 地址、模型金鑰同 Header。使用 OneAPI、NewAPI 等中轉站時，要揀與實際接口相符嘅 OpenAI、Gemini 或 Claude 協議，並核對模型 ID 同圖片、影片接口；唔係所有中轉站或私有協議都可直接使用。BYOK 模型調用唔加收平台模型費用，亦唔扣平台生成積分；工作空間服務同供應商模型費用仍分開收取。

只連接你信任嘅渠道，正式環境使用 HTTPS。自訂請求會經已登入嘅後端轉發；所需提示詞、參考素材同憑證會參與請求。唔好將 API Key、密碼或含金鑰嘅 Header 放入公開畫布、截圖或客服申請。