【2026 最新】CLAUDE.md 指令膨脹怎麼整理？用 WHY、到期條件與定期稽核安全刪規則

CLAUDE.md 指令膨脹有一條很常見的路徑：每次 Claude 出錯，團隊就補一句「以後永遠不要再犯」，卻很少保存它的適用證據。問題修好了，規則仍沒人敢刪；半年後，同一份檔案同時裝著舊架構、例外、補丁與互相衝突的命令。

這不是紙上問題。一位維護超過一年的 repository 使用者近期直接問：是否該刪掉並重建舊 CLAUDE.md、Skills 與 Agents？答案不該是定期失憶，而是讓每條規則都能交代自己的生命週期。

這篇是《AGENTS.md 規則與驗收閘門》的維護續篇。前篇處理「規則該放哪裡」；本文只回答更棘手的一題：一條常駐規則怎麼出生、怎麼留下理由，又怎麼在不讓舊錯復發的前提下安全退出？

先給答案：規則的壽命，不能長過它的證據

你只要記住這個維護原語：

健康的持久指令＝WHAT＋WHY＋OWNER＋EXIT＋EVAL

做什麼、為何存在、誰負責、何時重新判斷、怎麼證明刪了也安全。

review_by 不是自動刪除期限，只是把規則送回人工審查。delete_when 也不是日期，而是可驗證的退出條件，例如「CI 已在每次合併前強制跑同一組回歸測試」。安全、權限或資料刪除相關規則，則不應交給自動清理。

CLAUDE.md 指令膨脹：這篇論文稱它為 Catastrophic Remembering

想像冰箱裡有一排沒有標籤的藥。你知道每顆都曾經救過某個人，卻不知道治什麼、誰放的、病人是否還需要；最安全的短期選擇就是全部留下。規則也是如此：指令還活著，當初加入它的理由卻先消失，於是追加很便宜，刪除很可怕。

2026 年 8 月 11 日提交的 arXiv v1 預印本《Why Does CLAUDE.md Keep Growing?》把 Agent 指令維護中的這個版本稱為 Catastrophic Remembering；它和較早 continual-learning 文獻的同名用法不同。研究合併分析 CLAUDE.md、AGENTS.md 與 copilot-instructions.md：1,867 個公開 GitHub repository、247,694 段指令生命週期。每個檔案最後追蹤版本的指令中位數為 39；在 1,576 個多版本 repository 中，64.3% 變長、26.6% 變短。把每個檔案第一版標準化後，平均 instruction-count 軌跡最高達 +226%，約為起點的 3.26 倍。

研究也做了受控實驗：在資訊註解處理組，後續維護者可看到規則的失敗脈絡、假設與結果，執行任務的 Agent 則看不到註解。到 51 輪時，無註解組相對 minimum cover 的 excess size 為 +211.3%，資訊註解組為 +1.4%，兩組最後 constraint satisfaction 都是 44.0%；不過這是 184 個 world、單一 seed，而且 minimum cover 只有 2～3 條限制，不能直接當成真實大型程式庫的保證。

更重要的是，論文沒有證明把一大段 WHY 直接塞給 Claude 就會變好。它測的是 executor 看不到的維護通道；在 184 個 world、單一 seed 的 ablation 中，executor-visible 組最後的多餘指令為 +28.5%，剝離版為 −0.1%；constraint satisfaction 相較剝離版低 1.7 個百分點，但 95% 信賴區間包含 0，沒有可辨識改善。

Claude Code 官方文件提供一種可實作的對應方式，但不是論文直接驗證的同一機制：block-level HTML 註解在 CLAUDE.md 自動注入 context 時會被剝離。Claude 若用 Read 工具直接開啟該檔仍會看見，Markdown code fence 內的註解也會保留；因此它適合承載不含敏感資訊的人類維護 metadata、降低常駐噪音，卻不是秘密或安全邊界。

先修 admission gate：不要每錯一次就加規則

Anthropic 現行指南把這些情況列為加入 CLAUDE.md 的訊號：同一個錯誤出現第二次；code review 抓到 Claude 本該知道的 repo-specific 問題；你跨 session 重複給同一修正；或新隊友也需要同一背景。本文據此把 admission gate 設為：第一次失敗先修程式、測試或任務描述，確認需要跨 session 保存後，再升級成持久指令。

