CI 花十分鐘完成，其中六分鐘在準備原始碼，增加一個寫程式的 Agent，可能只是替佇列多排一件工作。這是教學用的假設場景；本文沒有量測讀者的 repository，也沒有實測 Scion。

Anthropic 在 2026 年 10 月 13 日公開 Scion，說明如何把內部 monorepo 遷離 Git。公司自述，九月每天合併超過三萬次變更；新系統把歷史查詢、提交與合併放到服務端，客戶端按需要取得資料。這提供了一個值得借用的問題：每個工作究竟需要多少原始碼，為什麼要為它準備整份工作區？

這篇報導是內部工程案例。官方明確說 Scion 不適合一般用途的 Git 替代，也不是可以直接裝進團隊的公開產品。一般團隊更可行的第一步，是把 checkout 與測試成本分開記帳。

把「CI 很慢」拆成可以判斷的數字

假設一個團隊每天啟動 500 個 job，每次取得 2 GB 原始碼，粗略資料搬運量就是每天 1,000 GB。這只是未計快取、壓縮、重試與共享工作區的教學估算，不能直接拿來推帳單。

同一批工作，格式檢查可能只讀十個檔案，整合測試卻需要跨模組的 migration 與 fixture。讓兩者下載相同資料，付出的成本很容易混在「測試耗時」裡。

我會讓每個 job 留下四項紀錄：

  • 準備原始碼與安裝依賴各花多久。
  • 實際讀取哪些目錄，以及是否需要提交歷史。
  • 測試開始前的等待時間。
  • 結果所對應的精確 commit，以及重試次數。

至少觀察一個正常工作日與一次大量提交時段。若主要時間消耗在資料庫初始化，改版本控制系統並不會解決眼前瓶頸。

最小方案是減少搬運，同時保留工具需要的歷史

Git 的 partial clone 文件說明按需取得物件的設計；sparse-checkout 文件則處理工作樹呈現哪些路徑。它們解決的層次不同，不能只把一個旗標貼進所有 job。

以虛構的訂單服務為例，純文件檢查可以只準備文件目錄；需要比較基準版本的 migration 檢查，則必須能取得基準提交及差異。若工具依賴 blame、標籤或 merge base，縮小 checkout 前要把這些依賴列出來。

驗證方式很直接：挑一批固定提交，同時用既有完整流程和縮小後流程執行，逐項比較輸出與失敗結果。不能只比較「兩邊都綠燈」，還要放入一筆刻意破壞跨目錄相依性的變更，確認精簡流程同樣會拒絕它。

若精簡 checkout 讓必要的失敗案例消失，就停止推廣。節省傳輸量不能靠漏看受影響檔案取得。

查詢可以卸載，驗證身分不能省略

有些 job 只想知道「這兩個提交改了哪些檔案」。為了回答這個問題，替它建立完整工作目錄未必划算。Scion 的服務端 API 思路可以轉化成更小的改動：由受控的 repository 服務提供查詢結果，執行測試的工作再取得必要內容。

這是工程建議，並非要求另造一套版本控制。代價是查詢服務的可用性與正確性會成為 CI 依賴。回應至少應帶上查詢使用的兩個 commit ID，而不是只寫 main 與 feature 分支名稱。分支會移動；同名不代表同一份輸入。

快取也應依不可變的版本識別值取用。把「最新差異」快取五分鐘，對文件預覽也許可接受，拿來判斷能否部署付款程式就需要另一套失效規則。若服務暫時不可用，回退完整流程和暫停工作各有成本，應事先決定，避免偷偷把查詢失敗當成沒有變更。

合併速度要服從可驗證的發布速度

Anthropic 的案例也討論大量並行變更下的合併與測試安排。這類取捨不能直接照搬到一般交易系統。

假設工作 A、B 各自通過測試，但兩者合起來改壞同一項庫存規則，兩張綠色結果都不足以證明合併後的版本可部署。團隊必須明確說出：哪一個組合版本接受過測試，失敗時誰阻止發布，哪一份產物可以回復。

最小可行方案通常仍是維持必要的合併前檢查，部署前驗證精確候選版本。若吞吐量不足，先找可取消的重複工作與可分流的測試，再評估更複雜的投機測試或批次驗證。新增並行度後，要監看未驗證提交數與最舊待驗證時間，不能只看每分鐘合併數。

相關的repository 品質門檻與執行收據討論的是同一條責任線：產物增加之後，證據仍要跟得上。

下一步：選一個最浪費準備時間的 job

先替它記錄一週的 checkout、依賴準備、排隊與測試耗時，再寫下實際需要的目錄和歷史操作。做一個可回退的小型精簡試驗，保留同版本的完整流程作對照。

只有當這些手段仍無法滿足量測過的吞吐需求，而且團隊有能力承擔新的服務可用性與遷移成本時，才值得討論專用原始碼服務。Scion 最有價值的地方，是把工作負載假設攤開；採用別人的架構之前，自己的成本也應該能被攤開。