Gemini 3.7 影片理解：代理模式指南

01

什麼是 Gemini 3.7 影片理解？

Gemini 3.7 可以在一次請求裡綜合影片、音訊和轉錄資訊。Google 影片理解文件說明，標準處理預設按每秒 1 格進行視覺取樣。它適合穩定畫面，但可能漏掉短暫 UI 狀態或快速動作。

根據 Google 官方發布文章，代理處理會規劃檢查方式、選擇相關時刻，並按問題組合轉錄、音訊、影格率和解析度。它仍基於被選中的證據工作，因此不能保證答案一定正確。

02

代理模式改變了什麼

靜態取樣回答「從一次均勻檢查裡能看出什麼」；代理檢查回答「為了這個問題，下一步該收集什麼證據」。後者可以先在長影片裡縮小區間，再對關鍵位置做更細檢查。

LensWalk 等研究也在探索先規劃「怎麼看影片」的路線。但「代理」不等於自動正確。更可靠的目標是限定問題、明確證據，並規定證據缺失時必須拒答。

03

選擇代理模式還是靜態取樣

應按素材特徵和漏掉事件的代價選擇模式。Google 更推薦代理處理長影片和精準時刻問題；對 5 分鐘以內、重視低延遲的短片，或需要全片可預測影格精度的任務，靜態處理仍有價值。

Inspect image

把這套判斷當作起點，而不是永久規則。用自己的素材同時測試兩種模式，加入短暫視覺事件、純音訊證據和故意無法回答的問題，比較時間戳、無依據陳述、延遲和輸出結構。

04

寫提示詞前先建立輸入契約

可靠請求先定義輸入契約：影片位置、處理模式、具體問題、輸出結構和核驗規則。影片輸入放在文字提示前，在支援的 API 中使用文件規定的 agentic 值，時間統一要求 MM:SS。

{
  "input": [
    {
      "type": "video",
      "uri": "YOUR_VIDEO_URI",
      "processing": "agentic"
    },
    {
      "type": "text",
      "text": "找到第一次結帳失敗。返回 MM:SS 時間戳、可見錯誤文案、之前的使用者操作，以及不確定性。"
    }
  ]
}

下面只是根據 Google 文件簡化的請求結構，不是 TapVid 的實測基準。正式使用前應核對目前模型和 SDK 語法。輸入可來自 File API、Cloud Storage、支援的 YouTube URL，或文件限制內小於 100 MB 的短檔案。

05

用證據契約約束可核驗答案

弱提示詞只要求答案；強提示詞會定義問題、證據管道、帶時間戳的輸出、不確定性規則和禁止推斷的結論。這樣可以把「按鈕仍然不可用」這類觀察，與對使用者意圖的猜測分開。

• 問題：明確要識別的決策或事件。
• 證據管道：轉錄、音訊、螢幕文字、UI 狀態或可見動作。
• 輸出結構：要求時間戳和簡短發現。
• 不確定性：證據不足時必須明說。
• 排除項：明確不能推斷的結論。

Inspect image

每條發現都應包含時間區間、簡短觀察、證據管道、可見或可聽的具體依據和信心程度。如果素材無法建立答案，正確輸出應是「未能建立」並說明缺少什麼，而不是給一個聽起來合理的猜測。

分析這段影片中的 {{決策}}。每條發現返回 MM:SS 區間、簡短觀察、證據管道、具體依據和信心程度。不要推斷影片未支援的事實。證據缺失時返回「未能建立」，並解釋缺少什麼。

06

常見分析任務的可複製提示詞

以下範本是分析提示詞，用來在既有影片中定位證據或為證據分類，並不要求模型生成新畫面或編輯素材。使用時請替換範本中的預留內容，同時保留對時間戳記和不確定性的要求。對於會影響實際決策的重要發現，應回到原始影片逐項複核，確認結論確實有來源支持。

定位產品示範失敗

檢查產品示範中的失敗或未完成步驟。每項返回 MM:SS、之前的操作、確切 UI 證據，以及講解者是否口頭承認。沒有證據時，不要把停頓標成失敗。

從長會議中提取決策

