之前我花了很長一段時間，研究怎麼讓 Codex 從產品資料開始，一路做到銷售頁、圖片、Variant、HTML、ZIP，最後真的放上 cPanel。

我原本覺得：「這套 AI 自動化已經很有意思了。」結果沒多久，我又開始想另一件事。

如果 Codex 可以自動做網頁，那它能不能連影片也一起做？

而且我想的不是：輸入一句 Prompt，讓 AI 隨便生一支影片。

我真正想要的是：我只準備一段自己的錄音，接下來讓系統自動處理字幕、畫面、動畫與輸出。

因為我平常本來就有很多知識型內容。有些是 15 秒、有些是 20 秒，如果每一支都要：聽錄音、手動打字幕、切時間、做 PPT、找圖片、做動畫，再剪成影片。

做一支還好，如果未來要做 10 支、50 支、100 支，這個工作量就很可怕，所以這一次，我開始測試：Codex ＋ HyperFrames。

目標很單純：一段 MP3 錄音進去，最後得到一支可以直接看的 MP4 知識短片。

我最開始準備的東西，其實只有一段錄音

這次最早測試的音檔，就是：tina-test.mp3


以前如果拿到一段錄音，我腦袋裡的流程大概是：先匯入剪映、辨識字幕、找素材，再手動決定每一段畫面放什麼，字幕哪裡太長，再一條一條切，最後慢慢調動畫。

但我這次想測的是：這些事情，可不可以先交給 Codex 規劃？

Codex 和 HyperFrames 到底怎麼分工？

這也是我一開始最容易混亂的地方。

我原本會把它們都想成：「做影片的工具。」後來才發現，它們的角色其實不一樣。

工具	我現在的理解
Codex	像導演＋企劃＋工程師，負責理解需求、拆段落、安排畫面、修改程式與流程
HyperFrames	像影片排版與動畫引擎，把文字、圖片、字幕、音訊與動畫按照時間軸組合起來

所以我現在不會說：「HyperFrames 幫我想影片。」

比較接近的是：Codex 先決定影片應該怎麼做，再讓 HyperFrames 把這套設計真正動起來。

第一步：先把錄音變成可以理解的文字與時間

只有 MP3，其實還不夠。

因為系統如果只知道：「這裡有一段 15 秒聲音。」

它還不知道：第 1 秒講什麼、第 4 秒講什麼，哪一句應該出現在畫面上，哪裡該換畫面。

所以第一個重要步驟，就是：Transcription，也就是把錄音轉成文字。

更重要的是：文字最好還要有時間資訊。

這樣後面才有辦法把：字幕、動畫、圖片、重點字，跟聲音同步。

我後來發現：字幕不是「有辨識出來」就結束

這是這次實作中很重要的一課。

第一次做的時候，字幕其實有、內容也大致對，可是我一看成品就覺得：字幕的位置太高了。

因為畫面上方本來已經有 PPT 式的知識卡，字幕又跑到中下方，結果上下內容一直搶畫面。

所以後來我的要求就變得很具體：字幕要更貼底。

讓上面留給：標題、圖片、知識卡、動畫，下面則固定保留給字幕。

第二個字幕問題：不要一次把兩行字全丟出來

後來做到更多影片，我又發現另外一個問題。

有些口播一句比較長，系統會一次顯示：兩行字幕。

雖然沒有錯，但短影音上看起來會比較像：「一整塊文字突然出現。」，閱讀壓力就比較大。

所以後來我們又調整成：一句一句出現，而不是一大段全部一起放上去，這其實是一個很小的修改，但觀看感受差很多。

所以字幕本身也需要一套規則

我現在如果整理這套字幕規則，大概會是：

項目	我希望的做法
位置	靠畫面底部，不和主要內容重疊
出現方式	依口播一句一句出現
長度	不要一次塞太多文字
同步	跟著實際錄音時間走
字體	整支影片統一
可讀性	背景複雜時仍然要看得清楚

