AI Agent 越通用，代码审查反而越容易翻车。
这事听起来反常。模型会读上下文，会调用工具，会解释复杂逻辑，为什么还会漏文件、飘行号、质量忽高忽低？原因很简单：代码审查不是聊天。它是质量控制。
阿里这次开源的 Open Code Review，真正有意思的地方不在“又来了一个 AI code review 工具”。而在它承认了一件朴素的事：模型可以判断，但流程必须管住模型。
Open Code Review 做了什么
Open Code Review 是一个 AI 代码审查 CLI 工具，命令是 ocr。
项目说明称，它源自阿里集团内部官方 AI 代码审查助手，过去两年服务数万开发者，识别百万级代码缺陷。这里要打个折看：这是 README 自述，不是第三方验证结论。
它的基本工作流不复杂：读取 Git diff，识别变更文件，结合规则和上下文，把代码交给配置好的大模型，再生成带行级定位的审查意见。
| 维度 | Open Code Review 的公开信息 |
|---|---|
| 工具形态 | CLI 工具，命令为 ocr |
| 模型接入 | 支持 OpenAI / Anthropic 兼容端点，需要自行配置 LLM |
| 使用入口 | CLI、Claude Code 插件、Skill、CI/CD |
| 内置规则 | 覆盖 NPE、线程安全、XSS、SQL 注入等常见风险 |
| 规则扩展 | 支持项目级、全局、自定义规则 |
| 项目来源 | README 称源自阿里内部官方 AI 代码审查助手 |
这不是把“帮我审查代码”丢给模型就完事。
README 里直接点了通用 Agent 做代码审查的三个痛点：覆盖不完整、行号漂移、质量随 prompt 波动。
这三个坑，工程团队都熟。漏审一个文件，比评论写得不漂亮更致命。行号错了，意见再对也会变成噪音。prompt 换几个词，质量就抖一下，最后没人敢把它放进流水线。
分水岭不在模型，在流程约束
Open Code Review 的路线，是“确定性工程 × LLM Agent”。
确定性工程负责不能靠运气的部分：文件选择、过滤、分组、规则匹配、评论定位、结果反思校验。Agent 负责更适合模型的部分：动态判断、上下文检索、跨文件理解、工具调用。
这条路是对的。
代码审查的核心，不是模型能不能说出一段像样的理由。核心是它能不能稳定看见该看的文件，命中该命中的风险，指出该指出的位置。
审查不是写作文。质量控制最怕“灵光一现”。
“工欲善其事，必先利其器。”放到这里，器不是大模型本身，而是包住模型的流程、规则和约束。没有这层壳，Agent 越自由，越像一个兴致很高但纪律不稳的实习审查员。
这和早期工业化有点像，不完全一样，但逻辑相通。工厂不是否定工匠，而是不把良率押在工匠当天手感上。代码审查也一样。模型可以聪明，但入口、路径、边界、定位，要由工程系统兜住。
对比通用 Agent，Open Code Review 至少给出了更清晰的取舍。
| 路线 | 优点 | 风险 |
|---|---|---|
| 通用 Agent 审查 | 上手快，解释能力强，适合临时辅助 | 覆盖不稳，行号易漂，质量受 prompt 影响 |
| 确定性流程 + Agent | 文件、规则、定位更可控，更适合接入 CI/CD | 依赖规则沉淀，也依赖外部模型质量和成本 |
我不太买账的是那种“Agent 足够强就能包办审查”的说法。
真实研发流程里，审查意见要能追踪、能复现、能落到责任人。不能今天说这个风险，明天换个 prompt 就不说了。也不能在 CI 里吐出一堆看似聪明、没人敢信的评论。
模型能力当然重要。但在代码审查里，模型是刀，流程是刀鞘和尺子。没有尺子，刀再快也会乱切。
谁适合试，谁该先观望
这件事最直接影响两类人：工程团队负责人，以及已经在用 AI 编程工具的开发者。
工程团队负责人可以把它当成一个试点工具，而不是立刻替换现有 code review 流程。
更现实的做法是：先接入非核心仓库或低风险项目，看它对 NPE、线程安全、XSS、SQL 注入这类规则的命中情况。再看评论定位是否稳定，误报是否可控，CI 里会不会制造太多噪音。
如果团队已有 GitHub、GitLab 或内部代码审查平台，Open Code Review 更适合先做补充层。它可以帮你检查 diff，补一层规则化 AI 审查。但不要一上来就把人工 review 和安全扫描都让出去。
使用 AI 编程工具的开发者，则可以把它当作“提交前自查”。尤其是经常用 Claude Code、Cursor 或其他 AI 写代码的人，更需要一个反向约束：AI 帮你写，另一个流程化 AI 帮你查。
这听起来有点绕，但很现实。AI 编程最危险的不是写不出来，而是写得很像对，实际埋了坑。
不过，限制也摆在桌面上。
它仍依赖外部 LLM 配置。模型质量、token 成本、代码隐私、企业合规，都会直接决定能不能落地。对小团队，可能是一个低门槛补位工具。对大公司，它更像一套可参考的审查架构，不是拿来即用的银弹。
也不要把“阿里开源”理解成完整开放内部工程能力。项目开放的是工具和规则体系的一部分。真正难的东西，往往藏在长期规则沉淀、缺陷样本、研发流程和责任机制里。
接下来最该观察的变量，不是 README 里写了多少规则，也不是支持多少模型端点。
我更看三件事：
- 在真实仓库里，行级定位是否稳定；
- 接入 CI/CD 后，误报和噪音能不能压住；
- 企业在隐私、成本、合规上是否愿意让它常态化运行。
这三关过不去，它就是一个有启发的开源项目。过得去，才可能变成工程链路里的固定环节。
Open Code Review 值得看，正因为它没有把代码审查包装成模型能力秀。它提醒了一个不太性感、但很关键的行业现实：严肃工程里，自由发挥不是优势，稳定命中才是。