撕開Claude Code真相：讓它好用的98.4%，是工程不是AI

新智元報道

編輯：元宇

【新智元導讀】當普通人還在鉆研「最強提示詞咒語」時，硅谷頂級實驗室已經把AI基建跑成了生產線。

你還在ChatGPT的聊天框里反復調prompt？

最近，一位X用戶發(fā)了條推文，開頭就是一個驚呼：頭部大廠偷偷在用的Claude Code項目模板外泄！

這已經不是寫提示詞了。這是AI工程基礎設施。

整套打法圍繞一個文件「CLAUDE.md」展開，而它的核心原則只有三條：

每次Claude犯錯→你加一條規(guī)則；每次你重復自己→你加一個工作流；每次出bug→你加一道護欄。

這樣做，是要把項目經驗沉淀成它每次啟動都會讀取的長期上下文和自動化約束。

整個架構，像是一家AI公司的崗位編制：CLAUDE.md是入職手冊，skills/是工作SOP，hooks/是合規(guī)部，docs/是公司章程，tools/是后勤組，src/才是真正出活的業(yè)務部門。

你不再是在和AI聊天了，而是在構建一個了解你代碼倉庫的AI。

最瘋狂的部分是，你只需要配置一次，Claude就會自動審查代碼，并按指令重構、強制執(zhí)行架構規(guī)則、撰寫發(fā)布說明、從技能中運行工作流、記住過去錯誤等。

而且它會越用越聰明。

大多數人，都是打開ChatGPT，寫提示詞，復制粘貼，反復；而在這套打法下，你只需要打開終端，跑一個skill代碼已交付。

這等于是在自己的代碼庫里養(yǎng)了一隊AI同事。

這條推文背后，傳遞的是這個時代正在悄悄翻篇的一個小信號，大多數人可能還沒反應過來。

一張不算泄露的「泄露截圖」

撕開一個真相

@ai_rohitt曬出來的這張截圖，是Anthropic官方文檔里公開推薦的Claude Code標準范式。

CLAUDE.md是Claude Code在每次會話開始時自動讀取的項目記憶文件。

.claude/skills/和.claude/hooks/是官方支持的擴展機制。

這些都是社區(qū)已經討論了幾個月的公開做法，并不是什么人偷出來的「內部模板」。

但它之所以能讓一些資深開發(fā)者主動轉發(fā)，說明它得到了一些天天用Claude的開發(fā)者們的認同。

其中相當一部分人，可能這兩天才意識到原來它還能這么用。

而硅谷頂級團隊，已經把這件事跑成了生產線。

第一個例子，是OpenAI Frontier團隊。

OpenAI官方披露的Frontier團隊實驗中，一個從空repo起步的內部beta，在約5個月內由Codex生成了約100萬行代碼和約1500個PR；團隊從3人擴展到7人，人工不直接寫代碼。

帶隊的Ryan Lopopolo在后續(xù)訪談中進一步提到，這套工作流已經接近「0 人工代碼、0 人工 review」的極限形態(tài)。

他認為與其節(jié)省token，不如利用模型極高的并發(fā)能力和極低的成本來代替人類有限且昂貴的同步注意力。

第二個例子，是Stripe內部的自動化代碼代理系統(tǒng)Minions。

Stripe內部的Minions每周生成并推動超過1300個PR合并，這些代碼從頭到尾由AI生成，但仍經過人工review。

這里還有一對數據：1.6%vs98.4%，它來自Mohamed bin Zayed AI大學VILA-Lab發(fā)表的一篇論文。

https://arxiv.org/pdf/2604.14228

研究者系統(tǒng)性扒了Claude Code v2.1.88版本51.2萬行TypeScript源碼，給出的結論是：只有1.6%是AI決策邏輯，剩下的98.4%是確定性的工程基礎設施。

具體說就是權限網關、上下文管理、工具路由、錯誤恢復這四類。

這組數字不是說模型只貢獻1.6%的能力，而是說明Claude Code作為產品，大量復雜度不在模型本身，而在權限、上下文、工具路由、恢復機制等確定性工程基礎設施上。

@ai_rohitt那張圖里的CLAUDE.md/skills/hooks結構，就是普通開發(fā)者也能搭一套的「入門版基建」，它和OpenAI、Stripe那套生產級架構是同一種范式，只是規(guī)模小得多。

CLAUDE.md暴露的秘密

過去3年，所有人都在問「GPT什么時候能更聰明」「Claude什么時候出新版本」。

但真正在生產環(huán)境跑通AI編程的團隊，他們更關心的可能根本不是這個，而是如何讓AI記住自己上次踩過的坑，怎么讓AI在動手前先看一眼項目的架構約束，怎么讓AI犯錯的時候自己被工具擋住。

CLAUDE.md正是這一切的承載體。

Anthropic官方對它的定義只有一句：

一個markdown文件，放在項目根目錄，Claude Code在每次會話開始時自動讀取。

https://code.claude.com/docs/en/memory

聽上去很簡單，圍繞它展開的那幾層結構，才是它真正厲害的部分。

CLAUDE.md是項目大腦。

架構決策、命名約定、測試要求、那些反復踩過的坑，都堆在這里。它是AI每次啟動時第一眼看到的「員工手冊」。

.claude/skills/是可復用工作流。

