源碼被開源，Claude Code之父回應了：純內部開發者手滑

機器之心編輯部

昨天，AI 圈最炸的一件事，莫過于 Claude Code 的源代碼「被動」開源。

由于工程失誤，Anthropic 在發布 npm 包時未剔除 source map 文件，導致完整的 TypeScript 源碼被輕易還原。短短幾個小時內，代碼已經被下載、鏡像，并在 GitHub 上迅速擴散。

這種泄露方式，怎么不算某種意義上的開源呢？就連馬斯克在看到別人評論「Anthropic 現在已經比 OpenAI 更 Open」時也忍不住「夸上一句」：「絕了」。

至于此事的原因，也并不復雜，盡管 Anthropic 尚未發布官方報告，但科技媒體 Decrypt 從一位 Anthropic 發言人那里得到了評論：「今天早些時候，一個 Claude Code 版本包含了部分內部源代碼。沒有涉及或暴露任何敏感的客戶數據或憑證。這屬于人為錯誤導致的發布打包問題，并未構成安全漏洞。我們正在采取措施防止此類事件再次發生。」

Claude Code 之父 Boris Cherny 也在 X 上簡單表示這「就是開發者的錯誤」所致。

就在大家還在圍觀這場被動開源的戲劇性時刻時，另一批人已經開始沉下心來逐行閱讀代碼，并嘗試還原其背后的設計邏輯。

一些原本不對外公開的系統級策略也被揭示出來，尤其是在模型能力保護與數據安全層面，Claude Code 顯然做了更深的工程設計。

對 Claude Code 源代碼的多方深度解讀

當吃瓜群眾還在圍觀時，大量開發者已經開始逐行閱讀代碼，嘗試還原頂級 AI Agent 背后的設計邏輯。一些原本不對外的系統級策略也隨之曝光。

Claude Code 內置了兩套反蒸餾機制

X 用戶 Sahil 發現：Anthropic 在 Claude Code 中內置了兩套反蒸餾機制，用于防止競爭對手利用其數據進行訓練。

• 其中一套機制，會在模型輸出流中注入偽造的工具調用，從而污染任何被抓取的數據，使其難以被有效用于訓練。
• 另一套機制，則會將所有工具調用的具體細節抽象成模糊的摘要，使得外部很難還原 Agent 實際執行了哪些操作。

來源：https://x.com/sahilypatel/status/2039004352367689891

Claude Code 源碼可以學到并復用的東西

而 AlphaSignalAI 開發者 Lior Alexander 則對 Claude Code 源代碼進行了深度分析，并給出了 14 點總結，我們挑選了其中幾條比較有價值的供大家參考：

來源：https://x.com/LiorOnAI/status/2039068248390688803

1：系統提示詞是一門行為控制的范本

完整的 system prompt 位于 constants/prompts.ts，可以說是整個代碼庫中最有價值的文件。它清晰展示了 Anthropic 是如何在生產級編碼 Agent 中精確控制 Claude 的行為，以及每一條指令背后的設計動機。

三行重復代碼，也好過過早抽象。在編碼指令部分，系統明確要求 Claude 不要為一次性操作創建 helper、工具函數或抽象結構，也不要為假想的未來需求做設計。

默認不寫注釋。一個帶有 @[MODEL LAUNCH] 標記的注釋說明，這是為了對抗內部代號為 Capybara 的模型默認過度注釋的問題。只有在 WHY is non-obvious 時才允許添加注釋。

如實報告結果。另一個 @[MODEL LAUNCH] 標注透露，Capybara v8 的錯誤陳述率高達 29–30%（相比 v4 的 16.7%）。因此，prompt 明確規定：

• 不要在測試失敗時聲稱全部通過
• 不要隱藏失敗檢查來制造成功結果
• 不要把未完成的工作描述為已完成

用數字約束比用模糊描述更有效。源碼中的注釋提到：相比簡潔表達，使用明確字數限制可降低約 1.2% 的輸出 token。因此，Anthropic 不說寫得簡短，而是直接規定：

• 工具調用之間的文本 ≤25 個詞
• 最終回答 ≤100 個詞

外部提示詞與內部提示詞分層設計。對外用戶使用的提示詞是簡潔版，比如：直奔重點，盡量簡短。而內部（Anthropic 員工使用）版本則更復雜。

隱藏的 Simple 模式。當設置環境變量 CLAUDE_CODE_SIMPLE=1 時，整個復雜的 system prompt 會被壓縮為一行：「You are Claude Code, Anthropic's official CLI for Claude」，并附帶當前工作目錄與日期。

