前言：一份規則文件，是設計出來的，還是長出來的？

「CLAUDE.md 這種規則文件，應該是團隊坐下來，一次把所有規矩想清楚、寫完整的吧？」

如果你真的動手寫過一份給 AI 用的規則文件，會發現事實幾乎相反。今天要講一個通用但真實反映日常運作的模式：一份規則文件很少是「設計」出來的，多半是一次一次被使用者糾正後,長出來的——每一條看起來理所當然的規則,背後往往藏著一次具體的失敗。

一條規則的誕生：先有事件，才有條文

想像一條常見的規則:「不要用寬鬆比對迴避判斷」。單獨看這句話,像是憑空立下的最佳實踐,任何一本軟體工程書都可能寫得出來。但如果這條規則真的出現在一份團隊的 CLAUDE.md 裡,它背後幾乎一定有一個具體事件:AI 在寫測試時,遇到新舊兩個版本輸出的內容有些微差異,不確定這個差異是不是刻意的,於是選擇了一個看起來安全的做法——把斷言放寬（例如去掉頭尾空白後再比對、或只比對部分欄位），讓測試先過關,再說。

問題是,這個差異可能根本不是無關緊要的空白,而是一個真正的行為改變。使用者當場抓到這個放寬的斷言,指出:「你不是在驗證『新舊行為一致』,你是在讓測試看起來通過。」這次糾正,才變成了那條規則。

規則不是先想出來再套用,是先犯錯、被糾正,才回頭寫成一句能被下次套用的條文。 這個順序很重要,因為它決定了規則帶不帶「為什麼」——用一組對照來看差異:

❌ 只有條文,沒有事件:
「規則：斷言要精確,不要用寬鬆比對。」
→ 讀者知道「要這樣做」,但不知道「為什麼」,
  遇到一個看起來例外的情境時,無法判斷這條規則
  適不適用（例如：真的只是格式差異,能不能放寬?）

✅ 條文帶著事件:
「規則：斷言要精確,不要用寬鬆比對迴避判斷。
 背景：曾經因為不確定新舊輸出的差異是不是刻意的,
 選擇放寬斷言先讓測試過關,結果掩蓋了一個真正的
 行為改變,被使用者當場抓到——正確做法是先查出
 真正的值、判斷這個差異該不該保留,再對精確值斷言。」
→ 讀者理解這條規則要防的是什麼情境,
  遇到看起來例外的狀況時,能自己判斷這條規則
  適不適用,而不是機械式套用

為什麼「帶著事件」的規則更耐用

一份只寫條文、不寫事件的規則文件,有個隱藏的脆弱點:遇到規則沒有明講的邊界情況時,執行者（不管是 AI 還是人）沒有辦法推論這條規則的精神,只能死板套用或乾脆忽略。

但如果規則帶著「當初為什麼會有這條規則」,遇到邊界情況時,可以回頭問:「這個情境跟當初那次事件的核心問題一樣嗎?」如果一樣,規則適用;如果不一樣（例如這次的差異真的只是格式,已經確認過不影響行為）,可以做出更精準的判斷,而不是盲目套用一條字面上寫死的規則。

這正是這個系列的主題句在規則文件本身的展現:一份沒有清楚驗證機制、沒有留下「為什麼」的規則文件,退化的方式就是變成一堆條文,執行者只能猜測適用範圍,猜錯了又要再糾正一次,規則越長越多,但沒有真的變聰明。

規則演化史的另一面：舊規則也會被推翻或收斂

規則演化不只是「加新規則」,有時候是原本的規則被發現不夠精確,要收斂或改寫。例如原本一條規則寫「重構時不要一次改太多檔案」,後來發現真正的問題不是檔案數量,是「有沒有測試覆蓋」——於是規則被改寫成更精確的版本:「重構前先確認有沒有測試覆蓋,沒有覆蓋就先停手」。表面上規則變了,實際上是同一個問題被理解得更透徹,舊條文只是階段性的近似值。

這代表規則文件不該被當成一份寫好就不動的合約,而是持續在跟真實案例對照、修正的活文件——每一次「這條規則好像不太對」的懷疑,都值得回頭追那條規則最初是為了防什麼而寫的。

今日思考題

回想你手上任何一份團隊規範、SOP、或給 AI 用的規則文件:裡面有沒有哪一條規則,你其實不知道它當初是為了防什麼而寫的?如果拿掉這條規則,你有把握不會重蹈覆轍嗎?

今日重點回顧

• 一份規則文件多半不是設計出來的,是一次一次被使用者糾正後長出來的,每條規則背後往往藏著一次具體的失敗
• 「帶著事件」的規則比「只有條文」的規則更耐用,因為執行者可以推論規則的精神,判斷邊界情況適不適用
• 沒有留下「為什麼」的規則文件,退化的方式是變成一堆只能死板套用或忽略的條文
• 規則演化不只是加新規則,也包含把原本不夠精確的規則收斂成更準確的版本

明日預告

明天要往上升一層,討論一個貫穿整個系列的問題:AI 協作有哪些決定,不管流程設計得多完善,都不該讓 AI 自己拍板。