---
title: "Anthropic 自己做了版本控制系統 Scion：對照我開發 App 踩到的 5 個坑"
seo_title: "Anthropic Scion 版本控制重點：AI agent 開發的 5 個實戰教訓"
description: "Anthropic 每天合併超過 3 萬次程式碼，git 撐不住，自己做了版本控制系統 Scion。本文整理原文重點：工作副本要輕、審意圖不逐行讀、合併後自動測試、專職監看的 superfan agent、衝突交給 Claude 修，並對照我用多個 AI agent 開發桌面 App 時踩到的 5 個坑：158 個工作資料夾塞滿硬碟、測試全過但 App 打不開等。"
author: "莊哲昀（AJ）"
tag: "Vibe Coding 實錄"
date: 2026-10-15
canonical: https://www.ahadigit.work/blog/anthropic-scion-source-control-agent-dev-lessons
source: "blocks"
---

# Anthropic 自己做了版本控制系統 Scion：對照我開發 App 踩到的 5 個坑

Anthropic 內部每天合併超過 3 萬次程式碼變更，git 撐不住，他們花 5 個月自己做了一套版本控制系統 Scion。我的專案規模差了好幾個數量級，用不到 Scion。**但這篇文章裡的 5 個觀念，剛好對上我這幾天踩到的坑。我最近在開發自己的 App。**

原文是 Anthropic 工程部落格〈Redesigning source control at Anthropic〉，2026 年 10 月 13 日發表，作者是 Nick G. 和原始碼管理團隊。前半段整理原文重點，後半段是我對照自己專案的 5 個教訓。

> **名詞解釋**
>
> **版本控制**：記錄程式碼每一次修改的系統，最常見的是 git。**monorepo**：把整間公司的程式碼放在同一個儲存庫裡。**工作副本**：把程式碼從儲存庫拿到自己電腦上、可以直接修改的那一份檔案。

## 一、Anthropic 遇到什麼問題

Anthropic 的工程師大量用 Claude 寫程式。寫程式本身已經不慢了，慢的是周邊的基礎設施：版本控制、建置和自動測試。這些系統當初是照「人類寫程式的速度」設計的。

- **合併量暴增：**2026 年 5 月每天約 2,500 次，9 月已超過 30,000 次。
- **儲存庫很大：**主分支歷史約 100 GB，一份壓縮後的工作副本就超過 25 GB。
- **拉取量驚人：**自動測試每天約 2,500 萬次取出程式碼。照 git 原本的做法，每天流量會超過 600 PB。

git 的設計假設每個人都會離線工作，所以每個人都要有完整的歷史紀錄。但 Anthropic 現在的使用者大多是「永遠連線」的 AI agent 和自動化任務，這個假設反而變成負擔。

## 二、Scion 怎麼解決

一個 7 人團隊花 5 個月做出 Scion，同時做了程式碼審查工具，再把整個 monorepo 從 git 搬過去。這段期間，每天的合併量又成長了 10 倍。幾個關鍵設計：

- **工作副本是選配的：**只拿需要的目錄，甚至可以完全不拿，直接透過 API 讀寫。原文寫「The working copy is optional, and sparse by design.」
- **重活交給伺服器：**歷史、合併、比對都在伺服器端做，個人電腦只留有上限的快取。
- **審意圖，不逐行讀：**工程師仍審每一份變更，但看的是「這次想做什麼、取捨對不對」。原文說，工程師很常扮演的角色是對 Claude 說「不」。
- **合併後才測試：**排隊一個一個合併的做法在 agent 的速度下行不通。他們改成先合併、合併後與部署前再自動測試，衝突交給 Claude 修。
- **專職監看的 agent：**每個元件配一個只負責看健康狀態的 Claude，他們叫它 superfan。它會讀遙測資料和日誌，找出一般告警抓不到的細微異常。

結果是：快取命中率超過 99%，運算資源需求比原本的 git 架構小約 200 倍，自動測試取出程式碼的時間從幾分鐘降到幾秒。

Anthropic 也說明，Scion 只適合超大型 monorepo，不打算當 git 的通用替代品。他們分享的目的是讓 git 社群參考其中有用的設計。

## 三、我的情況：一個人帶著一群 agent 開發 App

我最近在開發一個桌面 App，叫 Thatcaster，用來錄製和剪輯教學影片。開發方式是讓多個 AI agent 平行工作：每個功能開一個分支、一個獨立的工作資料夾，做完再合進發行分支，打包成安裝檔給我安裝。

這個規模用 git 綽綽有餘。不過這幾天出的狀況，和 Anthropic 文章裡講的問題，形狀幾乎一樣。

## 坑 1：工作副本太重，硬碟被塞滿

我讓每個任務都開一個完整的工作資料夾（git 的 worktree 功能，可以在同一個儲存庫底下同時開好幾份工作副本）。agent 做完不會自己清，**幾天下來累積到 158 個，硬碟只剩 23 GB。**

