Anthropic 宣布已從 Git 完全遷移至內部開發的版本控制系統 Scion，以應對由 Claude 驅動的高頻程式碼合併需求。隨著 AI 編碼能力增強，Anthropic 的每日合併次數從 2026 年 5 月的約 2,500 次飆升至 9 月的超過 30,000 次，且預期增長不會放緩。傳統 Git 架構因假設客戶端離線工作且需完整倉庫副本，無法負荷此規模：Anthropic 主分支歷史接近 100 GB，壓縮後工作副本超過 25 GB，每日需進行約 2,500 萬次程式碼檢出，若直接抓取將產生每日超過 600 PB 的流量。為解決此瓶頸，Anthropic 在 5 個月內完成遷移，並同步開發了代碼審查介面 Antique、代碼搜尋及權限管理系統。
Scion 的設計基於「客戶端始終在線」與「客戶端-伺服器不對稱」原則，假設使用者多為線上代理與自動化任務。與 Git 不同，Scion 將提交、合併與歷史查詢等重負載操作移至伺服器端，客戶端僅維護有限本地快取並按需獲取數據。系統採用「Changeset」作為工作單元，僅記錄相對於父提交的變更檔案列表及內容指標，而非完整樹狀結構，從而實現高吞吐量與無鎖操作。Scion 透過水平擴展的伺服器群集提供 API 服務，數據內容定址（Content-addressed）使得任何伺服器皆可快取數據而無需協調，消除了 Git 的 Packfiles 維護需求。此外，Scion 支援稀疏檢出與虛擬化檢出，允許 CI 任務僅透過 API 查詢差異或歷史，無需本地倉庫副本。根據 Anthropic 披露，Scion 的基礎設施佔用比之前的 Git 鏡像基礎設施小 200 倍（以 CPU 和記憶體需求計算），CI 和研究任務的程式碼檢出速度快兩個數量級（從分鐘級降至秒級），且 CI 單獨實現了 25% 的 CPU 容量節省。
Anthropic 強調，Scion 並非 Git 的通用替代品，其概念僅適用於擁有數萬工程師或大量代理編碼的極端規模 Monorepo。由於 Anthropic 內部組件高度客製化，且其內部 Token 消耗能力遠超一般企業，其他組織難以直接採用其內部解決方案。Anthropic 認為此類問題將在未來 6 至 12 個月內變得普遍，並建議其他開發者參考 Scion 的成功部分來改進 Git 架構，而非直接遷移。
事件背景
Git 作為去中心化版本控制系統，其設計假設每個克隆都是完整且可離線運作的倉庫，這在大多數場景下是標準做法。然而，隨著單倉庫（Monorepo）規模擴大，Git 的離線假設與完整副本需求成為擴展瓶頸。業界已有類似解決方案，如 Google 的 Piper 和 Meta 的 Sapling，它們針對超大規模倉庫進行了集中式或混合式架構調整。Anthropic 指出，雖然目前僅少數組織面臨此極端負載，但隨著 AI 編碼工具普及，類似壓力點將逐漸浮現。
社群觀察
社群討論聚焦於 AI 對開發基礎設施與人力角色的影響。East River Source Control 創辦人 Steve Klabnik 表示 Anthropic 的舉措驗證了他們關於「後 Git 時代」的觀點，並提供兼容層以協助企業過渡。用戶 trnvll 分享案例，指出使用 Claude Mythos Preview 重寫數據攝取管線後，記憶體消耗降低 20 倍且速度提升 4 倍，顯示 AI 在基礎設施優化上的潛力。用戶 jcims 透過比較 Claude Code 發布說明中的變更數量與 Anthropic 合併圖表，指出兩者趨勢一致。用戶 piker 質疑在大量 AI 生成程式碼的情況下，Anthropic 人類開發者的角色是否將被取代或面臨裁員。用戶 kburman 則認為 AI 降低了自訂工具開發成本，將引發更多輪子重造現象，但維護自訂軟體的成本是否同樣低廉仍有待觀察。
