HyperFrames：用 HTML 與可跳轉動畫，打造給 AI coding agent 的確定性影片渲染框架

如果要讓 AI coding agent 產生影片，真正困難的地方通常不是「能不能呼叫一個生成模型」，而是如何把時間軸、素材、動畫、音訊與輸出品質組合成可以重跑、可以檢查、也可以放進 CI 的工程流程。HeyGen 開源的 HyperFrames 選擇了一條很直接的路：用一般前端熟悉的 HTML、CSS 與 JavaScript 描述畫面，再由 headless Chrome 逐幀取樣，最後交給 FFmpeg 編碼成 MP4。

這個設計的重點，不是把影片包裝成另一種神祕的時間軸格式，而是讓「網頁組合」成為影片組合。對 AI coding agent 而言，HTML 是容易產生、容易檢查、也容易交接的介面；對工程團隊而言，固定的 frame seeking 則能讓預覽、測試與正式輸出使用同一套時間模型。

本文依據 repository 在 2026 年 9 月 15 日查證到的 HEAD edf6e4b373528501f4f80284d3ce2d0e1e09fbe4、@hyperframes/cli 0.8.41 package metadata，以及官方 README 撰寫。功能與 CLI 介面仍可能隨後續版本變更。

先講結論：HyperFrames 解決的是「可重現的影片程式設計」

HyperFrames 不是單純的影片剪輯器，也不是只提供幾個動畫元件的前端函式庫。它把影片製作拆成幾個可以由程式描述的層次：

使用 HTML 元素定義畫面與素材。
使用 data-start、data-duration、data-track-index 等資料屬性描述時間與軌道。
使用 GSAP、CSS、Lottie、Three.js、Anime.js、WAAPI 或自訂 adapter 控制可 seek 的動畫。
透過 CLI 執行初始化、lint、檢查、預覽與渲染。
由 headless Chrome 逐幀定位畫面，再用 FFmpeg 輸出 MP4。

因此它的核心主張是「相同輸入得到相同影格與相同輸出」，而不是依賴播放當下的 wall-clock 狀態。這對自動化內容管線尤其重要：當影片是由 agent 產生時，我們需要知道哪個 HTML、哪組素材與哪個時間設定造成某一幀，而不是只能重新播放一次看看結果。

為什麼選 HTML，而不是再做一套時間軸 DSL？

傳統影片工具常把時間軸藏在專用編輯器、JSON schema 或複雜的 React abstraction 裡。這些方式各有優點，但對 agent handoff 會增加額外成本：agent 必須先理解框架的 component API，才能修改一個標題位置或插入一段影片。

HyperFrames 的選擇比較像「把瀏覽器當成合成引擎」。一個最小的 composition 可以是普通的 index.html：

<div
  id="stage"
  data-composition-id="launch"
  data-start="0"
  data-width="1920"
  data-height="1080"
>
  <video
    class="clip"
    data-start="0"
    data-duration="6"
    data-track-index="0"
    src="intro.mp4"
    muted
    playsinline
  ></video>

  <h1
    id="title"
    class="clip"
    data-start="1"
    data-duration="4"
    data-track-index="1"
  >Launch day</h1>
</div>

這段標記同時具備三種價值。第一，它是瀏覽器可以理解的文件，不必先經過 React bundler 才能看到結果。第二，時間資訊直接貼在元素上，agent 或人類讀 code 時可以從元素本身理解它何時出現。第三，HTML、CSS 與媒體檔案能被一般的 lint、diff、review 與版本控制工具處理。

這並不代表 HyperFrames 只能做靜態 HTML。官方範例使用 GSAP timeline，並把 timeline 掛到 window.__timelines，讓 renderer 在指定影格時可以把動畫定位到正確狀態：

const tl = gsap.timeline({ paused: true });
tl.from("#title", { opacity: 0, y: 40, duration: 0.8 }, 1);

window.__timelines = window.__timelines || {};
window.__timelines.launch = tl;

關鍵字是 paused 與 seekable。若動畫只依賴真實時間流逝，就可能在不同機器或不同負載下得到不同影格；若 renderer 能把 timeline 定位到指定時間，則預覽與輸出才有機會保持一致。

從「會動」到「能渲染」：CLI 生產循環

HyperFrames 的 CLI package 名稱是 @hyperframes/cli，發布的 binary 叫做 hyperframes。官方 README 將它定位成建立、預覽、lint、檢查與渲染 HTML video composition 的工具，並提供一個非互動的工作流，這很適合接在 agent 產生檔案之後。

最小流程如下：

npx hyperframes init my-video
cd my-video
npx hyperframes preview
npx hyperframes render

實際使用時，可以把流程理解成四個檢查點。

1. Init：建立可執行的 composition

先讓 CLI 產生基本結構，再由 agent 修改 HTML、CSS、素材引用與動畫。這種方式比要求 agent 從空目錄自行猜測所有檔案名稱安全，因為初始結構提供了明確的入口與預期的執行方式。

