把脏活累活丢给 Codex代码审查这件事说穿了就是个体力活。你要盯着 diff 看命名是否规范检查空指针有没有漏网之鱼还要在重复代码里找茬。这些工作不需要太多创造力却极度消耗注意力。Codex 进入这个场景后我第一件事就是把这类脏活累活丢出去。实际用下来Codex 对代码异味的识别相当敏锐。重复代码是最典型的例子——它能跨文件定位到逻辑相似的块甚至能识别出结构重复但变量名不同的变体。命名规范方面它不仅能检查是否符合驼峰或蛇形命名还能结合项目上下文判断语义是否清晰。比如getData()这种模糊命名它会建议改成fetchUserOrderSummary()这类带业务含义的表达。潜在 NPE 的排查更让我意外。Codex 会沿着调用链向上追溯标记出这里可能返回 null 但没有校验的点位。有一次它甚至发现了一个我都没注意到的场景某个工具类的缓存方法在并发下可能返回空值而调用方直接链式调用了.size()。设计模式审查能搭脉但开不了方说到设计模式Codex 的表现要分两层看。识别层面它能准确指出这里用了策略模式但缺少上下文封装或者工厂方法和构建者模式混用了职责边界模糊。这种诊断对于初级开发者尤其有价值相当于有个资深同事在旁边随时提点。但重构建议层面就明显保守了。它倾向于给出教科书式的标准实现却容易忽略项目里的特殊约束。比如我们的订单系统为了兼容历史数据策略模式的上下文必须带版本标识Codex 第一次给出的建议完全没考虑这个点直到我把 AGENTS.md 里的业务规则补充进去才调整过来。我的做法是让 Codex 先做模式识别和初步诊断具体的重构方案必须结合人工判断。把它当成一个能发现问题的实习生而不是能拍板的技术负责人。嵌入团队 Review 流程的三种姿势Codex 不是替代现有流程而是嵌进去。我们团队摸索出三种用法前置过滤提交到人工 Review 之前先过一遍 Codex。它能在 30 秒内标出明显的风格问题和低级 bug把人工审查的注意力解放出来聚焦架构层面。这个环节的通过标准我设得比较松——“无致命问题即可放行”不追求一次性修干净。并行审查对于大型 MR让 Codex 和人工同时开工。它负责逐行注释标问题人工负责把握整体设计走向。最后对比双方的审查点往往能找到互补的盲区。事后复盘每周抽几个典型 MR让 Codex 重新审一遍已合并的代码。这种马后炮有意外的价值能发现当时赶工期漏掉的技术债也能校准团队对审查标准的理解是否一致。这些坑Codex 现在还填不上用了两个月我整理出一份仍需人工把关的审查清单业务语义正确性它能检查语法但理解不了这里的折扣计算应该优先使用会员价而非活动价这种业务规则性能陷阱的上下文判断能识别出 N1 查询但判断不了这个接口的调用频率是否真的需要优化安全漏洞的深层逻辑对 SQL 注入、XSS 等有明显特征的问题识别率不错但对权限绕过、竞态条件这类需要业务上下文理解的场景容易漏检架构一致性单个文件的修改是否合理它能判断但这个修改是否破坏了模块间的依赖关系需要人来看设置 Review 通过阈值的心得我现在的做法是分层设阈值不搞一刀切层级检查内容Codex 角色通过标准L1 阻塞项编译错误、明显 NPE、安全漏洞自动拦截必须修复零容忍L2 警告项代码异味、命名规范、简单设计问题标出并建议修复修复率 ≥ 80%L3 建议项设计模式优化、性能提升空间仅标注不阻塞人工判断是否采纳这个阈值不是固定的会根据项目阶段调整。新业务快速迭代时 L2 的修复率可以降到 60%但 L1 的底线绝不松动。偷懒的边界在哪里说到底Codex 让我偷懒的部分是机械劳动的替代而不是责任的转移。我现在提交 MR 前的心态很清晰Codex 审过的代码我还是要快速扫一遍但扫的重点从找 bug变成了验证 Codex 有没有漏掉业务层面的坑。有个挺实际的收益是审查时间的重新分配。以前一个 500 行的 MR 可能要花 40 分钟仔细过现在 Codex 先过一轮人工审查压缩到 15 分钟多出来的时间用来写测试或者做设计。这种偷懒不是消极应付而是把人的注意力从低价值劳动里释放出来。当然前提是你得接受它偶尔会犯傻。有一次它建议我把一个工具类改成单例模式却忽略了我们部署环境是多实例的——这种建议如果无脑采纳反而引入问题。所以我的底线始终没变Codex 是审查流程里的一个环节不是终审法官。