>**副标题：** 引入 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&nbsp;{}
```或者：
```

    
    
    
  '上传失败'
```模型的注意力很容易被这些 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":&nbsp;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:&nbsp;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。

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

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

AI 写代码越来越快，Code Review 却成了新的瓶颈。我们在 Molio 引入 Open Code Review（OCR），从踩坑到读源码，最终通过重写规则，让 LLM、Linter 和人工 Review 各司其职，把 AI Review 聚焦到真正的语义 Bug。

开发工具

人工智能

后端

AI代码审查新突破：OpenCodeReview(OCR)如何将AI评论从30条噪音优化为12条高价值建议。通过精准配置rule.json规则，有效过滤低价值规范问题，专注发现ESLint无法检测的语义漏洞，如目录穿越风险、MIMEType欺骗等关键问题。揭秘AI代码审查工程化实践，提升开发效率同时保障代码质量。

代码解释

TypeScript

GitHub

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

AI 写代码越来越快，为什么 Code Review 反而更慢了？-腾讯云开发者社区-腾讯云

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

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

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