Anthropic Scion 取代內部 Git：每天三萬次合併，AI 寫程式的瓶頸移到哪裡？
Anthropic Scion 在五個月內接手大型程式庫，應付每天超過三萬次合併。解析 AI 開發的基礎設施瓶頸、Git 設計差異、人類審查角色與一般團隊的採用判斷。
AI 寫程式越快，團隊越可能把時間花在等待程式碼進入主版本，Anthropic Scion 就是在這個壓力下出現的。
Anthropic 在 2026 年 10 月 13 日公開內部版本控制系統的設計，表示大型程式庫已從 Git 遷移到自建服務。
版本控制負責記錄程式碼改動、保留歷史，以及把不同人的工作合在一起，是軟體團隊日常依賴的基礎工具。
依公司公告，單日合併量從五月約 2,500 次，成長到九月超過 30,000 次，原本支援人類開發速度的工具開始吃緊。
這個案例最有意思的地方，是 AI 擴大了工作量，也協助團隊打造承接工作量的系統。
對一般公司，值得學習的是如何找出等待與重複工作的成本，直接替換 Git 通常沒有必要。
要理解這個選擇，得先看看大量 AI 代理如何改變程式庫的使用方式。
Anthropic Scion 為什麼出現？提交變多，等待也會變多
AI 開發的產能要穿過整條流程才能形成產品，生成檔案只是開頭，後面還有合併、測試、審查與部署。
這裡的 AI 代理，是能持續操作工具、修改檔案與執行工作的軟體助手。許多代理同時運作，就會反覆向程式庫取得資料。
依 Anthropic 工程公告，公司在五個月內完成大型程式庫遷移，並同步建立程式碼審查等配套系統。
程式庫集中儲存多個專案時，常稱為 monorepo，也就是把許多系統放在同一個版本管理範圍內。
這有助於跨專案協作，卻也讓小任務可能接觸到龐大的資料。當每個代理都做一次相似操作，成本會被放大。
一次取資料很快，乘上大量工作就可能很慢
人類工程師開啟專案後，通常會在同一個環境工作一段時間。短生命週期的自動任務則可能不斷建立新環境。
每個環境都需要準備檔案，即使實際只改幾行。等待若發生在每一次測試前，就會佔掉大量總運算時間。
想像許多人每次查一頁資料，都要先搬一整箱檔案。單次看來可以接受，人數增加後，搬運就成了主要工作。
這是理解基礎設施負擔的比喻。企業要改善它，仍需要測量自己實際的檔案量、等待時間與重複操作。
合併次數增加，不等於產品品質自動提高
大量合併可以包含小修正、實驗與基礎設施更新，數量本身不會告訴我們使用者得到了多少新功能。
公司公開的成長數字，能支持工作負荷改變這個判斷，卻不能單獨證明所有改動都有價值。
若團隊只獎勵提交量，AI 可能讓無效工作也增加。觀察交付速度時，應同時看錯誤、回復舊版與維護負擔。
因此，承接更多改動的工具需要更快，也需要讓團隊能找出哪些改動值得留下。
Git 的離線優勢，遇到的是不同使用情境
Git 的重要特性是每個完整複本可以自行檢視歷史與建立提交，即使暫時無法連上伺服器，開發者仍能繼續工作。
Git 官方書籍 說明多數操作可在本機完成。這種設計適合開源協作，也讓開發者保有本機操作能力。
Anthropic 的主要客戶端卻是持續連線的代理與自動工作，團隊因而選擇把更多工作交給中央服務處理。
這是一項取捨：減少本機需要儲存與計算的資料，換來對伺服器可用性的依賴。
本機能力與中央服務各有成本
如果工程師常在網路不穩的環境工作，本機保有完整操作能力就很重要。伺服器設計再快，也不能替代離線需求。
若多數工作都在雲端執行，則可以把重複查詢集中處理，讓多個任務分享同一份結果。
公司的使用情境決定了何種成本更高。工具選擇應回答這個問題，不能只因一家 AI 公司更換系統就跟進。
大型程式庫已有其他設計經驗
大型版本控制的問題早在 AI 代理普及前就存在。Scion 的公告也提到其他公司處理巨大程式庫的經驗。
例如 Meta 的 Sapling 以大型程式庫為重要使用情境，提供了解另一種設計的官方入口。
這些背景有助於判斷新聞的創新範圍：新的壓力來自代理工作量，許多承接壓力的想法則延續既有工程經驗。
對讀者而言，比較工具的出發點應是自己的瓶頸，而不是把版本控制看成一場只能有一個贏家的競賽。
Scion 怎麼減少重複工作？把資料當成可以分享的服務
Scion 的方向是讓伺服器處理歷史查詢與提交等工作，客戶端只取得任務需要的資料，避免每項工作都維護完整程式庫。
如果一個測試只需要某個目錄，服務可以提供相應檔案。如果只想知道兩版差異，也可以直接取得比較結果。
這裡的 API 是讓程式呼叫服務的介面。查詢能透過 API 完成，就不必為了一個答案先建立完整開發環境。
對自動化工作，這有機會減少準備成本，也讓查歷史、回復改動等能力更容易被其他工具使用。
分享快取，能減少相同檔案反覆傳送
快取是把已取得的資料暫存，下一次使用時直接重用。許多工作需要相同檔案時，共享快取就有價值。
但快取必須知道自己儲存的是哪個版本。如果版本識別不清楚，任務可能跑得更快，卻測到錯誤的程式碼。
Scion 公開的設計以內容識別與分層服務來處理資料重用。一般團隊可以先理解這個方向，無須照搬整套內部架構。
例如先記錄測試工作的版本與依賴，再檢視哪些資料每次都重新下載，就能找到比較具體的改善入口。
服務變集中，故障影響也需要重新設計
客戶端依賴中央服務後，服務中斷可能同時影響更多工作。系統因此需要限流、隔離與回復機制。
限流是控制同時進入的請求量，避免一個工作把服務壓垮。隔離則是讓局部故障不會拖垮其他部分。
這些能力不會因模型能寫程式就自動成立。工程師仍要決定失敗時哪些工作應停、哪些可以繼續。
從這個角度看，自建版本控制系統是一項長期服務責任，不只是做出幾個比原工具更快的指令。
AI 協助造工具，人類工程師負責決定邊界
Scion 的案例也揭示工程師的工作如何改變：當程式碼生成更容易，設計取捨與驗證的重要性就上升。
Anthropic 在公告中描述，工程師需要阻止代理採用違反核心限制的做法，也需要避免審查建議造成過度複雜的系統。
對一般讀者，可以把它理解成建造前先確認結構。快速增加材料，並不能取代決定房子如何承重。
程式碼同樣如此。模型可能用看似合理的方法完成局部任務，卻讓整體系統產生難以維護的依賴。
審查要看改動的目的，也要能驗證結果
AI 生成量增加後，逐行閱讀的時間會變得有限。團隊需要先確認改動要解決什麼問題，以及哪些行為不能改。
這不代表只讀一段摘要就足夠。摘要、程式碼差異與測試證據應能互相對照，讓審查者追到實際變更。
涉及權限、付款或資料刪除的改動，也不應和文字修正使用相同審查強度。影響越大，證據要求越高。
如果想了解 AI 程式碼品質的討論，站內有從開發者觀點出發的整理，可以和這次基礎設施案例一起看。
延伸閱讀：@poteto 引爆軟體工程論戰：AI 代理寫的程式碼，品質與資安該怎麼看？
測試排程也要跟上合併速度
一批測試開始後，其他代理可能已經提交更多改動。等測試結束時，主版本與起跑版本可能不同。
因此測試報告必須附版本，部署前也需要知道哪些改動真的被檢查過。否則綠色結果只代表某一個過去狀態。
這是大量並行開發容易放大的協作問題。把版本資訊連到審查與部署，比單純增加測試數量更能提高可追溯性。
一般開發團隊要跟著更換 Git 嗎？
對多數團隊，應先最佳化現有流程。Anthropic 本身也明確表示，Scion 不適合作為一般用途的 Git 替代品。
遷移版本控制會牽動開發環境、審查、搜尋、測試與發版工具，導入成本可能大於原本等待造成的損失。
如果團隊每天的主要延遲是需求反覆修改，換版本控制不會解決問題。若主要時間花在審查排隊，也應先改善審查流程。
只有當資料準備、歷史查詢或大量並行操作已成為可量測的瓶頸，新的服務設計才有充分討論理由。
可以先學會量測，再考慮自建
小團隊可以記錄從代理完成改動，到進入主版本所需的時間，分開看等待、測試、審查與重試。
這會讓工具討論更具體。某一段若只佔總時間很小比例，即使加速很多，整體交付也未必明顯改善。
同時保留失敗與回復資料，避免把更多合併誤認成更高產出。使用者真正受益的，是可靠功能更快到手。
對需要建立證據與操作邊界的 AI 開發流程，另一篇站內文章也提供了從原始行為追查到實作的思路。
延伸閱讀：REA 逆向工程教學：讓 Claude Code 追查軟體功能，從證據到自己的實作
遷移版本控制，先證明歷史和工作都能接上
對一般團隊，自建系統最容易低估的工作，是保留既有歷史與協作習慣。新提交能成功，只能證明新系統完成了其中一項操作。
舊版本能否取出、同一檔案的修改來源能否追查，以及既有工具能否找到正確版本，都是遷移需要回答的問題。
如果歷史查詢不完整，工程師排查舊錯誤時就可能失去線索。這種損失不會立即出現在速度圖表上，卻會影響後續維護。
因此評估新設計時，可以先拿一組已知版本做對照，讓相同查詢在新舊系統得到一致答案，再討論速度改善。
快速和正確，需要不同指標
等待時間下降，可以用工作排程量測；版本是否正確，則需要比對檔案內容與歷史。兩項都通過檢查，改善才有實際意義。
例如一個任務原本等兩分鐘，後來只等幾秒，還要確認它測的是同一版程式，而非較舊的快取。這是示例，不是新效能報告。
對大量代理工作，還可以看同時運作時的失敗率。單一任務很快，不代表大量請求進來後仍然能維持相同結果。
這些測量會讓系統討論離開口號。團隊可以知道改善發生在哪裡，又有哪些成本被移到伺服器或維護人員身上。
公司報告的改善，對應的是內部基礎設施
Anthropic 表示，與先前 Git 鏡像基礎設施相比，Scion 的 CPU 與記憶體需求約縮小 200 倍，取程式碼也從分鐘降到秒。
公司另外列出 CI 節省 25% CPU 容量。CI 是每次改動後自動建置與測試的流程，這裡量測的是運算資源，並非員工數量。
三項數據都來自 Anthropic 的內部環境。巨大程式庫與大量代理使它有機會回收可觀資源，一般小專案不能直接期待相同比例。
對管理者，這比合併量更接近效益：任務少花時間準備，運算資源就能留給測試或研究，而不是反覆搬相同資料。
七人團隊的成果，也包含新的服務責任
公告表示，七人團隊同步建立 Scion、Antique 審查工具與其他配套。這讓五個月遷移的規模更具體，也說明成本不只在版本控制本身。
服務上線後，快取、權限與合併工具都需要持續維護。公司還描述使用 Claude 協助監看元件狀態，發現細小變化。
這是內部運作方式的案例，不是已對外販售的監控方案。其他團隊若要學習，應先確定自己有哪些可觀察指標與處理責任。
收益與服務責任放在一起，才看得出遷移是否合理。對多數團隊，先解決已量測的等待，仍是比重建整套開發工具更有根據的起點。
Anthropic Scion 常見問題
Anthropic Scion 已經提供大家下載嗎？
這次公告介紹的是內部系統與工程經驗，並非一般開發者可直接採用的通用產品發表。
每天三萬次合併，代表三萬個新功能嗎？
合併可能是修正、實驗或內部更新。數量反映負荷，不能直接換算為新功能或商業價值。
AI 會因此不再需要工程師嗎？
公告呈現工程師在架構、限制與審查上的作用。程式碼容易生成後，決定做什麼與驗證結果仍需要人負責。
先找出等待在哪裡，工具選擇才有答案
Scion 把 AI 開發的討論往前推了一步：當寫碼變快，承接改動的系統必須跟著調整。
一般團隊最值得採用的起點，是量測自己的交付流程，確認版本控制究竟佔了多少時間與資源。
從 Anthropic 原始工程文章 看設計取捨，再對照實際工作量，會比照著熱門標題換工具更有幫助。
若想持續追蹤相關更新，可免費訂閱 AI 郵報。
