Andrej Karpathy 年初抱怨 Claude 寫程式常犯錯，Forrest Chang 整理出 4 條規則，6 週內作者再補 8 條，覆蓋多步驟 Agent、hook 鏈式觸發等新場景。實測 30 個程式庫，錯誤率從 41% 驟降至 3%。
（前情提要：SEC 下調券商穩定幣折扣率「從 100% 降至 2%」，為何是重大利多？）
（背景補充：Anthropic AI 經濟指數萬字報告：自動化交易工作流頻率翻倍，Claude 正從工具變生活助理）
本文目錄
- Karpathy 的 4 條規則：從抱怨到爆紅的 12 萬星
- 新戰場：Agent 衝突、hook 連鎖、跨 session 中斷
- 規則 5-8：預算上限、模式統一、測試真邏輯
- 規則 9-12：檢查點、風格一致、靜默失敗現形
- 實測 30 個程式庫：錯誤率從 41% 降到 3% 的關鍵
2026 年 1 月，AI 大神 Andrej Karpathy 在 X 上發文抱怨 Claude 寫程式的方式——暗中預設、過度設計、誤傷無關程式碼。Forrest Chang 將這些痛點濃縮成 4 條行為規則，放進 CLAUDE.md 檔案，一上線就爆紅。但幾個月後，Claude Code 生態已從單次補全進化到多步驟 Agent 協作，舊規則開始失靈。一位開發者在 6 週內測試 30 個程式庫，揭露原版模板在 4 個關鍵場景默默失靈，並補上 8 條新規則，將錯誤率從 41% 壓到 3%。
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 浪費，而且不同會話之間缺乏一致性。
第三，複製一個模板後就再也不管。它可能有效兩週，但隨著程式碼庫變化，會在你不知不覺中失效。
Karpathy 的 4 條規則：從抱怨到爆紅的 12 萬星
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 條規則已經不夠用了。下面我會先講那個場景，再給出對應規則。
Karpathy 的規則沒有覆蓋這一點。於是模型開始決定一些本該由確定性程式碼處理的問題：是否重試一次 API 呼叫、如何路由一條訊息、什麼時候升級處理。結果是，每週的判斷都不一樣。你得到的是一種按每 token 0.003 美元計費的、不穩定的 if-else。
新戰場：Agent 衝突、hook 連鎖、跨 session 中斷
那個時刻是這樣的：有一段程式碼會呼叫 Claude 來「判斷遇到 503 時是否應該重試」。它一開始執行得很好，持續了兩週，後來突然變得不穩定，因為模型開始把請求體也當作判斷上下文。重試策略變得隨機，因為 prompt 本身就是隨機的。
沒有預算約束的 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 個月。
Karpathy 的「以目標為導向執行」暗示測試可以作為成功標準。但在實踐中，Claude 會把「測試透過」當成唯一目標，於是寫出一些能透過淺層測試、卻會破壞其他東西的程式碼。
那個時刻是這樣的：Claude 為一個認證函式寫了 12 個測試，全部透過。但生產環境裡的認證邏輯壞了。那些測試只是在驗證函式「返回了某個東西」，而不是驗證它是否返回了正確的東西。函式之所以能透過測試，是因為它返回的是一個常量。
Karpathy 的模板預設互動是一次性的。但真實的 Claude Code 工作往往是多步驟的：跨 20 個檔案重構、在一個會話裡構建功能、跨多個 commit 除錯。如果沒有檢查點，一步走錯，前面所有進度都可能丟失。
那個時刻是這樣的：一個 6 步重構任務在第 4 步出錯了。等我發現時，Claude 已經在錯誤狀態之上繼續完成了第 5 步和第 6 步。拆解修復花的時間，比重做整個任務還長。如果有檢查點，第 4 步就能發現問題。
在一個已經有成熟模式的程式碼庫裡，Claude 喜歡引入自己的寫法。哪怕它的寫法「更好」，引入第二套模式本身，也比任何一種單一模式都更糟。
規則 5-8：預算上限、模式統一、測試真邏輯
那個時刻是這樣的：Claude 在一個基於 class component 的 React 程式碼庫裡引入了 hooks。它確實能執行。但它同時破壞了程式碼庫原有的測試模式，因為那些測試依賴 componentDidMount。最後花了半天時間才把它刪掉並重寫。
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 的「簡單優先」在早期程式碼裡容易過度觸發。
規則 9-12：檢查點、風格一致、靜默失敗現形
這 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 行，超過之後，規則遵守率就會明顯下降。
兩步即可：
實測 30 個程式庫：錯誤率從 41% 降到 3% 的關鍵
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 彎路，歡迎轉發。
📍相關報導📍
Claude Code 邊做邊學：這免費網站用 11 堂課教你上手，免安裝直接練
頂級 AI 模型走向分化：ChatGPT to C，Claude to B
Anthropic 訂閱 Claude Code 封殺龍蝦 OpenClaw！往後第三方工具僅能付費額度
