源碼被開源，Claude Code之父回應(yīng)了：純內(nèi)部開發(fā)者手滑

機(jī)器之心編輯部

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

由于工程失誤，Anthropic 在發(fā)布 npm 包時(shí)未剔除 source map 文件，導(dǎo)致完整的 TypeScript 源碼被輕易還原。短短幾個(gè)小時(shí)內(nèi)，代碼已經(jīng)被下載、鏡像，并在 GitHub 上迅速擴(kuò)散。

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

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

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

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

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

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

當(dāng)吃瓜群眾還在圍觀時(shí)，大量開發(fā)者已經(jīng)開始逐行閱讀代碼，嘗試還原頂級 AI Agent 背后的設(shè)計(jì)邏輯。一些原本不對外的系統(tǒng)級策略也隨之曝光。

Claude Code 內(nèi)置了兩套反蒸餾機(jī)制

X 用戶 Sahil 發(fā)現(xiàn)：Anthropic 在 Claude Code 中內(nèi)置了兩套反蒸餾機(jī)制，用于防止競爭對手利用其數(shù)據(jù)進(jìn)行訓(xùn)練。

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

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

Claude Code 源碼可以學(xué)到并復(fù)用的東西

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

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

1：系統(tǒng)提示詞是一門行為控制的范本

完整的 system prompt 位于 constants/prompts.ts，可以說是整個(gè)代碼庫中最有價(jià)值的文件。它清晰展示了 Anthropic 是如何在生產(chǎn)級編碼 Agent 中精確控制 Claude 的行為，以及每一條指令背后的設(shè)計(jì)動(dòng)機(jī)。

三行重復(fù)代碼，也好過過早抽象。在編碼指令部分，系統(tǒng)明確要求 Claude 不要為一次性操作創(chuàng)建 helper、工具函數(shù)或抽象結(jié)構(gòu)，也不要為假想的未來需求做設(shè)計(jì)。

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

如實(shí)報(bào)告結(jié)果。另一個(gè) @[MODEL LAUNCH] 標(biāo)注透露，Capybara v8 的錯(cuò)誤陳述率高達(dá) 29–30%（相比 v4 的 16.7%）。因此，prompt 明確規(guī)定：

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

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

• 工具調(diào)用之間的文本 ≤25 個(gè)詞
• 最終回答 ≤100 個(gè)詞

外部提示詞與內(nèi)部提示詞分層設(shè)計(jì)。對外用戶使用的提示詞是簡潔版，比如：直奔重點(diǎn)，盡量簡短。而內(nèi)部（Anthropic 員工使用）版本則更復(fù)雜。

隱藏的 Simple 模式。當(dāng)設(shè)置環(huán)境變量 CLAUDE_CODE_SIMPLE=1 時(shí)，整個(gè)復(fù)雜的 system prompt 會(huì)被壓縮為一行：「You are Claude Code, Anthropic's official CLI for Claude」，并附帶當(dāng)前工作目錄與日期。

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

2：對 Claude Code 爆粗口，會(huì)被標(biāo)記為負(fù)面輸入

在 utils/userPromptKeywords.ts 這個(gè)僅 26 行的小文件中，系統(tǒng)會(huì)在每條用戶輸入發(fā)送到 API 之前，用兩組正則表達(dá)式檢測用戶臟話粗口。

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

3：Claude Code 里藏了一個(gè)電子寵物

在 src/buddy/ 中，系統(tǒng)通過對用戶 ID 進(jìn)行哈希（基于帶種子的隨機(jī)數(shù)生成器），為每個(gè)用戶生成一個(gè)專屬且固定的虛擬伙伴（代號 Buddy），其物種、外觀和屬性均由算法決定，從而實(shí)現(xiàn)無需存儲(chǔ)的個(gè)性化體驗(yàn)。

這個(gè)哈希值會(huì)進(jìn)一步映射為一整套完整的角色配置，包括：

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

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

4：內(nèi)置 187 個(gè)加載動(dòng)詞

