Daksh Gupta：如何打造更好的 AI 代码审查智能体

我是 Daksh Gupta，Greptile 的联合创始人。我们开发智能体，结合完整代码库上下文来审查和测试 PR，寻找 bug、逻辑错误和代码质量问题，尤其关注 AI 生成的代码。每天有数千家公司使用 Greptile。Gupta 说，GitHub 上大约 1% 的 PR 会经过这项服务。

有些公司的需求非常特殊，自己搭建审查器反而更合适。Greptile 会帮助这类团队，因为我们积累了代码审查、沙箱运行应用，以及高效分配推理资源的经验。今天我会介绍这套方法，供想自建审查器或想判断产品优劣的团队参考。

Gupta 把产品优势归纳为三方面。第一是代码库上下文：在转向代码验证之前，Greptile 就在研究如何让早期语言模型理解大型代码仓库，并因此打下了扎实的索引能力。第二是把客户的技术栈放进依赖齐全的沙箱，再通过计算机操作来测试应用和 API 端点。

第三是谨慎分配推理资源：为审查和验证流程中的每个子任务选择合适的模型与推理预算。Gupta 认为，这样的组合能比内部工具或竞争产品以更低成本取得更好的效果。

团队可能是想自建审查器，也可能正在挑选审查或测试智能体，想知道够用的产品和优秀的产品究竟差在哪。Gupta 从最简单的方案讲起，说明它为何会出问题。

设想你在平台团队工作，或者是团队里最积极推动 AI 的工程师。工程师和营销团队都在用 vibe coding 快速写代码，审查与验证因此成了瓶颈。第一步是准备沙箱，可以使用服务商提供的环境，也可以用 Firecracker 等工具自己搭建。

把智能体放进沙箱，连接 GitHub 或 GitLab，再用 PR webhook 把每个新改动发给它。给智能体一条简单指令，让它审查 PR，然后通过 GitHub 的审查 API 返回评论。理论上，PR 打开后大约五分钟就能收到反馈。

问题从依赖这套简陋流程开始。首先，它会漏掉很多 bug。代码中的 bug 往往相互交织、层出不穷，而审查器至少得拦住可能导致严重宕机或事故的问题。

第二，智能体可能不了解代码库各部分如何协作、团队正在朝什么方向发展，也可能不熟悉某个库的工作方式。如果公司有成千上万个仓库，审查一个改动时可能需要参考其中多个仓库的上下文。

第三，成本可能出乎意料。Gupta 说，尝试用编程智能体审查 PR 的公司，单次花费在 3 至 25 美元之间。token 用量很快就会累积，成本可能在不知不觉中升高。

第四，智能体可能留下挑剔的小意见：它们在技术上说得通，却过于吹毛求疵。开发者得从一堆小风格问题里筛出真正严重的风险。更糟的是，编程智能体可能会不加判断地逐条处理这些评论，最后把代码库改得防御过度、难以维护。

同一个 PR 每次重新运行审查器，都可能发现一批新问题。这让团队很难判断什么时候才算审查完成，也说明系统必须把注意力放在真正有价值的发现上。

最容易着手的改进是把提示词写得更具体。除了要求它按 GitHub 评论格式输出，还要明确它应查找哪些重要 bug 类型，并跳过挑剔的小意见。团队可以分析过去的宕机和事故，找出代码库最容易出现的错误。

还要明确定义哪些情况属于吹毛求疵，例如没有具体风险却要求层层增加防护，或抱怨错误处理方式略显粗糙。提示词只改一点，评论数量也可能大幅变化，因此很难判断审查器是否真的变好了。

审查器能证明自己发现了 bug，却无法证明没有其他 bug。严重问题特别难评估，因为它们很少发生。Gupta 估计，大约每 1,000 个 PR 才有一个含有灾难性 bug；随后他也改口说，或许是每 1,000 行代码才有一个。智能体可能漏掉一个问题，却长时间看起来表现不错。

第二项改进是建立历史 PR 数据集。如果公司会记录宕机和事故，就整理出曾导致问题的 PR，再让每个新版本的审查器都检查这些案例。这样，团队调整提示词、衡量智能体是否能抓住已知问题时，就有了更明确的依据。

数据集需要定期更新，因为 bug 的模式和类型会随时间变化。许多 bug 是过去错误的重演，但越来越强的编程智能体也会带来全新的失误。没有数百万个 PR，公司很难覆盖足够多的 bug 类型。Greptile 能利用跨公司的大型 PR 集合进行测试；内部团队也可以从自己的数据中获得不少帮助。

