Karpathy 的 CLAUDE.md 解析：一場技能搜尋背後的單一檔案

在 Google Trends 上，全球範圍內，過去七天（讀取於 2026 年 10 月 23 日），「karpathy skills」在「claude skills」種子查詢下顯示為竄升查詢。任何追蹤該搜尋的人最終都會來到同一個地方：github.com/multica-ai/andrej-karpathy-skills，這是一個在 GitHub 上顯示 222,612 顆星、讀取於 2026 年 10 月 23 日的儲存庫。它的說明完全沒有包含 skill 這個詞。說明寫道：「一個單一的 CLAUDE.md 檔案，用來改善 Claude Code 的行為，衍生自 Andrej Karpathy 對 LLM 程式設計陷阱的觀察。」

查詢與物件之間的落差並不是一個小小的技術細節。技能與 CLAUDE.md 檔案是不同的機制，做著不同的工作，而人們對這個儲存庫提出的幾乎每一項說法，不是取決於知道它到底是哪一個，就是默默假設成錯的那一個。裡面的指引是單一檔案。圍繞該檔案的儲存庫還帶有一份外掛資訊清單，以及 skills 底下的一個資料夾，搜尋列裡的那個詞大概就是從這裡來的。把包裝與實際內容分開，是這裡第一個有用的動作。

這些數字全都來自 GitHub，讀取於 2026 年 10 月 23 日：222,612 個星標、22,321 個分支（fork）、建立於 2026 年 1 月 27 日、最後推送於 2026 年 4 月 20 日、MIT 授權條款。最後那兩個日期才是耐人尋味之處。這個儲存庫大約六個月沒收到任何推送，星標數卻仍持續攀升。

檔案負責實際運作；包裝則說明搜尋詞。

打開儲存庫，檔案清單就讓這種不一致顯而易見。根目錄有 CLAUDE.md，旁邊有 CURSOR.md、EXAMPLES.md、一個 .cursor/rules 資料夾（其中包含與 Cursor 專案規則相同的指引）、一個 .claude-plugin 資料夾，以及一個 skills/karpathy-guidelines 目錄。README 建議的安裝途徑是外掛市集，並將結果描述為讓「該技能可在你所有專案中使用」。

所以，這個搜尋詞與其說是錯誤，不如說是不夠精確。有一個 skills 資料夾。有一個外掛。沒有的是一組各自負責不同工作的獨立技能，而這正是人們通常所說的技能包樣貌：一個資料夾，裡面放著 SKILL.md 以及該能力所需的任何支援檔案，並針對單一任務叫用。在這裡，整份指引是一份單一的常設指示文件，而外掛的存在是為了將該文件交付到專案中。

這個區別對你是否重要，取決於你想從這次搜尋中得到什麼。如果你在找的是一個工具箱，這並不是。如果你想要的是一本簡短的規則手冊，能改變 coding agent 在整個專案中的行為，那它正是如此；而且值得理解為什麼有人會把它寫成檔案，而不是寫成 skills。

它所針對的那些投訴

README 標示的來源，是 Andrej Karpathy 在 X 上的一則貼文；README 引用了這則貼文中針對模型如何撰寫程式碼的三項抱怨。這些抱怨值得完整讀過，因為那四項原則幾乎與它們一一對應。

第一點：模型「會替你做出錯誤假設，然後不經查核就順著這些假設一路做下去」，而且「不會處理自己的困惑、不會尋求澄清、不會揭露不一致之處、不會呈現取捨，也不會在該反駁時反駁」。請注意這裡描述的是什麼。這不是在抱怨答案錯誤，而是在抱怨流暢的錯誤答案被毫不猶豫地給出：本應引發提問的不確定性，反而產生了自信滿滿的程式碼。

第二點：他們「真的很喜歡把程式碼和 API 過度複雜化、讓抽象膨脹、不清理死程式碼……明明 100 行就夠了，卻要實作超過 1000 行的臃腫建構。」只要曾經要求一項功能、結果卻收到一整套框架的人，對這一點都不陌生。

第三點更微妙，而且對任何審查 diff 的人來說代價最高：他們「仍然有時會把他們理解不夠充分的註解和程式碼當作副作用來變更／移除，即使這與任務無關」。對單一註解做無關的編輯，本身影響很小。但放大到整個程式碼庫後，這正是審查佇列被沒有人要求的變更塞滿的方式，也是解釋某個 workaround 的註解在任何人了解該 workaround 為何存在之前就消失的方式。

四項原則，以及每一項所留下的考驗