2. Lint 與 check：先抓結構問題

在進入昂貴的渲染前，先檢查 HTML composition、時間屬性、素材引用與框架契約。對自動化流程來說，lint 不是可有可無的美化工作，而是把「渲染到一半才發現格式不對」提前成快速失敗。

3. Preview：用瀏覽器確認視覺結果

Preview 讓開發者先在瀏覽器看到畫面、動畫與素材是否按照預期運作。由於 composition 本身就是 HTML，這個步驟不需要先匯出低畫質影片才能檢查基本佈局。

4. Render：逐幀產生最終檔案

正式渲染時，HyperFrames 以 headless Chrome 對每一幀進行 seek，再使用 FFmpeg 編碼。這個架構把瀏覽器負責的事情限制在「產生畫面」，把影片封裝與編碼交給成熟的媒體工具；也讓同一份 composition 可以在本機、Docker 或分散式 render path 中使用。

Agent skills 不只是 prompt 範例

HyperFrames 的另一個特色，是 repository 同時提供給 AI coding agent 使用的 skills。官方 README 將 /hyperframes 描述為 router 與 capability map，並列出 product launch video、faceless explainer、PR-to-video、embedded captions、motion graphics、music-to-video、slideshow、general video 等工作流。

這裡的價值不只是「多一個 prompt」。一個好的 agent skill 應該把領域知識轉成操作順序，例如：

先確認創作 brief 與輸出類型。
選擇適合的 composition workflow。
讀取 core contract，理解 timing、track 與 media 規則。
寫出 HTML 與動畫。
執行 lint、preview、snapshot 或 render。
遇到外部素材時，保留可追蹤的來源與檔案。

這種 router 加 domain skill 的分層，讓 agent 不必每次都載入全部文件，也降低把「製作簡報」與「輸出 MP4」混成同一條流程的機會。對團隊而言，skills 也可以成為 code review 的共同語言：審查者不只看畫面漂不漂亮，還能檢查 composition 是否走過正確的製作循環。

Catalog 與可重用視覺元件

除了手寫 HTML，HyperFrames 也提供 catalog。官方文件示範可以用 CLI 加入 shader transition、Instagram overlay 或 animated chart：

npx hyperframes add flash-through-white
npx hyperframes add instagram-follow
npx hyperframes add data-chart

這個設計將「從零發明每個效果」改成「選擇已定義的視覺積木」。當積木本身有文件、範例與固定輸入契約時，agent 只需要決定何時使用它，而不是同時負責設計效果、處理時間軸與修正瀏覽器相容性。

對內容平台來說，可重用 catalog 也代表更容易建立品牌規範。團隊可以先批准一組 transition、title card、chart 與 caption component，再讓 agent 在受控的元件集合中組合新影片。

適合哪些場景？

HyperFrames 特別適合以下幾種工作：

將產品頁、功能介紹或 release note 轉成短影片。
把 GitHub pull request 轉成 changelog 或 feature walkthrough。
建立資料視覺化、chart race、地圖動畫與流程圖影片。
產生帶有 kinetic typography、caption、overlay 與音樂的社群影片。
將文件、PDF 或網站內容轉成 explainer。
把可重用 motion graphic 接到 CI 或內容發布管線。

共同點是：畫面不是一次性剪輯，而是可以用檔案、程式與素材清單描述的輸出。若你的需求是手動拖曳時間軸、精細修剪真人素材，專業 NLE 仍然更合適；若需求是讓 agent 大量產生可審查、可重跑的程式化影片，HyperFrames 的模型就很有吸引力。

與 Remotion 的差異：不是誰取代誰

HyperFrames 官方文件明確表示它受到 Remotion 啟發，兩者都使用 headless Chrome 與 FFmpeg。主要差異在 authoring model：Remotion 以 React component 為核心；HyperFrames 則押注 plain HTML、CSS 與 seekable animation。

這個差異會影響團隊選型：

| 面向 | HyperFrames | Remotion |

|---|---|---|

| 撰寫方式 | HTML、CSS 與可 seek 動畫 | React components |

| Build step | index.html 可直接預覽 | 通常需要 bundler |

| Agent handoff | 一般 HTML 檔案 | JSX／React 專案 |

| 動畫模型 | 透過 adapter 對齊 frame | 依 React 與時間控制模式實作 |

如果團隊已經有成熟的 React video stack，Remotion 可能仍是更自然的選擇；如果希望讓不同 agent、前端工程師與設計師都能以接近網頁的方式編輯 composition，HyperFrames 的 HTML-native 路線則更容易降低入門成本。

依賴與部署現實

截至查證版本，@hyperframes/cli 要求 Node.js >=22，並依賴 Puppeteer、Sharp、Hono、FFmpeg 相關能力；官方 README 也列出本機需要 Node.js 22+ 與 FFmpeg。這意味著它不是「裝一個 npm package 就不必管理執行環境」的工具，部署前要先處理瀏覽器與編碼器的可用性。