我以前會把字幕想成：影片最後再加上去的東西。

現在反而覺得：字幕其實就是影片版面的一部分。

第二步：Codex 把口播拆成 Scene

有了逐字稿之後，下一件事情就是：這 15 秒到底要怎麼切？

如果我的影片規格是：5 秒＋5 秒＋5 秒，那可以先切成：

Scene 01：0–5 秒
Scene 02：5–10 秒
Scene 03：10–15 秒

如果是 20 秒版本，也可以切成四段，但真正重要的不是硬切秒數。

而是：每一段要有一個明確任務。

例如：

• • 第一段：提出問題。
  • 第二段：解釋觀念。
  • 第三段：給方法。

或者：

• • 第一段：Hook。
  • 第二段：核心知識。
  • 第三段：結論／CTA。

錄音決定時間，內容決定畫面

我現在很喜歡用這句話理解整套流程。錄音決定「什麼時候」，內容決定「畫面放什麼」。

例如錄音講到：「很多人以為，做短影片一定要先拍大量素材。」

這時畫面可以出現：相機、手機、素材資料夾。

「大量拍攝？」的大字。

接著口播：「其實一段錄音，也可以先成為影片的骨架。」

畫面就可以換成：MP3、波形、字幕、箭頭、Scene Timeline，這就是 Codex 開始扮演「導演」的地方。

第三步：不是做 PPT，而是先建立 Visual Story

第一次生成之後，我其實有一個很強烈的感覺：「這看起來很像有動畫的 PPT。」

它不能說不能看，字也有、字幕也有、背景也有、東西會飛進來。

但就是：不像真正的短影片。這讓我後來開始重新思考一件事情。

影片不是：把 PPT 裡面的元素加動畫。

而是：讓每一秒的視覺都在幫口播說故事。

「有動畫」和「有影片感」是不一樣的

例如一張知識卡：標題飛進來、圖示飛進來、三個 bullet 一個一個出現，這確實有動畫。

但如果 15 秒全部都只是：卡片、標題、圖示、文字，最後還是 PPT 感。

真正比較像短片的做法，還需要加入：畫面層次、攝影式構圖、插畫、視覺焦點切換、局部放大、遮罩、重點 Highlight、元素之間的前後景。

這也是後來為什麼我們又開始往：Illustrated Storytelling 和 Layered Motion Graphics 繼續走。

HyperFrames 真正好用的地方：畫面不是「剪」出來，而是「排」出來

這一點和我以前用剪輯軟體的思考很不一樣。

以前剪片，我是把：影片 A、影片 B、圖片 C、字幕，全部丟進時間軸，然後剪。

HyperFrames 的思考方式比較接近：先設計一個畫面，再讓這個畫面按照時間發生變化。

例如一個 Scene 裡面，可以有：背景、圖片、標題、重點字、圖示、字幕、裝飾線。

每一個都有自己的位置和時間。

然後再決定：0.2 秒標題進場、0.5 秒插畫放大、1.1 秒重點字亮起、2.5 秒這組元素淡出、下一組進場。

這就是我第一次比較清楚感受到：HTML 也可以變成影片的舞台。

第四步：先把「最漂亮的靜態畫面」排好，再做動畫

這個觀念我覺得非常值得記下來。

因為一開始很容易犯一個錯：看到影片就急著做動畫，標題從左邊飛進來，圖片從下面彈出來，圖示旋轉，字幕淡入。

結果全部動畫做完才發現：標題和圖片疊在一起、字幕壓到人物、手機版安全區被吃掉。

所以比較好的順序應該是：

1. 1. 先找每一個 Scene 最完整、最好看的 Hero Frame
   2. 把所有元素放到最終正確位置
   3. 先確認靜態畫面漂亮
   4. 再決定它們從哪裡進來
   5. 最後才加離場與轉場

簡單說：先把畫面做好，再讓它動。

第五步：圖片不能只是裝飾，而要跟口播有關

這也是我後來一直修改的地方。

如果口播在講：「一段錄音可以自動生成影片。」

