今天上午刷 GitHub Trending，榜首是阿里开源的 open-code-review，一天涨了三千多星。星数不是重点，重点是它踩中了我最近的一个真实困扰：AI 把写代码的门槛打下来了，review 却还在原地踏步------Cursor、Claude Code 生成的代码越来越多，谁来审？ 把 diff 直接丢给通用 AI 聊天框去 review，我试过很多次，结果基本三种：改了 30 个文件它只盯着一处喷；报的问题行号对不上；再来一堆"建议增加注释"式的正确废话。token 倒是烧得很爽。
OpenCodeReview（装完之后命令行叫 ocr）的思路不太一样，它压根不打算让模型自由发挥。按官方文档的说法，整个评审拆成三段：规则引导的任务分发、带上下文约束的文件评审、最后还有一层独立的反思过滤。文件筛选、规则匹配、评论定位这些确定性工作由传统代码逻辑完成，LLM 子代理只负责理解改动和判断问题值不值得提，而且它拿到的工具集是受约束的代码工具，不是 unrestricted shell。 这个设计我挺认同。代码 review 是高度重复的工程任务，给模型最大自由度反而意味着每次结果都不可预测------写业务代码可以天马行空，判断"这一行该不该评论"这种事，枷锁就是生产力。
装上就能跑，DeepSeek 是预置项
安装就是一行 npm：
sql
npm install -g @alibaba-group/open-code-review我这边两秒装完，ocr version 正常：
perl
open-code-review v1.12.5 (189be5b024) linux/amd64
built at: 2026-09-17T13:19:46Z
https://github.com/alibaba/open-code-review有个小插曲：官方要求 Git 2.41 以上，我的老机器是 2.34.1，每次跑都会警告一句 git 2.34.1 is older than the minimum supported version 2.41.0。实测不阻塞任何功能，diff 解析都正常，但看着确实有点膈应，回头还是升一下。 接模型比我预想的省事。我本来以为要走自定义 provider 那套流程，结果 DeepSeek 直接是预置项：
arduino
ocr config set providers.deepseek.api_key sk-你的key
ocr llm test测试通过时模型还回了段自我介绍，挺有节目效果：
vbnet
Source: provider:deepseek
URL: https://api.deepseek.com
Model: deepseek-flash
I am open-code-review (ocr), a code review assistant developed by
Alibaba that runs in your command-line environment...
✓ Connection test successfuldeepseek-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 确认了范围，没毛病，直接开审：
ini
─── user_service.py:20-21 ───
[security · critical] SQL injection: `keyword` is concatenated directly
into the query. A value like `'; DROP TABLE users; --` (or a UNION-based
payload) would be executed by the database. Use a parameterized query.
- sql = "SELECT id, name, email FROM users WHERE name LIKE '%" + keyword + "%'"
+ sql = "SELECT id, name, email FROM users WHERE name LIKE ?"
+ rows = conn.execute(sql, (f"%{keyword}%",)).fetchall()参数化查询的修法是对的，连 LIKE 通配符该放在绑定参数里这个细节都没漏。硬编码 key 那条报的也是 critical，还多提醒了一句：这个 key 已经进过工作区，记得轮换。分页那个逻辑 bug 一眼看穿，page_size > 100 反手给我改成 1000 的操作，它直接标了 bug · high。 5 个坑全部命中，每条都带行级定位和修复 diff。意外收获是第 6 条：requests.post 的返回值被忽略，导出失败会静默当成成功------这个坑我没埋，它自己顺出来的。整个过程 45 秒，6 条评论，零误报。
换干净代码再试：不讨好，但挑的都是真毛病
全中零误报只能说明它抓坑能力强，我还关心另一个问题：会不会为了显得有用，对正常代码也硬凑一堆发现？这类工具最败好感的就是讨好型审查，把没有问题的地方说出一朵花。 我又写了个挺规矩的重试装饰器------至少我自己写的时候觉得挺规矩：
python
def retry(times=3, backoff=2.0):
def decorator(func):
@functools.wraps(func)
def wrapper(*args, **kwargs):
delay = 1.0
last_exc = None
for attempt in range(times):
try:
return func(*args, **kwargs)
except requests.RequestException as exc:
last_exc = exc
time.sleep(delay)
delay *= backoff
raise last_exc
return wrapper
return decorator结果它报了 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... 就写到这，等我拿大项目压一轮再聊后面的体验。