阿里开源的 AI 代码评审工具，我喂了 5 个坑，一个没漏

今天上午刷 GitHub Trending，榜首是阿里开源的 open-code-review，一天涨了三千多星。星数不是重点，重点是它踩中了我最近的一个真实困扰：AI 把写代码的门槛打下来了，review 却还在原地踏步——Cursor、Claude Code 生成的代码越来越多，谁来审？ 把 diff 直接丢给通用 AI 聊天框去 review，我试过很多次，结果基本三种：改了 30 个文件它只盯着一处喷；报的问题行号对不上；再来一堆"建议增加注释"式的正确废话。token 倒是烧得很爽。

OpenCodeReview（装完之后命令行叫 ocr）的思路不太一样，它压根不打算让模型自由发挥。按官方文档的说法，整个评审拆成三段：规则引导的任务分发、带上下文约束的文件评审、最后还有一层独立的反思过滤。文件筛选、规则匹配、评论定位这些确定性工作由传统代码逻辑完成，LLM 子代理只负责理解改动和判断问题值不值得提，而且它拿到的工具集是受约束的代码工具，不是 unrestricted shell。 这个设计我挺认同。代码 review 是高度重复的工程任务，给模型最大自由度反而意味着每次结果都不可预测——写业务代码可以天马行空，判断"这一行该不该评论"这种事，枷锁就是生产力。

装上就能跑，DeepSeek 是预置项

安装就是一行 npm：

1npm install -g @alibaba-group/open-code-review
2

我这边两秒装完，ocr version 正常：

1open-code-review v1.12.5 (189be5b024) linux/amd64
2built at: 2026-09-17T13:19:46Z
3https://github.com/alibaba/open-code-review
4

有个小插曲：官方要求 Git 2.41 以上，我的老机器是 2.34.1，每次跑都会警告一句 git 2.34.1 is older than the minimum supported version 2.41.0。实测不阻塞任何功能，diff 解析都正常，但看着确实有点膈应，回头还是升一下。 接模型比我预想的省事。我本来以为要走自定义 provider 那套流程，结果 DeepSeek 直接是预置项：

1ocr config set providers.deepseek.api_key sk-你的key
2ocr llm test
3

测试通过时模型还回了段自我介绍，挺有节目效果：

1Source: provider:deepseek
2URL:    https://api.deepseek.com
3Model:  deepseek-flash
4I am open-code-review (ocr), a code review assistant developed by
5Alibaba that runs in your command-line environment...
6✓ Connection test successful
7

deepseek-flash 穿着阿里 review 助手的皮干活，一个开源工具对国产模型接入做到这个程度，国内用户基本零门槛。非 DeepSeek 用户也行，OpenAI 兼容和 Anthropic 兼容的自定义 endpoint 都支持，团队有自己的网关就能指过去。

埋坑实测：45 秒，6 条全中

光看演示不算数，我直接搭了个真实场景：一个小型用户服务的 Python 项目，先提交一版干净的代码，然后在工作区里加一个用户搜索接口——顺手埋了 5 个坑：

• SQL 拼接注入（关键字直接字符串拼接进 LIKE 查询）
• 硬编码推送网关的生产 key
• 分页上限逻辑写反（page_size > 100 时设成 1000）
• 查不到用户时直接下标取值（None 崩溃）
• open() 不用 with 管理文件句柄

不提交，保持工作区 diff 状态，然后跑 ocr review。它默认的 workspace 模式会覆盖暂存、未暂存和未跟踪的变更，正好适合提交前自查。先 --preview 确认了范围，没毛病，直接开审：

1─── user_service.py:20-21 ───
2[security · critical] SQL injection: `keyword` is concatenated directly
3into the query. A value like [`'; DROP TABLE users; --`](https://xplanc.org/primers/document/zh/10.Bash/90.%E5%B8%AE%E5%8A%A9%E6%89%8B%E5%86%8C/EX.users.md) (or a UNION-based
4payload) would be executed by the database. Use a parameterized query.
5
6-     sql = "SELECT id, name, email FROM users WHERE name LIKE '%" + keyword + "%'"
7+     sql = "SELECT id, name, email FROM users WHERE name LIKE ?"
8+     rows = conn.execute(sql, (f"%{keyword}%",)).fetchall()
9