這個檔案體現了四項原則。每一項都附有一組簡短的規則，其中兩項明確寫出一行測試，讓你不必安裝任何東西就能套用到 diff 上。規則正是這個檔案的特色所在。

寫程式前先思考

該標題的指示是「不要假設。不要隱藏困惑。攤開取捨。」在其下：明確陳述假設，並提問而非猜測；當請求含糊時，提出多種解讀；當存在更簡單的做法時，提出反對；感到困惑時停下來，指出不清楚之處，並要求釐清。這正是針對第一個抱怨。其機制不是「更小心」，而是把無聲的選擇轉為可見的選擇，讓審查者能在程式碼存在之前而非之後提出異議。

簡約優先

這條規則就是：用最少的程式碼解決問題，不做任何臆測性的添加——不額外加入沒被要求的功能，不為一次性使用的程式碼建立抽象，不提供沒人要求的彈性或可配置性，不為不可能發生的情境撰寫錯誤處理，而且「如果 200 行能寫成 50 行，就改寫它」。檢驗標準只有一個問題——資深工程師會不會說這寫得太複雜了？——這是一個判斷取捨，而且我們也坦然承認如此。

手術性變更

這裡檔案把指令分成兩部分，這是其中最有用的地方。編輯既有程式碼時：不要順手改善鄰近的程式碼、註解或格式；不要重構沒壞的東西；即使你會寫得不一樣，也要配合既有風格；遇到無關的無用程式碼，提出來就好，不要直接刪掉。當你自己的改動產生孤兒時：移除因你的改動而變得未使用的 import、變數和函式，但除非有人要求，否則不要動到原本就存在的無用程式碼。判斷標準是：每一行改動都能直接追溯到需求。

目標驅動的執行

定義成功準則，並持續循環直到驗證通過。README 以成對方式呈現這種轉換。與其「加入驗證」，不如針對無效輸入撰寫測試，然後讓這些測試通過。與其「修正錯誤」，不如撰寫一個能重現該錯誤的測試，然後讓它通過。與其「重構 X」，不如確保重構前後的測試都通過。對於多步驟工作，它要求一份簡短計畫，其中每個步驟都要指明自己的驗證方式。README 在這裡再次引用 Karpathy 的話：「大型語言模型非常擅長持續循環，直到達成特定目標……不要告訴它該做什麼，給它成功準則，然後看它發揮。」

檔案、技能和外掛是三種不同的東西

值得把這套機制講精確，因為實際行為並不相同。CLAUDE.md 是專案指示檔：Claude Code 會把它當作某個儲存庫的常駐上下文來讀取，無論這一輪是否有人要求，它都會存在。Skill 是一個含有 SKILL.md 的資料夾，SKILL.md 描述這項能力應在何時使用；只有在任務需要時才會載入，在此之前不會。Plugin 則是透過市集安裝的發佈套件，可搭載 skills、指令與其他元件。這些區別的著眼點在於指示何時進入上下文、以及由誰決定，而不在於品質高低。

從這個角度來看，CLAUDE.md 是三者中最直白的一種。它在該專案中永遠處於啟用狀態，適用於專案裡的每一項任務，而且無論工作只是修一行錯字，還是進行一次遷移，它都會在每一輪佔用上下文。該檔案自己的 README 在一個名為「權衡說明」的章節中承認了這項成本：這些指引偏向謹慎而非速度，而對於瑣碎的任務——簡單的錯字修正、顯而易見的一行程式碼——你應該自行判斷。它說，目標是減少非瑣碎工作中代價高昂的錯誤，而不是拖慢簡單的工作。

這是對常設指示檔能做什麼的如實說明。它無法為模型增添模型本身不具備的能力。它只能讓模型既有的行為更可能或更不可能發生。這正是為什麼該檔案是以限制的形式寫成——不要做這個、做那個之前先問——而不是以鼓勵模型變得更好的形式寫成。

222,612 顆恆星衡量的是什麼

它們衡量的是關注度。這不是貶低，也不是無關緊要：一個於 2026 年 1 月建立、最後一次推送是在 4 月的儲存庫，到了 2026 年 10 月 23 日，在 GitHub 上達到 222,612 顆星和 22,321 次分支；這是當天讀到的數據，意味著它被廣泛分享，並被想要自己留一份副本的人分支。星數能相當合理地反映有多少人覺得某個東西值得加入書籤。

這並不是效果的替代指標，而該儲存庫也沒有假裝不然。在其中任何地方都未發表的是：任何比較有無該檔案之結果的基準測試、任何衡量它是否有效的方法，以及任何與對照組的比較。沒有在真實程式碼庫上的前後對照，沒有審查者研究，沒有事故率。這樣的一份檔案是關於模型行為的假設，表述優雅，卻沒有人進行過試驗。

