HeyGen 為什麼放棄 Remotion，重寫了一個更適合 AI Agent 的視頻引擎

呢個唔係套咗層殼嘅 Remotion 咩？

有人喺評論區拋出呢句說話。我明點解會咁諗，但答案係否定嘅。

Remotion 真係好用。佢將「用代碼描述影片」變成可行嘅事，證明 headless Chrome 係可以當一個幀級確定性嘅渲染器嚟行。我哋喺生產環境用咗幾個月，從來冇諗過要換咗佢。

直到 AI Agent 開始寫代碼。

俾大模型嚟寫 Remotion 合成影片，輸出結果令人失望：置中標題，普通轉場，死板排版，好似有人套咗個模咁。要整返好需要大量約束同提示詞，而且好多時都係爭啲。

我用咗一段時間先諗通，問題唔係喺模型，而係喺框架。

Remotion 係 React 優先嘅。Agent 要先將大量 token 花喺學框架規則上面，邊啲 hook 用得，邊啲 API 唔得，項目結構點樣搭。等到佢終於可以發揮創意，已經用曬大半精力。

仲有一個更棘手嘅問題：GSAP、Anime.js、Motion One 呢啲有自己內部時鐘嘅動畫庫，同 React 嘅逐幀渲染係天然衝突。想用現成嘅 GSAP 動畫，就要翻譯成 React 組件，翻譯過程中細節大量流失。

呢堵牆越嚟越高。我哋開始認真討論：由頭嚟過。

用 HTML，唔用 React

我哋最終揀 HTML 嘅理由講起上嚟並唔複雜。

Web 係大模型訓練量最大嘅媒介。HTML、CSS、JavaScript、CodePen 上面 25 年嘅 GSAP 動畫，呢個係模型訓練數據入面最深嗰口井，React 生態喺裏面只係一個細切片。同樣嘅模型，直接寫 HTML 加 GSAP，創意範圍會闊好多，因為佢唔需要先翻譯，唔需要先學規則。

另一個原因嚟自編輯器。我哋希望同一份代碼同時係渲染層同數據層。整可視化編輯器嗰陣，呢點好關鍵：DOM 係你渲染嘅，亦係你編輯嘅，係同一個嘢。點選、拖動、即時預覽，喺 HTML 上面實現好順手。

Remotion 嘅數據源係 JSON，透過構建工具鏈轉成 React 代碼。改一個元素要兜一個大圈先可以寫返去，脆弱、慢、容易出錯。Paper.Design 一早揀咗 HTML 做可編輯源，道理係一樣嘅。

HyperFrames 就係喺呢兩個前提下設計嘅。

一個具體嘅測試

剩係講理由唔夠直觀。我哋俾 Remotion 同 HyperFrames 同樣嘅任務：一段 4 秒嘅 GSAP 時間軸，"HYPERFRAMES" 11 個字母錯開出場、back-out 緩動、停低 1.5 秒、然後旋轉跌落。動畫代碼一模一樣，唯一改變嘅係渲染器。

HyperFrames 嘅結果係動畫應有嘅樣：四秒用完，字母一個個飛入，停留約一秒半，旋轉跌落。

Remotion 嘅結果：成個動畫喺渲染第一秒內就跑完咗，之後 Remotion 捕捉到嘅係 GSAP 已經結束、字母都退場後嘅空舞台，大部分輸出係黑幀。

原因唔複雜：GSAP 靠 performance.now() 驅動時間軸，渲染時以即時速度行，唔等渲染器。HyperFrames 喺每幀捕捉前先暫停 GSAP，將佢 seek 到 frame / fps，令庫同渲染器同步。Remotion 冇呢個機制。

呢個唔只係 GSAP 嘅問題。Anime.js、Motion One，以及任何有自己時鐘嘅動畫庫，喺 Remotion 裏面都會遇到同樣嘅困境。

Remotion 真係贏喺邊度

講完 HyperFrames 嘅優勢，都要講清楚 Remotion 贏喺邊度，如果唔係呢篇文冇意義。

React 組件重用。 團隊已經有嘅設計系統組件，可以直接拎嚟合成影片，類型安全、IDE 補全、跨檔案重構都有。對深度押注 React 嘅團隊，呢個係實實在在嘅優勢。

