先别手写，用codex做代码评审

先别手写，用codex做代码评审

去年年底，我们团队接手了一个金融交易系统的重构项目。那段时间，我要同时盯三个项目的代码，最疯狂的一周，经手了23个PR。有一天晚上，我发现自己已经盯着同一个变量命名问题在不同的PR里反复写了五遍几乎一样的评论。那一刻我突然意识到：我花在“重复评审”上的时间，已经远远超过了真正需要我判断的“复杂逻辑审计”。也就是在那个月，我开始尝试把Codex塞进评审流程里。

结果不是“一夜解放”，而是一个更微妙的变化：Codex帮我筛掉了80%的低级重复问题，而我终于有精力去追问一个分布式事务的一致性边界到底设在哪儿合适。这篇文章聊的，就是那段经历沉淀下来的东西，不是“怎么装插件”，而是在你真的用Codex做评审之后，该用什么样的思维方式去设计这套工作流，才能让它不只是替你干活，更是替你长脑子。

不止是提效，是把你的评审习惯“制度化”

大多数人对Codex做评审的印象，还停留在“打开PR，粘贴diff，输入‘审查这个PR’，然后看它刷出一堆建议”。这个用法本质上跟“让实习生帮你看看代码”没区别，每次都是临场发挥，每次都要重新交代上下文，而且这次提的问题下次可能就漏了。

我试了大概两周之后发现，真正好用的不是Codex的“编辑能力”，而是它审代码时的“固定检查逻辑”。于是我开始做一件事：把我脑子里每次审PR都会过的那套检查项，写成一份.md文件，喂给Codex。

这份文件包括三块：

1. 硬性规范清单：变量命名规则、函数长度上限、循环嵌套深度阈值、必须写注释的场景。
2. 团队踩坑记录：过去在生产环境出过事故的代码模式，比如“对用户输入做float()转换但不捕获异常”、“在数据库事务里调用外部HTTP接口”。
3. 追问触发条件：某些特定写法出现时，不直接给结论，而是追问“为什么”。

这套东西上线之后，效果很有意思。Codex不再是那个每次都问你“有什么要求”的实习生，它开始像一个记住了你所有评审偏好的自动化质检员。同样一个关于“空指针保护不够”的问题，之前在三个PR里我要手动写三条评论，现在Codex先帮你标出来，我只需要确认。

核心结论：不要每次手写评审指令。把你那套“审查习惯”固化成一个.md文件，也就是常说的Skill工作流。它不是插件，是你的岗位说明书。这份说明书一旦稳定下来，你就从“重复劳动的评审机器”里被解放出来了。

为什么是“评审思维”，而不是“编辑能力”？

一个容易被忽略的关键点是：让Codex改代码，和让Codex审代码，是两种完全不同的工作模式。

“改代码”模式下，你给它一个任务，它直接修改，然后你再看结果。但如果你审得不够仔细，它可能顺手引入一个看起来很合理、实际上有逻辑缺陷的改动。我在一次性能优化的PR里就踩过这个坑：Codex把一段循环里的数据库查询改成了批量查，逻辑上完全正确，但它没注意到这个改动破坏了原有的事务隔离级别，导致并发场景下出现了脏读。

“审代码”模式就完全不同。我现在对一个超过200行改动的PR，会先用create-plan类Skill让Codex先出一份《审查计划书》，而不是直接改。这份计划书必须包含：

• 这次改动涉及哪些模块
• 每个模块的风险等级（高/中/低）
• 如果要合并，必须前置验证的三件事

我收到计划书之后，先判断风险点我是否认可，然后再进入“编辑阶段”。这个流程让我的角色从一个“逐个检查每一行的审计员”变成了一个“确认风险清单和兜底方案的技术Lead”。

对比一下两种模式的时间消耗：

这个表格背后的道理很简单：用Codex做评审，效果的上限不取决于它有多聪明，而取决于你设计的这套评审工作流有多完善。

三步构建你的“评审导师”

我自己设计这套工作流的过程分了三个阶段，每个阶段解决一个层次的问题。

第一步：复刻“团队评审规范”

如果你的团队已经有白纸黑字的《代码评审Checklist》，那这一步最简单：直接把这些规范翻译成Codex能理解的语言和格式。注意，不能用自然语言糊弄，要给它结构化约束。

markdown

必须检查的硬性规范

1. 函数长度：单函数超过50行，必须标记并建议拆分。
2. 嵌套深度：if/for嵌套超过3层，必须标记复杂度风险。
3. 异常处理：所有外部调用（数据库、网络、文件IO）必须有try-except包裹。
4. 测试覆盖：所有新增public方法必须在PR中附带至少一个单元测试用例。

如果你的团队还没有成文的评审规范，这很正常，大多数中小团队都没有，那这一步其实给你一个机会，把你脑子里默会的那套标准外化出来。这个过程本身就是一次团队方法论的对齐。

