header-langage
简体中文
繁體中文
English
Tiếng Việt
한국어
日本語
ภาษาไทย
Türkçe
掃碼下載APP

分析Claude Code源碼:為什麼它會比其他AI編程工具好用?

閱讀本文需 23 分鐘
Anthropic 選擇了最難的那條路,用你的終端、你的環境、你的配置來幹活,而不是「在一個乾淨房間裡給你寫一段程式碼然後複製過來」。
原文標題:《一文瞭解 Anthropic 的 Claude Code 源碼:為什麼它就是比別人好用?》
原文作者:Yuker,AI 研究員


2026 年 3 月 31 日,安全研究者 Chaofan Shou 發現 Anthropic 發布到 npm 的 Claude Code 套件中,source map 檔案沒有被剝離。


這意味著:Claude Code 的完整 TypeScript 源碼,51.2 萬行,1903 個檔案,就這樣暴露在了公網上。


我當然不可能在短短數小時內看完這麼多程式碼,因此,我帶著三個問題去讀這份源碼:


1. Claude Code 和其他 AI 程式設計工具到底有什麼本質區別?


2. 為什麼它寫程式碼的「手感」就是比別人好?


3. 51 萬行程式碼裡,到底藏著什麼?


讀完之後,我的第一反應是:這不是一個 AI 程式設計助手,這是一個作業系統。


一、先講一個故事:如果你要雇一個遠端程序員


想像你雇了一個遠端程序員,給他你電腦的遠端訪問權限。


你會怎麼做?


如果你是 Cursor 的做法:你讓他坐在你旁邊,每次他要敲命令之前你看一眼,點個「允許」。簡單粗暴,但你得一直盯著。


如果你是 GitHub Copilot Agent 的做法:你給他一台全新的虛擬機,讓他在裡面隨便折騰。搞完了把程式碼提交上來,你審核後再合併。安全,但他看不到你本地的環境。


如果你是 Claude Code 的做法:


你讓他直接用你的電腦——但你給他配了一套極其精密的安檢系統。他能做什麼、不能做什麼、哪些操作需要你點頭、哪些可以自己來、甚至他想用 rm -rf 都要經過 9 層審查才能執行。


這就是三種完全不同的安全哲學:



為什麼 Anthropic 選擇了最難的那條路?


因為只有這樣,AI 才能用你的終端、你的環境、你的配置來幹活——這才是「真正幫你寫程式碼」,而不是「在一個乾淨房間裡給你寫一段程式碼然後複製過來」。


但代價是什麼?他們為此寫了 51 萬行程式碼。


二、你以為的 Claude Code vs 實際的 Claude Code


大多數人以為 AI 編程工具是這樣的:


使用者輸入 → 呼叫 LLM API → 返回結果 → 顯示給使用者


Claude Code 實際是這樣的:


使用者輸入
→ 動態組裝 7 層系統提示詞
→ 注入 Git 狀態、專案約定、歷史記憶
→ 42 個工具各自附帶使用手冊
→ LLM 決定使用哪個工具
→ 9 層安全審查(AST 解析、ML 分類器、沙箱檢查...)
→ 權限競爭解析(本地鍵盤 / IDE / Hook / AI 分類器 同時競爭)
→ 200ms 防誤觸延遲
→ 執行工具
→ 結果流式返回
→ 上下文接近極限?→ 三層壓縮(微壓縮 → 自動壓縮 → 完全壓縮)
→ 需要並行?→ 生成子 Agent 蜂群
→ 迴圈直到任務完成


相信大家都很好奇上面的是什麼,不著急,讓我們逐個拆開看。


三、第一個秘密:提示詞不是寫出來的,是「拼裝」出來的


打開 src/constants/prompts.ts,你會看到這個函數:



注意到那個 SYSTEM_PROMPT_DYNAMIC_BOUNDARY 了嗎?


這是一個快取分界線。分界線上面的內容是靜態的,Claude API 可以快取它們,節省 token 費用。分界線下面的內容是動態的——你當前的 Git 分支、你的 CLAUDE.md 專案配置、你之前告訴它的偏好記憶……每次對話都不一樣。


這意味著什麼?


Anthropic 把提示詞當成了編譯器的輸出來優化。靜態部分是「編譯後的二進制」,動態部分是「運行時參數」。這樣做的好處是:


1. 省錢:靜態部分走快取,不重複計費


2. 快:快取命中直接跳過這些 token 的處理


3. 靈活:動態部分讓每次對話都能感知當前環境


