前面第 16～21 篇，我一路從一段錄音開始，慢慢把整套 AI 知識短片工作流拆開。

錄音、逐字稿、字幕、Scene、Illustrated Storytelling、Layered Motion Graphics、AI Presenter、Preview、Final Render，甚至連 Codex 額度怎麼省，都開始研究了。

做到這裡，終於可以回到我前陣子看到、也一直很好奇的一句話：「Codex 一天可以做 100 支影片。」

第一次看到，我的反應其實也是：真的嗎？

因為我自己光是一支影片，就已經從 v1 修到 v4.1。字幕要改、畫面要改、PPT 感太重又要改、插畫做好之後還要拆 Layer、Presenter 還要另外處理，如果一支片都這麼多步驟，那一天 100 支到底怎麼做到？

做到現在，我覺得這個問題不能只回答可以，或者：不可以。

真正應該先問的是：「你說的 100 支，到底是哪一種 100 支？」

第一個問題：什麼叫「做完一支影片」？

這件事情比想像中重要。如果我說：AI 已經幫我輸出一個 MP4。那當然可以叫：完成一支影片。

可是這支影片可能：字幕還沒有檢查、圖片有錯、人物手指怪怪的、CTA 擋住字幕、音訊沒有對齊、甚至有某一幕根本沒載入，這種影片算不算「完成」？

如果只是：Render 出一個檔案 和 可以正式發布，其實是完全不同的標準。

所以「100 支」至少要先定義品質標準

所謂完成	實際代表
Draft	已經產生初版，可供檢查
Preview Ready	主要畫面、字幕、音訊已完成，可以預覽
QA Ready	等待最後品質檢查
Final Ready	已檢查、可直接正式發布

如果有人說：「一天生成 100 個 Draft。」和：「一天交付 100 個 FINAL READY。」難度差非常多。

第二個問題：100 支影片是不是都用同一套模板？

這是決定產量最重要的因素之一，假設我已經做好一個 15 秒模板。

固定：1080×1920、5 秒＋5 秒＋5 秒、字幕位置固定、字體固定、片頭固定、CTA 固定、轉場固定。

我現在只換：標題、三段口播、三張圖片、那這種影片非常適合大量化，因為真正需要改變的變數很少。

但是如果 100 支全部要長得完全不一樣，就不是同一回事

例如每一支都要：重新分析文案、重新設計 Storytelling、重新產 6～10 張插畫、重新拆 Layer、重新做 Motion、重新產 Presenter、再人工 QA。

那「100 支」代表的是完全不同等級的工作量。

所以我現在看到這種數字，第一個反應不再是：「哇，好厲害。」而是：「它重複使用了多少東西？」

真正的 Batch Mode，核心不是「做很多」，而是「很多東西不用再做」

這其實就是上一篇第 21 篇一路推導過來的結果。

如果每支影片都重新：建立專案、設定尺寸、決定字體、決定字幕位置、建立片頭、建立片尾、建立 Safe Zone、設定輸出格式。

那你只是：把手工作業做了 100 次。

真正的 Batch 應該是：這些東西早就已經 LOCK，每支影片只把新的變數填進去。

我現在理解的 Batch Mode，比較像「資料列」

例如我先準備：

ID	標題	錄音	素材資料夾	模板
EP001	為什麼總是拖延？	ep001.mp3	assets/ep001	knowledge-A
EP002	真正讓人累的不是工作	ep002.mp3	assets/ep002	knowledge-A
EP003	你不是沒時間	ep003.mp3	assets/ep003	knowledge-B

接下來系統不是問：「請做 EP001。」做完再：「請做 EP002。」

而是讀取一整批任務，然後按照相同規則處理，這才開始接近真正的 Batch。

Batch Mode 的概念，其實很像工廠生產線

如果一家工廠說：一天可以做 10,000 個產品。

並不是代表：10,000 個產品都由工程師重新設計一次。

而是：設計早就完成、模具早就完成、流程早就完成、規格早就完成、品管標準也完成。

真正每天做的只是：按照這套已經穩定的規格生產。AI 影片其實也是同一個道理。

所以「一天 100 支」最大的前提，是影片已經不是一個專案，而是一個產品

這是我自己做到現在很大的體會。

