AI APPLICATION · LITAS

現成工具應用

我把簡報改寫成 HTML：自動化最難的不是生成，而是讓畫面真的跟上聲音

把 HTML 場景、VoxCPM 旁白與真實音檔長度接成可查錯、可重做的簡報影片流程。

作者：Litas

個人自行研究並與 AI 協作實作｜無贊助、無聯盟連結｜文中工具均為第三方工具

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

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

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

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

項目	目前結論
目的	把腳本、場景、動畫、旁白與時間軸變成可修改、可檢查、可重複輸出的內容流程，降低每次重錄後人工重排整份簡報的成本。
已驗證成果	「兩分鐘法則」實作已把 10 段 VoxCPM 音檔重新量測並接回 HTML 場景，成功輸出 58.9 秒、4.0 MB 的影片；lint 沒有場景重疊警告，我也確認該版一次到位。
證據邊界	這證明一個真實專案可以跑完，不代表選題、腳本、視覺與發布都已無人化。多代理選題、固定排程與成品通知仍有規劃內容，不能寫成現成系統。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

重新合併 10 段 vox2_s*.wav，得到 58.88 秒的新旁白。
用 ffprobe 量測每個 clip 的實際長度。
依累積時間重新計算 HTML 場景的开始與結束。
在背靠背場景之間保留 0.01 秒，避免浮點計算形成重疊警告。
重新 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、VoxCPM、FFmpeg 為其各自專案或權利人的名稱。本文記錄的是 Litas 如何把第三方工具組合成個人流程，不代表與上述專案有合作或官方關係。