用一台 8GB 筆電顯卡,搭一條 AI 影片生產線:實戰踩雷全記錄

一句話總結

用一台 RTX 5060 Laptop(8GB VRAM)的筆電,把「生圖 → 生影片 / 配音 → 上字幕 → 配樂 → 輸出 1080」整條 AI 影片流程在本地(加少量雲端訂閱)跑通,最後收斂成兩條能實際量產的生產線。這篇記錄的重點不是「成功」,而是中間踩過的十幾個雷、每個雷怎麼被誤判又被找出根因、以及最後的修法——這些才是真正花掉時間、也最值得留下來的東西。

為什麼要自己搭

市面上的 AI 影片服務(尤其 image-to-video)按秒計費,做長影片很貴:一支 10 分鐘的影片若全用付費 i2v,成本動輒幾十美金。目標很簡單:便宜、可量產、盡量本地化。於是把幾種引擎都試過一輪,最後留下兩條最划算的路。

工具棧

角色	工具	計費
生圖	Codex CLI 的 $imagegen(gpt-image-2)	ChatGPT 訂閱
生影片(對嘴口播)	Grok Build CLI 的 generate_video(i2v)	SuperGrok 訂閱內含點數
配音(一般)	edge-tts(微軟神經語音)	免費
配音(本人聲音)	GPT-SoVITS 本地克隆	免費(本地 GPU)
組裝/字幕/配樂	ffmpeg	免費
本地 i2v / 對嘴(評估後備案)	ComfyUI + WAN 2.2、MuseTalk	免費(本地 GPU)
全程膠水	PowerShell 包裝腳本	—

最後採用的兩條生產線

A. Grok 直幅口播(9:16,本人出鏡) 本人定場圖 → Grok i2v 生「對著鏡頭講話、原生對嘴」的短片 → 末幀接龍(每段用前一段最後一幀當起點)拼成一鏡到底 → 宋體置中字幕 → 強制 1080。適合「自己的臉、自己的聲音」的口播。

B. 圖 + Ken Burns 長片(16:9,無真人旁白) 每句旁白配一張 16:9 示意圖 → 緩慢推拉(Ken Burns)→ 克隆聲音旁白 → 宋體字幕 → 免版權配樂 → 1080。幾乎免費、長度無上限,是做長影片(健康/知識/故事頻道)的主力。一支 15 秒的成本約 $0,同樣長度的付費 i2v 要約 $0.75。

成果展示

A. 圖 + Ken Burns 長片(健康頻道・鉤子段)

從「揉眼睛的疲憊 → 晨起無神 → 一堆咖啡杯昏沉 → 深夜文件堆裡硬撐 → 靜下來望向窗外」——全是 AI 生的 16:9 示意圖,配克隆聲音旁白與宋體字幕,無真人、幾乎零成本。這 ~30 秒就是一支健康頻道長影片的開場長相。

上面是 ~30 秒的鉤子段;這支鉤子所屬的完整健康長片〈睡再多還是累?這可能是血癌警訊——醫師點名 5 個徵兆〉已上架 YouTube。點下圖看全片,就能看到同一條「圖 + Ken Burns」生產線從開場到收尾的完整長相:

B. Grok 直幅口播(本人出鏡、原生對嘴)

同一個人、同一個場景,11 段「末幀接龍」拼成一鏡到底,情緒從沉靜 → 衝刺 → 重燃,手勢逐段對應、字幕置中。這是「自己的臉、自己的聲音」的口播路線。

踩雷全記錄

以下每個雷的格式:症狀 → 一開始的誤判 → 真正根因 → 修法。會反覆出現的主題是:先診斷、再修;用證據驗證、不要用猜的。

雷 1:Grok CLI「自己遞迴呼叫自己」

• 症狀:用 CLI 自動生口播,一個晚上跑了 50 幾次、只成功 2 支,其餘全失敗。
• 誤判:以為是「Grok 服務當機 / server 時好時壞」,甚至去回退 CLI 版本。
• 真正根因:去讀 Grok agent 的對話記錄才發現——我把 grok 的工作目錄設在專案資料夾,agent(它本身是會用工具的 AI)list_dir 看到我的包裝腳本 grok-i2v.ps1,就自作聰明地用 shell 去「執行」這支腳本,而那支腳本又會呼叫 grok……形成遞迴空轉,根本沒呼叫到真正的生影片工具。
• 修法:讓 grok 在一個乾淨的 ASCII 暫存夾裡跑(裡面只放一張 src.png,沒有任何 .ps1 可以被它發現),提示詞改成強制「直接呼叫 generate_video,不要執行任何腳本」。換掉之後一次就出片、穩定可靠。
• 教訓:當「自動化工具」本身是一個 agent,不要把你的腳本暴露在它的工作目錄裡,它會去動它。

