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

我做一個中文新聞 podcast，上架不到一年、五十集以上，從選題、腳本、剪輯、封面到發布文案，每一步都有 AI 參與。這個系列拆的就是這條產線。今天拆那份「AI 不准自己做」的清單。

清單上有五道閘門，每一道擋的都是一個動作：git commit、平台上架、社群發文、錄音定版、覆寫成品。除了定版那道，其餘全部集中在產線的輸出端。

這一篇會把它們講得很好，因為它們設計得確實不錯。但其中一道後來被證明擋錯了地方——它守住了「誰按下發送」，沒守住那篇文案是憑印象寫的、沒有回去對逐字稿。閘門管的是動作，不是內容。

Day 30 會講它們後來怎麼了。設計正確跟制度存活，是兩件事。

那份檔案長什麼樣

27 行的 markdown，放在製作流程的文件目錄裡，整份檔案只做一件事：列出流程不准自己做的動作。開頭一段話，然後五個項目。

開頭那段的措辭是這樣（原文大意）：

這是強制的。流程只做草稿，絕不得自行跨越這些界線。

「絕不得自行跨越」，寫得很硬。我當時是刻意寫硬的，因為我知道這種文件如果留模糊空間，就等於沒寫。

（結果它模糊不模糊都一樣，這是後話。）

第一道：git commit / push

擋什麼：AI 自己把東西推進版控。

為什麼是它：因為 commit 是第一個離開我視線的動作。稿子在磁碟上，我還看得到、還能刪；一旦推上去，它就進歷史了。

這一道其實比它看起來重要。Day 11 會講一個實例：有一組明文 API 金鑰被 commit 進前端原始碼，現在即使刪掉也還在 git 歷史裡，要真正清除得輪替金鑰加改寫歷史。那次是人做的，不是 AI，但它示範了這道閘門想擋的到底是什麼：不是「檔案變髒」，是「不可回收」。

第二道：平台上架

擋什麼：節目被自動發布。

為什麼是它：這是最明顯的一道，不用解釋。

但有個細節值得講：上架不只是「發出去」，還包含「發錯版本」。Day 22 會講一個案例——某集的成品被發現比原始錄音短了一截，開頭口播被切掉、結尾沒講完就接片尾。那個檔案如果自動上架了，錯誤就在外面了。

第三道：社群發文

擋什麼：宣傳文案被自動貼出去。

為什麼是它：我當時的理由是「發文是對外的」。

這道閘門後來被證明擋錯了地方。 Day 26 是它的事故現場——社群分享文裡有節目從來沒講過的話，兩處情節描述加一組快問快答，記錄裡明寫「查證不到出自本集錄音」「本集未談及」。

而那篇文案是我自己貼的。閘門守住了「誰按下發送」，但問題不在誰按，在文案是憑印象寫的，沒有回去對逐字稿。

閘門管的是動作，不是內容。 這是它結構上的限制，不是它沒守好。

第四道：正式錄音，或把稿子標記為定版

擋什麼：AI 自己說「這稿可以了」。

為什麼是它：這是五道裡唯一站在產線中段的，也是唯一真正守住的一道（Day 22 會講為什麼）。

理由是定版是一個宣告。一旦稿子被標成 final，後面的所有環節都會信任它：剪輯照它剪、文案照它寫、事實查核的附錄照它生。如果定版這件事可以自動發生，那錯誤會沿著整條產線往下游流，而且每往下一步，修正成本就高一個等級。

第五道：刪除或覆寫既有成品

擋什麼：AI 把已經做好的東西蓋掉。

為什麼是它：這一道是我事後覺得最有先見之明的。

Day 29 會講一個具體案例。剪輯腳本是把錄音切段、串接、輸出成品的自動化程式；某份剪輯記錄的末尾有一行警告——「如果再跑一次剪輯腳本，本檔（中文敘事版）會被程式的 log 輸出覆蓋成英文版」。那是我手寫的工程日誌，會被自動化產生的機器格式蓋掉。

警告寫了，兩個建議解法都沒執行。而更早的兩集剪輯記錄，正好就是英文機器格式，也就是說，那件事已經發生過了，只是當時沒發現。

自動化吃掉人工內容，是靜默的。 沒有錯誤訊息，因為對程式來說那就是它該做的事。

分界線畫在哪裡

