大規模編排AI程式碼審查

在大型工程團隊中，程式碼審查是至關重要的環節，但也常常成為瓶頸。合併請求在佇列中等待，審查者需要切換上下文，指出一些變數命名的問題，作者再回復，如此迴圈。在Cloudflare內部，很多專案的首次審查中位等待時間長達數小時。為了解決這個問題，Cloudflare構建了一套CI原生的AI程式碼審查系統，利用開源編碼代理OpenCode，實現了從傳統人工審查到自動化智慧審查的轉變。

起初，團隊嘗試了市面上一些AI程式碼審查工具，但它們缺乏足夠的靈活性，無法滿足Cloudflare這樣規模的組織需求。於是，他們轉向直接使用大語言模型，將git diff放入簡單的提示詞中，結果產生了大量噪音，包括模糊的建議、幻想的語法錯誤以及冗餘的錯誤處理建議。顯然，簡單的總結方法無法滿足複雜程式碼庫的需求。

最終，Cloudflare決定圍繞OpenCode構建一個CI原生的編排系統。當工程師提交合並請求時，系統會啟動一組協調的AI代理進行審查。系統最多支援七個專門的審查者，分別負責安全、效能、程式碼質量、文件、釋出管理、內部合規（Engineering Codex）等。這些審查者由一個協調代理管理，它負責去重、判斷問題的嚴重性，併發布結構化的評論。

系統的核心是可組合的外掛架構。每個外掛實現了ReviewPlugin介面，包含三個生命週期階段：Bootstrap（併發非致命）、Configure（順序致命）和postConfigure。透過ConfigureContext API，外掛可以註冊代理、新增AI提供者、設定環境變數等，但無法直接訪問最終配置物件，從而實現了隔離。例如，GitLab外掛無需瞭解Cloudflare AI閘道器的配置。

為了控制成本並提高效率，系統引入了風險層級分類。根據diff的大小和性質，合併請求被分為Trivial（瑣碎）、Lite（輕量）和Full（完整）三種。Trivial級別的更改（如拼寫錯誤修復）僅使用兩個審查者，而Full級別則啟動全部七個專門的代理。此外，系統還透過diff過濾去除噪音檔案（如鎖檔案、壓縮資產等）。

在模型選擇上，協調代理使用頂級模型（如Claude Opus 4.7和GPT-5.4），而子審查者根據任務複雜度使用標準模型（如Claude Sonnet 4.6、GPT-5.3 Codex）或輕量模型（如Kimi K2.5）。所有模型分配均可在執行時透過Cloudflare Worker動態覆蓋，以應對提供者故障。

系統還實現了斷路器模式，每個模型層級維護獨立的健康狀態。當模型失敗時，系統會遍歷回退鏈尋找健康的替代模型。例如，如果Opus 4.7不可用，則回退到Opus 4.6。此外，錯誤分類器區分可重試的API錯誤（如429、503）和其他不可重試的錯誤（如認證失敗、上下文溢位），確保只有可重試的錯誤觸發模型回退。

在提示詞注入防護方面，系統對使用者控制的內容進行了清理，移除了可能破壞XML結構的邊界標籤。共享上下文檔案機制避免了重複傳遞MR上下文，顯著降低了令牌消耗。

經過30天的執行，該系統在5,169個倉庫上完成了131,246次審查，共處理48,095個合併請求。中位數審查耗時3分39秒，中位數成本0.98美元。系統共產生159,103個發現，其中程式碼質量審查者貢獻了近一半（74,898個）。安全審查者的關鍵問題比例最高（4%）。令牌使用方面，總處理量約1200億令牌，快取命中率高達85.7%，節省了大量成本。

儘管取得了顯著成效，Cloudflare也坦誠地指出了系統的侷限性。AI審查不擅長理解架構意圖、跨系統影響以及細微的併發錯誤。此外，審查成本會隨diff大小增加。系統並非旨在取代人工審查，而是作為輔助工具，幫助工程師更快、更安全地交付程式碼。

目前，該系統已整合到GitLab CI中，團隊只需在.gitlab-ci.yml中新增一行配置即可使用。它也可以本地執行，提供與CI相同的審查體驗。Cloudflare計劃繼續最佳化，並歡迎社群反饋。