Claude Code的創(chuàng)建者Boris Cherny在社區(qū)里反復強調一句話：「如果你每天做某件事超過一次，把它變成skill或command。」

一個skill就是一段可執(zhí)行的方法論。Code review、生成commit message、寫發(fā)布說明，這些都不該是每天手敲提示詞的活，應該是skill調一下就出結果。

.claude/hooks/是自動護欄。

這是最關鍵的部分。它不依賴AI自己判斷，由確定性代碼在AI犯錯之前就擋住它。這就是為什么敢讓AI「無人監(jiān)督」地跑，因為出錯的邊界由hooks卡死了。

docs/decisions/是架構決策記錄。

讓AI不僅知道代碼「是什么」，還知道代碼「為什么是這樣」。

這一項最容易被忽略，但也是AI協(xié)作最大的杠桿點。

tools/和src/是執(zhí)行層。

這套架構真正值得注意的地方，不在于某個開發(fā)者搞出了一個漂亮目錄，而是越來越多獨立團隊正在收斂到同一個方向：把模型放進一套由上下文、工具、權限、評估和反饋循環(huán)組成的harness里。

GitHub上已經能看到不少類似項目：

rohitg00的awesome-claude-code-toolkit、diet103的claude-code-infrastructure-showcase、affaan-m的everything-claude-code，都在圍繞agents、skills、hooks、rules、MCP configs等組件搭建Claude Code的工程化工作環(huán)境。

這說明，真正成熟的AI編程工作流，不是只靠一個更強的模型，也不是只靠一條更長的prompt，而是把模型嵌入一套可復用、可約束、可恢復、可審計的工程系統(tǒng)里。

至于具體目錄結構，各家實現(xiàn)并不完全相同。

OpenAI實驗室的極限實驗

2026年2月11日，OpenAI官方博客發(fā)了一篇文章：《Harness engineering: leveraging Codex in an agent-first world》。

https://openai.com/index/harness-engineering/

Anthropic圍繞這個概念重新調整了Claude Code的架構思路；Martin Fowler的網站把它凝練成一個公式：「Agent=Model+Harness。」

Harness這個詞來自馬術。它指的是馬的整套挽具，韁繩、馬嚼子、馬鞍、籠頭。

一匹馬可以跑得很快很有力，但它自己不知道往哪兒走：整套挽具決定了它的方向。

類比到AI編程：模型本身能力很強，但它不知道在你的代碼庫里該往哪兒走。Harness就是你為它造的方向盤+剎車+導航。

OpenAI Frontier團隊那個「100萬行0人工」的實驗，本質就是把Harness做到極致。

他們的關鍵工程實踐包括以下幾條。

層級架構強約束。

從Types到Config到Repo到Service到Runtime到UI，依賴關系單向流動，由linter在CI層強制執(zhí)行。Agent寫出違反層級關系的代碼？直接構建失敗。

linter錯誤信息本身是修復指令，這也是最反直覺的細節(jié)。

普通項目的lint錯誤是「violation detected」，給人看的；OpenAI Frontier的lint錯誤是「use logger.info({event: 'name', ...data}) instead of console.log」，給Agent看的、可以直接讀懂并修復的指令。

文檔作為單一事實來源。所有架構圖、execution plans、設計規(guī)范都在倉庫內部的docs/目錄。Agent不需要任何外部知識庫，一切就在repo里。

這套東西效果有多厲害？

模型沒有換，但LangChain調整了harness，包括系統(tǒng)提示、工具、中間件和推理模式，最終把Terminal Bench 2.0分數從52.8提到66.5。

你今天就能做的事

是為AI造一個項目大腦

問題回到普通開發(fā)者這里：如果范式已經轉移，作為一個普通工程師，今天就能做點什么。

第一件事，在你最重要的項目根目錄建一個CLAUDE.md。

不需要完美，也不需要很長。寫下你團隊的架構規(guī)則、命名約定、測試要求、那些反復踩過的坑，10分鐘能寫完一個能用的版本。

下次AI犯錯的時候，先不要手動修，而是問自己一句：CLAUDE.md里缺了什么？

第二件事，把每天重復做的事改造成skill。

這里要注意Boris Cherny的金句：「如果你每天做某件事超過一次，把它變成skill或command。」

Code review、生成commit message、寫發(fā)布說明、修一類重復的bug，這些都該是skill，不該是每天手敲提示詞。

第三件事，在容易踩坑的地方加一個hook。

Hook是98.4%里最有杠桿的那部分。它不依賴AI變聰明，它依賴確定性代碼做強制檢查。這是把人類工程師的判斷力翻譯成機器可讀約束的過程。

這件事的核心不在寫代碼，而在寫規(guī)則。

Karpathy今年1月在推特上的那句被廣泛轉發(fā)的話：「我已經從80%手動寫代碼變成了80%交給Agent寫。」

未來五年，工程師的能力曲線正在從「我能寫多少行代碼」轉向「我能為AI設計多嚴格的工作環(huán)境」。

寫代碼的活兒正在被Agent接管。

但設計那個讓Agent能寫出好代碼的世界，還是人的工作。而且比以前更難、更重要、也更有意思。

參考資料：

https://x.com/ai_rohitt/status/2048390767115428016?s=20

https://arxiv.org/pdf/2604.14228