2026 年 1 月下旬，Andrej Karpathy 發了一篇討論串，抱怨 Claude 寫程式碼的方式。三種失敗模式：無聲的錯誤假設、過度複雜化、對不該碰的程式碼造成附帶損害。
Forrest Chang 讀了這篇討論串，將這些抱怨打包成一個 CLAUDE.md 檔案中的 4 條行為規則，並放上 GitHub。第一天就獲得 5,828 顆星。兩週內有 60,000 個書籤。今天已達 120,000 顆星。 2026 年成長最快的單一檔案儲存庫。
然後，我在 6 週內於 30 個程式碼庫上測試了它。
這 4 條規則有效。在適合它們發揮的任務上，過去約 40% 會發生的錯誤，下降到低於 3%。但這個模板是為了解決 1 月的程式碼撰寫錯誤而建立的。
2026 年 5 月的 Claude Code 生態系統有著不同的問題——Agent 衝突、Hook 串聯、技能載入衝突、跨 session 中斷的多步驟工作流程。
所以我增加了 8 條規則。以下：完整的 12 條規則 CLAUDE.md、每條規則為何有其存在的必要，以及原始 Karpathy 模板在 4 個地方會無聲地失效。
如果你想跳過解釋直接貼上，完整的檔案在最後面。
為什麼這很重要
Claude Code 的 CLAUDE.md 是整個 AI 編碼堆疊中最被低估的檔案。大多數開發者要嘛：
- 把它當作傾倒所有偏好的垃圾桶，膨脹到超過 4,000 個 token，遵循率降到 30%
- 完全跳過它，每次都重新提示——浪費 5 倍的 token，session 之間沒有連貫性
- 複製一個模板後就忘記。有效兩週，然後隨著程式碼庫的變化而無聲地失效
Anthropic 的官方文件說得很清楚：CLAUDE.md 是建議性質的。Claude 大約 80% 的時間會遵循它。超過 200 行後，遵循率會急遽下降，因為重要的規則會被淹沒在雜訊中。
Karpathy 的模板用一個檔案、65 行、4 條規則解決了這個問題。這是地板。
天花板更高。透過下面我將說明的另外 8 條規則，你不僅涵蓋了 Karpathy 抱怨的 2026 年 1 月的程式碼撰寫問題，還涵蓋了撰寫模板時還不存在的 2026 年 5 月的 Agent 編排問題。
原始的 4 條規則
如果你還沒讀過 Forrest Chang 的儲存庫，這是基礎：
**規則 1 — 先思考再編碼。
**沒有無聲的假設。說出你的假設。揭露取捨。在猜測之前先提問。當有更簡單的方法時，提出異議。
**規則 2 — 簡潔至上。
**解決問題的最小程式碼。沒有投機的功能。沒有為一次性程式碼設計的抽象。如果資深工程師會說它過度複雜——就簡化它。
**規則 3 — 外科手術式變更。
**只碰你必須碰的。不要「改進」相鄰的程式碼、註解或格式。不要重構沒有壞掉的東西。符合現有風格。
**規則 4 — 目標驅動執行。
**定義成功標準。持續迭代直到驗證。不要告訴 Claude 要遵循哪些步驟，告訴它成功的樣子，讓它自己迭代。
這四條規則消除了我在無監督的 Claude Code session 中看到的大約 40% 的失敗模式。其餘大約 60% 存在於下面的缺口之中。
我增加的 8 條規則（以及原因）
每一條都來自於 Karpathy 的 4 條規則不夠用的真實時刻。我會展示那個時刻，然後是規則。
規則 5 — 不要讓模型做非語言的工作
Karpathy 的規則對此保持沉默。模型決定那些應該是確定性程式碼的事情，例如是否重試 API 呼叫、如何路由訊息、何時升級。每週都有不同的決定。以每個 token $0.003 的代價執行不穩定的 if-else。
1## 規則 5 — 僅將模型用於判斷性呼叫2將 Claude 用於：分類、草稿、摘要、從非結構化文字中提取。3不要將 Claude 用於：路由、重試、狀態碼處理、確定性轉換。4如果狀態碼已經回答了問題，純程式碼就回答了問題。
那個時刻： 呼叫 Claude 來「決定是否在收到 503 時重試」的程式碼完美運行了兩週，然後開始不穩定，因為模型開始將請求主體作為決策的上下文來讀取。重試策略變得隨機，因為提示是隨機的。
規則 6 — 嚴格的 token 預算，沒有例外
沒有預算的 CLAUDE.md 就是一張空白支票。每個迴圈都有可能失控，變成一個 50,000 token 的上下文傾倒。模型不會自行停止。
1## 規則 6 — Token 預算不是建議2每個任務預算：4,000 個 token。3每個 session 預算：30,000 個 token。4如果任務接近預算，總結並重新開始。不要硬撐。5揭露超支 > 默默地超支。
那個時刻： 一個除錯 session 持續了 90 分鐘。模型非常樂意在同一條 8KB 的錯誤訊息上迭代，逐漸忘記已經嘗試過哪些修復。到最後，它開始建議我在 40 則訊息前就拒絕過的修復。Token 預算會在 12 分鐘時就終止它。
規則 7 — 揭露衝突，不要平均它們
當程式碼庫的兩個部分意見不一致時，Claude 會試圖取悅兩者。結果是不連貫的。
1## 規則 7 — 揭露衝突，不要平均它們2如果程式碼庫中兩個現有模式互相矛盾，不要混合它們。3選擇一個（較新 / 經過較多測試的），解釋原因，並標記另一個待清理。4滿足兩條規則的「平均」程式碼是最糟糕的程式碼。
那個時刻： 一個程式碼庫有兩種錯誤處理模式——一種是使用明確 try/catch 的 async/await，另一種是使用全域錯誤邊界。Claude 寫的新程式碼同時使用了兩者。錯誤處理器加倍。我花了 30 分鐘才弄清楚為什麼錯誤被吞了兩次。
規則 8 — 先讀再寫
Karpathy 的「外科手術式變更」告訴 Claude 不要碰相鄰的程式碼。它沒有告訴 Claude 要先理解相鄰的程式碼。沒有這個，Claude 寫的新程式碼會與 30 行外的現有程式碼衝突。
1## 規則 8 — 先讀再寫2在檔案中新增程式碼之前，請先讀取該檔案的匯出、直接呼叫者以及任何明顯的共享工具。3如果你不了解現有程式碼為何如此結構，請在新增程式碼之前提問。4「看起來與我無關」是這個程式碼庫中最危險的詞語。
那個時刻： Claude 在一個它沒讀過的現有相同函式旁邊新增了一個函式。兩個函式做同樣的事情。新的那個因為匯入順序而優先。舊的那個已經作為事實來源 6 個月了。
規則 9 — 測試不是可選的，但它們不是目標
Karpathy 的目標驅動執行暗示測試是成功標準。實際上，Claude 將「測試通過」視為唯一目標，並寫出能通過淺層測試但破壞其他一切的程式碼。
1## 規則 9 — 測試驗證意圖，而不僅僅是行為2每個測試都必須編碼 WHY 行為很重要，而不僅僅是 WHAT 它做了什麼。3像 `expect(getUserName()).toBe('John')` 這樣的測試，如果函式接受一個硬編碼的 ID，那就毫無價值。4如果你無法寫出一個在業務邏輯改變時會失敗的測試，那麼這個函式就是錯的。
那個時刻： Claude 為一個驗證函式寫了 12 個測試。全部通過。驗證在生產環境中卻是壞的。這些測試是在測試函式是否回傳了某個東西，而不是是否回傳了正確的東西。函式通過是因為它回傳了一個常數。
規則 10 — 長時間運行的操作需要檢查點
Karpathy 的模板假設是一次性互動。真正的 Claude Code 工作是跨多個步驟的——跨 20 個檔案重構、在一個 session 中建構功能、跨多個提交進行除錯。沒有檢查點，一個錯誤的轉彎就會失去所有進度。
1## 規則 10 — 在每個重要步驟後設定檢查點2在完成多步驟任務的每個步驟後：總結完成了什麼、驗證了什麼、還剩下什麼。3不要從你無法向我描述的狀態繼續。4如果你迷失了方向，停下來重新陳述。
那個時刻： 一個 6 步驟的重構在第 4 步出了問題。當我注意到時，Claude 已經在錯誤的狀態上完成了第 5 和第 6 步。釐清花費的時間比重做整個事情還要長。檢查點會在第 4 步就發現問題。
規則 11 — 慣例勝過新穎
在一個有既定模式的程式碼庫中，Claude 喜歡引入自己的模式。即使它的方式「更好」，引入兩種模式也比單獨使用任何一種模式更糟。
1## 規則 11 — 符合程式碼庫的慣例，即使你不同意2如果程式碼庫使用 snake_case 而你偏好 camelCase：用 snake_case。3如果程式碼庫使用基於 class 的元件而你偏好 hooks：用基於 class 的。4不同意是另一場對話。在程式碼庫內部，一致性 > 個人品味。5如果你真的認為某個慣例是有害的，請提出來。不要默默地分支。
那個時刻： Claude 將 React hooks 引入了一個基於 class 元件的程式碼庫。它們能運作。但它們也破壞了程式碼庫的測試模式，這些模式假設了 componentDidMount。花了半天時間移除並重寫。
規則 12 — 明顯地失敗，而不是無聲地失敗
最昂貴的 Claude 失敗是那些看起來像成功的失敗。一個函式「能運作」但回傳了錯誤的資料。一個遷移「完成」但跳過了 30 筆記錄。一個測試「通過」但只是因為斷言是錯的。
1## 規則 12 — 大聲失敗2如果你不能確定某件事是否成功，請明確地說出來。3如果 30 筆記錄被無聲地跳過，「遷移完成」就是錯的。4如果你跳過了任何測試，「測試通過」就是錯的。5如果你沒有驗證我問到的邊緣案例，「功能正常」就是錯的。6預設是揭露不確定性，而不是隱藏它。
那個時刻： Claude 說資料庫遷移「成功完成」。它默默地跳過了 14% 因違反約束而失敗的記錄。跳過被記錄了但沒有被揭露。11 天後，當報表開始看起來不對勁時才發現問題。
數據
我在 6 週內追蹤了跨越 30 個程式碼庫的同一組 50 個代表性任務。三種配置：
錯誤率 = 任務需要修正或重寫才能符合意圖。計數：無聲的錯誤假設、過度工程化、附帶損害、無聲失敗、慣例違反、衝突平均、錯過檢查點。
遵循率 = Claude 在相關規則適用時，明顯應用該規則的頻率。
有趣的結果不是錯誤率從 41% 下降到 3% 的 headline 數字。而是從 4 條規則增加到 12 條規則，幾乎沒有增加遵循率的開銷（78% -> 76%），但卻將錯誤率再降低了 8 個百分點。新規則涵蓋了原始 4 條規則沒有解決的失敗模式——它們不會競爭相同的注意力預算。
Karpathy 模板無聲失效的地方
原始 4 條規則模板不夠用的四個地方，即使在增加新規則之前也是如此：
**1. 長時間運行的 Agent 任務。
*Karpathy 的規則針對的是 Claude 撰寫程式碼的時刻。它們對 Claude 執行*多步驟管道時會發生什麼保持沉默。沒有預算規則。沒有檢查點規則。沒有「大聲失敗」規則。管道會漂移。
**2. 多程式碼庫一致性。
**「符合現有風格」假設只有一種風格。在一個有 12 個服務的 monorepo 中，Claude 必須選擇哪種風格。原始規則沒有告訴它如何選擇。它隨機選擇或取平均值。
**3. 測試品質。
*目標驅動執行將「測試通過」視為成功。沒有說測試必須是有意義的*。結果是測試沒有測試任何有用的東西，但卻讓 Claude 充滿信心。
**4. 生產環境 vs 原型。
**保護生產程式碼免於過度工程化的同一套 4 條規則，也會拖慢那些為了找出方向而合法需要 100 行投機性 scaffolding 的原型。Karpathy 的「簡潔至上」在早期階段的程式碼上過度開火。
新增的 8 條規則並沒有取代 Karpathy 的 4 條規則。它們修補了他在 2026 年 1 月的自動補全式編碼模型與 2026 年 5 月的 Agent 驅動、多步驟、多程式碼庫工作之間不匹配的缺口。
什麼沒有效
在確定 12 條規則之前，我嘗試過的事情：
- 加入我在 Reddit / X 上看到的規則。 大多數要嘛是用不同措辭重述 Karpathy 的 4 條規則，要嘛是無法通用的領域特定規則（「總是使用 Tailwind classes」）。把它們刪掉了。
- 超過 12 條規則。 我測試到 18 條。超過 14 條規則後，遵循率從 76% 下降到 52%。200 行的上限是真實存在的。超過之後，Claude 開始模式匹配到「存在規則」，但實際上並沒有讀取它們。
- 依賴於可能不存在的工具的規則。「總是使用 eslint」在 eslint 未安裝時會失效。規則無聲地失敗。替換為與能力無關的措辭：「符合程式碼庫強制執行的風格」而不是「使用 eslint」。
- 在 CLAUDE.md 中放範例而不是規則。 範例比規則更重。三個範例消耗的上下文大約相當於 10 條規則，而且 Claude 會過度擬合它們。規則是抽象的，範例是具體的。使用規則。
- 「要小心」/「努力思考」/「真正專注」。 純粹的雜訊。這些規則的遵循率下降到約 30%，因為它們無法測試。替換為具體的命令（「明確陳述假設」）。
- 告訴 Claude 要「資深」。 沒有效。Claude 已經認為自己是資深的。遵循率的差距在於思考與行動之間。命令式規則縮小了差距；身份提示則沒有。
完整的 12 條規則 CLAUDE.md（可直接複製貼上）
1# CLAUDE.md — 12 條規則模板23除非明確覆蓋，否則這些規則適用於此專案中的每個任務。4偏見：在非平凡工作上，謹慎勝過速度。在瑣碎任務上使用判斷力。56## 規則 1 — 先思考再編碼7明確陳述假設。如果不確定，提問而不是猜測。8當存在歧義時，提出多種解釋。9當存在更簡單的方法時，提出異議。10感到困惑時停下來。說出不清楚的地方。1112## 規則 2 — 簡潔至上13解決問題的最小程式碼。沒有投機的東西。14沒有超出要求的任何功能。沒有為一次性程式碼設計的抽象。15測試：資深工程師會說這過度複雜嗎？如果是，就簡化。1617## 規則 3 — 外科手術式變更18只碰你必須碰的。只清理你自己的爛攤子。19不要「改進」相鄰的程式碼、註解或格式。20不要重構沒有壞掉的東西。符合現有風格。2122## 規則 4 — 目標驅動執行23定義成功標準。持續迭代直到驗證。24不要遵循步驟。定義成功並迭代。25強大的成功標準讓你能獨立迭代。2627## 規則 5 — 僅將模型用於判斷性呼叫28將我用於：分類、草稿、摘要、提取。29不要將我用於：路由、重試、確定性轉換。30如果程式碼能回答，就讓程式碼回答。3132## 規則 6 — Token 預算不是建議33每個任務：4,000 個 token。每個 session：30,000 個 token。34如果接近預算，總結並重新開始。35揭露超支。不要默默地超支。3637## 規則 7 — 揭露衝突，不要平均它們38如果兩個模式矛盾，選擇一個（較新 / 經過較多測試的）。39解釋原因。標記另一個待清理。40不要混合衝突的模式。4142## 規則 8 — 先讀再寫43在新增程式碼之前，請先讀取匯出、直接呼叫者、共享工具。44「看起來與我無關」是危險的。如果不確定程式碼為何如此結構，請提問。4546## 規則 9 — 測試驗證意圖，而不僅僅是行為47測試必須編碼 WHY 行為很重要，而不僅僅是 WHAT 它做了什麼。48一個在業務邏輯改變時無法失敗的測試就是錯的。4950## 規則 10 — 在每個重要步驟後設定檢查點51總結完成了什麼、驗證了什麼、還剩下什麼。52不要從你無法向我描述的狀態繼續。53如果你迷失了方向，停下來重新陳述。5455## 規則 11 — 符合程式碼庫的慣例，即使你不同意56在程式碼庫內部，一致性 > 個人品味。57如果你真的認為某個慣例是有害的，請提出來。不要默默地分支。5859## 規則 12 — 大聲失敗60如果有任何東西被默默地跳過，「完成」就是錯的。61如果有任何測試被跳過，「測試通過」就是錯的。62預設是揭露不確定性，而不是隱藏它。
將其儲存為你儲存庫根目錄下的 CLAUDE.md。在 12 條規則下方加入專案特定的規則（技術棧、測試命令、錯誤模式）。總行數不要超過 200 行，超過之後，遵循率會下降。
如何安裝
兩個步驟：
1# 1. 將 Karpathy 的 4 條規則基準附加到你的 CLAUDE.md2curl https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md >> CLAUDE.md34# 2. 將本文中的規則 5-12 貼在下方
儲存在你的儲存庫根目錄。>> 很重要，它會附加到你現有的 CLAUDE.md 中，而不是覆蓋你已有的任何專案特定規則。
心智模型
CLAUDE.md 不是一個願望清單。它是一個行為合約，用來關閉你觀察到的特定失敗模式。
每條規則都應該回答：這能防止什麼錯誤？
Karpathy 的 4 條規則防止了他在 2026 年 1 月看到的失敗模式： 無聲的假設、過度工程化、附帶損害、薄弱的成功標準。它們是基礎。不要跳過它們。
我增加的 8 條規則防止了 2026 年 5 月出現的失敗模式： 沒有預算的 Agent 迴圈、沒有檢查點的多步驟任務、沒有測試的測試、隱藏無聲失敗的無聲成功。它們是附加的。
你的情況可能會有所不同。如果你不運行多步驟管道，規則 10 就不重要。如果你的程式碼庫透過 linting 強制執行一種一致的風格，規則 11 就是多餘的。閱讀這 12 條，保留那些對應到你實際犯過的錯誤的規則，丟掉其他的。
一個針對你真實失敗模式調整過的 6 條規則 CLAUDE.md，勝過一個有 6 條你永遠不會需要的規則的 12 條規則 CLAUDE.md。
結 束
Karpathy 在 2026 年 1 月的討論串是一個抱怨。Forrest Chang 把它變成了 4 條規則。120,000 名開發者為結果加了星標。他們中的大多數今天仍在運行這 4 條規則。
模型已經改進。生態系統已經改變。多步驟 Agent、Hook 串聯、技能載入、多程式碼庫工作——這些在 Karpathy 撰寫他的討論串時都不存在。這 4 條規則沒有解決它們。它們沒有錯；它們是不完整的。
再加 8 條規則。在 30 個程式碼庫上進行 6 週的測試。錯誤率從 41% 降到 3%。
把這篇收藏起來，今晚就把這 12 條規則貼到你的 CLAUDE.md 裡。如果它為你省下了一週的 Claude 錯誤轉彎，請轉發。
Telegram 每日 Claude 優化技巧：