第二步：输入“坏味道”样本

规范只能告诉你“没做到什么”，但识别“看起来正常、实际上有风险的写法”，需要额外训练。

我在Skill里加入了一组“反模式”案例，都是过去在生产环境真实出过问题的代码片段。比如：

markdown

高风险模式示例

• 在循环中拼接SQL字符串（即使参数化了，也可能导致查询计划缓存的性能陷阱）
• 对用户输入先做strip()再做空值判断，但没处理strip()返回None的场景
• 异步函数内部直接用time.sleep()而不是asyncio.sleep()

Codex拿到这些样本之后，能够识别出同构的风险。这不是因为它变聪明了，而是你帮它把“什么是坏味道”这件事翻译成了它能执行的语法。

第三步：设定“追问机制”

这一点是很多人忽略的，却是让评审从“单向结论”变成“思维训练”的关键。

我在Skill里设了这样的规则：

markdown

追问规则

如果发现以下情况，不直接给出修改建议，而是追问：

• 使用全局变量但未注释其生命周期 → 追问：“这个全局变量在多线程下的安全边界是什么？”
• 新增了一个与已有函数高度相似的实现 → 追问：“是否可以考虑抽象为公用方法？”
• 使用了不常见的算法但未注释来源与决策依据 → 追问：“选择这个算法的取舍理由是什么？是否有性能基准测试？”

这个功能让Codex评审的结果，看起来不像一份判决书，而更像一次资深工程师的Code Review对话。对于团队的初级开发者来说，这种追问远比“这里写错了”更有成长价值。

从“提效工具”到“成长导师”，三层价值阶梯

用了大半年之后，我回过头来审视这套工作流带来的变化，发现它的价值是分层的。

第一层：提升效率。

重复劳动被Codex接管了。我现在一个上午能处理以前需要一整天的PR量，而且漏审率反而下降了。业务线那边说“最近代码合入速度快了很多”，这就是最直接的效果。

第二层：固化经验。

以前团队里最有经验的架构师的评审标准，全在他一个人的脑子里。他休假或离职，这套标准就打个折扣。现在这套标准变成了一个.md文件，谁打开Codex都能得到相同严谨度的评审。团队规范不再是口头宣贯，而是可以执行的代码。

第三层：思维训练。

这是我最没想到的收获。因为Codex会在评审时反复追问“为什么这里选择这个方案”，团队的初级开发者开始养成“写代码时就要准备好解释它”的习惯。三个月下来，同一个人在PR里被问到“分布式锁的超时时间为什么是5秒而不是3秒”的时候，他真的写了对延迟和死锁概率的权衡分析。

引用一位OpenAI一线开发者的话来说：“当你可以同时调度10到20个Agent去执行小时级的任务时，你已经不是在写代码了，你是在做技术调度和方案验收。”用Codex做评审，本质上就是这个转型的训练场。

三层价值划分，可以帮助你判断自己目前处于哪个阶段，以及下一个优化方向在哪：

现实取舍：不是所有PR都适合塞给Codex

这里也需要诚实地说一个限制：不是所有类型的改动都适合用这套工作流。

适合交给Codex评审的：

• 业务逻辑清晰、有大量重复模式的增删改查
• 风格、规范、安全检查这些“法条式”规则
• 重构类的功能等价替换（重构前后行为应该一致，让AI来验证）

不适合、或需要人类主导判断的：

• 核心架构调整（如拆分微服务边界、更换消息队列方案）
• 复杂算法的实现正确性验证（AI可能验证了“看起来对”，但没验证“数学上对”）
• 涉及安全审计的代码（如加密实现、权限模型），目前仍然需要安全专家人工介入，Codex可作为第一轮筛子

我现在的做法是：让Codex负责第一轮“合规性审查”，我负责第二轮“架构与取舍判断”。 第一轮跑完之后，我给出的评论就很少是“变量名写错了”这种事了，而是更聚焦的、更需要经验的问题。

这个分工，让我从一个每天被淹没在机械性评审里的一线操盘手，变成了一个可以专注于“最难那10%决策”的技术角色。

从今天开始，花30分钟创建第一个Skill

如果说这篇文章只有一个你带得走的东西，那就是：不要继续手写评审指令了。把你脑子里那套评审逻辑写下来，装进Codex里。

具体动作：

1. 打开一个文本编辑器，新建一个.md文件。
2. 第一版只写10条你最常重复的评审意见。
3. 明文告诉Codex：“在每次代码评审时，除了检查这10条之外，如果发现不明确的模式，追问设计理由。”
4. 把这个.md文件保存到你的项目目录里，在下一次Codex评审时引用它。

然后你会看到，Codex开始像你一样评审代码。

不是因为它变强了，而是因为你有了一套自己的标准。这个标准一旦稳定，你就不再是那个每天手写重复评论的人。你的评审开始带脑子，你的团队也跟着你一起长脑子。