不猜像素、改寫程式碼：商湯開源的 Code2Video，把影片生成這件事換了個底層做法

Claude Opus 用寫程式的方式產出一支 15 秒影片、燒掉近百美元的討論還沒退燒，V2EX 上已有網友貼出另一個選項：商湯（SenseTime）旗下 OpenSenseNova 開源了 SenseNova 6.8 Code2Video，一個 27B 參數、專門靠編寫與修改程式碼來生成影片的模型，全量權重與配套的創作 Skill 都放在 GitHub 上。以下內容以該篇 V2EX 貼文與其引用的專案說明為依據，部分細節仍以官方文件為準。

為什麼像素擴散模型做不好科普動畫

Sora、Runway 這類影片生成模型，本質上是逐幀「猜」像素。畫面好看，但遇到科普影片、動態圖形（Motion Graphics）或排版動畫這類需要精準的內容，問題就來了：文字出現亂碼、數學公式變形、物理碰撞穿模。這些毛病靠加大參數量救不了，因為問題出在實作原理，像素機率分布天生管不動「這個字必須拼對」這種事。

Code2Video 換了條路：模型不產出像素，而是產出可執行的前端與圖形程式碼，涵蓋 HTML/CSS、Canvas、SVG、Three.js、Manim、p5.js 等工具。在程式碼的世界裡，文字是原樣排版的字元，公式直接來自輸入資料，座標、時長、運鏡路徑都是精確數字，運動與光影由數學方程計算。打個比方：像素模型像請一位畫家憑印象畫一千張連續圖，Code2Video 像請一位工程師寫一份動畫程式，電腦照著跑，每一格都算得出來。

渲染機制：把畫面寫成時間的函數

它的渲染流程和 Opus 的做法類似，不靠錄幕抓畫面，而是把每一幀畫面寫成時間參數 t 的純函數。給定任意時間點，程式就能唯一算出那一刻所有元素的位置、形變與色彩。因為不依賴系統即時時鐘，同一份程式碼跑一百次，畫面分毫不差。

實際產出時，系統用 Playwright 啟動無頭 Chromium 瀏覽器，按設定幀率逐步呼叫時間函數、截取畫面，最後交給 FFmpeg 把成百上千張序列幀與音軌合成 MP4。配樂、環境音與動作音效也能用 Python 腳本合成並對齊節拍，讓切鏡和音樂拍點一致。

spec.md 才是關鍵：先寫規格書，不是先抽卡

一般模型一句話生成的動畫之所以粗糙，常常是因為直接跳進寫程式碼。Code2Video 與其開源的 Skill 規定了嚴格流程：接到需求後，模型先讀取對應指南，把需求轉成一份可核查的技術規格文件 SPEC.md，確定構圖、配色、緩動曲線與分鏡時間軸，然後才動手寫程式。

這份規格文件的價值在於：使用者用自然語言要求修改時，實際上是改 spec，而非直接改程式碼。專案有了統一規格，多次修改後風格才會一致、邏輯才連貫。貼文也提到，吳恩達近期在 vibe coding 課程中同樣強調了這一點。

初版程式渲染完成後，系統會自動抽取關鍵幀生成「分鏡縮圖聯繫表」（Contact Sheets），模型自己當導演審閱：文字有沒有重疊、元素有沒有出畫、節奏是否合理，發現問題就改程式、重新渲染。貼文指出，一支精品短片往往要經歷上百次這種循環，而該模型針對長程任務做了專門訓練。

對一般使用者意味著什麼

如果你做過簡報動畫、產品說明影片或數據視覺化，這條路線的吸引力很具體：改一個數字、換一組配色，不用重抽卡，改 spec 再渲染就行，結果可預期。代價是它天生適合圖形、排版、科普這類結構化內容，寫實影片仍是像素模型的場域。

至於成本面，開源全量權重代表可以自己部署，避開按次計費的 API 帳單；不過 27B 參數模型的推理硬體需求與實際產出品質，仍有待社羣實測驗證，V2EX 貼文本身並未提供跑分或實際渲染成本數據。想自行評估的人，專案位於 GitHub 的 OpenSenseNova 帳號下，文件寫得比熱帖詳細得多，值得直接讀原始說明。

一句話收斂：當「用程式碼生成內容」從頂級付費模型獨有的能力，變成一份可以下載的權重檔，內容工作流裡最該重新估價的，是那些需要精準、可反覆修改的影片製作環節，從科普頻道到企業產品說明，都算在內。