Claude Code 作者叫你每半年刪掉 CLAUDE.md？真正該做的是「指令斷捨離」
Boris Cherny 建議每半年測試移除 CLAUDE.md、Skills 與 Hooks。重點不是清空專案知識，而是找出過期 Prompt，保留真正重要的規範。
Claude Code 創作者 Boris Cherny 最近在 Y Combinator Startup School 2026 的訪談中，給了一個很容易被截成聳動標題的建議：每隔一段時間，刪掉你的 CLAUDE.md、Skills 和 Hooks，看看模型在沒有這些設定時會怎麼做。
這句話的重點不是「文件都沒用了」，而是很多 AI 工作流程正在累積一種新的技術債：為舊模型缺點寫下的補丁，到了新模型仍被當成永久規則。它們不只佔用 context，還可能讓更有能力的模型照著過時方法工作。
我的結論很直接：不要在正式專案裡無條件刪除所有設定，但值得每季或每次更換主力模型時，做一次可還原的空白基準測試。真正該刪的是已經失效的模型補丁，不是模型無法自行知道的專案事實、團隊決策與安全邊界。
Boris Cherny 到底說了什麼？
Boris Cherny 是 Anthropic 的 Head of Claude Code。Y Combinator 在 2026 年 7 月 25 日至 26 日舉辦 Startup School 2026，並在官方 YouTube 頻道公開這場訪談。影片標題直接寫著：「We Cut 80% of Claude Code’s Prompt」。
訪談談到一個核心現象：模型進步後，過去為了修正模型行為而加入的許多提示，可能已經不再必要。Boris Cherny 因此建議 Claude Code 使用者每 6 個月嘗試拿掉 CLAUDE.md、Skills 和 Hooks，先觀察模型的原始表現，再決定哪些指令真的需要加回來。他接著補充，只有模型在同一件事上反覆出錯時，才應該把相關指令加回去。這段完整說明可從官方影片的 6 分 55 秒開始觀看。
這比較接近軟體開發中的消融測試（ablation test）。白話來說，就是暫時移除一個元件，看看結果是否真的變差。若拿掉某條指令後，模型仍能穩定完成任務，那條指令就可能只是在消耗 context；若模型反覆犯下同一個錯誤，再把最少量的必要規則加回去。
Y Combinator 官方訪談從 3 分 30 秒開始討論 Claude Code 刪除 80% system prompt 的原因。
社群截圖把它濃縮成「每 6 個月刪除 CLAUDE.md」，方向沒有錯，但很容易漏掉最重要的動作：先保留可還原版本、設計測試案例，再比較移除前後的結果。沒有比較基準的刪除，只是冒險，不是優化。
為什麼 Prompt 和 Skills 也會變成技術債？
很多人的 CLAUDE.md 不是一次設計完成，而是模型每犯一次錯，就補上一條規則。久而久之，檔案裡可能同時存在三代模型留下的修補方式，甚至出現互相衝突的指令。
例如，舊模型可能需要你逐步指定「先找檔案、再讀函式、接著修改第幾行」。但 Anthropic 最新的 Claude Code context 指南 已建議使用者描述成果與原因，讓 Claude 自行探索程式庫。當模型已具備搜尋與規劃能力，過細的步驟反而可能把它鎖在錯誤路徑上。
另一個問題是訊號被稀釋。Anthropic 的 Claude Code steering 指南 指出，專案根目錄的 CLAUDE.md 會在工作階段開始時載入，而且每一行都會消耗 context。檔案越長，真正重要的限制就越容易埋在大量低價值說明裡。官方因此建議把檔案控制在約 200 行以內，指定負責人，並像審查程式碼一樣審查每次變更。
這裡真正值得注意的不是節省幾個 token，而是讓模型更容易分辨什麼最重要。當「按鈕使用品牌藍色」和「禁止測試寫入正式資料庫」被放在同一層級、用相同語氣呈現，模型收到的優先順序其實很模糊。
哪些內容可以刪？哪些不能直接刪？
判斷方式可以簡化成一句話：更聰明的模型能不能只靠讀取專案，自行推導出這件事？
| 指令類型 | 範例 | 建議處理方式 |
|---|---|---|
| 舊模型行為補丁 | 不要重複結論、不要寫過多註解、先自己搜尋檔案 | 優先移除並重新測試 |
| 可從工具取得的資訊 | 完整 API 文件、檔案列表、過長的模組說明 | 改成索引或讓模型按需讀取 |
| 專案事實 | 使用 pnpm、測試指令、目錄用途、特殊部署環境 |
保留，但維持精簡與最新 |
| 團隊決策 | 命名慣例、錯誤處理方式、指定套件、分支規則 | 保留，因為模型無法猜出團隊選擇 |
| 可重複程序 | 發版流程、安全審查清單、資料遷移步驟 | 移到 Skill，任務需要時再載入 |
| 強制安全規則 | 禁止危險指令、提交前一定要跑 lint、阻擋正式環境寫入 | 不只寫 Prompt，改用 Hook、權限或 CI 強制執行 |
這張表也解釋了為什麼「全部刪除」不適合直接套到正式團隊。一個更強的模型可以知道 React 的一般寫法，卻不可能憑空知道你的公司決定使用哪套驗證流程，也不會自動理解某個舊資料表仍被外部客戶依賴。
尤其是安全與合規規則，不能只依賴模型記得。Anthropic 官方也明確提醒，遇到「每次都必須做」或「絕對不能做」的要求，應該使用 Hooks、permissions 或 CI 等確定性機制。Hooks 是在指定事件發生時由系統觸發的自動化，不是請模型自行判斷要不要執行。換句話說，真正不能出錯的規則，本來就不該只放在 CLAUDE.md 裡。
CLAUDE.md、Skills、Hooks 該怎麼分工？
CLAUDE.md 適合放模型在整個工作階段都要知道的專案背景，例如建置指令、核心架構、目錄配置與團隊慣例。它比較像新成員第一天會拿到的專案簡介，而不是完整操作手冊。
Skills 適合封裝可重複、但不是每次都會用到的程序。像是「如何發布 staging」、「如何做資安審查」或「如何產出固定格式的變更紀錄」，只有任務需要時才載入，可以避免長流程一直佔用主要 context。
Hooks 則負責一定要發生的動作。例如每次修改檔案後自動執行 formatter、提交前跑 lint，或在模型嘗試執行危險指令時直接阻擋。這類要求若只寫成自然語言，模型仍可能在長對話、模糊情境或遭遇 prompt injection 時漏掉。
最實際的原則是：背景放 CLAUDE.md，程序放 Skills，強制執行交給 Hooks、permissions 或 CI。不是每種設定都該刪，而是每條設定都要待在正確的位置。
一套不會破壞正式專案的「指令斷捨離」流程
如果你想測試 Boris Cherny 的建議，不需要真的把設定永久刪掉。以下流程比較適合個人開發者與團隊使用。
第一步：建立可還原版本
先確認 CLAUDE.md、Skills 與 Hooks 已納入 Git，或複製到不會被 Claude Code 自動載入的封存目錄。測試應該在新分支、測試專案或隔離環境進行，不要直接拿正式部署流程當第一個案例。
第二步：替每條規則分類
把內容分成「模型補丁、專案事實、團隊決策、可重複程序、強制規則」五類。若一條規則混合兩種目的，就把它拆開。光是這一步，通常就能找出重複、互相衝突或已經無人理解的內容。
第三步：先移除模型補丁
專案事實與團隊決策先保留，只拿掉為舊模型行為設計的微管理指令。這比一次清空全部設定更容易定位差異，也較適合沒有完整 eval 系統的小型團隊。
第四步：用代表性任務比較
Eval 是用固定案例衡量 AI 表現的測試。你不必先建一套大型平台，可以從 5 至 10 個常見任務開始，例如修一個 bug、增加 API 欄位、補測試、整理重複程式碼，以及完成一次不寫入正式環境的部署演練。
比較時至少記錄四件事：結果是否正確、需要人工糾正幾次、完成時間，以及是否違反重要限制。只比較回答看起來順不順，無法判斷舊規則是否真的有價值。
第五步：一次只加回一條
若模型在同一類任務反覆出錯，先找出最小原因，再加回一條能解決問題的指令。不要一次恢復整份舊檔，否則你仍然不知道是哪條規則發揮作用。
第六步：讓規則有負責人與淘汰日期
Anthropic 官方建議定期檢查 CLAUDE.md，刪除過期內容。實務上，可以替每條非顯而易見的規則記錄原因或對應案例，並在主力模型升級、框架更換或每季檢查時重新測試。這會比死守「每 6 個月全部刪除」更容易維護。
從 PM 角度看，重點不是 Prompt 寫得多完整
這件事對 AI 產品團隊最大的提醒，是不要把 Prompt 當成只進不出的知識庫。每次模型出錯就加規則，短期看起來很快，長期卻會讓團隊無法回答一個基本問題：目前的品質到底來自模型、工具、資料，還是某條沒人敢刪的 Prompt？
更成熟的做法是把重要行為變成可測量的產品規格。輸出格式可以用 schema 驗證，程式品質可以用測試與 lint 檢查，權限可以由系統限制，只有難以形式化的偏好與專案背景才交給自然語言指令。
這也代表，模型升級不能只看 benchmark。團隊應該用自己的代表性任務重新跑一次基準，確認哪些舊指令已經沒有幫助、哪些規則仍是產品不可缺少的護欄。模型越強，Prompt 不一定要越長，但驗收標準反而要更清楚。
FAQ
CLAUDE.md 是什麼？
CLAUDE.md 是 Claude Code 會自動讀取的 Markdown 專案說明檔。它適合放建置與測試指令、核心架構、目錄用途、團隊慣例和已知陷阱，讓 Claude 在每次工作時掌握必要背景。
真的要每 6 個月刪掉 CLAUDE.md 嗎？
不建議在正式專案裡無條件永久刪除。比較安全的做法是先封存，再於隔離環境移除舊模型補丁，用固定任務比較結果。真正有效的規則才逐條加回。
CLAUDE.md 越詳細，Claude Code 表現越好嗎？
不一定。過長、重複或互相衝突的指令會稀釋重要訊號。Anthropic 建議根目錄的 CLAUDE.md 維持短而密集，約控制在 200 行以內，其他內容改用路徑規則、Skills 或外部文件按需載入。
Skills 和 Hooks 也要刪嗎？
可以定期停用並測試，但兩者不能混為一談。Skills 多半是可重複程序，應檢查內容是否仍符合新模型與現行流程；Hooks 常負責確定性自動化或安全阻擋，刪除前必須確認已有其他機制接手。
沒有完整 Eval 平台也能做嗎？
可以。先挑 5 至 10 個最常見且結果可驗證的任務，記錄正確率、人工修正次數、完成時間與規則違反情況。小型測試已經比憑感覺決定 Prompt 去留可靠許多。
結論：刪除不是目的，重新證明每條指令的價值才是
Boris Cherny 的建議之所以引起討論，是因為很多人已經把 CLAUDE.md 和 Skills 當成不可碰的資產。但在模型快速迭代的情況下，六個月前有效的 Prompt，今天確實可能只是舊模型留下的拐杖。
不過，專案知識、團隊決策與安全機制不會因模型變聰明就自動被理解。最合理的做法不是全部保留，也不是全部刪除，而是定期建立空白基準、用真實任務測試，再讓每一條指令重新證明自己值得存在。
如果一條規則無法說明它防止什麼錯誤，也沒有測試能證明它有效，那它很可能只是 Prompt 技術債。反過來說，若一條規則關係到安全、權限或正式環境，就不該只寫在 Prompt 裡，而應升級成系統真正會執行的護欄。
