AI 写代码越来越快，为什么 Code Review 反而更慢了？

>**副标题：** 引入 Open Code Review（OCR）的真实经历：我们如何把 AI review 从「30 条噪音」变成「12 条真正值得看」的评论。

过去一段时间，[Molio](https://mp.weixin.qq.com/s/iP-kjk2ll5UwamOGZkW4Dg)的开发流程发生了一个明显变化：AI 写代码越来越多了。

新功能、重构、修 Bug，很多代码都是先由 Claude Code、Codex 等 Agent CLI 生成第一版，再由工程师 review、修改、合并。

原本以为，AI 写代码之后，研发效率会一路提升。

结果真正跑起来以后，我们发现新的瓶颈出现了。

**代码写得越来越快，Code Review 却越来越慢。**

原因很简单：写 1000 行代码，可能只需要几十分钟；认真 review 1000 行代码，却往往比写代码更耗精力。随着 AI 提高了代码产出速度，人类 reviewer 很快就成了整个流程里最慢的一环。

于是，我们开始尝试让 AI 去 review AI 写的代码。

结果，比想象中复杂得多。

----

我们试过三种办法

第一种，是直接让大模型 review PR diff。

优点很明显，几乎零成本。

但稳定性并不好。同一个 PR 连跑两次，评论数量和内容都可能差很多。

更重要的是，模型很容易把注意力放到一些「显眼但价值不高」的地方，例如：

- • 一段中文字符串

- • 一个 `catch {}`

- • 一个 magic number

真正值得关注的语义问题，反而容易被淹没。

第二种，是把 ESLint、TypeScript 检查收紧。

它们确实能很好地解决规范问题。

例如：

- • 未使用变量

- • 空 catch

- • 类型错误

- • 风格一致性

但是像 race condition、stale closure、path traversal 这类语义 Bug，它们天然发现不了。

第三种，就是继续人工 Review。

准确率最高，但吞吐始终上不去，而且 reviewer 很容易疲劳。

后来我们逐渐意识到，我们真正需要的其实不是一个更聪明的 AI，而是一种职责划分：

- • **LLM 负责发现语义 Bug**

- • **Linter 负责规范检查**

- • **人只关注 AI 和静态分析都解决不了的问题**

于是，我们开始尝试阿里的AI驱动的代码审查 CLI 工具—— Open Code Review（OCR）。

----

# OCR 比直接让 LLM Review，多了一层什么？

刚开始，我也以为 OCR 的价值只是「把 prompt 封装好了」。

真正用下来以后发现，它更多解决的是工程化问题。

例如：

**规则可以版本化。**

团队把规则写进 `.opencodereview/rule.json`，随仓库一起维护。规则修改可以走 PR，可以 Git blame，不再依赖某个人脑子里的 prompt。

**会主动补上下文。**

OCR 不只是把 diff 丢给模型，而是会按需读取相关代码、类型定义、调用关系，让模型拥有比单纯 diff 更多的信息。

很多误报，其实都是因为上下文不足。

**会做事实核查。**

OCR 内置了 REVIEW_FILTER_TASK，会检查评论是否能够被 diff 直接反证。

例如评论说：

>文件里存在 XXX

但 diff 根本没有 XXX。

这种评论会直接被过滤。

**还能直接集成 GitHub PR。**

评论最终直接落到对应代码行，reviewer 不需要切换工具。

整个思路其实很合理：

- • ESLint 负责规范。

- • OCR 负责语义。

- • 人负责架构和业务。

可惜，现实并没有这么理想。

----

# 第一个坑：LLM 太喜欢"认真工作"

OCR 上线第一周，我就把它关掉了。

不是因为它不准。

而是因为它**太能说**。

一次 PR，大概三四十条评论。

其中大部分都是：

- • 这里硬编码了中文字符串

- • 这里 catch 是空的

- • 建议抽一个 helper

- • 建议去掉 magic number

- • 建议不要嵌套三元表达式

这些问题有没有道理？

都有。

问题在于，它们本来就是 ESLint 的职责。

Reviewer 已经看过 ESLint，再看一遍 AI 的重复提醒，没有任何增益。

真正重要的问题反而被埋没了。

----

# 第二个坑：我以为问题在 Workflow

我的第一反应，是做后处理。

在 workflow 里加了一层过滤：

- • 正则过滤低价值评论

- • path line body 去重

真实 PR 跑下来以后，结果很尴尬。

regex：

**0 命中。**

因为 OCR 的评论写得非常正式。

它不会说：

>Looks good.

也不会说：

>This is fine.

而是：

>Hardcoded Chinese strings detected...

这些完全匹配不到。

去重也没什么效果。

真正重复的评论，LLM 会重新组织语言。

如果按内容去重，去不掉。

如果按位置去重，又可能把同一行两个真正不同的问题一起删掉。

折腾了一晚上，我发现自己一直在错误的地方用力。

----

# 第三个坑：读完源码，我才找到真正的杠杆

后来，我把 OCR 的源码 clone 下来读了一遍。

读完以后发现，之前很多判断都是错的。

## 真相一：rule.json 不是硬规则

我原来以为：

rule.json 是规则。

实际上：

它只是作为 `Review Checklist` 放进用户提示词。

如果 diff 里某个 token 特别显眼，例如：

```

catch{}

```或者：

```

'上传失败'

```模型的注意力很容易被这些 token 吸走。

仅仅写一句：

>不要报告硬编码字符串。

作用并不明显。

后来我们改成：

- • 把 NEVER REPORT 放到最前面

- • 给具体 token 示例

效果才开始稳定下来。

----

真相二：默认规则和我们的目标相反

继续读源码以后，我们发现 OCR 默认的 TS/JS 规则其实鼓励报告：

- • 硬编码字符串

- • duplicate code

- • nested ternary

- • async error handling

- • null check

而这些，很多正是我们不希望 AI 重复报告的内容。

因此，rule.json 不能只是补充规则，而需要显式禁止这些类别。

----

真相三：`merge_system_rule: false` 很重要

最开始我还以为：

保留系统规则，再追加自己的规则，会更安全。

实际上恰恰相反。

如果系统规则在前鼓励报告硬编码字符串，后面的用户规则再说不要报告，模型很容易优先遵循前面的内容。

因此我们最终选择：

```

"merge_system_rule":false

```直接替换系统规则。

----

## 真相四：REVIEW_FILTER_TASK 不是质量过滤器

以前我一直以为：

OCR 已经内置了低价值评论过滤。

实际上不是。

它只负责事实核查。

能够证明评论与 diff 不一致，它就删。

至于评论有没有价值，它完全不判断。

因此，低价值评论只能从 rule.json 源头控制。

----

## 真相五：Review 模式本身没有 Dedup

读 task template 后才发现：

Review 模式没有 DedupTask。

真正的评论去重只存在于 Scan 模式。

这也解释了为什么 reformulated 重复评论会直接出现在 PR 里。

----

# 真正的改动，其实只有一个地方

后来我们没有继续修改 workflow。

而是回到 rule.json。

核心思路只有一句话：

**把模型的注意力，从规范问题，重新拉回语义问题。**

我们主要做了几件事：

- • 把 **NEVER REPORT** 放到最前面；

- • 每条规则都配具体 token 示例，例如 `'上传失败'`、`void someAsync()`、`fs.*Sync()`；

- • 删除对模型没有帮助的说明性文字；

- • 最后增加一句明确约束：

>If your finding matches ANY of the above, DO NOT post it.

同时保持：

```

merge_system_rule:false

```整个 workflow 里的 regex 和 dedup 逻辑也全部删掉了。

----

# 验证结果

我们用同一个 commit、同一个 PR，再跑了一遍。

|指标|调整前|调整后|

|:-:|:-:|:-:|

|评论总数|30|12|

|低价值评论|24|0|

|发现的语义 Bug|6|12|

那些反复出现的：

- • i18n

- • magic number

- • empty catch

- • nested ternary

- • cosmetic

- • sync I/O 建议

都没有再出现。

与此同时，新发现了一些真正值得 reviewer 关注的问题，例如：

- • symlink 导致目录穿越风险

- • MIME Type 欺骗

- • Markdown placeholder 冲突

- • WikiLink 解析顺序导致路径转换错误

这些都是 ESLint 不可能发现，也是人工 review 比较容易遗漏的问题。

这也是我们真正希望 LLM 去做的事情。

----

# 这次踩坑最大的收获

回头看，真正的问题并不是模型能力。

而是我一开始没有找到正确的杠杆。

我先写了一晚上 post-processing。

后来花了两个小时读源码。

真正修改 rule.json，大概只用了半小时。

最后起作用的，也只有 rule.json。

这件事让我重新认识了一点：

**AI 工具越来越多，但真正决定效果的，往往不是模型本身，而是工程化。**

Prompt 不是工程。

Workflow 也不是工程。

只有把规则、上下文、校验、CI 串成一套流程，AI 才真正成为研发能力，而不是一个聊天工具。

----

# 写在最后

如果你们也在尝试让 AI 参与 Code Review，欢迎评论区分享你们的实践。

例如：

- • 不同模型下，规则是否需要分别维护？

- • 如何应用多套不同的 Review 策略，比如AI 写的代码和人写的代码采用不同的review策略配置？

- • 除了 OCR，你们还在使用哪些工具？

这些问题，我们目前也还在持续探索。

[Molio](https://github.com/zhuzhaoyun/Molio) 是一个GitHub开源项目，这套 OCR 配置也已经放进仓库，Star项目随时关注动向。如果你有不同的思路，欢迎一起讨论，也欢迎直接提出 Issue。","createTime":1782699102,"ext":{"closeTextLink":0,"comment_ban":0,"description":"","focusRead":0},"favNum":0,"html":"","isOriginal":0,"likeNum":0,