畫面卻只放一張漂亮女生坐在咖啡廳，雖然漂亮，但沒有幫助理解。

比較好的畫面可能是：一個音訊波形、一個 MP3 檔案、箭頭連到字幕、再連到 Scene，最後變成影片畫面。

這時觀眾不只是在「看美圖」，而是在：看懂內容。

所以我現在會把影片素材分成三種

素材類型	主要用途
主敘事畫面	直接表達這一段在講什麼
輔助圖像	補充概念，例如圖示、流程、簡圖
裝飾元素	增加節奏、層次與視覺質感

這三者如果混在一起，畫面就容易很吵，所以每一個 Scene 最好都要先問：這一秒真正的主角是誰？

第六步：讓字幕、主畫面和動畫各司其職

做到後來，我覺得一支知識短片其實有三個資訊層。

第一層：聲音：真正完整的內容在錄音裡。

第二層：字幕：幫助沒開聲音的人，也能知道正在說什麼。

第三層：視覺：負責把重要概念變得更好懂、更有記憶點。

如果三層全部在講一模一樣的字，就浪費了。

例如口播是：「先把錄音轉成逐字稿，再依語意切成三個 Scene。」字幕可以完整顯示這句話。

但主畫面不需要再打一次一模一樣的大字。

主畫面可以直接做：

MP3
↓
Transcript
↓
Scene 01 / Scene 02 / Scene 03

這樣三層資訊才是在合作。

我原本想要的 15 秒版本，其實很適合拿來測試

因為 15 秒夠短，錯了容易看，重做也比較快。我們一開始就用：5 秒＋5 秒＋5 秒 來測。

例如：

時間	內容角色
0–5 秒	Hook／問題
5–10 秒	知識重點
10–15 秒	答案／結論／CTA

這種架構簡單。

但是非常適合用來測：字幕、動畫、版面、節奏、圖片、轉場。

如果 15 秒都不好看，做 60 秒只會把問題放大

這也是我後來很深的感覺。

如果一支 15 秒影片：字幕就已經太高、卡片很無聊、動畫很像 PPT、圖片沒有故事性，那把它延長成 60 秒，不會突然變精彩，反而會讓觀眾看四倍時間的無聊。

所以短版其實是一個很好的：Workflow 壓力測試。

第七步：Lint、Inspect、Preview，不要每改一次就直接 Render Final

這是開始做自動化之後很實際的一件事情。

以前我會有一種衝動：改完了、直接輸出。

結果 Render 完才發現：字幕被裁到、某一個字超出框、動畫重疊、圖片蓋住標題，又得重來。

比較合理的流程應該是：

1. 1. 先檢查程式與時間軸
   2. 再檢查文字有沒有超出畫面
   3. Preview 看實際節奏
   4. 確認之後才 Render

我現在會把它理解成：影片版的 Final QA。

Render 也不應該第一次就用最高品質

因為影片還在修改階段時，真正需要知道的是：時間對不對、字幕對不對、畫面有沒有撞、節奏順不順，這時先做測試輸出就夠了，等整支都確定，再做 Final Render。

這和前面銷售頁的邏輯其實一模一樣。

不是一開始就追求：最高品質，而是先確定：方向正確。

我後來最常改的，其實不是內容，而是「觀看感受」

這一點很有意思，原始錄音沒有變、口播也沒有變、字幕文字大致沒有變。

可是影片卻從 v1、v2、v3，一路一直改。

改的是：字幕位置、字幕出現方式、圖片大小、畫面層次、卡片比例、動畫速度、轉場、重點字。

這讓我又想起第 15 篇的網站。

AI 很快可以做到：能用，但是要做到：好看、好讀、願意看下去，還是需要反覆修。

「自動做影片」並不是完全不看成品

這是我覺得一定要寫進筆記的一點。

自動化很容易讓人以為：按一個按鈕、全部完成、不用再看。

但我現在比較不會這樣理解。

