來源與事實範圍 本文主要依據 Anthropic 2026-10-13 官方工程文章〈Redesigning source control at Anthropic〉。文中 Anthropic 的合併量、Scion 架構、團隊規模與效能數據均來自該文；延伸到一般團隊與個人 AI 工作流的段落屬作者整理與推論，不代表 Anthropic 官方建議。

AI 寫 Code 寫到 Git 撐不住：Anthropic 五個月重做版本控制，真正的瓶頸已經換了

如果你還在問：

「AI 到底能不能寫出能用的程式碼？」

Anthropic 已經遇到下一個問題了。

不是 Claude 寫得不夠快。

是它寫得太快，快到原本替人類開發速度設計的 Git、CI、Build 流程開始撐不住。

Anthropic 在 2026 年 5 月，平均每天合併大約 2,500 次程式碼變更。

到了 9 月，這個數字已經超過 30,000 次／天。

短短幾個月，合併量成長超過十倍。

於是他們做了一件非常極端的事：

五個月內，重新打造一套版本控制系統，並把整個 monorepo 從 Git 遷移過去。

這套系統叫 Scion。

我覺得真正值得看的，不是「Anthropic 做了一個 Git 替代品」。

而是另一件事：

AI 讓 Coding 變快之後，瓶頸不會消失，只會往下一個環節移動。

第一個撐不住的，不一定是人

很多人談 AI Coding，注意力還放在：

• 哪個模型寫 Code 比較強？
• 哪個 Agent benchmark 分數最高？
• 一個功能可以省多少工程時間？

但如果 Coding 速度真的提升十倍，問題很快就不在 Coding 本身。

Anthropic 的 monorepo 主分支歷史已經接近 100 GB，壓縮後的 working copy 也超過 25 GB。

每天光 CI 就要進行大約 2,500 萬次 code checkout。

如果照傳統方式直接從 Git 抓取，理論上的資料流量會大到非常不現實。

所以他們最後問的問題不是：

「Git 還能不能再優化？」

而是：

「如果今天大多數 client 都不是離線工作的工程師，而是永遠在線的 Agent 和 CI job，版本控制系統還需要長得像 Git 嗎？」

這個問題很重要。

因為 Git 的很多設計，本來就是為「人」準備的。

每個 clone 都有完整能力，可以離線看 history、diff、blame、checkout。

但 Agent 不一定需要這些。

Agent 通常在線，而且只需要目前任務涉及的那一小部分資料。

當使用者變了，系統的最佳解也可能跟著變。

AI-native，不是把 AI 塞進舊流程

這是我看完整篇後最有感的地方。

很多團隊現在所謂的「AI 導入」，其實只是：

原本流程 + AI。

原本工程師開 branch。

現在 Agent 開 branch。

原本工程師寫 Code。

現在 Agent 寫 Code。

原本工程師開 PR。

現在 Agent 幫你開 PR。

看起來變快了，但底層流程完全沒變。

這在 AI 還只是輔助工具時沒有問題。

但當 Agent 的產出速度超過整套系統原本設計的吞吐量，所有舊假設都會開始浮出來。

Anthropic 甚至直接重新思考：

如果測試還在跑的時候，已經有幾百甚至幾千個 change merge 進 main，那傳統 merge queue 還合理嗎？

他們目前投入更多 post-merge 與 pre-deploy automated testing，而不是假設所有變更都能像以前一樣，在一個全域鎖定的 queue 裡乖乖排隊。

這其實是一個很大的思維轉換：

不要只讓 AI 適應舊流程，也要開始問：哪些流程本來就是為人類速度設計的？

AI 寫得越快，人反而越不該逐行 Review

另一段我很喜歡。

Scion 和它搭配的 Code Review 工具 Antique，是由一個 7 人團隊在五個月內完成並遷移。

Anthropic 在文章裡直接寫：

團隊裡的工程師現在都認為 Claude 寫 Code 的能力比自己更好。

但這不代表工程師變得不重要。

剛好相反。

他們的工作開始往上移。

