这一年来，写代码几乎都是用 AI 了，同时 TinyShip 从发布到现在半年了，功能越来越多，代码量也越来越大，由于是我的一个模版产品，对于质量自然要求比较高，因为现在也有很多用户，保证质量是非常重要的，

现在 AI 一分钟能给我吐出几百行，跨七八个文件，我根本不可能逐行看完。更麻烦的是，TinyShip 是个 monorepo，Next.js、Nuxt.js、TanStack Start 三个 app 要同时改，同时还支持 PG 和 SQLite 两种数据库，任何一个改动都可能影响另外两个。

每次 feature 提交有一千行以上的时候，我的心头一紧，怎样更好的 Review 它的代码呢？

最近很喜欢一篇文章，非常喜欢，Using AI to write better code more slowly，它的中心思想用 AI 写代码不需要只追求快，而是让 AI 帮我们写出更健壮质量更高的代码，所以要慢，要仔细看代码，这个观点正合我意。

所以针对我自己的产品的质量，我采取两种策略：

• 测试，尤其针对 TinyShip，E2E 非常有必要，由于有 6 种不同的情形，所以 E2E 必不可少，我会在后面一篇文章介绍我 E2E 的策略。
• Code Review，我搞了一套自己的 review 流程，给它起了个名字叫 Review Forge。不是什么复杂的工具，就是一套规则 + 文件结构，让 AI 帮我做 review，我来做最终决策。就是我这篇文章要讲的。

总览

我将我的 Code Review 流程创建成了一个 skills，地址在这里：https://github.com/vikingmute/review-forge

它的大体过程是这样的：

• Review 让不同的模型根据当前 diff 或者 branch 生成 bug 报告，每个模型一份单独的报告。
• Synthesize 根据不同模型的 bug report，汇总生成一份 summary.md 的报告。
• 手动 Review 和决定修复哪些问题
• Fix：让一个模型修正 summary 中的问题，并且跑测试验证。
• Verify：让另外一个模型验证是否修复，以此循环直到你标记的问题解决。

下面我来结合我的 skills 详细说明每一个步骤种的要点。

Review

# 安装完 review forege 的 skills，当开发完毕以后，要开始 review 的时候，我在一个 Agent 中输入这样的 Prompt
/review-forge review feature: checkout-refactor

它在 /code_review 文件夹中创建一个 checkout-refactor 的 feature 文件夹（之后所有相关的 review 内容都会在其中），然后 model 会按照自己的名称创建一个 review 文档，如果你用的是 codex，那么就是 codex.md， 所以现在文件结构式

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

# 接下来我会在另外一个 agent 中输入 Prompt，生成另外一份报告
/review-forge review feature: checkout-refactor

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

我一般会用三个模型，GPT5.5 / Composer 2.5 / DeepSeek Pro V4

为什么要多 Agent Review

一开始我只用一种服务做 review，我试过的有 Bugbot / CodeRabbit / Codex review mode。

效果还行，能抓到一些明显的 bug——逻辑错误。但是只有一个模型发现的问题，当一大堆 Bug 报告给我的时候，我会眼花缭乱，然后会更谨慎。不是说不信，而是会多花一步去验证：真的有这个问题吗？还是这个模型理解偏了？我甚至还会去问其他模型，这些问题真的存在吗？存在的话帮我修复。

同时我还发现一个问题：每个模型都有自己的盲区。

同一个功能，每种模型关注的是代码写得对不对。但有些边界条件、异常路径、跨文件的副作用，它不一定能全覆盖。这不是能力问题，是注意力分配的问题——一个模型一次 review 就像一个人审代码，总有忽略的地方。

后来我试了试让两个模型分别审同一份代码，GPT 和 Claude 各出一份报告，然后合并对比。

结果挺有意思：

• 大约 60% 的发现是重叠的
• 剩下的 40% 各有侧重
• 关键的是，有几条只有其中一个模型发现了，另一个完全没提

但这里面有一个更重要的洞察： 两个模型都发现的问题，基本就是铁板钉钉的真问题。

重叠的那些发现，我会直接看，不需要花太多时间判断”这是不是真的 bug”。因为它们被不同模型独立地指出来，说明问题本身足够明显。尤其是高优先级的重叠项，这种我就不纠结了，直接修。

所以多模型 review 给我的价值是两层：

