第 0 層：憲法。

這是每個人都有的那一層。CLAUDE.md、Cursor rules、system prompt 最頂端那幾條「絕對不可以」。它最便宜，也最弱。今天講它的極限在哪，以及怎麼讓它發揮該有的作用。

那個案子做到了這一層

先講公道話：第 0 層那個案子做得不差。

主規範文件裡有四個方框級的「絕對禁止事項」，還有六項欄位檢查清單。格式清楚、位置顯眼、語氣強烈。

如果只看文件本身，那是一份合格的規範。

問題是它就只有這一層。

Day 11 列過結果：AI 還是建了新表、還是把非必填改成必填、還是設了一個跟資料庫不符的欄位長度。

為什麼會失效

除了昨天講的「advisory 依賴自願配合」之外，第 0 層還有三個結構性問題。

一、context 是有限資源。

你在規範文件裡塞的每一段文字，都在跟「AI 該去注意的實際程式碼」搶注意力。

那份 591 行的命名規範，每次都要被讀進去。

這裡我原本寫的是「591 行換來的可能是 AI 少讀了兩個實際的檔案」。那個講法我要收回。 它把機制講成了一個額度模型（好像 context 是個油箱、多裝這個就少裝那個），而實際上有 prompt caching，這種「排擠」不是那樣運作的。

真正的機制是注意力稀釋和指令衝突：不是它讀不到，是在一堆同等強度的指令裡，它分不出哪一條是真的重要。下面那一節講的就是這件事。你為了讓 AI 表現更好而加的東西，反而讓它更難分辨哪一條是真的重要。

二、規則多到某個程度會失去優先序。

當一份文件裡有十七處都寫著「這非常重要」「絕對必須」，那就沒有最重要的了。AI 會遵守其中一部分，而你無法預測是哪一部分。它不是故意挑，是它沒有辦法從十七個「最高優先」裡分出真正的優先。

我後來把這個現象叫做選擇性失憶。

這個詞是我取的，而且我要先把它的證據等級標出來：它是我在一段時間內、用特定幾個模型、在特定幾個專案上觀察到的行為模式，不是模型規格，也沒有做過對照實驗。這一整段——以及後面所有講「AI 會怎樣、不會怎樣」的地方。都是這個等級。模型會改版，這些觀察不保證明年還成立。而且它跟人一模一樣。如果你的主管每件事都說「這件最急」，你也會自己排優先序，然後排錯。

三、愈長愈容易漂移。

一百行的文件，你改動程式結構的時候還會記得回頭更新。五百行的文件，裡面一定有你忘記的段落，而那些段落會安靜地過期。

而過期的規範對 AI 來說不是失效，是誤導。它會照著一個已經不存在的結構去產碼，而且不會報錯。

而它的極端版本，我後來真的遇到了

上面講的是 591 行。**而另一個案子給我的是兩三百頁。**那份規範被完整地提供、被我們做成機器檢查、跑起來全綠。然後客戶說不符合規範，因為他們真正在用的那套從來沒有被寫進那兩三百頁裡。

兩三百頁的規範，比五頁的更危險。 因為五頁你知道它不完整，你會去問；兩三百頁看起來已經講清楚了，你不會去問。（那個案子後面會單獨講。這裡先記一句：第 0 層的問題不只是「愈長愈容易漂移」，還有「愈長愈讓人以為不用溝通」。）

所以第 0 層要薄

我現在的做法是把它壓在 100 行以內，而且只放三類東西：

一、鐵律，五條以內。

每一條都必須是真實踩坑換來的，而且新增時要附上決策紀錄的編號。初始狀態是空的。不是一開始就寫五條你認為重要的事，而是等它從實際的失敗裡長出來。五條滿了怎麼辦？汰換，不是加到第六條。這個上限是刻意的：它強迫你每次新增的時候回答「那要拿掉哪一條」，而這個問題會逼出真正的優先序。

二、指標——指路，不複製內容。

規格在哪、範例在哪、編碼規範在哪、決策紀錄在哪、配置的單一真相在哪

全部是路徑，沒有任何實質內容。憲法不告訴你命名規則是什麼，它告訴你命名規則寫在哪裡。

三、驗證指令。

跑測試的指令、跑結構檢查的指令、驗規格的指令。

就這三類。其他東西都不該在這裡。

這件事二十年前就有人講過了

寫到這裡我想岔出去一下，因為我後來讀到一段話，發現這個「薄」的主張並不新。

