--- title: "Anthropic 說可以信任模型判斷，我的 `CLAUDE.md` 分三層來實踐" description: "Claude 官方發布了 Claude 5 世代的 context engineering 新規則。我回頭檢視自己幾個月來寫的規則系統，發現不但符合文章精神，有幾個設計更好：依生效機制分層、多模型分級、防稀釋維護規則、傷疤鍛造的指令。這篇把做法與設定寫清楚。" pubDate: 2026-07-26 author: "jacobmei" category: "AI與科技" tags: [LLM, claude, fable5] canonical: https://jacobmei.com/blog/2026/0726-ctx3lr/ lang: zh-TW license: CC BY-NC 4.0 --- # Anthropic 說可以信任模型判斷，我的 `CLAUDE.md` 分三層來實踐 # Anthropic 說可以信任模型判斷，我的 `CLAUDE.md` 分三層來實踐 Anthropic 最近那篇 [The new rules of context engineering for Claude 5 generation models](https://claude.com/blog/the-new-rules-of-context-engineering-for-claude-5-generation-models)，講了六組「以前怎麼做／現在怎麼做」的對照：以前寫死規則，現在讓模型自己判斷；以前給範例，現在設計更有表達力的介面；以前把所有東西塞在最前面，現在漸進式揭露；以前靠重複強調，現在把指示寫進 tool description 就好；以前靠 `CLAUDE.md` 存記憶，現在讓模型自動記憶；以前給簡單的 spec，現在可以給測試套件、rubric 這種更豐富的參考資料。合起來就是他們把 Claude Code 的系統提示詞砍掉超過 80%，沒有看到可量測的品質下降。 很多人將這篇文章解讀成「模型變強了，規則不重要了」，然後教你怎麼去改你的 Claude.md 。 但我覺得不是這樣，文章裡有一句話我更在意： > [!note] > Claude 現在有 memory、artifacts、skills 可以用，代表它自己就能決定怎麼在 session 之間載入和分享 context。 換句話說，不是規則變少，是「誰來決定什麼時候載入什麼」這件事，從寫 prompt 的人手上，轉移到模型自己手上。這個轉移本身沒問題，但轉移的前提是 Opus, Sonnet, Haiku 等模型有能力能接得住，不然還是只能靠 Fable 打天下。 我過去這半年一直在整理 Claude Code 的規則系統，踩了一堆坑，拷貝了很多人的 Skill 回來學習和改善，但還是常常出現（特別是最近 Opus 好像變笨了）：模型跳過檢查、patch 重套、editable install 掩蓋發布問題、批次作業差點因為輸入範圍判斷錯誤整批重跑。 每次出事，最自然的反應都是「加一條規則，以後別再犯」。久了，`CLAUDE.md` 就越來越像事故現場的紀念碑，測試規定、Git 規定、安全規定、除錯流程、commit 前檢查、指令目錄、工具使用習慣，什麼都有，理論上很完整，但我愈來愈不確定模型到底有沒有真的抓住優先順序，還是每次 session 都背著一大包文字，偶爾從裡面撿到一兩條。 --- ## 我不再按主題整理規則 以前比較直覺的分類法，是把測試規則放一起、Git 規則放一起、安全規則放一起。人看文件時很合理，但模型不是照文件目錄在工作，它面對的是當下的 context：有些東西永遠在、有些需要時才載入、有些得等它自己想到才會去找，這三種規則失效的方式不一樣。 我現在大致規劃如下： |層級|位置|怎麼出現|放什麼| |---|---|---|---| |憲法層|全域 `CLAUDE.md`|每個 session 都在|行為底線、不可自行跨越的界線| |深度層|專案記憶／文件目錄|先讀索引，需要時展開|事故背景、案例、架構理由、過去決策| |機械層|Commands / skills|任務觸發才載入|發布、commit、批次處理等工作流程| 分這三層不是為了看起來有架構，是因為我發現，如果模型已經偏離基本紀律，它通常不會主動去載入一份叫做「紀律」的文件。不要假裝執行過測試、不要把推測寫成已驗證事實、碰到正式資料或不可逆操作先確認影響範圍、一個關卡沒過不要自己找理由跳過，這些不應該是有空再查的，而是每次都該做的事。但「發布 Python wheel 前要檢查產物內容」這種有明確觸發時機的東西，放在對應 command 裡更合理，不需要每次對話都佔位子。 Anthropic Blog 說的是 progressive disclosure，我後來比較習慣用另一種方式想：不要先問這條規則屬於測試、Git 還是安全，先理解若這條規則沒有被執行，或是他會在什麼時候失效。 --- ## 信任模型判斷這件事，不是所有模型都能照抄 這大概是原文最容易被誤用的地方。Claude Fable5 能少一點鉅細靡遺的規定，是因為它有足夠能力理解原則、辨認例外、自己補齊中間推理。但日常工作流裡不會只用一個最強模型，其他小型模型拿來做整理、轉換、簡單修補、跑檢查，中階模型可能負責某些子代理審查，比較難的設計、除錯、跨檔案推理才交給最強的模型，這些模型不能用同樣的規則來限制，會很慘（對，因為我的 Opus 就幾乎每天翻車，白眼）。 小模型常見的問題不是完全做不出來，而是卡住後還會硬往前走，把不確定性包裝成一句看似合理的話：「這應該沒問題」、「這個檢查先略過」、「雖然測試沒跑完，但改動不大」。這種時候給它更多抽象原則通常沒什麼用，它需要的是欄杆。 原文另外兩組對照剛好給了我所謂的邊界該長什麼樣子的線索。一組是用設計更有表達力的介面取代範例教學，文章舉的例子是 Todo 工具把狀態設計成 `pending / in_progress / completed` 這種 enum，模型光看參數就知道該怎麼用，不需要額外範例。另一組是用測試套件、rubric 這種可驗證的參考資料取代簡單的文字 spec。這兩件事合起來，其實就是我對其他模型的做法：不是寫更多說明文字讓它「理解」，是把驗收條件做成它可以直接對照的東西：狀態式的參數設計、跑得出結果的測試、grep 有沒有零命中等，這些不需要判斷力，只需要照著核對就好。 所以我的做法是憲法層儘量精簡，但機械層維持原狀。對需要由小模型執行的 command，我會把失敗處理寫得很硬：同一關卡修兩次還過不了，就停下來，附上已執行的指令、錯誤輸出、嘗試過的修法再升級，也不是因為第三次一定不會成功之類的，而是這時候多半缺的不是再亂槍打鳥的不斷測試，而是需要新的資訊。 然後最忌諱的是，不能只靠一句「請仔細分析」就希望模型很聰明的執行完，要列假設、找證據、逐項排除，不要留一個很大的自行思考空間然後期待它剛好走到正確答案，這和擲筊差不多。而 `grep` 有沒有零命中、測試有沒有全綠、輸入數量和輸出數量對不對得起來，這些能用機器判定的事，就不該完全單純的相信模型說「我檢查過了」就了事。 強模型需要留有邊界，讓它處理例外和整合；弱模型需要收斂，讓它在清楚的輸入、步驟與驗收條件下完成事情。原文說的「設計介面」跟「豐富參考資料」，某種程度上就是把「邊界」轉換成「收斂」的具體工具。 --- ## `CLAUDE.md` 不是維基 這是另一個這兩年我常犯的錯誤，我常常讓全域規則越來越大，每次翻車就加一條，久了以後原本應該是幾條高優先原則的 `CLAUDE.md`，變成把所有歷史事故都寫進去的操作手冊和維基百科，這邊很尷尬的是，就算定期整裡，但還是很容易不小心就無性增值的沒完沒了。 我現在給它一條有點殘酷的規則：想加東西進去，就得同時刪掉、合併，或壓縮別的東西，不是硬做字數守恆，而是逼自己檢視一遍：這條新規則到底要取代什麼？它重要到應該擠進每個 session，還是其實只適合出現在某個固定任務裡？ 照這個原則整理了一次，把生命週期流程圖搬出全域檔案、刪掉指令目錄（工具本來就會注入可用指令清單）、把 commit 前自審清單移到 commit command、把除錯升級表移到實際發生故障時才會用到的流程。最後 `CLAUDE.md` 少了約 47%，然後再開新的 Session 用 `/doctor` 跑了一次檢查確認。 不是說少了約 47% 一定比較好，這部分我還在累積經驗，不然「砍 prompt 以後感覺比較聰明」也很容易只是另一種確認偏誤 XD --- ## 規則最好帶著傷疤 我現在也比較少從最佳實踐清單或結果直接抄成功典範規則，不是說最佳實踐沒價值，模型其實越來越聰明，單看成功點費的組合規則經驗，很多規則會變得越來越像儀式，但問題是，怎麼錯的其實不太知道，要事後檢查，所以現在重要的 command 或規則，我會盡量留下它的來源，哪一次失敗讓它出現、當時的防線為什麼沒擋住、它到底在防哪一種錯。 然後我個人非常熱愛搭配 Spectra 結合 Sequential Thinking （雖然有人覺得 Sequential Thinking 沒有使用價值了，但我覺得善用它，會讓思維和程式品質都有客觀的提升），我在規劃開始後，都會至少留下三輪檢查：先驗證實際配置不只看預設值、用 dry-run 確認它眼中的輸入宇宙、在正式開工前就想好中斷續跑與去重策略。 還有一條是閾值。只要系統要用某個分數或門檻自動決定結果，我現在都要求先拿正例和最靠近界線的反例來重新測量，如果兩邊沒有分離帶，先不要急著調，因為那通常不是閾值選得不好，是拿來判斷的特徵根本不夠有辨識力。也因此補了一條很土但很實際的規定：量測工具要盡量用真實實作本體，一個簡化版模擬器看起來很快，但它若和真正引擎在同一份資料上給出相反結論，後面的精密調參只是往錯的方向跑得更快。 這些慘痛經驗不需要全部放在全域 prompt 裡，但該被留下來（我有用 Github 搭配，每次 commit 都會有軌跡留下），幫助我以後要修改規則時，知道這不是手賤隨手加上的 :P --- ## Commit 前檢查，是一個很典型的搬遷案例 現在的 commit 檢查大致有：跑 linter 檢查 patch 重套後留下的重複定義、看 `git status` 確保 `.rej`、`.orig`、備份檔沒有混進去、重構後搜尋舊 helper 確認新舊邏輯沒有並存、看相似呼叫端的錯誤處理是否一致、跑一份小型安全檢查（secret 比對、環境變數白名單、數字上下界與 URL 驗證）、把 staged diff 從頭讀完不只看 `--stat`。其中有些還是需要人來判斷，例如兩個呼叫端的錯誤語意算不算一致；但只要可以客觀驗證的地方，我就盡量不讓模型用一句「已檢查」帶過，因為模型最危險的時候，常常不是不知道，而是很自然地假設自己知道。 --- ## Context engineering，最後其實是治理問題 我現在也不太把 context engineering 理解成「提示詞怎麼寫比較強」，提示詞當然重要，但真正難的事情是：你要決定哪些規則值得常駐、哪些只該在任務發生時出現、哪些要留下事故背景、哪些應該變成測試或工具、哪些則該被刪掉。 這和維護一個逐漸變大的程式碼庫很像。程式碼不是越多越完整，規則也不是越多越可靠，你需要邊界、需要模組、需要知道依賴從哪裡來，也需要定期刪掉已經不再服務任何風險的東西。 Anthropic 把系統提示詞砍掉 80%，是因為不同規則不該全部擠在同一個 context 裡；但這件事是否適合每個 agent 都照抄，還是要取決於你真正的工作流，我這次重新檢視後，暫時得到的結論是：每條規則都該知道自己為什麼存在、該在哪裡生效、什麼時候可以退場，而且這個答案，對強模型跟弱模型可能完全不同。 --- ## 兩個常被問到的問題 **既然模型能自己判斷，為什麼還要留 `CLAUDE.md`？** 因為「模型有能力判斷」和「每一次都會在正確時機判斷」不是同一件事。專案記憶、搜尋、RAG 都很適合存放架構背景、事故紀錄、歷史決策，但前提是模型得先知道自己需要查，而且查得到正確的東西。底線不該依賴這件事。「不能假稱已執行測試」「動正式資料前先確認範圍」這類規則仍然該常駐，不是因為模型完全不懂，是因為不該把這種風險押在一次檢索有沒有剛好命中。Memory 比較像檔案室，全域原則比較像門口的規定，兩個都重要，但不能互相取代。 **Default-deny 不會讓模型動不動就卡住，最後都要人接手嗎？** 會，所以 default-deny 不能只寫成「失敗就停止」。如果模型停下來時只留一句「無法完成」，等於把問題丟回給人。真正有用的停止至少要留下：卡在哪個關卡、跑過哪些檢查、哪些輸出不符合預期、已經試過哪些修復、為什麼接下來需要新資訊或人工判斷。這樣人接手時不是從零開始。而且如果某個 command 很常把模型卡住，第一個該懷疑的通常不是模型夠不夠聰明，而是流程設計得不夠好，驗收條件不清楚、可觀測性不足、任務拆得太大。Default-deny 不是要製造停滯，是阻止模型在證據不足時硬闖。