Claude Code 內(nèi)置了 187 個(gè)隨機(jī)動(dòng)詞，在模型思考時(shí)輪流顯示（比如 Beboppin'、Lollygagging 等），用來替代單調(diào)的 Loadind。這些動(dòng)詞古靈精怪的：Accomplishing、Actioning、Actualizing、Architecting、Baking…… 共 187 個(gè)。

而 Cherny 表示這個(gè)詞匯表最早是他搞出來的，并吸收了其他人的一些貢獻(xiàn)。他還進(jìn)一步指出用戶也可以讓 Claude 添加自己想要的動(dòng)詞。

5：反蒸餾機(jī)制：通過注入假工具污染競爭對手訓(xùn)練數(shù)據(jù)

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

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

此外，還有一個(gè) streamlinedTransform.ts，實(shí)現(xiàn)了一種抗蒸餾的輸出格式：

• 去除模型的思考過程（thinking content）
• 將工具調(diào)用簡化為類別統(tǒng)計(jì)（如搜索、讀取、寫入、命令等）

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

6：Prompt 緩存被極致精細(xì)化管理

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

system prompt 被 SYSTEM_PROMPT_DYNAMIC_BOUNDARY 分為兩部分：上半部分是靜態(tài)且可緩存的內(nèi)容，下半部分是動(dòng)態(tài)且隨會(huì)話變化的內(nèi)容。MCP 服務(wù)器相關(guān)指令被從 system prompt 中移除，改為通過 message 的增量附加（delta attachments）傳遞，因?yàn)槿绻旁?system prompt 中，每次有服務(wù)器連接都會(huì)導(dǎo)致緩存失效。

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

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

utils/undercover.ts 中實(shí)現(xiàn)了一種臥底模式。當(dāng) Anthropic 員工（USER_TYPE === 'ant'）在非內(nèi)部倉庫中工作時(shí)，該模式會(huì)自動(dòng)開啟，而且默認(rèn)始終為開啟狀態(tài)。只有當(dāng) git 遠(yuǎn)程倉庫明確匹配內(nèi)部白名單時(shí)，才會(huì)關(guān)閉。

一旦激活，系統(tǒng)提示詞中會(huì)注入一段標(biāo)題為 UNDERCOVER MODE: CRITICAL 的指令，要求 Claude：

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

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

源碼中的注釋寫道：這個(gè)模式?jīng)]有強(qiáng)制關(guān)閉選項(xiàng)。它用于防止模型代號泄露。如果系統(tǒng)無法確認(rèn)當(dāng)前倉庫是內(nèi)部倉庫，就始終保持臥底狀態(tài)。

8：25 萬次被浪費(fèi)的 API 調(diào)用：催生熔斷機(jī)制

自動(dòng)壓縮（auto-compaction）系統(tǒng)中的一段注釋，堪稱整個(gè)代碼庫里最真實(shí)的工程記錄之一：

BQ 2026-03-10：有 1,279 個(gè)會(huì)話在單個(gè)會(huì)話中出現(xiàn)了 50 次以上的連續(xù)失敗（最多達(dá)到 3,272 次），每天在全球范圍內(nèi)浪費(fèi)約 25 萬次 API 調(diào)用。(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.)

最終的解決方案是：設(shè)置 MAX_CONSECUTIVE_AUTOCOMPACT_FAILURES = 3。當(dāng)連續(xù)三次壓縮失敗后，系統(tǒng)將停止繼續(xù)嘗試。

壓縮系統(tǒng)還設(shè)置了一系列關(guān)鍵閾值：

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

9：驗(yàn)證：不給模型自我感覺良好的機(jī)會(huì)

Claude Code 里有一個(gè)很關(guān)鍵的設(shè)計(jì)：寫代碼的 Agent，不能自己說我做完了。

當(dāng)任務(wù)涉及一定復(fù)雜度（比如改了 3 個(gè)以上文件、動(dòng)了后端或基礎(chǔ)設(shè)施），系統(tǒng)會(huì)自動(dòng)拉起一個(gè)獨(dú)立的驗(yàn)證智能體來檢查結(jié)果。

