編按：本文綜合整理自 Anthropic 工程部落格原文、Simon Willison 摘錄、Meta 工程團隊 Sapling 開源公告，並加入 Siami 編輯部觀點與分析。
Anthropic 在 2026 年 10 月 13 日公開了一篇工程長文，揭示他們如何用五個月時間，把公司整個 monorepo 從 git 遷移到一套名為 Scion 的自製版本控制系統。直接驅動這次搬家的原因是 Claude：自從 Claude Mythos Preview 與 Claude Tag 在公司內部上線後，AI 寫程式碼的速度衝破 git 的天花板，五個月內日均合併量從 2,500 次暴增到 30,000 次以上。
從 2,500 到 30,000：Claude 把 git 推到極限
在 Anthropic 內部，「寫程式」已經不再是瓶頸。Claude 能自主跑研究迴圈、微優化複雜程式、從零打造新服務，速度與規模前所未見。瓶頸反而轉到所有為「人類工程師」規模設計的基礎設施——版本控制、build、CI 都成了拖油瓶。
2026 年 5 月：平均每天 2,500 次程式碼合併。 2026 年 9 月：每天合併 30,000 次以上。 團隊預期這個成長曲線短期內不會減緩。
主分支歷史檔逼近 100 GB、壓縮後的工作複本超過 25 GB。每天光是 CI 就要做約 2,500 萬次 checkout，還不含開發環境、agent 沙箱與研究任務。粗暴一點算，等效的 git 流量一天高達 600 PB 以上。
Anthropic 早已動用淺層 clone、稀疏 checkout、promisor remote、內部 git mirror、blob storage 種子等所有常見的 git 大 monorepo 撇步——巔峰時期跑著數百個內部 mirror。但隨著合併速率持續飆升，mirror 越來越難維護：種子越來越落後於 main tip、依賴歷史的 diff 與 blame 在 partial clone 上越來越難運作。
為什麼這件事重要
這不是「Anthropic 嫌 git 難用」的故事，而是 AI 編碼時代開發基礎設施斷裂的第一個公開案例。
過去十年業界對「大型 monorepo」的最佳解方，是 Google Piper 與 Meta Sapling 兩條路線。Anthropic 的 Scion 並非憑空發明，而是把這兩條既有路線整合到「agent 永遠在線、合併速率比人類時代高一個量級」這個新約束下重新設計。這代表：
- 程式碼不再是稀有資源。當合併速率從日 2,500 跳到 30,000，整個軟體供應鏈——code review、CI、release management、security audit——的單位成本都必須重新算。
- 「人類 reviewer 讀每行 code」這個假設開始破功。Scion 團隊在文章裡承認：「工程師的角色越來越常是對 Claude 說『不』」，review 焦點從「讀每行」變成「讀意圖」。這對未來招募、考核、職涯路徑都是深層衝擊。
- 整套「為人類設計」的工具鏈即將集體重寫。版本控制只是第一張骨牌；merge queue 在 agent 規模下變得沒有意義、CI 在測試還在跑時就有數百個 commit 落地、release 流程需要全自動化的 post-merge 與 pre-deploy 測試。
如果未來六到十二個月內其他重度使用 AI 編碼的公司碰到同樣壓力，Anthropic 這篇文章就成了公開教材。
為 agent 規模重新設計：Scion 的六條鐵律
Anthropic 團隊把 Scion 設計的核心原則攤成六條，每一條都是對 git 中心化假設的反叛：
- 客戶端永遠在線：放棄 git「離線也能做事」的預設，client 設計成伺服器隨時可達、要用才拉。
- 客戶端—伺服器不對稱：伺服器負責歷史查詢、blame、commit、merge、rebase；客戶端只負責 bounded 本地快取、鋪工作目錄、監聽檔案變化。客戶端運算能力被刻意閹割，換來資料本地需求大幅縮減。
- 版本控制服務化，能驅動新型工具：所有 git 用 client 端 repo 才能回答的問題（誰改過這行、兩個 commit 怎麼關聯），Scion 全部用 API 曝露。CI、自動 bisect、自動 revert pipeline 都可以完全不持有本地 repo。
- 一切橫向可擴展：沒有任何一處有「完整一份 repo」。資料分散儲存、每個元件獨立 scale、不需要 packfile，因此不需要 repo 維護工作。
- Commit 必須便宜、增量、無鎖：每次 commit、rebase、merge 都在伺服器端發生；運算成本必須隨改動大小 scale，而非 repo 整體大小。
- 工作目錄可有可無、預設稀疏：CI 想算某 commit 與其 merge base 的 diff？直接問 server 拿。Sparse checkout 只包含 client 要求的目錄；virtualized checkout 隨用隨下載。
怎麼做出來的：Scion 的資料結構與擴展架構
資料結構：以 changeset 為核心 + 衍生資料
git 的最小單位是「完整檔案快照」，Scion 改成 changeset——只記錄「改變了什麼」。一個 changeset 本身沒辦法回答「誰最後改過這行」「哪些 commit 動過這個檔案」，所以 Scion 在 changeset 之上蓋了多層 derived data（衍生資料）：檔案 blame、path history、commit 圖的 skip list 等等。
所有衍生資料都用遞迴方式定義——一個 changeset 的衍生值，由它的 parent 衍生值計算得來。這帶來三個好處：
- 想加新型衍生資料很容易，新結構能直接加速某個操作
- 每種衍生資料可以選擇 eager 或 lazy 計算，不會浪費算力在不需要的東西上
- client 永遠看不到內部結構，server 端可以持續優化而不用更動 client 介面
擴展架構：scn client → scion-daemon → scion-cache → scion-server
Scion 用三層快取撐起橫向擴展：
- scn client：跟 git 不一樣，不做 server 端協商——只表達「我想要哪些 tree 與 blob」，遞迴抓取。任何快取都能回答，架構像傳統分層快取
- scion-daemon：跑在每個 node 上，存整個 node 共用的物件；從週期性更新的 snapshot 啟動
- scion-cache：區域級快取伺服器，直接從記憶體串流物件到 daemon 用的磁碟格式，省下算 missing object 與 delta 壓縮的成本
- scion-server：權威源，缺什麼才從 Spanner 或雲端儲存拉
每一層快取命中率都超過 99%，且不需長期保存狀態。實測結果：基礎設施 CPU 與記憶體用量只有原本 git mirror 的 1/200，CI 與研究任務的 checkout 速度快了 兩個數量級（秒級 vs 分鐘級），CI 本身回收了 25% 的 CPU 容量。
數據解讀與質疑
看起來很猛，但魔鬼藏在細節裡。
- 「2,500 → 30,000」這個倍數是真的，但分母是 Anthropic 自家怪物用量。他們在文章裡老實承認：自家可用 token 預算「遠超任何其他企業會想花的程度」，這個前提是拿來「同時解決自家開發需求 + 順便壓力測試 Claude 能力」。對一般公司而言，這條路徑不見得能複製。
- 「7 人 5 個月」是品牌行銷話術，也是 AI 能力展示。一支 7 人團隊打造出一套 VCS + 程式碼審查工具 + 程式碼搜尋 + IAM 並完成全公司遷移，傳統上要花多年與更多人力。文章不迴避這一點——他們直接說這正是 Claude Mythos Preview 的能力展示：把第一版手寫的 ingestion pipeline 丟給 Claude，零指示就拿到「記憶體少 20 倍、速度快 4 倍」的重寫版。
- 「人類 reviewer 從讀每行變成讀意圖」這句話值得停下來想。Anthropic 自己也說：「agent 為了滿足某個 pattern，會違反系統核心限制」、「對抗式 review 容易過度工程」。換言之，AI 寫得快但容易跑偏，必須靠資深工程師在迴圈裡「告訴 Claude 不」。這對職場新鮮人是壞消息——能爬到「判斷 trade-off」層級的機會正在快速集中。
- 不會有開源版，至少短期內不會。Scion 偏離 git 太遠、需要的配套（code review、code search、CI）太 bespoke。文章直接寫：「打造一個試圖取悅所有人的公開版，不會真的好用。」所以這套系統短期內只是 Anthropic 內部 demo 場，不是產業解方。
對生態系真正的訊號：Anthropic 呼籲 GitHub、GitLab 與開源社群一起討論「git client 端不需要改，但 git server 端可以重寫成類似 Scion 的 RPC 介面」這條路。換言之，他們希望主流平台借鏡 Scion 而非讓 Scion 變成 git 殺手。
給業界的訊號：六到十二個月後會發生什麼
Anthropic 對未來的預測很明確：未來六到十二個月，會有更多公司撞上同樣的牆。當其他重度使用 AI 編碼的組織也發現 git mirror 撐不住、淺層 clone 撐不住、CI 流量撐不住時，業界需要的是：
- git server 端可以重新設計，不必照 client 端的玩法走
- forge 之間的標準化 RPC，讓 git client 可以跟不同後端對話
- 稀疏與淺層特性要能乾淨地組合，而不是各做各的
這對 GitHub、GitLab 與開源社群是清楚的工作清單。Anthropic 自家不會開源 Scion，但他們把思考攤開來，是給整個生態系的禮物。
致謝與後記
原文由 Nick G. 與 Scion 團隊共同撰寫：S.G.、R.K.、Dan C.、Garrett H.、Ben L.、Colin M.、Joe P.。Antique（程式碼審查工具）的早期貢獻者為 Amir O.。Vilas J. 與 Sergiu D. 在整個過程中提供支援。
原文附註：把 merge 後變更的檔案相對於 first parent 儲存是風格選擇；在 trunk-based development 的 monorepo 實務裡，人們通常只在意主線上的歷史與 blame。
網友熱門留言 (5)