把 Claude 犯錯率從 41% 壓到 3%：只靠一個文件
整理版優先睇
將Claude Code錯誤率從41%壓到3%：一份12條規則嘅CLAUDE.md
呢篇文章由《賈傑嘅AI編程秘籍》同《又100個思維碎片》嘅作者墨問撰寫，講述點樣用一份CLAUDE.md檔案將Claude Code嘅錯誤率由41%降到3%。文章背景係2026年1月Karpathy公開抱怨Claude表現，開發者Forrest Chang將佢嘅4條規則整理成CLAUDE.md模板，獲得12萬GitHub星。隨後有人花6星期喺30個真實項目上測試，再加8條規則，形成完整12條規則，將錯誤率壓低到3%。
作者首先解釋CLAUDE.md嘅概念：一個放喺項目根目錄嘅純文字檔案，Claude Code每次啟動會自動讀取，但遵守率約80%，且超過200行會顯著下降。然後介紹Karpathy嘅4條地板規則：先想再寫、簡單優先、外科手術式修改、目標驅動執行。再指出呢4條只針對單次編寫場景，對多步驟Agent工作流有盲點。新8條規則針對Token失控、無Checkpoint錯誤複利、測試虛假信心、沉默失敗等問題，每條均由真實事故提煉。文章最後提供完整12條規則模板同快速部署方法，強調CLAUDE.md係行為合同，要喺200行內寫出高密度約束，並建議讀者根據自己踩過嘅坑自訂規則。
- 結論：一份200行內嘅CLAUDE.md可以將Claude Code錯誤率由41%降到3%，關鍵係將行為變成約束。
- 方法：Karpathy嘅4條規則關閉沉默假設同過度工程化；新8條規則針對多步驟工作流，補充Token預算、Checkpoint、測試意圖等。
- 差異：加8條規則後合規率幾乎不變（78%→76%），但錯誤率大幅下降（11%→3%），證明規則覆蓋獨立失控點，唔互相干擾。
- 啟發：規則必須針對真實踩過嘅坑，每條要問自己「防止咗邊個真實事故？」，超過200行會稀釋注意力。
- 可行動點：直接複製文章提供嘅12條規則模板，或者用Claude根據自己項目生成自訂CLAUDE.md，30秒內部署。
從41%到3%：CLAUDE.md嘅力量
先講一個數字：
41%
。呢係冇任何約束時，Claude喺真實編程任務裏面需要人工返工嘅概率。然後Karpathy抱怨咗一輪，Forrest Chang將佢嘅抱怨整理成4條規則，放上GitHub，一日5,828星，兩週6萬書籤，而家12萬星。
CLAUDE.md
係一個放喺項目根目錄嘅純文字檔案，Claude Code每次啟動都會自動讀取。關鍵數字係
200行
——超過上限，遵守率會顯著下降。所以呢場遊戲係點樣喺200行以內寫出最高密度嘅約束。
遵守率約80%
Karpathy嘅4條地板規則同埋盲點
Forrest Chang嘅原版模板有65行、4條規則，係所有後續優化嘅基礎。
- Rule 1 — 先想再寫：顯式講出假設，有歧義時先問，存在更簡單方案時主動推後。
- Rule 2 — 簡單優先：最小可用代碼，唔寫冇被要求嘅功能。
- Rule 3 — 外科手術式修改：只改應該改嘅，唔順手「優化」隔籬。
- Rule 4 — 目標驅動執行：定義成功標準，循環到驗證通過。
Karpathy嘅4條規則
關閉咗大約40%嘅常見失誤。但原版規則係針對2026年1月單次編寫場景，而家嘅問題係
多步驟Agent工作流
。新8條規則補充咗呢啲盲點：Token失控、無Checkpoint導致錯誤複利、測試質量虛假信心、沉默失敗。
先想再寫
目標驅動執行
新8條規則：由真實事故提煉出嚟
以下係Rule 5到12，每條背後都有一個真實嘅事故。
- 1 Rule 5 — 用模型只做判斷：分類、起草、總結、提取；路由、重試、確定性變換交畀Code。
- 2 Rule 6 — Token預算唔係建議：每任務4,000 tokens，每Session 30,000。臨近預算要總結重啟。
- 3 Rule 7 — 暴露衝突，唔好平均：兩種模式矛盾時揀一個，標記另一個清走。
- 4 Rule 8 — 先讀再寫：加Code前讀exports、callers、shared utilities。
- 5 Rule 9 — 測試驗證意圖，唔只行為：測試要編碼點解重要，而唔係做咗咩。
- 6 Rule 10 — 每完成重要步驟就Checkpoint：總結做咗咩、驗證咗咩、仲有咩未做。
- 7 Rule 11 — 匹配Codebase約定，哪怕你唔同意：一致性>品味。
- 8 Rule 12 — 大聲失敗：有任何嘢靜靜跳過就算失敗。
用模型只做判斷
Token預算
暴露衝突
大聲失敗
點樣實戰用呢套規則
直接複製下面嘅12條規則模板，存做CLAUDE.md放喺項目根目錄。或者用curl追加到現有CLAUDE.md：
# 追加Karpathy原版4條規則
curl https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md >> CLAUDE.md
# 然後將上面Rule 5-12粘貼到文件後面另外可用Claude生成項目專屬規則：丟個Prompt畀Claude，叫佢根據你嘅技術棧同常見失誤寫CLAUDE.md，包含12條基礎規則同3-5條自訂規則，總行數唔超過200行。
12條規則模板
行為合同
🌟星標 + 👆關注，第一時間知道最新、最有用的AI Coding技巧
《賈傑嘅AI Coding秘籍》付費合集，總共有10篇，而家已經完結。30蚊交個朋友，學唔到真嘢揾我退錢；）
同埋我最新嘅付費合集《又100個思維碎片》墨問，把我返一日工，AI自己喺屋企寫一日Code嘅秘訣，分享畀你
寫喺前面
首先講一個令人沉默嘅數字：41%。
呢個係冇任何約束嘅時候，Claude喺真實Coding任務裏面需要人工返手嘅機率。唔係「可以做得更好」，係一定要改——否則就錯。
然後Karpathy喺今年1月鬧咗一輪，有個叫Forrest Chang嘅開發者將佢嘅抱怨整理成4條規則，塞入一個叫 CLAUDE.md 嘅檔案，掉上GitHub。第一日5,828粒星，兩週6萬個Bookmark，而家 12萬粒星——2026年增速最快嘅單檔案Repo。
然後有人用咗6個星期，喺30個真實Project上面將呢4條規則測試完，再加咗8條，將錯誤率壓到 3%。
呢篇文章嘅目標好簡單：將呢12條規則完整畀你，話畀你知每一條背後發生咗咩真實事故，順便附上一個現成嘅Prompt，等你今晚就可以用。
什麼是 CLAUDE.md？
先定義，費事有人唔知。
CLAUDE.md 係一個放喺Project Root嘅純文字檔案，Claude Code每次開都會自動讀取佢。相當於你畀Claude嘅工作手冊——每次佢開新Task，就順便睇一次呢本手冊，然後先開始做嘢。
官方文檔講咗：呢個係「advisory」（建議性質），Claude跟嘅機率大約80%。
（翻譯過嚟即係：寫咗唔一定聽，但唔寫就一定唔聽。）
關鍵數字係 200行。超過呢個上限，跟嘅機率會明顯下降，因為重要規則被噪音淹沒——Claude開始「見到規則嘅存在」而唔係「真正理解規則嘅內容」。
所以，呢個就係一場喺200行以內，寫出最高密度約束嘅遊戲。
Karpathy嘅4條規則——地板
Forrest Chang嘅原版模板，65行，4條規則，係所有後續優化嘅地板。
唔熟嘅話，我快速講下：
Rule 1 — 先諗後寫（Think Before Coding）
講清楚假設。有歧義嘅時候先問，唔好靠估。存在更簡單方案嘅時候主動放棄。
Rule 2 — 簡單優先（Simplicity First）
最細可用嘅Code。唔寫冇被要求嘅功能。冇「以防萬一」嘅抽象。
Rule 3 — 外科手術式修改（Surgical Changes）
只鬱應該鬱嘅嘢。唔順便「優化」隔籬嘅Code、註釋或者格式。
Rule 4 — 目標驅動執行（Goal-Driven Execution）
定義成功標準，循環到驗證通過。唔好話畀Claude聽要行邊啲步驟，話畀佢聽咩叫「做曬」。
呢4條關閉咗大約40%嘅常見失誤。剩低60%嘅失誤，收埋喺跟住落嚟嘅8條裏面。
8條新規則——點解4條唔夠用
「Karpathy嘅模板係為咗修2026年1月嘅問題。而家係2026年5月，問題已經唔同咗。」
Agent循環、多步驟工作流程、多Repo一致性——呢啲嘢1月仲未係主要痛點。而家係。
我逐條講，每條都有一個令我寫低佢嘅真實事故。
Rule 5 — 只將Model用喺判斷上面
## Rule 5 — Use the model only for judgment calls
Use me for: classification, drafting, summarization, extraction.
Do NOT use me for: routing, retries, deterministic transforms.
If code can answer, code answers.事故經過： 有人寫咗一段Code，叫Claude「判斷應唔應該喺503上面重試」。頭兩個禮拜表現完美。然後開始隨機失敗——因為Model開始讀取Request Body做判斷嘅Context，重試策略變咗隨機。
本質問題： Status Code已經可以回答呢個問題。點解要畀Language Model做？路由、重試、Status Code處理、Deterministic變換——呢啲係 if-else 嘅工作，唔係Claude嘅工作。用Model做呢啲嘢，等於每次畀$0.003買一個隨機數。
Rule 6 — Token Budget唔係建議
## Rule 6 — Token budgets are not advisory
Per-task: 4,000 tokens. Per-session: 30,000 tokens.
If approaching budget, summarize and start fresh.
Surface the breach. Do not silently overrun.事故經過： 一個Debug Session行咗90分鐘，Model一路圍住同一個8KB Error Message迭代，慢慢忘記咗邊啲Method已經試過。最後開始建議40條Message之前已經被否決嘅方案。
本質問題： 冇Token Budget，每個Loop都可能失控變成50,000 Token嘅Context垃圾場。Model唔會自動停落嚟。寫Budget，唔係為咗慳錢，係為咗強制Reset——喺失控之前。
Rule 7 — 暴露衝突，唔好平均化
## Rule 7 — Surface conflicts, don't average them
If two patterns contradict, pick one (more recent / more tested).
Explain why. Flag the other for cleanup.
Don't blend conflicting patterns.事故經過： 一個Project裏面有兩種Error Handling模式——一種係顯式try/catch，一種係Global Error Boundary。Claude寫咗兩種都用到嘅新Code，結果Error被吞噬咗兩次。用咗30分鐘先搞清楚點解。
本質問題： 當兩種規範互相矛盾，Claude會本能咁「令所有人滿意」，寫出同時符合兩種規範嘅混合體——呢個係最差嘅結果，比任何一種單一方案都差。
Rule 8 — 先讀後寫
## Rule 8 — Read before you write
Before adding code, read exports, immediate callers, shared utilities.
"Looks orthogonal" is dangerous. If unsure why code is structured a way, ask.事故經過： Claude喺一個Function隔籬新加咗一個功能完全相同嘅Function——因為佢冇讀嗰個已經存在嘅Function。新Function因為Import順序取得咗優先權，將行咗6個月嘅原Function踢走咗。
本質問題： Karpathy嘅「外科手術」講嘅係「唔好鬱唔應該鬱嘅Code」，但冇話「要先讀明隔籬嘅Code先鬱手」。呢個係兩件唔同嘅事。
Rule 9 — Test驗證意圖，唔止係行為
## Rule 9 — Tests verify intent, not just behavior
Tests must encode WHY behavior matters, not just WHAT it does.
A test that can't fail when business logic changes is wrong.事故經過： Claude為一個Auth Function寫咗12個Test，全部通過。但Production個Auth係壞嘅。因為Test只驗證Function「有嘢回傳」，冇驗證回傳嘅係唔係正確嘅嘢——Function回傳緊一個常數。
本質問題： 「目標驅動執行」默認咗「Test通過」係成功標準，但冇話畀Claude聽Test本身一定要有意義。一個只Test「Function執行咗」嘅Test，同冇Test一樣危險。
Rule 10 — 每完成重要步驟就Checkpoint
## Rule 10 — Checkpoint after every significant step
Summarize what was done, what's verified, what's left.
Don't continue from a state you can't describe back.
If you lose track, stop and restate.事故經過： 一個6步Refactor，第4步出錯。發現嘅時候Claude已經喺錯嘅基礎上面完成咗第5步同第6步。解開嘅時間比重做成件事更加長。
本質問題： Karpathy嘅規矩係為單次互動設計嘅，對多步驟、跨Session嘅Workflow係盲點。冇Checkpoint，一個錯誤會喺後續每一步裏面複利增長。
Rule 11 — 跟返Codebase嘅約定，就算你唔同意
## Rule 11 — Match the codebase's conventions, even if you disagree
Conformance > taste inside the codebase.
If you genuinely think a convention is harmful, surface it. Don't fork it silently.事故經過： Claude喺一個Class Component嘅Codebase裏面引入咗React Hooks。Hook可以正常運行，但打破咗Codebase裏面基於 componentDidMount 嘅Test模式。用咗半日清理。
本質問題： 即使Claude嘅選擇客觀上更加好，喺同一個Codebase裏面同時存在兩種模式，永遠比任何一種單獨存在更加差。一致性 > 品味。分歧係另一個對話，唔係喺Code裏面靜靜雞Fork出去嘅權利。
Rule 12 — 大聲失敗
## Rule 12 — Fail loud
"Completed" is wrong if anything was skipped silently.
"Tests pass" is wrong if any were skipped.
Default to surfacing uncertainty, not hiding it.事故經過： Claude話一次Database Migration「成功完成」咗。其實佢靜靜雞跳過咗14%觸發Constraint衝突嘅Record。Log有，但冇浮現出嚟。11日後Report開始出現異常先發現。
本質問題： 最貴嘅失敗係睇落成功嘅失敗。「已完成」係錯，如果有任何嘢被靜靜雞Skip咗。「Test通過」係錯，如果有任何Test被略過。默認暴露不確定性，唔係默認隱藏佢。
完整嘅12條規則Template
直接複製，儲存做 CLAUDE.md 放喺你嘅Project Root：
# CLAUDE.md — 12-rule template
These rules apply to every task in this project unless explicitly overridden.
Bias: caution over speed on non-trivial work. Use judgment on trivial tasks.
## Rule 1 — Think Before Coding
State assumptions explicitly. If uncertain, ask rather than guess.
Present multiple interpretations when ambiguity exists.
Push back when a simpler approach exists.
Stop when confused. Name what's unclear.
## Rule 2 — Simplicity First
Minimum code that solves the problem. Nothing speculative.
No features beyond what was asked. No abstractions for single-use code.
Test: would a senior engineer say this is overcomplicated? If yes, simplify.
## Rule 3 — Surgical Changes
Touch only what you must. Clean up only your own mess.
Don't "improve" adjacent code, comments, or formatting.
Don't refactor what isn't broken. Match existing style.
## Rule 4 — Goal-Driven Execution
Define success criteria. Loop until verified.
Don't follow steps. Define success and iterate.
Strong success criteria let you loop independently.
## Rule 5 — Use the model only for judgment calls
Use me for: classification, drafting, summarization, extraction.
Do NOT use me for: routing, retries, deterministic transforms.
If code can answer, code answers.
## Rule 6 — Token budgets are not advisory
Per-task: 4,000 tokens. Per-session: 30,000 tokens.
If approaching budget, summarize and start fresh.
Surface the breach. Do not silently overrun.
## Rule 7 — Surface conflicts, don't average them
If two patterns contradict, pick one (more recent / more tested).
Explain why. Flag the other for cleanup.
Don't blend conflicting patterns.
## Rule 8 — Read before you write
Before adding code, read exports, immediate callers, shared utilities.
"Looks orthogonal" is dangerous. If unsure why code is structured a way, ask.
## Rule 9 — Tests verify intent, not just behavior
Tests must encode WHY behavior matters, not just WHAT it does.
A test that can't fail when business logic changes is wrong.
## Rule 10 — Checkpoint after every significant step
Summarize what was done, what's verified, what's left.
Don't continue from a state you can't describe back.
If you lose track, stop and restate.
## Rule 11 — Match the codebase's conventions, even if you disagree
Conformance > taste inside the codebase.
If you genuinely think a convention is harmful, surface it. Don't fork silently.
## Rule 12 — Fail loud
"Completed" is wrong if anything was skipped silently.
"Tests pass" is wrong if any were skipped.
Default to surfacing uncertainty, not hiding it.快速部署方法
兩步，30秒：
# 1. 把 Karpathy 原版 4 條追加到你的 CLAUDE.md
curl https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md >> CLAUDE.md
# 2. 把上面的 Rule 5-12 粘貼到文件後面注意是 >>，追加而唔係覆蓋——保留你本身有嘅Project Rules。
深度解析：點解呢套嘢會有效
睇完規則，我哋傾下佢哋點解有效——呢個比規則本身更加重要，因為理解咗原理，先可以寫出適合你自己Project嘅第13條。
規則嘅本質：將行為變成約束
Claude唔係唔聰明，佢喺大多數情況下確實知道應該點做。問題在於，知道和每次都做到之間，有一道巨大嘅執行鴻溝。
CLAUDE.md解決嘅唔係能力問題，解決嘅係一致性問題。
每一條規則，都對應一個Claude喺「冇約束時會隨機表現」嘅維度。Rule 12 — Fail Loud 唔係喺教Claude咩叫失敗，係話：「喺呢個Project入面，沉默唔係選項。」
呢個就好似畀一個優秀但係有啲貪方便嘅同事寫工作規範——唔係因為佢唔識，係因為冇白紙黑字，佢間唔中會偷偷行捷徑。
四條原版規則嘅盲點
原版4條規矩係針對單次、單檔案、寫Code呢個場景優化嘅。
2026年嘅實際情況係：Claude Code越來越多咁用於多步驟Agent Workflow——跨多個檔案嘅Refactor、跨Session嘅Function開發、跨多個Service嘅一致性維護。呢啲場景嘅失敗模式完全唔同：
• 單次寫Code 主要失誤：假設錯誤、Over-engineering、誤傷隔籬Code • 多步驟Agent 主要失誤：Token失控、冇Checkpoint導致錯誤複利、Test質量虛假信心、沉默失敗
新嘅8條規則覆蓋嘅正正係後者。兩組規則唔衝突，佢哋針對嘅係唔同維度嘅失控。
最反直覺嘅發現
由4條到12條，合規率只係由78%跌到76%——幾乎冇變。
但錯誤率由11%繼續降到3%。
即係話：加咗8條規則，Claude嘅遵守成本幾乎係零，但覆蓋咗完全唔同嘅失敗類型。
呢個說明12條規則之間唔係爭同一塊注意力Budget，佢哋各自管緊獨立嘅失控點。好嘅規則設計，覆蓋面唔會重疊。
200行紅線嘅物理含義
文件超過200行，合規率由76%急速跌到52%。
呢個唔係Claude偷懶，係Context Window入面嘅注意力稀釋。當規則數量超過某個Threshold，Claude開始識別「規則存在」呢個事實本身，而唔再逐條解析每一條規則嘅含義。
實踐含義：CLAUDE.md唔係願望清單，係行為合約。 每條規則都要問自己：呢條規則防止咗我真實踩過嘅邊個坑？防止唔到真實嘅坑，就刪咗佢。
附：點樣用Claude嚟寫你自己嘅CLAUDE.md
（係，用Claude畀Claude寫規則，完全冇問題。）
將下面呢個Prompt掉畀Claude，話畀佢聽你Project嘅Tech Stack同你最常遇到嘅失誤類型，佢可以幫你寫出一套Project定製化嘅規則：
我在用 Claude Code 開發 [你的技術棧，如：React + TypeScript + Node.js]。
請幫我寫一份 CLAUDE.md，包含以下信息：
- 項目類型：[Web 應用 / API 服務 / 等]
- 常見失誤：[你最常遇到的 Claude 錯誤類型]
- 現有規範：[你項目裏有沒有已有的代碼風格、測試規範等]
要求：
1. 包含本文提到的 12 條基礎規則
2. 在後面追加 3-5 條項目專屬規則
3. 總行數不超過 200 行
4. 每條規則都是可執行的命令句，不是模糊的期待總結
一張表，直接睇數字：
Karpathy嘅4條關閉咗沉默假設、Over-engineering、誤傷隔籬Code、弱成功標準。
新嘅8條關閉咗Token失控、冇Checkpoint嘅錯誤複利、Test質量嘅虛假信心、沉默失敗嘅破壞力、約定衝突嘅混亂。
兩組規則都唔可以少。前者係地板，後者係天花板。
你唔需要12條全部用。6條你真係踩過坑嘅規則，比12條照本宣科嘅規則有效得多。 睇完呢篇，揀你踩過嘅坑，刪咗你冇遇到嘅場景，今晚儲存做File。
然後將錯誤率壓低。
P.S. 呢套規則唔係萬能。CLAUDE.md係行為約束，唔係技術能力嘅Patch。Model本身做唔到嘅事，規則都叫唔返。但喺Model能力範圍內，佢令「偶爾做到」變成「每次做到」——呢個先係41%到3%嘅真正來源。
堅持創作唔容易，求個一鍵三連，多謝你～❤️
以及「AI Coding技術交流Group」，聯絡ayqywx我拉你入Group，一齊交流學習～
🌟星標 + 👆關注，第一時間知道最新、最有用的AI編程姿勢
《賈傑的AI編程秘籍》付費合集，共10篇，現已完結。30元交個朋友，學不到真東西找我退錢；）
以及我最新的付費合集《又100個思維碎片》墨問，把我上一天班，AI自己在家寫一天代碼的焚訣，分享給你
寫在前面
先說一個讓人沉默的數字：41%。
這是沒有任何約束時，Claude 在真實編程任務裏需要人工返工的概率。不是"可以做得更好"，是必須修——否則就錯了。
然後 Karpathy 在今年 1 月抱怨了一通，一個叫 Forrest Chang 的開發者把他的抱怨整理成 4 條規則，塞進一個叫 CLAUDE.md 的文件，丟上 GitHub。第一天 5,828 星，兩週 6 萬書籤，如今 12 萬星——2026 年增速最快的單文件倉庫。
然後有人花 6 周時間，在 30 個真實項目上把這 4 條規則測完，又加了 8 條，把錯誤率壓到了 3%。
這篇文章的目的很簡單：把這 12 條規則完整給你，告訴你每一條背後發生了什麼真實事故，順手附上一個現成的 Prompt，讓你今晚就能用上。
什麼是 CLAUDE.md？
先定義，免得有人不知道。
CLAUDE.md 是一個放在項目根目錄的純文本文件，Claude Code 每次啓動都會自動讀取它。相當於你給 Claude 的工作手冊——每次它打開新任務，就先把這本手冊過一遍，然後再動手。
官方文檔說了：這是"advisory"（建議性的），Claude 遵守率約 80%。
（翻譯過來就是：寫了不一定聽，但不寫一定不聽。）
關鍵數字是 200 行。超過這個上限，遵守率會顯著下降，因為重要規則被淹沒在噪音裏——Claude 開始"看到規則的存在"而不是"真正理解規則的內容"。
所以，這就是一場在 200 行以內，寫出最高密度約束的遊戲。
Karpathy 的 4 條規則——地板
Forrest Chang 的原版模板，65 行，4 條規則，是所有後續優化的地板。
不熟悉的話，我快速過一下：
Rule 1 — 先想再寫（Think Before Coding）
顯式說出假設。有歧義時先問，別猜。存在更簡單方案時主動推後。
Rule 2 — 簡單優先（Simplicity First）
最小可用代碼。不寫沒被要求的功能。沒有"以防萬一"的抽象。
Rule 3 — 外科手術式修改（Surgical Changes）
只動該動的。不順手"優化"旁邊的代碼、註釋或格式。
Rule 4 — 目標驅動執行（Goal-Driven Execution）
定義成功標準，循環到驗證通過。不告訴 Claude 走哪些步驟，告訴它什麼叫"做完了"。
這 4 條關閉了約 40% 的常見失誤。剩下 60% 的失誤，藏在接下來的 8 條裏。
8 條新規則——為什麼 4 條不夠用了
"Karpathy 的模板是為了修 2026 年 1 月的問題。現在是 2026 年 5 月，問題已經不同了。"
Agent 循環、多步驟工作流、多代碼庫一致性——這些 1 月份還不是主要痛點。現在是。
我逐條講，每條都有一個讓我寫下它的真實事故。
Rule 5 — 只把模型用在判斷上
## Rule 5 — Use the model only for judgment calls
Use me for: classification, drafting, summarization, extraction.
Do NOT use me for: routing, retries, deterministic transforms.
If code can answer, code answers.事故經過： 有人寫了一段代碼，讓 Claude "判斷是否應該在 503 上重試"。前兩週表現完美。然後開始隨機失敗——因為模型開始讀取請求體作為判斷上下文，重試策略變成了隨機的。
本質問題： 狀態碼已經能回答這個問題了。為什麼要讓語言模型來做？路由、重試、狀態碼處理、確定性變換——這些是 if-else 的工作，不是 Claude 的工作。用模型做這些，等於每次花 $0.003 買一個隨機數。
Rule 6 — Token 預算不是建議
## Rule 6 — Token budgets are not advisory
Per-task: 4,000 tokens. Per-session: 30,000 tokens.
If approaching budget, summarize and start fresh.
Surface the breach. Do not silently overrun.事故經過： 一個調試 Session 跑了 90 分鐘，模型一直在圍繞同一個 8KB 錯誤消息迭代，慢慢地忘記了哪些修法已經試過。最後開始建議 40 條消息前已經被否決的方案。
本質問題： 沒有 Token 預算，每個循環都可能失控成 5 萬 Token 的上下文垃圾場。模型不會主動停下來。寫預算，不是為了省錢，是為了強制重置——在失控前。
Rule 7 — 暴露衝突，不要平均
## Rule 7 — Surface conflicts, don't average them
If two patterns contradict, pick one (more recent / more tested).
Explain why. Flag the other for cleanup.
Don't blend conflicting patterns.事故經過： 一個項目裏有兩種錯誤處理模式——一種是顯式 try/catch，一種是全局錯誤邊界。Claude 寫了兩種都用的新代碼，結果錯誤被吞噬了兩次。花了 30 分鐘才搞清楚為什麼。
本質問題： 當兩種規範互相矛盾，Claude 會本能地"讓所有人滿意"，寫出同時滿足兩種規範的混合體——這是最差的結果，比任何一種單獨方案都糟。
Rule 8 — 先讀再寫
## Rule 8 — Read before you write
Before adding code, read exports, immediate callers, shared utilities.
"Looks orthogonal" is dangerous. If unsure why code is structured a way, ask.事故經過： Claude 在一個函數旁邊新加了一個功能完全相同的函數——因為它沒讀那個已存在的函數。新函數因為 import 順序取得了優先級，把運行了 6 個月的原函數踢掉了。
本質問題： Karpathy 的"外科手術"說的是"不要動不該動的代碼"，但沒說"要先讀懂旁邊的代碼再動手"。這是兩件不同的事。
Rule 9 — 測試驗證意圖，不只是行為
## Rule 9 — Tests verify intent, not just behavior
Tests must encode WHY behavior matters, not just WHAT it does.
A test that can't fail when business logic changes is wrong.事故經過： Claude 為一個 auth 函數寫了 12 個測試，全部通過。但生產環境 auth 是壞的。因為測試只驗證函數"返回了東西"，沒驗證返回的是不是正確的東西——函數在返回一個常量。
本質問題： "目標驅動執行"默認把"測試通過"當作成功標準，但沒告訴 Claude 測試本身必須是有意義的。一個只測試"函數執行了"的測試，和沒有測試一樣危險。
Rule 10 — 每完成重要步驟就 Checkpoint
## Rule 10 — Checkpoint after every significant step
Summarize what was done, what's verified, what's left.
Don't continue from a state you can't describe back.
If you lose track, stop and restate.事故經過： 一個 6 步重構，第 4 步出錯了。發現時 Claude 已經在錯誤的基礎上完成了第 5 步和第 6 步。解開的時間比重做整件事更長。
本質問題： Karpathy 的規則是為單次交互設計的，對多步驟、跨 Session 的工作流是盲點。沒有 Checkpoint，一個錯誤會在後續每一步裏複利增長。
Rule 11 — 匹配代碼庫的約定，哪怕你不同意
## Rule 11 — Match the codebase's conventions, even if you disagree
Conformance > taste inside the codebase.
If you genuinely think a convention is harmful, surface it. Don't fork it silently.事故經過： Claude 在一個 Class 組件的代碼庫裏引入了 React Hooks。Hook 能正常運行，但打破了代碼庫裏基於 componentDidMount 的測試模式。花了半天清理。
本質問題： 即使 Claude 的選擇客觀上更好，在同一個代碼庫裏同時存在兩種模式，永遠比任何一種單獨存在更糟糕。一致性 > 品味。分歧是另一個對話，不是在代碼裏悄悄 fork 出去的權利。
Rule 12 — 大聲失敗
## Rule 12 — Fail loud
"Completed" is wrong if anything was skipped silently.
"Tests pass" is wrong if any were skipped.
Default to surfacing uncertainty, not hiding it.事故經過： Claude 說一次數據庫遷移"成功完成"了。其實它悄悄跳過了 14% 觸發約束衝突的記錄。日誌有，但沒有浮現出來。11 天后報表開始出現異常才發現。
本質問題： 最貴的失敗是看起來成功的失敗。"已完成"是錯的，如果有任何東西被悄悄跳過。"測試通過"是錯的，如果有任何測試被略過。默認暴露不確定性，不是默認隱藏它。
完整的 12 條規則模板
直接複製，存為 CLAUDE.md 放在你的項目根目錄：
# CLAUDE.md — 12-rule template
These rules apply to every task in this project unless explicitly overridden.
Bias: caution over speed on non-trivial work. Use judgment on trivial tasks.
## Rule 1 — Think Before Coding
State assumptions explicitly. If uncertain, ask rather than guess.
Present multiple interpretations when ambiguity exists.
Push back when a simpler approach exists.
Stop when confused. Name what's unclear.
## Rule 2 — Simplicity First
Minimum code that solves the problem. Nothing speculative.
No features beyond what was asked. No abstractions for single-use code.
Test: would a senior engineer say this is overcomplicated? If yes, simplify.
## Rule 3 — Surgical Changes
Touch only what you must. Clean up only your own mess.
Don't "improve" adjacent code, comments, or formatting.
Don't refactor what isn't broken. Match existing style.
## Rule 4 — Goal-Driven Execution
Define success criteria. Loop until verified.
Don't follow steps. Define success and iterate.
Strong success criteria let you loop independently.
## Rule 5 — Use the model only for judgment calls
Use me for: classification, drafting, summarization, extraction.
Do NOT use me for: routing, retries, deterministic transforms.
If code can answer, code answers.
## Rule 6 — Token budgets are not advisory
Per-task: 4,000 tokens. Per-session: 30,000 tokens.
If approaching budget, summarize and start fresh.
Surface the breach. Do not silently overrun.
## Rule 7 — Surface conflicts, don't average them
If two patterns contradict, pick one (more recent / more tested).
Explain why. Flag the other for cleanup.
Don't blend conflicting patterns.
## Rule 8 — Read before you write
Before adding code, read exports, immediate callers, shared utilities.
"Looks orthogonal" is dangerous. If unsure why code is structured a way, ask.
## Rule 9 — Tests verify intent, not just behavior
Tests must encode WHY behavior matters, not just WHAT it does.
A test that can't fail when business logic changes is wrong.
## Rule 10 — Checkpoint after every significant step
Summarize what was done, what's verified, what's left.
Don't continue from a state you can't describe back.
If you lose track, stop and restate.
## Rule 11 — Match the codebase's conventions, even if you disagree
Conformance > taste inside the codebase.
If you genuinely think a convention is harmful, surface it. Don't fork silently.
## Rule 12 — Fail loud
"Completed" is wrong if anything was skipped silently.
"Tests pass" is wrong if any were skipped.
Default to surfacing uncertainty, not hiding it.快速部署方法
兩步，30 秒：
# 1. 把 Karpathy 原版 4 條追加到你的 CLAUDE.md
curl https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md >> CLAUDE.md
# 2. 把上面的 Rule 5-12 粘貼到文件後面注意是 >>，追加而不是覆蓋——保留你已有的項目規則。
深度解析：為什麼這套東西能奏效
讀完規則，我們來聊一聊它們為什麼有效——這比規則本身更重要，因為理解了原理，才能寫出適合你自己項目的第 13 條。
規則的本質：把行為變成約束
Claude 不是不聰明，它在大多數情況下確實知道應該怎麼做。問題在於，知道和每次都做到之間，有一道巨大的執行鴻溝。
CLAUDE.md 解決的不是能力問題，解決的是一致性問題。
每一條規則，都對應一個 Claude 在"沒有約束時會隨機表現"的維度。Rule 12 — Fail Loud 不是在教 Claude 什麼叫失敗，而是在說："在這個項目裏，沉默不是選項。"
這就像給一個優秀但略愛省事的同事寫工作規範——不是因為他不會，是因為沒有白紙黑字，他偶爾會悄悄走捷徑。
四條原版規則的盲點
原版 4 條規則是針對單次、單文件、編寫代碼這個場景優化的。
2026 年的實際情況是：Claude Code 越來越多地被用於多步驟 Agent 工作流——跨多個文件的重構、跨 Session 的功能開發、跨多個服務的一致性維護。這些場景的失敗模式完全不同：
• 單次編寫 的主要失誤：假設錯誤、過度工程化、誤傷相鄰代碼 • 多步驟 Agent 的主要失誤：Token 失控、無 Checkpoint 導致錯誤複利、測試質量虛假信心、沉默失敗
新的 8 條規則覆蓋的正是後者。兩組規則不衝突，它們針對的是不同維度的失控。
最反直覺的發現
從 4 條到 12 條，合規率只從 78% 降到了 76%——幾乎沒變。
但錯誤率從 11% 繼續降到了 3%。
也就是說：加了 8 條規則，Claude 的遵守成本幾乎為零，但覆蓋了完全不同的失敗類型。
這說明 12 條規則之間並不競爭同一塊注意力預算，它們各自管的是獨立的失控點。好的規則設計，覆蓋面互不重疊。
200 行紅線的物理含義
文檔超過 200 行，合規率從 76% 急速跌到 52%。
這不是 Claude 偷懶，是上下文窗口裏的注意力稀釋。當規則數量超過某個閾值，Claude 開始識別"規則存在"這個事實本身，而不再逐條解析每一條規則的含義。
實踐含義：CLAUDE.md 不是心願單，是行為合同。 每條規則都要問自己：這條規則防止了我真實踩過的哪個坑？防止不了真實的坑，就刪掉。
附：怎麼用 Claude 來寫你自己的 CLAUDE.md
（對，用 Claude 給 Claude 寫規則，沒有任何問題。）
把下面這個 Prompt 丟給 Claude，告訴它你項目的技術棧和你遇到的最常見失誤類型，它能幫你寫出一套項目定製化的規則：
我在用 Claude Code 開發 [你的技術棧，如：React + TypeScript + Node.js]。
請幫我寫一份 CLAUDE.md，包含以下信息：
- 項目類型：[Web 應用 / API 服務 / 等]
- 常見失誤：[你最常遇到的 Claude 錯誤類型]
- 現有規範：[你項目裏有沒有已有的代碼風格、測試規範等]
要求：
1. 包含本文提到的 12 條基礎規則
2. 在後面追加 3-5 條項目專屬規則
3. 總行數不超過 200 行
4. 每條規則都是可執行的命令句，不是模糊的期待總結
一張表，直接看數字：
Karpathy 的 4 條關掉了沉默假設、過度工程化、誤傷相鄰代碼、弱成功標準。
新的 8 條關掉了 Token 失控、無 Checkpoint 的錯誤複利、測試質量的虛假信心、沉默失敗的破壞力、約定衝突的混亂。
兩組規則都不可少。前者是地板，後者是天花板。
你不需要 12 條全上。6 條你真正踩過坑的規則，比 12 條照本宣科的規則有效得多。 讀完這篇，選你踩過的坑，刪掉你沒遇到的場景，今晚存成文件。
然後把錯誤率壓下去。
P.S. 這套規則不是萬能的。CLAUDE.md 是行為約束，不是技術能力的補丁。模型本身做不到的事，規則也叫不回來。但在模型能力範圍內，它讓"偶爾做到"變成"每次做到"——這才是 41% 到 3% 的真正來源。
堅持創作不易，求個一鍵三連，謝謝你～❤️
以及「AI Coding技術交流羣」，聯繫 ayqywx 我拉你進羣，共同交流學習～