Code Video Model 可控影片解析：用程式安排動作，再讓生成模型完成畫面
Code Video Model 結合可編輯程式與生成影片。本文解析場景、動作與外觀的分工，對照公開程式的執行要求，整理創作者測試與驗收可控性的具體方法。
Code Video Model 最近在 X 受到關注，把程式控制與生成影像接在一起，嘗試改善影片看起來漂亮、動作卻難以修改的問題。
創作者常需要很具體的調整：物件先往左移，再停一下，鏡頭最後拉近。每次重新描述整段影片，其他已經滿意的部分也可能跟著改變。
這項研究先用程式安排場景與運動，再讓預先訓練的影片模型完成畫面。程式提供可修改的結構，生成模型則負責較豐富的外觀。
這種分工有吸引力，因為修改可以從明確的位置開始。創作者能先檢查物件與鏡頭，再處理生成後的材質與細節。
不過，程式草稿正確，最終影片仍可能出現誤差。是否值得採用，要看指定動作能否留下來，以及重做時能否保住其他條件。
理解這個研究方向，可以先從一段影片被拆成哪些工作看起。
Code Video Model 如何分工？
Code Video Model 把影片製作拆成可執行的場景草稿、外觀參考與最後生成，讓結構和風格有不同的修改入口。
官方研究稱場景草稿為代理影片。它是先把物件位置、動作時間和鏡頭路徑算出來的簡化版本，可以當成製作正式畫面前的動態分鏡。
這裡的程式代理，是接受需求後協助撰寫與修改程式的 AI 工具。它產生的程式仍需要執行，畫面才會顯示物件實際如何移動。
公開程式使用 Three.js 建立場景。這是能在瀏覽器呈現三維物件的工具，適合把位置、角度、路徑與鏡頭寫成可修改的設定。
如果一臺車要沿彎路前進，程式可以安排車子的座標和朝向，再讓鏡頭保持追蹤。創作者看到的先是這段可計算的運動。
運動清楚以後，系統再準備參考圖片，提供色彩、材質與整體風格。最後的影片模型接收草稿、參考圖及文字需求，生成完整片段。
研究指出，影片模型若一直參考簡化草稿，可能把草稿平淡的外觀也帶進成品。結構控制太強，反而會限制想要的視覺表現。
團隊因此提出只在生成初期使用草稿線索的方式。模型先建立場景結構，後續減少這項約束，讓參考圖的外觀有較多發揮空間。
官方把這個方法稱為不需額外訓練的控制排程。它仍使用已經訓練好的影片模型，沒有省掉下載模型、運算或生成成品的成本。
程式可修改的意義，就是讓創作者知道哪一部分先改。車子走錯路，可以回頭修路徑。外觀偏離參考圖，則要檢查後續生成。
兩個階段彼此影響，驗收時也要分開觀察，才能找到修改原因。
可控制不等於沒有生成誤差
驗收的第一步，是把程式草稿與最後影片放在一起比較，確認模型保留了哪些安排，又在哪些地方自行改變。
物件數量、移動路徑、動作順序與鏡頭方向，都應對應原本要求。只看最後一張截圖，會漏掉移動途中出現的錯誤。
例如需求指定車子通過兩個路標，最終畫面可能很精緻，卻把第二個路標省略。這會影響故事與資訊，不能只用美觀評分帶過。
時間也需要驗收。產品在畫面中停留幾秒，會影響觀眾能否看清楚。動作順序被改變，可能讓操作示範產生不同意思。
把結構、風格與品質各自評分
官方評估工具分別檢查結構、風格與品質。這個分法對創作者有用，因為三種問題需要不同的修正方式。
結構看位置、軌跡和事件是否符合草稿。風格看成品是否保留參考圖的外觀。品質則看畫面是否有明顯破碎、變形或不連貫。
假設要做一段杯子的產品短片，可以先寫下杯子轉動方向、鏡頭距離、停留時間，再指定材質與品牌色。這是建議測試情境。
成品若轉動方向正確，但杯身標誌在轉動時改變，就代表結構通過、品牌細節未通過。兩者分開記錄，後續才不會修錯地方。
可計算的物理也有適用條件
官方展示包含物理動態，由程式中的方程安排部分運動。這能讓草稿有明確規則，而不必把所有動作交給模型自行想像。
但方程安排得合理，還不等於場景已完整模擬真實世界。材質、碰撞和邊界條件都會影響結果，最後生成也可能偏離草稿。
如果影片用途是娛樂，少量視覺誤差可能可以接受。若是科學教學或產品操作，錯誤運動會傳達錯誤資訊，標準就要提高。
因此，同一段漂亮示範只能證明研究展示了某種能力。能否投入你的工作，還要用自己的需求檢查可重複性。
創作者先準備什麼？
開始試行前，先把影片需求分成結構與外觀，避免一次要求太多改變，最後無法判斷哪個階段出了問題。
結構包括誰移動、何時移動、移到哪裡與鏡頭怎麼走。外觀則包括顏色、材質、品牌細節及整體視覺風格。
需求要寫成可觀察的條件，例如物件從畫面左側進入，在中央停留，再由鏡頭靠近。抽象的「更有動感」較難驗收。
公開程式也提供場景檢視工具，可以播放、拖曳時間軸、逐格檢查，並檢視來源程式。這有助於先確認草稿，減少直接生成整段的浪費。
場景檢視器還能顯示鏡頭視野與移動軌跡。若物件離開鏡頭，創作者可以先調整場景，再評估成品畫面。
先用現成案例確認環境
2026 年 10 月 13 日查閱公開倉庫時，安裝說明以 Ubuntu 與支援 CUDA 的 NVIDIA 顯示卡環境為前提，並要求相應的 Python 與影片工具。
CUDA 是讓 NVIDIA 顯示卡執行運算的軟體環境。這項前提會影響誰能直接跑範例，不能把研究頁面寫成一般電腦開網頁就能完成。
倉庫提供跑車、戰車、室內導覽與機器人導航等範例，包含提示、參考圖與程式影片。先跑既有案例，較容易分辨環境和需求問題。
完整流程還使用不同模型服務製作程式與參考圖片。模型存取、服務費用及憑證設定，都要和本地影片生成一起評估。
不需要一開始就把整套流程改成自己的專案。先確認可重現一個範例，再替換其中一項要求，會較容易找到失敗原因。
修改時保留原始版本
例如先保持物件、風格和片長不變，只修改鏡頭位置。新版本若連材質也改了，就能知道修改產生了額外影響。
每次儲存程式、代理影片、參考圖與成品，並用同一組條件比較。只保留最後的 MP4，會失去追查前一階段的依據。
官方也提供建立原版與修改版的流程，兩邊都有場景程式和生成輸入。這種成對比較，比單看一支精選影片更能說明可控性。
實際工作中，修改紀錄可以寫得簡短：本次改了什麼、哪些條件要保持，以及生成後有哪些偏差。重點是讓下一次修改有依據。
研究成績與創作成本要分開看
研究頁面用 CodeVideoBench 評估不同應用的控制效果，公開倉庫描述了二十二個案例，並附上可修改程式與相關輸入。
案例涵蓋遊戲、場景編輯、鏡頭效果、物理動態和重建等用途。這顯示團隊測試了多種任務，但樣本仍有明確範圍。
官方分數由評估模型依指定維度產生。它能支援研究比較，創作者仍需要人工檢查品牌字樣、細部動作與實際用途。
例如一支商品短片可能得到不錯的整體分數，包裝上的小字卻不可讀。對研究可能只是區域性缺陷，對商業素材卻可能需要重做。
時間也要從需求開始算到可交付為止。研究描述代理影片可快速預覽，這個速度不能直接當成最後成品的完整製作時間。
前期整理需求、修改場景、生成、檢查與後製，都會佔用工作時間。若只計算一次生成，會高估自動化的效益。
建議記錄每個階段花的時間，並和原本的方法比較。可編輯程式的價值，應該體現在少做無效嘗試，或更容易保留已經完成的部分。
若團隊仍需反覆手工重做，問題可能出在需求不清楚、草稿不足，或影片模型未保留細節。找到原因後，才知道是否值得繼續。
一次小測試如何得到可用結論
建議把第一次測試限制在一個主要動作，例如物件沿固定路線移動。先讓程式草稿通過，再加入所需外觀，減少同時改動造成的混淆。
測試時保留一份固定需求，讓每個版本都回答相同問題。不能在看見成品後才降低標準，否則很容易把偶然出現的漂亮結果當成成功。
如果第一次生成符合要求，還可以用同一組輸入重做。這能觀察成品是否穩定，而不只是某次執行剛好避開了錯誤。
再挑一個明確修改，例如把停留時間加長，檢查其他動作是否維持。修改能力需要同時看變更有沒有生效，以及原有條件有沒有被保留。
最後把失敗分到草稿、參考圖與生成結果。若草稿已經錯，重試生成只會消耗資源。若草稿正確而成品偏離，就要處理模型控制。
這份紀錄不必很長，卻能支持下一個決定：繼續調整同一方法、縮小使用範圍，或保留傳統製作方式處理必須精準的部分。
Code Video Model 常見問題
這是只靠程式做影片嗎？
它結合程式安排與生成模型。程式負責可計算的場景和運動，最終影像仍由模型生成，兩個階段都需要檢查。
最適合先測哪種需求？
可以先測路徑、順序或鏡頭要求明確的短片。條件容易觀察，才方便比較草稿與成品，判斷控制方法是否有幫助。
官方示範能否證明所有情況都穩定？
公開展示與基準有各自的場景範圍。自己的需求仍需要多次執行，保留失敗案例，確認不同版本能否維持重要條件。
有程式是否就能保證正確物理？
物理結果取決於程式採用的規則與參數，生成階段也可能出現偏差。教學或操作影片應另行核對實際內容。
一般創作者要先學完整程式嗎？
先理解流程與可修改項目就有幫助。若需要自行部署、除錯或改場景，則需要相應的技術能力，不能只依賴一句提示。
先畫清楚影片的動作骨架
Code Video Model 的方向，是讓影片結構有可修改的入口。場景程式使動作較容易追查，生成模型則補足簡化草稿的外觀。
對有指定路徑、順序與鏡頭需求的創作者，這值得進一步測試。能否採用，仍要看成品是否保留安排，以及修改後是否少了無效重做。
先選一段短片，寫清楚動作順序、時間與鏡頭，再對照公開範例。把草稿和成品一起儲存，就能逐步找出自己的控制瓶頸。
延伸閱讀：2026 Claude Code 做影片 Skills 推薦：HyperFrames、Remotion 到剪輯工具怎麼選？
延伸閱讀：Synthesia Syren 教學：用品牌影片當參考，做可修改的產品介紹與短片