参数化查询的修法是对的，连 LIKE 通配符该放在绑定参数里这个细节都没漏。硬编码 key 那条报的也是 critical，还多提醒了一句：这个 key 已经进过工作区，记得轮换。分页那个逻辑 bug 一眼看穿，page_size > 100 反手给我改成 1000 的操作，它直接标了 bug · high。 5 个坑全部命中，每条都带行级定位和修复 diff。意外收获是第 6 条：requests.post 的返回值被忽略，导出失败会静默当成成功——这个坑我没埋，它自己顺出来的。整个过程 45 秒，6 条评论，零误报。

换干净代码再试：不讨好，但挑的都是真毛病

全中零误报只能说明它抓坑能力强，我还关心另一个问题：会不会为了显得有用，对正常代码也硬凑一堆发现？这类工具最败好感的就是讨好型审查，把没有问题的地方说出一朵花。 我又写了个挺规矩的重试装饰器——至少我自己写的时候觉得挺规矩：

1def retry(times=3, backoff=2.0):
2    def decorator(func):
3        @functools.wraps(func)
4        def wrapper(*args, **kwargs):
5            delay = 1.0
6            last_exc = None
7            for attempt in range(times):
8                try:
9                    return func(*args, **kwargs)
10                except requests.RequestException as exc:
11                    last_exc = exc
12                    time.sleep(delay)
13                    delay *= backoff
14            raise last_exc
15        return wrapper
16    return decorator
17

结果它报了 2 条，都是 low 级别，但都成立：times 传 0 或负数时循环体不执行，last_exc 还是 None，最后那行 raise last_exc 会变成 TypeError: exceptions must derive from BaseException——我写的时候真没想过这茬。另一条是最后一次失败之后还会先 sleep 再抛异常，默认参数下多白等 4 秒。没有任何一条安全问题硬凑，两处都给了具体修法。

这一轮下来我对它的判断是：抓坑能力在线，不讨好，判级也克制（真安全问题才上 critical，边界瑕疵就老实待在 low 里）。 上面测的其实只是 review 一个命令。完整翻了一遍 help，还有几个我翻 help 才发现的，还没实测就不展开。scan 能脱离 diff 直接全文件审查，哪天接手祖传目录用得上。输出支持 JSON 和 SARIF，接质量门禁这个我倒是真想试试。评审会话有落盘，中断了能 resume。团队规则可以写进项目里的 .opencodereview/rule.json 随仓库走，规范不用每次靠嘴说。CI 侧 GitHub Actions、GitLab CI 的模板都是现成的。还有个 delegation mode 挺有意思，在 Claude Code、Cursor 这类宿主 agent 里跑的时候，ocr 只做确定性的文件筛选和规则匹配，推理直接用宿主 agent 的模型，连 API key 都不用单独配。

几个不吐不快的槽点

槽点也有。输出目前全是英文，我读着没障碍，但团队里英文一般的同事看 critical 评审意见会吃力，希望后续有本地化选项。我这次测的是单文件 +23/-6 的小 diff，它宣称的大 PR 分组并发能力我没有条件验证，这个不下结论。另外效果终究挂在模型身上，deepseek-flash 跑这种单文件场景绰绰有余，跨文件的复杂推断行不行，得等我拿真项目试过再说。

适用场景我的判断很明确：提交前自查和 CI 自动拦截，这两个位置它现在就能顶上。至于替代人工 review——它抓的是机械性问题，业务逻辑合不合理这种事，目前还轮不到它说话。 仓库地址：github.com/alibaba/ope…就写到这，等我拿大项目压一轮再聊后面的体验。

《阿里开源的 AI 代码评审工具，我喂了 5 个坑，一个没漏》 是转载文章，点击查看原文。