200行配置換來輸出質(zhì)量"跳崖式"上漲——方向是對的。這是Boris Cherny的真實經(jīng)歷，他親手搭建了Claude Code。而大多數(shù)開發(fā)者的CLAUDE.md，本質(zhì)上是個自暴自棄的README。

你的"規(guī)則清單"正在拖垮Claude

HumanLayer引用arXiv一篇關(guān)于指令跟隨極限的論文指出：前沿推理模型能可靠執(zhí)行的指令約150-200條。他們對Claude Code系統(tǒng)提示詞的拆解顯示，你的CLAUDE.md加載前，Claude已經(jīng)內(nèi)置了約50條指令。

具體數(shù)字或許有爭議，但趨勢沒有。規(guī)則加到某個臨界點，Claude執(zhí)行所有規(guī)則的能力都會下降——不只是新加的。

Compliance drops uniformly. 你最在乎的規(guī)則，和那些忘了刪的廢話，被忽略的概率一模一樣。

這就是為什么X上那些"400行CLAUDE.md讓Claude變10倍工程師"的病毒推文，實際上在幫倒忙。作者好意，但追隨者們往文件里塞規(guī)則，Claude在前100條之后就悄悄停止執(zhí)行了。

上下文是預(yù)算。要像付房租一樣花它，而不是當(dāng)賭場籌碼。

一半內(nèi)容在浪費指令額度

最諷刺的是，多數(shù)人塞進(jìn)CLAUDE.md的東西，Claude本來就能推斷。技術(shù)棧在package.json里，TypeScript配置在tsconfig.json里，Linter規(guī)則在.eslintrc里。Claude全都會讀。重復(fù)這些內(nèi)容，等于把指令額度燒在毫無影響的事情上。

Boris Cherny給每條規(guī)則設(shè)了一個測試："刪掉這條，會讓Claude犯一個無法挽回的錯誤嗎？"

刪掉"use TypeScript"，而你的項目有tsconfig.json——無事發(fā)生。刪掉"Convex queries不能調(diào)用mutations，要用actions"——Claude會生成通過類型檢查、但運行時爆炸的代碼。

只放Claude獨自搞不定的東西。

他曬出自己的舊CLAUDE.md，十一行"信息"：Stack、Node版本、包管理器，以及"用TypeScript""寫測試""別刪.env"。Claude三秒就能從倉庫里扒出來的東西。剩下的是"寫干凈代碼""遵循最佳實踐""保持組件小巧"——多?。縍eact組件那么小，還是微服務(wù)那么小？Claude不知道，你也沒說。

真正有效的四類信息

重構(gòu)四個生產(chǎn)倉庫后，Boris把CLAUDE.md拆成四個區(qū)塊，按重要性排序：

1. 項目級上下文（最多50行）

這是"為什么"和"為誰做"。不是功能列表，是決策依據(jù)。目標(biāo)用戶是誰，核心用戶旅程是什么，技術(shù)選型背后的約束——比如"用Convex是因為需要實時同步，但代價是查詢不能調(diào)mutations"。

Claude Code的維護(hù)者Trail of Bits，在審計倉庫里會寫清：這份代碼是做什么的，審計范圍是什么，已知風(fēng)險在哪。不是給人類看的文檔，是給Claude的決策錨點。

2. 工作流偏好（20-30行）

怎么和現(xiàn)有代碼庫協(xié)作。測試命令是什么，怎么跑類型檢查，提交前必須過哪些門。Anthropic黑客馬拉松的獲勝團(tuán)隊會寫明：先寫測試再寫實現(xiàn)，還是反過來；遇到不確定的設(shè)計決策時，該問誰或查哪份文檔。

關(guān)鍵要具體。"寫測試"是廢話。"用vitest，測試文件放__tests__/，覆蓋率門檻80%"才是指令。

3. 常見陷阱（10-15行）

Claude反復(fù)踩過的坑。不是通用最佳實踐，是本項目特有的 gotcha。比如"Convex的auth()在edge runtime里不可用，要用getAuth()""這個repo用zod做運行時校驗，別用io-ts"。

Boris的200行里，這部分不到10%。但每條都救過命。

4. 禁止事項（5-10行）

紅線列表。不是"別寫爛代碼"，是"別動這個文件""別升級這個依賴""別用React Server Components，我們還沒遷移"。

數(shù)量少，因為每條都必須是"違反就回滾"級別。

從"文檔"到"環(huán)境變量"的思維切換

README是給新同事看的，CLAUDE.md是給Claude看的。兩者的區(qū)別像用戶手冊和.env文件——一個解釋"這是什么"，一個配置"怎么運行"。

Boris的轉(zhuǎn)折點發(fā)生在對比了Trail of Bits的審計倉庫之后。他們的CLAUDE.md沒有"項目介紹"，只有"審計范圍""已知漏洞模式""工具鏈版本"。Claude生成的報告直接可用，不需要人類再改格式。

另一個參照是Anthropic官方黑客馬拉松的獲勝項目。他們的CLAUDE.md平均長度是失敗項目的三分之一，但"具體指令密度"高出五倍。"用shadcn/ui，主題色slate-950"——不是"用好看的組件庫"。

核心洞察：Claude不是需要更多信息，是需要更精確的信息。每多一行模糊的指導(dǎo)，就擠占一行能改變行為的指令。

怎么驗證你的CLAUDE.md有效

Boris的測試方法：刪掉CLAUDE.md，讓Claude完成一個典型任務(wù)，記錄哪里出錯。然后把修復(fù)指令寫進(jìn)CLAUDE.md，重復(fù)測試。有效的條目會讓錯誤消失，無效的條目會讓Claude在其他地方犯錯——因為上下文被稀釋了。

他最初的200行里，經(jīng)過三輪測試后剩下127行。被刪掉的包括：所有能從配置文件推斷的內(nèi)容，所有"盡量""考慮""適當(dāng)"開頭的句子，所有和本項目無關(guān)的通用最佳實踐。

一個反直覺的發(fā)現(xiàn)：把CLAUDE.md從50行擴(kuò)充到200行，輸出質(zhì)量先降后升。中間那段"150行左右"是最差的——規(guī)則夠多造成干擾，又不夠多形成體系。要么精簡到核心，要么系統(tǒng)化到完整，卡在中間最致命。