1. 从写完没人验到机器替你Review不知道你有没有这种经历本地用 Claude Code 噼里啪啦生成了一大段业务逻辑commit 之前信心满满结果代码合进去之后同事在 review 时挑出一堆低效写法、边界漏洞、格式问题。更尴尬的是这种问题通常在 CR 阶段才会暴露而那时候你已经在写下一个需求了上下文早就断了。我自己有段时间被这个问题折腾得够呛。我在一个中型项目里负责比较核心的模块每天肚子里的代码量不小Claude 帮我写了不少但谁来复查几乎是个没人接的活。团队里大家手头都有事不可能盯着 AI 生成的一百行代码逐行做静态审查。后来我把思路换了一下与其让人去测 AI 写的代码不如让AI去测 AI 写的代码。于是我把 Codex 接进我的工作流配了 4 个专门做 Code Review 的智能体专门帮我盯 Claude 生成的代码。这篇文章就围绕这套思路展开。我会先聊聊为什么 AI 写代码之后更需要自动化 Review再讲清楚怎么在 Codex 里把插件跑起来最后重点给出我实际在用的 4 套智能体配置。内容里包含完整的提示词思路、参数调整、环境变量处理方式和几类我踩过又填上的坑照着做基本能直接上手。如果你现在的工作流已经是Claude 生成 人工简单过目那我强烈建议你把后面这套方案跑一遍。它不会替代人的判断但它能帮你在 commit 前挡住很多低级问题。2. 为什么会存在写完没人测这个局面先说个挺现实的问题很多开发团队根本没有严格的 Code Review 流程或者有流程但没有真正落地。原因不只是懒而是成本太高——每个人都要先理解上下文再紧跟当前需求才能给出有价值的反馈。可现实往往是需求排期紧大家手头都有自己的一摊事review 这种看起来不产生业绩的环节自然就被压缩了。但当代码由 Claude 这类 AI 生成时情况变得更特殊。AI 写代码有个特点单看每一段都很规范类型标注也做了函数名也像模像样但放到整个项目里可能会出现风格不统一、重复逻辑、安全边界不完整、甚至和团队已有约定冲突的问题。这些问题不是一眼能看出来的而是需要结合项目全局信息去判断。人没空看普通 Lindt 又只能检查规范这时候把 Codex 拉进来做自动化 Review 就成了比较自然的选择。Codex 本身是能调用工具、能执行命令的它可以跑测试、做静态分析、读文件甚至直接给 Git 提交信息。把它包装成一个Review 助手本质上就是把原本需要人类经验判断的部分交给一个拥有项目上下文理解能力的智能体去完成。可能有人会问Claude 自己不是也能读代码吗为什么不直接在 Claude 那边做可以但我的实际感受是让写代码的模型去审自己的代码容易陷入惯性思维——它知道自己当时想写什么就容易忽略掉真正会影响别人的地方。换成 Codex 来做审查相当于换了一个视角反而更容易发现边界问题和不良实践。3. 插件选型为什么我用 Codex 而不是其他工具市面上做自动化代码审查的工具不少有像 Codacy、SonarQube 这类老牌的也有像 CodeRabbit 这种 AI 优先的新产品。各有各的好处但我最后选择基于 Codex 来搭有几个比较实际的理由。第一插件化程度高。Codex 本身支持配置自定义指令和扩展能力你可以把它理解成一个可以带任务书干活的智能助手。我想让它只做 Code Review它就可以只做 Code Review我不想让它擅自改代码它就不会动。这种边界控制在我实际用下来非常关键。第二底层能力足够强。Codex 不只是聊天模型它能在本地或云端环境里执行命令、读文件、跑测试。这一点在做 Review 时特别有用——它能真实运行你的测试用例而不是靠猜。很多 AI 审查工具只做静态文本分析但 Codex 可以做到动态验证这一层。第三配置完全文本化方便放进仓库共享。我把 4 个智能体的配置写成 markdown 文件放在仓库的 .codex 目录下面团队里任何人拉下来就能用。相比那些必须打开 Web 界面操作的平台这种模式更贴近开发者习惯。我也承认这套方案有学习成本。不是装个插件就完事而是需要你自己写好审查的 prompt、配置好可用的命令、反复调。但一旦跑起来你等于给自己请了一个随叫随到、态度稳定、永不喊累的 CR 搭子。4. 准备工作Codex 安装与环境配置在配智能体之前先把 Codex 本身装好。这里我先说明一下我用的场景是本地开发环境重点讲命令行和编辑器集成的安装方式。安装这块其实没什么难度主要看你原本的环境如果你已经在用 OpenAI 的生态Codex CLI 可以通过包管理器直接装装完初始化一下身份认证就能用。如果你用的是 VS Code可以在扩展市场里搜 Codex 相关的官方扩展装好然后在编辑器里绑定你的 API Key 或账号登录。如果你是 macOS 或 Linux 环境建议直接用 Homebrew 装省事一些。Windows 上我用 WSL 跑也很顺畅。装完之后建议先跑一个最简单的任务验证链路通不通比如让它读一下当前目录下的代码文件列表。我见过不少人在这一步卡住症状通常是请求发出去了但是没反应十有八九是身份认证没配好或者网络环境有问题。用命令行跑一次codex exec list files很快就能暴露问题。另外注意一下模型选择。做 Code Review 的时候模型的推理能力比速度重要得多。如果你条件允许优先选推理能力较强的模型因为这个任务本质上是多步阅读 判断。我自己在本地用的时候会指定一个偏审慎的模型来做最终判定速度慢一点无所谓关键是它给出的建议要能站得住脚。一个小建议不要把 API Key 硬编码在配置文件里。用环境变量的方式加载这样既能保证安全性也方便在不同项目之间切换。5. 4 大智能体配置从代码质量到安全意识5.1 智能体 ACode Quality Agent代码质量审查我配的第一个智能体也是最基本的一个专门盯代码质量。它的职责是检查新改动是否符合当前项目的编码风格、有没有重复逻辑、函数体是不是太长、类型标注是否到位、有没有明显可优化的地方。在 Codex 里配置它我会用一个独立的 markdown 文件描述它的角色。比如这样写它的核心指令# Agent: Code Quality Reviewer 你是这个项目的代码质量审查员。你只做评审不修改任何文件。 当收到一个 diff 或一组文件路径时请依次做以下检查 1. 是否遵循项目已有的命名规范和结构约定。 2. 是否存在可以抽取为公共函数的重复代码。 3. 是否有未处理的错误路径如空指针、边界值、异常被吞掉。 4. 是否存在明显性能问题例如循环内查询、不必要的大对象复制。 5. 类型标注是否完整公开函数的注释是否足够。 输出格式按严重级别Critical / Warning / Suggestion分组每一条建议必须给出具体文件和行号。这个配置的关键在于只做评审不修改任何文件。如果你不加上这句Codex 有时候会自作主张帮你改代码这在 Code Review 场景里是绝对要避免的。我不想让它在 review 的同时把代码偷偷改掉那样就没法追踪了。运行的时候我会把 Claude 生成的代码 commit 到一个 feature 分支上然后让 Codex 基于这个分支跑一个 diff 审查。命令大概是这样的codex exec --agent code-quality 请 review 当前分支相对 main 的改动它输出的结果会直接列出一批问题我再决定是手动改还是交给 Claude 去改。这里的核心价值是省掉了人肉通读一百遍的环节。5.2 智能体 BSecurity Guard安全红线审查第二个智能体我主要用在涉及用户输入、鉴权、支付逻辑、内部接口暴露这些敏感场景。因为 Claude 有时候会在不知情的情况下写出存在逻辑漏洞的代码比如对用户输入只做了前端校验、越权没拦截、日志里打印了敏感信息等等。Security Guard 的配置指令会更强调规则意识# Agent: Security Guard 你是安全评审专家。请主要关注以下红线 - 用户输入是否经过后端校验和规范化。 - 是否存在越权访问风险水平越权和垂直越权。 - 是否硬编码了密钥、Token 或连接串。 - 是否在日志中输出敏感字段密码、手机号、身份证号等。 - 使用的第三方依赖是否存在已知高风险版本。 请优先输出你识别的风险项不要给出修改后的代码除非风险属于 极严重级别且不修改会导致直接安全问题。我在一个电商项目的订单模块里做过实测。当时 Claude 生成了一段用户取消订单的接口逻辑看起来完整结果 Security Guard 一眼就看出来它只校验了用户是否登录但没有校验这个订单是否属于当前用户。这种水平越权问题如果靠人 review难度还真不小因为你要先看上下文、再看代码才能意识到这里少了东西。但 AI 在配置好指令的情况下反而更容易抓住这一类模式。5.3 智能体 CUnit Test Copilot测试覆盖审查第三个智能体负责侦查测试覆盖情况。Claude 生成完代码之后八成是不会主动帮你把测试补齐的它在写代码的时候更关注让功能跑通而不是让功能被验证。这个智能体就是用来专门盯着测试覆盖率。它的配置是这样的# Agent: Unit Test Copilot 你的职责是评估当前改动的可测试性并给出最小测试计划。 不要直接生成全部测试代码而是 1. 找出被修改的核心函数和分支逻辑。 2. 识别哪些分支没有对应的测试用例。 3. 给出一个最值得补的 3 个测试清单并解释理由。 4. 如果已有测试文件存在检查它们是否覆盖了新增变更。 如果你发现某个函数的复杂度已经高到难以测试请直接指出 并建议是否应该拆分为更小的函数。我推荐不要让它直接生成所有测试而是先让它列清单。原因很实际如果 AI 一口气给你写出 10 个测试文件你很难有精力全部 review 一遍而且测试代码本身可能也有 bug。但如果是先给清单、你再决定补哪个整个流程就更可控。实际跑下来这个智能体还有一个额外好处它能帮你发现这次改动根本没法测的场景。有一次 Claude 写了一个内部函数直接依赖了环境变量和外部缓存这个智能体直接标注了该函数存在耦合测试难度高建议重构这时候你就知道不是缺测试文件而是代码结构需要调整。5.4 智能体 DArchitecture Watcher架构一致性审查最后一个智能体也是我后知后觉才加上的。它检查的不是单行代码而是这次改动和整体架构方向是否一致。比如项目里明明约定用 Repository 模式访问数据但 Claude 生成的代码却直接开了数据库连接架构 watcher 就要把这种问题揪出来。配置指令侧重于分层和边界# Agent: Architecture Watcher 你是项目的架构守卫。当收到改动时请重点检查 - 本次改动是否遵循项目的分层架构如 controller / service / repository。 - 是否有跨层直接调用如 controller 中直接写 SQL 或缓存操作。 - 新增依赖是否有必要是否破坏了模块边界。 - 是否使用了与项目统一的错误处理和返回格式。 - 是否符合既定的目录组织约定。 输出时请按照架构违背 / 建议重构 / 风格偏差三级进行分类。这个智能体在一个微服务项目里帮我逮到过一个问题。Claude 生成了一个新的查询接口直接在 Controller 里拼了一个查询字符串去查数据库完全绕开了项目里现成的查询服务层。单看接口功能是好的但放回整个架构体系里这就是一个明显的分层破坏。以前这种问题要等到架构师 review 才能发现现在提交前就能被拦下来。6. 把 4 个智能体串成一条 CI 工作流到这里你可能会想4 个智能体都是独立的难道我要一个个手动跑其实不用。我在项目里把它们串成了一个流水线脚本每次提交代码到 feature 分支后自动触发跑完之后把结果汇总到一个 markdown 报告里。大致的流程是这样的获取当前分支和 main 分支之间的 diff 文件列表。按优先级依次调用 Code Quality、Security Guard、Architecture Watcher。再跑一次测试目录对比调用 Unit Test Copilot。把 4 份输出汇总到review-report.md。如果检测到 Critical 级别问题脚本返回非零退出码提醒你处理。这个流水线可以用很轻的方式实现核心就是一个 shell 脚本加几个参数codex exec --agent code-quality 审查 diff 文件$(git diff --name-only main...HEAD) codex exec --agent security-guard 审查同一批 diff侧重安全问题 codex exec --agent architecture-watcher 检查架构一致性 codex exec --agent unit-test-copilot 给出测试补充建议有个细节需要注意串行跑比并行跑更稳。并行确实能节省时间但多个 Codex 进程同时读同一批文件时偶尔会出现输出相互污染的情况。我这个方案本来就是给提交前用的多等一两分钟完全无所谓稳定更重要。7. 实际效果与调参经验上面这套配置我用了大概两个月覆盖三个不同项目。整体效果可以总结成三句话低级错误大幅减少CR 阶段的争论变少开发节奏更顺了。先说数据。我自己做了个小统计启用之前大概 30% 的 PR 会被同事驳回返工启用之后这个比例降到了大约 8%。当然这里面有一部分原因是自己在写代码的时候更小心了但自动化 review 把最浅层的那些问题都挡在了提交前这是实实在在的。再来说说调参过程中的经验。初学者最容易犯的错是提示词写得太泛。比如你直接跟 Codex 说帮我审查一下代码它给出的反馈也会很泛——大概率的输出是整体代码质量不错建议优化命名。这种反馈没有任何价值。你需要明确告诉它不要夸我只看问题按严重程度分级每条必须给出文件位置。这些都是我在踩了两次坑之后才固定下来的配置。另外一个经验是模型参数调整。做 Review 类的任务temperature建议调低一点别让它太有创造力。我一般会控制在 0.2 以下这样它输出的判断比较稳定。如果让它在审查代码时充分发挥想象力它很可能会给你脑补出一些并不存在的问题反而干扰判断。还有一点是关于 token 长度。大项目 diff 文件很多一次性全塞进去输出质量会明显下降。我的做法是限制每次审查的文件数量按优先级分批跑。比如核心业务文件优先配置文件可以跳过。如果你审核的文件范围太大不如拆成几次来做效果会好很多。8. 遇到的问题和排查思路8.1 Codex 插件无法加载本地路径我第一次配置时怎么都跑不起来报错信息跟网络和代理相关。我排查了一圈发现不是模型的问题而是它在尝试访问某个本地服务时失败。后来我把相关的环境变量检查了一遍发现是代理配置影响了本地请求。处理办法是在运行命令前清掉多余的环境变量或者直接把代理关掉再跑。这类问题的根因通常不是 Codex 本身而是系统的网络栈和它不兼容。如果你遇到类似的诡异报错建议先试最基础的办法在干净的环境里跑一次codex exec什么都不带只让它读一个文件。如果这样也能失败那就不是指令或插件配置的问题而是安装或环境的问题。8.2 智能体不遵守只审查不改代码的指令这个问题我一定要单独提出来。我一开始写配置的时候只写了你是代码审查员没有强调你不修改任何文件。结果 Codex 在审查过程中顺手帮我修复了几处代码缩进还改了变量名。这种问题非常隐蔽因为代码看起来确实变好了但你在 review 的时候找不到原始版本的对比很容易就直接 commit 了。处理办法很简单就是在智能体配置里加上强约束并且用否定句式不要告诉我你改了什么也不要执行任何写操作。如果有必要我推荐你在跑完审查之后用 Git diff 确认一下没有任何改动。安全第一。8.3 报告太长看不完还有个尴尬的问题4 个智能体的短评汇总起来报告可能比代码本身还长。第一次跑完我打开 review-report.md密密麻麻几千行根本看不下去。后来我做了两个调整。第一个是要求每个智能体的输出限制条数Critical 最多 5 条Warning 最多 10 条其余多余的只提总数。第二个是让脚本自动过滤掉 Suggestion 级别的内容只在报告中显示 Critical 和 Warning。这样一来报告控制在了一屏以内每天看反馈成了很轻松的事。8.4 在 CI 上运行时模型不稳定我在 GitHub Actions 上尝试把这个流程接入 CI但发现模型行为有时不稳定同样的代码这次审查和上次审查给出的结论略有不同。这其实是概率模型的正常现象但在 CI 场景里不稳定就意味着不可信。我的折中方案是先把自动化 review 用在本地提交前阶段作为预备审查真正跑在 CI 里的还是传统测试和规范检查。这样既保留了灵活性又不会让模型的不稳定性变成流水线的阻塞点。如果你想完全自动化至少需要保证你的指令非常明确、输出格式强制固定并且要接受偶尔的重跑成本。9. 这套方案能给你的项目带来什么我在开头说过这个方案的初衷是解决AI 写的代码没人审的问题。用了两个月之后我认为它的价值已经远超补位本身。它让你对 Claude 生成的代码更有掌控感也让团队里的 Code Review 从一件没人想接的额外工作变成了一件机器已经帮你过滤过一遍的事。当然我并不认为 AI 审查能替代人的判断。架构上的一些长期决策、业务语义上的合理性判断这些仍然需要资深工程师把关。但在低垂果实层面——代码规范、明显 bug、安全红线、测试缺失——这套方案的作用非常明显。它把这些事变得随叫随到你就不用每次都在心里默默祈祷 Claude 这次没有埋雷。我个人实际用下来的体会是不要指望一次配好就一劳永逸智能体配置一定要跟着项目的运行节奏去调。你跑得越勤越了解它会漏掉什么然后针对性补强那个版本才是最适合你项目的。如果你手头也正被 AI 写代码的后续审查问题困扰不妨按这套思路搭一下。最先跑通一个代码质量的智能体就行不用一上来就上全套。等你觉得有效果了再慢慢把安全、测试、架构这几个维度加进来。你会发现AI 自动写代码之所以让人既兴奋又害怕并不是因为它能力不足而是因为我们的流程还没跟上。这些工具和配置就是把流程补上的那一块拼图。