README 反倒提供了一個名為「如何得知它正在奏效」的章節，其中列出你可能觀察到的四件事：diff 中較少出現不必要的變更、因過度複雜化而導致的重寫較少、釐清性問題在實作前而非犯錯後才出現，以及乾淨精簡的拉取請求。這些都是合理的訊號。但它們也正好是你什麼都沒量測時會寫出來的東西，而且是由套用這份檔案的人自我回報。請把它們當成在自己的儲存庫裡檢驗這份檔案是否達標的清單，而不是它已經通過的證據。

你實際輸入來安裝它的內容

README 提供兩種路徑。建議的路徑是在 Claude Code 內執行：先新增外掛市集，再安裝外掛，之後指引就會存在於各專案中，而不是只限於單一儲存庫。第二種是按專案處理：將原始的 CLAUDE.md 抓取到新的儲存庫，或附加到現有的儲存庫。另外還有一個已提交的 Cursor 專案規則，因此在 Cursor 中開啟該資料夾時，也會套用相同的指引——這個細節說明該檔案是為了能跨工具攜帶而撰寫，適用於會讀取專案層級指令檔的工具，而非綁定於單一廠商的載入器。

有一個不夠順暢的地方，值得提出來，因為如果你完全照著 README 操作就會遇到。市集指令中的名稱是 forrestchang/andrej-karpathy-skills，而頁面最上方的儲存庫 URL 則是 multica-ai/andrej-karpathy-skills。這兩個字串都出現在同一份 README 中（閱讀日期為 2026 年 10 月 23 日）。我看得出這個不一致，但無法告訴你為何會存在，所以誠實的建議是：如果其中一個路徑失敗，就試另一個；並把這兩個字串之一視為過時。

首頁上另一件值得注意的事：這個儲存庫是由 multica-ai 維護的，而 README 開頭的區塊引言宣傳了 Multica，也就是「一個用於執行與管理編碼代理、並具備可重複使用技能的開源平台」。這是一項合理的揭露，同時也提供了線索，說明為什麼它的包裝方式看起來是這樣。一個對可重複使用技能感興趣的專案，很可能會把自己的指引以可安裝的形式釋出，而這個外掛正是如此。

使用它，但不繼承它的預設假設

「自訂」區段是大多數讀者會跳過的部分。這個檔案的設計是要與專案特定的指示合併使用，而不是取代它們；它提供的例子很具體：使用 TypeScript 嚴格模式、所有 API 端點都必須有測試、遵循特定檔案中既有的錯誤處理模式。這不是裝飾。這正是通用規則手冊與一套知道你程式碼位於何處的指示集之間的差別。

合併而非疊加有其實際理由。若你把檔案原樣貼進去，而你的專案又有自己的慣例，兩套指示就可能互相牴觸；而模型在調解這種牴觸時，正是第一原則想消除的那種混亂。把你的慣例以同樣的語氣寫進同一個檔案，能讓指示表面小到足以稽核。

而你確實應該審核它。這是一份簡短的行為指示文件，將適用於該儲存庫中的每一個請求。正確的問題不是 222,612 個人是否可能全都錯了——那種問法解決不了任何事——而是每一條規則是否對應到你確實見過的失敗情況。如果你的 diff 從來沒有包含順手改寫的註解，那麼〈精準式修改〉這一節就只是白白耗費你的上下文。把它刪掉。這個檔案採用 MIT 授權，本來就是要讓人編輯的。

再往下一層來看，這些都不會改變由哪個模型來回答。CLAUDE.md 檔案影響的是請求送達模型之後如何被處理；它對接收請求的模型本身則隻字未提。第二個決定取決於位在模型前方的任何東西。其中一種安排方式，是用單一 OpenAI 相容端點，以同一把金鑰承載超過 200 個模型，並在各供應商之間自動容錯切換，且供應商列表價格以 0% 加價原樣傳遞。我們託管模型；我們不製作 Claude Code，而你的儲存庫中的任何內容都不會對我們可見。

搜尋結果會一直說「skills」，因為那是人們用來稱呼某種東西的詞——你安裝它，就能讓 agent 表現得不一樣；而這個儲存庫的包裝也用了這個詞。這件成品是一個檔案：一份常設指示文件，針對三個具體抱怨而寫，包含四項原則，以及一組你可以手動套用的測試。判斷它的標準，是那些抱怨聽起來是否像你的儲存庫。這比星數是更好的問題；星數向來只衡量有多少人剛剛跟你有一樣的反應。