如何打造高效AI代码审查Agent：提示词与模型反转实战

AI 代码审查 Agent 正在成为平台团队的新基建。当公司里所有人都在 vibe coding，审查瓶颈就会迅速出现。本文基于一场实战分享，拆解从沙箱搭建到提示词优化、模型反转、代码上下文注入，再到端到端测试的完整链路，并指出每个环节最容易踩的坑。

从沙箱到 PR 反馈：最小可行审查 Agent

搭建一个能用的审查 Agent 并不复杂。你需要一个沙箱环境（Firecracker 或市面上的沙箱服务均可），把 Agent 放进去，选一个模型无关的 harness 如 OpenCode 或 Py，接上 GitHub 或 GitLab 的 PR webhook，收到 PR 内容后让 Agent 审查，再通过 GitHub review API 把意见写回 PR。

这个最小系统跑通后，大约五分钟就能在 PR 上看到反馈。很多人以为这就是审查 Agent 的全部，但真正的问题会在使用中逐一暴露。

Firecracker 是 AWS 开源的轻量级虚拟化技术，基于 KVM 实现 microVM，能在毫秒级启动并保持强隔离性，常用于需要安全执行不可信代码的场景。在审查 Agent 中，沙箱的作用是让 Agent 可以自由运行测试、安装依赖甚至执行 PR 中的代码，而不污染宿主机或访问敏感数据。如果不想自建 Firecracker，也可以选择 E2B、Modal 等托管沙箱服务，它们提供类似的隔离执行环境与 API。

所谓模型无关的 harness，指的是把「推理模型」与「工具调用、文件读写、终端执行」解耦的运行时框架，例如 OpenCode 或 Py。它不绑定特定模型供应商，方便后续做模型反转和成本分层，只需替换底层模型即可。

四个必然踩中的坑：漏 Bug、缺上下文、成本高、太啰嗦

第一个坑是漏 Bug。Bug 在代码里近乎分形无限，一个系统再努力也无法穷尽。更麻烦的是，审查 Agent 只能告诉你 Bug 存在，无法告诉你 Bug 不存在——你永远不知道反事实是什么。

第二个坑是缺上下文。Agent 不理解代码库的走向，不理解某个库的运作方式。如果公司经历过微服务拆分，仓库数量庞大，上下文缺失会更严重。

第三个坑是成本。用编码 Agent 审查单个 PR，花费可能在 3 到 25 美元之间，Token 消耗累积速度远超预期。

第四个坑是挑剔评论。技术上正确但过度迂腐的评论会带来双重伤害：人类读者被噪音淹没，难以分辨哪些是灾难性问题；而编码 Agent 会不加辨别地逐条解决所有评论，最终把代码库改得过度防御、面目全非。

优化提示词：瞄准具体 Bug 类型，明确跳过挑剔项

最低垂的果实是优化提示词。初始提示词往往是“审查这个 PR 并按 GitHub API schema 输出评论”，这远远不够。提示词应该围绕两个主题重构：第一，要求 Agent 寻找具体的 Bug 类型；第二，明确告诉它什么是挑剔评论、不要找这些。

具体 Bug 类型从哪来？对内部历史故障和事故做数据分析，找出代码库最容易产生的 Bug 类型，建立目录，然后让提示词逐一针对。挑剔评论也需要显式定义，比如“为什么这里没有三层防御”“错误处理写得不够严谨”这类评论都应被排除。

提示词微调有个隐蔽风险：改动一小处，评论数量可能剧烈波动。这意味着你无法判断它是否漏掉了 Bug。由于灾难性 Bug 极其罕见——据其数据团队统计，大约每千行代码才有一个灾难性 Bug——你可能发布了一个看似不错但悄悄漏掉关键问题的版本，很久之后才会发现。

用历史 PR 数据集校准，但别指望一劳永逸

第二个改进是建立历史 PR 数据集。如果公司有完善的故障记录，可以把曾导致事故的 PR 整理成清单，让每个版本的审查 Agent 跑一遍，观察捕获频率。这能让提示词调优更有底气。

但 Bug 的拓扑和本体论会随时间变化。大约 80% 到 90% 的 Bug 是重复性错误，但随着编码 Agent 变强，它们开始犯前所未有的新错误。除非有数百万级 PR 数据，否则很难保持较高的 Bug 类型覆盖率，这是数据集方法的天花板。

模型反转：用不同的模型审查代码

第三个改进是模型反转。研究发现，Claude 模型和 GPT 模型产生的 Bug 类型差异显著：Claude 模型出现一次性错误的概率约为 GPT 模型的三倍，而 GPT 模型出现认证绕过的概率明显高于 Claude 模型。这被认为是后训练带来的差异。

如果用同一个模型审查自己写的代码，捕获的 Bug 会更少，因为它在审查时会以同样的方式失败。所以要用 Claude 写代码、用 GPT 审查，反之亦然。

