Anthropic 於 10 月 13 日發布工程回顧，揭露公司花了五個月，把整個單一程式碼庫（monorepo）從 git 遷到自行研發的版本控制系統 Scion，同一期間還做了一套程式碼審查工具 Antique。核心團隊只有 7 個人。
起因是程式碼合併量。2026 年 5 月，Anthropic 的 monorepo 每日平均合併約 2,500 次；到了 9 月，這個數字已超過 3 萬次。回顧中寫道：
“As our merges per day grew more than tenfold, source control became our biggest development bottleneck.”
每日合併量成長了十倍以上，原始碼管理成了我們最大的開發瓶頸。
寫程式本身已不再是瓶頸，卡住的是原始碼管理、建置與 CI。
git 撐不住的地方
Anthropic 列出幾組數據：主幹歷史接近 100 GB，壓縮後的工作副本超過 25 GB，CI 每天大約進行 2,500 萬次程式碼檢出。如果每次都老老實實完整拉取，每天的 git 流量將超過 600 PB。尖峰時期公司同時運行數百個內部 git 鏡像，合併一快，鏡像與預置快照就越來越難維護。
回顧指出的根本原因，是設計目標對不上。git 為離線、分散式的人類協作而生，每個人手上都有一份完整儲存庫；而 Anthropic 現在的主要用戶端，是持續在線的代理程式（agent）與自動化任務。
Scion 的思路因此反過來：歷史、blame、提交、合併、變基全部放在伺服器端，用戶端只保留有限的本機快取與工作副本，資料按需取得。提交在伺服器端完成，成本與改動大小有關，與儲存庫總大小無關。分支只保留主幹與發行分支，移動一個分支指標，就是對資料庫中的一筆記錄做一次比較並交換（compare-and-swap）。用戶端依序經過本機常駐程式、分層快取，最後才到伺服器，各層快取命中率都超過 99%。
算一筆帳
拿回顧裡的數字粗算：600 PB 除以 2,500 萬次檢出，每次約 24 GB，與「工作副本超過 25 GB」大致吻合，可見 600 PB 是按「每次完整拉取」估算出的上限。
3 萬次合併分攤到 24 小時，平均每分鐘 20 次出頭。依 git 的推送模型，每次推送前都得先與遠端同步，在這個頻率下，衝突重試會把佇列塞住。Scion 把合併移到伺服器端，省掉了推送這一步；Anthropic 同時放棄了全域合併鎖，改靠合併後、部署前的自動化測試把關，並行改動撞車時交給 Claude 修復。
換來的成果，依公司說法：Scion 基礎設施的 CPU 與記憶體用量比原本的 git 鏡像叢集少約 200 倍；CI 與研究任務的檢出從分鐘級降到秒級；光 CI 一項就空出約 25% 的 CPU 容量。
Claude 在裡面做了什麼
遷移本身也用上了模型。早期手寫的 git 到 Scion 匯入流水線，交給 Claude Mythos Preview 重寫後，記憶體用量降為原來的 1/20，速度快了約 4 倍。回顧稱 Claude 還找出一些演算法層面的最佳化，寫了大量測試、模擬與模糊測試；工程師的工作變成掌握設計意圖、否決不合理的方案，並審查改動的意圖，而不是逐行讀程式碼。
至於 Antique，回顧並未展開細節，只提到它能為審批設定語意規則，把只改註解的提交與動到敏感邏輯的提交區分開來，讓人工審查集中在後者。
Scion 不開源。Anthropic 的說法很直接：“Scion is by no means a suitable replacement for git for general use.” 內部元件客製化程度太高，無法打包給其他公司使用。它希望 GitHub、GitLab 與開源社群借鏡伺服器端 RPC、稀疏檢出這些思路來改進 git。Google 的 Piper、Meta 開源的 Sapling 都走過類似的路，差別在於這次推動重寫的壓力，來自 AI 寫出的程式碼量。
參考來源：CocoLoop、Anthropic 工程部落格；每日合併量、檢出次數、資源用量倍數均為 Anthropic 自行公布的數字，單次檢出體積為編輯依其數字粗略推算。