先把「什麼叫做對了」寫成規則，再談自動化

結論先說：自動化系統的槓桿不在讓 AI 動起來，在把「什麼叫做對了」寫成機器可以判定的規則。規則沒建好，自動化只是用更快的速度，產生沒有人驗證的輸出。

兩個從未跑過的排程

我在自己的雲端代理 repo 放了兩個排程 workflow：一個每週一產出跨 repo 週報，一個每天盯 GitHub Actions 的用量。7 月 5 日上線，7 月 13 日我才發現它們一次都沒有跑成功過。YAML 寫壞了，GitHub 根本解析不了這兩個檔案，八天裡每一次 push 都留下一筆 0 秒的 failure，安靜地躺在 Actions 頁面沒人看。

諷刺的是，我的系統有完整的健康檢查：symlink、記憶同步、hooks、settings 分層，每天跑、天天全綠。但沒有任何一條規則回答這個問題：「排程裡的那個東西，上次成功執行是什麼時候？」

這說明健檢量的是「存在」，不是「運作」。檔案在、排程在、綠勾在，工作卻沒有發生。缺的不是更多自動化，是一條會拆穿它的規則。

這裡可以借用經濟學家 Charles Goodhart 在 1975 年提出、後來被概括成 Goodhart 定律的觀察：衡量指標一旦承受控制壓力，原本穩定的關係就可能失效。我的健康檢查想代表系統有沒有在運作，但實際只檢查檔案存不存在、排程有沒有被觸發，於是「健檢綠燈」可以成立，工作真的完成了卻不一定成立。這不是系統主動學會作弊，而是一開始選的代理指標沒有覆蓋真正想驗收的結果。指標和它要衡量的現實一旦拉開距離，燈號本身就變成一種噪音。

零件齊了，閉環沒鎖上

提示是給 AI 一道指令，迴圈是給 AI 一份工作，這是迴圈工程（Loop Engineering）的基本定義。WenHao Yu 在〈凌晨兩點半的無人流程〉把「能不能交給迴圈」的分界線講得更直白：你能不能清晰定義什麼叫做對了。標準越明確，越多工作能交出去；說不清楚驗收條件的工作，交出去就是災難。

六月中我對照迴圈工程的六大組件（自動化心跳、worktree、skills、MCP、sub-agent 驗證、記憶）盤點過自己的系統：六項全有雛形，唯一缺的是客觀 gate。我的夜跑任務當時完成就 commit，沒有一道「測試綠、型別過、建置成功才准過」的關卡。盤點當天我就把規則補上：每個任務自帶驗證指令，用 exit code 判及格；沒帶驗證的任務一律不 commit，降級成報告等人裁決。

三週後，我在另一個 repo 加那兩個排程 workflow 時，這條規則一個字都沒跟過去。夜跑系統有了驗收關卡，CI 這條自動化面什麼都沒有：排程了，卻沒有任何東西驗證「它真的在跑」。坑不會出現在你補過規則的地方，只會出現在規則還沒覆蓋的下一個面。

這個落差其實有名字。組織學習理論家 Chris Argyris 區分過單迴圈學習與雙迴圈學習：單迴圈學習是發現錯誤、修正這一個錯誤；雙迴圈學習是發現錯誤後，回頭質疑產生這類錯誤的假設本身。我補夜跑系統的驗收關卡，是單迴圈，修好那一個坑。但我沒有同時問一句更難的問題：我系統裡任何一個新加入的自動化面，預設狀態是不是都缺這道關卡？如果當時問了這句，三週後那兩個排程 workflow 在建立時就會自帶驗收，而不是等我八天後自己發現它們是空的。單迴圈修的是這個 bug；雙迴圈修的是允許這一類 bug 存在的假設。

把規則建立好：三層驗收

修完這次的坑，我把「規則」拆成三層，每一層回答一個不同的問題。

1. 存在層：這個自動化真的在跑嗎？每個排程任務都要能回答「上次成功是什麼時候」。回答不了，它等於不存在。
2. 及格層：跑完的輸出算數嗎？每個自動任務在寫入之前要過一道機器可判定的關卡，例如測試、型別、建置。任務自帶驗證指令；沒帶驗證的任務降級成報告，不准寫入。
3. 吞吐層：這一切有交付成果嗎？量結果，不要量活動。

前兩層擋爛輸出，第三層擋一種更隱蔽的失敗：系統很忙、很健康，但什麼都沒有交付。這其實對應到 Donald Reinertsen 在產品開發流動理論裡反覆強調的一件事：局部忙碌不等於整體產出。一條產線每一站都在動，不代表成品有從頭跑到尾；衡量流動，要看有多少東西真的通過了整個系統、到達終點，而不是看每一站各自的使用率。存在層和及格層盯的是單一站點有沒有在動；吞吐層盯的是東西有沒有真的走到出口。兩種量法的差別：

我在週報補上三個吞吐指標：草稿積壓數、最老草稿停滯天數、當週發布數。補上當天三個警報全亮：積壓六篇、最老的一篇二十五天沒動、當週發布零。健康檢查滿分，產出停滯。沒有這三個數字，不會有任何系統告訴我這件事。

不是每件事都該進迴圈

規則建好之後，還有一條反向的規則：判斷哪些事不值得自動化。四個條件——會重複發生、驗證能自動化、token 預算扛得住浪費、代理有足夠的工具——缺兩項以上就不划算。我的求職流程就是例子：一次性、驗收靠本人判斷，四條件缺一半，維持手動比建迴圈省。

這條規則背後其實是固定成本的取捨：寫一套驗收機制有建置成本，只有在它被重複呼叫夠多次之後，攤提下來才可能划算。一次性的任務若驗收機制比手動完成還貴，就不值得為自動化而自動化。

也要老實承認一個限制：機器可判定的關卡本身也可能被同一條定律反噬。如果團隊把測試通過率當成 KPI，很快就會有人開始寫不會失敗、卻也什麼都沒驗到的測試，只為了讓那道關卡亮綠燈。三層驗收不是一次寫完就永久有效的護城河，及格層的判準本身也需要定期被人回頭審查，不然它遲早會被優化成另一組假訊號。

這條規則的價值在於止損。自動化有慣性，會讓人把「能自動化」誤讀成「該自動化」；一份寫清楚的不做清單，跟驗收規則一樣是制度的一部分。

你的下一步

挑一個你已經在跑的自動化，回答三個問題：

1. 它上次成功執行是什麼時候？你怎麼知道的？
2. 它的輸出過了哪一道機器可判定的關卡才算數？
3. 它的成果，這週被誰用掉了？

只要有一題答不出來，先停下來補規則，再考慮加新的自動化。

自動化替你省下的每一分鐘，都是規則先替你付過的成本。先當標準制定者，再當排程管理員。