Anthropic釋出了一套名為Scion的原始碼控制系統，並已在內部單體倉庫中用Scion取代了Git。這套系統由一個7人團隊在5個月內構建完成，同期還搭建了程式碼審查平台Antique以及另外六個相關係統，並完成了全部遷移工作。

Anthropic做這件事的直接原因是內部程式碼產量的爆發式增長。2026年5月，其內部平均每天合併約2500處程式碼變更；到9月，日均合併量已突破3萬筆，四個月暴漲12倍，且這一勢頭短期內沒有放緩跡象。研究人員發現，每消除一個瓶頸，程式碼產量就會立即進一步增加，程式碼合併的潛在需求幾乎無限。

問題的根源在於，Claude如今能夠自主迭代研究流程、對複雜程式做精細化最佳化，甚至從零搭建全新服務，其執行速度與規模前所未有。真正的瓶頸不再是模型能力，而是原本面向人類開發者打造的基礎設施——版本控制、構建流程與持續整合（CI）——正不堪重負。

Git長期以來是現代軟體工程的事實標準，絕大多數團隊用它管理程式碼、留存變更歷史、多人協同。但Anthropic的單體倉庫規模已遠超其設計預期：僅主分支歷史記錄就接近100GB，壓縮後的工作副本超過25GB。不包括開發環境、代理沙箱和研究任務，Anthropic每天仍需在CI環境中執行約2500萬次程式碼檢出，粗略估算每天Git流量超過600PB。為應對負載，其在峰值時期維護了幾百個內部Git映象，但運維壓力隨合併量上漲而持續加大。

Anthropic研究人員注意到一個關鍵矛盾：多數公司只是把Git當作集中式系統使用，只維護一個權威倉庫，而絕大多數訪問方其實是始終線上的智慧體和自動化任務。Git那些為分散式離線工作設計的特性，反而成了倉庫擴容的阻礙。於是他們開始設想：如果從頭設計一套原始碼控制系統，原生就以智慧體永遠線上為前提，會是什麼樣？

Scion在幾個核心原則上與Git截然不同。客戶端始終線上，圍繞一個始終可訪問的伺服器設計協議，而非預設離線工作並持有完整副本；客戶端與伺服器高度不對稱，伺服器負責回答檔案歷史與blame查詢、建立提交、執行合併和變基，客戶端只維護有界本地物件快取；所有原始碼控制查詢通過API公開，許多作業根本不需要原生代碼庫；倉庫資料分散式儲存，每個元件可獨立擴充套件，伺服器上也沒有倉庫的完整例項；提交、變基或合併都在伺服器端進行，成本與變更大小成正比而非與倉庫整體大小成正比；工作副本可選，協議以稀疏檢出和按需例項化檔案的虛擬化檢出為核心。

效能資料方面，Scion每一層都保持超過99%的快取命中率，且不需要長期狀態。就CPU和記憶體需求而言，Scion基礎設施佔用空間僅為Git映象基礎設施的1/200。CI和研究作業檢出程式碼的速度提高了兩個數量級，從幾分鐘縮短到幾秒鐘；僅CI一項就實現了25%的CPU容量提升。客戶端和快取都不需要執行程式碼庫維護，作業生命週期管理得以簡化。

Scion的工作單元是“變更集”（changeset），它是預寫式日誌中的一個條目，儲存相對於第一個父級發生更改的檔案列表及指向Blob儲存的指標，在伺服器端建立並可立即在任何位置訪問。這種架構支援極高吞吐地接收變更集，無需處理打包檔案、加鎖或跨服務協同。變更集本身無法快速回答“誰最後編輯了某一行”之類的問題，Scion為此構建了額外的“派生資料”結構，遞迴定義、可即時或延遲計算，且客戶端永遠看不到內部細節，研究人員可在不更改客戶端的情況下最佳化。

值得一提的是，在構建Scion過程中，Claude Mythos Preview的早期內部快照版本重寫了Git到Scion的資料匯入管道，在沒有任何進一步指示的情況下，生成了一個記憶體佔用減少至1/20、速度提升4倍的版本，同時保留了所有關於資料匯入順序和資料結構的隱式不變性。

Anthropic特別強調，Scion絕非Git的通用替代品。它只適用於真正龐大的單體倉庫——要麼有數萬名工程師，要麼有大量智慧體在高效編寫程式碼。由於很多元件需要根據公司情況高度定製，Anthropic不會推出通用的Scion版本，只是向業界提供一種思路。

從產業視角看，這條訊息的意義超出一次內部工具替換。當程式設計主體從人類開發者變為7×24小時線上、高頻批次迭代的AI智慧體，版本控制只是第一個被重新設計的環節。構建系統、快取排程、程式碼評審、測試沙箱、許可權審計等環節，都可能需要適配AI的併發模式。Anthropic的做法借鑑了谷歌Piper和Meta Sapling等大型單體倉庫的成熟技術，也說明超大規模程式碼庫的工程經驗正在從少數巨頭向更廣範圍擴散。對關注AI產業鏈的讀者而言，這提供了一個觀察視窗：AI程式設計能力的提升，正在倒逼整個軟體研發工具鏈重構，而這類基礎設施的改造需求，可能成為下一階段工程軟體與雲基礎設施投入的一個方向。