WeVisCut 9B 剪輯代理開源，把解說稿變多分鐘成片

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

如果你經營知識型解說頻道，或負責一條「固定講稿進、多分鐘影片出」的產線，多半試過把剪輯流程交給通用大型模型：它會寫分鏡、會下指令，可是長片的中間產物互相依賴，旁白、素材、配音、時間軸缺一樣，後面的成片計畫就走不下去，反覆重試的結果是決策 Token 的用量跟著帳單一起往上。騰訊 WeChat Vision 團隊與西安電子科技大學在 2026 年 10 月 28 日向 arXiv 提交的 WeVisCut，把這個問題拆開來回答：誰做決策、誰做執行。一個約 90 億參數的小模型專門讀剪輯狀態、挑下一個動作；實際的旁白合成、素材檢索、時間軸渲染交給 12 種剪輯工具，環境負責驗收。論文、程式與模型權重都在十月內開放：程式放在 GitHub 的 Tencent/WeVisCut 儲存庫，權重放在 Hugging Face 的 tencent/WeVisCut 供下載，連產生訓練資料的軌跡收集管線 data_construct_pipeline 也一併公開。

Pin

在同工具環境的 100 個保留任務上，這個 9B 模型五項指標平均 90.5，與固定版本的 Claude Opus 5 的 89.9 在伯仲之間；每成功成片一分鐘的生成 Token 約 2,377，約為對方的三十三分之一。這兩個數字是整份研究最常被轉述的部分，也是最容易轉述錯的部分，後面分開談。

長片自動剪輯卡住的是狀態，不是生成

一句話生影片的模型，輸出一次就結束；長片剪輯代理面對的是連續幾十個互相牽動的決策。旁白配音先鎖定鏡頭長度，素材檢索要看分鏡內容，時間軸組合要等每個鏡頭渲染完成，任何一步缺檔，後面全部卡住。WeVisCut 的做法是把剪輯狀態（章節、鏡頭、旁白、素材、模板、配樂、渲染產物）留在工具環境裡，模型每一步只看狀態就發出一次工具呼叫，README 說明一次完整製作大約 12 次呼叫就交片。12 種工具涵蓋切章節、規畫鏡頭、合成配音、檢索素材、套用動態模板、組時間軸、找配樂、文字與畫面兩種品質檢查、自我反思、外部服務預檢與最終合成。

一個設計細節是「擋」與「代勞」的分際：環境只拒絕非法的工具呼叫，不會替模型挑下一個動作；修復有次數預算，用完就停，缺檔不會自動變成可交付的成果。論文附了一段執行紀錄，模型一度認為可以交片，合成工具回報必要的渲染結果缺失，流程被擋下；補上時間軸組合與配樂之後重試同一個合成要求，才真正完成，而且先前做好的鏡頭都沒有重做。「已經計畫」和「已經做完」由環境分開認定，模型自己說了不算。另一個細節是角色分工：編排者選工具、內容生成者準備結構化內容、品評者檢查成果與修復需求，三種角色共用同一套 9B 模型參數，靠工作脈絡切換，並非三個模型各做一段。對長流程來說，這代表同一個模型要同時學會下指令、填內容和挑毛病。

訓練資料是整份研究最費工的部分。成片本身不會記錄剪輯師當時點過哪些工具，團隊先從 3,750 支既有旁白影片回推每個鏡頭想表達的內容，題材橫跨科技與數位產品、商業金融、自然科學、社會科學與人文，再放進工具環境實際重做；重播過程留下工具名稱、參數、回傳值與失敗情形，經檢查與有限次數修復，累積成 134,771 筆「做了這一步之後發生什麼」的可執行樣本。失敗回傳之所以重要，是因為只看順利完成的理想流程，模型選錯工具時就不知道怎麼回到還能接續的狀態。訓練依序走三個階段：先模仿既有軌跡，接著讓模型面對自己執行後產生的狀態、教師模型逐步退場，最後在同一角色、同一剪輯狀態下比較不同決策的實際結果。相對於未訓練的 Qwen3.5-9B 底模，五項平均從 74.5 拉到 90.5，其中稿件內容忠實度提高 18.6 分，畫面與旁白的語意匹配提高 15.4 分。專案頁的互動展示標明是「真實製作過程的重播」，可以直接看它怎麼接鏡頭、怎麼被擋、怎麼補件。

