AI 狂寫碼每天合併三萬次！Anthropic 嫌 Git 太慢自建 Scion 重寫版控規則

標題

每天合併三萬次：Anthropic 棄 Git 自建 Scion，AI 寫碼速度正在重寫版控假設

正文（已通順正確，請做編輯優化）

重點摘要

• 2026 年 5 月至 9 月，Anthropic 每日程式碼合併次數從約 2,500 次暴增至逾 30,000 次，四個月漲幅超過十倍。
• 七人團隊五個月完成遷移，自建集中式版控系統 Scion 與程式碼審查工具 Antique；主分支歷史近 100 GB，CI 每日約 2,500 萬次 checkout，沿用 Git 天真拉取的話每日流量超過 600 PB。
• 對抗性審查在 AI 輔助開發下效率高，但模型易對假想問題過度設計，資深工程師把方向這道關省不掉。

Anthropic 公開了一份工程技術文件，說明過去幾個月他們如何把整個版本控管流程從 Git 遷移到內部自建的集中式系統 Scion，並同步推出程式碼審查工具 Antique。Simon Willison 在 2026 年 10 月 13 日的部落格文章中整理分析這份技術文件，引出了幾個讓規模問題具體化的數字：主分支歷史接近 100 GB，壓縮後的工作副本超過 25 GB；光是 CI 流程每天就需要執行約 2,500 萬次程式碼 checkout。繼續用 Git 天真拉取的話，每日流量換算超過 600 PB。這不是「需要優化一下」的問題，而是設計假設根本不再成立。

AI 寫碼代理人爆發式的提交量打破了 Git 的分散式架構前提，迫使軟體工程基礎設施回歸按需取用的集中式思維。

Scion 和 Antique 解決的是什麼問題？

Git 的核心採分散式設計：每個開發者都有完整的版本庫副本，在本地操作後推到遠端。這個設計在數十人的工程團隊裡幾乎沒有缺點，歷史可追溯、離線可操作、分支成本低。問題在於，當每日合併次數從 2,500 次衝到 30,000 次以上，這個前提開始反噬自己：每個工作副本都要同步近 100 GB 的主分支歷史，壓縮後仍超過 25 GB，乘以每天 2,500 萬次 CI checkout，流量的數學根本算不過去。

Scion 的解法是有意識地走回集中式版控，概念上和 Subversion（SVN）更接近。集中式架構的優點在於用戶端可以按需取用，不需要在本地維護完整歷史；CI agent 只拿當下任務對應的那份快照，流量才壓得下來。Antique 在這個新版控基礎上重建程式碼審查流程。七人團隊從零打到遷移完成，花了五個月。

是什麼讓合併次數四個月漲了十倍以上？

Anthropic 的技術文件沒有直接點出原因，但數字本身很難用人員增長來解釋。Simon Willison 把時間軸疊在 Anthropic 各款模型的公開發布節點上，觀察後推測 Fable 和 Mythos 等級模型的推出，是推動程式碼產出速度暴增的關鍵因素，但他也特別標注這是公開發布日期，不是模型在 Anthropic 內部可用的日期，兩者未必一致。這個方向目前只是 Simon Willison 的推測，Anthropic 官方並未確認。

推測的邏輯是直接的：如果 AI 程式碼代理人的能力在某個門檻之後質變，每個工程師能並行啟動的代理人數量、每個代理人提交 PR 的頻率都可能同步爆升，而且幾乎沒有線性上限。從 2,500 到 30,000，這個倍數靠招人達不到，更可能的解釋是自動化寫碼的比例在這段期間大幅拉高，機器提交的速度不再受人的工作時間限制。

Git 的分散式設計在 agent 洪流下為什麼撐不住？

分散式版控的兩個核心假設是：操作者有能力維護一份本地完整副本，而且有需要反覆用到它。這兩個假設在人類開發者身上大致成立，一台開發機放 25 GB 的工作副本不是大事，開發者也確實會查本地歷史。

AI 程式碼代理人把這兩個假設都打掉了。代理人是無狀態的，跑完一個任務就銷毀容器，下次重新起。讓生命週期只有幾分鐘的代理人在啟動時先拉 25 GB，純粹是浪費。代理人也不需要完整的版本歷史，它需要的只是當下任務對應的那份程式碼狀態。Git 的傳輸模型不是為「大量短命用戶端各自需要一小塊快照」這個場景設計的，而這正是 CI 代理人洪流的日常。集中式版控在這裡反而有結構優勢：伺服器端維護唯一的正規狀態，用戶端按需取用，不需要每個用戶端複製完整歷史。這不是技術退步，純粹是按新的存取模式選擇合適的資料模型。

AI 輔助開發下，adversarial review 的有效邊界在哪裡？

Anthropic 在這份技術文件裡也提到他們大量使用對抗性審查，讓模型互相找漏洞、挑問題。這個做法在許多層面效率極高，但他們同時點出一個實際遇到的限制：模型容易對假想的問題過度設計，把不一定真實存在的風險當成確定要解決的工程課題，把工程師往不必要的複雜度推。他們的結論是，資深工程師的主要工作已經不是寫程式，而是把方向導對、避免 Claude 陷入對假想問題的過度工程。

這個觀察的適用範圍比 Anthropic 自己更廣。自動生成的程式碼量愈多，審查訊號的信噪比就愈低。對抗性審查能在表面層篩掉語法錯誤和邏輯漏洞，但它沒有對系統未來演化方向的感知，因此無法替代對整體架構的判斷。把對抗性審查當成全自動化的品質閘門，而不是人工判斷的加速器，目前看來是最容易踩到的陷阱。

七人團隊花五個月完成遷移，Anthropic 展示的不單是工程案例。Git 被換掉不是因為設計太差，主要是它的設計前提不再成立。當 AI 程式碼代理人的速度推進到某個量級，原本默默支撐整個開發流程的基礎設施假設就會一一失效，版控只是第一個被壓垮的。其他重度使用 AI 程式碼代理人的團隊，遲早面對同樣的問題，只是時間早晚的差異。