1. 確認復發：它是第二次同型錯誤，還是一次性的模糊需求？
2. 找真正根因：缺的是 repo 事實、操作流程，還是本來就該由 CI 擋下的錯誤？
3. 選對載入範圍：每個 session 都需要才放 root；特定路徑放 scoped rule；偶爾才做的多步驟流程移到 Skill。
4. 寫成可驗證動作：不要寫「仔細測試」，要寫何時跑哪個命令、什麼結果才算通過。
5. 附上生命週期資料：至少有 owner、失敗證據、建立日、複查日與退出條件。
6. 先做回歸 fixture：沒有重現案例，就無法知道未來刪除是否讓問題復發。

若要求不依模型判斷而強制阻擋，別只寫進 CLAUDE.md。改用針對正確事件與 matcher 設定、並測過等價命令的 PreToolUse command hook，或 managed permissions／sandbox／CI；prompt 或 agent hook 仍含模型判斷，不能一概當成 deterministic。這也是 Agent Harness 的責任。

一條可刪的規則，應該長這樣

假設 Agent 曾兩次修改登入流程，卻只跑 root test，漏掉 token refresh suite。完整事件脈絡可放進 CLAUDE.md 的獨立 block-level HTML 註解；實際貼進檔案時不要再包一層 Markdown code fence。Claude 真正需要理解的短理由，才留在可見規則：

<!--
rule_id: auth-test-before-handoff
owner: @platform
source: PR-482
created_at: 2026-08-14
review_by: 2026-09-14
delete_when: CI blocks merges unless auth regression passes
evidence: recurrence=2; eval=evals/auth-refresh.yaml
why: root test missed token-refresh regressions twice
-->

- When files under `src/auth/**` change, run `pnpm test:auth`
  before handoff.
  WHY: the root test command does not include the auth refresh suite.

source 應連得回 issue、PR 或 incident；evidence 要記錄失敗、假設、實際結果與復發次數，不是只寫「某人說這很重要」。如果 WHY 只服務未來維護者，就全部放註解；如果 Claude 需要它才能判斷例外，才保留一句最短的可見理由。