分佈式渲染。 Remotion Lambda 將長影片拆俾幾百個 AWS Lambda 並行行，成熟、有生產驗證、文檔完善。HyperFrames 目前行喺單機上，分佈式渲染仲喺路線圖裏面。呢一項 Remotion 明顯領先，唔係短時間追得上嘅。

HyperFrames 喺呢兩點上而家唔同佢競爭。

HyperFrames 嘅另外幾個設計

除咗前面講嘅，仲有幾個值得提嘅地方。

任意 HTML 就係合成素材。落地頁、設計系統文檔、CodePen embed，貼入嚟就可以渲染，唔需要改寫成 JSX，翻譯步驟消失咗。

兩種捕獲模式自動切換。BeginFrame 模式（Linux + chrome-headless-shell）原子驅動 Chrome 合成器，跨機器逐字節可重現；截圖模式（macOS、Windows）作為自動回退，同 Remotion 方案一致。渲染器編譯時檢測組合入面嘅原語，發現 BeginFrame 處理唔到就降級，同時俾診斷信息。實際行落嚟，GSAP、Lottie、Three.js 都喺 BeginFrame 模式下確定性渲染，canvas 循環同 iframe 嵌入自動行截圖模式。

可視化編輯器。HyperFrames Studio 喺 live iframe 裏面預覽合成，點選元素、拖動定位、屬性面板即時改，編輯器同渲染器共用同一個 DOM，冇重編譯。呢個功能仲喺開發中，會持續開源。

授權方面，HyperFrames 係 Apache 2.0，Remotion 係商業授權，3 人以下免費，之後按次計費（$0.01/次，最低 $100/月）。

最後講一點

Remotion 同 HyperFrames 嘅根本差異得一個：React 定係 HTML。但呢一個選擇，的確會拉出好多分支。

我哋揀 HTML 唔係因為佢喺所有維度上都贏咗，而係喺 AI Agent 生成影片呢個場景下，佢更自然、更快、更少出錯。如果你嘅團隊深度喺 React，或者需要超大規模分佈式渲染，Remotion 係更成熟嘅選擇，呢個冇乜好迴避嘅。

HeyGen 將 HyperFrames 開源出嚟，係因為呢條路一個人行唔完。如果你喺做 AI 影片或者代碼轉影片嘅流水線，值得自己判斷一下。

"這不就是套了層殼的 Remotion 嗎？"

有人在評論區扔出這句話。我理解為什麼會這麼想，但答案是否定的。

Remotion 確實好用。它把"用代碼描述視頻"做成了可行的事，證明 headless Chrome 可以當一個幀級確定性的渲染器跑。我們在生產環境用了好幾個月，從來沒有動過要換掉它的念頭。

直到 AI Agent 開始寫代碼。

讓大模型來寫 Remotion 合成視頻，輸出結果讓人失望：居中標題，常規轉場，死板排版，像是有人套了個模子。拉上來需要堆大量約束和提示詞，而且往往還是差點意思。

我花了一段時間才想清楚，問題不在模型，在框架。

Remotion 是 React 優先的。Agent 得先把大量 token 花在學框架規則上，哪些 hook 能用，哪些 API 不行，項目結構怎麼搭。等它終於能發揮創意，已經耗盡了大半精力。

還有一個更硬的問題：GSAP、Anime.js、Motion One 這些有自己內部時鐘的動畫庫，和 React 的逐幀渲染天然衝突。想用現成的 GSAP 動畫，就得翻譯成 React 組件，翻譯過程中細節大量丟失。

這堵牆越來越高。我們開始認真討論：從頭重來。

做 HTML，不做 React

我們最終選 HTML 的理由說起來並不複雜。

Web 是大模型訓練量最大的媒介。HTML、CSS、JavaScript、CodePen 上 25 年的 GSAP 動畫，這是模型訓練數據裏最深的那口井，React 生態在裏面只是一個小切片。同樣的模型，直接寫 HTML 加 GSAP，創意範圍要寬得多，因為它不需要先翻譯，不需要先學規則。

