當 AI 開始寫視頻代碼，React 反而成了包袱
整理版優先睇
HeyGen 開源 HyperFrames，指出當 AI Agent 取代人類寫視頻代碼時，React 反而成為包袱，HTML 係更優選擇。
呢篇文章出自 HeyGen 團隊嘅技術分享，佢哋最近開源咗一個叫 HyperFrames 嘅項目，專門用嚟做「代碼生成視頻」。有人話呢個只係 Remotion 嘅 wrapper，但 HeyGen 好直接咁話：唔係。HyperFrames 係從零開始構建，特別為 AI Agent 設計。文章嘅核心命題係：當視頻嘅「作者」由人類程序員變成 AI Agent，底層技術選型嘅最優解可能要徹底翻轉。
文章比較咗兩個方案：Remotion 用 React 作為視頻嘅編寫界面，而 HyperFrames 用 HTML。呢個分別看似只係框架選型，但牽一髮而動全身。LLM 嘅訓練數據入面，HTML、CSS、JavaScript 佔咗好大比例，而 React 只係一個子集，仲有好多框架規則要學。HeyGen 做過評測，發現同一個 LLM 寫 HTML + GSAP 嘅創意範圍明顯闊過寫 React。另外，動畫庫嘅時鐘衝突係一個好致命嘅技術問題：GSAP 用真實時間驅動，Remotion 用幀序列驅動，兩個時鐘唔同步，導致動畫出錯；而 HyperFrames 可以暫停 GSAP 時鐘同步截幀。仲有可編輯性方面，HTML 自然做到渲染同編輯共享同一份 DOM，React 就需要將改動翻譯返 JSX 再編譯，路徑又長又脆弱。
總括嚟講，Remotion 喺分佈式渲染同 React 生態複用方面仍然領先，但呢場技術選型之爭嘅真正問題係：當內容…
- HyperFrames 係從零開始專為 AI Agent 構建，唔係 Remotion wrapper，核心判斷係當作者由人變成 AI，技術選型要翻轉。
- 核心分歧：React vs HTML——React 對人類係增效工具，對 AI Agent 係認知負擔，因為 LLM 訓練數據中 HTML 比 React 豐富好多。
- 技術問題：動畫庫時鐘衝突——GSAP 用真實時間，Remotion 用幀序列，導致唔同步；HyperFrames 可以暫停時鐘同步，GSAP 15年積累功能直接可用。
- 可編輯性：HTML 天然做到渲染同編輯共享同一份 DOM，React 需要將改動翻譯返 JSX 再編譯，路徑又長又脆弱。
- 啓示：Agent-first 世界入面，要揀為人類優化定為 Agent 優化，呢個選擇會決定系統嘅天花板，HyperFrames 揀咗 Agent。
核心分歧：React 定 HTML？
HeyGen 開源咗 HyperFrames，有人話佢係 Remotion 嘅 wrapper，但官方好清楚話唔係。呢個項目係從零開始，專為 AI Agent 設計。背後嘅判斷好值得思考：當視頻嘅作者由人類變成 AI Agent，最優嘅技術選型可能要徹底翻轉。
Remotion 揀咗 React 做視頻編寫界面，HyperFrames 揀咗 HTML。呢個決定牽一髮而動全身。
點解呢個決定咁重要？因為而家寫視頻代碼嘅越來越唔係人，而係 LLM Agent。Agent 嘅訓練數據裡面，HTML、CSS、JavaScript 佔咗極大比例，但 React 只係一個子集，仲有大量框架規則要學。
三個後果：創意、時鐘、編輯
- Agent 嘅創意天花板：LLM 訓練數據中 HTML 比 React 豐富好多，寫 HTML 時 Agent 可以發揮更多花樣，React 限制咗輸出空間。
- 動畫庫嘅時鐘衝突：GSAP 用真實時間，Remotion 用幀序列，兩個時鐘唔同步導致動畫錯亂。HyperFrames 可以暫停 GSAP 時鐘同步截幀，所以 GSAP 15 年嘅功能直接可用。
- 可編輯性嘅天然差異：HTML 嘅 DOM 同時係渲染層同數據層，點擊即可編輯；React 要將改動翻譯返 JSX 再編譯，路徑又長又脆弱。
呢三個後果直接影響 Agent 嘅輸出質素同開發效率。尤其係動畫庫時鐘衝突，HeyGen 做咗個對比實驗：同一段 GSAP 動畫，HyperFrames 輸出完整4秒，Remotion 只捕捉到開頭幾幀同大量黑屏。
GSAP 嘅 SplitText、ScrollTrigger、MotionPath 呢啲功能喺 HyperFrames 直接可用，喺 Remotion 就要痛苦適配。
Remotion 嘅強項同真正問題
公平啲講，Remotion 喺兩個方面仲有明顯優勢：分佈式渲染同 React 生態複用。Remotion Lambda 可以將長視頻分拆到數百個 AWS Lambda 並行渲染，呢個能力好成熟；如果你團隊已經有 React 設計系統，Remotion 可以重用同一組件。
但呢場技術選型之爭嘅真正問題係：當內容創作者從人類變成 AI Agent，我哋要重新審視啲「理所當然」嘅技術決策。
表面睇係 React vs HTML，實際上係問：你究竟為人類定為 Agent 優化？HeyGen 揀咗 Agent，你呢？
當AI開始寫影片代碼，React反而變咗個包袱
HeyGen最近開源咗一個叫HyperFrames嘅項目，用嚟做「代碼生成影片」。
有人喺推特下面留言：「「呢個咪係Remotion嘅wrapper囉？」」
HeyGen嘅回應好乾脆：唔係。HyperFrames係由零開始砌出嚟，專為AI Agent設計嘅。
呢件事本身冇乜稀奇。稀奇嘅係佢背後嗰個判斷——「當影片嘅「作者」由人類程式員變成AI Agent，底層技術揀邊個最好可能要徹底反轉。」
今日傾下呢個判斷，同埋佢對所有做AI+內容生成嘅團隊代表啲乜。
先講下Remotion做啱咗啲乜
一定要認，Remotion係個好項目。
佢證明咗一件事：「用代碼編排影片係可行嘅，headless Chrome可以作為一個確定性嘅影片渲染器。」 五年生產級打磨，Lambda分佈式渲染做到超大規模，React生態嘅類型安全、IDE補全、組件重用樣樣齊。
HeyGen自己喺生產環境入面用咗Remotion好幾個月。佢哋唔係「用唔到Remotion所以自己造轆」嘅情況，而係用到盡，發現咗個天花板。
呢個天花板，唔係喺Remotion嘅工程質量，而係喺佢嘅底層假設。
一個核心分歧：React vs HTML
Remotion揀咗React做影片嘅編寫界面。你寫React組件，就係喺度寫影片。
HyperFrames揀咗HTML。你寫HTML頁面，就係喺度寫影片。
睇落只係「框架揀邊個」嘅分別。但呢一個決定，牽一髮而動全身。
「點解？因為而家寫影片代碼嘅，越嚟越唔係人。」
第一個後果：Agent嘅創意天花板
LLM嘅訓練數據裏便，HTML、CSS、JavaScript佔咗好大比例——25年嘅互聯網累積，CodePen上面成千上萬嘅動畫案例，所有瀏覽器渲染到嘅嘢。
React呢？React喺訓練數據裏便梗係有，但同整個Web相比，佢係一個子集——而且係一個有大量「框架規則」嘅子集。
HeyGen做過對比評測。叫同一個LLM分別寫Remotion組合同HyperFrames組合：
「寫Remotion嗰陣」，Agent花咗大量token喺學框架規則——邊啲hook用得，邊啲API唔俾用，項目點樣搭建。出嚟嘅視覺效果傾向收斂：置中標題，常見轉場，常規排版。 「寫HTML+GSAP嗰陣」，同一個Agent嘅創意範圍明顯闊好多。因為佢嘅訓練數據裏便，呢種組合嘅花樣實在太多。
「一句講曬：React對人類程式員係增效工具，對AI Agent係認知負擔。」
第二個後果：動畫庫嘅時鐘衝突
呢個係一個好具體、好致命嘅技術問題。
GSAP、Anime.js、Motion One呢啲動畫庫，個個都有自己嘅內部時鐘，用 performance.now() 驅動。Remotion嘅渲染模式係逐幀渲染——佢跟住自己嘅節奏一幀一幀捕獲畫面。
問題嚟喇：「GSAP嘅時鐘喺「真實時間」入面行，Remotion喺「幀序列」入面行。兩個時鐘唔同步。」
HeyGen做咗一個直觀嘅對比實驗。同一段GSAP動畫——「HYPERFRAMES」11個字母依次飛入、停留1.5秒、然後旋轉跌低，總時長4秒：
「HyperFrames輸出」：完整4秒，字母逐個飛入，完整停留，逐個跌低。動畫忠實還原。 「Remotion輸出」：GSAP喺大約1秒嘅真實時間入面跑曬全部4秒動畫。Remotion只嚟得切捕獲開頭幾幀同大量黑畫面。
原因好清楚：HyperFrames會暫停GSAP嘅時鐘，將佢手動seek到 frame / fps 嘅位置再截幀，動畫庫同渲染器鎖步前進。Remotion冇呢個原語。
呢個意味住 「GSAP 15年累積嘅所有功能——SplitText、ScrollTrigger、MotionPath、物理動畫——喺HyperFrames裏邊直接用得，喺Remotion裏邊要痛苦嘅適配。」
第三個後果：可編輯性嘅天然差異
HyperFrames仲做咗另一個架構判斷：「用同一份代碼，同時做渲染層同數據層。」
咩意思？你見到嘅DOM就係你編輯嘅DOM。撳一個元素就可以揀中佢，拖拽就可以改位置，屬性面板直接改屬性。渲染器同編輯器共享同一個事實來源。
呢個喺HTML入面係自然嘅——HTML本來就係一種同時形容「生咩樣」同「係咩」嘅語言。
喺React入面就唔同喇。React嘅事實來源係代碼加埋構建步驟。你喺可視化編輯器入面改咗一個元素嘅位置，要將呢個改動「翻譯」返JSX，重新編譯。呢個來迴路徑又長又脆弱。
Paper.Design同Pencil揀HTML做可編輯源，都係同一個原因。
Remotion仍然領先嘅地方
公平啲講，Remotion喺兩個方面有明確優勢：
「分佈式渲染」：Remotion Lambda可以將長影片分拆到數百個AWS Lambda函數上面並行渲染。呢個能力成熟、經過生產驗證。HyperFrames目前只能單機渲染，分佈式喺roadmap上面但未做到。
「React生態重用」：如果你嘅團隊已經有一套React設計系統，Remotion俾你用同一套組件做影片。類型安全、IDE補全、跨文件重構，React帶嚟嘅工程體驗係真實嘅。
真正嘅問題
表面睇，呢個係一個「React vs HTML」嘅技術揀邊個之爭。
但係諗深一層，佢其實係答緊一個更根本嘅問題：「當內容嘅創作者由人類變成AI Agent，我哋需要重新審視邊啲「理所當然」嘅技術決策？」
React係為人類程式員設計嘅。組件化、類型安全、狀態管理——呢啲都係為咗幫人類管理複雜度。但AI Agent嘅「複雜度瓶頸」唔係呢度。Agent嘅瓶頸在於：佢嘅輸出空間有幾大，佢嘅表達自由度有幾高，佢需要學幾多「框架規則」先開始工作。
從呢個角度睇，「HTML嘅優勢唔係因為佢更「先進」，而係因為佢更「基礎」。」 佢係瀏覽器嘅母語，亦係LLM訓練數據裏面最深嗰口井。
HyperFrames揀咗Apache 2.0開源，Remotion係商業授權（3人以下免費，之後每次渲染 100）。呢個差異喺開源生態同社區貢獻層面都會產生長期影響。
對你嘅意義
如果你正在搭建AI影片生成嘅pipeline，或者做緊任何「令Agent生成視覺內容」嘅工作，呢個案例值得仔細研究。
核心啟示唔係「用HyperFrames取代Remotion」——兩者各有適用場景。核心啟示係：
「喺Agent-first嘅世界入面，「對人類友好」同「對Agent友好」可能係兩個方向。揀為邊個優化，會決定你個系統嘅天花板。」
HeyGen揀咗Agent。你呢？
❝原文連結：https://x.com/liu8in/status/2046337462604279828
❞
當 AI 開始寫視頻代碼，React 反而成了包袱
HeyGen 最近開源了一個叫 HyperFrames 的項目，用來做"代碼生成視頻"。
有人在推特下面評論：「"這不就是 Remotion 的 wrapper 嗎？"」
HeyGen 的回應很乾脆：不是。HyperFrames 是從零開始構建的，專門為 AI Agent 設計。
這件事本身不稀奇。稀奇的是它背後的那個判斷——「當視頻的"作者"從人類程序員變成 AI Agent，底層技術選型的最優解可能要徹底翻轉。」
今天聊聊這個判斷，以及它對所有做 AI + 內容生成的團隊意味着什麼。
先說 Remotion 做對了什麼
必須承認，Remotion 是個好項目。
它證明了一件事：「用代碼編排視頻是可行的，headless Chrome 可以作為一個確定性的視頻渲染器。」 五年生產級打磨，Lambda 分佈式渲染做到了超大規模，React 生態的類型安全、IDE 補全、組件複用一應俱全。
HeyGen 自己在生產環境裏用了 Remotion 好幾個月。他們不是"用不好 Remotion 所以自己造輪子"的情況，而是用到了極限，發現了天花板。
這個天花板，不在 Remotion 的工程質量，而在它的底層假設。
一個核心分歧：React vs HTML
Remotion 選擇 React 作為視頻的編寫界面。你寫 React 組件，就是在寫視頻。
HyperFrames 選擇 HTML。你寫 HTML 頁面，就是在寫視頻。
看起來只是"框架選型"的區別。但這一個決定，牽一髮而動全身。
「為什麼？因為現在寫視頻代碼的，越來越不是人了。」
第一個後果：Agent 的創意天花板
LLM 的訓練數據裏，HTML、CSS、JavaScript 佔了巨量比例——25年的互聯網積累，CodePen 上成千上萬的動畫案例，所有瀏覽器能渲染的東西。
React 呢？React 在訓練數據裏當然有，但和整個 Web 相比，它是一個子集——而且是一個有大量"框架規則"的子集。
HeyGen 做過對比評測。讓同一個 LLM 分別寫 Remotion 組合和 HyperFrames 組合：
「寫 Remotion 時」，Agent 花了大量 token 在學習框架規則——哪些 hook 能用，哪些 API 禁止，項目怎麼搭建。產出的視覺效果趨向於收斂：居中標題，常見轉場，常規排版。 「寫 HTML + GSAP 時」，同一個 Agent 的創意範圍明顯更寬。因為它的訓練數據裏，這種組合的花樣太多了。
「一句話總結：React 對人類程序員是增效工具，對 AI Agent 是認知負擔。」
第二個後果：動畫庫的時鐘衝突
這是一個很具體、很致命的技術問題。
GSAP、Anime.js、Motion One 這些動畫庫，都有自己的內部時鐘，用 performance.now() 驅動。Remotion 的渲染模式是逐幀渲染——它按自己的節奏一幀一幀捕獲畫面。
問題來了：「GSAP 的時鐘在"真實時間"裏跑，Remotion 在"幀序列"裏跑。兩個時鐘不同步。」
HeyGen 做了一個直觀的對比實驗。同一段 GSAP 動畫——"HYPERFRAMES"11個字母依次飛入、停留1.5秒、然後旋轉落下，總時長4秒：
「HyperFrames 輸出」：完整4秒，字母逐個飛入，完整停留，逐個落下。動畫忠實還原。 「Remotion 輸出」：GSAP 在大約1秒的真實時間內跑完了全部4秒動畫。Remotion 只來得及捕獲開頭幾幀和大量黑屏。
原因很清楚：HyperFrames 會暫停 GSAP 的時鐘，把它手動 seek 到 frame / fps 的位置再截幀，動畫庫和渲染器鎖步前進。Remotion 沒有這個原語。
這意味着 「GSAP 15年積累的所有功能——SplitText、ScrollTrigger、MotionPath、物理動畫——在 HyperFrames 裏直接可用，在 Remotion 裏需要痛苦的適配。」
第三個後果：可編輯性的天然差異
HyperFrames 還做了另一個架構判斷：「用同一份代碼，同時作為渲染層和數據層。」
什麼意思？你看到的 DOM 就是你編輯的 DOM。點擊一個元素就能選中它，拖拽就能改位置，屬性面板直接改屬性。渲染器和編輯器共享同一個事實來源。
這在 HTML 裏是自然的——HTML 本來就是一種同時描述"長什麼樣"和"是什麼"的語言。
在 React 裏就不一樣了。React 的事實來源是代碼加上構建步驟。你在可視化編輯器裏改了一個元素的位置，要把這個改動"翻譯"回 JSX，重新編譯。這個往返的路徑又長又脆弱。
Paper.Design 和 Pencil 選擇 HTML 作為可編輯源，也是同樣的原因。
Remotion 仍然領先的地方
公平地說，Remotion 在兩個方面有明確優勢：
「分佈式渲染」：Remotion Lambda 可以把長視頻分拆到數百個 AWS Lambda 函數上並行渲染。這個能力成熟、經過生產驗證。HyperFrames 目前只能單機渲染，分佈式在 roadmap 上但還沒做到。
「React 生態複用」：如果你的團隊已經有一套 React 設計系統，Remotion 讓你用同一套組件做視頻。類型安全、IDE 補全、跨文件重構，React 帶來的工程體驗是真實的。
真正的問題
表面上看，這是一個"React vs HTML"的技術選型之爭。
但往深一層想，它其實在回答一個更根本的問題：「當內容的創作者從人類變成 AI Agent，我們需要重新審視哪些"理所當然"的技術決策？」
React 是為人類程序員設計的。組件化、類型安全、狀態管理——這些都是為了幫助人類管理複雜度。但 AI Agent 的"複雜度瓶頸"不在這裏。Agent 的瓶頸在於：它的輸出空間有多大，它的表達自由度有多高，它需要學習多少"框架規則"才能開始工作。
從這個角度看，「HTML 的優勢不是因為它更"先進"，而是因為它更"基礎"。」 它是瀏覽器的母語，也是 LLM 訓練數據裏最深的那口井。
HyperFrames 選擇 Apache 2.0 開源，Remotion 是商業授權（3人以下免費，之後每次渲染 100）。這個差異在開源生態和社區貢獻層面也會產生長期影響。
對你的意義
如果你正在搭建 AI 視頻生成的 pipeline，或者在做任何"讓 Agent 生成視覺內容"的工作，這個案例值得仔細研究。
核心啓示不是"用 HyperFrames 替換 Remotion"——兩者各有適用場景。核心啓示是：
「在 Agent-first 的世界裏，"對人類友好"和"對 Agent 友好"可能是兩個方向。選擇為誰優化，會決定你的系統天花板。」
HeyGen 選了 Agent。你呢？
❝原文連結：https://x.com/liu8in/status/2046337462604279828
❞