先地圖，後審查

在一個提取要求的兩端，坐著兩項不同的工作。在代理動筆之前，它需要一張即將修改的程式碼樹的地圖。在代理開啟 PR 之後，應該有什麼東西對照系統的其餘部分來讀這個變更，並留下人類可以據以行動的評論。

這兩項工作從遠處看很相似，因為二者都涉及「理解程式碼庫」。但它們不是同一個產品。一個回答的是「這個改動應該落在哪裡？」。另一個回答的是「這個 diff 破壞了什麼，而逐行檢查的程式碼檢查工具會漏掉？」。把它們混為一談，只會產出更差的初稿和更嘈雜的審查。

這篇文章是一份聯合工作流程指南。Maguyva 是代理首先查詢的地圖。Greptile 是隨後為 PR 新增評論的審查代理。這個搭檔在設計上就是互補的：Maguyva 不審查提取要求，Greptile 也不會取代代理用來撰寫這些改動的上下文層。

為什麼這種分工有用

一個從訓練先驗加上幾個貼上檔案出發的編碼代理，會編造一條看似合理的路徑並編輯它。這就是錯誤檔案的失敗模式，是一個檢索問題。Maguyva 是一個遠端 MCP 程式碼庫上下文層：語意、結構（AST）、圖／依賴和文字檢索融合成排序結果，再加上符號查詢和檔案擷取。有依據的答案以 path/file.ext:line 的形式傳回，讓你能在補丁存在之前就拒絕一個錯誤的結果。這個主張保持謙遜：更少的幻覺編輯。模型仍然可能猜測。只是第一步不再是猜測。

Greptile 是一個 AI 程式碼審查代理。用他們自己的話說，它以對程式碼庫的完整理解自動審查每一個提取要求，並將這與孤立檢查檔案、而非整個系統的傳統程式碼檢查工具相對照。它的設定就是安裝 GitHub 或 GitLab 應用程式並選擇儲存庫。沒有需要你維運的本機索引。託管方式是 Greptile Cloud（他們表示符合 SOC 2 Type II，並可應要求提供報告），也為企業提供自託管選項。

他們自己的編號流程是：連接儲存庫，並為每個函式、類別和依賴建置依賴圖；在每個提取要求上，使用那張完整儲存庫圖分析變更，並在大約三分鐘內以附修復建議的 PR 評論形式發布結果；每條評論都可以把問題移交給團隊已經在用的編碼代理。他們還表示會持續閱讀先前人類留下的 PR 評論，以學習團隊的編碼標準並減少嘈雜的建議。據他們所說，這套學習系統需要 2 到 3 週來適應。

這是審查，不是起草。Greptile 的突出之處在於，針對已經落地到 PR 中的變更提供完整儲存庫圖上下文，隨後是一個閉環，把發現結果發給 Claude Code、Codex、Conductor、Cursor 或 Devin。Maguyva 的突出之處在於代理在那次變更被寫下之前查詢的排序地圖。兩者都用。不要要求任何一方去做另一方的工作。

Maguyva 與 Greptile 之間沒有宣布任何官方第一方產品整合。你也不需要。Maguyva 透過 MCP 與代理對話。Greptile 透過自己的應用程式與 GitHub 或 GitLab 對話。它們在提取要求處相遇。沒有黏合用的腳本，也沒有把一個工具接到另一個工具的排程任務。這個搭檔不需要 bash，因為每個產品都已經站在自己應有的位置上。

這不是什麼

這不是對 Greptile 的拆解。這不是一篇「換個審查工具」的文章。Greptile 於 2024 年 3 月 5 日作為 Y Combinator W24 公司在 Hacker News 上發表，那篇貼文是很多人第一次瞭解這款產品的方式。如果你也是這樣發現他們的，那就繼續用。這個頁面補上的是那個迴圈中缺失的前半段：先讓代理紮根，使 Greptile 看到的那個 PR 一開始就瞄準了正確的檔案。

Greptile 的行銷材料主打審查速度和抓 bug 能力的說法。請把這些當作 Greptile 自己的說法，而不是獨立核實過的數字。本文不會把它們當作事實重複。

語言覆蓋也是同樣的誠實問題。Greptile 把支援範圍表述為覆蓋所有程式語言，而不是一份列舉清單；沒有給出精確的數字。Maguyva 公開支援 279 種以上的語言和基於文字的技術，並在涉及技術問題時，在網站上給出技術上的細分（有解析器支援的 AST 與純文字）。這是兩個不同的產品，做出不同的聲明。不要把它們混為一談。

Greptile 的定價沒有出現在本文可以使用的資料中。付費方案是存在的；請參考他們的定價頁面。Maguyva 按工作區計費，而不是按席位。方案從免費開始。如果你需要工作區數字，定價頁面 上列出了公開的方案。

工作流程

三個有名字的階段。按這個順序執行。第一次嘗試這個搭檔時，一個都不要跳過。

1. Maguyva 上下文