每個工具都有獨立的「使用手冊」


更讓我震驚的是:每個工具目錄下都有一個 prompt.ts 檔案——這是專門寫給 LLM 看的使用手冊。


看看 BashTool 的(src/tools/BashTool/prompt.ts,約 370 行):




這不是寫給人看的文件,這是寫給 AI 看的行為準則。每次 Claude Code 啟動時,這些規則都會被注入到系統提示詞中。


這就是為什麼 Claude Code 從不會擅自 git push --force,而某些工具會——不是模型更聰明,是提示詞裡已經把規矩講清楚了。


而且 Anthropic 內部版本和你用的不一樣


程式碼裡大量出現這樣的分支:



ant 就是 Anthropic 內部員工。他們的版本有更詳細的程式碼風格指引(「不寫註釋除非 WHY 不明顯」)、更激進的輸出策略(「倒金字塔寫作法」),以及一些仍在 A/B 測試的實驗功能(Verification Agent、Explore & Plan Agent)。


這說明 Anthropic 自己就是 Claude Code 最大的使用者。他們在用自己的產品來開發自己的產品。


四、第二個秘密:42 個工具,但你只看到了冰山一角


打開 src/tools.ts,會看到工具註冊中心:



42 個工具,但大部分你從未直接看到過。因為很多工具是延遲加載的——只有當 LLM 需要時,才通過 ToolSearchTool 按需注入。


為什麼這樣做呢?


因為每多一個工具,系統提示詞就要多一段描述,token 就要多花一份錢。如果你只是想讓 Claude Code 幫你改一行程式碼,它不需要加載「定時任務調度器」和「團隊協作管理器」。


還有一個更聰明的設計:



設置 CLAUDE_CODE_SIMPLE=true,Claude Code 就只剩三個工具:Bash、讀檔案、改檔案。這是給極簡主義者的後門。


所有工具都從同一個工廠出來



注意那些預設值:isConcurrencySafe 默認 false,isReadOnly 默認 false。


這叫 fail-closed 設計——如果一個工具的作者忘了聲明安全屬性,系統會假設它是「不安全的、會寫入的」。寧可過度保守,也不漏掉一個風險。


「先讀後改」的鐵律



FileEditTool 會檢查你是否已經用 FileReadTool 讀過這個檔案。如果沒有,直接報錯,不讓改。


這就是為什麼 Claude Code 不會像某些工具那樣「凭空寫一段程式碼覆蓋你的檔案」——它被強制要求先理解再修改。


五、第三個秘密:記憶系統——為什麼它能「記住你」


用過 Claude Code 的人都有一個感受:它好像真的認識你。


你告訴它「不要在測試中 mock 資料庫」,下次對話它就不會再 mock。你告訴它「我是後端工程師,React 新手」,它解釋前端程式碼時就會用後端的類比。


這背後是一個完整的記憶系統。


用 AI 來檢索記憶




Claude Code 用 另一個 AI(Claude Sonnet)來決定「哪些記憶和當前對話相關」。


不是關鍵詞匹配,不是向量搜索——是讓一個小模型快速掃描所有記憶檔案的標題和描述,選出最多 5 個最相關的,然後把它們的完整內容注入到當前對話的上下文中。


策略是「精確度優先於召回率」——寧可漏掉一個可能有用的記憶,也不塞進一個不相關的記憶污染上下文。


KAIROS 模式:夜間「做夢」


這是最讓我覺得科幻的部分。


程式碼中有一個叫 KAIROS 的特性標誌。在這個模式下,長對話中的記憶不是存在結構化檔案裡,而是存在按日期的追加式日誌中。然後,有一個 /dream 技能會在「夜間」(低活躍期)運行,把這些原始日誌蒸餾成結構化的主題檔案。



AI 在「睡覺」的時候整理記憶。這已經不是工程了,這是仿生學。


六、第五個秘密:它不是一個 Agent,是一群


當你讓 Claude Code 做一個複雜任務時,它可能悄悄做了這件事:



它生成了一个子 Agent。


而且子 Agent 有严格的「自我意识」注入,防止它递归生成更多子 Agent:



这段程式碼在說:「你是一個工人,不是經理。別想著再雇人,自己幹活。」


Coordinator 模式:經理模式


在協調器模式下,Claude Code 變成一個純粹的任務編排者,自己不幹活,只分配:



核心原則寫在程式碼註釋裡:


「Parallelism is your superpower」只讀研究任務:並行跑。寫檔案任務:按檔案分組串行跑(避免衝突)。