找到改變價格、發布時間、功能範圍或負責人安排的決策。返回 MM:SS、決策內容、負責人、截止日期和口頭依據。把已確認決策與建議、待定問題分開。

按批准步驟審核教學

把教學與 {{檢查清單}} 對照，每項標記為正確、錯誤、未展示或不清楚，並給出 MM:SS 和可見 UI 標籤。只有旁白不能證明螢幕步驟已經發生。

定位短暫物理事件

找到 {{事件}} 第一次在畫面上明確完成的時刻。細查前後區間，返回最早可辯護的 MM:SS、完成線索，以及遮擋、動態模糊或剪輯造成的不確定性。

把事件、證據和拒答條件寫清楚，比加入「深度」「專家級」等形容詞更有效，因為審核者可以判斷輸出是否符合契約。

07

在多輪分析中保留影片脈絡

影片分析經常會連續追問：第一輪定位事件，第二輪找相關例子，第三輪整理已批准發現。只有應用正確保留影片和處理狀態，這種多輪流程才可靠。

Google Interactions API 可以透過上一輪 interaction ID 延續狀態；無狀態實作則要重播相關處理呼叫和結果，不能只重播最後一段文字。應把來源 ID、模式、interaction ID、提示詞版本和輸出結構一起保存。

08

限制與常見失敗模式

代理檢查無法修復本來就不可讀的標籤。Gemini 3.7 Flash 模型卡也把幻覺、速度慢和逾時列為已知限制。正式流程需要重試、逾時、審核狀態，以及處理來源影片的合法權限。

• 捏造細節：強制要求時間戳和不確定性。
• 時間戳接近但不準確：人工覆核邊界敏感結論。
• 微小或短暫 UI：盡量提供更高品質來源檔案。
• 說話人歸屬錯誤：覆核重疊或畫外音。
• 處理慢或逾時：設定重試、逾時和審核狀態。
• 版權與隱私：只處理有權使用的素材。

評估裡必須加入負例：不存在的事件、故意模糊的文字、說話人不明確的音訊，以及影片無法證明的動機。如果系統仍然自信作答，即使正例看起來漂亮，也是不合格。

09

影片理解不等於影片生成

影片理解把既有影片轉換成發現、時間戳記、描述或決策；影片生成則建立新的視覺與音訊內容，影片編輯則改變既有內容。這些任務要求不同：分析提示詞可以要求找出影片中第一次對價格提出異議的時刻；生成提示詞則可以要求把一張產品照片製作成產品發表片段。

Inspect image

如果目標是創作或編輯影片，應使用 Gemini Omni 影片提示詞庫。把它與本指南分開，可以保護真實搜尋意圖：分析結果必須指回來源影片，生成結果則要按素材、批准文案和創意 Brief 覆核。

一個範本不能取代兩種驗收。分析即使沒有生成新影片也可能有價值；生成影片即使很好看，只要改錯標籤或把錯誤素材配給某段文案，也仍然失敗。

10

把核驗後的發現交給解說影片流程

應把分析輸出設計成可控交接：先提取帶時間戳的觀察，讓人確認哪些準確、有用，再把已批准內容寫進腳本，為每段腳本綁定正確素材，最後覆核文案和畫面的對應關係。

TapVid 的正式定位是 Explainer Video Engine。AI 解說影片生成器負責把使用者提供的素材和批准文案做成可覆核影片，但它不會讓上游分析裡的錯誤自動變成事實。人工批准仍是模型輸出和公開內容之間的橋樑。

11

一套實用評估清單

從真實素材裡選一小組測試樣本，用可觀察標準評分。真正合適的模式是能通過你的驗收條件，而不是名字更新的那個。

• 是否定位到正確區間
• 是否標出證據管道
• 螢幕或語音內容是否忠實
• 是否區分「沒展示」和「不是真的」
• 證據不足時是否拒答
• 審核者能否快速覆核
• 多輪之間是否保留影片證據
• 延遲是否符合實際任務

模型或 API 發生變化後要重新評估。把提示詞和預期輸出保存為帶版本的測試範例，才能發現時間戳、拒答、延遲或輸出結構是否改變。

12

常見問題