Alistair Cockburn 在《Agile Software Development》附錄裡討論 Naur 那篇論文的時候，問了一個一模一樣的問題：文件幾乎必然落後於程式的當前狀態，那到底該把什麼放進文件？

他的答案是一句斜體：

That which helps the next programmer build an adequate theory of the program.
（能幫助下一位工程師建立起關於這支程式的恰當理論的東西。）

而他建議的起手式，也是三樣：

不是同一份清單，但形狀完全一樣：都是「少數幾樣有目的的東西」，都不是窮舉。

而他收尾那句，我認為在 AI 時代比 2002 年更重要：

Documentation cannot—and so need not—say everything.
（文件無法、因此也不需要，把每件事都說完。）

為什麼更重要？因為以前「說完一切」是做不到的，成本擋住了你。現在做得到了。 你可以叫 AI 產出一份三百頁、格式整齊、什麼都寫了的規範文件，成本幾乎是零。

於是那條天然的煞車不見了。 而第 0 層要薄這件事，從「因為寫不完所以只好精簡」變成了一個必須刻意做的決定。(這也是為什麼我把上限訂成 100 行。不是那個數字有什麼道理，是它逼你每次都要選。)

演進方向：範例驅動

那第 0 層還能怎麼變強？

答案不是寫得更嚴厲，是改變表達方式：

用「範例」取代「條列規則」。

理由是一個我這一年最有感的觀察：

AI 模仿範例的能力，遠遠大於它遵守文字規則的能力。

你寫十條規則叫它「命名用駝峰式、錯誤處理要統一包裝、資料存取不可以出現在控制器」。它會遵守大部分，然後在某個你沒特別強調的地方漏掉，而且每次漏的地方不一樣。

但你給它兩個寫得很好的既有檔案，說「照這個樣子寫」。它模仿出來的東西在一致性上會明顯勝過照規則寫的。

而且它會模仿到你沒寫進規則裡的東西：註解密度、參數排列習慣、guard clause 放哪、測試命名的節奏。這些你很難寫成規則（寫出來會變成一百條），但範例裡全部都有。那個案子的規範文件裡其實有一段「禁止事項（具體範例）」，方向是對的，但密度不夠。

理想的做法是：每一條規則都附正反範例，而且在範例裡讓「違反的後果」具體可見。

❌ 這樣寫 → 會導致系統啟動失敗
✅ 這樣寫

比「請務必遵守」有效得多，因為它把抽象的規則變成了可以被模仿的形狀。

一個很小但有效的技巧

最後講一個成本極低的做法：預設值要刺眼。

如果你的模板裡有一個欄位需要人來填（例如「這條規則的來源是什麼」），不要留白。

• 留白：審核的時候會被滑過去。空白很容易被解讀成「不適用」，然後就過了
• 填一個刺眼的預設值（例如「未知，待確認」）：它會一直在那裡，逼人回答。而且你可以在文件裡搜尋「未知」來算出還有多少沒填

這是第 0 層少數幾個「便宜又有效」的招式。它不改變強度，但它改變了空白的可見度。

小結

第 0 層的定位是：最便宜、最快建立、但只能當基線。它的正確用法：

• 薄（100 行以內，鐵律 ≤5 條）
• 指路不複製內容（規則單一來源）
• 用範例取代條列（讓 AI 有東西可以模仿）
• 預設值刺眼（讓空白被看見）

它的錯誤用法：把所有規則都塞進來，然後用愈來愈強的語氣。明天講第 1 層。那一層要處理一個第 0 層處理不了的問題：AI 不知道「真實的值」是什麼。

參考文獻

1. Cockburn, A.（2006）。Agile Software Development: The Cooperative Game（2nd ed.）。Addison-Wesley。附錄 B〈Naur, Ehn, Musashi〉，其中〈Applying "Theory Building"〉一節見頁 405–406。
   — 文中「該把什麼放進文件」的三樣起手式、「clean code 就是讀者能多容易建立起連貫理論」、以及「Documentation cannot—and so need not—say everything」皆出自這一節，作者是 Cockburn。
   要特別註明：這一節裡提到的系統隱喻（system metaphor）是 Kent Beck 的主張，Cockburn 是引述他（原文寫的是 "Kent Beck suggested that…"）。那幾句關於 clean code 與文件的話，是 Cockburn 自己寫的，不是 Beck 說的。
2. 該附錄同時完整重印了 Naur 的原文（頁 393–405），是目前取得這篇論文最方便的正式出版管道之一。第 1 版（2002）與第 2 版（2006）分頁不同，引用時要註明版次。