第三项改进是模型反转：写代码和审查代码时使用不同系列的模型。Gupta 的研究显示，Claude 模型更容易出现单点错误，而 GPT 模型更容易产生权限绕过。这些差异在他看来可能来自模型后训练方式不同。

如果同一个模型既写代码又审查代码，它可能在两个环节重复同样的盲点。因此，如果 Claude Code 写了代码，可以换 GPT 模型来审查，反过来也一样。很多时候，识别作者模型并不难：Codex 可能会留下 codex/ 开头的分支名，Claude 则可能出现在 PR 描述或共同作者信息中。

剩下的情况更难判断，团队可能需要启发式方法、内部使用记录，或来自开发者电脑的遥测数据。Gupta 说，Greptile 观察到换模型后 bug 发现率提高了 10%。他认为，当问题可能导致事故或宕机时，这样的提升并不小。

第四项改进是补足代码库上下文。Gupta 说，Greptile 早在开始做代码验证前就在研究这个方向。他认为，单靠 grep 查找既不精确也很昂贵：编程智能体可能花很多 token 搜索、读取和缓存文件，即使其中不少内容都与当前问题无关。

更有针对性的做法，是建立一套内部知识库，梳理系统并为各个组成部分编制索引。以身份认证为例，知识库可以说明流程如何运作、画出关系图，并列出涉及的文件。检查权限绕过时，这些上下文尤其重要，因为审查器必须知道相关代码是否已经处于认证边界之内。

即使代码没有明显 bug，质量也可能很差：它或许根本没有满足作者的真实意图。Gupta 开玩笑说，人们越来越把 Slack 当 IDE 用，但一句简短的修复请求往往留下许多歧义。代码即使通过狭义的正确性检查，也可能解决错了问题。

要弥补这个缺口，就得给智能体更多上下文。Gupta 特别提到产品文档和工单，以及经过索引的代码库。让智能体访问 Jira 或 Linear，再加上 Confluence、Notion 等文档库，能补上许多工程师平时不自觉依赖的团队经验。

Greptile 把这些来源汇集到一份持续更新的 wiki 中，形成对公司运作方式的动态认识。它可以整合代码库知识、从生产遥测和日志中了解应用行为，再从文档与 Linear 工单中获取路线图信息。审查器既能利用这些背景，也能更准确地搜索代码。

第五项改进是自主测试。审查器查看 React 改动时，可能觉得代码没问题；但页面实际渲染后，按钮也许在 iPhone 上被挡住了。Greptile 的解决方法，是使用可配置的虚拟机，装齐应用依赖，并在其中运行客户的技术栈。

随后，智能体会用计算机视觉端到端测试应用。Gupta 说，新一代 GPT 和 Opus 模型的视觉能力大幅提升，让端到端质量保障第一次接近实用。团队仍需记录应用中的关键流程，并简化构建步骤，让智能体可以启动整套技术栈。

这套环境需要开发机、运行着 PR 分支和依赖的应用，以及一份流程图，例如哪些代码负责认证、用户怎样登录。有了这份图，浏览器智能体就能发现按钮虽然出现了，却在 iPhone 上被遮挡，或落在首屏之外。

即使具备这些能力，单次审查仍可能花费 3 至 20 美元。第六项改进是让部分子任务使用更便宜的模型。Gupta 认为，前沿模型整体仍更强，但 Greptile 只把约 20% 的模型用量留给最关键的任务，其余探索性工作和文件读取则交给多种小模型。

举例来说，小模型可以搜集相关上下文，轻量级计算机操作模型可以测试用户流程，而前沿模型负责分析 bug 并作出最终审查判断。Greptile 实际上有约 20 个子任务，每个任务都指定了合适模型，还有一支小型研究团队持续调整配置。

Gupta 估计，只要把简单工作换成简单模型，团队就可能达到完整方案 70% 至 80% 的效果。但大型评估数据集依然重要：否则，便宜的子智能体可能悄悄降低 bug 发现率，直到某次问题导致事故后，团队才意识到。

便宜的模型还可以筛选现有上下文，判断哪些内容值得载入，从而减少无效文件读取。理论上，团队可以用决策模型或 API 为上下文排序，再决定哪些内容应进入前沿模型的缓存；Gupta 认为，这是系统中成本最高、也最稀缺的资源之一。

把这些改进结合起来，团队就有机会打造出能力不错的代码审查智能体。Gupta 邀请听众做出来后联系他，邮箱是 daksh@prod.com；如果不想自建，也可以使用 Greptile。他最后向观众致谢。