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

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

过去一段时间，Molio 的开发流程发生了一个明显变化：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 是一个GitHub开源项目，这套 OCR 配置也已经放进仓库，Star项目随时关注动向。如果你有不同的思路，欢迎一起讨论，也欢迎直接提出 Issue。