這條規則也不必讓所有工作常駐載入。把可見指令移到 .claude/rules/auth-testing.md，用 paths frontmatter 限定 src/auth/**；多步驟 runbook 則改成按需 Skill。官方目前明文保證 comment stripping 的範圍是 CLAUDE.md，規則搬進 .claude/rules/ 時，可把 lifecycle record 留在連結的 issue／PR，別把未經文件保證的行為當成隱藏通道。單純用 @import 拆檔只改善排版，imported content 仍會載入，不會替你省 context。Skill 太多時，再用《Skill Router 教學》處理路由與按需揭露。

再修 deletion gate：期限到，只代表該重新舉證

「三十天沒觸發就刪掉」看似乾淨，實際上可能只是三十天沒遇到危險情境。論文的資訊註解組有 12.1%（67／552）的 world 最終成為空 prompt，無註解組為 2.4%；在這批較困難的 world 中，兩組 satisfaction 相差 −2.0 個百分點，但 95% 信賴區間包含 0。這不足以宣稱正確率顯著失守，卻足以揭露過度刪除的尾端風險；作者因此建議把人保留在刪除路徑、設定 pruning floor，並先排除尚未另行測試的安全規則。實務上可用六步驟：

1. 由 owner 讀回 WHY：原始事故還能重現嗎？相關程式與工具是否已改變？
2. 分類候選：過時就刪；重複就合併；只在局部需要就下放 scoped rule；多步驟流程就移到 Skill；硬性底線就升級到 CI 或 hook。
3. 建立 candidate branch：先移除或搬動規則，不要直接改主線。
4. 重跑原始失敗：同一 fixture 必須通過，安全案例不得退步。
5. 跑正反案例：不只測「該觸發」，也測文件修改等「不該觸發」任務。
6. PR 留下結論：記錄測試、差異與退出理由；失敗就恢復原文，不靠記憶重寫。

前面的 auth 例子，在 CI 已強制執行 test:auth 後就達成 delete_when。此時不是把保護拿掉，而是把「模型可能遵守的提醒」換成 CI 的強制檢查；配合同一組回歸 eval，這才是風險較低、可驗證的刪除候選。

如何做 CLAUDE.md 指令膨脹 A/B test？

A 組保留目前的歷史累積版，B 組使用 candidate 精簡版；兩組固定同一個 repo commit、Claude 版本、模型、權限與設定，每個任務開全新 session。Anthropic 的 Agent eval 指南也建議使用穩定環境、明確 grader、隔離 trial、重複多次，並以結果為主，不把固定步驟誤當成功。

新手可先準備 8～12 個真實任務，每題跑 3 次作為 smoke test；這不是統計證明，但比「感覺 Claude 變聰明」可靠。題庫應同時含會命中規則的 auth 修改、不得命中的文件修改，以及權限／刪除等安全案例。若使用內建 Explore 或 Plan subagent，要注意官方文件說它們會跳過 CLAUDE.md；A、B 必須用相同執行路徑。

至少記五個欄位：task pass rate、安全回歸數、每題 total tokens、延遲、衝突或不必要行為。同時讀 transcript，分辨是規則沒載入、被衝突覆蓋，還是 task 本身含糊。可用《AI Evals 教學》建立 fixture 與 grader，再以《Agent Observability》追蹤長期趨勢。

月度與 PR 稽核：把 CLAUDE.md 當會腐化的程式碼

Anthropic 在官方 Claude Code 維護文章建議為共用 CLAUDE.md 指定 owner、像 code 一樣 review，並定期刪除 stale guidance；官方 Help Center 提供的基準節奏是每季快速檢查。高變動團隊可把它延伸成月度稽核，任何修改 CLAUDE.md 或 .claude/rules/ 的 PR 則即時觸發審查。

• 載入面：用 /context all 看實際占用，/memory 檢查來源，必要時用 InstructionsLoaded hook 記錄何時、因何載入。
• 健康面：活躍指令數、無 owner／WHY／review_by 的規則數、全域與 scoped 比例、重複與衝突數。
• 行為面：固定 eval 的成功率、安全回歸、tokens／task、延遲與人工介入次數。
• 處置面：/doctor 可提出 trimming 建議，但仍要像 review diff 一樣逐條確認，不能自動接受。

別把「低於 200 行」當 KPI。官方把每份 CLAUDE.md 低於 200 行列為目標，不是 parser 硬上限；真正目標是每條常駐內容都與本次工作相關、沒有矛盾，而且可被驗證。

六個最常見的清理陷阱

1. review_by 一到就自動刪：日期只觸發複查，刪除要看 outcome 與回歸測試。
2. 只追求最短：短 prompt 若遺失關鍵安全規則，仍是失敗。
3. 把檔案切碎就算瘦身：@import 仍載入；沒有 paths 的 rules 會在啟動時無條件載入。
4. 把完整事故報告送給 Agent：CLAUDE.md 自動注入時可用 block-level HTML 註解降低常駐噪音；scoped rules 的紀錄留在 issue／PR，可見 WHY 只保留執行判斷需要的部分。
5. 用自然語言代替強制層：付款、刪檔、權限與 secret 邊界應由經測試的 command hook、managed permissions／sandbox 或 CI 保證。
6. 沒有原始 fixture 就刪：你無法證明舊錯不會復發，只是把未知風險改名為整理。

CLAUDE.md 指令膨脹 FAQ

CLAUDE.md 超過 200 行就會失效嗎？

不會突然失效。200 行是 Anthropic 的建議目標，不是硬上限；長檔仍會載入，但占用更多 context，也可能降低遵從度。

每條規則都一定要寫 WHY 嗎？

維護上應該有，模型端不一定要看完整版本。在 CLAUDE.md 可把非敏感的事故、假設與結果放 block-level HTML 註解；若是 scoped rule，完整紀錄留在 issue／PR。只有 WHY 能幫 Claude 判斷何時套用時，才保留一句可見理由。

review_by 到期可以讓 bot 自動刪嗎？

不可以直接刪。到期只建立 review 任務；owner 仍要確認退出條件、重跑 fixture，安全規則還要人工核准。

把長內容拆成 @import 就會省 token 嗎？

不會。import 只改善組織，內容仍會載入。要減少無關 context，使用有 paths 的 scoped rules 或按需 Skill。

哪些規則絕對不該自動清理？

安全、權限、付款、刪除資料與 secret 邊界。這些應先升級到 deterministic gate，再由人審查文字規則能否退出。

A/B test 只看 token 變少就夠嗎？

不夠。先要求任務成功不退步與安全零回歸，再比較 token、延遲、衝突與不必要行為；省 context 不能交換正確性。

什麼情況該刪，什麼情況該搬家？

過時或重複才刪；仍有效但範圍太大就搬。局部慣例移到 scoped rule，多步驟流程移到 Skill，硬性要求移到 CI 或 hook。

這篇論文已證明 owner 和月度稽核有效嗎？

沒有。論文直接測的是保存失敗理由與結果的隱藏註解；owner、review_by、PR gate、月度稽核與真實 repo A/B，是本文根據研究機制與官方維護建議延伸的流程。