Anthropic 的做法是讓工作副本盡量輕，只拿需要的部分。對照到我的專案，改法是：

- 不再一個任務開一個資料夾，改成固定幾個可以重複使用的「工作槽」。
- 任務結束就自動清掉，不靠人記得刪。

## 坑 2：我在審意圖，但沒有寫下規則

Anthropic 的工程師不逐行讀程式碼，只看這次改動想做什麼、取捨對不對。這其實就是我現在的角色。我也不會逐行看 agent 寫的程式，我看的是它想做什麼。

問題是，我的規則都在腦袋裡，或散落在每次交辦的對話裡。例如：

- **不能動 main 分支：**所有修改先進發行分支，確認沒問題才進 main。
- **內嵌網頁不能加 preload：**preload 是讓網頁內容碰到桌面系統功能的通道。內嵌外部網頁時開這個口，等於給網頁太多權限。
- **打包白名單：**哪些檔案要放進安裝檔，有一份清單管控。

改法是把這些寫成一張明確的規則表。每個 agent 開工前要讀，結束時要逐條自查。這樣我審的時候，也有一份可以對照的標準。

## 坑 3：測試全過，裝好的 App 卻打不開

這是這幾天最痛的一次。第 5 個組建（build 5）的安裝檔做好了，所有自動測試都通過。我裝上去，**App 開不出視窗。**

原因是主程式啟動時要讀一個選單檔，但打包白名單漏了它，安裝檔裡根本沒有這個檔。測試是在開發環境跑的，檔案都在，所以抓不到。裝好的 App 也沒有人或 agent 真的開啟過。結果，我就是第一個發現的人。

Anthropic 改成合併後、部署前自動測試。對照到我的專案，驗收要做到「裝好的成品」這一層：

- **已經做了：**打包完自動檢查主程式要讀的檔案是不是都在安裝檔裡，缺一個就讓打包失敗。build 6 就靠這個確認了 228 個檔案都在。
- **還差一步：**安裝後自動啟動一次，確認視窗有出來、日誌沒有錯誤，才通知我去裝。

## 坑 4：缺一個專門盯著的 agent

修好的第 6 個組建（build 6）安裝檔做好了，**卻過了 4 個小時都沒裝上去。**

原因是前一個負責後續流程的排程任務提早被刪掉了，沒有人接手。每個 agent 都只顧自己那一段，段與段之間的交接就掉了。

Anthropic 的 superfan 是每個元件配一個只負責盯健康狀態的 Claude。我不需要這麼多，但可以有一個固定的排程任務，專門盯「打包到安裝」這條線：有沒有新的安裝檔、裝上去了沒、開起來正不正常。

## 坑 5：合併排隊，偶爾卡住

我現在每一版安裝檔，要合併 4 到 6 個功能分支。分支之間偶爾會衝突，衝突就卡在那裡等我處理。

Anthropic 的結論是：在 agent 的速度下，排隊合併行不通。原文寫「Claude can typically fix these conflicts faster than humans can even identify them.」，也就是 Claude 修衝突的速度，往往比人類發現衝突還快。

對照到我的專案，改法是讓修改直接進發行分支，打包時再完整跑一次測試。遇到衝突，就讓 AI 程式工具（我用的是 Grok CLI）當場修，不再排隊等我。

## 四、規模差很多，問題的形狀一樣

Anthropic 是每天 3 萬次合併，我是一天幾個分支。但根本的問題相同：AI 寫程式變快之後，瓶頸就移到程式以外的地方。例如工作環境要有人清，規則要寫下來，成品要驗收，流程要有人交接。

如果你也開始讓 AI agent 幫你寫程式，可以先檢查這 5 件事：

1. **工作環境會不會自動清理？**agent 開出來的資料夾、分支、暫存檔，有沒有人收。
2. **規則有沒有寫成文字？**不能做的事要寫成清單，讓 agent 開工前讀、收工時自查。
3. **驗收做到成品了嗎？**測試通過不等於使用者拿到的東西能用，要真的安裝、開啟來檢查。
4. **流程的交接有人盯嗎？**每段都有 agent 負責，不代表段與段之間有人負責。
5. **合併衝突要排隊等人嗎？**可以讓 agent 先修，人再審它修的意圖。

工程師的角色正在變：寫得少，審得多，更常說「不」。而要能審、能說不，前提是規則和驗收標準已經清楚寫下來。

## 資料來源

- [Nick G. 等，Redesigning source control at Anthropic（Anthropic Engineering，2026-10-13）](https://www.anthropic.com/engineering/redesigning-source-control)
- 文中 Anthropic 的數據與引言皆引自上述文章；Thatcaster 的開發狀況為作者本人專案的紀錄。