2026 年 9 月，Anthropic 的程式碼倉庫平均每天合併超過 3 萬筆變更。按一天 86400 秒攤開，不到 3 秒就有一筆新程式碼並進主線，晝夜不停。
就在四個月前，這個數字還是約 2500 筆。四個月漲了 12 倍，一套全世界通用了二十年的工具，就這樣被擠爆了。
這套工具叫 Git。它是程式設計師的「總賬本」：誰在什麼時候改了哪一行、為什麼改，都記在裡面；改壞了可以翻回舊賬，幾個人同時改也能把各自的改動對齊、拼回一本。今天幾乎所有軟體公司都用它管程式碼，Linux 作業系統的核心也靠它維護。
Anthropic 換掉的正是這本賬。擠爆 Git 的不是程式碼太多，而是取程式碼、改程式碼的「人」變了：Anthropic 的倉庫裡，最主要的使用者是永遠線上、成千上萬併發的智慧體。AI 寫程式碼的瓶頸從來不在「寫」，而在寫完之後的取、審、合、測；當智慧體讓一家員工以千計的公司長出谷歌級別的程式碼流量，它只能走谷歌十年前走過的那條路——集中到伺服器，用到哪個檔案才取哪個檔案。
Git 是為一個會斷網的人設計的
Git 誕生於 2005 年，最初就是為了管理 Linux 核心的開發。那是一群分散在世界各地、各自在自己電腦上幹活的志願者，網路不總是可靠，也沒有誰願意把命門交給一台中央伺服器。
於是 Git 選了「去中心化」：每個人電腦上都存一份完整的倉庫，連同從第一天起的全部歷史。斷了網照樣能查舊賬、能提交、能開新分支（分支就是從主線複製出一條岔路，在上面改，改好再並回去）。伺服器只是大家約定碰頭交換改動的地方。
這個設計好用到了家。它撐住了 Linux，撐住了幾乎所有公司，二十年裡沒人覺得需要換。它的每一條預設假設，都站在「一個人、一台電腦、時不時斷網」這個畫面上。
四個月，12 倍：一本量級賬
Anthropic 把全公司的程式碼放在一個大倉庫裡，業內叫單體倉庫（monorepo）。2026 年 10 月 13 日，它的工程部落格公開了這個倉庫這幾個月的數字：
| 專案 | 數字 | 大白話 |
|---|---|---|
| 日均合併的變更 | 5 月約 2500 筆 → 9 月超 3 萬筆 | 四個月約 12 倍 |
| 主分支歷史 | 近 100GB | 從頭到尾的全部舊賬 |
| 一份工作副本（壓縮後） | 超過 25GB | 幹活時要拿到手的那份程式碼 |
| CI 每天檢出次數 | 約 2500 萬次 | CI 是自動構建和測試的流水線；檢出就是把程式碼取出來 |
| 若都按 Git 方式整份拉取 | 每天超過 600PB | 1PB＝1000TB |
| 內部 Git 映象 | 高峰期幾百個 | 為分擔讀取壓力而複製的副本伺服器 |
2500 萬次檢出只算 CI，還沒算開發環境、智慧體的沙箱（隔離起來讓智慧體試跑程式碼的小環境）和研究作業。2500 萬次乘以每次 25GB，約 625PB，和部落格說的「超過 600PB」對得上。
拿谷歌作參照。2016 年，谷歌兩位工程師在《ACM 通訊》上披露：谷歌的單體倉庫約 86TB、20 億行程式碼、900 萬個原始檔；約 2.5 萬名開發者每個工作日提交約 1.6 萬筆改動，自動化系統再提交約 2.4 萬筆。
兩邊口徑不完全一樣——一邊是日均合併，一邊是工作日提交。但量級已經站到了一起：Anthropic 9 月的日均合併量，約是當年谷歌每個工作日人機合計 4 萬筆的四分之三，接近谷歌當年人工提交量的兩倍。
謎底：不是倉庫太大，是取程式碼的人變了
奇怪的地方在這裡。Anthropic 的全部歷史近 100GB，谷歌當年是 86TB，差了近千倍。論體積，Anthropic 的倉庫遠沒大到壓垮 Git。
壓垮 Git 的是「取」。Git 的邏輯是每個使用者各拿一份完整副本，使用者一多，就得多架映象分流。Anthropic 高峰期維護了幾百個內部 Git 映象，可一旦倉庫超出單台映象的磁碟或記憶體，加機器也救不回來。合併越頻繁，映象的快照離最新的主線就越遠；在只拉一部分資料的「部分克隆」（partial clone）上，查改動差異（diff）、查某行程式碼是誰寫的（blame）也越來越難。
600PB 是什麼分量？相當於每天把谷歌 2016 年披露的整個倉庫搬運近 7000 遍。
問題的根子在 Git 預設的那個使用者畫像。Anthropic 的部落格把話說得很直：Git 假設客戶端離線、各持完整副本，而這裡幾乎所有客戶端都是永遠線上的智慧體和自動任務，「Git 的設計在跟擴容作對」。Simon Willison 轉述過一位 Scion 工程師的解釋：沒優先做離線支援，是因為最重的使用者是 Claude，而 Claude 從不下線。
| Git 的預設假設 | Anthropic 倉庫裡的現實 |
|---|---|
| 使用者會斷網，所以每人帶一份完整副本 | 使用者幾乎全是永遠線上的智慧體和自動任務 |
| 整份拉下來再幹活 | 歷史近 100GB、工作副本超 25GB，整份拉不動 |
| 提交、合併、查歷史都在自己電腦上做 | 這些活最好放到伺服器上集中做 |
| 分支隨手開，各管各的 | 每一個分支都是需要全域性同步的狀態，本身就是擴容難題 |
| 一個人一天提交幾次 | 日均超 3 萬筆合併 |
集中、按需、服務端：Scion 怎麼取代 Git
谷歌比 Anthropic 早撞上這堵牆。它自建的系統叫 Piper，資料分佈在全球 10 個資料中心，用 Paxos 協議（一種讓多台伺服器對同一件事達成一致的演算法）保持同步。工程師日常幹活用的 CitC 則走「按需」路線：程式碼看上去全在，實際只有改動過的檔案存在本地，平均一份工作區不到 10 個檔案。
Anthropic 的 Scion 走的是同一個方向，只是更徹底。它定下六條原則：
- 客戶端始終線上：不預先囤資料，要用才取。
- 客戶端和伺服器分工不對稱：查歷史、查 blame、提交、合併、變基（把一串改動挪到最新主線後面重放）都在伺服器上做。
- 完整的原始碼控制介面：不用在本地放倉庫，就能程式化地做自動二分排查（bisect，逐步對半縮小範圍找出是哪次改動引入了故障）和自動回滾。
- 一切都能橫向加機器：任何地方都沒有完整的倉庫副本，也沒有 packfile（Git 把大量物件打成的壓縮包）需要維護。
- 提交便宜、增量、無鎖：全在服務端完成，不用 push；除了主分支和釋出分支，不鼓勵開分支，因為全域性狀態本身就是擴容難題。
- 工作副本可有可無、只取區域性：檢出是虛擬的，讀到哪個檔案才真正寫到硬碟上。
拆開看，Scion 裡一次改動叫 changeset（變更集），就是一本只追加、不改寫的流水賬裡的一行，只記相對上一個版本改了哪些檔案，外加指向檔案內容的指標。把主分支往前挪一步，等於在谷歌雲的分散式資料庫 Spanner 裡對一行資料做一次「比較再交換」：確認它還是剛才看到的值，才換成新值，幾筆合併同時到達也不會互相覆蓋。
取程式碼的路徑分四級：機器上的命令列客戶端 scn，先問同一台機器上的 scion-daemon，再問所在區域的 scion-cache，最後才問權威的 scion-server，後者從 Spanner 或雲端儲存裡讀資料。
結果是每一級快取命中率都超過 99%，基礎設施的 CPU 和記憶體佔用約為舊 Git 映象的 1/200；CI 和研究作業取程式碼從幾分鐘降到幾秒，快了兩個數量級；僅 CI 一項就省出 25% 的 CPU 容量。
Simon Willison 的評價是，這是集中式版本控制的一次迴歸，有點像 Git 之前流行過的 Subversion。鐘擺擺了二十年，擺回了起點；推它回來的，是一群從不下線的使用者。
寫程式碼已經是最便宜的一環
Scion 本身就是這套新工作方式的樣品。7 個人，5 個月，造出 Scion、程式碼審查工具 Antique 和另外約六個相關係統（程式碼搜尋、原始碼控制的許可權系統等），還完成了整個倉庫的遷移。大部分程式碼是 Claude 寫的，一些最佳化也是它找到的，比如繞開一個缺失的索引、修正查祖先版本的演算法。
早期測試裡還有一幕：內部的 Claude Mythos Preview 快照在沒有額外指令的情況下，重寫了把 Git 歷史匯入 Scion 的管道，記憶體降到原來的 1/20，速度快了 4 倍。
程式碼寫得這麼快，卡點就挪到了下游。把一次變更從寫到上線的鏈條攤開：
| 環節 | 為人設計的老辦法 | Anthropic 現在的做法 | 卡點 |
|---|---|---|---|
| 寫 | 工程師敲程式碼 | 大部分由 Claude 寫 | 已不是瓶頸 |
| 取程式碼 | 每人本地一份完整副本 | 按需取檔案，CI 一天檢出約 2500 萬次 | Git 映象擴不動，整份拉取每天超 600PB |
| 審 | 人逐行讀 | 人看意圖；Antique 區分「只改註釋」和「動了敏感邏輯」等審批語義；大量用 AI 做對抗式審查 | 人的注意力；對抗式審查容易短視、過度設防 |
| 合 | 合併佇列加全域性鎖，一筆一筆排隊 | 不設全域性鎖，衝突交給 Claude 修 | 併發衝突，但 Claude 修衝突通常比人發現衝突還快 |
| 測 | 合併前把關 | 加大合併後、部署前的自動測試 | 測試吞吐 |
| 盯執行 | 值班工程師 | Claude 當「鐵桿粉絲」盯 scion-daemon、scion-cache、合併佇列等元件 | — |
人在這條鏈上的位置變了。每一個變更請求仍有人審，但審的重點從「這一行寫得對不對」變成「這次改動想幹什麼、該不該幹」。工程師最要緊的活，是在 Claude 越界時說「不」：有個系統本該去問程式碼審查工具，Claude 卻讓它逐條掃描整本提交日誌；對抗式審查過度防禦，加了太多多餘的校驗——這些都要人攔下來。
這把鑰匙只配一把鎖
Anthropic 自己劃了邊界。Scion 不是 Git 的通用替代品，只對超大單體倉庫有意義；而且 Anthropic 內部的 token 預算異常充裕，能讓 Claude 這樣大手大腳地寫、審、修。這些工具都是定製的，不打算對外發布，只分享思路：建議 Git 託管平台增加服務端的呼叫介面，讓 Git 已有的稀疏檢出（sparse，只取部分目錄）和淺克隆（shallow，只取最近的歷史）能更好地搭配使用。
大多數公司離日均 3 萬筆合併還很遠，Git 對它們依然夠用。
為人設計的那一半工具鏈
真正在變的，是那一半為人設計的東西。程式碼託管、程式碼審查、CI 平台，過去二十年的產品邏輯都建立在「一個工程師、一次提交、一次人工審閱」的節奏上。Anthropic 的這次改造說明，當主要使用者換成智慧體，這些環節的設計假設都要重新過一遍：資料是本地囤還是現取，審批是逐行看還是看意圖，合併是排隊還是併發。
這股流量也不只在 Anthropic 內部。Claude Code 在 2026 年 2 月的年化收入已超過 25 億美元，過半來自企業客戶；Anthropic 的託管智慧體平台 10 月上線的「動態工作流」，單次最多可並行跑 1000 個智慧體。外面的公司遲早也會碰到同一個問題，只是早晚和輕重不同。對關注這條產業鏈的人，值得盯的方向是：程式碼託管和 CI 平台會不會補上服務端介面、按需檢出這些能力，以及誰先把「給智慧體用的版本控制」做成產品。
二十年前，Git 押注每個程式設計師都該帶著一整本賬去流浪。如今在 Anthropic，翻賬最勤的那位從不出門，它只需要伺服器一直亮著。