爆破GitHub倉庫、“偷”開發(fā)者余額，Anthropic一夜成硅谷大惡人

就在前天，一場堪稱AI行業(yè)“核彈級”的烏龍事件，徹底打破了硅谷大模型圈的平靜。明星AI獨角獸Anthropic旗下的核心產(chǎn)品——Claude Code（AI編程助手），竟然因為一次極低級的打包錯誤，將其最核心的51萬行源代碼直接“開源”到了公共網(wǎng)絡(luò)上。

不過，這還僅僅是開始，更搞笑的是Anthropic在事發(fā)后的“搶救”措施：為了能夠?qū)⒆约旱脑创a從Github上下架，他們啟動了DMCA（數(shù)字千年版權(quán)法）投訴工具，結(jié)果變成了“無差別攻擊”，直接導(dǎo)致數(shù)千個合法的、無辜的GitHub開發(fā)者倉庫被連坐誤刪。

科技圈常說“技術(shù)無罪”，但當(dāng)頂級的AI公司也開始頻頻翻車時，我們不得不重新思考一個問題：在這個越發(fā)依賴AI的時代，我們是否應(yīng)該將整個AI系統(tǒng)的安全，寄托在少數(shù)幾個人或者企業(yè)的身上？

不止源代碼泄露！多個BUG被曝光

說實話，在一開始知道Claude Code源代碼泄露后，雷科技（ID：leitech）以為是哪個神通廣大的黑客把Anthropic的服務(wù)器攻破了，結(jié)果在詳細了解后才發(fā)現(xiàn)，這純粹就是一次“低級錯誤”。

根據(jù)Anthropic官方的公告，此次泄露事件發(fā)生在2026年3月31日。當(dāng)時，Anthropic在npm代碼庫中推送了Claude-code 的 v2.1.88 版本更新。在此次更新中，Anthropic使用了前段時間收購的Oven公司開發(fā)的Bun工具，該工具在運行時錯誤地將一個完整的JavaScript source map 文件（通常用于內(nèi)部調(diào)試，包含了完整的原始未混淆代碼映射）一同打包發(fā)布了出去。

圖源：Claude

這一“手滑”，直接導(dǎo)致Claude Code內(nèi)部近2000個源代碼文件、超過51.2萬行的專有 TypeScript 源代碼直接暴露，所有人都可以查看、復(fù)制和使用。

更尷尬的是，泄露的代碼中還暴露了Anthropic的一些“小心思”。比如，代碼中包含了一個名為“Undercover Mode（臥底模式）”的系統(tǒng)設(shè)定，該設(shè)定的內(nèi)部指令要求AI在參與開源社區(qū)代碼貢獻時，必須“隱藏自己是AI的身份”，并禁止使用常規(guī)的“Co-Authored-By: AI”標(biāo)簽。

這種為了繞過開源社區(qū)人類開發(fā)者審查而設(shè)計的隱蔽機制，直接引發(fā)了開發(fā)者社區(qū)關(guān)于頂級AI公司隱藏身份參與項目維護的爭論。畢竟真要說的話這多少有些不道德，你技術(shù)再強也不應(yīng)該無視別人的社區(qū)規(guī)定，更何況從泄露的代碼來看還是“全自動執(zhí)行”的。

除此之外，還有一個更讓開發(fā)者惱火的BUG，該BUG是開發(fā)者對泄露代碼檢查時發(fā)現(xiàn)的，它會導(dǎo)致Claude Code在恢復(fù)會話時錯誤地出現(xiàn)“緩存未命中”的問題。

簡單來說，這個BUG會導(dǎo)致Claude Code把你之前已經(jīng)花Token執(zhí)行和推理過的問題，全部再計算一遍。要知道，全量推理和緩存命中之間的Token價格可是差了10倍，你原本打算在接下來10天使用的Token余額，可能會在1天內(nèi)就消耗殆盡。

圖源：雷科技

這個BUG被曝光后，不少開發(fā)者就馬上吐槽說：“怪不得我覺得客戶端的Token消耗比網(wǎng)頁版快得多，原來真有問題”。而且在對BUG進行回溯后，開發(fā)者發(fā)現(xiàn)這個BUG早在v2.1.69版本中就存在，直到因為源碼泄露被查證后，Anthropic才在后續(xù)發(fā)布的2.1.90版本上修復(fù)。

那么問題來了，Anthropic到底知不知道BUG的存在呢？這就是個耐人尋味的問題了。因為后續(xù)開發(fā)者們還發(fā)現(xiàn)一個問題，那就是Claude Code 會在系統(tǒng)提示詞的第一塊中強行插入一個名為 x-anthropic-billing-header 的字符串。

這個字符串會導(dǎo)致每一個新開啟的對話，系統(tǒng)提示詞前綴都是唯一且不同的。也就是說，即使你的提示詞都是一樣的，Claude Code也會進行一次全量寫入，消耗更多的Token，以至于現(xiàn)在不少開發(fā)者都對Anthropic產(chǎn)生了懷疑：這貨不會在偷偷地坑我們錢吧？