另一個原因來自編輯器。我們希望同一份代碼既是渲染層，也是數據層。構建可視化編輯器時，這一點很關鍵：DOM 是你渲染的，也是你編輯的，是同一個東西。點選、拖動、實時預覽，在 HTML 上實現很順手。

Remotion 的數據源是 JSON，通過構建工具鏈轉成 React 代碼。改一個元素要繞一大圈才能寫回去，脆、慢、容易出錯。Paper.Design 早就選了 HTML 當可編輯源，道理是一樣的。

HyperFrames 就是在這兩個前提下設計的。

一個具體的測試

光說理由還不夠直觀。我們給 Remotion 和 HyperFrames 同樣的任務：一段 4 秒的 GSAP 時間軸，"HYPERFRAMES" 11 個字母錯開出場、back-out 緩動、停住 1.5 秒、然後旋轉墜落。動畫代碼一模一樣，唯一改變的是渲染器。

HyperFrames 的結果是動畫該有的樣子：四秒用完，字母一個個飛入，停留約一秒半，旋轉落下。

Remotion 的結果：整個動畫在渲染第一秒內就跑完了，之後 Remotion 捕捉到的是 GSAP 已經結束、字母都退場後的空舞台，大部分輸出是黑幀。

原因不復雜：GSAP 靠 performance.now() 驅動時間軸，渲染時以實時速度走，不等渲染器。HyperFrames 在每幀捕捉前先暫停 GSAP，把它 seek 到 frame / fps，讓庫和渲染器同步。Remotion 沒有這個機制。

這不只是 GSAP 的問題。Anime.js、Motion One，以及任何有自己時鐘的動畫庫，在 Remotion 裏都會遇到同樣的困境。

Remotion 真實贏在哪裏

說完 HyperFrames 的優勢，也得說清楚 Remotion 贏在哪裏，不然這篇文章沒意義。

React 組件複用。 團隊已有的設計系統組件，可以直接拿來合成視頻，類型安全、IDE 補全、跨文件重構都有。對深度押注 React 的團隊，這是實實在在的優勢。

分佈式渲染。 Remotion Lambda 把長視頻拆給幾百個 AWS Lambda 並行跑，成熟、有生產驗證、文檔完善。HyperFrames 目前跑在單機上，分佈式渲染還在路線圖裏。這一項 Remotion 明顯領先，不是短時間能追上的。

HyperFrames 在這兩點上現在不與之競爭。

HyperFrames 的另外幾個設計

除了前面說的，還有幾個值得提的地方。

任意 HTML 即合成素材。落地頁、設計系統文檔、CodePen embed，粘進來就能渲染，不需要改寫成 JSX，翻譯步驟消失了。

兩種捕獲模式自動切換。BeginFrame 模式（Linux + chrome-headless-shell）原子驅動 Chrome 合成器，跨機器逐字節可復現；截圖模式（macOS、Windows）作為自動回退，和 Remotion 方案一致。渲染器編譯時檢測組合裏的原語，發現 BeginFrame 處理不了就降級，同時給診斷信息。實際跑下來，GSAP、Lottie、Three.js 都在 BeginFrame 模式下確定性渲染，canvas 循環和 iframe 嵌入自動走截圖模式。

可視化編輯器。HyperFrames Studio 在 live iframe 裏預覽合成，點選元素、拖動定位、屬性面板實時改，編輯器和渲染器共用同一個 DOM，沒有重編譯。這個功能還在開發中，會持續開源。

授權上，HyperFrames 是 Apache 2.0，Remotion 是商業授權，3 人以下免費，之後按次計費（$0.01/次，最低 $100/月）。

最後說一點

Remotion 和 HyperFrames 的根本差異只有一個：React 還是 HTML。但這一個選擇，確實會拉出很多分叉。

我們選 HTML 不是因為它在所有維度上都贏了，而是在 AI Agent 生成視頻這個場景下，它更自然、更快、更少出錯。如果你的團隊深度在 React，或者需要超大規模分佈式渲染，Remotion 是更成熟的選擇，這沒什麼好迴避的。

HeyGen 把 HyperFrames 開源出來，是因為這條路一個人走不完。如果你在做 AI 視頻或者代碼轉視頻的流水線，值得自己判斷一下。