我如何用 AI 做代码审查

Viking (vikingz.me) 2026-07-29T15:00:45.056672

2026年5月31日

在这个 AI 生成代码的时代，我发现代码审查比以往任何时候都更重要。AI 能以闪电速度产出代码——如果你不经常介入，整个系统很快就会失控，质量直线下降，一切都会变成一个黑箱。我整理了一套名为 Review Forge 的工作流程，让我的项目代码审查更有条理和一致性，它让我对每次发布的内容都更有信心。

阅读更多

过去一年里，我几乎所有的代码都是用 AI 写的。与此同时，TinyShip 已经上线运行了六个月——功能不断增多，代码库持续膨胀，而且由于它是一个面向真实用户的模板产品，质量绝不能事后才考虑。

问题是，AI 可以在同一分钟内横跨七八个文件生成数百行代码。我根本不可能逐行阅读。更棘手的是，TinyShip 是一个单仓（monorepo）——三个应用（Next.js、Nuxt.js、TanStack Start）需要同步变更，还要同时支持 PostgreSQL 和 SQLite。一个地方的改动可能会波及另外两个。

当一个功能提交超过一千行时，我心里就会一紧。这么多代码，我到底要怎么仔细审查？

最近我读到一篇很棒的文章——《用 AI 写更好的代码，但慢一点》。核心思想是：用 AI 写代码不应该是为了速度，而应该是为了借助 AI 产出更健壮、更高质量的代码。这意味着要慢下来，仔细阅读代码。这让我深有共鸣。

因此，为了我自己产品的质量，我采取双管齐下的策略：

• 测试——尤其是对 TinyShip 来说，端到端（E2E）测试必不可少。六种不同配置同时运作，绕不开它。我会在后续的文章中介绍我的 E2E 策略。
• 代码审查——我搭建了自己的审查工作流，称之为 Review Forge。它不是什么花哨的工具，只是一套规则加一个文件结构，让 AI 帮我做审查的苦力，我则做最终决定。这就是本文要讲的内容。

概览

我把自己的代码审查流程打包成了一个技能。你可以在这里找到它：https://github.com/vikingmute/review-forge

整体工作流程如下：

• 审查——不同模型各自根据当前的 diff 或分支生成一份 bug 报告，每个模型出一份报告。
• 整合——把每个模型生成的 bug 报告合并到一份 summary.md 文件中。
• 手动审查——逐条查看每一项发现，决定哪些问题真正需要修复。
• 修复——把选中的问题交给一个模型去修复，然后运行测试。
• 验证——让另一个模型验证修复结果。循环直到所有你标记的问题都得到解决。

接下来我逐一拆解每个步骤，结合它的实际用法来说明。

Review

# 安装好 review-forge，完成开发后，我向 Agent 发送这条提示词来启动审查：
/review-forge review feature: checkout-refactor

这会创建一个名为 checkout-refactor 的文件夹，放在 /code_review 目录下（该功能的所有审查相关内容都保存在这里）。模型随后会写一份以自己名字命名的审查文档——如果你用的是 Codex，就会得到 codex.md。最终文件结构如下：

code_review
├── checkout-refactor/
│   ├── codex.md

# 然后我用同样的提示词启动另一个 Agent，获得第二份报告：
/review-forge review feature: checkout-refactor

code_review
├── checkout-refactor/
│   ├── codex.md
│   ├── composer.md

我通常使用三个模型：GPT-5.5、Composer 2.5 和 DeepSeek Pro V4。

为什么用多 Agent 审查

一开始，我审查代码只用单一服务——试过 Bugbot、CodeRabbit 和 Codex 的审查模式。

效果还行，能抓到明显的 bug 和逻辑错误。但当一个模型甩给我一长串问题时，我会感到不知所措，然后变得过于谨慎。不是说我不信任它，而是我得多花一步去琢磨：这真的是问题，还是模型理解错了？我甚至得去问其他模型：“嘿，这些问题真的存在吗？如果存在，就修掉。”

然后我发现了另一件事：每个模型都有自己的盲区。

对于同一个功能，每个模型都会关注代码是否正确。但边界情况、错误路径、跨文件的副作用——单个模型不一定能覆盖全部。这不是能力问题，而是注意力分配问题。一个模型只做一遍审查，就像一个人审查代码一样——总会漏掉一些东西。

于是我尝试让两个模型独立审查同一段代码——GPT 和 Claude 各自生成一份报告——然后对比。

结果很有意思：

• 大约 60% 的发现是重叠的

• 剩下的 40% 各有侧重

• 关键在于，有几个问题只有一个模型发现；另一个完全没提。

但更深层的洞察是：当两个模型同时指出同一个问题，那几乎可以肯定是个真问题。

对于这种重叠发现的 bug，我直接处理就行，不用花时间纠结“这到底是不是真的 bug”。两个模型不约而同指向同一件事，说明问题足够明显。尤其是高优先级重叠——我不再犹豫，直接修。

所以多模型审查给我带来两层价值：

1. 交叉验证——多个模型都标记的问题，置信度高，果断修。
2. 更广覆盖——单个模型发现的漏洞，补充了另一个审阅者可能漏掉的部分，但这些我需要自己核实。

