Karpathy 4 句吐槽，做出 GitHub 史上最熱 65 行 markdown：兩週 9 萬 stars，超越所有 Agent Framework

兩週前，這個 GitHub repo 還是 0 stars。

今天它有 91,000 stars。

它不是 framework，不是 agent，不是模型。內容只有一個檔案，65 行 markdown。

而且作者不是哪家大廠。是一個叫 Forrest Chang 的個人開發者，他做的事情很簡單：把前 OpenAI 聯合創始人 Andrej Karpathy 在 X 上的一條吐槽推文，整理成一份 Claude Code 的系統提示。

就這樣。

結果它衝上了 GitHub trending 第一，把 LangChain、AutoGen、CrewAI 這些動輒幾萬行代碼的 framework 都擠下去。8.7K 個 fork。44 個還沒合併的 PR 在排隊。

我看到這個數字的第一反應是不可置信。第二反應是去把它裝起來用。第三反應是寫這篇文章。

Karpathy 看到的 4 個 LLM 寫代碼的坑

故事得從 2026 年 1 月 26 日 Karpathy 的一條 X 推文講起。他從 80% 自己手寫代碼切到 80% 給 agent 寫代碼之後，列出了 LLM 在寫代碼時最常犯的幾個錯。原話翻譯如下：

「模型會替你做出錯誤的假設，然後悶著頭一路跑下去，從不檢查。它們不管理自己的困惑，不主動釐清，不揭示矛盾，不呈現權衡，該頂回去的時候也不頂。」

「它們真的很愛把代碼和 API 搞得過度複雜、把抽象寫到肥大、不清死代碼、用 1000 行寫一個 100 行就夠的東西。」

「它們有時候會把它沒搞懂的代碼或注釋當成副作用順手改掉，即使那跟你交辦的任務根本沒關係。」

讀過幾條 AI 寫的 PR 的人應該都很有共鳴。這四個坑可以歸納成：

• 沉默假設不驗證：你的 prompt 模糊兩可，AI 自己選一個解讀，悶聲幹活。
• 抽象肥大：你叫它寫一個小函式，它順手蓋了一座大教堂。
• 附帶修改：你叫它改 A，它順便把 B 也改了，理由是「我覺得這樣比較整齊」。
• 沒有可驗證的成功標準：你說「修一下這個 bug」，它說「修好了」，你不知道對不對。

解法只有 4 個原則，不到 65 行

Forrest Chang 把這 4 個坑各對應一個原則，寫進一個叫 CLAUDE.md 的檔案。Claude Code 跑任何任務之前會先讀這個檔案，等於是給它戴了一頂「克制專業」的帽子再開工。

原則 1：先想清楚再動手（Think Before Coding）

說明白你的假設。如果有多種解讀，全部攤出來，不准悶聲選一個。如果你覺得使用者的方法是錯的，要敢頂回去。如果搞不清楚，停下來問。

這個原則的關鍵詞是「explicit」。AI 寫代碼最常見的災難都是從一個沒講清楚的假設開始的。

原則 2：先求簡單（Simplicity First）

用最少的代碼解決問題。不要寫沒人要求的功能。不要為了「未來可能要用」的彈性開後門。不要為了「不可能發生」的場景寫錯誤處理。如果 200 行可以寫成 50 行，就重寫。

檢驗標準是：「資深工程師看到會不會說這寫得太複雜？」會的話就重寫。

原則 3：外科手術式修改（Surgical Changes）

只動該動的地方。順手「改善」相鄰代碼的習慣戒掉。看不順眼的舊風格也不准改。發現了無關的死代碼，提醒一下就好，不准刪。

檢驗標準是：「每一行被改的代碼，能不能直接對應到使用者的請求？」不行的話就回退。

原則 4：用目標驅動執行（Goal-Driven Execution）

定義成功標準。loop 到驗證通過為止。把命令式的指令翻譯成可驗證的目標：

Karpathy 自己的原話最到位：「LLM 超會 loop 到符合特定目標為止。不要告訴它要做什麼，給它成功標準，然後看它跑。」

30 秒就能裝

裝法有兩種，看你習慣哪種：

方法 A：Claude Code 的 plugin（最推薦）

在 Claude Code 裡先加 marketplace：

/plugin marketplace add forrestchang/andrej-karpathy-skills

然後安裝：

