如何打造 AI 程式碼審查代理——Greptile 創辦人 Daksh Gupta

Greptile 共同創辦人 Daksh Gupta 認為，多數自建 AI 程式碼審查代理的公司，幾天內就能做出可用的展示版本，但接下來就會開始漏抓 bug、誤判脈絡、推論成本失控，還會讓 pull request 被大量吹毛求疵的意見淹沒。他的演講本質上是一份實作指南：針對特定 bug 型別設計提示、用歷史 PR 資料集衡量抓錯率、模型反轉、程式碼庫索引，以及沙箱化的端到端測試。整集節目幾乎全在講這些做法；推銷 Greptile 自家產品的段落只佔開頭與結尾幾分鐘。

Gupta 來自一家大規模審查 pull request 的公司——他說 GitHub 上約 1% 的 pull request 都流經 Greptile，涵蓋的程式碼庫包括輝達的 CUDA 與 Coinbase 的錢包程式碼。他把這場演講定位成：Greptile 會怎麼跟需求過於特殊、產品無法滿足的潛在客戶說明，同時也是一份給所有正在評估審查代理的人的採購清單。讀者讀完應該能掌握具體的失敗模式、背後的數字，以及五步改進路徑。

基本審查代理幾天就能做出來，然後以五種可預測的方式失敗

最小可行的做法很直接：一個沙箱（向廠商購買或在 Firecracker 上自建）、沙箱內一個寫程式的代理（Codex 或 Claude Code，或 OpenCode、Pi 這類開源框架以保持模型獨立性）、一個 GitHub 或 GitLab 的 PR webhook 把 diff 送給代理，再用 GitHub 的審查 API 把意見貼回去。PR 開啟五分鐘後就有回饋。Gupta 說，很多人以為審查代理這樣就夠了。

接下來就是失敗清單，也是整場演講的主幹：

Gupta 最強調吹毛求疵的問題，因為它會複合放大：審查代理的輸出會餵給寫程式的代理，所以低品質的意見不只是煩人，還會讓程式碼品質變差。

提示要指名 bug 型別，並明確定義什麼叫吹毛求疵

最容易下手的修正就是提示。先從「審查這個 PR，並以 GitHub API schema 格式輸出意見」這類指令出發，然後朝兩個方向調整：找出特定型別的 bug，以及略過吹毛求疵。Gupta 建議挖內部故障與事故資料，整理出這個程式碼庫最容易產生的 bug 型別清單，再把這些型別寫進提示。另外，提示必須定義什麼算吹毛求疵——他舉的例子是要求單一元件做三層防禦，或是對稍微粗糙的錯誤處理大做文章。

陷阱在於，提示只要小改，意見數量就會劇烈波動，而審查者無法揭露反事實。用 Gupta 的話說，驗證代理「能告訴你有 bug，但很不幸地，它沒辦法告訴你沒有 bug」。依他的資料科學估算，大約每 1,000 行程式碼就有 1 行含災難級 bug，所以某個 bug 類別若被悄悄漏掉，可能很久都不會被發現。

歷史 PR 資料集是唯一能確認代理有沒有用的方法

要解決提示改動無法衡量的問題，就得靠一份標註過的歷史 pull request 資料集——對會把每起事故都建檔的公司來說並不難。拿任何候選版本的審查代理去跑這些 PR，衡量它抓到已知 bug 的比例，提示調校就從猜測變成量測。

限制在於漂移。Gupta 說 80–90% 的 bug 是重複過去的錯誤，但隨著寫程式的代理進步，它們會產生全新的失敗，所以資料集必須即時更新。覆蓋率才是真正的瓶頸：沒有數百萬個 pull request，單一公司根本取樣不到足夠的 bug 型別。這正是他劃分內部工具與 Greptile 界線的地方——Greptile 在橫跨多家公司的大型語料上測試，因此能「在邊際上再榨出一點點效能」。他也承認，內部團隊用自己的資料也能走得「相當遠」。

反轉模型：同一個模型審查，抓到的 bug 更少

Gupta 早先的研究（他引用 2026 年初在舊金山 AI Engineer 的一場演講）發現，Claude 與 GPT 模型的失敗方式不同。據他所述，Claude 模型產生差一錯誤（off-by-one error）的機率約是 GPT 的三倍，而 GPT 模型產生驗證繞過（auth bypass）的機率明顯更高——他歸因於後訓練留下的痕跡。因此，用寫出程式碼的模型來審查，抓到的 bug 會比較少，因為生成與審查會在同一處失手。在 Greptile 的測試中，反轉模型讓抓錯率提高 10%，他把它說成事故少了 10%。

判斷 PR 是哪個模型寫的，約 80% 的情況很容易，其餘則很難。Codex 會把分支命名為 codex/branch-name；Claude 會在 PR 描述與 commit message 裡寫「co-authored by Claude」。剩下 20%——手動建立的分支、混用工具——就得靠啟發式規則、內部記錄工程師用哪些代理的清單，或開發者機器上的遙測資料。

Grep 既不精準又昂貴；程式碼庫知識庫自己就能回本

