Claude 写程式疯狂犯错装傻？12 条规则帮你把错误率从 41% 砍到 3%

Andrej Karpathy 年初抱怨 Claude 寫程式常犯錯，Forrest Chang 整理出 4 條規則，6 週內作者再補 8 條，覆蓋多步驟 Agent、hook 鏈式觸發等新場景。實測 30 個程式庫，錯誤率從 41% 驟降至 3%。（前情提要：SEC 下調券商穩定幣折扣率「從 100% 降至 2%」，為何是重大利多？）（背景補充：Anthropic AI 經濟指數萬字報告：自動化交易工作流頻率翻倍，Claude 正從工具變生活助理）揭露原版模板在 4 個關鍵場景默默失靈，並補上 8 條新規則，將錯誤率從 41% 壓到 3%。 026 年 1 月，AI 大神 Andrej Karpathy 在 X 上發文抱怨 Claude 寫程式的方式——暗中預設、過度設計、誤傷無關程式碼。Forrest Chang 將這些痛點濃縮成 4 條行為規則，放進 CLAUDE.md 檔案，一上線就爆紅。但幾個月後，Claude Code 生態已從單次補全進化到多步驟 Agent 協作，舊規則開始失靈。一位開發者在 6 週內測試 30 個程式庫，2026 年 1 月下旬，Andrej Karpathy 發了一條推文串，批評 Claude 寫程式碼的方式。他指出了三類典型問題：在沒有說明的情況下做出錯誤假設、過度複雜化，以及對原本不該改動的程式碼造成無關破壞。 Forrest Chang 看到了這條推文串，把其中的抱怨歸納為 4 條行為規則，寫進一個單獨的 CLAUDE.md 檔案，併發布到了 GitHub。這個專案上線第一天就獲得了 5,828 個 Star，兩週內被收藏 60,000 次，如今已有 120,000 個 Star，成為 2026 年增長最快的單檔案程式碼倉庫。隨後，我在 6 周時間裡，用 30 個程式碼庫對它進行了測試。這 4 條規則確實有效。過去大約 40% 機率會出現的錯誤，在適合這些規則發揮作用的任務中，下降到了 3% 以下。但問題在於，這個模板最初是為瞭解決 1 月份 Claude 寫程式碼時出現的錯誤。到了 2026 年 5 月，Claude Code 生態面臨的問題已經不同了：Agent 之間相互衝突、hook 鏈式觸發、skill 載入衝突，以及跨會話多步驟工作流中斷等。所以，我又加入了 8 條規則。下面是完整的 12 條規則版 CLAUDE.md：每一條為什麼值得加入，以及原版 Karpathy 模板會在哪 4 個地方默默失靈。如果你想跳過解釋，直接複製使用，完整檔案放在文末。 Claude Code 的 CLAUDE.md，是整個 AI 程式設計技術棧裡最被低估的檔案。大多數開發者通常會犯三類錯誤：第一，把它當成偏好垃圾桶，把自己所有習慣都塞進去，最後膨脹到 4000 多個 token，規則遵守率掉到 30%。第二，乾脆完全不用，每次都重新 prompt。這會造成 5 倍 token 浪費，而且不同會話之間缺乏一致性。第三，複製一個模板後就再也不管。它可能有效兩週，但隨著程式碼庫變化，會在你不知不覺中失效。 Anthropic just shipped Dreaming agents review their own sessions between runs, surface recurring mistakes, and rewrite their memory so the next session doesn't repeat them. Karpathy wrote CLAUDE.md for the same reason. > silent wrong assumptions > over-complication >… https://t.co/HqCTygknPK pic.twitter.com/lUkHfhH7hb— Mnimiy (@Mnilax) May 13, 2026 Anthropic 官方檔案說得很明確：CLAUDE.md 本質上只是建議性的。Claude 大約會有 80% 的時間遵循它。一旦超過 200 行，遵守率就會明顯下降，因為重要規則會被噪音淹沒。 Karpathy 的模板解決了這個問題：一個檔案、65 行、4 條規則。這是最低基準。但上限還可以更高。再加入下面這 8 條規則後，它覆蓋的就不只是 Karpathy 在 2026 年 1 月抱怨的程式碼寫作問題，也包括 2026 年 5 月才出現的 Agent 編排問題——這些問題在原模板寫成時還不存在。如果你還沒看過 Forrest Chang 的倉庫，先看這個基礎版本：規則 1：編碼前先思考。不要默默做假設。要說明你的假設，暴露權衡點。在猜測之前先提問。當存在更簡單的方案時，要主動提出反對意見。規則 2：簡單優先。用能解決問題的最少程式碼。不要加入想象中的功能。不要為一次性程式碼設計抽象層。如果一位資深工程師會認為它過度複雜，那就應該簡化。規則 3：外科手術式修改。只改必須改的部分。不要順手「最佳化」相鄰程式碼、註釋或格式。不要重構沒有壞掉的東西。保持與現有風格一致。規則 4：以目標為導向執行。先定義成功標準，然後迴圈迭代，直到完成驗證。不要告訴 Claude 每一步該怎麼做，而是告訴它成功結果應該是什麼樣，讓它自己迭代。這 4 條規則，能解決我在無人監督的 Claude Code 會話中看到的大約 40% 的失敗模式。剩下約 60% 的問題，則藏在下面這些空白地帶。每一條規則，都來自一個真即時刻：Karpathy 原來的 4 條規則已經不夠用了。下面我會先講那個場景，再給出對應規則。可以用 Claude 處理：分類、起草、總結、從非結構化文本中提取資訊。不要用 Claude 處理：路由、重試、狀態碼處理、確定性轉換。如果一個狀態碼已經回答了問題，那就讓普通程式碼來回答這個問題。 Karpathy 的規則沒有覆蓋這一點。於是模型開始決定一些本該由確定性程式碼處理的問題：是否重試一次 API 呼叫、如何路由一條訊息、什麼時候升級處理。結果是，每週的判斷都不一樣。你得到的是一種按每 token 0.003 美元計費的、不穩定的 if-else。那個時刻是這樣的：有一段程式碼會呼叫 Claude 來「判斷遇到 503 時是否應該重試」。它一開始執行得很好，持續了兩週，後來突然變得不穩定，因為模型開始把請求體也當作判斷上下文。重試策略變得隨機，因為 prompt 本身就是隨機的。單個任務預算：4,000 tokens。單次會話預算：30,000 tokens。如果一個任務接近預算上限，就總結當前狀態，然後重新開始。不要硬撐著繼續。明確暴露預算超限問題，比默默超支更好。沒有預算約束的 CLAUDE.md，就等於一張空白支票。每一次迴圈都有可能失控，變成一次 50,000 token 的上下文傾倒。模型不會自己停下來。那個時刻是這樣的：一次除錯會話持續了 90 分鐘。模型一直在圍繞同一段 8KB 的錯誤資訊反覆迭代，並逐漸忘記自己已經嘗試過哪些修復方案。到最後，它開始提出 40 條訊息之前我已經否定過的方案。如果有 token 預算，這個過程在第 12 分鐘就該被終止。如果程式碼庫中已有的兩種模式相互矛盾，不要把它們混在一起。選擇其中一種模式，優先選擇更新的或經過更多測試的模式，說明理由，並標記另一種模式後續需要清理。那種試圖同時滿足兩套規則的「平均程式碼」，是最糟糕的程式碼。當程式碼庫裡的兩個部分互相矛盾時，Claude 會試圖同時討好兩邊，結果寫出來的是一團不連貫的程式碼。那個時刻是這樣的：一個程式碼庫裡存在兩套錯誤處理模式，一套是 async/await 加顯式 try/catch，另一套是全域性錯誤邊界。Claude 寫出的新程式碼把兩套都用了。結果錯誤處理被做了兩遍。我花了 30 分鐘才弄明白，為什麼錯誤被吞掉了兩次。在一個檔案裡新增程式碼之前，先閱讀這個檔案的匯出內容、直接呼叫方，以及任何明顯相關的共享工具函式。如果你不理解現有程式碼為什麼這樣組織，就先提問，不要直接往裡加東西。「在我看來這不相關」，是這個程式碼庫裡最危險的一句話。 Karpathy 的「外科手術式修改」告訴 Claude 不要改動相鄰程式碼。但它沒有告訴 Claude：先理解相鄰程式碼。沒有這一條，Claude 會寫出和 30 行之外既有程式碼相沖突的新程式碼。那個時刻是這樣的：Claude 在一個已有函式旁邊新增了一個功能完全相同的函式，因為它沒有先讀原來的函式。兩個函式做的是同一件事。但由於 import 順序的關係，新函式覆蓋了舊函式，而舊函式已經作為事實上的唯一標準存在了 6 個月。每一個測試都必須編碼「為什麼這個行為重要」，而不只是「它做了什麼」。像 `expect(getUserName()).toBe(‘John’)` 這樣的測試是沒有價值的，如果這個函式其實接收的是一個硬編碼 ID。如果你寫不出一個會在業務邏輯變化時失敗的測試，那這個函式本身就是錯的。 Karpathy 的「以目標為導向執行」暗示測試可以作為成功標準。但在實踐中，Claude 會把「測試透過」當成唯一目標，於是寫出一些能透過淺層測試、卻會破壞其他東西的程式碼。那個時刻是這樣的：Claude 為一個認證函式寫了 12 個測試，全部透過。但生產環境裡的認證邏輯壞了。那些測試只是在驗證函式「返回了某個東西」，而不是驗證它是否返回了正確的東西。函式之所以能透過測試，是因為它返回的是一個常量。在多步驟任務中，每完成一個步驟後，總結已經做了什麼、驗證了什麼、還剩下什麼。不要從一個你無法向我複述清楚的狀態繼續往下做。如果你發現自己已經跟丟了，就停下來，重新陳述當前狀態。 Karpathy 的模板預設互動是一次性的。但真實的 Claude Code 工作往往是多步驟的：跨 20 個檔案重構、在一個會話裡構建功能、跨多個 commit 除錯。如果沒有檢查點，一步走錯，前面所有進度都可能丟失。那個時刻是這樣的：一個 6 步重構任務在第 4 步出錯了。等我發現時，Claude 已經在錯誤狀態之上繼續完成了第 5 步和第 6 步。拆解修復花的時間，比重做整個任務還長。如果有檢查點，第 4 步就能發現問題。如果程式碼庫使用 snake_case，而你更喜歡 camelCase：使用 snake_case。如果程式碼庫使用 class-based components，而你更喜歡 hooks：使用 class-based components。不同意見是另一場討論。在程式碼庫內部，一致性優先於個人偏好。如果你真的認為某個約定有害，就明確提出。不要默默開出一條分叉路徑。在一個已經有成熟模式的程式碼庫裡，Claude 喜歡引入自己的寫法。哪怕它的寫法「更好」，引入第二套模式本身，也比任何一種單一模式都更糟。那個時刻是這樣的：Claude 在一個基於 class component 的 React 程式碼庫裡引入了 hooks。它確實能執行。但它同時破壞了程式碼庫原有的測試模式，因為那些測試依賴 componentDidMount。最後花了半天時間才把它刪掉並重寫。如果你不能確定某件事已經成功，就明確說出來。如果有 30 條記錄被靜默跳過，就不能說「遷移完成」。如果你跳過了任何測試，就不能說「測試透過」。如果你沒有驗證我要求的邊界情況，就不能說「功能可用」。預設暴露不確定性，而不是隱藏它。 Claude 最昂貴的失敗，往往是那些看起來像成功的失敗。一個函式「能跑」，但返回了錯誤資料；一次 migration「完成了」，但跳過了 30 條記錄；一個測試「透過了」，但只是因為斷言本身是錯的。那個時刻是這樣的：Claude 說一次資料庫遷移「成功完成」。但實際上，它靜默跳過了 14% 觸發約束衝突的記錄。跳過行為被寫進了日誌，卻沒有被明確暴露出來。11 天后，當報表資料開始異常時，我們才發現問題。我在 6 周時間裡，追蹤了同一組 50 個代表性任務，覆蓋 30 個程式碼庫，測試了三種配置。錯誤率指的是：任務需要被糾正或重寫，才能匹配原始意圖。計入的錯誤包括：靜默錯誤假設、過度工程化、無關破壞、靜默失敗、違反約定、衝突折中、漏掉檢查點。遵守率指的是：當某條規則適用時，Claude 有多高機率會顯性應用這條規則。真正有意思的結果，不只是錯誤率從 41% 降到 3%。更重要的是，從 4 條規則擴充套件到 12 條規則，幾乎沒有增加遵守負擔，遵守率只是從 78% 變成 76%，但錯誤率又下降了 8 個百分點。新增規則覆蓋的是原來 4 條規則沒有處理的失敗模式，它們並沒有爭奪同一塊注意力預算。即便不加入新規則，原來的 4 條規則模板也至少在 4 個地方不夠用。第一，長時間執行的 Agent 任務。 Karpathy 的規則主要針對 Claude 正在寫程式碼的那一刻。但當 Claude 在執行一個多步驟 pipeline 時，會發生什麼？原模板沒有預算規則，沒有檢查點規則，也沒有「大聲失敗」規則。於是 pipeline 會慢慢漂移。第二，多程式碼庫一致性。「匹配現有風格」預設只有一種風格。但在一個擁有 12 個服務的 monorepo 裡，Claude 必須選擇到底匹配哪一種風格。原始規則沒有告訴它怎麼選。於是它要麼隨機選擇，要麼把幾種風格平均混合。第三，測試質量。「以目標為導向執行」會把「測試透過」視為成功，卻沒有說明測試本身必須有意義。結果就是，Claude 寫出一些幾乎什麼都沒驗證的測試，但這些測試會讓它誤以為自己很有把握。第四，生產環境與原型階段的差異。同樣的 4 條規則，可以防止生產程式碼被過度工程化，但也可能拖慢原型開發。因為原型階段有時確實需要 100 行探索性腳手架，先摸清方向。Karpathy 的「簡單優先」在早期程式碼裡容易過度觸發。這 8 條新增規則並不是要取代 Karpathy 的原始 4 條規則，而是在修補它們的空白：原模板對應的是 2026 年 1 月那種偏自動補全式的程式碼寫作場景；而到了 2026 年 5 月，Claude Code 已經進入由 Agent 驅動的、多步驟、多程式碼庫協作環境，兩者面對的問題並不一樣。在最終確定這 12 條規則之前，我也嘗試過一些其他方案。加入我在 Reddit / X 上看到的規則。其中大多數，要麼只是用不同說法重複 Karpathy 原來的 4 條規則，要麼是無法泛化的領域特定規則，比如「始終使用 Tailwind class」。最後都刪掉了。超過 12 條規則。我最多測試到 18 條。超過 14 條後，遵守率從 76% 掉到了 52%。200 行的上限是真實存在的。超過這個長度後，Claude 就會開始模式匹配成「這裡有規則」，而不是真的逐條閱讀規則。依賴某些工具存在的規則。比如「始終使用 eslint」，一旦專案裡沒有安裝 eslint，這條規則就會失效，而且是靜默失效。後來我把它改成了不依賴具體工具的表達，比如把「使用 eslint」改成「遵循程式碼庫中已經強制執行的風格」。在 CLAUDE.md 裡放示例，而不是規則。示例比規則更占上下文。三個示例消耗的上下文，差不多相當於 10 條規則，而且 Claude 很容易對示例過擬合。規則是抽象的，示例是具體的。所以，應當使用規則。「小心一點」「認真思考」「專注一點」。這些都是噪音。這類指令的遵守率掉到了大約 30%，因為它們無法被檢驗。後來我把它們替換成了更具體的命令式規則，比如「明確說明假設」。告訴 Claude 要像「資深工程師」一樣。這沒有用。Claude 本來就覺得自己像資深工程師。真正的問題不在於它是否這樣認為，而在於它是否這樣執行。命令式規則可以縮小這個差距，身份提示詞不行。以下是可直接複製貼上使用的完整版本。暫時無法在飛書檔案外展示此內容將它儲存為倉庫根目錄下的 CLAUDE.md。在這 12 條規則下面，再新增專案專屬規則，比如技術棧、測試命令、錯誤模式等。整體不要超過 200 行，超過之後，規則遵守率就會明顯下降。兩步即可： 1. 將 Karpathy 的 4 條基礎規則追加到你的 CLAUDE.md 中 curl https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md >> CLAUDE.md 2. 將本文中的規則 5–12 貼上到下面把檔案儲存在倉庫根目錄。這裡的 >> 很重要，它的作用是追加到已有的 CLAUDE.md，而不是覆蓋你已經寫好的專案專屬規則。 CLAUDE.md 不是願望清單，而是一份行為契約，用來封堵你已經觀察到的具體失敗模式。每一條規則都應該回答一個問題：它能防止什麼錯誤？ Karpathy 的 4 條規則，防的是他在 2026 年 1 月看到的失敗模式：靜默假設、過度工程化、無關破壞、成功標準薄弱。它們是基礎，不要跳過。我新增的 8 條規則，防的是 2026 年 5 月之後出現的新失敗模式：沒有預算約束的 Agent 迴圈、沒有檢查點的多步驟任務、看似測試了但其實沒測到關鍵邏輯的測試，以及把靜默失敗包裝成靜默成功的問題。它們是增量補丁。當然，具體效果因人而異。如果你不跑多步驟 pipeline，規則 10 對你就沒那麼重要。如果你的程式碼庫只有一種統一風格，而且已經由 lint 強制執行，規則 11 就是冗餘的。讀完這 12 條後，保留那些真正對應你實際犯過錯誤的規則，刪掉其餘部分。一份針對真實失敗模式定製的 6 條規則版 CLAUDE.md，勝過一份有 12 條規則、其中 6 條你永遠用不上的版本。 Karpathy 在 2026 年 1 月的那條推文，本質上是一場抱怨。Forrest Chang 把它變成了 4 條規則。最終，12 萬開發者給這個結果點了 Star。而其中大多數人，今天仍然只在使用那 4 條規則。模型已經進步，生態也已經變了。多步驟 Agent、hook 鏈式觸發、skill 載入、多程式碼庫協作——這些在 Karpathy 寫下那條推文時都還不存在。原來的 4 條規則並沒有解決這些問題。它們不是錯了，而是不完整了。新增 8 條規則。6 周時間，覆蓋 30 個程式碼庫的測試。錯誤率從 41% 降到 3%。今晚就收藏這篇文章，把這 12 條規則貼上進你的 CLAUDE.md。如果它幫你少走一週 Claude 彎路，歡迎轉發。