只能說，這次代碼泄露對于開發(fā)者來說基本沒啥壞事，甚至可以說都是“好事”。只是Anthropic就頭疼了，當(dāng)然，讓他們更頭疼的事情還在后面。

Anthropic維權(quán)“無差別轟炸”惹怒開發(fā)者

面對這種戰(zhàn)略級知識產(chǎn)權(quán)的“大出血”，Anthropic的反應(yīng)可謂是“病急亂投醫(yī)”的典范。

在代碼泄露的數(shù)小時內(nèi)，不少開發(fā)者和安全研究人員已經(jīng)將其下載并鏡像到了GitHub等平臺。部分泄露倉庫的Star數(shù)在極短時間內(nèi)突破數(shù)萬，甚至催生了去除官方安全限制、解鎖實驗性功能的所謂“破解版”。

為了遏制代碼的進一步擴散，Anthropic向GitHub發(fā)起了大規(guī)模的DMCA（數(shù)字千年版權(quán)法）下架要求，然后一場悲劇就這么發(fā)生了。

圖源：雷科技

據(jù)海外網(wǎng)站的知情者透露，Anthropic在執(zhí)行代碼清理時，極度依賴于自動化的代碼比對與舉報腳本。這些自動化工具的識別邏輯過于簡單粗暴：只要在代碼庫或README說明文件中檢測到包含泄露代碼的片段或特定關(guān)鍵詞，該倉庫就會被直接判定為“侵權(quán)”。

這種缺乏人工“合理性檢查”的自動化維權(quán)，直接演變成了一場大規(guī)模的GitHub倉庫爆破行動。GitHub方面的初期報告顯示，在短短一小時內(nèi)他們就處理了涵蓋超過8000個倉庫網(wǎng)絡(luò)的DMCA通知。

數(shù)千個合法開源項目，就因為撞上了自動化腳本的“槍口”而被封禁或強制刪除。其中大多數(shù)都是基于 Anthropic 官方公開 API 開發(fā)的開源項目，甚至還有 Anthropic 官方自己的部分公共示例庫派生版也被意外屏蔽，屬于是大水沖了龍王廟。

面對這樣的無差別轟炸，眾多受害者在社交媒體和論壇上發(fā)起了強烈的抗議，指責(zé)Anthropic這種“先斬后奏”的粗暴手段是濫用版權(quán)法，不僅給無辜開發(fā)者帶來了嚴(yán)重的代碼丟失風(fēng)險和業(yè)務(wù)停滯，更是嚴(yán)重損害了開源生態(tài)的基石。

圖源：雷科技

面對洶涌的輿情和大規(guī)模的誤傷，Anthropic不得不再次做出緊急回應(yīng)，與GitHub溝通并撤回了大部分的DMCA通知（縮減至幾十個確切的鏡像分支），并承認自己的做法有欠妥當(dāng)，后續(xù)將加強對相關(guān)流程的審核與管理。

不過，此次事件的影響還遠不止于此。網(wǎng)絡(luò)安全機構(gòu)Zscaler ThreatLabz的報告顯示，黑客組織已經(jīng)開始利用開發(fā)者的好奇心，在GitHub上發(fā)布偽裝成“Claude Code泄露版”的惡意倉庫，實則內(nèi)置了Vidar和Ghostsocks等竊密軟件。善后處理估計還要不少時間。

AI翻車不是第一次，也不是最后一次

在雷科技（ID：leitech）看來，Anthropic這次大翻車，說白了還是“對自動化工具和AI腳本的盲目信任”（雖然人類闖的禍也不少）。事實上，在整個科技與商業(yè)領(lǐng)域，因為過度迷信AI和自動化系統(tǒng)、減少甚至完全取消人工復(fù)核而導(dǎo)致企業(yè)損失慘重的事件，早已屢見不鮮。

舉個最近的例子，年初爆火的OpenClaw在3月22日上線了一個號稱“史上最強”的版本更新，并且自豪地宣布該版本的核心引擎95%以上的代碼由AI完成。然后，AI在干活時覺得之前的AI與人類合作寫的代碼過于低效，于是自行決定廢棄舊有的Skill API標(biāo)準(zhǔn)，重新編寫了一套它認為更高效的新API。

于是，OpenClaw最引以為傲的一萬多個Skill就這么全部被廢棄了，如果想繼續(xù)使用就要基于新的API做新的調(diào)用和優(yōu)化。由于其本就以全自動化運行著稱，很多部署了OpenClaw的企業(yè)一覺醒來，就發(fā)現(xiàn)自己的工具全部罷工，只因OpenClaw自動更新了版本并執(zhí)行了相關(guān)操作，導(dǎo)致所有Skill直接失效。

圖源：雷科技

