OpenQodex:在 push 之前为 Claude Code 与 Codex 做开源 AI 代码评审

Published · AI Daily — AI-assisted deep research, methodology & disclosure

OpenQodex 是面向 Claude Code 与 Codex 的开源推送前 AI 代码评审工具。一条 openqodex review 命令会圈定未推送提交与未提交改动,运行匹配的扫描器,只保留改动行上的发现,再由独立评审进程核查,并用脚本校验后输出 HTML、Markdown、JSON、SARIF 报告。无需额外密钥、账号或服务器。

AI 编码智能体把写代码的速度提了上去,却没有同步提高审查的速度。diff 越来越大,人眼越来越疲惫,真正有问题的那几行很容易被淹没在一堆看似合理的改动里。OpenQodex 的切入点很朴素:把评审放到 push 之前,让它成为你离开本地机器前的最后一道关。它面向 Claude Code 与 Codex 两类智能体,也可以直接在终端里运行。核心只有一条命令,openqodex review。它先弄清楚你这次到底改了什么:尚未推送的提交,加上所有未提交的改动。接着,它按改动文件的类型挑选合适的扫描器去跑,并且只保留落在你改动过的那些行上的发现,旧代码里的历史包袱不会来打扰你。 扫描器的结果只是原料。OpenQodex 随后会自己启动一个评审者,也就是一个独立的 Claude Code 或 Codex 进程,让它去读一份被冻结的改动副本。这个评审者要逐条核对扫描器的发现,同时会拿到每一行被改动的代码。它给出的答案不会被直接采信,OpenQodex 会用脚本再检查一遍,最后合成一份报告。这个设计的要点在于分工:规则型扫描器擅长稳定、可重复地发现模式,但误报多、不懂上下文;语言模型擅长理解意图和上下文,却可能遗漏或编造。让后者去裁决前者的每一条输出,再由确定性的脚本去核对后者的结论,三层互相牵制,比单独依赖任何一方都更可信。 评审者的隔离程度,是这个项目最值得细看的部分。按 README 的说法,Claude Code 作为评审者时只带读取、搜索和列目录三类工具,运行在改动副本之内,不加载你的任何设置、钩子、插件、记忆或指令文件。它的事件流会记录每一次读取,所以报告里能列出它读过哪些文件。Codex 的情况略有不同:它在只读沙箱中启动,读取范围被限制在改动副本和系统目录,命令没有网络,也不加载你的配置、插件、钩子和仓库里的指令文件。但文档也坦率承认两点:它仍会加载全局的 ~/.codex/AGENTS.md,而且它的事件流并不显示每一条命令,因此报告只能写明「读取未被记录」。把这类边界写进文档,比宣称绝对安全更让人放心,也提醒使用者按自己的威胁模型判断。

「完整」在这里有明确的定义。一次评审只有在三件事都成立时才算完成:每个阶段都运行过;每一条扫描器发现都被评审者提出,或者带着理由被丢弃;每一行改动都曾出现在评审者面前,可以是在任务简报里、在 OpenQodex 后续发来的消息里,或者对 Claude Code 而言,在它读过的某个文件里。任何一条不满足,工具都会打印「Review incomplete」,而不是给出一个看似圆满的结论。这相当于把「覆盖率」从口号变成了可检查的条件。对于习惯了「LGTM」式含糊结论的团队,这是一个值得借鉴的做法。 输出同样讲究克制。结束时终端会打印一张简短的回执:结论、评审者的摘要、每条发现占一行(编号、严重程度、类别、标题、文件与行号),以及 report.html 和 report.md 的绝对路径。完整报告同时落盘为 HTML、Markdown、JSON 和 SARIF 四种格式,SARIF 方便接入已有的安全工具链。report.html 是磁盘上的单个文件,把每个改动文件渲染成 diff,把每条发现挂在对应代码行下面,再附上覆盖情况、扫描器清单和影响面。据 README,它不运行任何脚本、不加载任何外部资源、转义所有字符串,并对扫描器发现的密钥做脱敏。修复的决定权留给人:随附的技能会让智能体先展示回执,再问「全部修复,还是告诉我修哪几条」,只修你点名的发现,openqodex findings 1,3 可以把指定的发现完整打印出来。

接入成本很低。npx openqodex init 会在本机寻找 Claude Code、Cursor、Codex CLI 和 Cline,列出将要写入的所有文件并只询问一次,然后指出它找到的评审者,或需要你修复的问题。它需要 Node 22 或更新版本和 git,支持 macOS 与 Linux,Windows 用户需借助 WSL,除已登录的 Claude Code 或 Codex 之外不需要任何其他密钥、账号或服务器。除了默认的本地改动,它还能用 review --all 评审整个仓库,或用 review 加分支名、加 '#42' 这样的拉取请求编号,评审并不在你当前工作区的内容。当前版本为 0.12.0,采用 Apache-2.0 许可。

这种做法对日常开发流程的改变也值得一提。以往的代码评审大多发生在拉取请求打开之后,评审者面对的是已经成形的提交历史,作者的上下文早已散落。把评审挪到 push 之前,意味着问题在最便宜的时刻被发现:改动还在本地,作者记忆犹新,修复不会打断任何同事。再加上所有扫描结果都被限定在你亲手改过的行上,报告里的每一条发现都与你此刻的工作直接相关,不必在历史遗留问题里翻找。对于由智能体批量产出代码的团队,这一步等于在提交与共享之间加了一道便宜而可靠的闸门,也让人类审查者可以把精力留给架构取舍和业务判断这类机器仍然难以替代的部分。 从行业角度看,它代表了一种正在成形的模式:评审不再是合并之后的流程,而是智能体工作流里的一个本地、可审计的步骤。当然也要保持清醒。让同一家族的模型去评审同类模型写的代码,可能共享盲区;Codex 路径的可审计性明显弱于 Claude Code 路径;0.12.0 的版本号也说明它仍处于早期。我们引用的是公开的 README 节选,对未覆盖的部分不做断言。但它把「证据、覆盖、人来决定」这三件事做进了产品的骨架,这一点值得每一个把智能体接进日常开发的团队认真对待。

Sources

FAQ

OpenQodex 的 openqodex review 到底评审哪些代码?

它评审尚未推送的提交加上所有未提交的改动,并只保留落在改动行上的扫描器发现。用 --all 可评审整个仓库,加分支名或 '#42' 这类编号可评审不在当前工作区的分支或拉取请求,它会把目标取到临时文件夹里评审。

评审者和你的本地环境隔离到什么程度?

据 README,Claude Code 评审者只带读取、搜索、列目录工具,在改动副本内运行,不加载你的设置、钩子、插件、记忆或指令文件,事件流可列出读过的文件。Codex 在只读沙箱中运行、命令无网络,但仍会加载全局 ~/.codex/AGENTS.md,且读取不会被完整记录,报告会如实说明。

什么情况下评审会被判为不完整?

只要有一个阶段没跑完,或某条扫描器发现既没被提出也没被带理由丢弃,或某行改动没有出现在评审者面前,工具就会打印「Review incomplete」,而不是给出看似圆满的结论。