副标题：引入 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 跑下来以后，结果很尴尬。
正则：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 策略、以及更多工具的搭配。Molio 是一个开源项目，这套 OCR 配置已经放进仓库，供参考交流。