不包含任何編碼規則、語氣控制或工具使用指令。

2：對 Claude Code 爆粗口，會被標記為負面輸入

在 utils/userPromptKeywords.ts 這個僅 26 行的小文件中，系統會在每條用戶輸入發送到 API 之前，用兩組正則表達式檢測用戶臟話粗口。

對此，Claude Code 之父 Boris Cherny 評論說：「這是我們用來判斷用戶體驗是否良好的信號之一。」

3：Claude Code 里藏了一個電子寵物

在 src/buddy/ 中，系統通過對用戶 ID 進行哈希（基于帶種子的隨機數生成器），為每個用戶生成一個專屬且固定的虛擬伙伴（代號 Buddy），其物種、外觀和屬性均由算法決定，從而實現無需存儲的個性化體驗。

這個哈希值會進一步映射為一整套完整的角色配置，包括：

• 物種：鴨子、鵝、Blob、貓、龍、章魚、貓頭鷹、企鵝等
• 帽子：無、王冠、禮帽、螺旋槳帽等
• 稀有度：普通（60%）、不常見（25%）、稀有（10%）等

值得注意的是，剛剛更新的 Claude Code v2.1.89 已經上線了 Buddy，用戶更新后只需輸入 /buddy 即可啟用 —— 即使配置了其它模型也可成功啟用。比如這里我們配置了 MiniMax-M2.7 的 Claude Code 便認領了一個名為 Moth 的 Buddy。

4：內置 187 個加載動詞

Claude Code 內置了 187 個隨機動詞，在模型思考時輪流顯示（比如 Beboppin'、Lollygagging 等），用來替代單調的 Loadind。這些動詞古靈精怪的：Accomplishing、Actioning、Actualizing、Architecting、Baking…… 共 187 個。

而 Cherny 表示這個詞匯表最早是他搞出來的，并吸收了其他人的一些貢獻。他還進一步指出用戶也可以讓 Claude 添加自己想要的動詞。

5：反蒸餾機制：通過注入假工具污染競爭對手訓練數據

在 services/api/claude.ts 中，有一項通過 feature flag 控制的機制：在 API 請求體中加入anti_distillation: ['fake_tools']。

這會指示 Anthropic 的 API 在請求中注入一些虛假的、不可用的工具定義。

此外，還有一個 streamlinedTransform.ts，實現了一種抗蒸餾的輸出格式：

• 去除模型的思考過程（thinking content）
• 將工具調用簡化為類別統計（如搜索、讀取、寫入、命令等）

從而讓外部很難根據捕獲的輸出，還原 Claude 的完整推理鏈路。

6：Prompt 緩存被極致精細化管理

代碼庫中最復雜的非 UI 代碼之一是 promptCacheBreakDetection.ts。在每一次 API 調用中，系統都會對 system prompt、每個工具的 schema（逐一哈希）、模型名稱、beta headers、fast mode 狀態、effort 參數、overage 狀態以及額外的請求體參數進行哈希處理，并將這些哈希值與上一次調用進行對比。如果有任何變化，就會記錄是哪一部分發生了變化，并生成統一的 diff。

system prompt 被 SYSTEM_PROMPT_DYNAMIC_BOUNDARY 分為兩部分：上半部分是靜態且可緩存的內容，下半部分是動態且隨會話變化的內容。MCP 服務器相關指令被從 system prompt 中移除，改為通過 message 的增量附加（delta attachments）傳遞，因為如果放在 system prompt 中，每次有服務器連接都會導致緩存失效。

子 Agent 會從父 Agent 繼承 CacheSafeParams（一個包含所有影響緩存鍵參數的結構體）。源碼中有一條注釋警告：在 fork 出來的 Agent 上設置 maxOutputTokens，可能會意外限制 budget_tokens，并在舊模型上破壞緩存兼容性。

7：臥底模式（Undercover Mode）：在開源貢獻中隱藏身份

utils/undercover.ts 中實現了一種臥底模式。當 Anthropic 員工（USER_TYPE === 'ant'）在非內部倉庫中工作時，該模式會自動開啟，而且默認始終為開啟狀態。只有當 git 遠程倉庫明確匹配內部白名單時，才會關閉。

一旦激活，系統提示詞中會注入一段標題為 UNDERCOVER MODE: CRITICAL 的指令，要求 Claude：

你正在一個公共 / 開源倉庫中以‘臥底’身份工作。你的提交信息、PR 標題和 PR 內容中，絕不能包含任何 Anthropic 內部信息。不要暴露身份。