当然，我并不是每次都跑多个模型。根据改动大小决定：涉及十几个文件以上的功能，才走多模型流程；小修小改用单个模型，省去繁琐步骤。毕竟多一次审查也不是免费的。

合成（Synthesize）

综合以上所有步骤，合成这一步其实是很自然的抽象。本质就是把不同报告交给 AI 去分析、排序，最后生成一份检查清单。

# 任何代理、任何模型都可以运行这个子命令。分析过程很直接。
/review-forge synthesize feature: checkout-refactor

code_review
├── checkout-refactor/
│   ├── codex.md
│   ├── composer.md
│   ├── summary.md   # <-- 新的总结文档

总结文档会把重叠的问题按优先级排在前面，每个问题前面加一个复选框，像这样：

- [ ] `RF-002`
- `severity`: high
- `reviewer_agreement`: 2/3 (composer, codex)

我会手动审查每个问题，决定哪些要修，把要改的项勾选上。

为什么我要手动决定修哪些 Bug

这可能是整个流程中最关键的一步。

验证人类判断

AI 审查完会输出一长串问题，每条都标了严重等级。按 AI 的逻辑，标记为严重的都得修。但实际不是这样。AI 缺乏项目上下文，也没有权衡取舍的判断力。项目越大越难办，AI 倾向于把每一条发现都当成必须修复的——过度优化。

所以最终拍板的还得是人。你必须足够了解自己的系统。

我的方法很简单：AI 审查结束后，我逐条过一遍。每一条发现，我问自己两个问题：

1. 这条问题在真实场景下真的会导致 Bug 吗？
2. 修复它的成本是什么？

AI 标出来的大部分问题，第一个问题的答案都是“否”。只是理论上的不完美。我真正动手去改的，是那些确实会出事的——用户碰见错误页面、数据损坏、支付失败。这些毫不犹豫就修。

对于高/中严重级别但投资回报率低的问题，我会跳过——比如改 100 行代码去处理一个极其罕见的边界情况。

一轮完整的审查走下来，AI 可能列出一二十个问题。我通常只改三四个。这不是说 AI 不行，而是审查代码和修复代码本质上是两回事。AI 擅长发现问题，但不擅长做决策。后者需要人类对项目的整体理解，权衡风险与收益的能力，以及判断“什么程度就够了”的直觉。

修复 / 验证

到这步，流程就很直接了——修复然后验证的循环。我用两个独立的 Agent：一个负责修复，一个负责审查。

# 我向运行 Claude 的 Agent 发送类似这样的提示：
/review-forge fix feature: checkout-refactor

这会生成 fix-plan.md 和 status.md 来跟踪进度，然后执行修复并运行相关测试。

code_review
├── checkout-refactor/
│   ├── codex.md
│   ├── composer.md
│   ├── summary.md
│   ├── fix-plan.md    # 修复计划
│   ├── status.md      # 状态跟踪

# 在另一个 Agent 中，我发送这个提示——这里我用 Codex 搭配 GPT-5.5：
/review-forge verify feature: checkout-refactor

2026年5月31日

在AI生成代码的时代，我觉得代码审查比以往任何时候都更重要。AI 能以闪电速度生成代码——如果你不经常介入，整个系统很快就会失控，质量直线下降，一切都变成黑盒。我整理了一套工作流，叫做 Review Forge，用来让我的项目代码审查更有条理、更一致。它让我对每次发布的变更都更有信心。

阅读更多

这个智能体会审查另一个模型的修复结果，检查每个问题是否真正解决，创建 verify.md 文档，并用反馈更新 status.md。两个智能体来回交替，直到我标记的所有问题都确认为止。

code_review
├── checkout-refactor/
│   ├── codex.md
│   ├── composer.md
│   ├── summary.md
│   ├── fix-plan.md
│   ├── status.md      # 更新后的状态
│   ├── verify.md      # 验证结果和细节

为什么不能用同一个模型来修复和审查

一旦你决定要修复什么，有一条硬性规则：修复模型不能与验证模型是同一个。

原因和人工代码审查一样——你不能让同一个人既写代码又审查代码。他们不会发现自己的 bug，不是因为能力不足，而是因为认知惯性。AI 也一样。

另外，用不同的模型来验证还有一个额外的好处：如果第二个模型也通过了修复，我可以相当放心。这就像有了双重防线。

结语

用了这套工作流一段时间后，我真实的感受如下：

最大的价值在于安心。以前，我犹豫要不要合并 AI 写的代码，因为我无法判断里面有没有隐藏的坑。现在，经过这个过程后，我知道哪些问题被评估过，哪些是我有意选择不修复的。我是睁着眼睛合并代码的。

多模型审查是有效的，但不要过度使用。把它留给大功能。对于小改动，不值得——一个模型就够了。

Review Forge 解决了一个简单的问题：用多个 AI 来暴露尽可能多的问题，然后让人来决定哪些值得修复。

如果你用 AI 写大部分代码，而你的审查流程跟不上，不妨试试类似的工作流。你不需要完全照搬我的配置——核心只有三件事：

1. 用多个 AI 审查你的代码，减少盲区
2. 人工逐条查看每一条问题，决定修复什么
3. 修复、运行测试，然后用另一个模型交叉验证

查看原文