Gupta 反駁「grep 已經解決程式碼庫脈絡問題」這種說法。他的論點有兩部分。第一是精準度：grep 讀取的檔案遠超過實際所需。第二是宏觀成本——他聲稱去年 GDP 成長中有個位數百分點來自推論，其中很大一部分是寫程式的代理，而寫程式代理的 Token 大多花在同樣三種操作上：grep、讀檔、寫入快取。他還語帶諷刺地補了一句「按 Token 計費的公司有反向誘因」。

Greptile 的替代方案是內部知識庫，把程式碼庫的每個部分都建檔——以驗證為例，包括它怎麼運作、有哪些流程、流程圖，以及牽涉到的每個檔案。背後的動機案例是偵測驗證繞過，這需要具體知道某條程式碼路徑是否位於已驗證的環境中。Greptile 把它延伸成「活的 wiki」，把各種脈絡來源去中介化：程式碼、生產環境遙測與日誌、檔案，以及 Linear 工單。這個 wiki 既提供脈絡，也讓搜尋更精準，代理「永遠不會讀到它不需要讀的檔案」。

程式碼正確也可能錯：檔案與工單提供意圖

Gupta 把「壞 PR」的定義從 bug 擴大到品質與意圖。他的例子是把 Slack 當 IDE 用：一、兩句話的需求幾乎沒有表達出意圖，寫程式的代理不是誤讀指令，就是無法化解歧義。結果就是程式碼正確，但仍然是錯的。解方是更多脈絡——JIRA 與 Linear 工單，加上 Confluence、Notion 或任何存放檔案的地方——因為很多人類寫出好程式碼的隱性知識默默在起作用，沒有這些脈絡的代理「就是不知道發生了什麼事」。

在滿載的沙箱裡做端到端測試，幾乎已經解決

有些缺陷在 diff 裡看不出來。Gupta 的例子是：React 的改動讀起來沒問題，卻讓某個控制項在 iPhone 上被藏起來。Greptile 的答案是可設定、相依套件齊全的 VM 沙箱，能啟動客戶的完整技術堆疊，由代理透過 computer use 操作應用程式，或對 API 端點做壓力測試。他說 computer use 在目前的 GPT 與 Opus 世代進步很大，「我認為端到端 QA 第一次快要被解決了」。

兩個前提決定成敗：應用程式要有檔案化的流程，以及建置指令碼要簡單到代理能自己把整套堆疊架起來。Greptile 派駐前線工程師協助客戶處理這件事，Gupta 說這是最棘手的部分之一——除非公司本來就有好的開發機，那「恭喜你在 Stripe 上班」。必備的元件是：一臺開發機、用 PR 分支的相依套件跑起應用程式，以及一份流程地圖（驗證程式碼、註冊流程等），這樣視覺模型才能抓到像按鈕技術上存在、卻在 iPhone 上被藏起來或在摺疊機上掉到摺線以下的問題。

把 80% 的 Token 導向便宜模型——但前提是有資料集可以驗證

就算代理做得再好，每次審查也要 3 到 20 美元，所以最後一個槓桿是推論資源的分配。Gupta 仍認為前沿模型優於開源模型，不過「橡皮筋正在拉緊」。Greptile 目前的分法是約 20% 用前沿模型處理最關鍵的任務，較小的模型負責探索性讀取這條長尾。以一個示意性的路由為例：小模型找脈絡，輕量的 computer-use 模型測使用者流程，前沿模型分析 bug、套用審查流程並提交。實務上 Greptile 跑大約 20 個子任務，每個都有自己的模型組合，由一個小型研究團隊持續重新調整分配。

flowchart TD
    A["PR webhook 觸發"] --> B["小模型：尋找脈絡"]
    B --> C["程式碼庫 wiki 與索引"]
    C --> D["輕量 computer-use 模型：在沙箱中測試流程"]
    D --> E["前沿模型：分析 bug 並套用審查流程"]
    E --> F["前沿模型：提交審查意見"]
    F --> G["寫程式的代理處理意見"]

Gupta 警告，沒有好的資料集，把子代理換成便宜模型看起來像免費：代理會悄悄變差，你要等到它漏掉某個東西、造成事故時才會發現。他也建議用便宜的決策或重排序模型（他點名 Jev 和一個 Decisions API）來決定哪些脈絡片段要放進前沿模型的快取，並稱那個快取是最貴也最稀缺的資源。

結尾的張力是結構性的。Gupta 自己的建議——用歷史 PR 衡量、反轉模型、索引程式碼庫、架起沙箱、依子任務分配推論——描述的是一套需要研究團隊和數百萬 PR 語料才能運作良好的方案。這正是他說內部工具填不上的缺口，也是他願意幫助任何嘗試者的原因：「如果你選擇不自己做，那也可以直接用我們的產品，相較之下是免費的。」每 1,000 行就有 1 行災難級 bug 的比例，以及模型反轉帶來 10% 增益，這兩項在其他公司的程式碼庫上是否成立，才是值得追蹤的重點；兩者都是 Greptile 自家的數字，並未提供外部來源。