如果每一支影片都還需要我坐下來想：這一支用什麼字體？字幕放哪？第一幕長什麼樣？Presenter 多大？CTA 放哪？

那它仍然是：一支一支做的作品。

當這些規則都確定之後，它才開始變成：可以批次生產的影片產品。

以我現在的 Tina Product Video Autopilot 來說，就很適合用這個方向理解

我原本想做的事情就是：一張商品圖＋官方產品資料 → 自動想出 10 支不同廣告 → 生成素材 → HyperFrames 做動畫 → 輸出 MP4。

如果每次拿到一個產品，都重新手動叫 Codex：先寫第 1 支 → 再寫第 2 支 → 再做第 3 支 → 一直做到第 10 支。

那只是AI 幫忙操作，還不是真正的 Batch。

真正的 10 支 Batch，應該是一開始就建立 Variant Plan

例如：

影片	策略
AD01	Problem Hook
AD02	Lifestyle Scene
AD03	Product Focus
AD04	Question Hook
AD05	Before Situation
AD06	Single Big Idea
AD07	Educational
AD08	Scenario Switch
AD09	Benefit Story
AD10	CTA Driven

10 個任務一開始就定義，系統再一次往下處理。

這才是真正從「做一支影片」變成「執行一批影片任務」。

「一句話做 10 支」不代表 AI 只做了一個動作

這一點非常容易被誤會。假設未來我真的只需要說：「幫我把這個產品做成 10 支廣告。」

表面看起來是一句話，但背後可能其實發生：讀取產品資料 → 建立 Product DNA → 生成 10 個廣告策略 → 產生 10 份腳本 → 建立 Scene Plan → 產生圖片需求 → 生成素材 → 整理素材 → 建立 HyperFrames Composition → 加入字幕 → 加入 Motion → Preview → 自動 QA → 失敗重試 → Render → 輸出 10 個 MP4


所以 One Prompt 並不等於 One Step，它只是把很多步驟藏到工作流後面。

這也是「自動化」最容易產生錯覺的地方

使用者只看到：輸入一句話 → 等一下 → 10 支影片出現，就很容易覺得「Codex 一口氣生了 10 支影片。」

但是系統內部其實可能跑了幾十、甚至更多個獨立步驟。

真正厲害的地方不是步驟消失，而是人不用再一個一個操作。

那一天 100 支，到底有沒有可能？

我的答案現在會是：先看影片是哪一級。

影片類型	大量生產難度
固定模板＋換文字／圖片	最適合大量批次
固定模板＋不同 Scene	需要素材庫與自動選圖
AI 生圖＋基本 Motion	開始受到生圖與 QA 速度影響
Illustrated Storytelling	需要每支重新設計 Visual Event
完整 Layered Motion	素材與動畫結構複雜很多
數字人＋Layered Motion＋精修	還要加入第三方生成、同步與更多 QA

所以只說：「100 支影片。」其實沒有太大意義，更重要的是：100 支什麼影片？

一天產 100 個 Draft，和一天精修 100 支代表作，是兩件完全不同的事

這就跟寫文章一樣，AI 一天可以產生很多篇初稿，但如果每一篇都要：查資料、改 SEO、檢查事實、配圖、內鏈、重新編輯，那真正完成的速度就完全不同，影片也是。

而且 Batch 真正可怕的不是成功，而是失敗

假設一次跑 100 支，結果：95 支成功、5 支失敗。

這時真正成熟的系統不應該：100 支全部重跑。

而是：記錄哪 5 支失敗、失敗在哪個 Stage、然後只 Retry 那 5 支。

所以 Batch Mode 一定要有 Status

例如：

EP001  DONE
EP002  DONE
EP003  FAILED_IMAGE
EP004  DONE
EP005  FAILED_RENDER
EP006  DONE
...

只有這樣，大量生產才真的可管理。

最好連失敗原因都要寫清楚

例如：

FAILED_TRANSCRIPT
FAILED_ASSET
FAILED_PRESENTER
FAILED_LAYOUT
FAILED_RENDER
FAILED_QA

因為不同錯誤，處理方式完全不同，如果只是 Render 錯誤，就不需要重新生圖；圖片壞了，也不需要重新做 Transcript。

這和第 21 篇筆記說的：只重做出問題的地方，其實是一模一樣的概念。

Batch Mode 要成立，Retry 一定要先設計

