當 AI 寫程式的速度超過人，連版本控制都撐不住。Anthropic 乾脆自己做一套叫 Scion 的系統，把整個大型程式庫從 git 搬了過去。
Anthropic 自建 Scion：把 git 換掉的那套系統
Anthropic 在工程部落格說明，團隊打造了一套自家版本控制系統 Scion，並在五個月內，把整個大型程式庫從 git 完整遷移過去。這不是要取代 git 的通用計畫，而是被逼出來的解法。
導火線是 AI 寫程式的產量。Anthropic 說，2026 年 5 月時，每天平均約有 2,500 筆程式變更合併進主線。到了 9 月，這個數字衝破 30,000 筆。合併量在四個月內成長超過十倍，原本為人類規模設計的工具鏈開始吃不消。
合併量從 2,500 暴增到 30,000
Anthropic 的處境很特別。它用自家 Claude 寫程式的比例遠高於其他公司，所以往往是最早撞上「為人類規模設計的工具開始失靈」的那一家。版本控制只是其中一個例子。
問題出在哪？Anthropic 說，主線歷史本身已接近 100 GB，壓縮後的工作副本超過 25 GB。光是 CI 每天就要做約 2,500 萬次程式碼取出，還不包含開發環境、代理沙箱與研究任務。如果照 git 原本的方式抓資料，一天的流量會超過 600 PB。
為了撐住，Anthropic 一度同時運行數百個內部 git 鏡像，但合併率越高，這些變通做法越難維護。於是團隊回頭問了一個問題：如果從一開始就假設「代理永遠在線」，版本控制該長什麼樣子？
Scion 跟 git 的設計差在哪
git 的強項是分散式。每個複本都是完整、自給自足的程式庫，可以離線算差異、讀歷史、取用任何版本。對絕大多數專案來說，這是對的設計，也是 git 成為標準的原因。
但 Anthropic 發現，絕大多數用戶端其實都是代理與任務，這些東西本來就隨時在線。git 為了離線工作而犧牲的那部分，反倒成了規模化的阻礙。Scion 因此採取不同原則：用戶端永遠在線，資料需要時再向伺服器取；伺服器負責回覆檔案歷史、建立提交、執行合併與重訂基底；用戶端只維持有限的本機快取。這套思路參考了 Google 的 Piper 與 Meta 的 Sapling。
不只版本控制：Antique 與配套工具
Scion 不是單一元件。Anthropic 在同一段時間還做了代碼審查介面 Antique、代碼搜尋、完整的版本控制 IAM 系統，以及管理與落地大量已審代碼的新做法。
換句話說，這是一整套為「代理大量寫程式」重寫的開發基礎設施，而不只是換掉一個 git。團隊規模很小，Anthropic 說前後只動用了七名工程師。
為什麼這件事值得關注
對多數開發團隊來說，短期內不會遇到這種問題。Anthropic 自己講得很直白：Scion 完全不是 git 的通用替代品，這些設計只有在「超級大型程式庫、且有數萬名工程師或大量代理不斷寫程式」的情境下才說得通。它甚至明說不會開源。
但這個案例真正的價值在於預告。當企業導入 AI 寫程式工具，產量拉高之後，第一個卡住的往往不是模型，而是為人類節奏打造的周邊設施，像是版本控制、建置、CI。Anthropic 說，它預期不久後，其他用 AI 寫程式的團隊也會陸續撞上同樣的壓力點，這也是它願意公開分享的原因。
Scion 目前只在 Anthropic 內部使用，HN 上也有不少討論與質疑。接下來值得觀察的是，這類「代理原生」的開發工具會不會被其他廠商跟進，以及當 AI 產量繼續往上衝，版本控制之後的下一個瓶頸會出現在哪裡。
