大家好我是大煊。最近我把 Open Code Review 接进了 Codex使用的是委托模式。Open Code Review 负责筛选文件、匹配审查规则真正读代码和给出判断的还是 Codex。项目特征描述项目名称Open Code Review项目地址https://github.com/alibaba/open-code-review主要语言Go热度趋势累计 ⭐ 19.7k截至 2026.8.8核心定位Open Code Review 是一款 AI 代码审查 CLI 工具通过确定性工程和 LLM Agent 检查 Git 变更并生成行级审查意见。核心价值稳定筛选审查文件、匹配项目规则并定位共性问题减少重复检查业务边界和历史原因仍需项目上下文支撑。一轮个人试用下来我的感受很明确。它适合给本地变更再加一道检查安全风险、硬编码和明显重复这类共性问题都在它擅长的范围内。到了项目架构、业务约束和历史债务这一层它能不能发现问题取决于仓库里有没有足够的上下文。这只是我在自己项目里的使用结果不能代表所有团队。我更关心的问题也很具体。一个已经长期使用 Codex 的开发者再接入 Open Code Review究竟能多得到什么。Open Code Review 在做什么Open Code Review 是阿里开源的一款 AI 代码审查 CLI 工具。Git diff 会决定初始审查范围Agent 还能按需读取完整文件、搜索代码库、查看其他变更文件最后生成带有文件位置和行号的审查意见。它的工程部分负责文件筛选、规则匹配和结果定位模型负责动态读取上下文和判断问题。我选择的是 Codex 委托模式。在这个模式下Open Code Review 提供审查脚手架Codex 使用自身的模型能力完成审查不需要再给 OCR 单独配置模型端点。安装时不用自己拆步骤把下面这段提示词交给 Codex 即可。按照 https://github.com/alibaba/open-code-review/tree/main/plugins/open-code-review#codex 里的 Codex 集成步骤在本地安装 OCR CLI并安装、启用 Open Code Review 插件。完成后检查 OCR CLI 和插件状态确认可以在新任务中调用插件。安装完成后新建一个任务将目录切换到项目下再用下面这段提示词。/open-code-review-codex:open-code-review-delegate 读取全部 diff 并完成审查。确保每个待审查文件都已检查或明确说明跳过原因按 P0、P1、P2 输出问题它对共性问题确实有用AI 把写代码的速度提上来以后Review 很容易变成新的排队点。一批本地改动里可能同时混着配置文件、业务代码和测试代码。人去翻 Git diff注意力很容易被大量改动打散。Open Code Review 会先把需要审查的文件和对应规则整理出来再交给 Codex 分析。我实际看到的结果也集中在共性问题上。比如潜在的安全风险、写死在代码里的配置、比较明显的重复逻辑。这些问题不需要知道完整的业务来龙去脉代码和通用规则已经能提供大部分判断依据。它在这里更像一次稳定的补漏。先按固定范围过一遍再把结果落到具体文件和行号上至少能减少人工反复扫低级问题的时间。真正难审的是代码背后的原因但是做过项目的朋友都知道项目里最重要的往往是代码表面看不出来的约束。拿支付流程举个例子。AI 写出一段代码付款成功后紧接着调用查询接口。从调用顺序看这段代码能运行异常处理也可能写得完整。我们项目原来的设计约束是付款动作只负责付款不耦合任何额外查询逻辑。查询由独立链路承担。这个约束如果没有写进项目说明Open Code Review 看到的只是一段语法正确、调用合理的代码。它不知道团队为什么要做解耦也不知道这条边界来自什么历史问题。Codex、Cursor、Claude Code 面对同样的信息缺口也只能根据通用经验猜测。项目里那些看起来绕的if else也是一样。有些是兼容旧数据有些是暂时不能拆掉的技术债务。缺少背景说明时AI 可能把它当成重复代码也可能建议一次看起来很漂亮的重构。真正的风险恰好藏在“为什么先别改”里面。所以我不会把这类工具当成人工 Review 的替代品。它适合先扫共性问题涉及业务正确性和架构边界的改动仍然要由了解项目的人确认。已经在用 Codex 还值不值得装如果你平时已经稳定使用 Codex、Cursor 或 Claude Code也会让它们主动检查本地变更我不建议把 Open Code Review 列成一个必须专门学习的工具。尤其在 Codex 委托模式下实际理解代码和发现问题的能力依然来自 Codex。Open Code Review 增加的是文件筛选、规则解析和审查流程约束。对个人开发者来说这部分增量有没有价值要看你原来的 Review 流程有多随意。如果每次只是临时对 Agent 说一句“帮我看下代码”它提供的固定入口和规则匹配会更有用。如果你已经有稳定的审查 Skill、明确的检查清单和项目上下文提升可能没有想象中大。比起引入审查类skills,我更愿意优先补这五类上下文工具能读多少代码解决的是信息获取问题。项目有没有把关键约束写下来决定了 AI 拿到信息后能判断到哪一层。我接下来会优先补这五类内容。项目目标和模块边界每个核心模块负责什么明确不负责什么跨模块调用走哪条入口。架构约束哪些能力必须解耦哪些层不能直接依赖事务、幂等和状态流转需要守住什么规则。历史债务说明特殊if else为什么存在兼容哪类旧数据满足什么条件后才允许删除。高风险业务的正反例支付、退款、订单状态等流程分别给出允许的调用方式和明确禁止的写法。给 AI 的审查入口把通用且稳定的要求写进 Review Rules把复杂背景放进项目说明或 Codex Skill并让审查任务能够找到这些材料。这些内容沉淀下来以后Open Code Review 才有机会检查项目真正关心的问题。下次换一个 Agent或者换一个刚接手项目的开发者也不用继续靠老员工口头解释代码为什么这样写。