剪一支三分鐘的產品宣傳片，以前的流程是這樣的：把幾十段 talking head 素材拖進剪輯軟體，一段一段聽，把講錯重來的部分標起來、把「呃」「那個」這種廢話剪掉，調色、配字幕、卡點。一個下午就沒了，而且還只是初剪。

現在 browser-use 團隊開源的 video-use，做法是你把素材丟進一個資料夾，打開 Claude Code，打一句「把這些剪成一支 launch video」，它自己清點、轉錄、提案、剪接、調色、上字幕，最後吐一支 final.mp4 給你。

聽起來就是「又一個 AI 自動剪片工具」。但這篇我想講的不是它能做什麼——那個你看 demo 就懂了。我想講的是它選擇不做什麼，因為那個選擇才是整件事真正聰明的地方。

一支 30 秒的影片，硬塞給 AI 要花多少錢

先算一筆帳。如果你照直覺做一個「會看影片的 AI 剪輯器」，最自然的想法是：把影片每一幀都丟給 vision model，讓它看懂畫面，再決定怎麼剪。

30 秒的影片，一秒 30 幀，就是 900 幀。每一幀進到 vision model 大概 1500 個 token 上下，900 幀就是約 135 萬個 token。這還只是 30 秒。一支一小時的原始素材這樣硬送，是 4500 萬 token 起跳。

這不只是貴的問題，是整個方法從根上就站不住。你花天文數字的 token，餵給模型的還是一堆它根本不需要逐幀細看的畫面——一個人講話的鏡頭，連續 30 幀幾乎一模一樣，你讓模型看 30 遍同一張臉，是要它領悟什麼。

video-use 的選擇是：不看。

它讀的是一份 12KB 的逐字稿

這裡藏著 browser-use 一脈相承的設計哲學。browser-use 當年做網頁自動化，沒有走「截圖給模型看」這條路，而是把網頁的 DOM 結構抽出來、整理成文字餵給 LLM。畫面是給人看的，結構才是給機器讀的。

video-use 把同一招搬到影片上。它不送畫面，送逐字稿——而且是 word-level、精確到每個字出現在第幾秒的那種逐字稿。一小時的素材打包成這樣一份文字檔，大約只有 12KB。

你把這兩個數字擺在一起看一下：暴力送幀是 4500 萬 token，讀逐字稿是 12KB。後者省掉的不是一點半點，是 99.97% 以上。

而剪片這件事，九成的決策本來就是靠「誰在第幾秒講了什麼」做的。哪句話講得好、哪句重來了、哪裡可以接到下一段——這些資訊全在逐字稿裡，根本不需要看畫面。video-use 抓住的就是這個：剪輯的決策層是文字的，不是視覺的。

那真的需要「看」的時候怎麼辦？比如要判斷一個剪接點接得順不順、兩次重拍哪一條表情比較好、停頓是不是太久。這時候它才會按需生成一張合成圖——把那一段的縮圖膠卷、聲音波形、文字標籤疊在一起的 PNG，只在那個當下、只看那一小段。它管這叫 text-first + on-demand visuals：預設讀文字，需要才看圖。

這就是那種「拆到最基本」的判斷——先問清楚「剪片到底在決策什麼」，答案是文字，那就別為了看起來高級而硬上 vision。

整條流水線，其實是一個會自我檢查的迴圈

把它的運作攤開來看，是一條這樣的鏈：

  1. 清點：用 ffprobe 把資料夾裡所有素材掃一遍，搞清楚有什麼
  2. 轉錄：丟給 ElevenLabs Scribe 批次轉成逐字稿
  3. 對話：讀完逐字稿後反過來問你——你想要什麼風格、什麼結構，確認清楚
  4. 提案：給你一份 4 到 8 句的剪輯策略，等你點頭才動
  5. 執行：產生一張 EDL（剪輯決策表，JSON 格式），平行生成動畫、調色、render
  6. 自我檢查：在每個剪接點跑一次 timeline view，看有沒有畫面跳得太突兀、有沒有 audio pop、字幕有沒有擋到東西
  7. 迭代：有問題就自己改 EDL、重新 render，最多跑 3 輪

第 6 步是我覺得最值得學的地方。大部分自動工具是「跑完直接丟給你」，video-use 是「跑完先自己看一眼」。render 完不是終點，是先在每個 cut boundary 生那張膠卷加波形的合成圖，自己檢查過，有問題自己修。3 輪之內修不好，它才老實告訴你「這裡我搞不定，你來」。

這個「做完先驗收」的習慣，讓它的成品品質比單次 render 穩很多。順帶一提，它還會把整個 session 的狀態寫進一個 project.md，下次打開同一個資料夾自動接續——你昨天剪到一半，今天回來不用重講一遍。

怎麼裝、能拿來剪什麼

它不是一個你 import 的 Python 套件，而是一個掛在 agent 底下的 skill。最省事的裝法是直接在 Claude Code 裡貼一句話，叫它自己讀 install.md 把 repo、ffmpeg、skill 全部接好：

1
2
Set up https://github.com/browser-use/video-use for me.
Read install.md first to install this repo, wire up ffmpeg, register the skill.

裝好之後，用起來就是 cd 進素材資料夾、開 claude、打一句「edit these into a launch video」，剩下交給它。

能剪的東西比想像中雜：產品宣傳片（自動排成 HOOK → PROBLEM → SOLUTION → CTA 的結構）、教學影片（去掉重講的段落，技術概念還能配 Manim 動畫）、訪談（靠 speaker diarization 認出不同講者，自動組 Q&A）、社群短影片（自動轉直式 1080×1920、上 UPPERCASE 粗體字幕、字幕往上抬避開平台 UI）。

該潑的冷水也得潑

有幾個地方得先講清楚，免得你裝完才踩到。

ElevenLabs Scribe 是付費 API，每轉一次就花一次錢——所以官方特別提醒，安裝驗證階段不要手癢跑轉錄測試。它也明確不支援離線 ASR，故意排除了本地 Whisper（理由是慢、而且會把語助詞正規化掉，反而剪不準）。

更根本的限制是：它的決策建立在音訊逐字稿上。所以一段沒人講話的風景空鏡、或一支舞蹈影片，它就抓瞎了——沒有逐字稿，它那套省 token 的聰明全部失效。動畫能力也有天花板，簡單疊加靠 PIL、技術圖靠 Manim、複雜一點靠 Remotion，但別指望它做到 After Effects 等級的特效。還有那個 self-eval，最多 3 輪，超過就放生。

這些限制其實都指向同一件事：video-use 不是萬用剪輯器，它是「會講話的影片」的剪輯器。它的強項和它的盲區，是同一個設計選擇的一體兩面。

回到最開頭那支宣傳片。真正讓你從「盯著時間軸爬一個下午」變成「打一句話」的，不是 AI 突然會看影片了——剛好相反，是有人想通了「剪這種片根本不用看影片」，把一個視覺問題降維成了文字問題。下次你想用 AI 解一個看起來很重的任務，不妨先學它問一句：這件事的決策，到底是發生在哪一層？

原文來源：browser-use/video-use (GitHub)