Claude Code負責人叫你每6個月刪掉CLAUDE.md,我照做之前先量了一遍(常載31,391字)
直接回答
「每6個月刪掉CLAUDE.md」這個建議要打折執行,因為它針對的是矯正型規則,不是偏好型規則。Boris Cherny刪掉的是Anthropic給全世界使用者的通用系統提示詞,那些是在補模型當時做不到的事,模型變強就過期;個人的CLAUDE.md有一半是偏好,例如標點格式、語氣、回覆優先順序,模型再強也猜不到,永遠不會過期。我實測自己的設定,每次開場常載31,391字,只佔1M context約2到3%,所以刪規則的理由不是省空間,是解綁。
有人丟給我一篇訪談整理,標題是Claude Code負責人建議每6個月刪掉你的CLAUDE.md、skills和hooks。
我沒有照著那份整理稿往下分析。先去查了原始訪談,然後發現整理的人漏掉最關鍵的一段。
—
那篇整理稿漏掉的一段
Anthropic的Boris Cherny在Y Combinator的訪談(2026年7月28日釋出)說,他們為了Opus 5刪掉了Claude Code 80%的系統提示詞,方法叫ablation:全部刪光,再一行一行加回去,量每一行的實際影響。
這部分是真的。他也確實建議一般使用者每6個月刪一次自己的CLAUDE.md、skills、hooks。
問題出在文章拿來當「讓模型自己跑」最強證據的那個案例。
Bun這個JavaScript執行環境原本用Zig寫的,讓AI整包改寫成Rust,11天完成。整理稿說能做到是因為Bun本來就有很完整的測試套件。
實際情況是:Bun作者Jarred Sumner自己跑的,不是Anthropic做的。約50個工作流、最多同時64隻agent、50萬行Zig變成100萬行Rust、燒掉大約16.5萬美金。而且他是照著一份300條規則的指南跑的,成品要通過超過100萬個測試斷言。
Bun的Zig轉Rust改寫:11天、50萬行轉100萬行、64隻agent、約16.5萬美金,依據一份300條規則的指南,通過超過100萬個測試斷言。
所以「讓模型自己跑」最成功的案例,底下墊的是300條規則加一套硬驗證。
這跟「規則是負擔,刪掉就好」是完全不同的結論。整理稿漏掉這段,讀起來會變成反規則,那是誤讀。
補一件整理稿也沒提的:Zig作者Andrew Kelley公開稱那份成果為unreviewed slop。我不是說他對,是說這個案例還在爭議中,不能當定論拿去推翻自己的做法。
—
我先量了一遍
訪談裡提到一個沒寫進文件的環境變數,可以把所有系統提示詞連同工具的提示詞一起清掉。我直接掃了本機安裝的claude.exe,那是一個265MB的二進位檔,CLAUDE_CODE_SIMPLE這個字串確實在裡面。
但我沒有急著用它。先量自己的設定,因為刪之前得知道刪掉能省多少。
量出來是這樣:
兩份CLAUDE.md合計7,764字。常載規則15支合計11,932字。記憶索引11,695字,這是單一最大的檔案。三者相加31,391字。
另外,skill總數127支(自己寫的22支、外部匯入59支、其他46支),記憶檔445個。
個人Claude Code設定實測:常載31,391字(CLAUDE.md 7,764 + 規則11,932 + 記憶索引11,695),在1M context下佔約2到3%。127支skill的名稱與說明每次也載入,佔位比規則更多。
在1M context下,31,391字大約佔2到3%。
這個數字改變了整件事的性質。刪掉80%可以省下不到2%的空間。所以刪規則的理由不能是省空間,只能是解綁:那些規則會不會反過來綁住模型。
順帶一提,真正佔位置的是那127支skill的名稱加說明,它們每次都要載,比規則還多。這一塊多數人量的時候會漏掉。
—
他刪的東西跟我的規則不是同一種
Boris刪的是Anthropic寫給全世界使用者的通用系統提示詞。那些規則存在的目的是矯正「模型該會卻不會」的行為,模型變強之後就過期。
我的規則有一半不是那種。
標點要用全形、訊息進來先回哪個對話、交件只給成品不要附說明,這些是偏好。模型再強也永遠猜不到。這種規則不會過期,因為它補的不是能力缺口,是資訊缺口。
所以該做的不是全刪,是先分兩堆:
偏好型,永不過期,留著甚至該更硬。 矯正型,有保鮮期,該定期試刪。
分完之後我發現,真正該進試刪名單的是那幾支「教模型怎麼思考」的規則:什麼時候算真的完成、碰到問題先分類、多輪任務不要漏掉前面的要求。這些加起來約4,400字,全部都是在補模型當時做不到的事。
—
第三種規則,兩邊都不是
分堆的時候跑出一個意外的第三類:問題是真的,但寫成文字規則沒有用的。
我自己的規則裡有一條在講「規則寫了不等於會生效,它要每次主動想起來才會被應用」。這條描述的問題百分之百正確。但它本身也是一條規則,也需要被想起來才生效。
這種規則不該刪,也不該只停在文字。它要變成檢查器或hook,變成一個「我想不到它也會發生」的東西。
分到這裡,原本的問題就變了。不是「該不該刪規則」,是「哪幾條該從文字升級成結構」。
—
還有一件我原本想做但做不成的事
我本來要跑一次真正的消除法:把那幾支矯正型規則搬走,跑同一組驗收題,比較前後差異。
搬完檔案,派出去的子任務仍然能一字不漏引出那些檔案的內容。
規則是session開場就載進記憶體的,中途搬檔案對已經開著的session完全無效,包含刪除。要做真正的消除法只有一條路:搬走檔案、關掉程式、開新session再跑。
這件事本身值得記下來,因為如果我沒有在實驗裡加一道探針去確認「規則真的被拿掉了」,我會得到四份漂亮但完全無效的數據,然後宣稱刪掉沒差。
刪或不刪從來不是真正的問題。真正的問題是每一條規則在補什麼:補能力缺口的會過期,補資訊缺口的不會,而問題為真卻寫成文字的那種,該做的是把它變成一個不用記得的東西。