在 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 編程時代有了新的具體含義:它不是文字上的克制,而是與模型注意力機制的精確對齊。規則寫在模型能穩定看見的位置,寫在它愿意照做的篇幅里,寫在它最不容易讀到一半就走神的長度內。
03
AI 編程下半場:
稀缺的不是模型,是約束設計
把這件事放回 LLM 工程化的整體脈絡看,它指向了一個更清晰的分層。
第一層是 Prompt Engineering。關注點在"讓模型聽懂指令"。這一層在過去兩年里被研究得最透,天花板也最明顯——提示詞寫得再精妙,模型行為的不穩定性依然存在,因為提示詞是"軟"的,模型可以選擇不聽。
第二層是 Workflow Engineering。關注點在"讓模型按步驟做事"。把任務拆成多步、引入 ReAct、引入反思機制,讓模型有能力處理長鏈任務。這一層顯著提升了單任務成功率,但仍然無法約束"模型在某個步驟上的越界行為"——工作流規定了"先做什么后做什么",卻沒有規定"什么不能做"。
第三層是 Agent Governance。關注點在"讓模型只能在邊界內做事"。這一層的設計對象不是"任務",而是"模型本身的行為約束系統"——包括規則文件、沙箱、審批、審計、回歸測試。這些文件本質上是"投影"——它們從同一個規則源編譯出來,分發給不同的 AI 代理。比如 AGENTS.md 寫給機器,README.md 寫給人,二者刻意分離。
CLAUDE.md 遵循的正是這第三層原則。而它之所以被反復傳閱,本質上是開發者社區用腳投票,對"約束設計"這件事的集體確認。當模型能力已經足以完成寫代碼這件事之后,下一個真正稀缺的能力不是怎么讓模型更聰明,而是"怎么讓模型在不被盯著的時候也能做對"。
這也是為什么那段被無數開發者轉發的吐槽能產生這么大的共鳴——或許當 AI 開始承擔真正的工程任務時,它需要的不是更多能力,而是一份它必須遵守的行為契約。
上車,帶你看遍全球 AI 頂會精華
可獨家暢覽:
專家演講PPT
大會報告全文
熱門論文解讀
學術新星訪談
未經「AI科技評論」授權,嚴禁以任何方式在網頁、論壇、社區進行轉載!
公眾號轉載請先在「AI科技評論」后臺留言取得授權,轉載時需標注來源并插入本公眾號名片。
特別聲明:以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布,本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.