這也是很多「自動做影片」展示很少會講的地方。

Demo 通常會展示成功的結果，但真正大量化之後一定會遇到：API Timeout、素材沒回來、圖片比例不對、字幕超框、音訊不存在、第三方服務失敗、Render 中斷，如果沒有 Retry 機制，Batch 跑得越大，人工反而越忙。

所以大量影片工作流至少需要三個結果

SUCCESS → 直接進下一步 → RETRY → 自動再試

NEEDS_REVIEW → 交給人工檢查

我覺得這比「一天 100 支」本身重要得多。

QA 也是 Batch Mode 最大的瓶頸之一

假設 100 支真的全部 Render 完成。接下來誰看？

如果每支 15 秒。我還是要：一支一支打開、看字幕、看圖片、看動畫、看 CTA，看有沒有出錯。

如果全部都由人工檢查，Render 可能已經不是最慢的地方。QA 才是。

所以真正的 Batch Mode 也要有自動 QA

例如可以自動檢查：

• • 影片檔案是否存在
  • 影片長度是否正確
  • 解析度是否正確
  • 字幕是否超出 Safe Zone
  • 音訊是否存在
  • 必要素材是否都有載入
  • 是否仍有 PLACEHOLDER
  • CTA 是否存在

這些屬於：Machine QA。先讓機器把最基本的錯誤擋掉，人最後只需要看：好不好看、有沒有怪、值不值得發布。

這樣人的工作才從「檢查 100 支」變成「處理異常」

理想狀況應該是：

100 支任務
↓
系統自動處理
↓
92 支 PASS
5 支 AUTO RETRY
3 支 NEEDS REVIEW
↓
人只看那 3 支

這時 Batch 才真正開始有價值。

Codex 的平行工作能力，也不等於所有事情都應該同時跑

這點我覺得也非常重要。有些工作可以平行。

例如：AD01 生圖、AD02 生圖、AD03 生圖，彼此互不依賴，這種就很適合一起跑。

但有些工作有順序。

例如：

先有 Transcript
↓
才能做 Caption Timing

先有 Scene Plan
↓
才知道需要哪些圖片

先有素材
↓
才能組 Composition

先有 Composition
↓
才能 Preview

所以 Batch 不是所有事情一次全部開始。而是可以平行的平行，有依賴關係的照順序。

我現在會把它想成 Pipeline，而不是一百個人在一起亂跑

例如：

Batch Input
↓
Script Queue
↓
Scene Queue
↓
Asset Queue
↓
Composition Queue
↓
Render Queue
↓
QA Queue
↓
Output

每一個 Stage 都可以有很多影片排隊。這比「開 100 個 Codex 視窗。」成熟很多。

真正限制產量的，往往是整條 Pipeline 裡最慢的那一站

假設：腳本很快、字幕很快、HTML 很快、但是 AI 生圖很慢，那最終產能就被生圖限制。

或者生圖很快，但是數字人每支都要等待，那 Presenter 就變成瓶頸。

再或者全部都很快，但 Render 很慢，那 Render Queue 就會越堆越長。

所以要談「一天 100 支」，其實應該先找 Bottleneck

也就是：瓶頸到底在哪？

可能是：Codex 額度、模型速度、生圖、第三方 API、HyperFrames Render、電腦硬體、網路、人工 QA，任何一個地方卡住，前面再快也沒有用。

這也讓我重新理解「並行」這件事情

如果每一個任務都完全依賴同一個資源，同時開更多任務，不一定真的比較快。

有時候只是：10 個人一起排同一台影印機。

真正有效的 Parallel，是：不同工作可以使用不同資源，同時進行。

如果未來我要真的測「一天 100 支」，我反而不會一開始就跑 100

我會先跑3 支，確認流程會不會壞，接著10 支，看 Retry、看額度、看 Render、看 QA。

再來30 支，看整個 Queue 能不能穩定，最後才有資格談100 支。

這就是我現在理解的 Batch Scaling

不是1 支成功，直接乘以 100。

而是：1 → 3 → 10 → 30 → 100


每一階段都先找：哪裡會壞、哪裡會塞車、哪裡需要人工、然後修好再放大。

否則只是把一個小問題複製 100 次

例如字幕位置錯 10px。