/plugin install andrej-karpathy-skills@karpathy-skills

裝完所有專案都吃這個規則，不用每次重設。

方法 B：直接拉一個 CLAUDE.md（單專案）

新專案的話，一行 curl：

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

已有 CLAUDE.md 的專案，把內容附加到後面：

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

用 Cursor 也適用。Repo 裡帶了一個 .cursor/rules/karpathy-guidelines.mdc，把整個資料夾打開就生效。

跟其他 AI 工具配置怎麼比

把這個 65 行檔案拿來跟 LangChain 比，當然不公平——一個是「給單一 agent 戴帽子」，一個是「蓋一座 agent 工廠」。

但這個 repo 衝上 trending 第一，本身就傳遞了一個訊息：很多時候大家要的不是更多功能，而是 少做一點蠢事。

實測：用了之後 diff 真的乾淨多了

我在自己的兩個專案上分別開了一份新 CLAUDE.md，跑了三天。記下三個最有感的變化：

1. 它開始問問題。以前我說「加一個 logout 按鈕」，它就直接給我寫一個。現在它會先問「你的 logout 是要清 localStorage 還是要打 API？兩個都做？」。一開始覺得很煩，習慣之後就回不去了。
2. diff 變窄了。原本 1 行修改的任務，AI 會順便重排我隔壁 5 個函式的 import 順序。現在它只動該動的，其他通通不准摸。code review 時間直接砍半。
3. 它會寫測試先。問它「修這個 bug」，它先寫一個能重現 bug 的測試。bug 修完之後測試自動變成迴歸測試。這個習慣比工具本身還值得抄。

缺點也有：簡單任務變慢。改個錯字、改個變數名，它也要先想三秒鐘確認你的意圖。Repo 作者自己也提醒過：「這套規則偏向謹慎而不是速度。明顯的小修改用判斷力就好，不必每次都搬出全套儀式。」

不寫代碼的人也能拿走的 4 個觀念

看到這裡有些讀者可能會說：「我不寫代碼啊，這跟我有什麼關係？」

關係很大。把這 4 個原則翻譯成日常用 ChatGPT、Claude、Gemini 的場景，每一條都還是站得住：

• 原則 1（先講清楚再動手）：給 prompt 的時候，先問 AI 它有沒有什麼地方需要釐清。比如要它寫一封信，先問它「這封信我希望語氣比較強硬還是比較柔軟？需要附證據還是純表態？」AI 自己會列出選項給你選，比它直接寫一封錯方向的信好得多。
• 原則 2（先求簡單）：要 AI 給建議的時候，加一句「給我最簡單可行的方案，不要過度設計」。你會驚訝它原本能多誇張地把一個三行就能搞定的問題寫成五頁 PPT。
• 原則 3（外科手術式修改）：給 AI 改文件、改文案的時候，明確說「只改 X 段，其他不准動」。AI 對「順手優化」的衝動跟工程師一樣強。
• 原則 4（目標驅動）：給任務的時候，加一句「成功的標準是什麼？你會怎麼驗證？」AI 會先列出檢核清單再開工，最後也會回頭對清單。

這 4 條看起來很基礎，但它們有效是因為它們直接對準了 LLM 訓練的副作用：愛猜、愛膨脹、愛多動、愛敷衍。

結論：這場勝利不是 framework 的，是「克制」的

過去兩年 AI 工具圈的主旋律是「加一層」。再加一層 RAG，再加一層 agent，再加一層 multi-agent 編排。每一層都號稱讓你變更強。

結果今年 GitHub 上最熱的不是這些「加一層」的方案，是一個叫你「少做一點」的 65 行檔案。

我覺得這件事對所有用 AI 的人都是個訊號。下次你開新專案前，先花 30 秒裝這個檔案。再下一次你跟 AI 對話前，自己默念一次那 4 條。

你會發現，AI 從來沒問題，問題是你沒給它一個夠克制的框框。

延伸資源

• 原始 repo：github.com/forrestchang/andrej-karpathy-skills
• Karpathy 的原推：x.com/karpathy/status/2015883857489522876
• Forrest Chang 的 X：x.com/jiayuan_jy

本文於 2026 年 5 月 9 日更新。GitHub stars 數據引自 repo 公開頁面，AI 工具更新極快，建議在使用前查看最新文件。本文不構成投資建議。