兩組實驗回答兩個不同的問題

同工具環境的實驗把所有模型放進同一套工具、同樣預算：100 個保留任務（不參與訓練）、每個任務固定旁白稿件、素材池、目標長度與畫面比例，各跑五次取平均。對照組包含 Qwen3.5-9B、Qwen3.6-27B、Qwen3.6-35B-A3B、Qwen3.5-397B-A17B、Gemini 3.1 Pro，以及固定版本的 Claude Opus 5（論文未載明快照的具體版本號）；這些參考模型都沒有接受此環境的專用訓練，所以比較的是「同一個環境裡，專用訓練帶來多少差距」。

Pin

五項指標本身值得認識：稿件內容忠實度（旁白有沒有涵蓋並忠於原稿）、畫面與旁白語意匹配（畫面撐不撐得起當下的旁白）、時間軸計畫實現（計畫的鏡頭有沒有真的做出來）、長程一致性（後段鏡頭的健康度與素材多樣性）、端到端產出率（能不能交出可解碼、長度足夠、旁白不缺席的影片檔）。數字要讀得準：WeVisCut 五項裡四項平均較高，語意匹配一項略低（74.6 對 74.8），沒有任何一項差距超過 1.3 分，這是「接近」的證據，撐不起「超越」的結論；它同時在五項全部高於 Qwen3.5-397B-A17B 與 Gemini 3.1 Pro。五項平均是等權重的描述性總結，論文明說指標之間不獨立（長程一致性的計算本來就用到語意匹配），90.5 不等於 90.5% 的片子可以直接發表；語意評分靠視覺語言模型評審，作者也自承證據隔離與人工校準無法完全消除裁判偏差。分子計入失敗嘗試，分母是成功輸出的影片分鐘。

原生系統的實驗換一個問題：各自用原生工具與編排時，完整系統的成本如何。腳本、素材池與交付要求固定，時間與美元估計都把失敗嘗試算進去。

同場還有三人盲測：WeVisCut 在主題忠實、內容豐富、敘事連貫、剪輯流暢、視覺品質與整體偏好六個維度全部最高，整體偏好 4.56 分（滿分 5 分），Crayotter 與 VideoAgent 分別是 3.48 與 3.46。這組數字反映的是作者測試條件下的完整流程效率，換了配音、素材或運算供應商就會變動，不能當成公開服務的價目表。固定素材池也代表結果落在「研究設定的來源範圍」內；自己的工作如果高度依賴即時素材或開放網路檢索，檢索與交付品質要另外驗。

三十三分之一的 Token，不是三十三分之一的製片費

2,377 對 78,763 的差距，量的是模型做決策時生成的文字量，成立條件是兩個模型都用同一套工具；0.09 美元那一組，量的是含失敗嘗試的完整流程成本，是另一個實驗設計。兩個數字回答不同的問題，相乘或互換都沒有實驗支持，偏偏「省 33 倍」是最容易在轉述中被合併成的句子。實際帳單還取決於素材檢索、配音、渲染各自接哪個服務、失敗重跑的頻率，以及 GPU 的取得方式：走 API 的通用模型按 Token 計費，決策文字量會直接反映在可變成本；自架 9B 則把成本換成 GPU 時間與一次性訓練投入。模型卡也提醒：成片品質取決於設定的檢索、配音與渲染服務和可用模板。對照一個參照點：同工具環境裡，未訓練的 Qwen3.5-9B 每分鐘用 11,883 個生成 Token、3.1 次工具呼叫，分數只有 74.5；專用訓練讓同一個底模把 Token 壓到 2,377，分數拉到 90.5。把 Token 壓下來的是約 13.5 萬筆可執行軌跡的專用訓練，模型規模本身沒有這個效果。

部署前要核對的四件事

