背景：AI規模開發壓垮傳統Git
大家好，這裡是最佳夥伴，我是大飛。
我們先來看一些數字：今年 5 月，NSB 平均每天向其主儲存庫合併 2500 個程式碼變更。到 9 月份，每天的點擊量超過 3 萬次——四個月內成長了十倍以上。他們明確表示，這種成長勢頭不會很快放緩，因為對程式碼合併的需求幾乎沒有上限；每次瓶頸被清除，產量都會進一步激增。
10 月 13 日，他們在官方工程部落格上發表了一篇文章，詳細介紹了一個七人團隊如何花了五個月的時間，從頭開始建立一個名為 SON 的內部版本控制系統，並將他們整個單體儲存庫從 Git 遷移過來。同期，他們也推出了程式碼審查工具、程式碼搜尋和原始碼權限管理系統等配套工具。這則消息在開發者圈迅速傳開來，甚至有人高喊「Git 安息吧」。近 20 年來，Git 定義了程式設計師的開發工作流程；現在，一家人工智慧公司用基於自身模型建構的系統取代了它。真的已經行不通了嗎？普通開發者應該感到擔憂嗎？今天我們要討論這個問題，你自然會明白的。
讓我們先從背景說起：寫程式碼本身不再是瓶頸。人工智慧可以自主迭代、研究、交換和微調複雜的程序，從零開始建立新的服務；瓶頸已經轉移到其他地方了。例如，版本控制、建造系統和 CI 管線——這些基礎設施都是為人類規模的開發而設計的。他們的負荷達到了什麼水準？僅主分支的歷史記錄就接近 100GB，壓縮後的工作副本超過 25GB，僅 CI 系統每天就執行約 2500 萬次代碼檢出。這還不包括開發環境、人工智慧沙箱和研究任務。如果他們每次都直接從 Git 拉取數據，每日流量將超過 600PB。
如此龐大的流量顯然無法由原有的 Git 架構處理。透過一些局部處理方法，如淺克隆、稀疏檢出和部分遠程，業界有一套處理大型單體存儲庫的標準操作手冊，例如設置內部鏡像或將存儲庫快照存儲在對象存儲中。Anthropic 嘗試過所有這些方法，在高峰負載時，他們運行了數百台 Git 鏡像伺服器。方法確實延長了使用壽命，但維護起來卻越來越困難。在刷新間隔期間，快照和主分支之間的差距越來越大，僅僅運行 diff 或 blame 等歷史操作就需要付出更多努力才能進行部分克隆。
此時，他們重新審視了自己的使用情況，並發現了一個嚴重的偏差。和大多數公司一樣，他們一直使用 Git 作為集中式系統，所有工作都圍繞著一個權威的儲存庫。然而，Git 從根本上來說是去中心化的，它假定客戶端可能會離線工作，這就是為什麼每個克隆都包含完整的儲存庫。問題在於，他們幾乎所有的客戶和自動化任務都始終在線上。Git 的功能是為離線場景設計的，但當其儲存庫變得過大時，這些功能就變成了可擴充性的障礙。
他們問自己，如果版本控制從一開始就以客戶始終在線為前提進行設計，那它會是什麼樣子？這就是 Sapling 的起點。大型單體倉庫版本控制已有先例；Google 的 Piper 和 Meta 的 Sapling 已經克服了許多陷阱，它們的設計借鑒了這些經驗。
新系統的五項核心設計原則
文章概述了幾項設計原則，讓我們逐一來看。
首先，客戶始終在線；它們只根據需要從伺服器獲取所需的資料。客戶端和伺服器的職責是不對稱的。歷史記錄查詢、責任歸屬、分支和合併等操作都在伺服器端處理。客戶端僅維護有限的本機物件存儲，將檔案放置在磁碟上，監視檔案系統更改，並提供方便的使用者介面。由於客戶端幾乎不執行任何繁重的計算，因此本地資料量要小得多。
其次，版本控制服務必須夠全面，才能支援新的應用程式。在 Git 時代，要找出最後修改一行程式碼的人，要嘛需要維護一個本機程式碼庫，要嘛希望平台的 API 能夠提供答案。Sapling 將客戶端使用的所有查詢功能都以 API 的形式公開出來。許多任務不再需要本地儲存庫；他們的內部自動二分查找和回滾管道依賴這種方法。如果沒有這種高效且可編程的存取方式，這些工具在目前的規模下是完全無法持續的。
第三，所有組件都必須能夠水平擴展。一旦儲存庫的容量超過單一機器的磁碟或記憶體容量，依賴那些數百 GB 的大型映像就是不可能的了。因此，Sapling 採用分散式資料存儲，允許每個組件獨立擴展。整個系統中沒有任何完全物化的儲存庫，甚至在伺服器上也沒有。由於 Git 使用的「packfile」壓縮和打包機制已不復存在，因此儲存庫維護不再是一個問題。
第四，提交必須是輕量級和增量式的。在 Git 中，提交是本地的，而在 Piper 中，提交、合併和整合都在伺服器上進行，沒有本地暫存步驟；這就要求每個操作都必須快速。建立提交的成本必須與更改的大小成正比，而不是與整個儲存庫的規模成正比，否則伺服器最終將無法跟上。指向提交的引用（例如分支和標籤）應該謹慎使用，因為如果所有伺服器都必須維護一致的全域狀態，擴展性將不可避免地成為瓶頸。
最後，工作副本是可選的，預設會按需檢出。由於程式碼庫規模龐大，每天有數千萬次 CI 檢出，我們盡可能避免檢出；需要將提交與合併基準進行比較的 CI 任務可以直接向伺服器發出請求，許多只讀任務可以完全透過 API 處理。如果必須將檔案寫入磁碟，我們會使用按需檢出或虛擬檢出，只提取實際讀取的檔案。
內部架構與資料結構實現
好了，原理部分講完了；現在讓我們來看看它們是如何實現的。
Piper 的基本工作單元稱為“變更清單”，它是預寫日誌中的一筆記錄。它儲存了提交中包含的大部分信息，但組織方式不同；Git 提交存儲指向整個目錄樹的指針，而變更列表存儲相對於父提交已更改的文件列表，以及指向對象存儲中壓縮文件內容的指針。變更清單在伺服器上創建，創建後立即全域可見。這種結構可以實現非常高的傳入變更吞吐量，無需管理包文件，無需鎖定，無需跨伺服器協調，也無需更新引用。
從技術上講，Piper 仍然支援引用，但建立或檢索提交並不涉及引用；移動引用只是對 Spanner 資料庫中的單行執行比較和交換操作，這與建立變更清單完全無關。
由於變更清單僅記錄變更本身，因此無法快速回答諸如誰最後修改了這一行或哪些提交影響了特定文件之類的問題。因此，Piper 在變更列表之上構建了一組額外的數據結構，包括用於加速提交圖查詢的跳躍列表和用於檢查“blame”和路徑歷史的工具；他們將不直接屬於變更列表的數據稱為“衍生數據”，所有這些數據都是通過統一的機制計算出來的。每種派生資料都是遞歸定義，並從父級的對應資料推斷出來的。為了加快操作速度，只需新增一種新的衍生資料類型；對於每種類型，您可以選擇事先計算或按需計算，避免產生未使用的資產。客戶端看不到內部結構，因此可以自由地優化伺服器，而無需在客戶端進行任何更改。隨著系統的發展，他們添加了許多新類型，例如用於重複文件檢測和基於路徑的文件搜尋的新索引。
從架構上看，一小部分伺服器向外部提供所有版本控制 API。所有數據內容一旦寫入便不可更改，任何伺服器都可以安全地快取這些數據，而無需相互確認。伺服器本質上是一組大型緩存，它們會順便計算派生資料並將其寫回 Spanner，這使得它們非常容易擴展。規模化容易，協調成本很低。
文件檢索協議與 Git 有很大不同。客戶端（稱為 SCN）在請求資料時不會告訴伺服器它已經擁有哪些資料；相反，它從根目錄開始檢查本地缺少哪些目錄樹對象，遞歸地請求它們，並以相同的方式獲取檔案內容。每個請求都指向一個特定的、不可變的物件。任何快取層都可以直接回應，避免了多 GB 的套件檔案回應，從而保證了高效率並支援恢復中斷的下載。稀疏檢出和虛擬化檢出不需要特殊支援；客戶端不會要求它不需要的目錄樹。
部署分為三個層次。客戶端透過套接字與本機 SD 卡通訊。SD 代表整個運算節點管理對象，讓同一節點上的任務重複使用相同的物件並進行統一管理。啟動時，它會載入定期刷新的快照，然後與本機區域的快取伺服器 S3Cache 通訊。S3Cache 直接從記憶體以磁碟就緒格式傳輸對象，無需計算差異或即時執行壓縮。只有當快取找不到物件時，才會回退到權威的 SServer，然後由 SServer 從 Spanner 或雲端儲存中檢索該物件。這三層都使用同一組 RPC 介面。客戶端無需了解快取拓撲結構。
理論上，任何一層都可以連接到另一層，但它們嚴格限制了分層訪問，以隔離故障，確保如果區域快取發生故障，請求不會湧向上游並導致整個系統癱瘓。
請注意效能資料：每一層的快取命中率都超過 99%，而且由於不需要長期狀態，您可以隨意擴展。與先前的 Git 鏡像日誌記錄工具相比，S 將 CPU 和記憶體使用量降低了 200 倍。CI 和研究任務的延遲提高了約兩個數量級，從幾分鐘縮短到幾秒鐘，釋放了叢集中的大量運算資源——僅 CI 就節省了 25% 的 CPU 使用率。
AI輔助開發與工程師角色的轉變
拋開技術本身不談，開發過程本身可能更有意思。
當他們開始這項工作時，恰逢克勞德-3-Opus 和克勞德-3.5-Sonnet 的內部發布。這兩種模式都提高了對 S 的需求，同時顯著加快了開發速度。文章中舉了一個典型的例子：今年早些時候，團隊手工編寫了從 Git 到 S 的資料導入管道的第一個原型，當時他們覺得這個原型相當不錯。後來，在獲得 Claude 的早期內部版本後，他們讓模型重寫了整個程序，而沒有提供任何額外的提示。Claude 傳回的版本記憶體消耗減少了 20 倍，運行速度提高了 4 倍，同時也遵守了原始程式中關於導入順序和資料結構的所有隱含約束。
在這個專案中，7 個人花了 5 個月的時間完成了 6 個相關系統（包括 S 和 Anti）以及程式碼搜索，並完成了一次完整的遷移——與此同時，每日合併量激增了 10 倍。過去，開發和部署這樣的版本控制系統需要更多工程師花費數年時間進行迭代和遷移，因此他們的結論是，建立大規模系統的小團隊將變得越來越普遍。
工程師角色的轉變也值得單獨探討。參與該專案的工程師現在承認，模型在純粹的編碼方面已經超越了他們，但工程師的工資並沒有降低；他們只是轉移了關注點。它們提供的是對系統之間整體關係的理解，對設計權衡的判斷，以及對要解決的問題和要支持的規模的了解。
工程師的工作常常是向克勞德說「不」。為什麼要拒絕呢？因為有時智能體為了滿足局部程式碼模式，會違反系統的核心限制。這種情況在遷移過程中經常發生；例如，有些系統想要檢查某個特定變更何時合併到主分支。Claude 的解決方案是線性掃描提交日誌，而正確的方法是直接查詢程式碼審查工具。它還大量採用了對抗性程式碼審查。雖然這種方法在許多方面都很有效，但它往往過於關注局部問題，導致系統過於複雜。在一次審查中，由於對另一項內部服務過度不信任，克勞德堆砌了大量的額外驗證。現在，團隊成員仍然會審查個別變更請求，但重點是變更的意圖，而不是逐行閱讀程式碼。
就品質而言，由於人工智慧編寫程式碼的速度比人類快得多，這成為了他們處理過的經過最好測試、保護最完善的程式碼庫之一。儘管時間緊迫，他們還是將歷史上複雜的基礎設施互動操作轉化為獨立的、可重複的模擬測試，同時也增加了模糊測試和強大的管道。人工智慧還可以輕鬆挖掘優化點；例如，它曾經發現祖先關係查詢演算法有問題。它改用了現有的索引。如果交給專家來處理這類問題，可能需要幾天甚至幾週的時間來分析和調整，但人工智慧只花了一天就完成了，並在第二天就開始處理下一個任務。
此外，從一開始就考慮了安全性和合規性，支援豐富的儲存庫存取控制，權限粒度足夠細，可以保護單一目錄的敏感程式碼，而不會失去單體儲存庫的優勢。配套的審核工具可以表達複雜的語意審核約束，例如區分簡單的變更（如評論更新）和敏感的邏輯修改，讓人工審核員專注於影響較大的變更。
此外，還有一種全新的方法：團隊大量使用 AI 代理程式來監控元件，建立專門的 Slack 頻道，每個頻道中都有一個 AI 實例，密切注意特定元件的運作狀況。他們稱這些人工智慧代理為“超級粉絲”，每個代理都被分配來監控特定的領域，例如快取、合併隊列等等。這些實例會存取遙測資料和日本志，像一個時間充裕的經驗豐富的工程師一樣，不斷檢查異常情況。當然，傳統的警報機制仍然保留，但超級粉絲能夠發現一些微妙的、前所未有的問題，相較之下，傳統的警報機制就顯得有些遲緩了。
這個計畫迫使他們重新審視許多為人類規模的操作而設計的流程，其中最典型的就是合併隊列。在人工智慧領域，當一次測試完成時，可能已經有成百上千項變更合併到程式碼庫中了。業界標準的全球儲存庫鎖定機制根本無法滿足需求；他們的解決方案是放棄全域排隊，並將重點轉移到合併和部署之間的自動化測試。在權衡之下，同時進行的更改可能會發生衝突，但人工智慧解決衝突的速度比人類發現衝突的速度還要快。
邊界與未來展望
最後，我們來談談界限。這部分需要解釋清楚，以免有任何誤解。需要明確的是，S 絕不是 Git 的通用替代品。這種設計只適用於真正龐大的單體程式碼庫，要嘛是成千上萬的工程師共享程式碼庫，要嘛是人工智慧不斷地產生程式碼。此外，Big 還擁有其他公司所不具備的優勢；它們為內部任務消耗運算能力的能力遠遠超過一般公司願意承擔的範圍，既滿足了自身需求，也測試了雲端的能力。
將 S 打造成通用產品也不現實；它與 Git 的差異太大了。採用它需要投入到完整的開發生命週期中，包括配套的程式碼審查、搜尋和持續集成，但由於這些系統是高度客製化的，外人很難使用它們。他們也擔心，為了取悅所有人而建造一個公共版本最終會使其毫無用處。
然而，他們認為，在接下來的 6 到 12 個月裡，這類問題將會變得越來越普遍。與其讓每家使用 Git 的公司各自碰壁，不如將他們的想法公開出來。他們認為 Git 伺服器不必像客戶端那樣運作，新的伺服器架構可以顯著提高可擴展性。通用平台可以提供像 S 這樣的完整的伺服器端 RPC 接口，甚至可以在不同的平台上實現 RPC 接口的標準化。現有的資料協商協議不必保持不變；淺克隆、資料取得和結帳等功能還有改進的空間。
他的態度非常克制。該社群花了 20 年時間擴展這些平台，為數百萬開發者提供服務。他們的貢獻相當有限——他們只是很早就看到了人工智慧編碼將如何與這些系統發生衝突，並希望與 GitHub、GitLab 和開源社群合作來解決這個問題。
從整體來看，Git 被替換更像是一個鉤子；真正值得記住的訊號更具普遍性。隨著人工智慧編碼速度開始呈指數級增長，圍繞人類節奏設計的工具鏈將一個接一個地遇到瓶頸。今天是版本控制，明天可能是持續集成，後天可能就是程式碼審查中的所有預設假設。雖然他們已經公開了自己遭遇瓶頸的過程，但對於其他球隊來說，情況卻並非如此……