不止如此，OpenClaw的AI在編程時還為了“高效”，私自關(guān)閉了多個關(guān)鍵的沙箱隔離權(quán)限，導(dǎo)致新版本存在更嚴(yán)重的安全問題。看到這里你可能會想，那我們回滾到上個版本不就好了？問題就在這里，AI重構(gòu)后的數(shù)據(jù)庫與舊版本不兼容，用戶想回滾的話就要面臨數(shù)據(jù)損壞的風(fēng)險。

雖然后續(xù)OpenClaw發(fā)布了一個新的兼容層，但也只能挽回部分損失，以至于不少用戶都跑路到了以“更嚴(yán)格的人工審核”著稱的Claude Code（沒錯，就是今天這篇文章的主角）。結(jié)果沒過多久Claude Code也暴雷了。好在這次與生產(chǎn)力無關(guān)，虧的只是Anthropic。

這次事件后，多數(shù)主流開源社區(qū)都發(fā)布了關(guān)于AI生成代碼的相關(guān)準(zhǔn)則與規(guī)定，強制要求所有基于AI的提交都必須經(jīng)過人工審核，并且配備自動化回歸測試模塊。

還有亞馬遜，從去年12月開始到今年的3月就已經(jīng)爆了兩次大雷。一次是AWS工程師在使用其自研的Kiro AI編程智能體時，“不小心”直接刪除并重建了整個生產(chǎn)環(huán)境，導(dǎo)致AWS成本管理服務(wù)在部分區(qū)域遭遇13小時的中斷。

第二次則是工程師在處理緊急部署需求時，由于過分相信AI助手給出的建議，導(dǎo)致亞馬遜主站的核心結(jié)賬邏輯與物流預(yù)測系統(tǒng)發(fā)生沖突。據(jù)后續(xù)統(tǒng)計，有12.5萬個訂單直接丟失，還有超過600萬個訂單因此延誤或出錯。

圖源：雷科技

事后亞馬遜查明，問題根源在于AI錯誤引用了一份過時的內(nèi)部文檔，導(dǎo)致部署代碼與現(xiàn)有系統(tǒng)產(chǎn)生嚴(yán)重沖突，最終引發(fā)系統(tǒng)宕機。事實證明，即使有人類在一旁監(jiān)督管理，如果其本身過分相信AI的話，結(jié)果并不會因此有所改變。

一連串的問題最終也讓不少人開始思考：我們到底該如何管理和使用AI的這份能力呢？

解鈴還須系鈴人，AI問題AI治？

面對這一連串因為“盲信AI”而導(dǎo)致的史詩級災(zāi)難，一個悖論就擺在了整個科技圈面前：隨著AI的代碼生成能力越來越強、邏輯推演越來越復(fù)雜，人類開發(fā)者審查AI操作的成本正在呈指數(shù)級上升。

既然人類已經(jīng)快要看不懂、也審不過來AI生成的海量代碼與指令了，那么AI惹出的麻煩，最后難道只能靠更強大的AI來解決嗎？在雷科技（ID：leitech）看來，答案既是肯定的，也是否定的。

首先從現(xiàn)實工作的角度來看，引入AI審查是必然的。“AI監(jiān)督AI”也是目前大多數(shù)頭部科技企業(yè)的做法之一：通過多個AI智能體的交叉驗證后，再把疑似有問題的代碼提交給人類工程師進行最后的復(fù)核，這樣就能降低AI幻覺導(dǎo)致的誤判問題出現(xiàn)的概率。

圖源：雷科技

不過，只有這個還是不夠的，因為Anthropic、亞馬遜等企業(yè)的教訓(xùn)告訴我們，即使有人工復(fù)核，問題一樣可能出現(xiàn)。所以更重要的是加入多道防火墻，比如嚴(yán)格遵守“最小特權(quán)原則”，對AI絕不能開放過多的權(quán)限，避免它在無人干預(yù)的情況下自行修改核心數(shù)據(jù)庫和生產(chǎn)環(huán)境。

此外，最好是加入由獨立系統(tǒng)負責(zé)的“熔斷機制”，當(dāng)系統(tǒng)監(jiān)測到異常且大量的高危指令時，直接暫停所有指令的執(zhí)行，并立即通知人類工程師對指令進行復(fù)核。如果Anthropic在大范圍投訴GitHub倉庫侵權(quán)時有類似的機制（比如請求投訴超50個倉庫后需要人工確認），估計后續(xù)的問題也就不會出現(xiàn)了。

最后，還是需要把責(zé)任落實到人的身上。作為AI的使用者與管理者，不能用一句“都是AI干的”來撇清責(zé)任，這樣至少能讓人類工程師在使用AI的時候，保持謹慎且小心的態(tài)度，避免因為過于信任AI而翻車的情況出現(xiàn)。

雷科技（ID：leitech）認為，AI雖然以顛覆性的方式重塑了我們的生產(chǎn)力，但是人類才是真正的主導(dǎo)者，這一點是不會變的。