Anthropic 自研 Git 替代方案：當程式碼量超出人工審查

當為人類步調打造的工具遇上機器步調

根據 Simon Willison 對這項變化的紀錄，Anthropic 已經自行打造了一套 Git 的替代方案。觸發原因既不是 bug，也不是資安事件，而是量體。落入公司程式碼庫的變更速度急遽攀升，到了 2026 年 5 月，平均每個週期約有 2,500 次請求，這樣的負載是傳統版本控制在設計之初從未打算承擔的。

人們很容易把這件事歸到內部工具的範疇就帶過，但那樣就錯了。Git 是有史以來最重要的軟體之一，它建立在關於程式碼如何變更的一整套假設之上，而這些假設如今在實務中正被打破。

Git 賴以建立的假設

Git 的設計內建了一種對人類行為的信念：變更以一個人能看的速度到來；一個分支代表一種能持續到足以被命名的意圖；歷史彌足珍貴，所以什麼都不會被丟棄；維護者能讀完一份 diff，在合併之前形成判斷。

當代理開始寫程式碼，這些假設每一條都在鬆動。

代理不會疲倦，因此它們持續產出變更，而不是以一個工作日為單位成批交付。它們不會把一種意圖維持好幾天，因此分支的生命週期短到替它命名本身就是負擔。它們產生的 diff 遠超過人類審查者能真正讀懂的量，這意味著 Git 整個工作流程所圍繞的審查環節，從一道保障變成了一個瓶頸。

結果就是：一個遠在設計邊界之外運作的系統，而所有人都堅持說一切沒變。儲存庫照常可用，但它周遭的流程已經不再代表過去那些意義。

真正最先崩掉的是什麼

最直覺的擔憂是儲存空間，結果它反倒是最不成問題的。磁碟很便宜，Git 的壓縮也做得很好。

第一個真正的犧牲者是審查。一個由代理產生、diff 有 4,000 行的 pull request，理論上可審查，實際上不可審查。審查者會做出人類在過載時一貫的反應：快速略過、信任摘要、核准。審查作為一種儀式存活了下來，卻丟掉了它的功能，而這比直接取消更糟，因為儀式會製造虛假的信心。

第二個犧牲者是身分。Git 的歷史記錄了誰在何時決定了什麼。當大多數提交的作者是回應提示詞的模型時，歷史裡仍然有名字，但這些名字已無法回答歷史本應回答的問題。你沒辦法去問一個代理六週前為什麼選擇某種做法，因為它不記得，而那條提交訊息正是由做出該選擇的同一個系統產生的。

第三個犧牲者是分支本身。在 Git 裡開分支很便宜，但在人的注意力上很昂貴。如果分支的增長速度快過任何人能顧及的速度，你就會積壓下一堆無人持有的意圖，這和合併衝突是另一種失敗，也更難被看見。

為什麼替代方案不只是更快的 Git

如果問題只是吞吐量，那解法就是換一台更快的伺服器。Anthropic 選擇另起爐灶，說明問題出在結構上。

一套為機器步調的變更而最佳化的版本控制系統，會在一些具體方面長得不一樣。它會假設大多數變更是短暫的，建立要便宜、丟棄也要便宜。它會把 diff 當作摘要而非最終產物，並為每個變更附加機器可讀的意圖，好讓代理日後無須讀程式碼就能找到它。它會為檢索而生，而不是為考古而生。

它還需要回答一個 Git 從來不必回答的問題。Git 假設有價值的產物是程式碼的最終狀態。而在代理驅動的工作流程裡，有價值的產物常常是產生某個變更的推理過程，以及驗證它的那些檢查。如果這些內容存放在版本控制之外，那麼版本控制就只記錄了歷史的一半。

平時沒人想起、需要時才發現的紀錄

版本控制不只是歸檔系統，它是計費、法規遵循與事件應變的底層支撐。稽核人員想知道誰在何時改了什麼；受監管的產業想要一份經得起審查、站得住腳的紀錄；資安團隊從提交裡重建時間軸。

如果這些問題的誠實答案變成「某個代理做的，在一個已經不存在的分支上，而推理過程停留在一個早已被丟棄的上下文視窗裡」，那麼紀錄上就出現了一個洞。紀錄上的洞恰恰是稽核生來就要找出的東西，而一個會在無人察覺的情況下製造這種洞的工具，遠在成為醜聞之前就已經是嚴重問題。

更廣泛的訊號

感受到這種壓力的不只 Anthropic，同一個故事的縮小版在其他地方也已浮現。GitHub 最近重做了它的儲存庫 star 歷史 API，讓趨勢資料用 24 次請求就能回傳，而不是大約 2,500 次，同時既不需要無邊界的資料庫工作，也不會暴露個別 star 使用者。GitHub 還推出了一個具備上下文感知的金鑰偵測分類器，把真實發現的接受率提高了 11.5%，同時把掃描時間中位數削減了 86%。

兩者回應的是同一種底層狀況：世界上的程式碼量在上升，而那些在人類是唯一作者的時代造出來的工具，正開始顯出老態。金鑰偵測是個很好的例子。憑證外洩的風險隨程式碼書寫量而放大，所以一套在人類產出速率下夠用的系統，到了代理產出速率下就不再夠用，即使它的設計一點沒變。

沒人願意大聲說出來的那一部分

這個故事有一個版本是：AI 讓軟體團隊的生產力大幅提升，工具也跟了上來，大家都沒事。

還有另一個版本：生成程式碼的量成長超出了人類理解它的能力，產業最終留下一堆沒有哪一個人能完整讀懂的儲存庫，靠沒人寫過的測試和沒人執行過的審查勉強維繫。這個版本的前兆不是崩潰，而是一種緩慢的漂移：程式碼庫照常運作，而真正理解其中緣由的人越來越少。

從這個角度看，替換 Git 是一個值得注意的症狀。它意味著業界最謹慎的公司之一認定，那件標準工具恰恰在追蹤正確性的那一層變成了負債。這不是一個小表態。它是一個訊號：軟體的基礎設施正被要求以快過其假設所能跟上的速度改變。

對其他所有人來說，務實的應對並不浪漫：衡量你的程式碼裡有多少是機器寫的；觀察你的審查環節是否還能改變任何東西；留意你的歷史是否還能回答「為什麼」。這些問題成本很低，而答案會告訴你，你需要的是新工具，還是僅僅一個新習慣。