HyperFrames 實作：讓 HTML 畫面跟上自己的旁白

我會開始研究 HTML 自動化簡報，不是因為我討厭做簡報，而是我發現內容一旦要變成影片，傳統投影片很快就會遇到另一組問題。

畫面什麼時候出現？一段旁白如果重錄，後面九個場景是不是都要重新拉時間？字幕、動畫與轉場有一處改動，能不能只修改那個場景，而不是再靠記憶把整份簡報拖一次？

我看過別人用多個 AI 分工完成腳本、畫面、配音與合成之後，真正吸引我的不是「全自動」三個字，而是那套流程有明確鷹架。每個階段知道自己要交什麼，錯誤也能被定位。於是我選擇用 HyperFrames 走 HTML 路線：把簡報當成可以被程式檢查與逐格渲染的場景，而不只是十張各自獨立的圖片。

這是「AI 影片製作」系列的畫面篇。另一篇聲音克隆實作：讓自己的聲音成為影片旁白，談的是本人錄音、台灣腔、模型選擇與配音。兩篇使用同一個「兩分鐘法則」案例：那篇把聲音準備好，這篇接著處理畫面如何跟上它。HyperFrames 和語音模型都是第三方工具，我分享的是自己的整合與修正歷程。

先看目的、成果與證據邊界

我參考的不是某個畫面，而是一套製作順序

最初研究 AI 影片流程時，我整理出的順序是：先完成腳本，再審查；確定內容值得做之後，才進入簡報、生圖、配音、字幕與合成。

這個順序對我很重要。語音生成要花時間，圖像與動畫也可能需要反覆調整。如果腳本還沒站穩，就直接投入後面的製作，最後不是自動化，而是自動產生更多要重做的東西。

因此我把流程拆成兩個層次：

1. 內容閘門：題目、觀點、逐字稿與引用先確認。
2. 製作管線：HTML 場景、聲音、字幕與影片輸出才開始工作。

HTML 自動化簡報屬於第二層。它不替我決定內容，也不能救一篇沒有觀點的稿子；它負責的是，當內容已經確認後，如何讓畫面與聲音更可控。

為什麼用 HTML，而不是直接請 AI 生十張圖？

如果只看第一版速度，生成十張圖片很有吸引力。但教學與說明型內容經常包含標題、數字、流程、引用與段落關係。這些元素若全部藏在點陣圖裡，文字改一個字、顏色換一層、動畫慢半秒，都可能需要重新生成整張。

HTML 的價值不是比較「高科技」，而是它本來就擅長處理文字、版面與狀態：

• 標題與內文仍是可修改的文字。
• 場景可以用資料與時間碼排列。
• 動畫可以在同一條時間軸上重播。
• 每個畫面能用相同設計規則，又保留個別構圖。
• 渲染前可以檢查場景是否重疊或缺少必要資訊。

HyperFrames 的官方說明把它描述為以 HTML 定義、逐格確定性輸出的影片框架。對我而言，這正好把「寫網頁」的可修改性，帶到「做簡報影片」裡。

第一版看起來能跑，後面兩幕卻對不上

「兩分鐘法則」是這條路線真正接受考驗的地方。

這個作品拆成 10 段旁白與 10 個主要場景。當時 HTML 使用的時間碼來自一份 63.64 秒的旁白 JSON，但實際合併完成的 VoxCPM 音檔只有 56.544 秒。只看每一段的文字與畫面，沒有明顯錯誤；真正播放時，前面一點點時間差累積到後面，S9、S10 就開始跟不上聲音。

這種錯誤很像傳統簡報排練時會遇到的問題：每一頁只差一點，最後一頁卻差很多。差別是，既然整套流程已經是程式化的，我不應該再憑耳朵手動拖曳每一幕。

真正的修正：時間必須相信音檔，不是相信腳本

最後的修正不是再猜一組時間，而是重建時間的資料來源。

聲音端如何從模型試聽走到分段旁白，可以接著看聲音篇的 VoxCPM 實作。對 HyperFrames 這一端來說，交接的重點不是模型訓練完成，而是拿到聽過、內容確認過的實際音檔，再用它們決定每一幕的長度。