• 硬體與環境：README 要求 Python 3.11 以上，bf16 精度的 9B 推論約需 24GB 記憶體的 NVIDIA GPU；外部依賴（Node、ffmpeg、渲染器）由安裝腳本抓取，約 1.1GB。Studio 可以用 –no-model 只開時間軸介面不載模型，方便看操作，但那不等於不用 GPU 就能完整製作。模型卡載明它並非獨立的文生影片模型，離開工具環境產不出影片。
• 素材與配樂來源：預設走開放網路搜尋（asset_retrieval_tool），設定檔可改指到自己的 API 或本機資料夾。檢索到的影片與音樂沿用各自的授權，使用這個代理不會自動取得商用權。
• 授權口徑：GitHub 儲存庫的 LICENSE 寫 WeVisCut（含騰訊公開的程式、參數與權重）採 Apache-2.0，第三方組件沿用原條款，清單列出的底模 Qwen3.5-9B 由阿里雲以 Apache-2.0 釋出；Hugging Face 模型卡卻標 license: other，寫「模型權重與第三方組件受各自條款規範」。兩個官方頁面對權重的口徑不一致，商用前建議兩份文件都留檔核對。
• 專案成熟度：儲存庫 2026 年 9 月 9 日建立，近兩個月後的現在是 42 顆星、8 個 fork、沒有 release 標籤，最後一次推送在 10 月 30 日（更新 README）；Hugging Face 顯示權重已被下載 191 次。專案很新、仍在動，還沒有經過時間與社群規模的驗證。

交片之後的介入點也設計過：Studio 介面有八條同步軌道（章節、鏡頭、旁白、字幕、素材、模板、配樂、渲染），支援暫停續作、手動修改、用對話改稿（例如換開場第一句、替換某個時間點的畫面）、單鏡頭重渲染與版本回退。README 的例子是把剪輯狀態留在可編輯的形式，人接手時不必整支重來；對照專案頁展示的導演對話修正，改一個鏡頭只動那個鏡頭的產物，已成立的段落原樣保留。視覺呈現則有明確天花板：重點鏡頭套用 HyperFrames 模板（HeyGen 的開源專案，論文引用編號 7，先前介紹過它的 Computer Use 更新），模板庫決定能做出哪些視覺語言，特殊風格只能用最接近的模板近似；論文的限制章節也點名模板庫與素材檢索穩定性是當前邊界。

誰該現在花時間研究它

適合的團隊：已有固定解說稿與製作管線、能部署對應服務、而且影片上線前有人審內容與權利。它省的是決策段的反覆，審片省不掉，模型卡明寫不保證事實正確性與製作品質。手上已經有大量成片資產的團隊還多一層想像空間：軌跡收集管線 data_construct_pipeline 一併開放，理論上可以用同樣的四階段流程，把自己的成片回推成自己的訓練素材，這也是這次開放比單純放出權重更值得注意的部分。對已經在用 AI 代理剪片、把計費畫在素材索引與工具呼叫上的 Kino 工作流，WeVisCut 提供另一種架構選擇：決策模型自帶、工具環境開放、權重可下載，不必把整條流程鎖在單一服務裡；對想搬回自己伺服器跑開放權重的影像團隊，十月底的 Pika H3 Flex 之外又多一條路。還不適合的場景：沒有固定稿件結構的素材型剪輯（新聞現場剪輯、大量特殊視覺風格），以及無法安排人工審查的流程。

要判斷它對自己的產線有沒有價值，最直接的方式是拿三支自己的稿件做對照：固定素材池與目標長度，分別量每分鐘成片的 Token、時間與人審修改量，再決定要不要接進日常。

官方資源

• WeVisCut 論文：arXiv 2610.38352，2026 年 10 月 28 日提交，35 頁全文。
• Tencent/WeVisCut 程式儲存庫：Studio 執行環境、12 種工具定義與訓練資料建構管線 data_construct_pipeline。
• tencent/WeVisCut 模型卡：9B 權重下載、部署需求與使用限制。
• 官方專案頁：架構圖、資料管線圖與真實製作過程的重播展示。