Git 被換掉，LLM 被替代：AI 編碼開始反噬傳統工具鏈？

Anthropic 代碼量暴漲，GitHub 密鑰掃描又慢又貴，兩家被迫改造系統。作者丨鄭佳美 編輯丨岑 峰 Git 已經支撐軟件開發二十多年，Anthropic 卻決定把它換掉。為了讓 Claude 持續生成的代碼順利進入開發流程，7 名工程師花了 5 個月，開發出版本控制系統 Scion，並將核心代碼倉庫遷移過去。今年 5 月，Anthropic 每天平均合併約 2500 項代碼變更，到 9 月已超過 3 萬項，僅 CI 系統每天就要執行約 2500 萬次代碼檢出。寫代碼的速度上來了，準備倉庫、同步對象和查詢歷史卻越來越費機器。

幾乎同一時期，GitHub 用微調後的 ModernBERT 替換密鑰掃描中的通用 LLM 判斷。哥倫比亞大學與 Google DeepMind 等機構則通過 BTTF，把芯片仿真波形轉換成 SQLite，讓 Agent 使用 SQL 排查異常。Scion 默認在線，BTTF 將波形變成查詢接口，GitHub 把高頻判斷交給分類器。圍繞人類開發節奏設計的系統，開始承受 Agent 帶來的另一種負載。01Git 的離線能力，為什麼成了負擔Git 的分佈式設計讓工程師克隆倉庫後，即使斷網也能提交、合併、查看歷史。

但 Anthropic 大量讀取代碼的任務是始終聯網的 CI 作業和 Agent 沙箱，運行幾分鐘便銷燬，可能只需要幾個文件、一份 diff，或確認兩個提交的祖先關係。為了這些操作準備本地倉庫，重複成本越來越高。Anthropic 主分支歷史接近 100 GB，壓縮工作副本超過 25 GB。若每天 2500 萬次檢出分別獲取完整副本，理論流量會超過 600 PB。公司雖用淺克隆、稀疏檢出、快照和數百臺 Git 鏡像，但鏡像仍要同步、快照會過期，歷史查詢還需補齊對象。倉庫越活躍，維護成本越高。Scion 將客戶端縮成輕量入口。

提交創建、合併、變基與歷史查詢放到中心服務，本地僅監測文件變化、維護少量緩存，需要工作目錄時按需展開。CI 若只想計算 diff，可以直接調用 API，無須完整檢出。這犧牲了離線自治，卻減少重複初始化。提交格式也變了。Git commit 指向描述倉庫狀態的目錄樹，Scion 的 changeset 則以預寫日誌條目記錄相對首個父提交修改過的文件，通過內容尋址指針引用數據。創建 changeset 無須生成 Git packfile，也不用立即移動共享分支，只有 main 等引用更新時，系統才對 Spanner 中的單行記錄執行 compare-and-swap。

Agent 可以併發生成變更，競爭集中到分支引用移動時。但歷史查詢仍有難題：增量記錄無法直接回答某行是誰改的、文件經歷過什麼。Scion 為 blame、路徑歷史與提交圖跳錶維護 derived data，按父提交關係預計算，或等查詢發生後再生成。寫入與歷史分析可以獨立擴展。檢出時，scn 客戶端從目標目錄樹開始，只請求缺失的 tree 和 blob。請求依次經過節點上的 scion-daemon、區域 scion-cache，再由 scion-server 回源到 Spanner 或對象存儲。對象寫入後不可變，緩存能夠跨任務複用，減少協商、壓縮及反覆傳輸。

Anthropic 稱緩存命中率超過 99%，並限制故障時的回源流量。遷移後，Scion 相較舊 Git 鏡像體系的 CPU 和內存需求約縮小 200 倍，檢出從分鐘級降至秒級，CI 釋放約 25% 的 CPU 容量。200 倍說的是基礎設施資源佔用，並非 Git 操作整體提速。Anthropic 還同步建設 Antique 代碼評審、源碼搜索、IAM 和批量合併工具，以適配新協議。在線服務的維護也成了新成本。02讓數據庫讀波形，Agent 才能追查故障芯片驗證面對的是另一種障礙。

RTL 仿真產生的 VCD、FSDB 波形記錄大量信號隨時間變化的狀態，複雜設計的轉儲可能達到數十 GB，甚至 TB 級。工程師可以在波形查看器裡沿時間軸尋找異常，Agent 若把原始波形轉換成文本，上下文很快便被時間戳、信號名和重複跳變佔滿。追查其他信號，還可能重複讀取文件。另外，人類習慣用眼睛在圖表裡“大海撈針”，但 Agent 再大的上下文也裝不下幾十 GB 的物理文件。因此，將這些“死文件”轉化為可被 SQL 精準調用的“活接口”，是給 AI 喂數據的最優解。BTTF 把數據訪問交給 SQLite。

signalmetadata 保存信號名稱、類型和層級等靜態信息，signalchanges 記錄信號 ID、時間戳和變化後的值，兩表通過 ID 關聯。查詢某條信號在指定時刻的狀態，SQL 找到該時刻之前最近的變化記錄，要檢查一段時間內的翻轉，則按時間窗過濾與聚合。兩次跳變之間狀態不變，不能把沒有新記錄誤當作未知。模型只需處理問題與少量返回事件。比如某段握手協議超時，Agent 可以先檢索請求與響應信號的變化，再縮小到異常區間，檢查時序關係。數據庫負責檢索，模型決定下一步查什麼。查詢需對齊信號 ID、時間單位與 RTL 版本。但把波形搬進數據庫，並不會自動消除壓力。

