AI 寫程式碼的速度徹底擊垮了 Git，Anthropic 重新設計了版本控制系統
五個月時間，7 個人從零自研了一套全新的版本控制系統 Scion，並完成了整個主程式碼庫的遷移。
起因只有一個：人類工具在 AI 提交面前失效了。
今年 5 月，Anthropic 每天合併的程式碼變更大約是 2500 次。
到了 9 月，這個數字突破了 30000 次。
程式碼合併頻率暴漲超過十倍。
現在 Anthropic 內部寫程式碼早已不再是瓶頸，Claude 可以自主迭代研究閉環、微調複雜程式、憑空搭起全新服務。
真正的瓶頸變成了原本為人類開發者設計的基礎設施：程式碼版本控制、建置系統和 CI 流程。
每天吃掉 600PB 流量，Git 被活活撐死
Anthropic 使用的程式碼管理模式是超大型單體儲存庫（Monorepo）。
主分支的歷史紀錄接近 100GB，壓縮後的工作副本超過 25GB。
為了支援密集的 CI 自動化測試、研究任務和智慧代理沙箱，他們每天要執行大約 2500 萬次程式碼簽出（checkout）。
如果直接用 Git 硬扛，每天產生的網路流量會超過 600PB。
Git 的核心邏輯是去中心化。每個本機複本都是完整儲存庫，具備離線查看歷史、計算差異、執行 blame 的一切能力。
這種模式適合人類在離線環境下工作。
但在 Anthropic，幾乎所有客戶端都是永遠在線的 AI 智慧代理和自動化任務。
為了替 Git 續命，他們嘗試過所有業界常規方案：淺層複製、稀疏簽出、物件儲存快照，甚至在內網部署了幾百個 Git 鏡像節點。
鏡像越來越多，機器記憶體和磁碟開始頂不住。快照更新的速度跟不上程式碼合併的速度，只要做一次依賴歷史紀錄的 diff 或 blame，整個局部複本就會頻繁報錯。
Git 的去中心化特性，反倒成了規模擴張的最大障礙。
全新系統 Scion：終結本機儲存庫
Anthropic 推翻了 Git 的基本假設，按照代理永遠在線的前提設計了 Scion。
這套系統的核心邏輯發生了根本改變：
客戶端不存完整複本
Git 要求客戶端擁有完整的儲存庫處理能力。
Scion 把所有運算全推給伺服器端。歷史查詢、行變更定位、程式碼合併、變基（rebase）全在伺服器端跑完。客戶端只負責維護一個有限的本機物件快取，把檔案擺在磁碟上，其餘資料隨用隨取。
變更集（Changeset）代替樹狀指標
Git 每次提交都要保存對整棵目錄樹的指標。
Scion 最小的工作單元是變更集。它只記錄當前變動相對於父節點的修改檔案清單，以及指向雲端儲存中壓縮檔案內容的指標。
沒有壓縮包打包流程，沒有跨伺服器協調鎖。建立提交不再依賴分支指標，修改分支只需要在 Spanner 資料庫裡執行一次單列 CAS 操作。
按需載入，無需全域拉取
在 Scion 裡，工作區（Working copy）變成了可選項。
CI 跑自動化任務如果只需要看某次提交的 diff，直接透過 API 向伺服器端要結果，不需要在本機機器上下載完整儲存庫。
就算需要把檔案落到本機磁碟，Scion 也採用了虛擬化和稀疏簽出機制，任務讀到哪個檔案，底層才拉取哪個檔案。
階層快取徹底消滅流量
在具體架構上，本機客戶端 scn 只和本機的 scion-daemon 通訊。
daemon 向區域快取伺服器 scion-cache 請求資料，最後才回退到核心的 scion-server 和資料庫。
每一層都實現了超過 99% 的快取命中率。
這套架構落地後，Anthropic 程式碼簽出速度從幾分鐘縮短到了幾秒鐘。
支撐底層運轉的伺服器 CPU 和記憶體占用，縮減到了原來 Git 鏡像叢集的兩百分之一。僅在 CI 環節，就省出了 25% 的 CPU 運算資源。
用 Claude 製造替代 Git 的武器
整套系統的開發過程，本身也是 AI 寫程式碼能力的試驗場。
完成整個系統研發、替換掉 Git、同時順帶自研了程式碼審查平台 Antique 和程式碼搜尋等半打系統的團隊，只有 7 個人。
7 個人，5 個月。
最典型的例子是資料遷移流水線。團隊最初純手寫了一版從 Git 到 Scion 的資料擷取管道原型。
隨後他們拿到了 Claude Mythos 預覽版的內部權限，直接讓模型去重寫。
在沒有任何額外提示詞的情況下，Claude 重寫出的版本記憶體占用減少到原來的二十分之一，執行速度提升了 4 倍，原有的資料結構和擷取順序規則完好無損。
參與專案的工程師表示，在寫程式碼這件事情上，Claude 現在的水準已經超越了他們自己。
工程師的核心工作型態徹底變了：
工程師的主要任務是向 Claude 說不。
AI 為了滿足局部需求，會本能地嘗試破壞系統的底層限制。例如多個自動化任務曾試圖透過一行行硬讀 commit 日誌來確認程式碼何時合併到主分支，這種做法會瞬間拖垮效能，需要人類把它糾正為直接呼叫審查系統。
還有程式碼對抗審查機制。AI 在審查程式碼時容易過度防禦，憑空塞進大量毫無必要的驗證邏輯，把系統搞得極其複雜。
人類工程師現在的工作，是在更高維度把控跨系統設計的權衡，審核每次提交的意圖，不再逐行肉眼挑毛病。
傳統工作流瓦解：沒有合併佇列，AI 在 Slack 裡當網管
隨著代理規模爆發，更多傳統的研發習慣被砸得粉碎。
傳統的合併佇列（Merge Queue）失效了。
當每分鐘都有海量程式碼並行合併時，全域加鎖排隊會讓整個 CI 系統癱瘓。
Anthropic 取消了全域合併鎖，改成程式碼先合入、在部署前跑自動化回歸測試。
這意味著程式碼衝突出現的機率大幅增加。但是他們發現，Claude 自動解決衝突的速度，比人類看懂衝突發生在哪裡還要快。
維運模式也變了。團隊利用 Claude Tag 在內部 Slack 裡建了一批元件監視頻道。
每個頻道裡都進駐了一個專門的 Claude 實例，官方稱它們為超級粉絲（superfans）。
有的 Claude 專門盯著 scion-daemon，有的專門盯著 scion-cache，有的專門盯合併佇列。
這些 AI 擁有完整的日誌和監控指標權限，每天不知疲倦地刷新後台圖表，捕捉那些傳統靜態告警規則根本無法識別的微小異常。
Git 真的要被淘汰了嗎？
Anthropic 並沒有把 Scion 開源替換 Git 的打算。
他們承認，Scion 的設計完全綁定了極度龐大的單體儲存庫、海量 AI 代理並行寫程式，以及遠超普通企業承受極限的 Token 消耗量。
對於絕大多數普通開發場景，Git 依然是極其優秀的版本控制工具。
Anthropic 判斷，隨著 AI 寫程式工具的擴散，在接下來的 6 到 12 個月裡，其他依賴 AI 寫程式碼的團隊也會陸續撞上這堵牆。
他們公開這套方案，是為了給開源社群、GitHub 和 GitLab 提供思路：Git 的伺服器端完全可以重新設計，導入更高效的 RPC 查詢機制和更靈活的協商協定，沒必要完全沿用幾十年前為人類手寫程式碼設定的規則。
當 AI 寫程式碼的速度呈指數級上升，軟體工程領域所有原本為人類肉身打的補丁，都得重新推倒重來。
source：
https://www.anthropic.com/engineering/redesigning-source-control