餵小說給 AI，自動生成短劇說漫：這套 AI 漫劇流水線終於有點樣子了

這篇是一次短影音產線的工作筆記。

我這次想做的不是「先做一堆圖,再想辦法硬配音」,而是反過來:先把故事變成能聽的旁白,再讓畫面去服務旁白。素材來自小說劇情,目標是產出 9:16 直式短影音,有旁白、有字幕、有分鏡,最後還要有 contact sheet 可以檢查。

以前我常覺得 AI 影片流程最麻煩的是生圖或生影片。這次做完才發現,真正決定成片穩不穩的,是聲音和時間軸。旁白秒數先確定,畫面才知道自己該站在哪裡。

開場:為什麼要做這套流程

我想要的是一條能處理小說/劇情內容的短影音流程。

小說很長,情緒很多,角色也不只一個。如果直接丟給模型生圖,很容易得到一堆漂亮但不連貫的畫面;如果先切分鏡,又會卡在每格到底要多長、字幕要跟誰對齊、配音會不會比畫面長。

所以這次我把順序倒過來。

先讀小說或劇情,理解主線、角色關係和情緒轉折;再把它改寫成 250-300 字內的短影音旁白。這個字數不是文學最完整的版本,而是短影音能承受的密度:有鉤子,有轉折,有一點情緒,但不能塞到像朗讀全文。

核心原則:旁白先行,畫面第二

這條流程的核心原則很簡單:旁白先行,畫面第二。

旁白不是成片後面才補上的音軌,它是整支影片的骨架。我要先知道一段旁白實際講了幾秒,才能決定這段要一格畫面、兩格畫面,還是三格畫面。

所以我的流程不是:

圖片 → 分鏡 → 硬配音 → 字幕勉強對齊

而是:

旁白 → 旁白秒數 → 自然段落 → 分鏡數 → 畫面 → 字幕與聲音對齊

這樣做的好處是節奏比較自然。字幕跟逐句 TTS 對齊,畫面則跟自然旁白段對齊。觀眾聽到的是一句一句清楚的聲音,看到的是一段一段情緒完整的畫面。

實際流程

這次最後收斂成這條流程:

階段	產物	我檢查的事
小說/劇本	原始劇情理解	主線、角色、情緒轉折是否清楚
250-300 字口語旁白	可念的短影音稿	有沒有像人在說話,不是像摘要
TTS 句子	逐句旁白 JSON	每句不能太長,方便 GPT-SoVITS 穩定輸出
GPT-SoVITS 生成與量測	raw/trimmed audio	秒數、RMS、peak,確認不是有字幕沒聲音
自然旁白段	合併後的段落	聽起來像自然敘事,不是機械切片
分鏡數與 panel mapping	每段對應幾格畫面	依實際秒數決定格數
直接生成宮格圖	一張完整 contact-like grid	角色、服裝、光線、場景一致性
裁切 9:16 panels	每格直式畫面	每一格都強制 portrait frame
合成影片	聲音、字幕、畫面	字幕逐句對齊,畫面對自然段
contact sheet QA	總檢查圖	快速檢查分鏡順序與畫面節奏
final output	最終短影音	手機直式觀看是否成立

換成一行就是:

小說/劇本 → 250-300 字口語旁白 → TTS 句子 → GPT-SoVITS 生成與量測 → 自然旁白段 → 分鏡數與 panel mapping → 直接生成宮格圖 → 裁切 9:16 panels → 合成影片 → contact sheet QA → final output

分鏡節奏規則

這次我沒有先拍腦袋決定「要 13 格」。

我先讓 GPT-SoVITS 把逐句 TTS 做出來,量測每句秒數,再把句子合併成自然旁白段。所謂自然旁白段,不是照標點硬切,而是照觀眾聽起來的情緒單位切。

例如一段可能是「人物處境」,下一段才是「情緒反轉」。這兩段在文字上可能只差幾句,但聽覺上是不同 beat。

分鏡數就依這些自然段的實際秒數來決定:

