Runway Gen-4 實戰：用參考圖加動作 prompt 做出可控影片，再讓 coding agent 幫你批次跑

瀏覽次數: 3

本文大綱

為什麼 coding agent 讀者要看 AI 影片模型

你可能不做影片，但很常需要：產品 demo 的動態封面、README 的示意動畫、發布文的 B-roll。這類需求量小、要求「角色與畫面風格前後一致」，卻不值得請人剪。Runway 的 Gen-4 就是針對「一致性」這個痛點設計的。

這篇不談產業趨勢，只回答三件事：Gen-4 官方到底宣稱什麼、怎麼寫 prompt 才可控、怎麼叫 Claude Code 之類的 coding agent 幫你批次呼叫 API。最後會講哪些事它做不到，省得你白花 credits。

誠實聲明：本文沒有實際跑過 Runway 的付費額度，所有能力描述來自 Runway 官方介紹頁與開發者文件，prompt 範例是依官方「先簡單、再迭代」的原則改寫，需要你自己實測微調。

Gen-4 要解決什麼問題

早期的影片生成模型有個通病：同一個角色，換個鏡頭就變成另一個人；同一個場景，換個角度就換了裝潢。想做連續的敘事，這是致命傷。

Runway 在 Gen-4 官方介紹頁（Runway Research）的說法是，模型可以只靠「一張參考圖」加文字指令，在不同光線、地點與處理方式下，產出角色一致的影片，而且不需要額外的微調或訓練（原文：without the need for fine-tuning or additional training）。同一頁列出的能力包括：

一致的角色：單張參考圖即可跨場景保持。
一致的物件：把任何物件放進任何地點與條件。
一致的場景：維持世界的風格、氛圍與攝影語言。
Coverage：給參考圖與構圖描述，產出同一場景的不同角度。
物理與動態：官方稱之為在模擬真實世界物理上的重要里程碑，並強調 prompt 遵循度與「world understanding」。

這些都是官方自述，不是第三方評測。官方介紹頁沒有給出時長、解析度或失敗率，所以後面講規格時，我會標明來源。

運作原理：參考圖當錨點，文字只管動作

理解 Gen-4 的使用邏輯，只需要抓住一件事：圖片負責「長什麼樣」，文字負責「怎麼動」。

在 image-to-video 模式下，輸入圖等於影片的第一個畫面，視覺內容（人物、服裝、光線、構圖）已經被定下來。所以 Runway 說明文件的建議是，prompt 幾乎只描述你要的運動。這點從搜尋到的官方 help center 指南摘要中可以確認：以「the subject」或「she」這類簡單稱呼指代主體，例如「The subject turns slowly」，而不是重新描述一次外觀。

為什麼這樣設計？因為你重新描述外觀，等於跟圖片搶話語權。圖說她穿紅外套、文字卻寫藍外套，模型只能在兩者之間妥協，結果往往是飄移與閃爍。

實作招式一：從最小 prompt 開始

官方建議是先寫只含最核心動作的 prompt，再逐步加細節。可以照這個節奏：

第一版：The subject walks toward the camera.
滿意動作後，加鏡頭：The subject walks toward the camera. Slow dolly back, handheld feel.
再加環境動態：Dust drifts in the light behind them.

每次只加一個變數。一次加三個，你就不知道是哪個詞讓畫面壞掉。

實作招式二：把外觀鎖在圖裡，不要鎖在字裡

參考圖的品質決定上限。檢查清單：

主體清楚、無遮擋、光線不要過暗。
構圖給動作留空間，例如人往右走，右邊就別貼邊。
想要多角度（coverage），先用 Runway 的圖像模型（API 的 gen4_image 可吃參考圖）產出不同角度的靜態圖，挑好的再各自轉成影片。這比直接要影片換角度穩定。

實作招式三：壞掉時的診斷順序

動作怪：縮短 prompt，只留一個動詞。
臉或衣服飄：換一張更清晰的參考圖，而不是加長文字描述。
鏡頭亂晃：明確寫一種鏡頭運動，不要同時寫 pan、zoom 和 handheld。

讓 coding agent 幫你批次跑

手動點網頁介面很快就會煩。Runway 提供開發者 API 與官方 SDK（Node 與 Python），這正是 coding agent 擅長的活：寫腳本、讀圖資料夾、批次送任務、輪詢結果、下載檔案。

可以直接把下面這段貼給 Claude Code：

請用 Runway 官方 Python SDK 寫一支 gen_clips.py：
1. 讀 ./refs/ 底下所有 png，每張圖搭配 prompts.json 裡同檔名的動作 prompt。
2. 對每張圖建立 image-to-video 任務，先用較便宜的模型與 5 秒長度。
3. 輪詢任務狀態，成功就下載 mp4 到 ./out/，失敗就把錯誤寫進 errors.log。
4. API key 從環境變數 RUNWAYML_API_SECRET 讀，不要寫死。
5. 開跑前先印出預估花費並等我輸入 y。
動手前先去讀官方文件確認參數名稱，不要憑記憶寫。

最後一句很關鍵：模型名稱、參數與支援比例這類細節常常更新，要求 agent 先讀官方文件（docs.dev.runwayml.com）再寫，比相信我文章裡的任何數字都可靠。

預估花費這一步不能省

第三方整理的資訊指出，API 文件列出 Gen-4 Turbo 為每秒 5 credits，API 端 1 credit 約 0.01 美元，也就是每秒約 0.05 美元；輸出為 5 或 10 秒、720p、24fps。這些是我從第三方彙整看到的，我沒有在官方頁面直接核對到同一組數字，請以你帳號的定價頁為準。

另外要注意，我查到的官方開發者模型頁現在已列出 Gen-4.5、Aleph 2.0 等較新的模型，也提到 ProRes、PNG 序列等專業輸出格式。也就是說「Gen-4」已不是最新一代，實際開工前先看目前模型清單，選你要的那一代。

批次腳本請加兩道保險：

上限：單次執行最多送 N 個任務。
乾跑模式：只印出會送什麼，不真的呼叫。

數據與限制：它做不到什麼

官方介紹頁的敘述都是能力宣稱，沒有公開量化的一致性指標，我也沒查到獨立的第三方基準。所以「一致」到什麼程度，只能靠你自己用你的素材測。以下是從使用邏輯推得、值得實測的限制點：

短片段：API 規格看起來是 5 到 10 秒，長敘事要自己剪接。「long-form narrative」是官方列出的應用方向，但實際上是多個短片段拼起來。
一致性不是百分百：只靠單張圖，側臉、背面、遠景這些圖裡沒有的資訊，模型要自己猜。
文字與細小物件：這類內容在影片模型上通常最容易變形，值得你先用小成本測。
成本隨迭代放大：好結果常常要多次重抽，預算要乘上重抽次數。
版權與肖像：用真人照片或品牌素材前，先確認你有授權。