索引一個你已經瞭解的儲存庫。連接你已經在用來寫程式碼的 MCP 用戶端——Claude Code、Cursor、Codex CLI、VS Code、Windsurf，或者其他 MCP 相容用戶端。Maguyva 為 24 個有文件記錄的 MCP 用戶端提供設定指南，也能連接支援標準 MCP 設定的其他用戶端。

在任何人寫下一行程式碼之前，先問一個你能評判的問題。「工作階段過期在哪裡處理，什麼在呼叫它？」比「修一下認證」是更好的第一步。要求引用。開啟 file.ext:line 結果。跟著符號走。確認你即將觸碰的依賴關係。

Maguyva 提供 11 個面向客戶的 MCP 工具，涵蓋搜尋、符號、依賴分析、檔案檢索、儲存庫上下文和確定性實用工作流程。四種檢索模式融合成排序結果；當你已經知道名字時，find_symbol 是一個獨立的工具。文件 描述了最短路徑：先免費開始，索引一個你已經瞭解的儲存庫，連接用戶端，然後問一個你能核實的問題。

快照帶有時間戳，因此代理能判斷自己讀到的是哪個版本的程式碼樹。誠實的限制是未同步的本機工作。如果編輯只存在於工作樹中，還沒有被推送，託管地圖就還不包含它。指令檔案（CLAUDE.md、AGENTS.md）在這裡依然有它們的位置，用來記錄慣例和不該觸碰的東西。它們不是一張活的地圖。用它們來規範行為。用 Maguyva 來核實事實。

在引用經受住與儲存庫接觸的考驗之前，不要讓代理開啟 PR。這道關卡就是這個階段的全部意義所在。

2. 代理 PR

同一個代理現在會在你已經付費使用的用戶端裡寫下這個改動。Maguyva 既不是編輯器，也不是審查者。代理仍然負責生成 diff。你仍然像以前一樣，在 GitHub 或 GitLab 上開啟提取要求。

應該不同的是第一個檔案。這個 PR 應該點明實際實作該行為的處理函式、將會被破壞的呼叫端，以及在改動出錯時會失敗的測試。如果第一階段被跳過了，第三階段就會把評論花在一個落在錯誤套件裡的改動上。Greptile 依然能發現系統性的問題。但它不應該還要從一條幻覺出來的路徑中恢復過來。

把 PR 的範圍控制好。一個有依據的第一個檔案，不是重寫整個模組的許可證。這個互補的搭檔之所以有效，是因為代理先帶著地圖完成了一項工作，然後請審查者在一個有邊界的 diff 上完成另一項工作。

3. Greptile 審查

Greptile 已經透過 GitHub 或 GitLab 應用程式連接到儲存庫。在新的提取要求上，它使用自己建置的完整儲存庫圖分析改動，並以附修復建議的評論形式發布結果。他們自己的材料把這個過程的時長定在大約三分鐘。

像讀一位仔細的隊友那樣讀這些評論：開啟被引用的位置，判斷這個發現是否真實，然後再行動。當 Greptile 提供「Fix with your Agent」時，它會把問題——檔案路徑、行號、建議程式碼——傳送給 Claude Code、Codex、Conductor、Cursor 或 Devin。「Fix All」會一次性傳送審查中的所有問題。他們還為這次移交提供了 Greptile MCP 和一個 Claude Code 外掛。Maguyva 不在那份具名的目標清單上；這種缺席不是問題。Maguyva 已經在第一階段完成了自己的工作。寫下這個 PR 的編碼代理，才是應該接收修復負載的那一方。

在最初的 2 到 3 週裡，預期會有一些噪音，因為 Greptile 的學習系統正在適應你團隊實際留下的評論。這是他們公布的時間表，不是這個搭檔的缺陷。人類審查依然在這個迴圈裡。Greptile 是自動化的第一道關卡，不是合併按鈕。

如果一條 Greptile 評論指向了代理在第一階段從未查詢過的檔案，這是一個有用的訊號。要麼是地圖漏掉了一個呼叫端，要麼是代理跳過了一次引用。針對這條評論修正草稿。不要關掉審查者。

如何保持這種互補關係的誠實

• Maguyva 永遠在先。對一個錯誤檔案的 PR 進行審查，依然是在審查錯誤的檔案。
• Greptile 永遠在後。一份引用充分的草稿，依然需要一次系統層面的 diff 通讀。
• 不要要求 Maguyva 發布 PR 評論。它不會這麼做。
• 不要要求 Greptile 在代理還在選擇路徑時，充當它的第一層檢索工具。這不是他們的 GitHub 或 GitLab 應用程式被設計來做的事。
• 不要編造一個「同步」兩者的 bash 管線。PR 就是介面。
• 獨立地驗證兩端。索引一個你已經瞭解的儲存庫。問一個你能核實的問題。然後開啟一個小的 PR，看看 Greptile 實際上評論了什麼。

一旦被命名，這個迴圈就很普通了。先地圖。再代理 PR。再審查。每個產品都留在自己擅長的那一側提取要求上。

// map first. review second. in that order.