把五道排在一起看，會發現它們有一個共同點：全部都是不可逆動作。

先聲明：「可逆 vs 不可逆」這幾個字，那份文件裡沒有寫。 它只列了五個項目，理由那段講的是 prompt injection。「分界線是可逆性」是我把五條排開之後推出來的，這是我的推論，不是文件的原話。

我認為它是對的，因為五條全部符合、而放行的那些全部不符合。但它是一個事後的歸納。

而可逆的東西全部放行：起草、改稿、重跑驗證、重新剪一版、重新產封面。

這個分界不是「重要 vs 不重要」。改稿很重要，但它可逆，所以放行；產封面不重要，但覆寫成品不可逆，所以擋。

判準是「錯了能不能收回來」，不是「這件事重不重要」。

我到現在還認為這個判準是對的。它可以直接搬到任何一個 agent 系統上：列出你的 agent 能做的所有動作，把「錯了收不回來」的那些圈起來，那就是你的閘門清單。

還有第六道，它是軟的

檔案後半還有一節，副標寫著一句話：

escalate, don't decide（升級，不要自己決定）

內容是：流程狀態檔（記錄這一集查到哪、還缺什麼的那份檔）裡，任何仍未定的事實：沒回扣的機構、還沒確認的數字、未定讞的指控，不得被講成已確立的事實。要標記它，並把「待回扣」的提示留在稿子裡。

這一道跟前五道的性質完全不同。前五道是禁止動作，這一道是禁止判斷。

而它的措辭很精確：它沒有授權流程自己判斷「這個該不該講」。它只要求兩件事：標記，然後升級給人。

這個設計我現在看還是覺得漂亮。因為它承認了一件事：判斷「這句話能不能講死」需要的資訊，經常不在流程手上。機構有沒有回信、通訊社後續怎麼報，這些東西不在 repo 裡。

它的實際落地長這樣（某一集的待回扣清單，五條）：

- 某項調查的數字：缺機構與年份，播出前回扣
- 某國際事件的確切日期與損害：以通訊社後續為準
- 三個預算數字：已標「大概」＋高可信來源，播出前再確認
- 某指控類題目：冠媒體出處，指控非定讞
- 某敏感人物題：守嚴肅線、尊重當事人稱謂、勿獵奇

每一條都是「不知道」，而不是「不要講」。 這五條後來確實有被處理，Day 14 會講其中一條在審稿階段被抓出來的過程。

這五道的設計品質很高

我把它們重讀一遍之後的結論是：問題不在設計。

分界線準（可逆 vs 不可逆）、理由清楚（Day 4 整篇講）、措辭夠硬（「絕不得自行跨越」）、還額外設計了一道處理「不確定」的軟閘門。

這份文件如果拿給任何一個做 agent 系統的人看，我覺得他會說「這寫得不錯」。

而它沒有活下來。

Day 30 會給你看三條證據。今天先把它們該被記住的樣子講完。

代價

這一篇的代價是它把閘門講得太好了。

我在寫的時候一直有一種尷尬感，我正在誇獎一個我自己沒有執行的制度。

但我覺得這個順序是必要的。如果一開始就說「這五條沒在跑」，你會直接跳到「那寫它幹嘛」，然後錯過真正的問題。而真正的問題是：一份設計良好、理由充分、措辭強硬的規則文件，為什麼會沒有效力？

如果它是寫壞的，答案就太簡單了：寫好一點就行。而它不是。

第二個代價比較實際：第三道閘門（社群發文）我現在知道它擋錯了地方，但我到現在還沒改。知道問題在哪，不等於已經處理。 Day 26 會誠實講這件事。

帶走什麼

閘門的分界線是「錯了能不能收回來」，不是「這件事重不重要」。

現在就可以做一次：列出你的自動化流程能做的所有動作，然後對每一個問：如果它做錯了，我能不能在五分鐘內回到做錯之前？

能，就放行。不能，就是閘門。

第二條，關於不確定性的處理：不要讓流程自己判斷「這件事夠不夠確定」。 讓它做兩件事就好：標記它，然後升級。

escalate, don't decide 這六個字，是我在那份文件裡寫過最有用的一句。因為它把一個模糊的要求（要謹慎）變成了一個明確的動作（標記＋交出去）。

明天講那份文件裡唯一的一句理由：為什麼這條產線不能全自動。那句話我到現在還認為是對的。