被禁止的信息包括：內部模型代號（如 Capybara、Tengu 等）、未發布的模型版本號、內部倉庫名稱、Slack 頻道、Claude Code 這一表述、任何關于自己是 AI 的描述，以及 Co-Authored-By 等署名信息。

源碼中的注釋寫道：這個模式沒有強制關閉選項。它用于防止模型代號泄露。如果系統無法確認當前倉庫是內部倉庫，就始終保持臥底狀態。

8：25 萬次被浪費的 API 調用：催生熔斷機制

自動壓縮（auto-compaction）系統中的一段注釋，堪稱整個代碼庫里最真實的工程記錄之一：

BQ 2026-03-10：有 1,279 個會話在單個會話中出現了 50 次以上的連續失敗（最多達到 3,272 次），每天在全球范圍內浪費約 25 萬次 API 調用。(BQ 2026-03-10: 1,279 sessions had 50+ consecutive failures (up to 3,272) in a single session, wasting ~250K API calls/day globally.)

最終的解決方案是：設置 MAX_CONSECUTIVE_AUTOCOMPACT_FAILURES = 3。當連續三次壓縮失敗后，系統將停止繼續嘗試。

壓縮系統還設置了一系列關鍵閾值：

• 為摘要輸出預留 20,000 tokens（基于歷史觀測中摘要長度的 p99.99，約為 17,387 tokens）
• 自動壓縮觸發閾值：context_window - max_output_tokens - 13,000 buffer
• 強制壓縮（阻塞用戶）閾值：context_window - max_output_tokens - 3,000 buffer

9：驗證：不給模型自我感覺良好的機會

Claude Code 里有一個很關鍵的設計：寫代碼的 Agent，不能自己說我做完了。

當任務涉及一定復雜度（比如改了 3 個以上文件、動了后端或基礎設施），系統會自動拉起一個獨立的驗證智能體來檢查結果。

流程很簡單：

• 主 Agent 寫代碼
• 驗證 Agent 獨立檢查
• 主 Agent 還要再抽查驗證結果

如果失敗，就改；通過了，也不能盲信，還要復核證據。

10：Auto Dream：跨會話的后臺記憶整合

services/autoDream/autoDream.ts 實現了一套后臺記憶整合機制。當時間間隔足夠、且累計了足夠多的會話后，Claude Code 會以 fork 出的 subagent 形式運行 /dream，回顧歷史會話內容，并將其壓縮整理為結構化的 MEMORY.md 文件。

系統的觸發流程遵循先便宜后昂貴的判斷順序：首先檢查時間（是否距離上次整理足夠久），其次檢查會話數量（是否積累了足夠的新內容），最后檢查鎖（是否已有進程在執行整理）。執行過程中會加文件鎖，若整理失敗則自動回滾。

記憶整理采用固定模板，提取為 10 個結構化模塊：Session Title、Current State、Task Specification、Files and Functions、Workflow、Errors & Corrections、Codebase Documentation、Learnings、Key Results 和 Worklog。每個模塊限制在約 2000 tokens，總體控制在 12000 tokens 以內。

此外，記憶提取不僅在周期性觸發，也會在任務循環中動態發生：當累計上下文達到 10000 tokens 時首次觸發，此后每增加 5000 tokens 或發生 3 次工具調用，就會再次觸發一次整理。

11：2592 行 Bash 安全防護（共 42 項獨立檢查）

tools/BashTool/bashSecurity.ts 文件長達 2592 行，實現了 42 項不同的安全檢查機制。

12：排除字符串：構建階段的金絲雀機制（Build-Time Canary）

代碼庫中多處引用了 excluded-strings.txt 文件。這個文件列出了絕對不能出現在外部構建產物中的字符串，包括內部代號、API Key 前綴以及其他敏感信息。構建系統會對打包后的輸出進行 grep，一旦發現這些字符串，就會直接構建失敗。

Sebastian Raschka 解讀

知名 AI 技術博主、《Python 機器學習》作者 Sebastian Raschka 也第一時間對這批泄露代碼進行了梳理與解讀，發現了一些有趣的小信息。

博客鏈接：https://sebastianraschka.com/blog/2026/claude-code-secret-sauce.html

1：Claude Code 會構建實時倉庫上下文

這是最直觀的一點：當你開始輸入提示時，Claude 會自動加載主分支、當前分支、最近的提交記錄，以及 CLAUDE.md 文件，作為上下文的一部分。

2：激進的 Prompt 緩存復用機制

