隨著程式碼代理工具愈來愈強大，我們反而花了更多時間在審查上。為了解決這個問題，我們打造了 Bugbot，一個程式碼審查 Agent，會在程式碼進入 production 之前，分析 PR（拉取請求）中的邏輯錯誤、效能問題與資安弱點。到了去年夏天，它的成效已經好到我們決定對外推出給使用者。

打造 Bugbot 的過程從定性評估開始，逐步演變為更系統化的方法，使用自訂的 AI（人工智慧）驅動指標，以爬坡式方式持續優化品質。

自從上線以來，我們已經執行了 40 個大型實驗，將 Bugbot 的問題解決率從 52% 提升到超過 70%，同時也把每個 PR（拉取請求）平均標記出的錯誤數量，從 0.4 提升到 0.7。這代表每個 PR（拉取請求）中被解決的錯誤數量已超過一倍，從大約 0.2 成長到約 0.5。

#卑微的起點

當我們第一次嘗試打造程式碼審查代理時，當時的模型還不夠強大，產出的審查結果很難提供實質幫助。

不過，隨著基礎模型能力的提升，我們意識到有許多可以調整的手段，可以用來提升錯誤回報的品質。我們嘗試了各種模型、pipeline、過濾器以及聰明的上下文管理策略的組合，並在過程中持續向內部工程師徵詢意見。只要看起來某個組合有較少誤判，我們就會採用它。

我們在早期發現的其中一項最有效的品質改善，是同時平行執行多次尋找 bug 的流程，並用多數決來彙整結果。每一次流程都會收到不同排序的 diff，藉此引導模型走向不同的推理路徑。當多個流程獨立地標記出同一個問題時，我們就把它視為這個 bug 真的存在的更強訊號。

經過數週的內部質性迭代後，我們最終得到一個 Bugbot 版本，在市場上的表現優於其他程式碼審查工具，也讓我們有信心正式推出。它使用的流程如下：

1. 以隨機化的 diff 順序進行 8 次平行流程
2. 將相似的 bug 合併到同一個群組（bucket）
3. 透過多數決過濾掉只在單次流程中出現的 bug
4. 將每個群組合併成一段清楚的描述
5. 過濾掉不需要的類別（例如編譯器警告或文件錯誤）
6. 將結果送進驗證模型以抓出誤判
7. 與先前執行所回報的 bug 做去重

#從原型到正式上線

為了讓 Bugbot 在實務上真正好用，我們除了核心審查邏輯之外，還必須投入打造一套基礎系統。這包括用 Rust 重建我們的 Git 整合、盡量減少擷取的資料量，讓儲存庫（repository）存取變得快速且可靠，同時加入頻率限制監控（rate-limit monitoring）、請求批次處理，以及以 Proxy 為核心的基礎架構，才能在 GitHub 的各項限制下運作。

隨著採用度提升，各團隊也需要一種方式，能將程式碼庫特有的不變條件（invariants）編碼起來，例如不安全的資料庫遷移（migration），或對內部 API 的錯誤使用。為此，我們加入了 Bugbot 規則，以支援這類檢查，而不必將它們硬編碼進系統。

整體來說，這些組件讓 Bugbot 在實際運行上變得可行，並能適應真實世界的程式碼庫。但它們無法告訴我們品質是否真的在提升。如果沒有衡量進展的指標，我們就無法量化評估 Bugbot 在真實環境中的表現，而這也形成了我們能將它推進多遠的上限。

#衡量真正重要的事

為了解決這個問題，我們設計了一個名為「解決率」的指標。它會在 PR（拉取請求）合併時，使用 AI（人工智慧）判斷哪些 bug 實際上已經由作者在最終程式碼中修復。在開發這個指標時，我們會與 PR 作者一起在內部抽查每個範例，結果發現 LLM 幾乎都能正確判定這些問題是否已被解決。

團隊經常詢問我們如何評估 Bugbot 為他們帶來的影響，因此我們會在儀表板中顯著呈現這個指標。對正在評估效果的團隊來說，這比零星回饋或留言中的反應要清楚得多。解決率能直接回答一個問題：Bugbot 是否正在找出工程師實際會修復的真實問題。

#Hill-climbing 式優化

定義「解決率」改變了我們打造 Bugbot 的方式。這是我們第一次可以根據真實訊號，而非只是憑感覺來做 hill-climbing 式優化。我們開始在線上用實際的解決率評估變更，並在線下使用 BugBench——一個由真實程式碼 diff 與人工標註錯誤精選組成的基準測試集——來進行評估。

我們在模型、提示（prompts）、迭代次數、驗證器、脈絡（context）管理、類別篩選，以及代理式設計等面向上，進行了數十種實驗。令人意外的是，許多變更反而讓我們的指標退步。結果證明，我們先前從早期質性分析得到的許多初步判斷其實是正確的。

#代理架構

我們在今年秋天將 Bugbot 切換為完全以代理為核心的設計時，看到了最大幅度的成效提升。代理可以對 diff 進行推理、呼叫工具，並自行決定要在哪裡深入挖掘，而不是遵循固定順序的多輪檢查。

這種代理迴圈迫使我們重新思考提示設計。在早期版本的 Bugbot 中，我們需要嚴格約束模型，以盡量減少誤報。但在代理式做法下，我們遇到的是相反的問題：它變得過於謹慎。我們改用更積極的提示，鼓勵代理調查每個可疑模式，並傾向於標記潛在問題。

此外，代理架構也開啟了更豐富的實驗空間。我們能夠將更多資訊從靜態 context 中移出，放入 動態 context，調整模型在一開始收到多少 context，並觀察它如何適應。模型會在執行期間穩定地拉取自己所需的額外 context，而不必預先一次性提供所有內容。

同樣的架構也讓我們可以直接對工具組本身做迭代。由於模型的行為會受到其可呼叫工具的影響，即使是工具設計或可用性上的小改動，也會對結果產生極大的影響。經過多輪迭代，我們調整並打磨了這個介面，直到模型的行為能夠持續與我們的預期保持一致。

#下一步

目前，Bugbot 每月會為 Rippling、Discord、Samsara、Airtable 和 Sierra AI 等客戶審查超過兩百萬個 PR（拉取請求）。我們也在 Cursor 的所有內部程式碼上使用 Bugbot。

展望未來，我們預期會定期有具備不同優缺點的新模型推出，來自其他提供者，也來自我們自己的訓練工作。要持續取得進展，就必須找到模型組合、harness 設計，以及審查結構的最佳搭配。今天的 Bugbot 已經比剛推出時強大數倍；再過幾個月，我們預期它又將有顯著提升。

我們已經在為這個未來積極打造功能。我們剛推出處於 Beta 階段的 Bugbot Autofix，它會自動啟動一個 Cloud Agent，來修正在 PR（拉取請求）審查期間發現的錯誤。下一階段的主要能力包括：讓 Bugbot 能自行執行程式碼來驗證自己的錯誤回報，並且在遇到複雜問題時啟動深入研究。我們也在嘗試一個常駐運行的版本，持續掃描你的程式碼庫，而不是等候 PR（拉取請求）。

到目前為止，我們已經取得了長足進展，而這一切都要歸功於幾位關鍵成員的貢獻，包括 Lee Danilek、Vincent Marti、Rohan Varma、Yuri Volkov、Jack Pertschuk、Michiel De Jong、Federico Cassano、Ravi Rahman 和 Josh Ma。接下來，我們的目標仍然是幫助你的團隊在 AI（人工智慧）開發工作流程擴張的同時，維持程式碼品質。

閱讀文件 或 立即試用 Bugbot。