建議把環境檢查放在 pipeline 開頭：

node --version
ffmpeg -version
npx hyperframes doctor

若要在 CI 使用，應固定 Node.js major version、鎖定 package lock，並對輸出的影格或影片 metadata 建立驗證。若要在服務端執行，則要評估 headless Chrome 的 sandbox、字型、GPU／CPU 資源與暫存空間。若影片包含外部字型或遠端媒體，最好在渲染前下載並固定版本，避免網路內容改變造成輸出漂移。

官方 README 也列出 Docker、AWS Lambda 與 GCP Cloud Run 等部署方向。這些選項適合把渲染從開發者筆電移到工作佇列或 CI，但不能省略資源估算：影片長度、解析度、影格率、字型載入與媒體解碼都會影響成本與執行時間。

一條可落地的 agent pipeline

如果要把 HyperFrames 接到自己的 AI 內容系統，可以從下列流程開始：

Agent 讀取 brief，產生 storyboard.md 與素材清單。
Agent 根據固定的 design tokens 建立 index.html。
將圖片、影片、音訊與字型複製到版本化的 assets 目錄。
使用 timing data attributes 定義出入場、軌道與 composition 尺寸。
使用一種 animation adapter 實作可 seek 的動畫，避免混用未受控的 wall-clock effect。
執行 lint、check 與 preview，先修正結構錯誤。
產生 snapshot 或低成本預覽，交給人類做視覺 approval。
通過 approval 後才執行正式 render，並保存 commit、素材 hash、CLI version 與輸出 metadata。
將 MP4、縮圖與 manifest 一起送到內容儲存或發布系統。

這樣的流程把 agent 的創作自由放在「內容與組合」，把工程可靠性放在「契約、檢查與可重現輸出」。兩者不是互相衝突，而是應該分層處理。

常見問題與排查順序

預覽可以播放，但正式輸出缺少素材

先確認素材引用是本機可讀取的路徑，而不是只在某個開發伺服器上存在的 URL。把圖片、影片、音訊與字型放進 composition 的 assets 目錄，並在 render 前執行檔案存在性檢查。若素材來自網路，應先下載到固定目錄，再把來源、下載時間與版本記錄在 manifest；不要讓正式渲染依賴一個會變動的遠端檔案。

動畫在預覽正常，逐幀輸出卻跳動

這通常與沒有正確處理 seek 有關。檢查動畫是否使用 window.__timelines 或對應的 adapter，並確認 timeline 是 paused、可以被定位到指定時間，而不是只在 requestAnimationFrame 或真實時間流逝時更新。也要避免把隨機值、目前時間或未固定的網路資料直接放進畫面；如果確實需要隨機效果，先產生固定 seed 或把結果寫入 composition。

找不到瀏覽器或 FFmpeg

HyperFrames 的 renderer 需要 headless Chrome，輸出編碼則依賴 FFmpeg。先執行 node --version、ffmpeg -version 與 npx hyperframes doctor，確認 Node.js major version、瀏覽器下載位置、FFmpeg PATH、暫存目錄權限與可用磁碟空間。CI container 要特別檢查字型與 Linux sandbox 設定，因為本機能運作不代表最小化 container 也具備相同系統套件。

字型、音訊或字幕在 CI 與本機不同

不要只依賴作業系統預裝字型；把必要字型與字幕輸入列為版本化資產。音訊則要確認取樣率、聲道與音量處理在所有 runner 一致。若使用遠端資產，將它改成在 pipeline 開始時下載並驗證 checksum。最後用 snapshot、影格抽樣、影片 metadata 與音訊軌檢查做最小回歸測試，而不是只比較檔案是否成功產生。

Render 很慢或記憶體不足

先降低預覽解析度或影片長度，確認 composition 與素材沒有無限增長的 DOM、過大的圖片或未釋放的媒體資源，再決定是否升級 runner。正式環境可把渲染放入工作佇列，限制同時執行數，並保存每次 render 的耗時、影格數、解析度與失敗原因。若採用 AWS Lambda 或 GCP Cloud Run，還要額外測量 cold start、暫存空間、封裝大小與長影片的逾時風險。

最後的判斷

HyperFrames 值得注意，不只是因為它把 HTML 拿來做影片，而是它同時處理了三個 AI 影片工具常被分開處理的問題：agent 如何產生內容、composition 如何表達時間、以及輸出如何被重跑與驗證。HTML-native authoring 降低了 agent handoff 的門檻；frame seeking 與 FFmpeg pipeline 提供工程上的確定性；CLI、skills 與 catalog 則把一次性的 demo 推向可重用工作流。

它仍然需要 Node.js、FFmpeg、headless browser 與合理的素材管理，也不會取代需要人工剪輯判斷的專業後製。但對「讓 coding agent 產生大量、可審查、可回歸測試的程式化影片」這個問題，HyperFrames 提供了一個相當清楚的開源答案。