前言：「你們現在也有一堆沒人敢刪的 lint 規則吧？」

這是一句很難反駁的質疑,也是這個系列該正面回答的問題。前面用了好幾天篇幅講「把期待寫成可執行規則」——複雜度預算、架構測試、CLAUDE.md／Skill——聽起來像是找到了解方，但如果誠實一點，這些規則本身也是程式碼的一種形式，一樣會過時、一樣需要維護、一樣可能被寫得比它該有的樣子複雜。這篇要正面回答：這套方法論會不會只是把過度設計的問題,從「業務程式碼」搬到「規則本身」？

今日目標

• 誠實承認「可執行規則」本身也有維護成本，不是一次寫完就永久有效的解方
• 具體列出規則清單可能腐化的幾種典型模式
• 討論怎麼降低規則本身變成技術債的風險，而不是假裝這個風險不存在
• 把這個反思跟系列主題句放在一起，看它有沒有削弱原本的論點

規則會腐化,這件事不用迴避

任何一條寫死的規則，都可能在系統演化之後變得不合時宜。Day 24 討論過的例子已經預告了這個風險：如果把「改一個欄位最多動 3 個檔案」這條複雜度預算規則直接套用到留言功能，機制會忠實地擋下每一次合理的改動，逼工程師想辦法繞過檢查——而「想辦法繞過檢查」正是規則腐化最典型的徵兆。一旦工程師開始習慣性地在 PR 裡加註解「這個規則不適用，因為……」，規則本身就已經名存實亡,跟過度設計版本裡「以防萬一」的死碼是同一種性質的東西：曾經有存在的理由，現在只是佔著位置。

架構測試也有類似風險。一條寫在專案早期的架構測試斷言（例如「Domain 層不能依賴任何 Infrastructure 命名空間」），可能在系統成長到需要某種合理例外時（例如 Domain 事件需要序列化，勢必要碰到某個底層介面），變成一個每次 CI 跑就要看著失敗、然後手動加白名單的日常摩擦。如果沒有人定期回頭檢查「這條規則現在還在保護什麼」，規則清單本身會變成一堆化石,跟沒人敢刪的舊程式碼一模一樣。

規則清單腐化的三種典型模式

第一種，規則寫死了具體數字，沒有寫清楚背後的意圖。像「改一個欄位最多動 3 個檔案」這種數字，脫離了「這個系統目前的聚合根有多複雜」這個脈絡就沒有意義，一旦系統成長，數字沒跟著調整，規則就變成噪音。第二種，規則之間互相打架，例如架構測試堅持嚴格分層,但複雜度預算又要求改動幅度要小,兩者在某些需求下互相拉扯,工程師只能選擇違反其中一條，久而久之大家會挑違反成本比較低的那一條,規則的約束力被磨損。第三種,沒有人被指定負責規則本身的演化，規則被當成「寫一次就永久生效的基礎建設」,沒有排進任何回顧週期,直到某天集體發現規則已經跟現況嚴重脫節才驚覺。

這個風險削弱系列的論點嗎？——不,它補上了論點的下半句

回頭看系列主題句：AI 沒有發明過度設計，它只是讓過度設計的速度追上了你按下 Enter 的速度；Review 要跟得上，審的就不能再是程式碼本身，而是產生程式碼的規則。 今天這篇反思沒有推翻這句話，但補上了一句容易被忽略的下半句：規則取代程式碼成為 review 的對象之後，規則本身也需要被 review，這件事不會因為規則的形式是「機制」而不是「程式碼」就自動免疫。

具體的緩解做法，不是發明一套新機制去驗證機制（那只是把問題再往上疊一層），而是老實地把規則的維護跟程式碼的維護放在同一套紀律底下：每條規則寫下時附上「這條規則要防的是什麼具體情境」，定期（例如每次大型需求上線後）回頭問「這條規則現在還在防那個情境嗎」，發現不合時宜就大方修改或刪除,不要留著當作歷史遺跡。這跟 Day 25 講的「機制不能自動生出正確判斷」是同一個道理的延伸——維護規則清單一樣需要人持續投入判斷力，不會因為寫成了自動化檢查就從此不用管。

今日思考題

你們專案裡現有的 CI 檢查、lint 規則、架構測試，有沒有定期被回頭檢視過？如果從來沒有，下一次是不是該找個時間，跟團隊一起清點一次「這些規則現在還在保護什麼」？

今日重點回顧

• 可執行規則本身不是一次寫完永久有效的解方，一樣會隨系統演化而腐化
• 規則腐化常見的三種模式：寫死具體數字沒有意圖脈絡、規則彼此打架、沒有人負責規則的演化
• 這個風險沒有推翻系列主題句，而是補上了容易被忽略的下半句：規則本身也需要被持續 review
• 緩解方式不是疊加更多機制，而是把規則的維護放進跟程式碼維護一樣的紀律裡

明日預告

Day 28 要把格局拉高，談一個更大的命題：AI 加速的到底是什麼？不是寫程式本身，而是每一種軟體工程裡本來就存在的舊毛病的發作速度。

老派工程師的心得

寫這篇的時候我一度想避重就輕，只講規則腐化的風險存在，卻不敢明講「這代表我自己也可能在不知不覺中把規則清單養成一堆化石」。但如果連自己都不敢承認這個風險，這篇文章寫出來就只是嘴上說誠實，實際上還是在賣一個講得太滿的方法論。這不是我想留給這個系列的樣子。