一支影片只是一個小問題，Batch 跑 100 支之後，100 支全部錯 10px。

這就是自動化最可怕也最有趣的地方。

好的規則，可以被放大 100 倍；錯的規則，也一樣。

所以 Batch 之前，模板一定要先跑到穩定

我現在甚至覺得：前面那些 v1 → v4.1 的反覆修改，根本不是浪費時間。

那是在做：Batch 前的校正、字幕位置要先定、Scene 結構要先定、Safe Zone 要先定、Motion 規則要先定、QA 規則要先定，否則越大量，後面越痛苦。

這也回答了我最開始的疑問：為什麼高手可以說「一句話做很多支」？

現在我比較能理解了！不是因為他的 Codex 跟我的 Codex 完全不一樣，也不一定是他下了一個神奇 Prompt。

真正差別很可能是：他前面已經把大量規則寫進系統。

所以那一句話只是：Trigger、觸發器、真正做事的是後面早就建立好的 Workflow。

一句話觸發，是自動化的終點，不是起點

這句話我現在非常有感。

如果還沒有：資料規格、模板、Scene 規則、素材規則、命名方式、字幕規則、Render、QA、Retry。

就直接追求：「我能不能只說一句話？」

很容易得到一個：看起來很自動，但非常不穩定的系統。

這和我做 Tina-Sales-Page-Generator 的經驗其實完全一樣

一開始我也是想：一句話做銷售頁。

後來才慢慢建立：Brand DNA、Product DNA、Strategy、Component、Variant、Image Rules、QA。

直到這些東西建立起來，才真正開始有「一句話生成」的可能。影片只是把同樣的道理再走一次。

如果我要替真正的影片 Batch Mode 設計資料夾，我會希望長這樣

batch/
├── jobs.csv
├── templates/
├── global-assets/
├── EP001/
│   ├── input/
│   ├── scenes/
│   ├── assets/
│   ├── preview/
│   └── output/
├── EP002/
├── EP003/
└── logs/

然後每一個 Job 都有自己的：Status、Retry Count、Output Path、QA Result。

甚至可以有一張 Batch Report

ID	Status	Retry	QA
EP001	DONE	0	PASS
EP002	DONE	1	PASS
EP003	REVIEW	2	SUBTITLE

這時我才真的會覺得我不是在做很多影片，我是在管理一條影片生產線。

那 Codex 在這條生產線裡，到底是什麼角色？

做到現在，我覺得 Codex 最適合的角色，不是100 支影片生成器，而是生產線的工程師與調度者。

它可以：讀任務、寫程式、呼叫流程、檢查結果、處理異常、修改局部檔案，把不同工具串起來。

真正生成圖片、生成數字人、Render 影片的工作，則可以由各自擅長的工具處理。

這也是第 17 篇筆記講「正確分工」再一次出現

Codex 不必什麼都自己做。

它真正需要的是知道誰該做什麼，以及什麼時候做。

所以我現在不再追求「Codex 能不能一天做 100 支」

我反而更想問我的 Workflow 能不能穩定處理 100 個 Job？

這兩句話只有幾個字不同，但概念差非常多。

第一句把焦點放在AI 有多厲害，第二句把焦點放在系統有沒有設計好。

Tina學姐這次最大的體會：100 支不是生成問題，是系統問題

做到第 22 篇筆記，我覺得這就是整段實驗最值得記下來的一句話。

一天做 100 支影片，真正困難的不是叫 AI 生成 100 次，而是讓第 1 支到第 100 支，都能按照同一套規則被管理。

生成只是其中一段，還有：輸入、素材、命名、流程、狀態、Retry、QA、版本、輸出。

只有這些都建立起來，100 才有意義。

寫在最後：Batch Mode 不是追求更多，而是讓「已經會做的事」可以被大量重複

真正的 AI 自動化，不是「AI 幫我做很多東西」，而是「我把自己的做事方法，變成一套可以重複執行的系統」。

至於一天到底能不能做 100 支？我現在反而覺得數字已經不是最重要的答案。

只要整條 Workflow：可重複、可監控、可 Retry、可局部修改、可 QA，那今天也許跑 10 支、明天跑 30 支、未來再跑更多。

真正重要的是它不再依賴我坐在電腦前，一支一支重新操作。我覺得，這才是 Batch Mode 真正吸引我的地方。