识别代码由哪个模型生成，对 80% 的 PR 来说不难：Codex 会用 codex/ 前缀命名分支，Claude 会在 PR 描述和提交信息中写 co-authored-by。剩下 20% 需要启发式判断，比如内部登记表或开发机遥测。实测模型反转能带来更高的捕获率，这个提升放在事故和故障维度上相当可观，足以避免灾难性后果。

后训练（post-training）指模型在预训练之后经历的指令微调、RLHF 或 Constitutional AI 等阶段。不同厂商的后训练数据与偏好目标不同，会塑造出不同的「失败模式」：例如某类模型被强化为更谨慎地处理认证与权限，另一类则更倾向于快速补全功能。这种差异使得同一段代码在不同模型下产生的 Bug 类型分布不同，也是模型反转能提升捕获率的根本原因。

启发式判断代码来源时，可以结合分支命名前缀、提交信息中的 co-authored-by 标记、内部开发机遥测或代码风格特征。需注意这些信号可能被伪造或缺失，因此应作为概率性输入而非绝对依据。

代码上下文：GREP 不是万能解

代码上下文是审查 Agent 的第三块基石。有一种流行观点认为 GREP 已经解决了代码上下文问题，但事实并非如此：GREP 极不精确，而且昂贵。在编码 Agent 的调用轨迹中，大量 Token 都花在 GREP、文件读取和文件内容的缓存写入上。

更精细的做法是构建内部知识库：扫描整个代码库，把认证等关键流程编目，记录其工作方式、流程图和涉及的所有文件。以认证绕过为例，判断是否发生绕过，需要确切知道当前代码是否处于已认证环境，这离不开结构化的代码上下文。

GREP 在代码检索中的局限在于它基于字面匹配，无法理解语义等价或跨文件调用链。当 Agent 需要判断「当前请求是否经过认证中间件」时，单纯搜索函数名可能遗漏动态注册、装饰器包装或配置驱动的路由。此外，每次 GREP 都会把大量文件内容写入上下文缓存，导致 Token 成本随仓库规模线性上升。

内部知识库的构建通常包括：静态扫描入口点与中间件、生成调用图、标注关键流程的信任边界，并定期随代码变更更新。它相当于给 Agent 一张结构化地图，使其在审查认证绕过等安全问题时，能直接定位相关文件而非盲目搜索。

代码不 Bug 也可能很糟：意图与端到端测试

代码即使没有 Bug，也可能质量很差，或者没有实现作者的表达意图。当人们把 Slack 当 IDE，用一两句话让 Agent 改代码时，指令中的歧义极大，Agent 可能误解意图，写出正确但完全不对的代码。

对抗这一点的方法是给 Agent 更多上下文。最重要的两类上下文是文档与工单（Jira、Linear）以及代码库索引。很多部落知识在潜意识里帮助人类写出更好的代码，Agent 缺了这些就会显得一无所知。

计算机使用能力已经大幅提升，在新一代 GPT 和 Opus 模型中表现远好于前代，端到端 QA 首次接近被解决。要做的是记录应用的所有流程，并准备足够简单的构建脚本，让 Agent 能拉起整套环境。然后 Agent 可以端到端测试代码，用视觉模型判断“这个按钮技术上存在，但在 iPhone 上被隐藏了”这类问题。

成本分层：前沿模型只留给关键任务

做完上述优化，成本依然不低，单次 PR 审查可能花费 3 到 15 或 20 美元。解法是任务分层：前沿模型仍比开源模型更强，但差距在缩小。一个可参考的配比是约 20% 的前沿模型用于最关键任务，长尾 Token（探索、文件读取等）交给各种更小的模型。

典型分工是：小模型负责寻找上下文，轻量计算机使用模型负责测试用户流程，前沿模型负责分析 Bug、执行审查流程和提交。实践中可以拆出约 20 个子任务，每个子任务都有特定的模型组合。即使只做简单的任务替换，也能达到七八成的效果。

但这里同样依赖数据集。如果没有好的数据集，你可能把子 Agent 换成更小更快的模型，却不知道它捕获 Bug 的能力已经明显下降，直到某次事故才后知后觉。另一个技巧是用廉价模型对上下文做重排序，决定哪些内容应加载进前沿模型的缓存——那是最昂贵也最稀缺的资源。

上下文重排序（reranking）是指用廉价的小模型对候选代码片段、文件或历史评论打分排序，只把最相关的少量内容送入前沿模型的缓存。由于前沿模型的输入 Token 价格远高于小模型，这一步能显著降低单次审查成本，同时避免无关内容稀释模型注意力。实践中可结合嵌入检索与轻量分类器，按任务类型动态调整送入前沿模型的内容预算。

没有银弹，只有持续校准

打造高效 AI 代码审查 Agent 不是一次性的工程，而是一套持续校准的系统：提示词瞄准具体 Bug 类型、数据集覆盖历史与新型故障、模型反转打破同源盲区、代码知识库提供精确上下文、端到端测试验证意图，最后用成本分层控制开销。每个环节都依赖对自身代码库和故障历史的诚实观察，而非通用模板。