225,000 顆星只為一份 markdown：Karpathy 的抱怨變成四條規則

一個只裝著一份 markdown 檔案的儲存庫，拿到了 225,000 顆 star。這週它又多了大約 4,000 顆。裡面沒有程式碼，沒有建置流程，沒有發布，沒有基準測試表格——只有四條原則，以及一組關於「當語言模型被要求改動一個程式碼庫時該怎麼表現」的說明。

這個檔案叫 CLAUDE.md，所在的儲存庫叫 andrej-karpathy-skills，維護者是 forrestchang。它把 Andrej Karpathy 對 LLM 寫程式行為的一連串抱怨，壓縮成 agent 在每次工作階段開頭真的會讀進去的東西。有意思的數據點是 star 數，而不是內容——因為它說明了一件事：眼下 agent 的行為正以非官方的方式被修補，用散文，由個人完成。

Karpathy 的原話：那些抱怨

這個儲存庫建立在原帖之上，其中三段引文：

「模型會替你做出錯誤的假設，然後沿著假設一路跑下去，不做任何核對。它們不管理自己的困惑，不主動求澄清，不指出前後矛盾，不擺出取捨，該反駁的時候也不反駁。」

「它們特別喜歡把程式碼和 API 搞複雜，堆砌抽象化，也不清理無用程式碼……本來 100 行能搞定的事，非要寫一千多行的臃腫構造。」

「它們有時還會順手改動或刪掉自己理解得並不充分的註解和程式碼，哪怕這些跟任務毫無關係。」

凡是交付過 agent 寫的程式碼的人，這三條都認得。第二條最常見：你要一個驗證函式，收到的是一個抽象基底類別、一個策略模式、一個設定物件，外加四十行針對不可能發生的狀態寫的錯誤處理。

四條原則到底說了什麼

先想再寫。把假設明確說出來，把多種解讀擺出來而不是默默挑一個，存在更簡單的做法時要反駁，困惑時就停下，並指出不清楚的地方是什麼。

簡單優先。用最少的程式碼解決問題。不加需求之外的功能，不為一次性程式碼做抽象化，不做沒人要求的可設定性，不為不可能發生的情境寫錯誤處理。檢驗標準：一個資深工程師會不會說這寫複雜了？

外科手術式改動。只碰你必須碰的。不要順手優化旁邊的程式碼，不要重新格式化你只是路過的部分。即便你會換個寫法，也要貼合現有風格。看到無關的無用程式碼，提一句就好——不要刪。你的改動產生了孤兒程式碼時，只清理這些。檢驗標準：每一行改動都能追溯到需求。

目標驅動執行。把祈使句式的指令轉成可驗證的成功標準。不是「加個驗證」，而是「為非法輸入寫測試，然後讓它們通過」。不是「修這個 bug」，而是「寫一個能重現它的測試，然後讓它通過」。

最後一條是四條裡唯一不是約束的原則。它是槓桿，而且配著原始材料裡最好的一句話：LLM 極其擅長朝著明確目標反覆循環，直到達成。別告訴它該做什麼；給它成功標準，看它跑。

安裝，以及它只有兩行這件事

兩條路徑，都很簡單。

/plugin marketplace add forrestchang/andrej-karpathy-skills
/plugin install andrej-karpathy-skills@karpathy-skills

或者，按專案來：

curl -o CLAUDE.md https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md

儲存庫裡還提交了一份 Cursor 規則 .cursor/rules/karpathy-guidelines.mdc，所以在 Cursor 裡開啟專案時，同樣的準則依然生效。MIT 授權。

散布方式才是重點。兩年前，要修「模型過度工程」，意味著一次微調、一份廠商下發的 system prompt，或者一個框架。現在它是一個被使用者丟進儲存庫的檔案，加一條 marketplace 清單——後者能讓它進入這台機器上的每一個專案。抱怨和修復之間的回饋迴路因此短得多，star 數之所以是現在這個數，原因就在這裡：這個檔案是行為改變成本最低的單位。

為什麼我對這套敘事仍然存疑

三點保留意見，按這個檔案自己的精神提出。

原則不是測試。「簡單優先」是一種偏好，不是一個判準。讀到它的 agent 照樣會在 80 行能解決的地方交出 300 行，因為模型沒有辦法度量複雜度。檔案裡唯一真正起作用的原則——目標驅動執行——之所以起作用，恰恰是因為它把偏好換成了檢查：一個測試，要嘛過，要嘛不過。

「外科手術式改動」對抗的正是 agent 的強項。如果你讓模型做個小改動，它就做個小改動，那你等於用一件昂貴的工具去省幾次敲鍵。agent 的價值在於它能重構你本來不想碰的東西。檔案的答案是：重構應該被要求，而不是主動奉上——這說得通，但它意味著這套準則在為一類特定使用者做優化：手上有現成程式碼庫、對 diff 有強烈主張的人。

沒有人測量它是否有效。儲存庫列出了訊號：diff 裡不必要的改動變少、重寫變少、在實作之前而不是之後才提澄清問題。這些都是真實可觀察的。但沒有對照組。你裝了一個寫著「先問再假設」的檔案，然後 agent 開始先問再假設。是檔案導致的，還是把它寫下來這個動作，讓你注意到本來就存在的行為？

作者對取捨是坦白的，這點值得肯定：這套準則偏向謹慎而非速度，面對瑣碎任務你應該自己判斷。這個提醒是對的，而它同時也是張力所在。一個為了一行錯字修正就要停下來發問的 agent，比一個直接改掉的 agent 更差。

如果讓我來寫，我會寫成這個版本

如果這個檔案的弱點是四條原則裡有三條只是偏好，那修法就是把它們轉成檢查。具體來說，四行能扛住真實儲存庫檢驗的規則：

動手之前，列出你打算碰的檔案；如果這份清單比需求所暗示的更長，就停下。這把「外科手術式改動」從一種心情變成了一道關卡。

結束之前，跑測試並把輸出貼出來。這是把「目標驅動執行」變成不可協商的，也是你能擺在 agent 面前的、槓桿最高的一條指令。

如果一個任務存在不止一種合理解讀，把兩種都寫出來，然後問是哪一種。這把「先想再寫」從一種願望變成對話裡的一個回合。

再加一個 diff 預算：如果一次 bug 修復的改動超過大約 150 行，就停下，逐個說明每個抽象化的理由。粗暴，但它能抓住 Karpathy 描述的那種失敗模式——那才是真正耗時間的那一種。

這些都不在檔案裡，也不需要。檔案的任務是設定一種姿態。檢查是儲存庫主人的任務。

star 數真正在說什麼

今年發布的 agent 工具，大多是在講能力：更長的上下文、更多工具、平行執行。這個檔案講的是克制，而它得到的關注超過了大多數能力發布。

這個落差很有資訊量。為這些工具付錢的人已經得出結論：瓶頸不再是模型能做什麼，而是讓它停下那些沒人要求它做的事。一個 225,000 星的 markdown 檔案，是相當清晰的訊號，告訴你挫折感究竟在哪裡。

對各家實驗室來說，這也是一個略顯尷尬的訊號。這個類別裡 star 最多的儲存庫，是一份「模型本來就應該做到的四件事」的清單。