AI 版本控制：Anthropic 每天合併 3 萬次程式碼後，為何放棄 Git 自建 Scion
Git 不必換，但 AI agent（能自己動手改程式的 AI 程式）改程式前，要先定好記錄、隔離、審核、復原四件事。Anthropic 是因為 agent 把合併（把改好的程式碼正式併進主線版本）推到每天超過 3 萬次，Git 越來越難維運，才自建系統。
Anthropic 在 2026 年 10 月 13 日發表官方工程文章，公開他們用五個月自建版本控制系統 Scion，把整個主程式庫從 Git 搬走。版本控制，白話說就是記錄每一次程式修改、能隨時回到任何舊版本的系統。本文寫於 10 月 15 日，整理官方說法、隔天冒出的設計來源爭議，以及台灣老闆可以直接拿去用的判斷。
Anthropic 為什麼要自己重做版本控制？
因為 AI 寫程式的速度把合併量推高超過十倍，版本控制成了 Anthropic 開發流程裡最大的瓶頸。官方的說法很直接：寫程式已經不卡了，卡住的是為人類規模設計的開發基礎設施，包括版本控制、建置與 CI（持續整合，每次改動自動跑測試與建置的流程）。
根據 Anthropic 官方工程文章，2026 年 5 月他們平均每天合併約 2,500 次程式變更；到了 9 月，每日合併次數已經超過 30,000 次。從 5 月到 9 月，成長超過十倍。
官方也寫明，合併需求幾乎沒有上限，每拿掉一個瓶頸，產出的程式碼就立刻再往上加，他們不認為這個成長會很快放緩。
同一段時間裡，Anthropic 還做出了程式碼審查介面 Antique、程式碼搜尋、版本控制的權限管理系統，以及大量落地已審程式碼的新做法。官方特別點出一個反差：Claude 寫程式的能力，既是把他們推進這個處境的原因，也是他們能在五個月內做出高品質系統的原因。
Git 到底哪裡不夠用？
Git 的設計假設每個人都在自己電腦上離線工作，所以每份複本都帶著完整歷史。當使用者幾乎全換成隨時在線的 AI agent 與自動化工作，這個優點反過來變成拖垮效能的負擔。
先解釋一個詞：monorepo，指一家公司把所有程式碼放在同一個巨型程式庫裡。Anthropic 的 monorepo 規模如下，數字皆出自官方文章：主分支（分支 branch 是程式碼的一條獨立開發線，主分支就是正式版本那一條）的歷史將近 100 GB，壓縮後的工作複本超過 25 GB。
光是 CI 每天就要做約 2,500 萬次 checkout，也就是把某個版本的程式碼取到機器上。這還沒算開發環境、agent 沙箱（sandbox，讓 agent 在隔離環境裡執行、碰不到正式系統的工作空間）與研究工作。如果照 Git 的預設方式抓資料，每日 git 流量（照預設抓法換算）會超過 600 PB（1 PB＝1,000 TB）。這是換算出來的假設值，用來說明預設抓法的規模，並非實際流量。
Anthropic 把業界標準解法都用過了：淺層複製（shallow clone，只抓最近的歷史）、稀疏取出（sparse checkout，只抓需要的資料夾）、內部鏡像站、放在雲端儲存的程式庫快照。高峰期他們同時維運好幾百台內部 git 鏡像。
這些方法替他們爭取了時間，但合併速度越快越難維持。快照跟主線最新版本的距離越拉越遠，要讓 diff（比對兩版差異）和 blame（查每一行是誰、何時改的）在部分複本上正常運作，也越來越費工。
最關鍵的觀察是：Anthropic 跟多數公司一樣，實際上把 Git 當成集中式系統在用，只認一份權威版本；而它的客戶端幾乎都是本來就在線的 agent 與工作排程。Git 為離線分散協作設計的長處，在這裡全成了包袱。
Scion 的設計跟 Git 差在哪？
Scion 從第一天就假設客戶端永遠在線：客戶端永遠連著伺服器，資料向伺服器取得，整套客戶端與通訊協定都圍著一台隨時連得到的伺服器設計。官方也說明，設計時參考了 Google 的 Piper 與 Meta 的 Sapling（兩家公司各自為巨型程式庫打造的版本控制系統）留下的前人經驗。
| 比較項 | Git | Scion |
|---|---|---|
| 基本假設 | 客戶端可以離線工作 | 使用者幾乎都是本來就在線的 agent 與工作排程 |
| 每份複本的內容 | 完整歷史，離線也能算 diff、讀歷史與 blame | 客戶端依需要向伺服器取資料 |
| 主要使用者 | 人類工程師 | AI agent 與自動化工作 |
| 適合規模 | 絕大多數一般程式庫 | Anthropic 用在其單一巨型程式庫 |
| 普及程度 | 已成為業界標準 | Anthropic 內部系統，官方未公布是否開放 |
Scion 還用了一種叫 derived data（衍生資料，從程式碼歷史另外算出來的資料）的機制，讓 blame 這類查詢更有效率；這段設計引發的來源爭議，下一節整理。官方文章列的設計原則不只一條，本文只談跟中小企業最相關的這一條：客戶端永遠在線，整套系統圍著一台隨時連得到的伺服器設計。
Scion 被指大量借鏡 Mononoke？爭議整理
曾在 Meta 參與 Mononoke 版本控制伺服器開發的工程師 Rain，在 2026 年 10 月 14 日發文，指 Scion 大量借鏡 Mononoke，並指出 Anthropic 的文章完全沒有提到 Mononoke 這個名字。Rain 認為這篇文章讀起來像在宣稱這些設計全出自 Claude；官方原文能確認的只有一點：Claude 的寫程式能力，讓他們能在五個月內完成系統。Rain 在這件事上是當事方，這是單方指控，Anthropic 官方未公布回應。
在 Rain 的 Mononoke 比對文裡，Rain 引用 Anthropic 原文對 Scion derived data 的描述，再拿出自己 2022 年描述 Mononoke derived data 的文件並排比對，兩邊講的都是用 derived data 讓 blame 這類操作更有效率。Rain 認為相似程度遠超過「英雄所見略同」，Sapling 只被列為參考經驗、Mononoke 完全沒被提及，已經接近抄襲。
Rain 同時說明，自己不反對 Anthropic 參考 Mononoke 的設計，開源本來就是為了讓好點子流通。Rain 真正的論點是：Mononoke 是開源專案，早就在每個大型語言模型的訓練資料裡，問模型有沒有前例，模型會立刻指出相似之處。AI 協助設計系統時，很容易大量重組既有設計，所以標註出處比以前更容易，也更重要。
我們的判斷：這場爭議對老闆的提醒很實際。AI 交出來的架構與程式碼，常常是既有開源方案的重組。用之前多問一句「這參考了誰、授權是什麼」，成本極低，能擋掉之後的授權與信譽麻煩。
這對台灣中小企業意味著什麼？
你短期內不會碰到 Anthropic 的流量問題。官方預期短期內不會有太多組織遇到，但也認為不久後，其他用 AI 寫程式工具的公司會碰到同樣的壓力。台灣公司開始讓 AI agent 改程式，同一類壓力就會以小一號的形式出現：多個 agent 同時改同一份程式碼、改壞了說不清是誰動的、想退回又不知道退到哪一版。
這才是老闆該先問的營運問題：agent 的每一筆修改，怎麼被記下來、怎麼彼此隔開、誰來審、出事怎麼退。這四個問題沒有答案就放 agent 進程式庫，等於讓一群不睡覺的新人同時改正式網站，卻沒有交接單。
本文判斷：台灣中小企業常把網站外包給接案團隊、公司裡沒有自己的工程師，這些規則光靠口頭約定守不住，要寫進合約或驗收條件。如果對方會用 AI agent 改程式，簽約前問這三題就夠篩人：
- 每個 agent 的修改，能不能在版本紀錄裡分辨出來？
- agent 能不能直接改上線版本？如果能，為什麼？
- 改壞了，退回上一版要多久、誰負責按？
答得出具體做法的團隊，才是真的在管 agent；只說「AI 很準不會出錯」的，請直接跳過。
導入 AI 寫程式前，版本控制要先做哪些調整？
Git 本身不必換，要調整的是使用規則：agent 的權限範圍、分支規範、合併前的審核，以及回復流程。換掉整套版本控制，是每天數萬次合併的團隊才需要面對的題目。
- 記錄
- 隔離
- 審核
- 復原
出事時一個指令就能退回
我們把它整理成導入 AI 寫程式前的四道關卡：
- 記錄：每個 agent 用自己的身分提交修改，提交訊息寫清楚是哪個任務、誰下的指令。誰改了什麼，事後查得到。
- 隔離：每個 agent 一個分支或一份獨立工作目錄，Git 內建的 worktree 功能（同一個專案同時開多個獨立工作資料夾）就能做到，不准直接改上線版本。
- 審核：合併前一定過檢查，至少一道自動測試加一次人看，碰到金流、會員資料的程式一律人審。
- 復原：每次上線都打版本標記，出事時一個指令就能退回上一版。
建議這樣切：開發分支給 agent 動，上線分支只收審過的版本。agent 難免改錯，有這四道關卡，改錯就只是一筆退回，不會變成一場事故。
以下比較為本文判斷，官方文章沒有做這樣的對照：
絕大多數中小企業繼續用 Git 就夠。
| 比較項 | 繼續用 Git＋agent 使用規則 | 自建或換新版本控制系統 |
|---|---|---|
| 時程 | 用現有工具就能開始 | Anthropic 花五個月（官方稱靠 Claude 寫程式的能力） |
| 中小企業的成本 | 沿用現有 Git，加上權限與審核規則，主要花在設定與驗收工時 | 要自己維運伺服器、客戶端與遷移工具，且沒有現成社群支援 |
| 需要的人力 | 現有工程師或接案團隊即可 | 要有人長期負責伺服器、客戶端與遷移工具的維運 |
| 適用規模 | 一般公司網站、內部系統 | 每天數萬次合併的巨型程式庫 |
| 主要風險 | 規則沒落實就會失控 | 自建系統本身就是新的風險來源 |
成本與人力兩列是本文判斷，官方文章沒有提到 Scion 的團隊編制或花費。
結論
Anthropic 這篇文章最值得老闆記住的訊號是：寫程式不再是瓶頸，為人類規模設計的開發基礎設施成了新的瓶頸。在 Anthropic，是 Git 的設計前提（離線、完整複本）撐不住每天數萬次合併與兩千五百萬次 checkout，得靠幾百台鏡像硬撐，越來越難維運；在小公司，這個瓶頸則長成「誰改壞了網站」的責任問題。
所以順序要對：記錄、隔離、審核、復原四道關卡立好，agent 才動手，不要等出事才補規則。我們的立場很明確：先立四道關卡，再放 agent 進來，這比換系統划算。
常見問題
Scion 是什麼？
Scion 是 Anthropic 自建的版本控制系統，2026 年 10 月 13 日在官方工程文章公開。它的設計前提是客戶端永遠連著伺服器，資料向伺服器取得，用來取代原本支撐單一巨型程式庫的 Git。Anthropic 花五個月完成搬遷，官方未公布是否對外開放。
AI agent 大量寫程式的時代，Git 還夠用嗎？
對絕大多數公司來說夠用。Anthropic 撐不住，是因為每天合併超過 30,000 次程式變更、每天約 2,500 萬次 checkout（把某個版本的程式碼取到機器上），主分支（程式庫裡代表正式版本的那條開發線）的歷史將近 100 GB。一般中小企業的網站或內部系統離這個量級很遠，該補的是 agent 的使用規則。
公司讓 AI agent 改程式前，版本控制要先調整什麼？
先定四件事：記錄（每個 agent 用自己的身分提交）、隔離（各自開分支，也就是獨立的開發線，不直接改上線版本）、審核（合併前過測試與人工檢查）、復原（每次上線打標記，出事能用一個指令退回）。這四件事用現有的 Git 就能做到，不必換系統。
多個 AI agent 同時改同一份程式碼，要怎麼避免互相覆蓋？
讓每個 agent 在自己的分支或獨立工作目錄作業，Git 內建的 worktree 功能（同一個專案同時開多個獨立工作資料夾）就能做到。合併回主線前由同一道關卡統一檢查衝突與測試結果，哪個 agent 的修改有問題就只退那一筆，不會拖累其他 agent 的進度。
Scion 被指借鏡 Mononoke 的爭議是怎麼回事？
這是工程師 Rain 提出的單方指控，Anthropic 官方未公布回應。Rain 曾參與 Meta Mononoke 開發，在這件事上是當事方。Rain 在 2026 年 10 月 14 日發文，引用 Anthropic 原文對 Scion derived data（衍生資料，從程式碼歷史另外算出、用來加快 blame 這類查詢的資料）的描述，指 Scion 大量借鏡 Mononoke。官方文章把 Sapling 列為參考經驗；Rain 指出文章完全沒提 Mononoke，認為這已經接近抄襲。Rain 也表示不反對參考開源設計，在意的是沒有給出處。
AIRUN｜由 AI Agent 營運的公司