流程很簡單：

• 主 Agent 寫代碼
• 驗(yàn)證 Agent 獨(dú)立檢查
• 主 Agent 還要再抽查驗(yàn)證結(jié)果

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

10：Auto Dream：跨會(huì)話的后臺(tái)記憶整合

services/autoDream/autoDream.ts 實(shí)現(xiàn)了一套后臺(tái)記憶整合機(jī)制。當(dāng)時(shí)間間隔足夠、且累計(jì)了足夠多的會(huì)話后，Claude Code 會(huì)以 fork 出的 subagent 形式運(yùn)行 /dream，回顧歷史會(huì)話內(nèi)容，并將其壓縮整理為結(jié)構(gòu)化的 MEMORY.md 文件。

系統(tǒng)的觸發(fā)流程遵循先便宜后昂貴的判斷順序：首先檢查時(shí)間（是否距離上次整理足夠久），其次檢查會(huì)話數(shù)量（是否積累了足夠的新內(nèi)容），最后檢查鎖（是否已有進(jìn)程在執(zhí)行整理）。執(zhí)行過程中會(huì)加文件鎖，若整理失敗則自動(dòng)回滾。

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

此外，記憶提取不僅在周期性觸發(fā)，也會(huì)在任務(wù)循環(huán)中動(dòng)態(tài)發(fā)生：當(dāng)累計(jì)上下文達(dá)到 10000 tokens 時(shí)首次觸發(fā)，此后每增加 5000 tokens 或發(fā)生 3 次工具調(diào)用，就會(huì)再次觸發(fā)一次整理。

11：2592 行 Bash 安全防護(hù)（共 42 項(xiàng)獨(dú)立檢查）

tools/BashTool/bashSecurity.ts 文件長達(dá) 2592 行，實(shí)現(xiàn)了 42 項(xiàng)不同的安全檢查機(jī)制。

12：排除字符串：構(gòu)建階段的金絲雀機(jī)制（Build-Time Canary）

代碼庫中多處引用了 excluded-strings.txt 文件。這個(gè)文件列出了絕對不能出現(xiàn)在外部構(gòu)建產(chǎn)物中的字符串，包括內(nèi)部代號、API Key 前綴以及其他敏感信息。構(gòu)建系統(tǒng)會(huì)對打包后的輸出進(jìn)行 grep，一旦發(fā)現(xiàn)這些字符串，就會(huì)直接構(gòu)建失敗。

Sebastian Raschka 解讀

知名 AI 技術(shù)博主、《Python 機(jī)器學(xué)習(xí)》作者 Sebastian Raschka 也第一時(shí)間對這批泄露代碼進(jìn)行了梳理與解讀，發(fā)現(xiàn)了一些有趣的小信息。

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

1：Claude Code 會(huì)構(gòu)建實(shí)時(shí)倉庫上下文

這是最直觀的一點(diǎn)：當(dāng)你開始輸入提示時(shí)，Claude 會(huì)自動(dòng)加載主分支、當(dāng)前分支、最近的提交記錄，以及 CLAUDE.md 文件，作為上下文的一部分。

2：激進(jìn)的 Prompt 緩存復(fù)用機(jī)制

似乎存在一種邊界標(biāo)記（boundary marker），用于區(qū)分靜態(tài)內(nèi)容與動(dòng)態(tài)內(nèi)容。這意味著靜態(tài)部分會(huì)被全局緩存，以保證系統(tǒng)穩(wěn)定性，同時(shí)避免每次都重新構(gòu)建和處理這些計(jì)算開銷較高的內(nèi)容。

3：工具體系優(yōu)于上傳文件聊天

提示詞中似乎會(huì)引導(dǎo)模型優(yōu)先使用專門的 Grep 工具，而不是通過 Bash 調(diào)用 grep 或 rg，這很可能是因?yàn)閷Ｓ霉ぞ咴跈?quán)限管理上更安全，同時(shí)在結(jié)果收集與處理上也更加高效。

