AI 写代码越来越快，为什么 Code Review 反而更慢了？
新功能、重构、修 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,
