模組一｜為什麼不做全自動（Day 1–5）

昨天說這條產線每一步都有 AI，只有錄音跟發布是我按的。今天把整條線攤開，讓你看清楚那五道閘門實際站在哪裡。

先講一個我自己整理的時候才發現的事實：

內容後台這個 repo，比製作端晚了 126 天才建。

也就是說，節目先跑了四個多月，工具才長出來。這條產線不是設計出來的，是痛出來的。

完整路徑

從一則新聞到一集節目，實際經過的東西：

新聞來源
  └─ 結構化條目（一則新聞 = 一個 JSON 物件，含開場鉤子、要點、查核、金句…）
       └─ 選題（從條目池撈，依受眾配比排序）
            └─ rundown（節目表：第幾段、幾分鐘、對應哪一則條目的 id）
                 └─ 口播稿 HTML（可朗讀版本，含立場守則與查核附錄）
                      └─ ★ 錄音（人）
                           └─ 逐字稿（ASR）
                                └─ 剪點（人下指示 → AI 寫成 Python 剪輯腳本）
                                     └─ FFmpeg 組裝（去空拍、變速、響度、BGM）
                                          └─ 封面（套版）／直式影片／短影片
                                               └─ 發布文案
                                                    └─ ★ 上架（人）

兩個 ★ 就是我按的那兩個鍵。中間十一個環節，全部有 AI 參與。

每一步，誰在做什麼

這張表看久了會發現一件事：AI 佔比最高的是「產出」，人佔比最高的是「決定」與「聽」。

那五道閘門在哪裡

把昨天那五道閘門標回這張圖上，位置很集中：

• commit → 貫穿全線，但發生在 repo 邊界
• 上架 → 最末端
• 社群發文 → 最末端
• 錄音／出稿定版 → 中段唯一的一道
• 覆寫既有成品 → 貫穿全線

五道裡有四道站在輸出端或 repo 邊界，只有一道站在中段。

閘門全擠在出口，中段每個接縫都在漏，沒有人正對著它。

而 AI 參與最深的是輸入與中段：結構化條目、口播稿、逐字稿、剪點、組裝。

這個位置關係我當時覺得很合理：擋住不可逆的出口就好，中間隨便跑，錯了重跑一次。

它有一個前提，而我那時沒有把它寫下來：「中間錯了會被發現」。

後面 28 天有一半在講中間沒被發現的事。

產線是長出來的，不是設計出來的

我原本以為這條線一開始就是這樣。查了目錄之後不是。

早期有一段時期，每集的工作目錄裡一支腳本都沒有。 那時候的剪輯是手動的，或者是一次性的指令跑完就丟。目錄裡只有音檔、封面、幾份文字檔，每集 11 到 16 個檔案。

現在每集穩定 3 到 7 支腳本，34 到 48 個檔案。

膨脹三倍，而且是逐集長出來的。不是某一天決定「來建一條產線」，是每一集遇到一個痛點、寫一支腳本，然後那支腳本被下一集複製過去。

這個成長方式有兩個後果，兩個都很明顯：

好的那個：每一支腳本都對應一個真實痛點，沒有一支是為了架構完整而寫的。

壞的那個：因為是「複製過去」，所以每一集都有自己的一份。同一段邏輯散在十幾個目錄裡，改一處不會影響其他處。Day 23 會給你看三支已經指向錯誤集數、但沒人發現的封面腳本；Day 27 會講這個複製機制怎麼造成集數撞號。

兩個 repo，兩種節奏

製作端跑了四個多月，內容後台才建。這個時間差解釋了一件事：內容後台不是規劃出來的，是製作端跑順之後，內容沒地方放。

而它們的忙碌期幾乎不重疊。有一個月製作端掉到全期最低，內容後台同月衝到全期最高——精力在兩個 repo 之間搬。

只有一個月兩邊同時衝刺。而那個月，字幕錯字的 commit 數是全期最高、資料檔的合併衝突連發、事實錯誤修正也集中在那時候。

兩邊同時滿載，就是兩邊的品質同時失控的時候。 這件事我當時完全沒感覺，是查月度分布才看出來的。

一個很土但有用的觀察

整條線的每一環，都有一個明確的產物落在檔案系統上。

條目是 JSON、rundown 是 Markdown、口播稿是 HTML、剪點是 Python、組裝結果是 mp3、封面是 PNG。

這不是刻意設計的，但它造成一個結果：這條產線的每一步都可以事後被檢查，因為每一步都留下了東西。

Day 12 那支驗證器之所以做得起來，就是因為它有一個檔案可以讀。而 Day 25 那個唯一沒有留下產物的環節（短影片的傳播效果），就是我唯一拿不出數字的地方。

產物落在磁碟上，你就能驗它；產物落在別人的伺服器上，你只能猜。

代價

這條產線最大的代價是它沒有一個地方是「整體」。

沒有一份文件描述全貌。今天這篇是我為了寫這個系列，才第一次把它畫出來的。在那之前，它只存在於我對每個環節的個別記憶裡。

這造成的問題很具體：當某一環改了，我不知道誰會受影響。 例如口播稿的段落標記改了名字，Day 12 那支驗證器會直接失效，而它不會報錯，它會通過，因為它 grep 不到的東西就當作不存在。

第二個代價是那個「中間錯了會被發現」的隱含前提。我把閘門都放在出口，等於假設中段的錯誤會在到達出口前浮出來。有些會（試聽會抓到剪壞的地方），有些不會（Day 16 那七組跨文件落差，一組都沒被抓到）。

帶走什麼

先畫出你的產線圖，再決定閘門放哪裡。

如果你也在做 AI 輔助的流程，今天可以做的一件事是：把每一環的「產物」列出來，然後對每一個產物問三個問題——

1. 它落在哪裡？（磁碟／別人的伺服器／沒有產物）
2. 有沒有東西在檢查它？
3. 如果它錯了，會在哪一步被發現？

第三個問題最有用。我做完這張表才發現，我的閘門全部集中在最後兩步，而中段有整整六個環節，錯了要等到成品才知道——或者永遠不知道。

明天把那五道閘門逐一拆開，看它們各自想擋什麼。