# 先地图，后审查

Canonical source: https://maguyva.ai/zh-hans/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-hans/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-hans/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.`