似乎存在一種邊界標記（boundary marker），用于區分靜態內容與動態內容。這意味著靜態部分會被全局緩存，以保證系統穩定性，同時避免每次都重新構建和處理這些計算開銷較高的內容。

3：工具體系優于上傳文件聊天

提示詞中似乎會引導模型優先使用專門的 Grep 工具，而不是通過 Bash 調用 grep 或 rg，這很可能是因為專用工具在權限管理上更安全，同時在結果收集與處理上也更加高效。

此外，系統還提供了專門的 Glob 工具用于文件發現（檢索文件路徑）。更進一步，它還集成了 LSP（語言服務器協議）工具，用于調用關系分析、查找引用等任務。

相比之下，傳統的 Chat UI 更像是將代碼當作靜態文本來處理，而這一整套工具鏈則讓模型能夠以結構化方式理解和操作代碼，這無疑帶來了顯著的能力提升。

4：最小化上下文膨脹

在處理代碼倉庫時，一個核心問題是上下文長度有限。尤其是在與 Agent 多輪交互、反復讀取文件、處理日志以及長時間 shell 輸出等場景下，這個問題會被迅速放大。

Claude Code 在這方面做了大量底層工程優化來緩解這一問題。例如：

• 文件讀取去重：系統會檢測文件是否發生變化，若未變化則不會重復處理；
• 大結果外置：當工具輸出結果過大時，會寫入磁盤，而在上下文中僅保留摘要預覽和文件引用；
• 自動上下文管理：與現代 LLM UI 類似，系統會自動截斷過長上下文，并在必要時進行自動壓縮（總結）。

整體來看，這些機制都是為了在有限的上下文窗口內，盡可能保留高價值信息，同時避免無效信息占用空間。

5：結構化會話記憶

Claude Code 會為當前對話維護一份結構化的 Markdown 文件，其中包含如下內容：

• 會話標題
• 當前狀態
• 任務描述
• 文件與函數
• 工作流程
• 錯誤與修正
• 代碼庫與系統文檔
• 學習與總結
• 關鍵結果
• 工作日志

從某種程度上來說，這其實很像人類寫代碼時的方式，我們也會不斷記錄筆記、總結過程，以便在復雜任務中保持清晰的上下文與思路。

6：使用 Fork 與 Subagents

Claude Code 通過 Subagents 并行處理任務，這一點其實并不令人意外。長期以來，這也是它相較于 Codex 的一個優勢（直到 Codex 最近也開始支持子 Agent）。

在這里，被 fork 出來的 Agent 會復用父 Agent 的緩存，同時又能夠感知可變狀態。這使得系統可以在后臺執行諸如摘要生成、記憶提取、背景分析等旁路任務，而不會干擾主 Agent 的執行流程。

Sebastian 最后總結，Claude Code 之所以優于普通的 Web UI，并不在于提示詞工程，甚至也不完全取決于模型本身，而在于上述這些圍繞性能與上下文管理的細節優化。

當然，還有一個很現實的因素：所有內容都可以在本地有序組織，而不需要反復將文件上傳到聊天界面。這種工作方式本身，也顯著提升了整體使用體驗。

還有網友整理了一份 Claude Code 源碼深度研究報告，覆蓋整體架構、系統提示詞、Agent 提示詞、Skills、Plugins、Hooks、MCP、權限與工具調用機制，以及新增的全量 Prompt 提取框架分析與 Agent 調度鏈深挖。

這里就不再一一介紹了，感興趣的讀者可以前去查看。

地址：https://github.com/tvytlx/claude-code-deep-dive

改寫與改進版正在涌現

有意思的是，由于直接發布 Anthropic 泄漏的源代碼可能存在法律風險，一些研究者和工程師已經開始著手改寫甚至改進 Anthropic 這 50 多萬行代碼了，當然這些工作本身也離不開 AI。更有意思的是，其中一個項目甚至創造了 GitHub 歷史上星數增長速度最快記錄！

時間要倒回到 Claude Code 源代碼被泄漏之后大概 6 小時，此時該代碼已經在 GitHub 上被 fork 超 4 萬次，這時候 Anthropic 也開始反應過來，試圖通過美國的數字千年版權法（DMCA）迫使 GitHub 刪除這些源代碼。

當然，所有人都知道：為時已晚。

除了成千上萬開發者已經下載到自己本地的版本，這些源代碼也已經被上傳到了去中心化平臺上 ——「永遠不會被刪除」。

https://gitlawb.com/node/repos/z6MkgKkb/instructkr-claude-code