1. 重新合併 10 段 vox2_s*.wav，得到 58.88 秒的新旁白。
2. 用 ffprobe 量測每個 clip 的實際長度。
3. 依累積時間重新計算 HTML 場景的開始與結束。
4. 在背靠背場景之間保留 0.01 秒，避免浮點計算形成重疊警告。
5. 重新 lint、渲染，再用完整影片確認最後兩幕。

最後輸出是 58.9 秒、4.0 MB，lint 沒有重疊警告。我確認這一版一次到位。

這次最有價值的成果並不是那支不到一分鐘的影片，而是一條後來可以重複使用的規則：

影片場景的時間，必須由實際輸出的音檔決定，不能沿用腳本預估或上一版 JSON。

HTML 簡報不是只有「一份 index.html」

實際能運作的專案，需要的不只是畫面檔案。以這次流程來說，至少包含：

逐字稿
→ 分段旁白
→ 實際音檔長度
→ HTML scene 時間碼
→ 動畫與轉場
→ lint
→ HyperFrames 渲染
→ MP4 完整播放確認

本機也保留了 HTML composition、HyperFrames 設定、各段音檔與多次渲染版本。這些檔案看起來比一個「生成影片」按鈕繁瑣，卻讓我可以回答：是哪一段聲音變了、哪一個場景跟不上、上一版和這一版究竟差在哪裡。

自動化如果沒有留下這些中間證據，只是把人工黑箱換成 AI 黑箱。

AI 在這條流程裡適合做什麼？

AI 很適合處理大量規則明確、又容易漏掉的小事：

• 依腳本拆場景與整理畫面需求。
• 建立 HTML 結構與一致的設計 token。
• 把實際音檔長度換算成場景時間。
• 檢查重疊、缺漏與格式問題。
• 在改稿後重建受影響的場景。

但有幾個決定仍然需要我負責：這個主題值不值得做、哪一段才是觀點、畫面是否太像模板，以及聲音和節奏是不是我願意公開的樣子。

我不想把 AI 內容製作理解成「人退出」。我更想要的是，人不用每次重新做相同的排版與對時，能把時間留給內容判斷。

哪些部分現在還不能稱為完成？

早期規劃曾包含多代理自動發想、固定週期選題、審稿、生成、通知與發布。這些方向仍有價值，但不能因為一支影片成功輸出，就說整條內容工廠已經完成。

目前真正通過的，是這個較小但重要的閉環：

已確認腳本 → 分段語音 → HTML 場景 → 依真實音檔重新計時 → lint → 成功輸出 → 本人觀看確認。

至於題目由誰決定、引用如何查證、視覺是否需要實拍或授權素材、成品是否公開，仍然有各自的人工閘門。

這套方法適合什麼內容？

我認為 HTML 簡報最適合：

• 文字、數字與結構關係很重要的教學影片。
• 會反覆修稿或重錄旁白的內容。
• 需要系列化視覺，但不想每集都長得完全一樣。
• 希望保留來源檔與可追溯修改紀錄的製作流程。

如果作品完全依賴寫實人物、電影感鏡頭或高度隨機的視覺，HTML 不一定是唯一主角；它也可以只負責標題卡、圖表、字幕與段落轉場。

我最後得到的不是一鍵出片，而是一條能除錯的管線

我一開始被「AI 可以自動做影片」吸引，真正做完一輪後，留下來的價值卻更務實。

我現在知道，簡報畫面可以像程式一樣重建；旁白重錄之後，時間軸不必再靠感覺重拉；輸出失敗時，也能追到音檔、場景或渲染哪一層出了問題。

這離完全自動化還有距離，但它已經比「每次從空白投影片重新開始」更接近我想要的工作方式。

工具資料與延伸閱讀

• 同系列・聲音篇：聲音克隆實作，讓自己的聲音成為影片旁白
• HyperFrames 官方介紹：以 HTML 定義並逐格渲染影片
• HyperFrames GitHub：HTML composition、lint、preview 與 render 工作流

商標與專案說明：HyperFrames、VoxCPM、FFmpeg 為其各自專案或權利人的名稱。本文記錄的是 Litas 如何把第三方工具組合成個人流程，不代表與上述專案有合作或官方關係。