上周三上午出了个小事故。

外包同学反馈某个后台页面打开就报错。一开始以为是后端接口或者数据的问题，顺着 MR 和 AICR 一路查下去，最后发现原因特别小：有个文件里，list 结构体参数少了一个标点符号。就这么一点东西，页面直接挂了。

这类问题最烦。不是大逻辑错了，是那种本来一眼能看出来、偏偏在 Review 里被漏掉的小毛病。我们组的 MR 不少都会到我这里来过一遍，数量一多很难每次都看得特别细。我自己提的 MR 也一样，要走两三个人的 Review，大家都忙，最后很容易变成"看过了"但没真看出什么。

那次事故之后，我开始在提 MR 之前加一步：先让 Codex 过一遍。

现在我的写代码流程变成了：Claude Code 或 Cursor 写代码，Codex 做第一轮 Review，自己修一轮，再提 MR。

怎么接进去的

用的是 Claude Code 的 Codex 官方插件。装好之后就能在 Claude Code 里直接调 Codex 做审查。

/plugin marketplace add openai/codex-plugin-cc
/plugin install codex@openai-codex
/reload-plugins
/codex:setup

跑完就算接好了。

验证一下：

/codex:review --background

看状态：

拿结果：

/codex:result

这一套能跑通就说明没问题了。

日常怎么用

写完代码之后，我会先自己过一遍改动，跑跑测试，别把太明显的问题甩出去。然后让 Codex 做一轮整体 Review：

/codex:review --base master --background

这条命令的意思是审查当前分支相对 master 的所有改动。日常小需求用这个就够了。它经常能帮我抓到一些比较碎但容易漏的东西——参数处理不完整、返回值结构不一致、某些分支没考虑到、测试没补全。不是每次都能发现大问题，但拿来"先筛一遍"确实管用。

单文件审查用得更多

整个 MR 改动不小的时候，我通常只想盯某一个关键文件。比如某个 service、某个 controller，或者某个改动比较大的业务逻辑文件。

这种场景我直接让 Codex 看单文件：

/codex:adversarial-review --wait 只分析 @config_online/mqueue.yaml  文件本身的代码问题，不要分析其他文件，用中文输出，简洁回答

如果是最近一次提交里的文件：

/codex:adversarial-review --base HEAD~1 --background 只分析 @config_online/mqueue.yaml

日常建议用第一条，--wait 会等结果出来再返回，不用再手动去拿。

这种方式对"文件级别的小坑"特别管用。有些需求代码量不大，但文件本身关键，人工 Review 因为上下文太多很容易漏掉细节。先让 Codex 看一轮，心里踏实一些。

说说实际感受

用了一段时间，最大的变化不是省了多少人力，是那些本来不该流到后面的低级问题被提前拦住了。

后端开发里有些问题真的不复杂，但很伤：一个标点符号写错，一个数组参数漏了，一个返回结构没对齐，一个小分支没兜住。这些东西如果在本地就被发现，后面 Review 的压力会小很多。

我现在把它定位成 Review 前面的一道保险。不是替代人工 Review，是在人工 Review 之前先把明显问题过滤掉。

两类场景用着最顺手：日常小需求，功能不大但容易出细节问题；常规文件检查，某个 service 或 controller 改了，先让它过一遍。

门槛不高，但确实实用。如果你平时也经常帮别人看 MR，或者自己就在 Claude Code、Cursor 里写代码，可以试试。

我是赛博李同学大厂写代码的，觉得有用的话，点个赞 + 转发给需要的TA，感谢支持！，我们下期再见！