Prompt Cache 的極致優化


為了最大化子 Agent 的快取命中率,所有 fork 子代理的工具結果都使用相同的占位符文字:


「Fork started—processing in background」


為什麼?因為 Claude API 的 prompt cache 是基於位元組級前綴匹配的。如果 10 個子 Agent 的前綴位元組完全一致,那麼只有第一個需要「冷啟動」,後面 9 個直接命中快取。


這是一個每次呼叫節省幾美分的優化,但在大規模使用下,能省下大量成本。


七、第六個秘密:三層壓縮,讓對話「永不超限」


所有 LLM 都有上下文視窗限制。對話越長,歷史訊息越多,最終一定會超出限制。


Claude Code 為此設計了三層壓縮:


第一層:微壓縮——最小代價



微壓縮只動舊的工具呼叫結果——將「10 分鐘前讀的那個 500 行文件的內容」替換成 [Old tool result content cleared]。


提示詞和對話主線完全保留。


第二層:自動壓縮——主動收縮


當 token 消耗接近上下文視窗的 87%(視窗大小 - 13,000 緩衝區),自動觸發。有一個熔斷器:連續 3 次壓縮失敗後停止嘗試,避免死循環。


第三層:完全壓縮——AI 總結


讓 AI 對整段對話生成摘要,然後用摘要替換所有歷史消息。生成摘要時有一個嚴厲的前置指令:




為什麼要這麼嚴格?因為如果總結過程中 AI 又去呼叫工具,就會產生更多的 token 消耗,適得其反。這段提示詞就是在說:「你的任務是總結,別幹別的。」


壓縮後的 token 預算:


· 文件恢復:50,000 tokens

· 每個文件上限:5,000 tokens

· 技能內容:25,000 tokens


這些數字不是拍腦袋定的——它們是在「保留足夠上下文繼續工作」和「騰出足夠空間接收新消息」之間的平衡點。


八、讀完這份源碼,我學到了什麼


AI Agent 的 90% 工作量在「AI」之外


51 萬行代碼裡,真正呼叫 LLM API 的部分可能不到 5%。其餘 95% 是什麼?


· 安全檢查(18 個文件只為一個 BashTool)

· 權限系統(allow/deny/ask/passthrough 四態決策)

· 上下文管理(三層壓縮 + AI 記憶檢索)

· 錯誤恢復(熔斷器、指數退避、Transcript 持久化)

· 多 Agent 協調(蜂群編排 + 郵件通訊)

· UI 互動(140 個 React 組件 + IDE Bridge)

· 效能優化(prompt 快取穩定性 + 啟動時並行預取)


如果你正在做 AI Agent 產品,這才是你真正要解決的問題。不是模型夠不夠聰明,是你的腳手架夠不夠結實。


好的提示詞工程是系統工程


不是寫一段漂亮的 prompt 就完事了。Claude Code 的提示詞是:


· 7 層動態組裝

· 每個工具附帶獨立的使用手冊

· 快取邊界精確劃分

· 內部版本和外部版本有不同的指令集

· 工具排序固定以保持快取穩定


這是工程化的提示詞管理,不是手工藝。


為失敗而設計


每一個外部依賴都有對應的失敗策略:



Anthropic 把 Claude Code 當作操作系統在做


42 個工具 = 系統呼叫 權限系統 = 使用者權限管理 技能系統 = 應用商店 MCP 協議 = 設備驅動 Agent 蜂群 = 處理管理 上下文壓縮 = 記憶體管理 Transcript 持久化 = 檔案系統


這不是一個「聊天機器人加幾個工具」,這是一個以 LLM 為核心的操作系統。


總結


51 萬行程式碼。1903 個檔案。18 個安全檔案只為一個 Bash 工具。


9 層審查只為讓 AI 安全地幫你敲一行命令。


這就是 Anthropic 的答案:要讓 AI 真正有用,你不能把它關在籠子裡,也不能放它裸奔。你得給它建一套完整的信任體系。


而這套信任體系的代價,是 51 萬行程式碼。


原文連結


歡迎加入律動 BlockBeats 官方社群:

Telegram 訂閱群:https://t.me/theblockbeats

Telegram 交流群:https://t.me/BlockBeats_App

Twitter 官方帳號:https://twitter.com/BlockBeatsAsia

選擇文庫
新增文庫
取消
完成
新增文庫
僅自己可見
公開
保存
糾錯/舉報
提交