雷 2:PowerShell 5.1 + 中文,三種死法

PS 5.1 對非 ASCII 的處理是長期痛點,這次一口氣踩到三種:

1. .ps1 檔裡的中文「可執行碼」會壞:把中文標點寫進 regex(例如 -replace '[,、]'),PS 5.1 讀無 BOM 的 .ps1 時用系統 Big5 解碼 → regex 變亂碼 → 整段爆掉。(註解裡的中文無害,因為被忽略。)
2. [char] 比對中文標點會失敗:$arr -contains $cjkChar、$str.IndexOf([char]$cjkChar) 在這個情境下偵測不到中文逗號。
3. 命令字串裡的中文,背景執行時會被吃掉:把中文當參數塞進「行內命令」,背景跑時間歇亂碼。

• 統一修法:中文一律從 UTF-8 檔案讀(用 $PSScriptRoot 組路徑、[IO.File]::ReadAllText),絕不讓中文進到命令字串;標點偵測改用 String.Replace / String.Split(這個對中文可靠),或用碼點 [char]0xFF0C 表示;可執行碼保持純 ASCII。

雷 3:併發——兩個 session 搶同一個生圖後端

• 症狀:批次生圖時,codex 間歇回 exit -1,偶爾還生出一張 0×0 的壞圖,導致後續組裝失敗。
• 關鍵線索:輸出資料夾裡冒出一堆不是我生的檔案(essay-*.png)。
• 根因:另一個 session 同時也在用 codex 生圖,兩邊打同一個 ChatGPT 生圖後端、寫同一個輸出夾 → 後端搶資源(間歇失敗)+ 併發時回傳損毀的圖。不是管線的錯。
• 修法:(1) 守規矩——一次只跑一個生圖 session;(2) 防禦性程式——生成器加上自動重試 + 圖檔有效性驗證(ffprobe 讀到 0px 就丟棄重生),就算撞到併發也能自癒。
• 教訓:同一個帳號的多個 agent session 會互相干擾,這是用 AI 自動化時很容易忽略的系統性問題。

雷 4:字幕,改了五六次才對

字幕是反覆最多次的地方,把每個小雷都記下來:

• 字體:要的是「宋體」,正解是 SimSun;我先用成 PMingLiU(新細明體＝明體)、更早還用到微軟正黑——都不對。
• 「置中」的真義:口播片的「置中」是整個畫面正中央(ASS Alignment=5),不是「底部水平置中」。但 16:9 長片反而要放底部(中央會擋畫面)。同一個詞,兩種版型不同解。
• 爆框:長句在直幅(400px 寬)一行塞不下、被切掉。要自動斷行,而且「逗號斷完若單行仍太長,要再依字數均分」。
• 16:9 不該斷太碎:寬螢幕要用長句(在標點處斷、塞到字數上限才換行),不是每個逗號都硬斷。
• 最陰的一個——字幕「累加」:某次重構後,第 2 段字幕變成「第1段＋第2段」、第 3 段變成前三段全部。是迴圈裡的區域變數沒有真正重設(PowerShell 的 scope 坑)。修法:把斷行邏輯抽成「函式」,用函式作用域天然隔離,問題消失。

雷 5:Ken Burns 推拉一直抖

• 症狀:圖片緩慢 zoom in/out 時畫面在抖動。
• 根因:ffmpeg 的 zoompan 每一幀把裁切位置 x/y 四捨五入到整數像素,慢速縮放時理想位置是次像素移動、卻被迫在整數間跳 → 抖。
• 修法:把縮放改在一張放大過的大畫布(5760×3240)上算(而且只預縮一次、不是每幀),輸入像素大 3 倍 → 整數步進細到次像素以下 → 看不見抖動了。

雷 6:腳本健壯性的三個坑

• 子腳本的 exit 把整個流程殺掉:包裝腳本失敗時 exit -1,結果連同呼叫它的外層批次一起終止,害「重試」永遠沒生效。修法:用子行程(powershell -File)呼叫,它的 exit 只殺自己。
• 清理時誤刪資料檔:重試前用 Remove-Item "$Name.*" 清舊檔,萬用字元把台詞檔 .line.txt 也一起刪了。修法:只刪 .mp4,不碰文字檔。
• 沙箱誤擋:Remove-Item -Recurse -Force 含變數路徑時被安全沙箱誤判封鎖。修法:改用 [IO.File]::Delete 刪指定檔、或用時間戳判斷而不刪。

