AI 影片編輯三部曲：從個人 CLI 工具到 Runway 的逐幀重寫
AI 影片編輯這兩年出現了三個切入角度，而且幾乎同步成熟：個人開發者自己做工具（video-use Claude Code skill）、開源團隊把架構設計原則化（browser-use 的 agent 設計）、商業平台直接把「改一格整片跟著變」做成產品（Runway Aleph 2.0）。三個入口、三種目標用戶，但解的是同一個問題：讓影片後製從手動變自動。
一、個人工具：video-use Claude Code Skill
Gregor Zunic 開門見山：他不想繼續付影片剪輯軟體的費用，所以他自己做了一個替代品。結果是一個 Claude Code skill，安裝完之後你對著鏡頭講話，然後得到一個 final.mp4——去掉了所有「嗯」和「啊」、字幕已燒錄、色調已校正、動畫已插入。
這不是 demo 專案。它是一個可以直接裝進日常 workflow 的工具。
它實際在做什麼
video-use 處理的是錄影後製流程中最費時、最無聊的部分：
自動清除填充詞：讀取 ElevenLabs Scribe 產生的逐字稿，每個詞都有毫秒級時間戳。遇到「umm」「uh」或取景間的靜音，直接標記成刪除區間，由 FFmpeg 執行切除。不需要你手動拖時間軸。
字幕燒錄：預設是兩個詞一組的全大寫字幕塊——就是你在 YouTube short 和 TikTok 上看到的那種格式。可以調，但預設值選得很合理。
色彩校正：提供 cinematic（電影感調色）和 neutral 兩種處理，直接套用，不需要你懂調色。
動畫生成：透過並行 subagent 呼叫 Manim、Remotion 或 PIL 生成動態圖形，再合進影片。這部分是這個 skill 最有野心的設計——剪輯、調色、動畫，全在同一個 Claude Code session 裡完成。
自我評估：在輸出前，skill 會在每個剪輯點做自動檢查，確認沒有畫面跳接異常。
Session 記憶：把當次的編輯決策存進 project file，下次繼續同一支影片時不需要重新建立上下文。
為什麼 token 用量沒有你想的那麼高
直覺上，讓 AI 處理影片聽起來很昂貴。但 video-use 的技術選擇正是為了解決這個問題。
它不讀取原始影格。取而代之，它讀的是：
- ElevenLabs Scribe 的文字逐字稿（含詞級時間戳）
- 縮圖 filmstrip（不是完整畫面序列）
- 音訊波形圖
這三樣東西加在一起，能讓 Claude 定位到任何一個剪輯點——而不需要把整部影片餵進 context window。實際的 FFmpeg 指令由 Claude 生成，執行在本地，沒有影格資料進入 API。
完整流程
整個流程的核心在 B-C-D 這三步：逐字稿帶著時間戳進來，Claude 判斷哪些要刪、哪些要保留、哪些位置插入動畫，輸出一份指令清單，然後 FFmpeg 在本地執行所有實際的影片處理。
和手動剪輯的時間對比
手動剪輯 vs video-use 所需時間（分鐘）
這些數字是針對一支 5 分鐘左右的錄影估算的。填充詞清除手動需要聽一遍再拖時間軸，video-use 的版本是讀逐字稿直接算出時間點，幾乎是定速的。動畫插入的差距最大，因為手動版本還要開 After Effects 或 Keynote 製作，video-use 直接呼叫 Manim subagent。
安裝方式
# 1. Clone repo
git clone https://github.com/gregpr07/video-use
# 2. 建立 symlink 到 Claude Code skills 目錄
ln -s /path/to/video-use ~/.claude/skills/video-use
# 3. 安裝 FFmpeg（macOS）
brew install ffmpeg
# 4. 設定環境變數
export ELEVENLABS_API_KEY=your_key_here
# 5. 把素材放進 footage/ 資料夾，啟動 Claude Code
claude-code edit footage/
輸出會在 edit/ 子目錄裡。ElevenLabs API key 是必要的，因為 Scribe 轉錄是整個流程的基礎——沒有逐字稿就沒有時間戳，沒有時間戳就沒有精確剪輯點。
幾個值得注意的地方
ElevenLabs 依賴：轉錄品質取決於 Scribe 的準確率。如果錄音環境嘈雜或口音較重，時間戳的精確度會下降，自動剪輯點可能會有偏差。這是整個架構的核心假設，換掉它不是小工程。
動畫生成的一致性：Manim 和 Remotion 的輸出品質取決於 Claude 怎麼理解你的影片內容。對於技術教學影片，效果通常不錯；對於更抽象的內容，可能需要多迭代幾次。
這是個人工具，不是服務：整個架構假設你有本地環境、會用終端機、知道怎麼設定 API key。它不是一個上傳就能用的線上服務，是一個可以嵌進你既有工作流程的 CLI 工具。
適合誰
如果你定期錄製技術教學、播客、產品 demo 或開發 vlog，video-use 解決的是真實痛點。不需要你學剪輯軟體，不需要你懂調色，不需要你雇人後製。
甜蜜點非常明確：
- YouTuber / Podcaster：每週一集，最花時間的就是切贅字跟對字幕
- 線上課程講師：螢幕錄影一錄兩小時，裡面 30% 是卡詞跟停頓
- 行銷 / 內容團隊：同一支素材要剪成長片、短片、社群版，預剪這一層可以自動化
- 教育工作者：上課錄影轉成可發佈的教材
反過來，不建議直接丟給它的：敘事型剪輯、MV、需要強導演觀點的紀錄片——那些本來就該人來做。它做的是 80/20 裡的那個 80：重複、機械、沒人想做的部分；剩下 20%（節奏感、轉場選擇、品牌調性、情緒起伏）還是得人來決定。但那個 80 如果能從「三小時」變成「十五分鐘 + 抽查」，對每週要出片的人就是生死線的差異。
Gregor Zunic 做這個工具的動機很具體：不想付剪輯軟體的錢。能用的人大概也有同樣的背景——知道自己想要什麼結果，但不想花時間在機械性的後製操作上。
二、架構原則：LLM 為什麼不應該看影格
6,000 stars、842 forks、只有 10 個 commits——這個反差本身就是一個問題。browser-use 團隊剛發布了 video-use，一個讓 AI agent 幫你剪片的工具，開發者的反應是「我等這個很久了」，而不是「這有什麼用」。
stars 是時機指標，不是品質指標。這個 section 要回答的是：它現在真的能用嗎？背後的設計決策值不值得你抄？
它現在能做什麼
video-use 是 browser-use 團隊做的 AI 影片剪輯 agent，用自然語言指令操作 FFmpeg 完成剪輯任務。五個核心能力：
- 去 filler words：自動剪掉「嗯」、「啊」、語塞和死空氣，精確到單詞級別
- 自動調色：對特定片段套用電影風格色彩分級（cinematic LUT）
- 字幕燒錄：預設每 2 個字一組、全大寫，風格可自訂
- Audio fade：每個剪切點自動加 30ms 淡入淡出，避免爆音
- Self-eval loop：渲染完成後自動檢查每個剪接點的視覺跳接和字幕可讀性，最多三次迭代
輸入：一個放著原始素材的資料夾。輸出：一支 final.mp4，加上一份 project.md 記錄本次的剪輯決策，下次繼續工作時不用重新說明。
為什麼不讓 AI 看影格
這是整個專案最值得拆的設計決策。
直覺做法是把影片轉成影格，餵給多模態模型看。問題在規模：一支 30 分鐘的影片，30fps 等於 54,000 個影格，每個影格壓縮後仍需約 1,000–1,500 tokens。這是 5,400 萬 tokens 的噪音，而且大部分連續影格之間幾乎沒有資訊差異。
video-use 的做法是「text-first，visuals on-demand」：
ElevenLabs Scribe 先把每支素材轉成帶有單詞級時間戳和說話者標記的 transcript，所有素材壓縮成一份約 12KB 的 markdown 檔案。LLM 讀這份文字，推理出剪接決策，生成 EDL（Edit Decision List），再由 FFmpeg 執行。只有在 LLM 需要視覺判斷時（例如確認調色效果），才會即時產生 filmstrip + waveform 的縮圖，而不是一開始就傾倒所有影格。
整個 pipeline 裡，LLM 從頭到尾沒有「看」過一格影片。
三個現在的真實限制
在你決定導入之前，這三個限制要清楚：
1. ElevenLabs Scribe 是必須的外部依賴：transcript 品質決定一切後續決策的準確度，而 video-use 目前硬綁 ElevenLabs Scribe API。這有費用，也有速率限制。長影片的轉錄成本不可忽略。
2. 流程假設你的素材在本機：整個 pipeline 以本機 FFmpeg 為核心，沒有雲端素材的整合方案。如果你的工作流程是從 Frame.io 或 Google Drive 拉素材，需要自己做前處理。
3. Animation overlay 需要額外安裝：字幕和調色開箱即用，但動畫疊加（Manim 生成數學動畫、Remotion 生成程式碼動畫）需要獨立安裝這些工具。對只想要基本剪輯的人來說是不必要的複雜度。
最好的 agent，不是讀最多資料的那個
video-use 和 browser-use 共用同一套思維：找到任務的最小夠用表示法（minimal sufficient representation），而不是餵給模型最多資料。
browser-use 的做法是讓 agent 讀 DOM 而不是截圖整個畫面。video-use 是讓 agent 讀 transcript 而不是看影格。兩者都在問同一個問題：這個任務真正需要的資訊是什麼形式？
對你下一個 agent 來說，這是值得在設計階段就問的問題——在你開始想怎麼處理資料之前，先想清楚你要給模型讀什麼結構。
好的 agent 不看最多，它讀最精。
video-use 現在還早，但這個架構決策，比 6,000 stars 更值得記住。如果把同樣的邏輯套到其他媒體類型（音訊 podcast、長文文件、程式碼庫），你會得出幾乎一樣的結論：模型不需要看全部，它需要的是一份好讀的摘要層。
還沒有人測過的邊界
當素材有多個說話者、場景切換複雜時，純 transcript 的表示法會不會開始失效？如果你在做 multi-speaker 剪輯，這個問題值得你在導入之前先想清楚。
三、商業平台：Runway Aleph 2.0 改一格整片跟著變
2026 年 5 月 21 日，Runway 發布 Aleph 2.0。你只需要編輯影片裡的一格，AI 就會把這個改動自動套用到整段影片。這不是濾鏡、不是貼圖特效，是真正懂得「這一格改了什麼」然後往前往後全部跟著動。
Aleph 2.0 實際上做了什麼
說白了就是三件事。
第一，你選一格畫面，改你想改的地方，Aleph 2.0 會把這個改動套用到整段影片，最長支援 30 秒、解析度 1080p。不用一格一格手動調，AI 自己搞定。
第二，它的修改是「局部精準」的。你改了某個物件的顏色，背景的光線和其他元素不會跑掉。這點很關鍵，因為過去很多 AI 工具一改就全部亂掉，Aleph 2.0 只動你要它動的地方。
第三，它支援多鏡頭剪接序列。就算你的影片中間有切換場景、有不同鏡頭，改動一樣會跨過剪接點延伸下去。這對要做正式影片內容的人來說，是真的有用的功能。
還有一個細節：你可以先把改動預覽成靜態圖片，確認方向對了再跑完整影片生成。少走很多彎路。
跟其他工具哪裡不一樣
現在市場上不缺 AI 影片工具。Pika 專注短片特效，Kling 在生成階段做角色一致性，Adobe Firefly 是大廠的生態整合方案，Sora 則是 OpenAI 的生成模型。
但這些工具都沒有「改一格、全片跟著動」這個工作流程。
說白了，它們大多是在生成影片的時候幫你控制風格，不是在你已經有一段影片素材之後，讓你精準修改再批量套用。Aleph 2.0 瞄準的是「後製編輯」這個位置，不是「從零生成」。
這是兩種完全不同的使用情境。如果你有一段拍好的素材或已生成的影片想要改，Aleph 2.0 現在是最直接的選擇。
Runway CEO 怎麼說
Aleph 1.0 redefined so many new ways of editing and making videos. Really excited for Aleph 2.0 to set a new standard for the category.
— Cristóbal Valenzuela，Runway CEO
現在可以怎麼用
Aleph 2.0 已經上線，入口是 Runway 同步推出的新產品 Edit Studio，直接在網頁版就能用。如果你有影片後製的需求，現在是實際試試看的好時機。
個人工具現在能省掉 80% 的重複剪輯工作——填充詞清除、字幕燒錄、調色，這些原本要花數小時的事情，CLI 跑一次就完成。商業平台則正在把剩下 20% 的「精細修改」也自動化：你改一格，整支片跟著變。對創作者來說，這條路走完之後，後製工作的本質會從「執行」變成「決策」——你只需要知道要改什麼，不再需要知道怎麼改。
參考來源
利益揭露：本文部分連結為聯盟連結，點擊購買我會獲得回饋，不影響你的價格。我只推薦自己用過 3 個月以上的工具。