前言：「道理我都懂，但每次都要重講一遍很累」

昨天講完怎麼引導 AI 先跑一次 Outside-In 流程，很實際的問題馬上浮現：如果每一次開新對話、每一個新功能,都要重新打一長串「先列業務規則、寫成 Given-When-Then、確認完整再動手實作」的指示，這件事本身就會變成一種負擔——負擔一大，人就會偷懶，偷懶了幾次之後，這套紀律就會慢慢名存實亡。

今天要講的，是怎麼讓這套紀律不需要每次重講，變成 AI 在這個專案裡預設就會遵守的行為。做法並不神秘：把規則寫進 CLAUDE.md，或者包裝成一個可以重複載入的 Skill。

今日目標

• 理解 CLAUDE.md 的角色：它是專案層級、每次對話都會被讀取的「持久指引」，不是一次性的 prompt
• 理解 Skill 的角色：把一組更完整的流程（步驟、檢查清單、範例）打包成一個可以隨時載入、重複使用的單元
• 看懂「寫進 CLAUDE.md」跟「臨時在對話裡交代」這兩種做法，在紀律持續性上的差異
• 認識這件事本身就是把「產生程式碼的規則」這句話,從抽象原則落地成具體檔案的最後一哩路
• 建立一個實際可行的起手式：從一條最容易被忽略、卻最重要的規則開始寫起

CLAUDE.md：把規則寫下來，而不是靠每次記得講

CLAUDE.md 這類機制的價值,在於它把「這個專案該遵守什麼規則」從「存在於某個人腦中、要靠他每次記得提醒」，變成「寫在一份會被自動讀取的文件裡」。這件事聽起來很基本，但它解決的正是這系列從 Day 1 開始就在講的核心問題——人的記憶力跟耐心是有限的資源，尤其在面對一個產出速度極快的協作對象時，你沒有餘裕在每一次互動裡,重新覆述一次所有的邊界條件。

具體到這個系列反覆講的紀律，值得寫進 CLAUDE.md 的規則,大致包含這幾類：

• 流程順序：新功能開發要先列業務規則、寫成驗收測試,再進入實作，不要跳過這個順序
• 複雜度預算：某一類需求（例如新增欄位）的合理改動檔案數區間是多少
• 禁止事項：不要為了「以防萬一」預先建立沒有測試要求的抽象層（Repository、Event、Cache 後端等）
• 檢查清單：完成實作後，要自己核對「這個類別是被哪一條測試逼出來的」

這正是這個系列主題句最終要收斂的地方：AI 沒有發明過度設計，它只是讓過度設計的速度追上了你按下 Enter 的速度；Review 要跟得上，審的就不能再是程式碼本身，而是產生程式碼的規則。 把這條規則寫進 CLAUDE.md，就是讓「規則」兩個字，變成一份 AI 每次對話都會先讀到的真實文件,而不是停留在某次對話裡講過、下次就被遺忘的口頭約定。

Skill：把更完整的流程打包成可重複載入的單元

如果一條規則只是「一句話禁止事項」，寫進 CLAUDE.md 就足夠；但如果是一整套流程（例如「先列業務規則→寫成 Given-When-Then→人工確認→逐條逼出最小實作→完成後自我檢查」這種多步驟、帶檢查清單的流程），把它包裝成一個獨立的 Skill 會更合適——Skill 可以在需要的時候被明確載入，內容可以比 CLAUDE.md 更詳細，也更容易被單獨修改、單獨驗證，而不會讓 CLAUDE.md 本身變得又長又雜。

實務上，這篇系列文章本身的寫作專案，就是用這個方式在運作的：有一份 CLAUDE.md 定義整個寫作專案該遵守的通用規範（例如寫作結構、事實查核流程），另外有專門的 Skill 負責承載更具體、更長的操作流程（例如某種風格指南、某個檢查腳本該怎麼跑）。這個分工方式本身,就是「規則要分層次存放」的一個實際案例——通用、簡短的規則放在 CLAUDE.md,具體、較長的流程包裝成 Skill，需要時才載入。這裡只講這個分工概念本身，不涉及這個寫作專案其他系列的具體內容。

常見誤區：把規則寫得太抽象，AI 沒辦法真的照做

寫 CLAUDE.md 最容易犯的錯誤,是把規則寫成「不要過度設計」這種抽象口號。這句話人類讀了會點頭,但它沒有給出任何可以被具體執行的判斷依據——「什麼叫過度設計」本身就是一個需要更多上下文才能回答的問題。

❌ 常見但不夠具體的寫法：

## 開發規範
- 不要過度設計
- 保持程式碼簡潔

✅ 更具體、可執行的寫法：

## 開發規範
- 新功能開發前，先列出完整業務規則，
  寫成 Given-When-Then 驗收測試，讓我確認清單完整後才開始實作
- 實作階段只寫「讓現有測試變綠」所需的最小程式碼，
  不要新增任何測試沒有要求的類別、介面或抽象層
- 新增一個純資料欄位（無新業務規則）的改動，
  預期落在 3-5 個檔案；超出這個範圍時，
  請在說明裡列出多出來的檔案分別是為了滿足哪一條規則

第二種寫法的每一條,都能直接對應到一個「AI 做完之後，人可以核對是否有遵守」的具體標準,這才是讓規則真正變成「預設值」而不是「裝飾用的口號」的關鍵。

今日思考題

如果你現在要幫自己的專案寫第一條「防止過度設計」的規則,你會挑哪一條先寫進 CLAUDE.md——是流程順序、複雜度預算，還是禁止事項？為什麼是這一條而不是別條？

今日重點回顧

• CLAUDE.md 的價值在於把規則從「靠人記得每次提醒」變成「AI 每次對話都會先讀到的文件」
• 多步驟、帶檢查清單的完整流程適合包裝成 Skill，簡短的通用規則留在 CLAUDE.md
• 規則要寫得具體、可核對，抽象的口號（如「不要過度設計」）沒辦法被真的執行
• 這件事是把「產生程式碼的規則」從系列主題句裡的抽象概念,落地成真實檔案的最後一步

明日預告

Day 23 是第三部的收斂：給出一個具體的 Review 分工框架——人定規則、工具驗證、AI 產生，把這幾天講過的 Outside-In TDD、架構測試、複雜度預算、CLAUDE.md／Skill,全部放進同一張分工圖裡。

老派工程師的心得

我以前對「寫文件」這件事一直有點消極——覺得規則寫在文件裡，也不保證有人會看、有人會照做，倒不如花時間直接盯著 code review。這幾年跟 AI 協作之後,我對這件事的態度整個翻轉：AI 不會嫌規則寫得囉嗦,也不會因為心情不好就跳過檢查清單，只要規則寫得夠具體，它幾乎每次都會照做——這反而讓「把規則寫清楚」這件事，從一件性價比存疑的苦差事，變成投資報酬率最高的一步。人會忘記、會偷懶、會嫌流程麻煩,AI 不會，這是我這幾年重新學到,關於「寫文件」這件事最實際的一課。