真正有價值的自動化，是：把大量重複工作先做掉。

例如：建立專案、讀取音檔、轉字幕、切 Scene、放字幕、建立基本動畫、輸出測試片，這些讓電腦做。

我最後比較需要看的，是：好不好看？有沒有重點？字幕舒服嗎？這個畫面我自己會想看嗎？

所以真正省下來的，是「機械工作」

以前我要把很多時間花在：複製、貼上、對時間、拉字幕、調位置、輸出。

現在如果前面流程建立好，這些工作可以先自動完成。

人的時間則留給：判斷。這件事我覺得比「AI 全部取代我」有意義得多。

我現在心中的錄音轉短片工作流

如果把目前做過的事情濃縮成最簡單的流程，我會寫成：

錄音 MP3
↓
Transcription
↓
取得字幕與時間資訊
↓
Codex 分析內容
↓
切 Scene
↓
決定每段重點
↓
安排圖片／知識卡／插畫
↓
HyperFrames 建立畫面
↓
字幕同步
↓
加入動畫與轉場
↓
Lint / Inspect
↓
Preview
↓
修改
↓
Render
↓
MP4

如果再往後，就還能加入：AI 生圖、Layered Motion Graphics、數字人、批次處理，甚至一次處理很多支影片。

這套流程真正有價值的地方，是它可以被重複

做一支影片，其實不值得花這麼多力氣建立系統，手動做可能還比較快。

但如果未來是：10 支、30 支、100 支，這時候差別就出來了。

只要規則先建立：字幕固定位置、影片固定尺寸、字體固定、動畫語言固定、Scene 結構固定、素材規則固定，下一次換錄音，就不需要全部重新想。

這時候它才真正開始變成 Skill

前面第 4～7 篇，我已經開始接觸 Skill。

那時我理解的是：把一套做事方式封裝起來，現在做到影片這裡，感覺更明顯。

如果我把：錄音輸入格式、字幕規則、Scene 切法、字體、位置、動畫、輸出方式，全部定義好。

未來我真正需要做的，可能就只是：「把新的 MP3 放進資料夾。」接著讓流程往下走。

但做到這裡，我還是不滿意

因為影片雖然已經可以：從錄音開始、自動有字幕、自動有畫面、自動有動畫、也可以輸出 MP4。

可是我還是一直覺得：少了一個人。

尤其知識型影片，如果畫面上只有：PPT、插畫、字幕，看久了還是容易覺得距離有點遠。

所以我後來又想到：如果左下角放一個小小的講師視窗呢？

真人不想露臉，那可不可以用 AI 講師？

錄音已經有了，我也已經有講師圖片，那能不能把這個 AI 講師變成會說話的數字人，再跟 HyperFrames 的動畫畫面結合？這就變成下一個新的問題。

Tina學姐這次最大的體會：錄音其實可以成為影片的「主時間軸」

以前我一直覺得，做影片最先需要的東西是：影片素材、照片、分鏡。

但這一次的實驗讓我發現：對知識型影片來說，起點也可以完全不同。

可以先只有：聲音。

因為聲音裡本來就有：內容、語氣、長度、節奏、停頓，只要把這些資訊拆出來，畫面其實可以再往上長。

錄音不是最後配上影片的聲音，它可以反過來成為整支知識短片的骨架。

我覺得這是我這次測 Codex＋HyperFrames 最大的收穫。

寫在最後：從「剪影片」變成「建立影片系統」

如果只是看最後成果，這可能就是一支 15 秒短片。

但我現在越做越覺得，真正有意思的不是這支影片本身，而是背後這條流程。

以前：我做一支影片、下一支再重新做一次。

現在我想的是：先把「怎麼做一支影片」這件事情變成系統，以後再把新的錄音丟進去。

這和前面 Tina-Sales-Page-Generator 其實是一樣的邏輯。

不是一直叫 AI：「再做一個。」

而是先建立：可以一直重複的工作方法。

我覺得 Codex 真正開始變得有趣，就是從這裡開始。