Karpathy 65 行文檔狂砍 17.6 萬星，阻止 Coding 犯大錯只需這四點

在 Github 上把 Anthropic 官方文檔甩在身後，怪不得 Dario 要把他招回去。 作者丨樊天驕、鄭佳美 編輯丨鄭佳美 一份只有 65 行的 Markdown 文件，剛剛成為 GitHub 歷史上最被討論的 AI 工程實踐——而它沒有寫一行可執行代碼。這就是 2026 年 4 月開始刷屏的 andrej-karpathy-skills 項目：累計 17.6 萬顆星，單文件、零邏輯，卻在同一個月裡把 Anthropic 官方的 anthropics/skills 倉庫（15.1 萬星）甩在身後。兩件事疊在一起看，AI 編程的競爭焦點正在發生一次清晰的位移——從"模型能不能寫"，轉向"模型在沒人盯著時，能不能不寫錯"。01想讓 AI 更聰明，就要約束它的行為Karpathy 那條原話被開發者社區反覆傳閱：模型會代你做錯誤假設，然後不假思索地執行；它們喜歡把代碼和 API 搞複雜，堆抽象，不清理死代碼；它們有時會改動或刪除自己理解不足的代碼和註釋，即使這些內容與任務無關。雷峰網這段吐槽戳中了 LLM 編碼代理最普遍、卻最少被正面討論的失敗模式——不是"不會寫"，而是"亂寫"。已經使用過 CLAUDE.md 的開發者們表示：裝上這份規則後，AI 編碼任務通過率從 65% 提升到 94%。這個數字沒有權威基準背書，但之所以能流傳，是因為它對應的是開發者每天都在經歷的真實落差。把"65% → 94%"的邏輯拆開看，本質上是三類系統性錯誤被顯式壓制了。第一類是誤解需求。AI 編程代理最常見的失敗不是不會寫代碼，而是"自行補全模糊需求"。模型收到"修一下登錄邏輯"這類指令時，會默認一系列產品假設——前端怎麼傳參、用戶態怎麼校驗、錯誤如何降級——然後把這些假設當成既定事實去實現。因此，CLAUDE.md 第一條原則要求"遇到歧義必須先問、先呈現權衡"，硬切斷了這種傾向。模型從"先動手再猜"變成"先彙報再請求授權"。雷峰網第二類是過度工程化。LLM 訓練數據中高質量代碼的密度極高，模型生成時傾向於堆疊抽象層、分層設計、泛化模式——本來 100 行能搞定的事情，往往被擴成 1000 行的臃腫架構。對此，Karpathy 自己的吐槽是"100 行能搞定的非要寫 1000 行"。而 "簡潔優先"原則把"50 行能寫完，絕不寫 200 行"寫進規則，等於給模型的"完美主義衝動"裝了一個剎車。第三類是修改擴散。沒有邊界約束時，AI 容易順手 reformat 相鄰代碼、改動理解不足的模塊、引入隱性副作用。Karpathy 稱之為"作為副作用修改或刪除了與任務無關的代碼和註釋"。"外科手術式修改"原則要求"每一行改動都能追溯到原始需求"，本質上是降低編輯自由度——一個能寫出 1000 行代碼的模型，被規則強制只能寫 50 行，效果反而更好。這三條之外，文件裡還有第四條原則：目標驅動執行。它要求 AI 在寫代碼前先把"修復 Bug"翻譯成"先寫一個能復現 Bug 的測試，再讓測試通過"——即把模糊的命令轉換成可驗證的成功標準。LLM 圍繞明確目標的循環能力極強，但前提是要給它清晰的成功判定。而這份規則讓 AI 不再"我說我改好了"，而是"測試證明我已經改好了"。把四條原則合在一起看，文件解決的不是"AI 寫不好代碼"的問題，而是"AI 太容易自作主張"的問題。它的設計目標不是讓模型更聰明，而是讓模型在每個關鍵節點停下來確認、剋制、剋制、再剋制。同時 CLAUDE.md 也讓 AI 編程的"行為約束"第一次有了一個低成本、可分發、可審計的載體——一個普通開發者用 curl 命令兩分鐘就能裝上，但所有 AI 代理都會照著執行。因此，CLAUDE.md 登上 GitHub 榜首的真正原因，不在 prompt 寫得多漂亮，而在於它把AI 編程的不確定性從"模型能力"問題，轉化成了"工程設計"問題——而後者，是開發者可以親手解決的。02為什麼是 65 行，而不是 200 行CLAUDE.md 的風潮很快席捲了 GitHub，衍生出一批同方向的探索項目。其中開發者 VoidLight00 的思路值得專門拿出來：一個能讓 AI 自動優化 AI 規則的系統。他的實現路徑帶著鮮明的工程思維：先在 eval.json 中定義一套斷言測試集，用來量化評估規則文件的實際效果；再讓系統進入"修改規則 — 重跑測評"的循環，如果本輪評分有提升就保留變更，沒有增益就回滾到上一版本。整套流程相當於把原本靠人工反覆打磨的提示詞優化工作，轉化成了類似代碼自動化測試的標準化流程。更有意思的是一組對照實驗：有開發者試著把 Karpathy 這份規則擴充到 200 行，結果 AI 生成的代碼質量非但沒提升，反而出現了下滑。背後的邏輯並不複雜。當規則文件越寫越長，真正關鍵的約束會淹沒在冗餘的描述裡。大模型固然能處理長上下文，但不代表它能在每一次生成中穩定識別並貫徹所有細則。規則文件的有效性，取決於模型在還沒忘之前讀到核心約束的概率。這也解釋了為什麼 Karpathy 那份文件從一開始就走極簡路線——四條原則、幾十行、沒有任何具體技術棧要求。它把工程紀律壓縮到了 AI 最容易穩定執行的篇幅裡。當 65 行就能解決核心問題，200 行的邊際收益大概率是負的。工程意義上的"短而精"，在 AI 編程時代有了新的具體含義：它不是文字上的剋制，而是與模型注意力機制的精確對齊。規則寫在模型能穩定看見的位置，寫在它願意照做的篇幅裡，寫在它最不容易讀到一半就走神的長度內。03AI 編程下半場：稀缺的不是模型，是約束設計把這件事放回 LLM 工程化的整體脈絡看，它指向了一個更清晰的分層。第一層是 Prompt Engineering。關注點在"讓模型聽懂指令"。這一層在過去兩年裡被研究得最透，天花板也最明顯——提示詞寫得再精妙，模型行為的不穩定性依然存在，因為提示詞是"軟"的，模型可以選擇不聽。第二層是 Workflow Engineering。關注點在"讓模型按步驟做事"。把任務拆成多步、引入 ReAct、引入反思機制，讓模型有能力處理長鏈任務。這一層顯著提升了單任務成功率，但仍然無法約束"模型在某個步驟上的越界行為"——工作流規定了"先做什麼後做什麼"，卻沒有規定"什麼不能做"。第三層是 Agent Governance。關注點在"讓模型只能在邊界內做事"。這一層的設計對象不是"任務"，而是"模型本身的行為約束系統"——包括規則文件、沙箱、審批、審計、迴歸測試。這些文件本質上是"投影"——它們從同一個規則源編譯出來，分發給不同的 AI 代理。比如 AGENTS.md 寫給機器，README.md 寫給人，二者刻意分離。雷峰網CLAUDE.md 遵循的正是這第三層原則。而它之所以被反覆傳閱，本質上是開發者社區用腳投票，對"約束設計"這件事的集體確認。當模型能力已經足以完成寫代碼這件事之後，下一個真正稀缺的能力不是怎麼讓模型更聰明，而是"怎麼讓模型在不被盯著的時候也能做對"。這也是為什麼那段被無數開發者轉發的吐槽能產生這麼大的共鳴——或許當 AI 開始承擔真正的工程任務時，它需要的不是更多能力，而是一份它必須遵守的行為契約。上車，帶你看遍全球 AI 頂會精華可獨家暢覽：專家演講PPT大會報告全文熱門論文解讀學術新星訪談掃描上方二維碼或點擊「閱讀原文」關注專區。