44 行字。2.3 KB。GitHub 全球第 24 名。
一句話結論：Karpathy CLAUDE.md（andrej-karpathy-skills）是一個 2.3 KB 的行為守則檔，超過 20 萬顆星、全球第 24，內容確實值得抄進你的專案——但 Karpathy 本人沒有參與，而它的星數不能當成「被驗證有效」的證據。
它的星數比 TensorFlow 多，比 VS Code 多。整個專案的核心產出，是一個叫 CLAUDE.md 的純文字檔——GitHub 標示 65 行，其中 44 行是實際內容。
而檔案名字上掛的那個人，一個字都沒寫過。
這篇把三件事查清楚：它到底寫了什麼、那顆星到底代表什麼、哪幾條你今天就該抄走。（查證日期：2026-08-26）
這個專案到底是什麼？
它是一個給 AI 寫程式用的「行為守則」檔。你把 CLAUDE.md 放進專案根目錄，Claude Code 動手前先讀它，然後照規矩做事——先問清楚再寫、能簡單就不要複雜、只改該改的行、先定義「怎樣算成功」再開工。
整個 repo 只有 5 個檔案在根目錄：CLAUDE.md（主檔）、CURSOR.md、EXAMPLES.md、README.md、README.zh.md。另外三個資料夾放 Claude Code plugin 設定、Cursor 規則、skill 版本。沒有程式碼，沒有測試，沒有相依套件。
時間線很緊湊。Karpathy 在 2026 年 1 月 26 日發了一則長推，講他把工作流換成「八成 agent」之後遇到的問題。隔天，1 月 27 日，這個 repo 建立。
不到一天。從一則推文，到一個排進全球前 25 名的專案。
44 行字憑什麼排到全球第 24？
先講數字，而數字本身就有故事。截至 2026 年 8 月 26 日，三個介面給的星數並不一致：GitHub 專案頁約 207.5k、star-history 206.8k、官方 API 回報 205,731，落在 205.7k–207.5k 之間，差距約 0.9%（star-history 是吃 GitHub API 的下游鏡像，不算獨立量度）。所以這篇只講三邊都同意的量級：超過 20 萬顆星，全球第 24。
放進排行榜看：
| 全球排名 | 專案 | 是什麼 |
|---|---|---|
| #16 | torvalds/linux | Linux 核心 |
| #22 | vuejs/vue | 前端框架 |
| #24 | andrej-karpathy-skills | 一個 2.3 KB 的文字檔 |
| #25 | n8n-io/n8n | 自動化平台 |
| #27 | tensorflow/tensorflow | 機器學習框架 |
| #32 | microsoft/vscode | 編輯器 |
| #33 | ohmyzsh/ohmyzsh | Shell 設定框架 |
TensorFlow 花了十年、幾千個貢獻者、幾百萬行程式碼。這個檔案花了一天、7 個貢獻者、44 行字。
不是說它不配。是說星數跟工程投入不是同一個量綱。
Karpathy 到底有沒有參與？
沒有。而且 repo 自己講得清楚。
README 的說明句寫的是「derived from Andrej Karpathy’s observations」，附上原推文連結。這是規矩的引用，不是冒名。問題在於專案名字叫 andrej-karpathy-skills，而大部分人只看名字，不會滑到說明句。
實際擁有者是 multica-ai，作者是 @jiayuan_jy。README 最頂端第一段不是講這個專案，是推銷作者自己的另一個產品 Multica（管理 coding agent 的開源平台）。
掛大神的名字、放免費的好東西、頂端擺自己的產品連結——很有效的分發策略，而且完全合法。你要知道這件事正在發生，不是要因此不用它。
Karpathy 沒有公開背書過。那 20 萬顆星證明的是「很多人覺得這概念值得收藏」，不是「Karpathy 認可這份實作」。
四大原則實際寫了什麼？
四條，短到可以背起來：
| 原則 | 核心一句話 | 最有用的具體規定 |
|---|---|---|
| 1. Think Before Coding （動手前先想） | 不要假設、不要藏起你的困惑、把取捨攤出來 | 「如果有多種解讀，全部列出來——不要默默挑一個」 |
| 2. Simplicity First （先求簡單） | 能解決問題的最少程式碼，不要預先設計 | 「寫了 200 行但其實 50 行做得到，就重寫」 |
| 3. Surgical Changes （外科式修改） | 只碰你必須碰的，只清你自己弄出來的爛攤子 | 「看到不相干的死程式碼，講一聲就好——不要刪」 |
| 4. Goal-Driven Execution （目標驅動） | 先定義成功條件，然後迴圈到驗證通過 | 「修 bug」改成「先寫一個能重現它的測試，再讓它通過」 |
CLAUDE.md 原文，2026-08-26 讀取。第三條我最有感。AI 幫你修一個空字串的 bug，順手統一了引號風格、加了型別註記、補了 docstring，還「順便」加強旁邊的驗證邏輯。diff 從 3 行變 40 行，你要花二十分鐘確認那 37 行沒弄壞別的東西。
EXAMPLES.md 對這條有一組精準對照：同樣是「修正空 email 會讓驗證器崩潰」，錯誤示範多做了四件事——加強本來沒壞的 email 驗證、補上沒人要求的 username 驗證、改寫註解、加 docstring。正確示範只動處理空 email 的那兩個判斷式。
為什麼第四條原則跟前三條不一樣？
因為它不是在修 bug，是在拿槓桿——讀原文才發現的結構。
README 的「The Problems」段落，引用了 Karpathy 原推文的三段抱怨：模型亂假設又不查證、愛把程式碼和 API 搞複雜、會去動它沒看懂的註解和程式碼。三段，不是四段。
但解法有四條。對不上。
去看 README 自己那張對照表就懂了。前三條原則的「Addresses」欄位填的都是缺陷——錯誤假設、過度複雜、越界修改。第四條 Goal-Driven Execution 填的是「Leverage through tests-first」，槓桿，不是缺陷。它來自 Karpathy 另一段完全不同的話：
「LLM 極度擅長迴圈直到達成特定目標……不要告訴它做什麼，給它成功條件，然後看它跑。」
Karpathy 原推文，README「Key Insight」段引用
所以它的真實結構是「三道防護欄 + 一個油門」，不是轉述文章常寫的「四大毛病對應四大解法」。
這分別有實際後果。前三條可以無腦全抄，它們只會讓 AI 更保守。第四條不一樣——它要你把「加個驗證」翻成「先寫失敗的測試再讓它通過」，前提是專案本來就有能跑的測試。沒有測試基礎就抄第四條，只會換來一堆 AI 自己編的、看起來很像成功條件的空話。
安裝指令指向的帳號，已經不是現在的擁有者了
README 的安裝段落有三處指向 forrestchang/andrej-karpathy-skills——那是原作者 Forrest Chang 的帳號。但 repo 現在掛在 multica-ai 名下。
看起來像壞掉了。所以我實測了一次。
結果是：能用。raw.githubusercontent.com/forrestchang/... 回傳完整檔案，內容跟 multica-ai 現在的版本一字不差；網頁版網址直接轉址過去。這是 GitHub 轉移擁有權後的標準重導向行為。
指令沒壞。但發生的事比壞掉更值得留意：你打的是 A 的名字，拿到的是 B 現在放在那裡的東西，而且過程完全沒有提示。
今天兩邊內容一模一樣，沒問題。但 curl ... >> CLAUDE.md 抓的永遠是那個帳號當下的 main 分支——你信任的是 Forrest Chang 這個名字，實際執行的是 multica-ai 當下的決定。這不是陰謀論，是供應鏈的基本算術。解法：先看內容再貼，不要直接 append。
怎麼裝？三步驟
最安全的裝法不是照 README 的 curl，而是先看後貼：
- 先讀原始檔：打開 repo 的
CLAUDE.md，65 行，兩分鐘看完。這是你要塞進每次 AI 對話的東西。 - 挑你要的條目：不需要四條全收，用下面的產生器勾選。
- 貼進專案根目錄：已有
CLAUDE.md就接在後面，加一行標明來源和日期。
哪幾條最值得抄進你的 CLAUDE.md？
勾選你要的原則，下面會產生可直接複製的內容。MIT 授權，抄走合法。
andrej-karpathy-skills 的 CLAUDE.md（MIT），2026-08-26 讀取。這是行為約束，不是效能保證——沒有公開 benchmark 證明它一定讓 AI 寫得更好。這個專案有什麼問題？
三個，按嚴重程度排：
一、沒有任何效果證據。整個 repo 找不到一個 benchmark、一組 A/B 測試、一份實測數據。README 的「How to Know It’s Working」段落給的是四個主觀感受，全部要你自己觀察，沒有數字。相比之下，同樣是約束 AI 行為的 ponytail 至少給了「12 個任務、程式碼行數減 54%」這種可以被檢驗、也可以被打臉的數字。
二、100 個未處理的 pull request。一個只有 5 個檔案、28 次 commit 的 repo，累積了 100 個開著的 PR。20 萬人按星，7 個人是貢獻者。這比例說明它更像「被收藏的想法」，而非「被維護的專案」。
三、四條規則會讓 AI 變慢。README 有誠實標註這個取捨：偏向謹慎而非速度。你叫它改個錯字，它可能先問你三個澄清問題。瑣碎任務要自己判斷該不該關掉。
那顆星，到底在量什麼？
查證時撞到一件我解釋不了、但值得寫出來的事：同一專案、同一天，兩個計數器給了互相矛盾的成長速度。
| 來源 | 讀數 | 時間戳 |
|---|---|---|
| GitHub Trending 快照 | 當日 +830 顆星 | 2026-08-26 08:08 HKT |
| star-history.com | 當週 +23 顆星、0 次 push | 2026-08-26 查詢 |
差距接近 40 倍。而且 star-history 自己的紀錄顯示，這專案 8 月 24 日排上 GitHub Trending 全語言第 4——當週只新增 23 顆星，很難同時排到當日第 4。所以至少有一個讀數是錯的，只是它不會告訴你是哪個。
我沒辦法用公開資料判定誰對。所以這篇沒有用任何一個速度數字下結論，只用了三個來源都同意的存量：超過 20 萬顆星。
星數量的是「有多少人滑過這一頁時覺得值得存起來」，不是「有多少人真的在用」，更不是「這東西有沒有效」。
所以：不要因為 20 萬顆星就照抄，也不要因為作者不是 Karpathy 就不看。打開那 65 行讀完再決定，兩分鐘而已。
還有什麼替代方案？
| 方案 | 做法 | 有沒有數據 | 適合誰 |
|---|---|---|---|
| andrej-karpathy-skills | 4 條行為原則，2.3 KB | 無 | 想要兩分鐘讀完、馬上上手的通用守則 |
| ponytail | 6 級決策階梯，逼 AI 先找現成方案 | 有（自報 −54% 行數） | 受夠 AI 重造輪子的人 |
| 自己寫 | 記錄你的 AI 實際犯過的錯，逐條變成規則 | 你自己的 | 已用 AI 寫程式一陣子、知道痛點在哪的人 |
長期來看第三個最有價值。前兩個的作用，是讓你不用從空白檔案開始。
新手今天可以做的三件事
- 打開那 65 行讀一次。不裝也無妨，光是知道「AI 會亂改旁邊的程式碼」，你 review diff 時就會多看兩眼。
- 先抄第 3 條（外科式修改）。四條裡投報率最高，而且零前置條件。
- 開一個檔案記錄 AI 犯的錯。每次它做了讓你翻白眼的事就寫一行。一個月後，那份檔案會比任何通用守則都適合你。
常見問題
Karpathy CLAUDE.md 是 Karpathy 本人寫的嗎？
不是。repo 說明寫的是「衍生自 Karpathy 的觀察」，原作者是 Forrest Chang，現在由 multica-ai 帳號維護。Karpathy 沒有公開背書過這個專案，他只是在 2026 年 1 月 26 日發過一則講 LLM 寫程式問題的推文。
四條原則要全部抄嗎？
不用。前三條沒有前置條件，可以直接抄。第四條「目標驅動執行」要求專案已有能執行的測試，否則抄了也只是讓 AI 編出看起來像成功條件的空話。
它只能用在 Claude Code 嗎？
不是。repo 同時提供 Cursor 版本（.cursor/rules/karpathy-guidelines.mdc）。內容是純文字規則，貼進任何吃系統提示的 AI 編碼工具都能用。
20 萬顆星代表它真的有效嗎？
不代表。整個 repo 沒有任何 benchmark 或實測數據，README 提供的驗證方式是四個主觀感受。星數反映的是概念受歡迎程度和名人效應，不是效果驗證。
README 的安裝指令指向舊帳號，還能用嗎？
能用。forrestchang 那組網址會被 GitHub 自動重導向到 multica-ai，實測回傳內容一字不差。但你抓到的是新擁有者當下放的版本，建議先看內容再貼，不要直接 curl append。
本文查證日期 2026-08-26，GitHub 星數、排名與專案內容以當日讀取為準，日後可能變動。文中數字皆標註來源與時間戳；星數成長速度因來源互相矛盾，已於文中說明並未採用。本文不構成投資或採購建議。
發表迴響