雷 7:合成配樂「很怪」→ 改用真的免版權音樂

• 症狀:用 ffmpeg 合成的環境 pad(純正弦波疊和弦)聽起來很假很怪。
• 修法:去抓真的免版權音樂。Pixabay(CC0、免署名、可商用)是最佳來源,但它擋自動下載(WebFetch/curl 回 403)。解法是用瀏覽器自動化:開 Pixabay → 點播放讓它載入 → 從頁面 <audio> 元素抓到 cdn.pixabay.com 的真檔網址 → 再用 Invoke-WebRequest 下載。
• 音量:母帶級的曲子當背景要壓很低,墊在人聲下約 -39dB(musicVolume ≈ 0.05)才不吵。

雷 8:計費判斷——別把訂閱搞混成按量付費

• 疑問:Grok 生影片到底是吃「SuperGrok 訂閱內含」還是「API 按量付費」?看到後台有「使用量 %」和「Invoiced Spending Limit」字樣,一度以為在燒按量付費。
• 查證:先查本機認證(OAuth、沒有任何 API key),但因為認證裡有 team_id、加上那些後台字眼,我一度誤判成 API 平台計費。最後靠後台截圖才確定:那是 grok.com 消費端的使用情況頁——「隨 SuperGrok 附贈的免費點數,每月 1 號重置」,當下只用了 21%,根本沒花到超額的錢。
• 結論 + 建議:CLI 影片吃的是訂閱內含的月免費點數池;只要去消費端設定「隨用隨付上限」(設 0 或小額),就連「萬一爆池」的風險都堵死。超額後 480p 6 秒約 $0.30/支。
• 教訓:金錢相關的判斷不要猜——查本機設定、看後台、用真實數字下結論。

雷 9:本地模型的現實——能跑 ≠ 能用

• 8GB 顯卡真的能跑 WAN 2.2 S2V-14B(音訊驅動對嘴),但 48 分鐘才出 3 秒,量產不可行。
• WAN TI2V-5B(無聲 i2v)速度可接受,但動態品質不佳。
• MuseTalk(本地對嘴)裝得起來、能動,但「不夠自然」。
• 結論:在這個硬體上,本地大模型目前只能當「特別需要本人聲音對嘴時」的備案;真正能量產的還是「Grok(雲端、便宜)」和「圖+Ken Burns(本地、幾乎免費)」這兩條。

雷 10:成片傳 LINE 會壞

• 同一支 1080 成片,傳 Telegram 正常,傳 LINE 卻顯示 30 幾分鐘、對嘴還會漂移。試過各種 remux 都沒用,最後判定是 LINE 的轉碼器問題。
• 修法:傳 LINE 時當「檔案」傳(不要當影片)、或改用 Telegram / 雲端連結。

工作方法 / 決策原則

把這次反覆驗證有效的做事方式抽出來:

1. 先診斷,再修:症狀像「服務當機」時,先去讀 log / agent 對話記錄找根因,而不是急著回退或重試(雷 1、雷 8 都是這樣才破案)。
2. 用證據驗證,不要用嘴講:對嘴準不準 → 抽幀比對;句間有沒有留白 → silencedetect;字體對不對 → 看 libass 的 fontselect log;圖壞沒壞 → ffprobe 讀尺寸。我看不到動態、聽不到聲音的部分,就老實交給使用者確認。
3. 失敗後把工具變健壯:每踩一個雷,就把腳本改成可續傳、會重試、有驗證,下次同類任務直接受惠。
4. 把「定案的慣例」寫進長期記憶:字幕樣式、計費模型、併發規則……寫進專案記憶,避免每次重新糾結、重複犯錯。
5. 成本/效益要會轉彎:本地 S2V 太慢 → 改 Grok;後來查清楚 Grok 其實吃免費池、不貴 → 放心用。判斷要跟著新證據走。

一些數字

• 一支 ~30 秒的 Ken Burns 長片片段,本地 render 約 37 秒(用了大畫布防抖的版本)。
• Grok 修好後,每段口播片 1 次就出片(之前要重試幾十次)。
• 16:9 長片成本 ≈ $0/分鐘(只吃 ChatGPT 訂閱生圖 + 免費 TTS + 免費 ffmpeg)。

結論

這條生產線真正的價值,不在某個「神工具」,而在把一堆會互相打架的免費/便宜工具,用一層健壯的膠水包起來——而那層膠水的厚度,幾乎全部來自上面這些雷。會踩雷不可怕,把每個雷的根因和修法留下來,下一支影片、下一個專案就會快很多。