1. 交叉验证——多个模型同时发现的问题，确定性高，果断修
2. 扩大覆盖面——单模型发现的问题，补充了另一个人可能漏掉的视角，但要自己验证

当然，不是每次都要多模型。我现在看改动大小：十几个文件以上的功能用几个模型，小修小补就用一个，也不需要这套复杂的流程。毕竟多一次 review 也是成本。

Synthesize

有了这些前提，所以自然我抽象出了一个 Synthesize 过程，其实就是将不同的报告使用 AI 分析和提取排序，生成一个 checklist。

# 随便哪个 Agent 哪个 Model 都可以运行这个子命令，这个分析的过程很简单
/review-forge synthesize feature: checkout-refactor

code_review
├── checkout-refactor/
│   ├── codex.md
│   ├── composer.md
│   ├── summary.md(会生成一个总结文档)

这个总结文档，将重合的问题按照优先级排序在前面，并且每个问题前面有个 checkbox，类似这样

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

我会手动的 Review 所有问题并且决定修复哪些问题，需要修复勾选对应的 checkbox 。

为什么要手动 Check 修哪些 Bug

这可能是整个流程里最重要的一步。

AI review 完会给一个长长的列表，每条都有严重程度的标签，按 AI 的逻辑，严重的问题都应该修。但实际情况不是这样的。AI 缺乏项目上下文和取舍判断力。尤其是当一个项目特别庞大的时候，会越来越难，并且它倾向于把所有发现的问题都当成重要问题去修复，过度优化。

所以必须人来 check，所以你必须对于你的系统非常熟悉。

我的做法很简单：AI 审完，逐条看。针对每一条我都要回答两个问题：

1. 这个问题在实际场景下会出 bug 吗？
2. 修它的代价是什么？

大多数 AI 标记的问题，第一个问题答案就是不会。它只是在理论上不完美。真正要修的是那种要出事的 —— 用户会看到错误页面、数据会被写坏、支付会失败，这种二话不说修。

跳过那些性价比不高的 High/Medium 问题，例如为了修复一个极窄的边缘情况而需要改动 100 行代码。

一套 review 下来，AI 可能列出十几条，我真正动手修的通常就三四条。这不是 AI 不行，是 review 和修代码是两件完全不同的事。AI 擅长找问题，不擅长决策。后者需要人对整个项目的理解，需要权衡风险和收益，需要知道什么时候够好了。

Fix / Review

接下来的流程就很清晰了，就是修复和验证的过程，我这里会使用两个不同的 agent，一个是 fix agent，一个是 review agent。

# 在 Agent 中输入类似这样的 Prompt，我用的是 Claude
/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 输入类似这样的 Prompt，我用的是 Codex 的 GPT5.5 模型
/review-forge verify feature: checkout-refactor

它会 review 另外一个模型的修复，看是否修复，创建 verify.md 文档，并且更新 status.md 留下批改意见，以此循环，让两个 agent 确认已经修复。文档更新已解决。

code_review
├── checkout-refactor/
│   ├── codex.md
│   ├── composer.md
│   ├── summary.md
│   ├── fix-plan.md
│   ├── status.md（更新状态）
│   ├── verify.md（Verify 的结果和详情）

为什么不能用同一个模型 fix 和 review

确定了要修哪些以后，这里面有一个铁律：review 和 fix 不能是同一个模型。

道理和人做 code review 一样——你不能让同一个人既写代码又审代码，自己写的 bug 自己看不出来，不是能力问题，是思维惯性，AI 也一样。

而且 verify 用不同模型还有个好处：如果修完的代码第二个模型也说没问题，那我基本上就放心了，相当于两道防线。

总结

用了一段时间，几个真实的感受：

最大的价值是减少焦虑。 以前 AI 写完代码我不敢合，因为不确定有没有坑。现在走完这套流程，至少我知道哪些坑是评估过的，哪些是故意不修的。合代码的时候心里有底。

多模型确实有效，但不要滥用。 大功能才用，小改动不值当，一个模型就够了。

Review Forge 在解决一个很朴素的问题：** 用多个 AI 来发现尽量多的问题，然后由人来决定哪些值得修。**

如果你也是用 AI 写大部分代码，review 跟不上了，可以试试类似的流程。不需要强制用我的这套，核心就三点：

1. 多个 AI 帮你审，减少盲区
2. 人工逐条 check，决定修不修
3. 修完跑测试，并且交叉验证

最终的文件状态是这样的：