一位名叫 Sigrid Jin 的韓國開發者更是另辟蹊徑，決定改寫一個版本。

據了解，他是在凌晨 4 點醒來時看到了 Claude Code 源代碼泄漏的消息。他于是決定坐下來，使用一個名為 oh-my-codex 的 AI 編排工具從頭開始將核心架構移植到 Python ，并在日出前推送了 claw-code 項目。該倉庫的 Star 數如火箭般飆升，僅僅 2 個小時就超過了 5 萬個，打破了 GitHub star 增長速度的歷史紀錄。

現如今，這個上線才十余小時的庫的 Star 數已經來到了驚人的 6.6 萬并仍在持續增長中。

https://github.com/instructkr/claw-code

更值得注意的是，從這個庫的 About 也能看到，Sigrid Jin 目前也正與開源社區（加上他們的 AI）一道用 Rust 重寫該項目！

對此，《The Pragmatic Engineer》的創始人 Gergely Orosz 在 X 上的一篇帖子中指出：這要么很絕妙，要么很可怕： Anthropic 意外泄露了 Claude Code 的 TS 源代碼。共享源代碼的倉庫被 DMCA 下架。但是這個倉庫使用 Python 重寫了代碼，因此它沒有侵犯版權，并且無法被下架，讓 DMCA 有力也無處使！

而如果考慮到 Claude Code 本身很大一部分就是 AI 編寫的，背后的法律問題還可能變得更加復雜 —— 畢竟 AI 生成的內容（AIGC）是否應當具有版權一直以來都備受爭議。

另外，開源社區對 Claude Code 的改進也已經開始！

畢竟，51 萬行代碼的項目，問題肯定少不了，正如 X 用戶 Rohan 在自己的技術博客中分析的那樣，Anthropic 在設計 Claude Code 時有一些「錯誤之處」。

https://x.com/rohan_2502/status/2038927786228998194

我們讓 Gemini 簡單總結了一下：

• 上帝組件與 Hook 濫用：核心交互組件 REPL.tsx 長度超 5000 行，包含 227 個 Hook 調用，邏輯高度耦合且無法進行單元測試。
• 特性標志與環境變數泛濫：存在 89 個特性標志和 472 個環境變量，反映出產品方向不明確且缺乏對陳舊試驗代碼的清理。
• 架構設計缺失導致循環引用：61 個文件存在循環依賴補丁，核心類型 Tool.ts 過于沉重，導致模塊邊界模糊且嚴重依賴 lazy require 避坑。
• 防御性編程淪為形式主義：為防止泄露代碼而強制使用的超長類型名（53 字符）被調用上千次，已失去警示作用，演變為無意義的「代碼儀式」。
• 性能優化的極端折中：為了在 Bun 環境下節省 135 毫秒啟動時間，將近 4700 行的 CLI 邏輯堆積在單一入口文件，犧牲了代碼的可讀性與維護性。
• 快速擴張的技術債：底層模式顯示功能迭代速度遠超架構演進，即便擁有巨額融資，頂尖 AI 產品的工程實踐依然充滿了臨時的局部規避與妥協。

改進也正在進行時……X 用戶 idoubi「讓 Claude Code 分析了一遍 claude-code-sourcemap 源碼，把邏輯全部抽離出來，寫了個 open-agent-sdk，用于替代 claude-agent-sdk」，解決了 claude-agent-sdk 不適合云端規模化調用的問題。

https://github.com/shipany-ai/open-agent-sdk

而 X 用戶則添加了一個 shim，將 Claude Code 開放給了各種第三方模型和服務：

與此同時，OpenClaude、Free Code、claw-code 等不同名稱的項目也正如雨后春筍般涌現。

結語

Claude Code 源碼泄露事件提供了一個極具觀察價值的行業切片。

一方面，它向我們展示了即便是估值百億的頂尖 AI 企業，其底層工程實現依然充滿了妥協、技術債與「草臺班子」式的局部修補。那些看似高深莫測的 Agent 能力，往往是由極其細致甚至略顯繁瑣的工程校驗規則堆砌而成的。

另一方面，社區在短短 24 小時內的反應速度令人驚嘆。

借助 AI 工具，開發者可以瞬間解構、翻譯并重構 51 萬行的復雜系統。當代碼重構的時間成本被壓縮到極致，傳統的軟件著作權邊界變得模糊不清。

這場由失誤引發的代碼狂歡，預示著 AI 正在以我們未曾設想的方式，重塑軟件工程的迭代速度與開源生態的底層邏輯。