工程師仍然 Review 每一次 change request，但重點逐漸從：

「這一行 Code 寫得對不對？」

轉成：

「這個修改的意圖對不對？」

這個差別非常大。

因為當 AI 可以快速產生大量實作時，真正稀缺的東西開始變成：

• 這個問題值得解嗎？
• 這個設計違反了什麼核心限制？
• 為了通過測試，Agent 是否偷偷做了錯誤的 trade-off？
• 這個解法是不是為了不存在的風險過度工程？
• 哪些改動需要更高層級的人工核准？

Anthropic 甚至提到，他們經常需要做的事情，是對 Claude 說：

「不。」

Agent 有時會為了完成眼前任務，破壞系統原本不能碰的 constraint。

而 adversarial review 雖然很好用，也可能因為過度防禦，讓系統長出不必要的複雜度。

所以人沒有退出流程。

只是從「寫每一行」慢慢移到：

設定邊界、判斷取捨、校準意圖。

真正成熟的 Review，不是所有東西都用同一套標準

Scion 的 Code Review 系統還有一個我很喜歡的設計：

它可以根據改動的語意，設定不同的 approval constraint。

例如：

只改註解。

跟修改敏感的核心邏輯。

本來就不應該用完全相同的審查強度。

這其實跟我最近在思考 AI Workflow 的方向非常接近。

不是每個任務都：

最強模型 + 三個 Agent + 完整測試 + 人工 Review。

而應該先問：

這個修改的風險是什麼？

低風險修改，流程可以很輕。

高風險修改，再提高模型能力、測試深度、審查層級與人工介入。

AI 讓執行成本下降之後，很容易讓人產生一種錯覺：

「反正 Agent 很便宜，多跑一點沒差。」

但真正可擴展的系統不是什麼都做。

而是知道：

什麼時候需要做到哪裡。

AI Coding 的下一個戰場，可能不是 Coding

Anthropic 的 Scion 當然不是一般團隊現在需要照抄的東西。

官方自己也說得很清楚：

這套設計適合非常巨大的 monorepo，以及大量 Agent 高頻產生程式碼的特殊環境。

大部分公司根本還沒到需要放棄 Git 的程度。

但我覺得這篇真正值得留下的，不是 Scion 的技術細節。

而是一個更早期的訊號：

當 AI 大幅降低某一層工作的成本，系統的瓶頸就會往下一層移動。

Coding 變快。

接著可能卡在：

Review。

Review 自動化。

接著可能卡在：

CI。

CI 變快。

接著可能卡在：

產品決策。

最後你會發現，真正難壓縮的東西慢慢變成：

判斷。

這也改變了我看多 Agent 工作流的方式

我最近一直在整理自己的 AI Agent 工作流。

以前最容易問的是：

「怎麼再多派一個 Agent？」

現在我更想問：

「如果這個 Agent 真的快十倍，下一個會被塞爆的是哪裡？」

是 Git worktree？

是測試時間？

是 Reviewer？

是 Token？

還是最後那個必須由人做的決策？

這個問題比「哪個模型比較強」更重要。

因為模型一定會繼續變快。

真正能留下來的能力，是你能不能看見：

整條工作流裡，新的瓶頸正在往哪裡移動。

我從這篇帶走的三件事

一、不要只優化 Agent，要優化整條 throughput。

Agent 快十倍，後面的流程沒跟上，整體速度不會快十倍。

二、Review 要從逐行檢查，往意圖與風險移動。

程式碼產量越高，人越應該把注意力放在最難自動化的判斷。

三、不要假設今天的開發流程是永恆的。

Git、PR、Merge Queue、CI，都是在某個時代的開發速度下形成的最佳實務。

當開發者從人變成大量永遠在線的 Agent，有些最佳實務可能也必須重新被檢查。

如果 AI 有一天真的讓你的團隊產出快十倍，

真正值得問的可能不是：

「我們是不是可以少幾個工程師？」

而是：

「我們現在這套流程，有哪一段根本不是為這種速度設計的？」

那裡，很可能就是下一個真正值得解的問題。