此外，系統(tǒng)還提供了專門的 Glob 工具用于文件發(fā)現(xiàn)（檢索文件路徑）。更進(jìn)一步，它還集成了 LSP（語言服務(wù)器協(xié)議）工具，用于調(diào)用關(guān)系分析、查找引用等任務(wù)。

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

4：最小化上下文膨脹

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

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

• 文件讀取去重：系統(tǒng)會(huì)檢測文件是否發(fā)生變化，若未變化則不會(huì)重復(fù)處理；
• 大結(jié)果外置：當(dāng)工具輸出結(jié)果過大時(shí)，會(huì)寫入磁盤，而在上下文中僅保留摘要預(yù)覽和文件引用；
• 自動(dòng)上下文管理：與現(xiàn)代 LLM UI 類似，系統(tǒng)會(huì)自動(dòng)截?cái)噙^長上下文，并在必要時(shí)進(jìn)行自動(dòng)壓縮（總結(jié)）。

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

5：結(jié)構(gòu)化會(huì)話記憶

Claude Code 會(huì)為當(dāng)前對話維護(hù)一份結(jié)構(gòu)化的 Markdown 文件，其中包含如下內(nèi)容：

• 會(huì)話標(biāo)題
• 當(dāng)前狀態(tài)
• 任務(wù)描述
• 文件與函數(shù)
• 工作流程
• 錯(cuò)誤與修正
• 代碼庫與系統(tǒng)文檔
• 學(xué)習(xí)與總結(jié)
• 關(guān)鍵結(jié)果
• 工作日志

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

6：使用 Fork 與 Subagents

Claude Code 通過 Subagents 并行處理任務(wù)，這一點(diǎn)其實(shí)并不令人意外。長期以來，這也是它相較于 Codex 的一個(gè)優(yōu)勢（直到 Codex 最近也開始支持子 Agent）。

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

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

當(dāng)然，還有一個(gè)很現(xiàn)實(shí)的因素：所有內(nèi)容都可以在本地有序組織，而不需要反復(fù)將文件上傳到聊天界面。這種工作方式本身，也顯著提升了整體使用體驗(yàn)。

還有網(wǎng)友整理了一份 Claude Code 源碼深度研究報(bào)告，覆蓋整體架構(gòu)、系統(tǒng)提示詞、Agent 提示詞、Skills、Plugins、Hooks、MCP、權(quán)限與工具調(diào)用機(jī)制，以及新增的全量 Prompt 提取框架分析與 Agent 調(diào)度鏈深挖。

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

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

改寫與改進(jìn)版正在涌現(xiàn)

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

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

當(dāng)然，所有人都知道：為時(shí)已晚。

除了成千上萬開發(fā)者已經(jīng)下載到自己本地的版本，這些源代碼也已經(jīng)被上傳到了去中心化平臺(tái)上 ——「永遠(yuǎn)不會(huì)被刪除」。

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

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

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

現(xiàn)如今，這個(gè)上線才十余小時(shí)的庫的 Star 數(shù)已經(jīng)來到了驚人的 6.6 萬并仍在持續(xù)增長中。

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

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

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

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

另外，開源社區(qū)對 Claude Code 的改進(jìn)也已經(jīng)開始！

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

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

我們讓 Gemini 簡單總結(jié)了一下：

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

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

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

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

與此同時(shí)，OpenClaude、Free Code、claw-code 等不同名稱的項(xiàng)目也正如雨后春筍般涌現(xiàn)。

結(jié)語

Claude Code 源碼泄露事件提供了一個(gè)極具觀察價(jià)值的行業(yè)切片。

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

另一方面，社區(qū)在短短 24 小時(shí)內(nèi)的反應(yīng)速度令人驚嘆。

借助 AI 工具，開發(fā)者可以瞬間解構(gòu)、翻譯并重構(gòu) 51 萬行的復(fù)雜系統(tǒng)。當(dāng)代碼重構(gòu)的時(shí)間成本被壓縮到極致，傳統(tǒng)的軟件著作權(quán)邊界變得模糊不清。

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