先地图，后审查

在一个拉取请求的两端，坐着两项不同的工作。在智能体动笔之前，它需要一张即将修改的代码树的地图。在智能体打开 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.