<mark id="oztn4"></mark>
0
作者丨樊天驕、鄭佳美
編輯丨鄭佳美
一份只有 65 行的 Markdown 文件，剛剛成為 GitHub 歷史上最被討論的 AI 工程實踐——而它沒有寫一行可執行代碼。
這就是 2026 年 4 月開始刷屏的 andrej-karpathy-skills 項目：累計 17.6 萬顆星，單文件、零邏輯，卻在同一個月里把 Anthropic 官方的 anthropics/skills 倉庫（15.1 萬星）甩在身后。兩件事疊在一起看，AI 編程的競爭焦點正在發生一次清晰的位移——從"模型能不能寫"，轉向"模型在沒人盯著時，能不能不寫錯"。
01
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
CLAUDE.md 的風潮很快席卷了 GitHub，衍生出一批同方向的探索項目。其中開發者 VoidLight00 的思路值得專門拿出來：一個能讓 AI 自動優化 AI 規則的系統。
他的實現路徑帶著鮮明的工程思維：先在 eval.json 中定義一套斷言測試集，用來量化評估規則文件的實際效果；再讓系統進入"修改規則 — 重跑測評"的循環，如果本輪評分有提升就保留變更，沒有增益就回滾到上一版本。整套流程相當于把原本靠人工反復打磨的提示詞優化工作，轉化成了類似代碼自動化測試的標準化流程。
更有意思的是一組對照實驗：有開發者試著把 Karpathy 這份規則擴充到 200 行，結果 AI 生成的代碼質量非但沒提升，反而出現了下滑。
背后的邏輯并不復雜。當規則文件越寫越長，真正關鍵的約束會淹沒在冗余的描述里。大模型固然能處理長上下文，但不代表它能在每一次生成中穩定識別并貫徹所有細則。規則文件的有效性，取決于模型在還沒忘之前讀到核心約束的概率。
這也解釋了為什么 Karpathy 那份文件從一開始就走極簡路線——四條原則、幾十行、沒有任何具體技術棧要求。它把工程紀律壓縮到了 AI 最容易穩定執行的篇幅里。當 65 行就能解決核心問題，200 行的邊際收益大概率是負的。
工程意義上的"短而精"，在 AI 編程時代有了新的具體含義：它不是文字上的克制，而是與模型注意力機制的精確對齊。規則寫在模型能穩定看見的位置，寫在它愿意照做的篇幅里，寫在它最不容易讀到一半就走神的長度內。
03
把這件事放回 LLM 工程化的整體脈絡看，它指向了一個更清晰的分層。
第一層是 Prompt Engineering。關注點在"讓模型聽懂指令"。這一層在過去兩年里被研究得最透，天花板也最明顯——提示詞寫得再精妙，模型行為的不穩定性依然存在，因為提示詞是"軟"的，模型可以選擇不聽。
第二層是 Workflow Engineering。關注點在"讓模型按步驟做事"。把任務拆成多步、引入 ReAct、引入反思機制，讓模型有能力處理長鏈任務。這一層顯著提升了單任務成功率，但仍然無法約束"模型在某個步驟上的越界行為"——工作流規定了"先做什么后做什么"，卻沒有規定"什么不能做"。
第三層是 Agent Governance。關注點在"讓模型只能在邊界內做事"。這一層的設計對象不是"任務"，而是"模型本身的行為約束系統"——包括規則文件、沙箱、審批、審計、回歸測試。這些文件本質上是"投影"——它們從同一個規則源編譯出來，分發給不同的 AI 代理。比如 AGENTS.md 寫給機器，README.md 寫給人，二者刻意分離。雷峰網(公眾號：雷峰網)
CLAUDE.md 遵循的正是這第三層原則。而它之所以被反復傳閱，本質上是開發者社區用腳投票，對"約束設計"這件事的集體確認。當模型能力已經足以完成寫代碼這件事之后，下一個真正稀缺的能力不是怎么讓模型更聰明，而是"怎么讓模型在不被盯著的時候也能做對"。
這也是為什么那段被無數開發者轉發的吐槽能產生這么大的共鳴——或許當 AI 開始承擔真正的工程任務時，它需要的不是更多能力，而是一份它必須遵守的行為契約。
上車，帶你看遍全球 AI 頂會精華
可獨家暢覽：
專家演講PPT
大會報告全文
熱門論文解讀
學術新星訪談
掃描上方二維碼
或點擊「閱讀原文」關注專區。
雷峰網原創文章，未經授權禁止轉載。詳情見轉載須知。