• 很短的段落,一格畫面就夠。
• 中等段落,可以兩格畫面交替。
• 情緒或資訊量比較高的段落,才增加到三格。
• 不讓畫面太頻繁切,也不讓同一格停太久。

這樣做之後,畫面比較像是跟著旁白呼吸,而不是字幕在追畫面、畫面在追配音。

直接宮格生成與 9:16 裁切

這次比較關鍵的改法,是直接生成整張宮格分鏡圖,再裁切每一格。

以前如果每格分開生,角色很容易漂。服裝、髮型、光線、場景都會慢慢變掉。直接讓模型一次生成整張宮格,雖然單張控制難度比較高,但整體一致性反而更好。

做法是先把每個 panel 的畫面需求寫清楚,再一次生成整張 grid。生成後不是拿整張圖進影片,而是把每一格裁切出來,並且強制轉成 9:16 portrait frame。

這件事很重要。

短影音不是「把橫圖塞進手機」,也不是「用一張大圖在畫面裡滑」。每一格都要先被當成手機畫面來檢查:人物位置、字幕空間、主體大小、上下安全區都要能用。

GPT-SoVITS / 字幕 / 編碼 QA

這次踩最多坑的地方,不是分鏡,而是文字和聲音。

一開始我用中文經過 PowerShell inline / 命令列時,字幕和旁白文字會被轉成 ??? 或亂碼。這種錯很可怕,因為影片可能照樣輸出成功,但你最後看到的是一堆問號。

修正方式是:所有中文旁白與字幕,都先寫成乾淨的 UTF-8 JSON / ASS 檔,再由腳本讀檔處理。不要把中文硬塞進 PowerShell inline command,也不要讓命令列轉來轉去。

最終輸出前,我現在一定檢查:

• 字幕裡沒有 ???。
• 沒有 Unicode replacement character。
• JSON 是 UTF-8。
• ASS 是 UTF-8。
• final video 的字幕不是從亂碼檔燒進去的。

GPT-SoVITS 也有一個坑:某句可能有字幕,但沒聲音。

這不一定會在肉眼看 timeline 時立刻發現,因為字幕還在,畫面也在,但音訊那一句其實是空的。所以每句 TTS 生成後,我會檢查 raw / trimmed 音訊的秒數、RMS、peak。

如果秒數異常短、RMS 幾乎沒有、peak 太低,就不能直接放進合成。那句要重生,不然成片會出現「字幕在講話,聲音消失」的斷裂感。

ASS 字幕也踩了一個很細的坑。

我要微調字幕位置時,override tag 必須插在 Text 欄位裡,不可以插到 margin 欄位。插錯地方不一定會直接報錯,但字幕位置會跑偏,而且 debug 起來很煩。

這種小坑很不華麗,但它們就是自動化流程能不能穩定的差別。

這次的輸出結果

這次輸出的是 9:16 直式短影音,1080×1920、30fps,長度約 55 秒。

下載影片檔

第一幀 QA 封面:

Contact sheet:

這張 contact sheet 對我來說很重要。它不是拿來好看的,而是拿來快速檢查:

• 分鏡順序是不是符合旁白情緒。
• 人物和場景有沒有明顯漂移。
• 哪幾格可能太像、太空、太難讀。
• 字幕安全區是否可能擋住主體。
• final video 前有沒有需要重切 panel。

我會繼續改進的地方

這條流程已經可以出片,但還不是終點。

接下來我會想繼續改幾件事:

1. 讓旁白段落切分更自動,不要每次靠人工直覺修。
2. 把每句 TTS 的秒數、RMS、peak QA 報表做成更直覺的表格。
3. 讓 panel mapping 可以半自動產生,再由我只改少數不順的地方。
4. 針對 9:16 安全區做更嚴格的畫面檢查,避免字幕和臉撞在一起。
5. 把 contact sheet QA 做成固定流程,每次 final video 前一定輸出。

這次最大的收穫不是多做了一支影片,而是流程順序終於對了。

旁白先行,畫面第二。

聲音先穩,分鏡才穩;時間軸先穩,影片才不會像硬湊出來的。