夜雨聆风引入 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，再跑了一遍。
那些反复出现的：
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。
