模組六｜治理與收斂（Day 28–30）

第一天我給了三個數字：

上架不到一年、五十集以上。
兩個 repo 加起來 1,513 個 commit。
其中 ci: 開頭的，0 個。

我說第三個是這 30 天的問題。今天回答它。

先結清前兩個

第一個兌現了。 沒有這條產線，一個人不可能在不到一年內出五十集以上。AI 確實做到了它該做的部分：ASR、EDL、FFmpeg 組裝、封面套版，那些「確定性、可重跑、可量測」的環節（Day 5），全部沒有出過事。

第二個要打折。 1,513 用的是 first-parent（995 + 285）。如果直接數 commit 會得到 1,180 + 333，灌水約 18%，那是平行分支的雙記（Day 24）。

第三個是答案。

0 個 CI，意思是沒有任何規則在被執行

這 30 天講了一堆規則：

• 五道人工閘門（Day 3）
• 兩套 schema 模板（Day 7）
• 查核分層的六條硬門檻（Day 8）
• 「起草者不得自評、要換一個模型審」（Day 14）
• 三態生命週期標記（Day 29）
• 根目錄邊界治理與 KPI（Day 28）

沒有一條掛在任何自動流程上。

而它們的落實率分別是：模板 8%、查核補件 31%、閘門，今天講。

三條證據

一、那份閘門文件寫過一次之後，零次修改。

它跟流程狀態檔是同一個 commit 建立的，此後再也沒被動過。

而在那之後，repo 又推了 205 個 commit、產出 5 集節目。

那五集，完全沒有再經過這條流程。

二、AI harness 的權限清單裡，有 Bash(git commit:*) 和 Bash(rm:*)。

閘門第一條寫著「絕不自動 commit」。而底層設定同時授權了它，還附贈了 rm（對應第五道「不得刪除或覆寫既有成品」）。

兩份設定互相矛盾，而沒有任何東西會發現這件事，因為沒有任何東西在讀那份 markdown。

三、另一個 repo 只有閘門的引用，沒有閘門的定義。

它的狀態檔寫著「Human gates（未做，等人工）」，然後列了三條。而那個 repo 裡根本沒有那份文件。

它引用了一個不存在於自己身上的規則。

我要把話說清楚

這不代表那五集出事了。

它們都是我自己按下的發布鍵，稿子是我自己讀過的，錄音是我自己錄的。

問題是另一個：如果不是我按的，也沒有任何東西會攔。

那五道閘門的實際狀態，不是「守住了」，是「沒有被測試過」。而一道從來沒有被測試過的防線，跟不存在的差別，只在你有沒有意識到。

而同一條產線上，有東西活得好好的

對照組全部在這 30 天裡：

一支 64 行的 bash，覆蓋率 10%，活著。 因為它有退出碼（Day 12）。

一條編輯倫理活著。 「未定事實不得講成定論」被壓成「查核段必須同時含已證實與待證實標記」，兩個 in 判斷（Day 8）。

一支 34 行的 Python 活著。 它的 docstring 寫著「防再把合併衝突 commit 進去」，而它只有一個 commit，訊息裡有「救回被丟的 6 則」（Day 13）。

兩個資料欄位 100% 填滿，沒有任何程式強制它們。 因為不填就播不了（Day 6）。

一條命名規則有效，而一支 CLI 工具無效。 因為那條規則的執行者是人（Day 27）。

而寫得最完整、理由最充分、措辭最強硬的那份閘門文件，沒有活著。

分界線在哪裡

Day 27 已經給了答案，我當時是在講集數編號的時候撞到的：

不是「文件 vs 程式」。是這條規則的執行者是誰。

• 執行者是人 → 寫成文件。人會讀、會記得、會被提醒
• 執行者是機器或 AI → 必須寫成機器讀得懂的斷言，否則它不存在

把這 30 天的規則按這條分類，結果非常整齊：

下面三條的共同點：執行者是機器，而我寫成了給人看的東西：一份 markdown，或者一支沒有被掛上去的驗證器。

閘門的錯不在寫得不好。它的錯在於，它是寫給 AI 看的文件。

而 AI 不會因為讀過一段 markdown 就改變行為。真正決定它能做什麼的，是那份權限清單。

十條心法

1. 能被 grep 的規則才會活下來（Day 12、13）
2. 事故 → 檢查 → 退出碼，這條路徑走完才算數（Day 13）
3. 保守的預設值是最有效的攔截：沒標＝不可信（Day 8）
4. 要驗一個模型的產出，就換一個模型，換的是推理路徑（Day 14）
5. 帳本會過期，而 exit code 不會告訴你（Day 15、16）
6. 有外部標準可錨的參數不會漂，靠感官的一定會漂（Day 19）
7. 參數的數值只是結論，註解才是推理（Day 20）
8. 先量出問題的形狀，再選演算法（Day 21、24）
9. 連續三個版本都在調參數，問題通常在目標（Day 22）
10. 這是為這一次寫的，還是為每一次寫的（Day 29）

而貫穿它們的那一條：規則要寫成它的執行者讀得懂的格式。

誠實邊界

這是一個人的產線，不是團隊最佳實踐。

一個人有一個特權：你可以在腦子裡執行閘門。 這也正是為什麼它懸空了那麼久都沒出事：每一次 commit、每一次上架，都是我，而我知道那五條。

而這個特權不能複製給團隊，也不能複製給明天的我。

第二個誠實邊界：這 30 天列了大概二十件「我知道該做而沒做」的事：輪替那組還在 git 歷史裡的金鑰、把驗證器掛進 pre-commit、建 ASR 詞庫、刪掉那 17 份沒人用的文件、把複製後的檢查寫出來。

寫出來不等於處理了。 這句話我在這個系列裡說了六次，而它最後也適用於這個系列本身。

我接下來要做的第一件事

不是上面任何一條。

是把那五道閘門搬進權限設定。

文件留著，它的推理是對的，Day 4 那句「輸入不可信是結構問題，不會隨模型變強而消失」我到現在還完全同意。

但執行的必須是設定檔。把 Bash(git commit:*) 從 allow 清單移到需要確認、把 rm 拿掉。十分鐘的事。

而它跟那份 27 行的 markdown 的差別是：設定檔會被讀，markdown 不會。

代價

寫完這 30 天，我得承認一件事：這個系列本身，就是我第一次真的執行那份閘門文件。

不是因為我變自律了，是因為寫成文章逼我去查證。而查證的過程就是執行：我去比對了兩個 repo、實跑了驗證器、算了落實率、發現了七組跨文件落差。

那些東西在磁碟上躺了幾個月，沒有任何機制會發現它們。是「要寫出來給人看」這件事把它們挖出來的。

這不是一個可持續的機制。我不可能每次都寫一個 30 天系列來檢查自己的產線。

帶走什麼

任何寫給自動化流程的規則，如果不能被 exit code 表達，它就只是註解。

現在就可以檢查一次：你專案裡那些「絕對不要」「一律必須」，是寫在 README 裡，還是寫在 CI 裡？寫在 CONTRIBUTING 裡，還是寫在 pre-commit hook 裡？

寫在 agent 的 prompt 裡，還是寫在它的權限清單裡？

前者是給人看的，人會讀，所以它有效。
後者才是給機器執行的。

而我，把給機器的規則寫成了給人看的格式。

三十天，一句話。