高頻時鐘產生密集記錄，逐行 INSERT 又有事務成本。BTTF 在攝取時建立波形標識到數據庫 ID 的映射，統計信號跳變，結合時鐘過濾、無跳變信號裁剪和批量插入。未裁剪數據庫佔用 1420 MB，查詢約耗時 410.5 毫秒，過濾時鐘和無跳變信號後，規模降到 395 MB，耗時降至 94.8 毫秒。若繼續刪除跳變率低於平均水平的信號，數據庫能縮至 185 MB，但活動覆蓋率只剩 64.23%。罕見故障可能恰好出現在幾乎不翻轉的控制信號上。數據在導入階段被刪除，後面的 Agent 就無法恢復證據。裁剪要服從斷言與調試需求。

有了 SQL 接口，BTTF 再安排不同 Agent 分工：Orchestration Agent 拆解任務，Analysis Agent 生成查詢，Verification Agent 檢查斷言並關聯 RTL 源碼，Evaluation Agent 核查時間範圍、字段關係與結果完整性。例如 ASSERT_KNOWN 發現信號出現 X/Z 未知狀態，系統先鎖定違規時刻，再向前檢查相關操作數的狀態，逐步定位可能的模塊。SQL 出錯還可以修正後繼續。研究團隊在 4.2 GB 波形、18450 個信號和 150 條專家標註查詢的實驗中，取得 95.33% 的執行準確率。

Multi-Agent 質量評分比單 Agent 提高 17.3%，平均延遲也增至約 1.96 倍，靜態 SVA 檢查準確率為 84.62%。方案可支持後仿真分析，但持續攝取與複雜歸因仍需驗證。03為什麼密鑰掃描換回了分類器高熵字符串可能是真實憑據，也可能是測試數據、佔位符或校驗和。正則表達式能快速找到可疑格式，卻不擅長判斷代碼上下文，通用 LLM 可以幫助區分，但候選越多，推理費用和延遲便不斷累積。對於需要在代碼提交被接受前給出結果的 Push Protection，這種等待會直接影響開發體驗。GitHub 保留正則作為候選入口，將後續判斷交給微調後的 ModernBERT。

它讀取候選字符串、密鑰類型、變量名、文件路徑和附近代碼，輸出風險分類得分，再由閾值決定是否告警。編碼器經過前向計算就能返回類別，不需要像生成式 LLM 那樣逐 token 輸出解釋，適合批量處理同類請求。難點在於 hard negatives：字符串很像密鑰，卻是無害示例。GitHub 將產品反饋及人工標註、真實倉庫中的高召回候選、專門合成的困難負樣本組合起來，並按倉庫、候選值和關聯關係劃分訓練與評估集，減少相似數據帶來的評估偏差。否則模型可能記住文件名，卻難以辨認陌生項目中的憑據。部署時，模型導出為 ONNX 並進行 8 位量化，以降低推理資源開銷。

閾值還需要結合 Precision、Recall 與線上流量校準：太寬鬆會帶來誤報，過於嚴格則可能放過真實密鑰。出現新密鑰格式時，還需更新訓練集和規則。相較舊 LLM 管線，新方案的離線 Precision 提高 13%，Recall 提高 19%。線上 A/B 實驗顯示，Post-push 掃描執行時間中位數下降 86%，模型服務成本下降超過 98%，按倉庫所有者加權的告警接受指標提高 11.5%。這裡 98% 指模型服務費用，並非整套安全系統的總成本。分類器也只能判斷正則找到的候選，前置規則的覆蓋範圍仍限制漏報表現。

規則發現線索，分類器完成判斷，開放式分析仍可交給通用 LLM，避免每次固定判斷承擔生成式推理成本。04接下來可能輪到 CIGitHub 縮短了安全掃描的反饋時間，代碼接下來仍要經過構建、測試和部署。Anthropic 在解決源碼檢出問題後，也遇到了新的麻煩：一輪測試尚未結束，主分支可能又合入數百甚至數千項修改。繼續依賴全局鎖會讓變更不斷積壓，放開併發又會帶來新的風險，即便某次測試已經通過，它對應的代碼狀態也可能與準備部署的版本出現差異。這意味著 CI 接下來要處理的，是驗證結果如何在高頻變更中保持有效。

構建緩存需要識別源碼與依賴關係的變化，測試記錄必須關聯具體提交和構建產物，系統還要判斷哪些結果能夠複用、哪些修改會使此前的驗證失效。對於依賴關係複雜的 Monorepo，僅僅增加測試機器，很難解決併發修改帶來的版本一致性問題。Anthropic 已經開始強化合並後測試與部署前驗證。對普通團隊而言，先完善依賴分析、增量測試和構建緩存，比直接重建版本控制系統更現實。隨著 Agent 持續提高代碼產出，軟件工程的瓶頸還會沿著交付鏈路向後移動。代碼進入主分支的速度可以越來越快，但構建、測試與部署之間必須保留可靠的驗證關係。

未來可能會有越來越多的例子說明，AI 寫代碼的狂飆突進，最終倒逼著整條軟件工程流水線被迫“重做一遍”。工程基礎設施的價值，也將更多體現在能否讓高速變化的代碼持續獲得可信的交付依據。參考鏈接：https://www.anthropic.com/engineering/redesigning-source-control上車，帶你看遍全球 AI 頂會精華可獨家暢覽：專家演講PPT大會報告全文熱門論文解讀學術新星訪談掃描上方二維碼或點擊「閱讀原文」關注專區。