Gemini Omni 是 Google 推出的影片生成與編輯模型，完整名稱是 Gemini Omni Flash，模型 ID 維持 gemini-omni-flash-preview，到目前為止仍然是預覽狀態。它跟一般影片模型最大的不同，是把「做影片」變成一場對話：你先生一支，再用自然語言一輪一輪改，模型記得前面每一輪的狀態，你不必每次都從空白重新生一支。本篇要教的，就是從拿到存取、下第一個 prompt、一路改到下載成品的完整流程，順便把會讓你撲空或花錯錢的硬邊界先講清楚。
先把會直接影響你能不能照著做的重點列出來：Omni 只在付費層提供、沒有免費層；輸出固定 720p、24 FPS、長度 3 到 10 秒，沒有 1080p 或 4K 可選；存取要走 Interactions API，不是你習慣的 generateContent，怕寫程式的人可以先在 Google AI Studio 裡試用；prompt 以英文為主，官方對英文以外的語言只標「未經評估」，中文不是不能用但別假設穩定；某些地區不能編輯含未成年人的圖片，也不能編輯你自己上傳的影片。規格、價格、區域可用性在預覽階段都可能調整，正式接入前回官方文件再確認一次，不要把這份教學當成不會過期的規格表。
重點先看：Omni 的價值在「反覆改同一支影片」，不在「一次生一支最漂亮的成片」。判斷要不要學它的第一個問題是：你的工作是生成後還要反覆改，還是生一次就要到位。前者 Omni 是為你設計的；後者你會更適合 Veo，後面會把分工講清楚。
文章目錄
Gemini Omni Flash 是什麼
Gemini Omni Flash 是 Google 目前還在預覽階段的影片生成與編輯模型，模型 ID 是 gemini-omni-flash-preview。官方在 Gemini Omni Flash 技術文件 裡給它的定義是「為高速影片生成、編輯與電影級控制而生」的高效能多模態模型，能吃文字、圖片或影片當輸入，輸出 3 到 10 秒、720p、24 FPS 的影片，生成之後還能用自然語言對話反覆修改，這是它跟其他影片模型拉開差距的地方。換句話說，它不是你平常聊天問答的那個 Gemini，而是 Google 生成式媒體陣容裡專門做影片的一員。
同一條生成式媒體線上，跟它並列的是 Veo、Lyria、Imagen 和 Nano Banana，各自做影片、音樂、圖片，Omni Flash 負責的是「可以對話修改」這一塊。它在官方 models 頁面被歸在 Gemini 3 的 Preview 分類下，當成 Gemini 3 這一代的影片模型來理解沒問題；但它的名字裡沒有「3」，Google 專屬頁面也沒有「Gemini 3 世代」這個官方說法，所以這個世代標籤是方便理解的講法，不是 Google 的正式命名。
為什麼它跟一般影片模型不一樣：對話式編輯才是主角
多數影片模型做的是單次生成：你給一段 prompt，它吐一支影片，不滿意就改 prompt 重來，每次重來都從零開始，前一支的成果完全作廢。Omni 走的是另一條路。它透過一個叫 Interactions API 的介面，讓你把影片生成跟後續修改變成一段對話，第一輪生一支，接著用自然語言告訴它「把背景改成黃昏」「第三秒鏡頭拉近」，它套用這些修改、同時盡量保留你沒提到要動的部分。模型靠一個叫 previous_interaction_id 的欄位，記得前面幾輪的脈絡跟影片狀態，你不用每次重新上傳前一支，也不用每次把全部需求重新描述一遍。
說穿了就一件事：Omni 的模型設計是衝著「反覆把一支影片調到很接近心裡那個樣子」這個工作來的，不是「一次得到一支漂亮的成片」。這個定位決定了整個教學的節奏，你會花最多心力在「怎麼下 edit 指令」「怎麼用 timecode 精準控制」「怎麼讓它保留沒提到要改的部分」，而不是在「怎麼擠出一段完美的開場 prompt」。
支撐這條工作流程的，還有兩個底層能力。一是原生多模態：Omni 一次吃進文字、圖片、音訊、影片，輸出也跨這些形態一起處理，畫面裡的主體、動作、聲音是綁在一起理解的，所以你改一個環節時另一個環節不會跟著走鐘，這是疊代穩定性的基礎；實際產出的差別是，主體的長相在動作中較能保持一致，並生成搭配畫面的音訊，而不是換個鏡頭就變了一張臉。二是它結合了物理理解與 Gemini 對歷史、科學、文化脈絡的知識，生成的畫面起點比較合理，例如要一段「1920 年代的爵士酒吧」，它對那個年代的服裝、燈光、樂器有基本認識，不是憑空捏造。世界知識不等於事實正確，它給的是合理的視覺起點，不是查核過的史料，細節該查證的還是要查證。
這三個能力合起來，解釋了為什麼 Omni 要用一條不一樣的操作路徑：原生多模態讓畫面裡的主體在動作中保持一致、並生成搭配畫面的音訊；對話式編輯讓「第 N 版」變成模型層級的狀態，不是你自己用檔案名稱硬記；世界知識讓起點畫面比較接近合理。但要提醒一個多數介紹文會略過的閱讀方式：能力清單講的是模型設計上做得到，限制清單講的是現在此刻哪些做不穩或不能做，兩者合起來才是真實的可用範圍。只看能力就投入開發，是預覽模型最容易翻車的地方，繞著硬邊界走、而不是撞上去才回頭改設計，會省下大量重工。
在哪裡動手：三個操作介面，外加一條 API
實際動手前先搞清楚一件事：Omni 不只有一個入口。Google 把它放在三個不用寫程式的地方，再留一條給開發者的 API，定位完全不同。AI Studio 是開發者導向的試用介面，Gemini app 是最休閒的聊天入口，Flow 是衝著影片創作來的工具，三者背後跑的是同一個 Omni Flash 模型，差別在介面給你多少控制權、把生成跟修改包成什麼樣子。怕寫程式的人不必只盯著 AI Studio，下面把四條路各自的定位講清楚。
不想寫程式、或還在評估階段，先走 Google AI Studio。 AI Studio 會幫你把 Interactions API 的互動結構兜好，你在網頁裡下 prompt、看結果、再下修改指令，整個對話式流程都能跑，不用安裝任何東西。這是確認這個模型到底符不符合你需求最省成本的方式。建議在接 API 之前，先用 AI Studio 跑完一輪完整工作流程（生成加兩到三輪修改），看實際結果與 token 消耗，再決定要不要寫進正式產製流程。
只想最快生一支、不想碰任何開發者介面，走 Gemini app。 gemini.google.com 本身就有影片模式，把輸入切到影片、用白話描述你想像的畫面，它就用 Omni 生成一支給你。這是最接近平常跟 Gemini 聊天的入口，沒有 API key、沒有 SDK，登入就能用。代價是控制粒度最粗：你在這裡拿到的是一支生成的影片，要再做精細的 timecode 控制或工程級的多輪 edit，這不是最順手的地方，把它當成快速試想法、或生第一版再丟去別處細修的入口就好。
操作節奏大致是這樣（以網頁版為例，介面會調整）：把輸入模式切到影片，會看到一排範本跟「描述影片構想」輸入框，挑範本或直接打一段畫面描述都行；送出後 Omni 在對話裡生出一支影片，不滿意就在同一個對話繼續用白話要求它改（能不能延續前一支的狀態，以你當下在 Gemini app 看到的為準）。這條路計入你的 Google 帳號方案額度，能不能用、能用多少以你當下的訂閱狀態為準。
要做場景、角色、多鏡頭的創作，走 Google Flow。 Flow 是 Google 的 AI 影片創作工具（flow.google.com），它不是聊天入口，而是把製作影片的流程整個包起來的環境：場景、角色、素材庫，還有一個能幫你批次生成的 Agent。依官方說明，Flow 沒有免費層，需要 Google AI Plus、Pro 或 Ultra 訂閱，其中 Pro 以上才完整含最新的 Gemini Omni Flash 模型，Ultra 再給更多點數與實驗模型優先權；實際方案內容與你所在地區的可用性，以Google 的訂閱方案頁為準。
在 Flow 動手的心智模型跟聊天不一樣。先在設定區決定用哪個模型生成（Omni Flash 或 Veo 3.1 系列都選得到），接著在工作區下提示，可以一次要它生多張圖或多段影片、建立能重複用的角色，Agent 會幫你把生成流程跑完；要改就針對同一個場景繼續提要求。這套「在同一個創作脈絡裡反覆改」的邏輯，呼應 Omni 的對話式修改，只是 Flow 用場景跟素材把它包起來，而不是要你自己記 interaction id。本來就在做多鏡頭、需要角色一致的創作者，Flow 是這幾個介面裡最對得上工作節奏的一個。
| 介面 | 適合誰 | 能不能反覆改同一支 | 解析度 | 門檻 | 什麼情況選它 |
|---|---|---|---|---|---|
| Google AI Studio | 開發者、評估階段 | 能，完整 task 與 edit | 720p | 付費層，token 計費 | 要摸完整 API 行為、之後打算接 API |
| Gemini app | 一般使用者、最快試 | 能，但控制較粗 | 720p | 需對應 Google 訂閱方案 | 只想最快生一支、不碰開發者介面 |
| Google Flow | 創作者、多鏡頭專案 | 能，包成場景與角色 | Omni 固定 720p；選 Veo 可到 1080p、4K | 需 AI Plus、Pro 或 Ultra 訂閱 | 要角色一致、多鏡頭，或在 Omni 與 Veo 間切換 |
要接進自家產品或產線，走 Interactions API。 Gemini Omni Flash 不走標準的 generateContent，官方在 Interactions API 總覽 標明這個 API 現已正式推出（舊的 generateContent 現在被標為 legacy，仍完整支援，但新專案建議直接走 Interactions API）。這件事會影響你能不能用熟悉的 SDK 直接呼叫：很多 Gemini SDK 範例都圍繞 generateContent 寫，換到 Omni 的時候呼叫結構要換，不能直接把 model 名稱改掉就上線。
以官方 Python SDK 為例（套件名 google-genai，用 pip install google-genai 安裝），結構是先 from google import genai 建立 client = genai.Client()（API key 透過環境變數帶入），再呼叫 client.interactions.create(model="gemini-omni-flash-preview", input=...)。對應的 REST 端點是 POST https://generativelanguage.googleapis.com/v1beta/interactions，這個端點需要 API key 驗證，用 x-goog-api-key header 或在 URL 加 ?key= 都可以，官方兩種寫法的範例都出現過；請求內容至少帶 model 與 input 兩個欄位。這套結構對接過其他生成式 API 的開發者不陌生，差別在於心智模型要從「單次請求、單次回應」換成「一串有狀態的對談」。每一輪的 interaction id 都要自己存好，斷了就接不回原來的影片脈絡，等於前面幾輪報廢。預覽階段還會遇到速率限制與逾時，重試與斷點續接要事先設計，而不是上線後才補。想看同類 AI 模型 API 整合的基本觀念，可以參考站上的 Claude AI 使用教學，概念是通的。
接 API 還有兩個工程細節要先想好。一是狀態管理：每一輪的 interaction id、對應的 prompt、結果影片的 URI 都要寫進自己的資料庫，把它當成版本控制，斷了才接得回來；團隊協作時，這份紀錄也是成本歸屬與責任釐清的依據。二是輪詢與重試：delivery="uri" 回來的 URI 不是馬上就備好，要輪詢到檔案可下載；遇到速率限制要用指數退避重試，而不是無腦連發，預覽階段的限流比正式版嚴。這兩件沒做好，正式產線會在最忙的時候斷線，而且常常斷在那個你最不希望斷的輪數。
什麼時候從上面任一個介面畢業、改接 API，判斷標準很實際：當你開始要把這個流程跑給團隊或客戶、要批次產出、要把 interaction id 寫進自己的資料庫做版本管理，就該接 API；如果你只是自己評估或偶爾生幾支，留在任一個介面就好，不必為了「看起來專業」而提早扛起狀態管理與重試邏輯的工程成本。
怎麼用它做影片：完整教學主幹
這一段是整篇的重心，照著走可以從零生出一支、再把它改到接近你要的樣子。下面的 task、edit、timecode 是模型層級的共通邏輯，不管你最後在 AI Studio、Gemini app 還是 Flow 動手，背後跑的是同一套，差別只在介面把它包成什麼樣子。先把四種工作模式講清楚，因為「這一輪要模型做什麼」是由 task 參數決定的，選錯 task 會連第一輪都生不出對的東西。
第一次試用前，先準備好這幾樣
實際打開模型之前，把這幾樣先備齊，第一次試用會順很多。一個能登入 Google AI Studio 的帳號，這是直接在網頁介面摸一遍流程的入口；要留意 Omni 沒有免費層，在 AI Studio 試跑一樣會計入付費層計費，是否需要先啟用計費以你帳號當下的狀態為準。一段你已經想清楚的第一個畫面描述，建議先用英文寫好，包含主體、場景、鏡頭、時長四個要素，比現場臨場發想更省 token。一個你願意花的預算上限，因為不管走 AI Studio 還是正式 API、每一輪都計費，心裡有數才不會在疊代到一半時猶豫要不要繼續。如果你的素材是直式，先標註長寬比要設 9:16，這個常被忘記，生完一支橫式的才發現要整支重來。
第一步：搞懂四種 task，各自什麼時候用
同一個 gemini-omni-flash-preview 模型可以做四種工作，靠 task 參數切換：text_to_video、image_to_video、reference_to_video、edit。它們對應不同的輸入組合與情境，選對 task 是後面一切的前提。
兩條路定位 task 的方式不同。走 Google AI Studio 的人，task 對應網頁介面裡選擇工作類型的選項，你在介面上點選要做哪一種（從無到有生成、把圖動起來、用參考圖、或修改上一輪），介面會把對應的請求結構兜好，你不必自己組 request body；實際的選項名稱與位置以你當下看到的介面為準，預覽階段介面仍可能調整。走 API 的人，task 是放在 generation_config.video_config.task 這個位置，不是直接寫在 prompt 或請求最外層。以官方 Omni 文件展示的結構為例，text_to_video 的寫法長這樣：
client.interactions.create(
model="gemini-omni-flash-preview",
input="A cup of black coffee on a wooden table, top-down, steam rising slowly, warm light, 10s.",
generation_config={
"video_config": {
"task": "text_to_video",
}
},
)官方文件也提到，task 沒設的話模型會自己從 prompt 推斷你想做什麼；但預覽階段建議還是明確指定，避免推斷錯了生錯東西。
| task | 輸入 | 什麼情況用 | 什麼情況不要用 |
|---|---|---|---|
text_to_video | 純文字 prompt | 從零開始生第一支，沒有現成參考圖 | 你手上已經有張定妝照或產品照，那用 image_to_video 更準 |
image_to_video | 一張圖 + 文字 | 把靜態產品照、插畫動起來，或指定開頭畫面 | 要多個角色同時入鏡，改用 reference_to_video |
reference_to_video | 多張參考圖 + 文字 | 主體一致性，例如同一隻貓出現在一系列短片 | 參考圖彼此矛盾、或想跨多支既有影片推理（目前不支援） |
edit | 上一輪的狀態或上傳影片 + 修改指令 | 反覆改同一支影片，這是 Omni 的主力 | 你要的是重新生一支截然不同的，那是新一輪 text_to_video |
判斷順序是這樣：第一次生成，有圖用 image_to_video，要多個主體用 reference_to_video，都沒有就 text_to_video；從第二輪開始幾乎都是 edit。
兩個用圖的 task 再補一句。image_to_video 給一張圖加文字，重點是那張圖要是你真的想當主體的圖，因為模型會以它為錨點生成動作；放一張只是「氣氛參考」的圖，結果常常不如直接用文字描述。reference_to_video 給多張參考圖時，用 <IMAGE_REF_1>、<IMAGE_REF_2> 在 prompt 裡標明每張圖扮演什麼角色（例如「主角」「場景道具」），模型才知道要把哪張圖的特徵放在哪裡，不會把兩張圖的特徵糊在一起。
來源：Google AI for Developers，依 CC BY 4.0 使用；本站已調整尺寸、嵌入品牌標誌並壓縮。
第一輪：用 text_to_video 生第一支
第一輪的 prompt 不必追求完美，因為 Omni 的設計邏輯就是讓你改。你要給的是夠具體的「畫面 + 動作 + 氛圍」，而不是一段文學描述。一個可操作的結構是：主體（是什麼、什麼狀態）＋ 場景與光線 ＋ 鏡頭（角度或運鏡）＋ 時間感。例如要一支產品展示短片，可以下：「A cup of black coffee on a wooden table, top-down angle, steam rising slowly, warm soft light, 10 seconds.」
反例也看一下，比較知道界線在哪。一段像「a beautiful coffee video」的 prompt 太空泛，模型會用預設氛圍填空，結果通常跟你心裡想的對不上；一段像「a close-up of steam rising from a single cup of black coffee on pale oak, morning side light, camera locked, 8 seconds, no text」則把主體、材質、光線方向、鏡頭狀態、時長、排除條件都講死，模型能發揮的自由度變小，結果反而更可控。第一輪的重點不是一次命中，是給後面幾輪一個「接近正確、值得繼續改」的起點，所以寧可具體到有點囉嗦，也不要留太多讓模型自己猜的空白。
幾個會影響這一輪結果的設定要知道。長寬比預設 16:9，要做直式短影片設 9:16，這對 Instagram Reels、TikTok、YouTube Shorts 這類豎屏素材是必要的；解析度固定 720p、24 FPS、長度 3 到 10 秒，沒有更高解析度的選項，這是硬邊界不是你 prompt 寫得夠好就能突破。生成結果會回傳一支影片跟一個 interaction id，把這個 id 存好，它是後面每一輪修改的接續鑰匙。
關鍵參數與進階語法
四個會反覆用到的東西：task 決定這輪做什麼；previous_interaction_id 接續上一輪狀態；長寬比 16:9 或 9:16；影片檔超過 4MB 時用 delivery="uri"，API 會回傳一個可輪詢下載的 URI，不會直接把影片塞在回應裡。
還有一個會悄悄抵銷 Omni 價值的參數。官方建議為了加速同步生成，可以設 background=false、store=false、stream=false，但 store=false 會讓這支影片沒辦法在後續輪次用 previous_interaction_id 接著改。你為了快一點，等於把 Omni 最核心的對話式編輯關掉，後面想改也接不回去。要疊代修改，就別設 store=false。
進階提示用兩種語法。一是 timecode，用 [0-3s] 或 After 3 seconds 這類寫法，指定某個修改或動作發生在影片的哪個時間點，對「前半段這樣、後半段那樣」的分時控制非常有用。二是圖片角色標籤：起始畫格用 <FIRST_FRAME>，參考圖用 <IMAGE_REF_N>，讓模型知道哪張圖扮演什麼角色，例如「這是開頭畫面」「這是主體參考」。這兩個語法在 image_to_video、reference_to_video 跟需要精準時間點的 edit 裡最常用到。
第二輪起：用 edit 做對話式修改
這才是 Omni 真正的賣點。第二輪起你帶著上一輪的 interaction id，把 task 設成 edit，用自然語言告訴模型要改什麼。模型會套用這些修改，同時盡量保留你沒提到要動的部分。你不用重新描述整支影片，也不用重新上傳第一版。
下 edit 指令有個關鍵習慣要養成：講清楚要改什麼之餘，明確講清楚不要動什麼。模型對「沒提到的部分盡量保留」是盡力而為，不是保證；當你下的修改牽涉到整體畫面（例如換背景、換時段），相鄰的元素還是有可能被帶動。實務上多寫一句「keep the rest unchanged」「其他不動」會比不寫穩，這也是降低反覆重試成本的小功夫。
prompt 怎麼寫才有效
幾個可操作的建議，都跟「讓模型在預覽階段盡量穩定」有關。
prompt 主體用英文。官方對英文以外的語言標「未經評估」，中文不是不能用，但品質沒保證、結果可能不穩。要做中文市場內容的人，折衷做法是用英文 prompt 生成畫面主體，需要中文出現在畫面裡（字卡、招牌）時，再單獨用一輪 edit 指定文字內容，並預留修正輪數。純中文旁白、純中文敘事的長影片，現階段不建議當成主力產線。
善用 timecode 做分時控制。要「前半段平移、後半段特寫」，寫成 [0-5s] slow pan across the table, [5-10s] push in to the cup 會比一句「先平移再拉近」精準很多。timecode 是 Omni 對「電影級控制」最具體的落實，值得在第一輪就熟練。
負面條件不要找 negative prompt 參數，它不存在。Omni 不支援 system instructions、temperature、top_p、stop sequences、negative prompts 這些控制參數，要排除什麼就直接寫在 prompt 裡，例如 Do not show any text、No dialogue、No camera shake。這是預覽階段的硬限制，不是你找不到設定。
還有一個會直接影響疊代效率的習慣：一輪改一個方向，不要把五個修改塞進同一輪。原因很實際：一次動太多，結果不對時你分不清是哪一個指令出問題，只能整輪重來；一次只動一個方向，出錯時回推成本極低，每一輪的 token 也花得清楚。這聽起來慢，但在需要反覆修改的工作流程裡，反而比一次下重手更省時間、也省 token。
官方標明 Omni 可以在畫面裡生成正確、可讀的文字，這對字幕卡、標題動畫、資訊圖影片相對實用，但仍建議把文字單獨拉一輪 edit 處理，出錯時只改文字那一輪，不必重來整支影片。
多輪工作流程範例（模擬情境，示意）
這個範例是基於官方能力推導的工作樣貌，屬於說明用的模擬情境，不是實際執行結果，目的是讓你看了就知道每一輪要做什麼、interaction id 怎麼接。假設要做一支十秒的咖啡產品短片。
第一輪（text_to_video）： 下「A cup of black coffee on a wooden table, top-down, steam rising slowly, warm light, 10s.」模型生第一版，回傳 interaction id #1。你看了覺得畫面可以，但蒸汽太快、且想要後半段鏡頭緩慢拉近。
第二輪（edit，帶 id #1）： 下「Slow the steam to half its current speed. From 5s, slowly push in to a close-up of the cup. Keep everything else unchanged.」模型套用兩個修改，保留咖啡、木桌、光影。這一輪回傳 id #2。
第三輪（edit，帶 id #2）： 你發現拉近後杯口邊緣有點變形，下「Fix the rim of the cup so it stays symmetrical. Do not change the lighting or the steam.」模型只修杯口。
第四輪（edit，帶 id #3）： 要加品牌字卡，下「[8-10s] add white text ‘Good morning, start with one cup’ in a clean sans-serif font, bottom center.」如果字拼對、位置合理，這支十秒短片就完成；字出了問題，因為是對話式，你只要再下一輪只修字，不用重來整支。
同一個情境換成 image_to_video，也看一下圖片角色標籤怎麼用（示意）。假設你手上有一張定妝好的咖啡杯俯拍照，想用它當開頭：第一輪把那張圖設為起始畫格，prompt 裡用 <FIRST_FRAME> 標記，並寫「Starting from <IMAGE_REF_1> 標，prompt 寫明它扮演什麼角色（例如「場景道具」），模型才知道特徵要放哪裡。
這個範例的重點不在每個 prompt 都完美命中，而在每一輪都是「在前一支的狀態上做修改」，而不是從空白重來。如果你的工作本來就是「收到回饋、改、再收到回饋、再改」這種反覆形態，這個流程會貼近你原本的節奏。疊代到第幾輪該停手，也有個判斷：當一輪改下來的改善已經小於那一輪花掉的 token 與時間，或當你發現自己在改的已經是模型反覆改不穩的細節（例如同一個字卡改了三輪還是歪），就該停，把這支當成這個版本的終點，而不是繼續硬磨。反覆修改型工作流程最怕的不是花錢，是陷在「再改一輪就會完美」的迴圈裡。
新手最容易踩的三個雷
最常踩的幾種雷，根源其實都一樣：對「對話式」這三個字理解不夠。最常見的是忘記存 interaction id，每一輪回傳的 id 是接續下一輪的唯一鑰匙，沒存好等於斷在那一輪，前面累積的「接近正確」全部接不回去；把它跟影片一起寫進你的產製紀錄，是接 API 的基本紀律。另一種是一輪塞太多修改，這個前面提過，核心是出錯時無法回推是哪一句指令出問題。還有人會期待 1080p 成片，但 Omni 的 720p 是硬邊界，需要高解析度要改走 Veo 或事後用放大工具處理，不要假設 prompt 寫得好就能突破。
成品怎麼下載
走 API 的話，影片檔超過 4MB 要記得用 delivery="uri"，回應會給你一個可輪詢下載的 URI，而不是把影片直接塞在回應內容裡；這在接產線時是基本動作，漏了會拿到空回應或逾時。走 AI Studio 的話，網頁介面直接有下載按鈕，不用管 URI 輪詢。下載下來的成品是 .mp4，官方範例與回應的 mime_type 都是 video/mp4，所以接後續剪輯或壓縮流程不會有格式障礙。生成的所有影片都會內嵌 SynthID 浮水印，肉眼看不到但可程式化偵測，用來驗證影片是 AI 生成的，所以你沒辦法把 Omni 的成品假裝成實拍。生成時間在預覽階段沒有穩定的數字，官方只說會依時長、解析度、當下負載變動，沒有給具體秒數；建議你第一次試用時實際計時記下來，作為評估交付節奏的依據，產製流程有硬性交付時間壓力時，也要把這個變動性算進去，或準備替代方案。
計費現實：怎麼算才不會爆預算
錢的部分要講清楚，這是預覽模型，你照著做會直接花到。根據 Gemini API 定價頁，Gemini Omni Flash 只在付費層提供，免費層是 Not available，計費單位是 token 而不是秒。
官方換算基準是：每秒 720p 影片等於 5,792 tokens。定價是輸入每百萬 tokens $1.50（涵蓋文字、圖片、影片、音訊），輸出每百萬 tokens 文字 $9.00、影片 $17.50。換成好懂的單位，標準定價下實效大約每秒 720p 影片 $0.10。但這個數字只算影片輸出的 token，還沒把你每一輪輸入的提示文字、參考圖也算進去，實際每秒成本會再高一點。
關鍵在於「反覆修改」這件事的成本會疊上去。每一輪 edit 都會累積輸入與輸出 token，一個四輪的對話式編輯，花費會明顯超過「一支十秒影片一塊錢」的直覺。要估預算，不能只看每秒單價，要把預計的修改輪數也算進去。比較穩的做法是先用 AI Studio 跑完一次完整工作流程（假設是生成加三輪修改），看實際用掉多少 token，再乘上你預期的產出量。模型在預覽階段，同一個提示跑兩次可能有些許差異，估預算留點緩衝比較實際。
把情境算給你看（示意）：假設你做一支十秒的 720p 影片，純輸出大概是 57,920 tokens（每秒 5,792 乘以十秒），乘上影片輸出每百萬 tokens $17.50，光成片輸出約 $1.01。接著你跑三輪 edit，每一輪除了新的影片輸出 token，還會把前面累積的脈絡當成輸入重新吃進去，輸入按每百萬 tokens $1.50 計。三輪下來，輸入側的累積會比單看成片輸出多出一截，整體花費會明顯超過一塊錢那個直覺數字。這個數字是說明用的推估，不是實際帳單，實際 token 消耗以你跑出來的為準，但它點出一個重點：決定總成本的是修改輪數，不是每秒單價。
要壓低疊代成本，方向跟省 token 是一致的：每一輪只改一個方向、把不要動的部分寫清楚、第一輪就把畫面方向跟長寬比設對避免整支重來。另一個值得養成的習慣是，把「明顯會被推翻的版本」先留在 AI Studio 的網頁介面裡跑，這條路同樣計入付費層，但省掉自己接 API、輪詢 URI 與重試的工程成本，確定方向穩定了再進 API 做細修，這種分段能把反覆試錯的開銷壓在最低那一層。
老實說，定價頁那個 Used to improve our products 欄位，在付費層標示為 No（免費層欄位是 Yes，但 Omni 沒有免費層），也就是你用 Omni 產生的資料不會用於改善 Google 的產品。這對不能外流的商業內容、或客戶有資料使用有限制的專案反而是有利條件；不過資料處理條款仍以你簽約當下 Google 的官方條款為準，不要把這裡的描述當成合約依據。
限制清單：照做會踩到的硬邊界
預覽模型真正貴的地方，通常不是帳單上的每秒單價，而是你照著能力清單設計好流程，上線才發現某個關鍵能力在你的地區、語言或解析度不能用，整個流程得重來。以下限制都對應 Gemini Omni Flash 模型卡，預覽模型的基本前提是：行為可能變動、速率限制比正式版嚴格、今天的行為不代表下週還一樣。
輸出規格。 輸出影片固定 720p、24 FPS、長度 3 到 10 秒，沒有 1080p 或 4K 可選，這是 Omni 跟 Veo 最直接的硬邊界，也是判斷一支影片能不能交件前要先確認的條件。
上傳影片與 context。 可以編輯的上傳影片，長度上限是 10 秒，超過的自拍素材沒辦法整段丟進去改。上下文視窗是 1,048,576 tokens，對話式編輯每一輪都會消耗這個額度，理論上能撐相當長的對話，但實際能維持編輯穩定度的輪數仍要看模型表現，不是這個數字撐滿以前都會一樣穩。
高解析度怎麼辦。 Omni 沒辦法超過 720p，這是硬邊界。如果你需要更高解析度的成片，方向有兩條：要質感的那一段鏡頭，從一開始就用 Veo 生成；已經在 Omni 跑出來的 720p 成品，也可以事後交給放大工具處理，但放大是否會損失畫質要你自己評估，這條路會多一道手續與成本，交付前最好把轉換前後比對一次。
區域限制。 上傳或編輯含未成年人的圖片，在歐洲經濟區、瑞士、英國不支援；上傳或編輯含特定可辨識人物的圖片不支援；編輯你自己上傳的影片，在這三個地區目前也不支援，但編輯模型自己生成的影片是支援的。換句話說，在這些地區你可以拿 Omni 生成的影片繼續改，但不能把自己拍的素材丟進去改。台灣不在這個限制範圍，但如果你服務的客戶、或部署環境在受限制地區，要先把這個條件納入設計，跨國專案最常在收尾階段因為這條翻車。
功能限制。 上傳音訊參考本版不支援；影片參考最長 3 秒，API schema 雖然接受，但模型目前無法正確處理；跨多支影片的參考與推理不支援，多影片提示可能造成效能下降或輸出異常；影片延伸（把影片拉長）與影格間插值不支援；語音編輯不支援；不支援保證吞吐量，高負載時拿到結果的時間不保證；不支援 system instructions、temperature、top_p、stop sequences、negative prompts，負面條件直接寫成 Do not X。
來源限制。 不能用 YouTube 影片當來源，想拿 YouTube 素材來改的需求要找替代來源。
語言限制。 英文完整支援，其他語言標「未經評估」。中文包含繁中不是不能用，但結果可能不穩定、品質沒有保證。實務建議是 prompt 用英文，畫面要出現的中文文字再分開處理，並預期需要多輪修正。
浮水印。 所有生成的影片都內嵌 SynthID 浮水印，肉眼看不到但可程式化偵測。使用場景需要「看起來完全像實拍、不能被偵測出來是 AI 生成」的話，Omni 不符合需求，而且這個限制不會消失，因為它是 Google 主動加的來源驗證機制。
Gemini Omni 跟 Veo 3.1 差在哪：依任務選工具
很多介紹文把 Omni 寫成「Veo 的下一代」或「Veo 的對手」，這是誤讀，兩者在 Google 模型卡上是並列的兄弟，不是前後代。Veo 的定位是電影級單次生成，詳細規格與計費可以在 Veo 技術文件 查到；它按秒計費，標準價格在 720p 與 1080p 都是每秒 $0.40、4K 每秒 $0.60，開 Fast 模式 720p 每秒 $0.10、1080p 每秒 $0.12、4K 每秒 $0.30。Omni 走的是對話式編輯。也就是說，Google 把「生成一支漂亮的成片」跟「反覆改一支影片直到對」拆成了兩個產品。
| 比較面向 | Gemini Omni Flash | Veo 3.1 | 什麼情況選它 |
|---|---|---|---|
| 工作模式 | 對話式疊代編輯 | 單次生成 | 要反覆改選 Omni，要一次到位選 Veo |
| 解析度 | 固定 720p | 可到 1080p、4K | 成片要 1080p 以上只能 Veo |
| 計費 | token 計費，實效約每秒 720p $0.10 | 按秒計費，Fast 720p 每秒 $0.10 | 同價位，但 Omni 疊代會疊 token |
| 狀態延續 | previous_interaction_id 原生支援 | 無，每次重新生成 | 要「同一支的第 N 版」選 Omni |
兩者 720p 每秒大約 $0.10 同價位，但工作流程、解析度上限、計費邏輯都不同。記得 Omni 用解析度的彈性，換來了 Veo 沒有的原生對話式編輯，這不是「同樣解析度下比誰強」。要把成片做到 1080p 以上的人，這一點會直接決定你能不能選 Omni。定位上記得一個原則：Omni 負責反覆改的 720p 短素材，Veo 負責一次到位的高解析度成片，兩者各計費；硬要混用只會疊成本，除非你清楚哪一段要質感、哪一段要彈性。
至於 Omni 跟 Sora、Runway、Pika、Kling 這類單次生成工具的差別，一句話講：它們比的是「一次生一支最好看的」，Omni 比的是「把同一支反覆改到對」。如果你要的是前者，這些工具跟 Veo 都比 Omni 直接；如果你要的是後者，靠 previous_interaction_id 做模型原生狀態延續的，目前同級對手很少。把它們拿來比「誰比較強」其實問錯了問題，該問的是你的任務屬於哪一種。
Gemini Omni 適合誰使用
把上面所有資訊收斂成一個判斷。會從 Omni 現在就拿到明顯價值的，是這幾種情境：你本來就在用 AI 影片生成做內容，而且工作流程是「生成、修改、再修改」的反覆形態，對話式編輯直接對應你的痛點；你做的是需要主題深度、文化正確性的內容，世界知識在這類情境會拉開差距；你的 prompt 習慣用英文，或你的產出語言是英文，語言限制對你影響最小；你的內容可以接受 SynthID 浮水印。
具體一點，現在就值得拿 Omni 試的影片類型大概長這樣：三五秒的產品展示短素材（生一支、再依回饋改細節）、社群直式短影片的實驗版本、需要正確文字的字卡與標題動畫、需要文化或年代氛圍的歷史重現或教育素材。它們共同的特徵是成品短、需要反覆調、可接受 720p，正好對上 Omni 現在的能力邊界；如果你的目標產出是長篇成片、高解析度或純中文旁白，這些條件現在會跟硬邊界打架，先把需求放到別的工具上更實際。
反過來，這幾種情況建議先觀望：你需要一次到位的電影級成片，Veo 更適合而且計費更好預估；你要編輯自己上傳的實拍素材，而且你或你的客戶在受限制的地區；你的主要產出語言是中文，而且沒有資源做多輪修正、也無法接受品質不穩定；你需要保證吞吐量，或需要 system instructions、temperature 這類控制參數，預覽階段的 Omni 都還不支援。
問題不是 Omni 強不強，是你要它做哪一種活。預覽模型的好處是早一步摸到新能力，代價是行為會變、限制會改、速率會卡。如果你的場景落在「現在就該用」那邊，建議先在 AI Studio 試一輪完整工作流程，從生成、對話修改到下載，把第一輪試用當成壓力測試，確認計費跟結果都符合預期，再決定要不要接進正式產線。
常見問題
Gemini Omni 免費嗎？
不免費。官方定價頁標明只在付費層提供，免費層是 Not available，計費用 token，標準定價下實效大約每秒 720p 影片 $0.10。想先在網頁介面試跑可以走 Google AI Studio，但 Omni 沒有免費層，試跑一樣計入付費層計費；正式接 API 同樣都會計費。
中文 prompt 行不行？
官方對英文以外的語言標「未經評估」，中文不是不能用，但品質沒保證、結果可能不穩定。建議 prompt 主體用英文，畫面要出現的中文文字再分開用一輪 edit 處理，並預期需要多輪修正。
Gemini Omni 跟 Veo 差在哪？
兩者是分工不是替代。Veo 3.1 走單次生成、按秒計費，可輸出 1080p 與 4K，適合一次生成一支電影級成片；Gemini Omni Flash 走 Interactions API 的對話式編輯、用 token 計費，輸出固定 720p，適合反覆修改同一支影片。兩者 720p 每秒大約同價位，但工作流程、解析度上限跟計費邏輯都不同。
輸出可以到 1080p 或 4K 嗎？
不行。模型卡載明 Omni 目前的輸出固定在 720p、24 FPS、長度 3 到 10 秒，沒有更高解析度的選項。需要 1080p 以上成片要改用 Veo 3.1，這是兩者最明確的硬邊界。
能編輯我自己上傳的影片嗎？
可以，但有區域限制，而且上傳的影片最長只能 10 秒。在歐洲經濟區、瑞士、英國，目前不支援編輯使用者上傳的影片，但編輯模型自己生成的影片是支援的。台灣不在限制範圍，但跨地區專案要先確認客戶或部署環境的位置。
每一輪修改都要重新上傳前一支影片嗎？
不用。對話式編輯靠 previous_interaction_id 延續狀態，下一輪帶著上一輪的 id，模型就會接著前面的影片脈絡改，不用重新上傳、也不用重新描述整支影片。要留意的是每一輪都會累積輸入與輸出 token，這是成本會疊上去的原因。
支援直式短影片嗎？
支援。長寬比預設是 16:9 橫式，要做成直式可以設 9:16，對 Instagram Reels、TikTok、YouTube Shorts 這類豎屏社群素材是必要的。解析度上限（720p）與時長上限（3 到 10 秒）不因直式而放寬。
實際花費怎麼抓？
以 720p 為例，標準定價實效大約每秒 $0.10（只計影片輸出 token）。但 Omni 是 token 計費、走對話式編輯，每一輪修改都會累積輸入與輸出 token，反覆疊代的成本會疊上去。要估預算不能只看每秒單價，要把預計的修改輪數也算進去，建議先用 AI Studio 跑一次完整流程看實際 token 消耗再推估。
成品是什麼格式、怎麼下載？
成品是 .mp4（官方回應的 mime_type 是 video/mp4）。走 API 時，超過 4MB 的影片要用 delivery="uri"，回應會給你一個可輪詢下載的 URI；走 Google AI Studio 的話，網頁介面直接有下載按鈕。
interaction id 不見了怎麼辦？
interaction id 是接續那支影片對話狀態的唯一鑰匙，一旦遺失就沒辦法還原同一支影片的脈絡，只能開一個新的 interaction 從頭來。習慣上每一輪生成完就把回傳的 id 跟對應的 prompt、結果一起存進自己的紀錄，是接 API 不會斷在半路的基本紀律。
結論：把它放進你的工作流程之前
回到開頭那句定位：Omni 的價值在反覆改同一支影片，不在一次生一支最漂亮的成片。整篇教學走下來，你會發現它的每一個設計，從 Interactions API、previous_interaction_id、timecode、四種 task，到對 edit 的偏重，都是為了「對話式疊代」這個工作形態而存在。你的任務如果是這個形態，現在就值得花時間摸熟；如果不是，Veo 或其他單次生成工具更直接，也更好估成本。
給你三件下週就能動手的事。第一步，在 Google AI Studio 裡用 text_to_video 跑一輪第一版，拿到 interaction id，確認畫面方向符合你的素材用途（橫式或直式）。第二步，接著用 edit 加 timecode 連改兩輪，一輪改動作、一輪改文字或細節，實際感受狀態延續跟 token 累積的速度。第三步，把這次試用的 token 消耗記下來，乘上你預期的月產出量，得到一個有依據的預算區間，再決定要不要接進正式產線。預覽模型規格會變，正式接入後把官方模型卡釘起來定期回頭核對，是避開過期規格最簡單的習慣。
