# 先地圖，後審查

Canonical source: https://maguyva.ai/zh-hant/blog/map-first-review-second

License: text under [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/); code samples under [MIT-0](https://opensource.org/license/mit-0); the Maguyva name, logos, brand assets and other code are not covered. Details: [maguyva.ai/license](https://maguyva.ai/license).

Date: 2026-09-07 · Author: Maguyva Team

> 在編碼代理動筆之前，先讓它紮根於一張儲存庫地圖。之後再讓 Greptile 審查這個提取要求。這是互補的搭檔，不是替代關係。

在一個提取要求的兩端，坐著兩項不同的工作。在代理動筆之前，它需要一張即將修改的程式碼樹的地圖。在代理開啟 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 按工作區計費，而不是按席位。方案從免費開始。如果你需要工作區數字，[定價頁面](/zh-hant/pricing) 上列出了公開的方案。

## 工作流程

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

### 1. Maguyva 上下文

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

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

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

快照帶有時間戳，因此代理能判斷自己讀到的是哪個版本的程式碼樹。誠實的限制是未同步的本機工作。如果編輯只存在於工作樹中，還沒有被推送，託管地圖就還不包含它。指令檔案（`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.`