昨天的結論是：要把「希望 AI 別做」轉成「讓 AI 做不到」。

但這中間不是一個開關，是一條光譜。今天把它畫出來。

四段光譜

希望 AI 別做  →  告訴 AI 別做  →  提醒 AI 別做  →  讓 AI 做不到
（無效）         （advisory）    （detective）   （preventive）

   □               ▣                 ▣▣              ████
 弱                                                      強

四段的差別：

最上面那格「無效」值得停一下。

隱性規則是最容易被漏掉的一類，因為它們對團隊裡的老手來說太理所當然了，理所當然到沒有人想到要寫下來。日期是民國年、布林欄位用 Y/N、金額不含稅、狀態碼 7 代表什麼。這些在老手腦子裡，不在任何文件裡。

而 AI 完全不知道。它會用它的覺得合理的方式：西元年、true/false、含稅、狀態碼用 enum。

只有最後一格是可靠的

這是整條光譜最重要的結論：只有 preventive 那一格是真的可靠。前面三格都要 AI 願意配合才有效。

而 AI 是否配合，取決於它當下對 prompt 的詮釋強度。那是機率，不是保證。你可以透過寫得更清楚來提高那個機率，但你提高不到 100%。detective 那一格比較微妙。「事後發現」聽起來比「什麼都不做」好，但它有一個致命的成本問題：

發現的成本，通常遠高於預防的成本。

前幾天的文章講過：修一個版型 bug 五分鐘，找到它三十分鐘。那個案子九輪人工測試找出 187 個問題單。那是把人當偵測器用，而人會疲勞、會漏看、會在第九輪的時候開始草率。

所以 detective 不是「比較弱的 preventive」，它是另一種東西：它把成本從機器轉嫁到人身上。

由此得到的判準

這條光譜給我一個很好用的判準，我現在檢視任何一條規則都問這句：

規則的價值，不在於它寫得多嚴謹，
而在於它落在光譜的哪一段。

推論：一條 preventive 級的封鎖，勝過五十條 advisory 級的方框警告。 這句話有點反直覺，因為 advisory 寫起來很快、看起來很完整、而且很有「我們有在管」的感覺。591 行的命名規範看起來比一條 lint 規則專業得多。

但 591 行只是勸告，lint 規則是強制。

而且更糟的是——591 行還會佔用 context。它每次都要被讀進去，擠掉本來可以放實際程式碼、放範例的空間。所以它不只沒效，它還有負面成本。(這一點後面會展開。)

一個實際的爬升例子

光講理論比較虛，我拿另一個案子的實際紀錄來看。那個案子有一份日誌，專門記錄每次調整規則的動作。其中一條長這樣：

把「貼警語」升級為「機器擋」
觀察：文件裡的 SQL 範例出現不該有的寫法，第 N 次發生。
判斷：目前的做法是在文件旁邊貼一段警語，屬於 advisory。
改進：把檢查腳本的掃描範圍擴及文件內的 SQL，違反就擋。

這就是光譜爬升的實際長相：同一條規則，從第二格搬到第四格。 注意它不是新增一條規則，而是把已經存在的規則換一個實作方式。這是我認為最划算的一種改善。你不需要想出新規則，只要把舊規則搬上去。

那是不是全部都要 preventive

不是。而且這是很多人導入時的第一個錯誤。

不是每條規則都能封鎖，也不是每條都值得封鎖。

判準大概是這樣：

最後一行是我後來加的，因為在整理那 591 行的時候發現：有些「規則」其實是風格偏好，寫的人自己也說不出違反了會怎樣。那種東西留在文件裡只會稀釋真正重要的規則。

接下我們會說明如何用一個洋蔥式的結構完成這樣的限制

明天開始逐層講。層次是這樣編號的：

編號從 0 開始是刻意的。第 0 層是每個人都有、但幾乎不構成約束的那一層。

而那個失敗的案子，絕大多數規則都卡在第 0 層。

明天就從那裡開始。

參考文獻

1. preventive / detective 這組分類不是本系列自創，而是借自內部控制與稽核領域的通用術語——預防性控制（preventive control）與偵測性控制（detective control），常見於 COSO 內部控制整合架構與各類資安控制框架。
   本文把它搬到 AI 協作的規則設計上，並在前面加了「無效」與「advisory」兩格，這四格光譜的組合是我的整理，不是既有框架的分類。
2. 「緊箍咒」這個比喻取自《西遊記》（吳承恩，明代）。用它是因為那個裝置的兩個性質——永遠戴著、自動觸發——正好是 advisory 規則缺的兩件事。

本系列所有案例均經去識別處理，不指涉任何特定客戶、系統或產業。