夜雨聆风
最近看到阿里开源了一个挺实用的 AI 编程工具：Open Code Review。
这是一个 AI 驱动的代码审查工具，主要用来在 Git 项目里自动 Review 代码改动。
简单说，它不是帮你写代码，而是帮你看代码。这点我觉得挺有意思。
过去大家聊 AI 编程，更多是在聊 Cursor、Claude Code、Codex 这类工具怎么帮我们生成代码。但真实开发流程里，代码写完之后，还有一个很重要的环节：Code Review。
而 Open Code Review 做的，就是把 AI 放到这个环节里。
它是什么？
Open Code Review 是一个命令行工具。安装之后，你可以在 Git 项目里运行它，让它根据当前代码改动自动做 Review。
官方介绍里提到，它的前身是阿里内部的 AI 代码审查助手，过去两年在内部服务过数万名开发者，也识别过大量代码缺陷。现在这个工具被开源出来了。
它的核心能力包括：读取 Git diff、分析本次代码改动、调用大模型进行审查、输出结构化 Review 意见、支持行级评论、支持接入 CI/CD、支持自定义审查规则，也支持 OpenAI / Anthropic 兼容模型。
它不是一个聊天机器人，而是一个更偏工程化的代码审查工具。
安装方式
如果你有 Node.js 环境，可以直接通过 npm 安装：
npm install -g @alibaba-group/open-code-review安装完成之后，会得到一个 ocr 命令。然后需要配置大模型接口，比如使用 Anthropic：
ocr config set llm.url https://api.anthropic.com/v1/messages
ocr config set llm.auth_token your-api-key-here
ocr config set llm.model claude-opus-4-6
ocr config set llm.use_anthropic true也可以通过环境变量配置：
export OCR_LLM_URL=https://api.anthropic.com/v1/messages
export OCR_LLM_TOKEN=***
export OCR_LLM_MODEL=claude-opus-4-6
export OCR_USE_ANTHROPIC=true配置好之后，可以先测试一下模型是否可用：
ocr llm test基本使用
进入你的 Git 项目目录：
cd your-project审查当前工作区改动：
ocr review审查某个分支相对 main 的改动：
ocr review --from main --to feature-branch审查某个 commit：
ocr review --commit abc123如果只是想预览会审查哪些文件，不调用大模型，可以用：
ocr review --preview如果想输出 JSON，方便接入 CI：
ocr review --from main --to feature-branch --format json整体使用方式还是比较开发者友好的。
它和直接问 ChatGPT 有什么区别？
很多人现在其实已经会用 AI Review 代码了。最常见的方式是把一段代码复制给 ChatGPT / Claude，然后说：
帮我 Review 一下这段代码。
小改动这样做没问题。但如果是一个真实项目里的 PR，问题就会多很多。
比如文件太多，AI 可能看不全；上下文不完整，AI 容易误判；行号不准确，意见很难落地；每次提示词不一样，结果也不稳定；更重要的是，这种方式很难接入 GitHub / GitLab / CI 流程，也无法沉淀团队自己的 Review 规则。
Open Code Review 的思路不是让 AI 随便点评几句，而是围绕 Git diff 做审查。也就是说，它一开始就知道这次改了哪些文件、哪些文件需要审查、哪些文件应该放在一起看、哪些规则应该应用到哪些文件，以及 AI 的评论应该落到哪里。
这个差别挺关键。因为 Code Review 不是纯聊天场景，而是研发流程的一部分。
比较值得看的设计
我看了一下项目文档，里面有几个设计比较实用。
1. 基于 Git diff 审查
它不是盲目扫描整个项目，而是先看本次改动。这比较符合真实 Code Review 的逻辑，因为 Review 主要关心的是：这次变更引入了什么问题？而不是泛泛地重新分析整个项目。
2. 支持读取上下文
虽然它从 diff 开始，但并不只看 diff。Agent 可以读取完整文件内容，也可以搜索代码库，还可以查看其他相关变更文件。
这对于 Review 很重要。有时候一行代码单独看没问题，但放到上下文里就有问题。比如调用方有没有处理异常，改了配置但没有改文档，改了中文文案但忘了英文文案，改了接口返回但调用方没同步，或者改了权限逻辑但测试没有覆盖。这些都需要上下文。
3. 相关文件会被打包审查
官方文档里提到，它会把相关文件打包成一个审查单元。比如国际化文件：
message_en.properties
message_zh.properties这类文件就应该放在一起看。否则只看一个文件，很可能发现不了“不一致”的问题。这个设计很细，但很实际。
4. 支持审查规则
不同类型的文件，Review 重点肯定不一样。Java 代码、SQL 文件、配置文件、前端组件、国际化文案，不可能都用同一套规则。
Open Code Review 支持规则匹配，也支持项目级规则文件。项目级规则路径是：
.opencodereview/rule.json这意味着团队可以把自己的 Review 习惯写进去。比如哪些路径要重点看安全问题，哪些文件要检查国际化一致性，哪些接口要检查权限，哪些模块要检查异常处理，哪些代码风格团队不接受。
这比每次手写 Prompt 稳定很多。
5. 可以接入 CI/CD
它支持 GitHub Actions 和 GitLab CI，这就比较适合团队用了。
理想情况下，可以变成这样：开发者提交 PR，CI 自动运行 Open Code Review，AI 先输出一轮 Review 意见，人再基于这些意见做最终判断。
这不是替代人工 Review，而是让 AI 先做一轮基础筛查。
适合审什么？
我觉得 AI Code Review 比较适合看这些问题：空指针风险、异常处理遗漏、资源未释放、SQL 注入、XSS、输入校验不足、线程安全问题、重复代码、配置遗漏、多语言文案不一致、明显的边界条件问题，以及简单的可维护性问题。
这些问题很适合让工具先扫一遍。因为它们重复、琐碎，但又确实容易出问题。
不适合审什么？
但也不要把它想得太神。AI Review 目前不太适合完全判断复杂业务逻辑、产品规则是否正确、架构设计是否合理、长期技术债取舍、团队内部隐性约定，以及依赖公司私有上下文的问题。
比如一个优惠券规则写错了，AI 未必知道业务真实含义；一个权限判断看起来合理，但可能不符合公司内部角色体系；一个接口改动表面没问题，但可能破坏了历史兼容逻辑。这些还是需要人来判断。
所以我觉得它比较适合做：第一轮自动 Review。不是最终裁判。
适合谁用？
我觉得这几类人可以关注一下。
1. 开发者个人
如果你经常用 AI 写代码，可以用它帮你做提交前检查。尤其是自己写 side project、开源项目、小工具的时候，跑一遍 AI Review，多少能发现一些低级问题。
2. 小团队
小团队最容易遇到的问题是：大家都知道 Review 重要，但时间不够。如果能在 PR 前自动跑一遍，至少能帮忙挡掉一部分明显问题。
3. 开源项目维护者
开源项目收到 PR 时，维护者往往要花不少时间看质量。AI 先扫一遍，可以减少一点基础负担。
4. 正在用 AI Coding 的团队
如果团队已经在用 Cursor、Claude Code、Codex 这类工具写代码，那更应该考虑 Review 环节。因为 AI 写出来的代码，也需要被审查，甚至更需要。
需要注意什么？
有几个点需要提前知道。
第一，它需要配置大模型接口。也就是说，你需要有可用的 LLM API。
第二，代码隐私要注意。如果是公司内部代码，不能随便发到外部模型。这类工具要在企业里用，最好先确认模型请求发到哪里，是否经过公司代理，是否允许上传代码，是否有私有化部署方案，以及是否符合安全规范。
第三，AI Review 会误报，也会漏报。不要看到 AI 给了意见就直接信。更合理的方式是：让它帮你发现问题，但最终由人判断。
小结
Open Code Review 值得关注的点，不只是“阿里开源了一个工具”。更重要的是，它代表了 AI 编程工具的一个变化：
AI 不只是在编辑器里帮你写代码，也开始进入代码审查、CI、PR 这些研发流程。
这可能比单纯的代码补全更有价值。因为真实的软件开发，不是只有写代码，还包括 Review、测试、合并、发布、排错。
如果 AI 能在这些环节里帮开发者减少重复劳动，那它才算真正进入工作流。当然，它现在还不能替代人工 Review，但作为提交前检查、PR 初审、团队规则辅助，我觉得已经值得试一试。
如果你是开发者，或者你所在团队已经开始用 AI 写代码，可以关注一下这个项目，最后奉上项目地址：
• 项目地址：https://github.com/alibaba/open-code-review
点击下方卡片，关注公众号“TJ君”
每天了解一个牛x、好用、有趣的东东