前言
代理寫程式的速度太快，版本控制先撐不住。Anthropic 在五個月內用自研系統 Scion 取代 git，同期每日合併量從 2,500 筆飆到超過 30,000 筆。以下先附一頁懶人包，再附原文全文翻譯與 HN 討論整理。
懶人包
手機版若看不到內嵌頁面，可直接開啟：https://derek-static.pages.dev/anthropic-scion-lazy.html
原文翻譯：在 Anthropic 重新設計版本控制
原文：https://www.anthropic.com/engineering/redesigning-source-control
在 Anthropic，寫程式碼早已不是做系統或做研究的瓶頸。Claude 能自主迭代研究迴圈、對複雜程式做微觀最佳化、從零開始做新服務，速度與規模前所未見。現在的瓶頸，反而是那些為人類規模而設的開發基礎設施：版本控制、建置與 CI。
2026 年 5 月，Anthropic 平均每天合併約 2,500 筆程式變更；到 9 月，每天合併超過 30,000 筆。我們預期這個成長速度短期內不會放緩；對合併程式碼的潛在需求，幾乎是無限的，每解掉一個瓶頸，產生的程式碼量馬上又再往上跳。
為了支撐這種成長，我們做出自研版本控制系統 Scion，並在五個月內把單一儲存庫從 git 完整遷移過去。同一期間，我們還開發並上線了程式碼審查介面（名為 Antique）、程式碼搜尋、功能完整的版本控制權限系統、管理並落地大量已審查程式碼的新作法等。本文聚焦 Scion 是怎麼做出來的。這是個有趣的案例：Claude 寫程式碼的能力，既是把我們推入這個處境的原因，也是我們能快速做出高品質、可擴展系統的手段。
單一儲存庫的成長
Anthropic 用 Claude 寫軟體的程度遠超幾乎所有其他公司，所以我們總是最先看到為人類規模而設的工具在哪裡開始吃力。版本控制只是其中一例。
Git 是去中心化系統：每個複製都是一份完整、自足的儲存庫，可以離線計算差異、讀取歷史與責任追溯、取出任何版本。對絕大多數儲存庫來說，這是正確的設計，也是 git 成為標準的一大原因。
但隨著單一儲存庫長大，它越來越不適合這個設計空間。光是主分支的歷史就將近 100 GB，壓縮後的工作複本也超過 25 GB。我們每天為 CI 做約 2,500 萬次程式碼取出，還沒算開發者環境、代理沙盒與研究任務。若都用原始方式抓取，相當於每天超過 600 PB 的 git 流量。
Git 有淺複製、稀疏取出、承諾者遠端等處理部分儲存庫的工具，也有內部鏡像與 blob 快照等變通作法，我們全都用過——高峰期營運了數百個內部 git 鏡像。這爭取到時間，但隨著合併速率上升，營運越來越困難。快照在兩次更新之間離主分支尖端越來越遠，要讓依賴歷史的操作在部分複製上正常運作，需要越來越多細心維護。
退一步看，我們其實是把 git 當集中式系統在用，只有一份權威複本，但幾乎所有客戶端都是生來就線上的代理與任務。讓 git 擅長分散式、離線工作的那些特性，反而在儲存庫變大時拖累擴展能力。於是我們自問：如果從一開始就假設代理永遠線上來設計版本控制，會長什麼樣子？
代理規模版本控制的六項原則
第一，客戶端永遠線上。幾乎所有客戶端都是代理與任務，把客戶端與協定設計成伺服器永遠可達，需要資料時再去抓。
第二，客戶端與伺服器不對稱。伺服器負責回答檔案歷史與責任追溯問題、建立提交、執行合併與變基等。客戶端只維護有限的本地物件快取、把工作複本檔案鋪到磁碟、監控檔案系統變化。它自己幾乎算不了什麼，但本地需要的資料少得多。
第三，功能完整的版本控制服務能驅動許多新應用。客戶端用的所有版本控制查詢都同時以 API 暴露，很多任務根本不需要本地儲存庫。沒有這種廉價、可程式化存取版本控制的手段，內部許多工具在這個規模下根本不可行。
第四，所有東西都必須能水平擴展。儲存庫資料分散存放，每個元件都能獨立擴展；即使在伺服器端，也沒有任何一份完整具現化的儲存庫複本，也沒有相當於打包檔的東西，所以不需要儲存庫維護工作。
第五，提交必須廉價、增量、無鎖。每次提交、變基或合併都在伺服器上發生，所以沒有東西要推送，但每個操作都必須快。成本必須隨變更大小擴展，而非隨儲存庫整體大小擴展。開發流程不鼓勵使用分支與標籤這類參照，主參照或發版分支除外，因為每台伺服器都要達成一致，全域狀態是潛在的擴展難題。
第六，工作複本是選配，且生來稀疏。CI 任務若只需要某個提交與其合併基準點的差異，直接問伺服器即可。協定以稀疏取出為中心，只包含客戶端要求的目錄，以及按需具現化檔案的虛擬化取出，客戶端只為實際讀到的東西付費。
Scion 如何運作
在 Scion，工作單位是變更集，即寫入前日誌中的一筆。git 提交存的，是指向樹的指標，變更集存的，是相對第一個父節點的變更檔案清單，以及指向 blob 儲存中壓縮檔案內容的內容定址指標。變更集在伺服器端建立，一建立就隨處可用。這種結構讓系統能以極高吞吐量接受變更集，因為沒有打包檔要接收、沒有鎖定或跨伺服器協調、也沒有參照要搬動。
變更集只記錄變更了什麼，光靠它無法快速回答某一行最後是誰改的。為此，Scion 從變更集再建出額外資料結構，包括專門的檔案責任追溯與路徑歷史結構，以及提交圖的跳表。凡不是變更集本體的，都稱為衍生資料，全部經由同一套通用機制計算。每種衍生資料都是遞迴定義的：某個變更集的值，由其父變更集的值算出來。好處有三：容易新增種類、可選即時或延後計算、客戶端看不到內部實作所以可自由最佳化。
一小組 Scion 伺服器為客戶端需要的任何操作提供 API。所有資料都是內容定址的，存進去就不再變，任何伺服器都能安心快取。客戶端經由 socket 與守護行程對話，由它為整台機器存物件；守護行程從定期更新的快照出發，之後只跟同區域的快取伺服器要東西；快取缺物件時，才去問權威伺服器。三層回應完全相同的 RPC，嚴格分層以隔離故障域。
每一層的快取命中率都超過 99%。基礎設施體積只有先前 git 鏡像的兩百分之一。CI 與研究任務取出程式碼快了兩個數量級，以秒計而非分鐘；光 CI 就省下 25% CPU 容量。
開發 Scion 學到的事
第一，小團隊快速開發會變得更常見。七人團隊在五個月內做出 Scion 與 Antique，外加半打相關系統，並完整遷移過去，而同期每日合併量還成長了十倍。
第二，工程師的價值不減，但工作在改變。參與的工程師現在都認為 Claude 寫程式碼比他們強，但工程師仍提供跨系統高層元件的理解與設計取捨判斷。很常發現，工程師的角色是跟 Claude 說不。團隊成員仍會審查每個變更請求，但現在看的是變更的意圖，而非逐行讀程式碼。
第三，最佳化與品質大幅推升。憑藉 Claude 寫大量程式碼的速度，Scion 是測試與防禦最完備的程式庫之一：密封模擬、模糊測試、精密限流一應俱全。Claude 還隨手找到重大演算法最佳化，那本來要專家花數天到數週分析調校。
第四，為單一儲存庫安全的新形態打下基礎。支援儲存庫層級的豐富存取控制，也能對個別目錄套用權限。程式碼審查工具能表達複雜的語義核准約束，區分單純註解修改，以及敏感的邏輯變更。
第五，新等級的營運卓越成為可能。團隊指派 Claude 緊盯單一元件的健康狀態，稱為超級粉絲。它們能看遙測與日誌，像個沒別的事、只會一直重整圖表找異常的資深工程師，能抓到傳統告警看不見的細微新穎問題。
第六，徹底重想既有假設。正規的合併佇列在代理規模下不太合理：測試還在跑的同時就有數百甚至數千筆變更合併。團隊轉而投資合併後與部署前的自動化測試。併發變更可能衝突，但 Claude 修衝突的速度，通常比人類找出衝突還快。
回饋生態系
Scion 絕不是一般用途的 git 替代品。這裡談的概念，只對真正巨大的單一儲存庫有意義。實務上很難把 Scion 做成對其他組織廣泛有用的形態：與 git 差異極大，內部工具高度客製。
不過，團隊預期這類問題在未來六到十二個月會更常見。他們認為最有影響力的事是分享思路，讓其他開發者能把 Scion 最成功的部分套用到 git：git 伺服器不必跟 git 客戶端同一種作法，新穎的伺服器架構，確實能顯著提升擴展能力，平台可以提供功能完整的伺服器端 RPC，協商協定也不必長得跟今天一樣。最後，他們肯定 git 社群花了近二十年為數百萬開發者擴展平台，期望與 GitHub、GitLab 及開源社群合作。
HN 網友怎麼看
本次討論串共 13 則留言，風向分三派。
| 帳號 | 觀點 |
|---|---|
| steveklabnik | 大實驗室背書集中式回歸，順勢推廣自家 git 相容橋 |
| trnvll | 自家模型優勢恐怖，用次級模型競爭的公司會被甩開 |
| jcims | 數 Claude Code 發版說明的條列點數，對照本文圖表 |
| amelius 等四人 | 提案把提示詞當原始程式碼提交，追問規格驅動開發、可重現性存疑 |
| JohnMakin | 批評怪 git 用法滲進模型訓練，害外部代理操作走鐘 |
| mijoharas | 酸：這不就是重發明 SVN |
| willmeyers | 類比大型遊戲與 3D 資產版控 |
| memonkey | 抱怨文件，要一部淺顯的解說影片 |
| jsrozner | 歪樓：拿 iPhone 重複拍攝類比代理狂產程式碼 |
三個值得帶走的點：集中式回歸是共識，超大單體儲存庫加永遠線上客戶端，繞一圈回到類 Piper 架構並不意外；最有火藥味的是模型行為汙染指控，把技術文跟模型訓練掛鉤；提示詞即原始程式碼分支正反合，可對照提交必須廉價增量的脈絡。