Part 1 開始。接下來我們要講一個框架。

先把背景放回來，因為接下來八天會一直提到「那個案子」：四個月的技術升級案、舊系統是 Web Forms、九輪人工測試累積 187 張問題單、最後客戶要求重做。

還有一件事要先講清楚，不然昨天和今天會像在講兩件不相干的事。昨天講的是「規格」沒把維度說全；今天開始講的是「規範」。就算維度說全了，寫在文件裡的東西為什麼還是擋不住。 這是兩條不同的軸，Part 0 的結尾同時交了兩根棒子出來。

這個框架不是我從書上看來的，是那個失敗的案子逼出來的。回顧的時候有人問了一句話：

我們明明寫了規範，為什麼沒用？

今天先回答這個問題。

先看寫了什麼

那個案子的規範文件不算少：

• 主規範文件用方框寫了「絕對禁止異動 DB Schema」
• 另一份專門的關鍵規則文件，用視覺強化重申同一件事
• 開發原則文件列了四大原則加六項檢查清單
• API 命名規範一份，591 行

語氣也不弱。方框、粗體、驚嘆號、「絕對」「必須」「嚴禁」，該用的都用了。

然後測試問題單裡出現這些：

AI 創建了新的資料表
AI 把非必填欄位改成必填
AI 設定了 MaximumLength(20)，但資料庫欄位是 nvarchar(10)

第三個特別值得看。它不是「AI 亂寫」，它是AI 沒有去查真實的欄位長度，用了一個看起來很常見的數字。而檢查清單裡明明就有一條「欄位長度必須對照資料庫」。

問題在哪裡

我一開始的假設是「規範寫得不夠清楚」。所以第一個反應是——再寫一份更清楚的。這個反應是錯的，而且它會讓事情變糟（後面會講為什麼）。真正的原因是這樣：AI 在執行任務的時候，prompt 裡同時存在兩種指令。

一種是正向指令：實作這個功能。
一種是負向指令：不要違反 X 規則。

正向指令是它這次被叫來做的事，是任務本身。負向指令是背景約束。當兩者衝突的時候——比如說功能需求隱含需要一個新欄位、或者舊系統的行為跟一般 UX 直覺相反。沒有強制力的負向指令就會被偏離。

而為什麼會被偏離？因為：

AI 違規不會收到立即懲罰。
所以規則的權重，會被當下任務的權重壓過去。

這就是 advisory rules（勸告型規則）的根本問題。它們依賴 AI 自願配合，而 AI 是否配合，取決於它當下對 prompt 的詮釋強度。那是一個機率，不是保證。

這不是 AI 特有的問題

順帶講一件我覺得有意思的事：**這個機制在人身上也一樣。**你的團隊也有規範文件。上面也寫著「PR 必須有測試」「不可以直接改 main」「commit message 要照格式」。

有多少條是靠自覺遵守的？那些條，遵守率大概多少？

而那些做成 CI gate、pre-commit hook、branch protection 的規則呢？遵守率是 100%。因為違反的人根本提交不上去。差別不在於哪條規則比較重要，也不在於團隊的紀律。差別在於哪一條有強制力。

AI 只是把這個現象放大了，因為它產出的速度是人的十倍，而且它沒有「被同事白眼」這種社會壓力。

一個更難堪的統計

回顧的時候還發現另一件事，比「規範沒用」更根本：

那個案子的規範文件，95% 都是事後補鍋。

把所有治理規範按建立日期排出來：

12/10  API 命名規範        ← 推測是命名衝突已經發生
12/26  關鍵規則文件        ← 「DB Schema 不可動」第一次寫成方框
 1/21  欄位對照表          ← 上線準備度報告的前一天
 1/21  開發原則文件        ← 文件自己寫「源自 ISSUE-019 的經驗教訓」
 1/22  測試問題回顧        ← 80 個問題之後
 1/22  開發檢查清單        ← 同一天交付
 2/23  主規範文件大改寫    ← 停擺 24 天後重啟，才寫進「行為複製規範」

沒有一份規範是在開工前就寫好的。

而最重要的那條底線。「資料庫不可動 + 行為必須與舊系統一致」。等到 2 月 23 日重啟才進主規範。那時候專案已經跑了將近四個月。

所以「規範沒用」這件事，其實有兩層：

1. 時序問題：規範是在問題發生之後才寫的，它防不了已經發生的事
2. 強度問題：就算寫了，它也只是勸告

今天講的是第二層。第一層（規範該什麼時候寫）留到 Part 2。

那要怎麼辦

答案很簡單，難的是做到：

把「希望 AI 別做」，轉成「讓 AI 做不到」。

這就是我後來叫它「緊箍咒」的原因。

孫悟空那個緊箍咒之所以有效，不是因為金屬硬。是因為它有兩個性質：

• 永遠戴著（不會因為這次任務很趕就拿下來）
• 自動觸發（不需要唐僧記得要念，違規當下就發作）

而我們寫在文件裡的那些「絕對禁止」，兩個性質都沒有。

但這個比喻我要先自己拆一次，因為它其實低了一格。

緊箍咒的機制是做了會痛。悟空隨時可以違抗，緊箍咒從來沒有讓任何一次違抗不發生，它只是讓違抗很痛。用後面幾天要建立的語言講：那是偵測加懲罰，不是預防。

而且原著裡唐僧必須念咒才會發作。「需要有人記得觸發」，正是我上面說 advisory 缺的那件事。

更麻煩的是我自己的診斷：我剛剛說 advisory 失效是因為「AI 違規不會收到立即懲罰」。如果病因是缺懲罰，對症的藥就是補上懲罰。那正是緊箍咒。但我後面要開的藥不是那個，是「讓它物理上做不到」。那是另一條路。

我選另一條路的理由是：AI 沒有跨 session 的痛覺記憶，懲罰對一個不會記得痛的產出者不成立。

所以這個系列的招牌，掛的是我沒有走的那條路。 我把它留著，因為它確實抓住了那兩個性質，而且好記。但讀到後面請記得：真正有效的那一層不需要痛，它是把可能性取消。明天要講的，就是怎麼把規則從「文件」搬到「戴在頭上的東西」。而那不是一個開關，是一條光譜。

小結

今天的三個重點：

1. AI 違規沒有立即懲罰，所以規則權重會被當下任務壓過
2. 這不是 AI 特有的問題，人的規範遵守率也是靠強制力決定的
3. 那個案子的規範 95% 是事後補鍋，所以它同時有時序問題和強度問題

明天講那條光譜，以及為什麼「一條 preventive 勝過五十條 advisory」。

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