Anthropic 每日合併程式碼破 3 萬筆，自建版本控制取代 git
Anthropic 10 月 13 日在工程部落格公開，公司內部每天合併進程式碼庫的變更，從今年 5 月平均約 2,500 筆，增加到 9 月超過 3 萬筆。寫程式不再是瓶頸，卡住的是原本為人類規模設計的開發基礎設施，於是團隊花五個月自建一套版本控制系統 Scion，把整個單一程式碼庫（monorepo）從 git 完全搬走。
Anthropic 在文中說，寫程式的速度已經不是限制，「瓶頸現在是所有為人類規模打造的開發者基礎設施：版本控制、建置與持續整合」。公司也預期這個成長速度短期內不會放緩，每拿掉一個瓶頸，產出的程式碼量就會再往上增加。
主分支歷史近 100 GB，每天簽出 2,500 萬次
根據這篇文章，Anthropic 程式碼庫光是主分支的歷史紀錄就接近 100 GB，壓縮後的工作副本超過 25 GB。持續整合系統每天要簽出程式碼約 2,500 萬次，還不包括開發環境、AI 代理沙盒與研究任務；如果每次都完整抓取，一天的 git 流量會超過 600 PB。
廣告 - 內文未完請往下捲動
Anthropic 說，過去已經用過淺層複製、稀疏簽出、內部 git 鏡像與快照等常見做法，高峰時期維運數百台內部 git 鏡像來分擔負載，但合併速度愈快，這些方法愈難撐住。團隊後來發現，公司其實是把 git 當成集中式系統在用，而幾乎所有使用者都是一直在線的 AI 代理與自動化任務，git 為離線、分散式協作設計的特性反而成了負擔。
伺服器負責運算，客戶端只拿需要的檔案
Scion 的設計前提是客戶端永遠在線。查詢檔案歷史、建立提交、合併與變基都在伺服器端完成，客戶端只保留有上限的本機快取，需要時才向伺服器要檔案。這些查詢也都開放成 API，持續整合任務很多時候根本不需要在本機放一份程式碼庫。Anthropic 表示，設計時參考了 Google 的 Piper 與 Meta 的 Sapling 這兩套大型程式碼庫版本控制系統的經驗。
換上 Scion 後，Anthropic 說各層快取命中率都超過 99%，整套基礎設施的 CPU 與記憶體需求只有先前 git 鏡像架構的 200 分之一。持續整合與研究任務簽出程式碼的時間從幾分鐘縮短到幾秒，光是持續整合就省下 25% 的 CPU 容量。
七人團隊五個月完成，工程師常要對 Claude 說「不」
Anthropic 表示，Scion 與程式碼審查工具 Antique 都由一個七人團隊打造，五個月內完成並全面遷移，期間每天合併量還成長了 10 倍。文章說，過去開發部署這種系統，一家公司通常要多年分階段遷移、投入更多工程師。
文中舉例，團隊年初大致以手寫方式完成 git 轉 Scion 匯入管線的第一版原型，後來交給內部早期版本的 Claude Mythos Preview 重寫，在沒有額外指示的情況下，新版記憶體用量少 20 倍、速度快 4 倍，並保留了原本匯入順序與資料結構的隱含規則。
Anthropic 說，參與的工程師現在都認為 Claude 寫程式比自己好，但工程師仍負責系統層級的設計取捨，而且「工程師的角色很常是對 Claude 說不」。文章舉的例子是，AI 代理有時會為了套用某種模式而違反系統核心限制，例如有好幾個系統想用線性讀取提交紀錄的方式，去查某個變更何時合併進主分支，而不是直接問程式碼審查工具。團隊成員仍會審查每一筆變更請求，但重點從逐行讀程式碼，轉為檢查變更的意圖。
團隊也用 Claude Tag 監看系統，在 Slack 開設頻道，讓 Claude 專注盯著單一元件的健康狀況，內部稱為「超級粉絲」，例如 scion-daemon 超級粉絲、scion-cache 超級粉絲。文章說，這些 Claude 可以讀取遙測資料與日誌，能抓出傳統警報看不到的細微異常。
不打算開源，預期 6 到 12 個月內其他公司也會碰到
Anthropic 強調，Scion 不適合一般用途、也無法直接取代 git，只對工程師數以萬計、或有大量 AI 代理寫程式的超大型程式碼庫有意義。公司也坦言自己內部可以投入的 token 量遠超過一般企業，Scion 又與自家程式碼審查、程式碼搜尋與持續整合工具深度綁定，很難做成其他組織能直接採用的版本。
不過 Anthropic 預期，這類問題會在未來 6 到 12 個月變得普遍，因此選擇公開設計思路，讓其他開發者能把 Scion 的部分做法套用到 git 上，例如讓 git 伺服器提供更完整的伺服器端查詢介面、改寫協商協定。文章最後表示，希望與 GitHub、GitLab 和開源社群合作，因應 AI 代理大量寫程式後的開發需求。
風險提示
加密貨幣投資具有高度風險，其價格可能波動劇烈，您可能損失全部本金。請謹慎評估風險。
