Day 25｜護欄：允許自動化到哪裡為止

Day 24 停在一個缺口：失敗即鎖定鎖得住機器，可是一批改動到底要不要進版控，還是得有人判斷。今天回頭讀我自己的規則，第一眼就看到一個說不通的地方。我把提交這種進版控的動作，開放給無人值守的流程自己做；可是在本機刪一個目錄，我卻要求先列出完整路徑、等我明確回覆。提交會留在紀錄裡給人看，刪目錄只動我自己的硬碟。照常理，該鬆的和該緊的好像放反了。這篇要說的是：不是放反，是我一直用錯了尺。

事故：同一份規則，兩種鬆緊

先把兩條規則並排。

全域規則對提交的寫法是：一律先審查，讓我看過檔案清單和訊息全文、明確說可以，才提交。到 10-04 盤點時，同一條緊接著開了四個例外，其中有的可以在沒人盯著的時候自己提交、自己推送。

刪除那條沒有例外。遞迴刪除目錄、清除未追蹤的檔案、丟棄還沒提交的工作，都要先列出路徑，再等我回覆。Day 8 講過攔截層在動作送出之前就分三檔判定，這裡不重講；這幾類動作落在「詢問」那一檔，下文叫它「要問人」，「拒絕」則叫「直接擋」。

放到無人值守模式下，差別更明顯。Day 22 講過，沒有人在時「要問人」一律改判「直接擋」；2026-09-07 到 09-27 之間的紀錄有 21 次，多數是上線當天的測試殘留。換句話說，同樣在沒有人的時候，刪一個目錄會被擋下，提交並推送一批改動卻可能照做。

我先想用可逆性解釋：刪除不可逆，提交可逆。這說不通。提交在本機確實撤得回來，可是一推上去，遠端已經被看見，只能再推一筆修正蓋過去。論收拾的難度，推送不比刪一個本機目錄容易。

我又想用影響範圍解釋，也說不通。刪目錄只影響我，推送卻對外可見。照影響範圍排，推送應該更緊才對。

兩把直覺的尺，都量不出這套規則現在的形狀。問題不在規則寫錯，而在我描述護欄的方式錯了。我一直把護欄講成「哪些指令不准跑」，可是規則實際在管的，從來不是指令本身。我原本以為自己寫的是一份黑名單：列出危險的指令，叫機器別碰。照黑名單的邏輯，提交和推送都該在名單上；可是它們沒有被一律禁止，只是被框了起來。

證據：把動作攤開，看主意在誰手上

我把規則碰得到的動作攤開，一共 12 種，逐一標上可逆性、有人時怎麼處置、無人值守時怎麼處置。

12 種動作依無人值守時的處置分成三組：框內可做、改判擋下、機器一律不做。可逆性和分組並不對齊：一般推送撤不回卻落在可做那組，解除失敗鎖撤得回卻落在機器一律不做那組。

可逆性不是那把尺。真正對齊的是另一個問題：這個動作要拿的主意，能不能在動作發生之前就由人拿好？

提交可以。要提交哪些檔、審查有沒有收斂、推送失敗怎麼收，都能在觸發時由我框定。框定之後，執行時不必再判斷，只要照做，而且事後可驗。

刪除不行。要刪哪個路徑、裡面有沒有我還要的東西，只有動作當下看到現場才知道。這個主意沒辦法事先拿好，所以只能等人；沒有人，就擋。

第三組連有人時也不交給機器：強制推送、建立合併請求、解除失敗鎖，還有對某個外部系統的寫入。這組的主意我不打算事先授權，要做就由我自己動手。其中建立合併請求本輪只查到文件層的禁令，沒查到機械層的規則；如果真的沒有，這是一個沒補上的洞。

再看例外實際被用了幾次。2026-09-18 到 10-02（以 UTC 日期計），這套工具自己的對話紀錄裡，我親手輸入的快速提交 7 次；審查後照固定方式處置的 13 次，其中一開頭就給了預授權的 11 次、沒給的 2 次；從待辦缺口清單自己做完、自己提交的那條 0 次。這些是指令被觸發的次數，不是提交的次數。版本紀錄不標提交從哪條路徑來，實際產生了幾筆提交，我取不到，也不推算。

Day 22 列過的四道邊界：限定路徑、三輪收斂、逐檔加入、非強制推送；它們是跟無人值守有關的兩條例外合起來的條件，不是每條例外都四道全有。任一道沒過都不是換個方式再試，而是收手：範圍變動則授權失效，未收斂則還原並標延後，推送失敗則不重試。

這張圖回答開頭的矛盾。被放行的不是「提交」這個指令，是一個主意已經事先拿好的框；框外的提交，照樣要有人。

解法：把「要不要」留給人，把「照做」交給機器

所以規則的分層方式改了：按決定分，不按指令分。

第一層，主意能事先拿好的動作，用例外框起來。授權只能來自我：要嘛親手輸入，要嘛事先給出預授權。框的每條邊事後都能驗，執行者在框內不需要判斷。這一層敢放，是因為它把判斷挪到動作之前，不是把判斷拿掉。

第二層，主意只能當下拿的動作，交給攔截層判「要問人」。有人時我回覆；沒人時改判擋下。2026-08-27 到 10-04，攔截層判「要問人」1486 次、「直接擋」909 次，人工放行 633 次、人工拒絕 43 次。每一筆「要問人」都假設現場有人；這個假設不成立時，它就不該變成照做。對另一個外部系統發訊息也歸這層：三步審核後等我明確授權，沒人時同樣擋下。

第三層，主意我不交出去的動作，機器一律不做。強制推送在攔截層一律擋；解除失敗鎖只能由我親手執行，機器去寫鎖檔一律擋。這一層不開給機器的例外，也不接受預授權。派工端另有兩份清單，決定哪些工作根本不離開本機，內容不列。

三層放在一起，護欄的定義就清楚了：護欄不是「哪些指令不准跑」，是「哪些決定不准在沒有人的時候做」。

新問題：會痛的如果不是我

回頭看這 12 種動作，有一件事很一致：最後承擔後果的都是我。刪錯目錄，痛的是我的硬碟；推錯一筆，留在我的版本庫；鎖住派工，停的是我的流程。連對外系統那兩種，也是以我的名義寫、以我的名義發。

這套框法有一個沒寫出來的前提：拿主意的人和承擔後果的人是同一個。我框定路徑、給出預授權，出錯了我自己收。在我自己的機器上，這個前提從來不用說出口。

我事先替自己拿好的主意，換成會落在別人身上的事，還算數嗎？授權該從誰那裡來，框該由誰來畫，我的規則裡都沒有寫。這些護欄保護的都是我自己的機器；如果會痛的是別人呢？

明日預告：Day 26｜一個真的要對外負責的專案