最近我提交代码前的动作多了一步先在终端里跑一遍codex review。这个功能是 Codex 新增的代码审查命令它会读取你本地 git 工作区的未提交变更和最近提交由大模型逐段检查输出一份问题清单。对很多程序员来说AI 写代码已经见怪不怪但真正敢把生成结果直接合进主干的人不多相比之下AI 审查反而先在真实工作流里站住了脚。原因很简单写代码是“从无到有”的创作审查是“从有到优”的找茬后者对上下文要求更少、失败成本更低、结果也更容易验证。这篇文章不聊宏大概念只讲三件事为什么审查比写代码更容易落地Codex review 怎么用起来以及我在实际项目里踩到的坑。1. 为什么 AI 审查比 AI 写代码更先落地1.1 写代码是创作审查是找茬AI 写代码的本质是生成式任务模型要在长上下文里规划模块、保持变量命名一致、遵守项目里看不见的约定然后产出一段从零开始的代码。这种任务最大的问题是“上下文越长越容易失控”一个五个文件的项目让模型从头写前 200 行可能很漂亮到后面它可能已经忘了最早定义的类型叫什么。我拿 Codex 做过类似实验让它写一个带缓存的小服务结果前两个文件都很正常第三个文件里它把缓存 key 的拼接规则写错了而且错误在第一版里根本看不出来只有跑起来触发特定场景才会暴露。更麻烦的是这类生成错误没法在写的过程中自动发现必须靠编译、测试、人工 review 层层兜底。审查任务恰好相反。给 Codex 一份 diff它只需要回答一个问题这段改动有没有问题输入范围小、目标清晰、结果可复核。它不需要维护整个项目的心智模型只需要把眼前这几百行和它记忆里的最佳实践做对比。打个不严谨的比方写代码像是让一个人从零写一篇两万字的中篇小说审查是让另一个人拿着修改清单通读稿件找错别字——后者显然更容易稳定发挥。1.2 审查有明确的验收标准生成没有AI 写代码是否成功标准很难一句话说清能编译能跑通主流程性能达标边界覆盖每一项都要额外验证。而“审查结果是否有用”的验收标准简单直接它列出的问题你是否认可或者你是否愿意把其中一条复制到自己的整改清单里。这个反馈周期非常短你用同一个 diff 跑三次 review看输出是不是稳定十几分钟就能得出结论。另外审查有个隐性优势——它不改动代码。AI 写代码一旦自动应用补丁如果模型理解错了需求代码库就被改动污染而审查只产生意见哪怕报了 20 条误报你手动忽略即可不会对系统造成任何副作用。这决定了它可以被放心地纳入自动化流程跑到 PR 提交前跑到 CI 里都不带来破坏性风险。1.3 成本结构决定落地顺序抛开技术不谈钱和时间的账也得算。让模型写一个模块动辄几万 token写到一半很可能超出上下文窗口又得重新总结、重来。审查一个几百行的 diff通常几千 token 就结束了而且不需要最强最贵的模型。Codex 默认提供的模型够用接入一些兼容 OpenAI 协议的模型也完全能胜任审查任务。这解释了为什么很多团队从“代码补全”和“代码审查”切入 AI 落地而不是一开始就让 AI 重写整个系统低风险、低 token 消耗、结果可解释。对你个人来说把 review 当成提交代码前的最后一道廉价检查是性价比最高的一种用法。2. 先把 Codex review 跑起来2.1 安装和准备一个干净的 Git 工作区Codex 的命令行工具目前主要通过 npm 分发。已经装过 Node 环境的机器上一条命令就能装完npm install -g openai/codex装完之后敲codex --version确认可用。注意一点Codex 的 CLI 版本迭代很快命令参数在不同版本之间可能有细微差异遇到不认识的新参数直接查codex review --help以本地版本为准。如果你更习惯图形界面VS Code 的 Codex 插件里也能触发审查跟终端命令共用同一套配置只是展示形式更友好。Codex review 依赖 Git 工作区来定位变更。它默认审查的是你当前分支上还没提交的改动以及最近一次或几次提交。所以在跑 review 之前项目一定要处在 git 仓库里并且你最好先git add了准备审查的文件或者至少让工作区有可对比的 diff。干净仓库也能跑只是它会去审最近的提交。登录和鉴权是很多人第一道坎。Codex 支持通过codex login完成账号登录也支持在环境变量里配置 API Key。如果你用的是兼容 OpenAI API 的第三方模型服务比如 DeepSeek或者公司内部的自建网关可以通过设置 base_url 的方式把 Codex 指向那里以较低成本把 review 流程跑起来。后续在配置章节我会给具体写法。2.2 第一条命令从单个文件开始第一次用不要急着全仓扫描挑一个小文件或者自己刚改完的一个文件就够了。假设你在一个 Go 项目下刚改了internal/service/order.gocodex review --files internal/service/order.go命令跑起来之后Codex 会把该文件当前内容和 git 里的基线做对比把变化的部分作为审查输入模型逐段扫描最后在终端输出问题列表。我第一次跑的时候大概花了不到 30 秒输出里带了严重程度、文件行号、问题描述和修改建议整体格式比较贴近常规代码评审工具。如果你的项目里大量文件都没提交也可以先在本地git commit一次再用codex review --since HEAD~1只审查最近这个提交这样输出会更集中不会被几十个文件的信息冲散。我自己后来一直用这种模式比裸跑 review 稳定得多。2.3 看明白输出并知道下一步怎么追问Codex review 的输出通常不是“这个文件有问题”这样笼统的结论而是逐条列出问题。我遇到过三种比较典型的表现一是很扎实的真问题你能看到哪一行存在空指针隐患二是价值有限的提醒比如“这个函数命名不够直观”属于风格建议三是误报它不了解业务上下文把某种必要的写法当成了风险。遇到模棱两可的问题我建议直接追问它不用自己揣测——“你说第 42 行有资源泄漏风险具体是哪条路径”让它在原问题上继续推理。审查类任务的好处就在于可解释它愿意把推理链路打开给你看。你要做的不是全盘接受而是把输出当作一份索引自己挑值得看的条目去确认。3. 把 review 调到更准配置、提示词与模型接入3.1 配置文件Codex 的 config.toml 到底能改什么Codex 的配置文件在主目录下的.codex/config.toml里。我用过的常用配置项主要这几个模型选择、审批策略、base_url。一个简化示例model gpt-5.6-sol approval_policy on-request [model_providers] [model_providers.someprovider] name someprovider base_url https://你的服务地址/v1 env_key SOME_API_KEYapproval_policy关系到自动执行的安全边界。如果你只是跑审查建议让 Codex 在准备自动修代码前先征求你同意如果只是一次只读审查其实不需要自动修复权限设成最保守的模式也没问题。这里的 base_url 就是接入第三方模型的入口。Codex 本身兼容 OpenAI 的 API 协议所以你在模型服务商后台拿到一个 API Key在配置里把 base_url 指到它提供的接口地址就能让 Codex review 用那个模型跑。如果你是自建网关或使用兼容 OpenAI 协议的第三方服务也可以用同样方式接入改动成本非常低。3.2 常见配置报错unrecognized configuration setting热词里有一条codex is ignoring 1 unrecognized configuration setting. check for typos or d...我猜很多人的第一反应是“难道我配置写错了”。其实这个提示本身并不致命它只是告诉你配置里存在一个 Codex 不认识、也不会生效的键。大部分情况是拼写错误或写错位置。我的处理方法是先备份 config.toml然后用二分法注释掉不常用的段逐项排查是哪一行让 CLI 不满意改掉再跑一遍即可。如果嫌麻烦干脆从官方文档里拷一份配置模板只改你自己需要的值别手写一堆貌似很合理的键名。还有一个常见报错是运行时报the gpt-5.6-sol model is not supported when using codex with a...这通常是你把 model 字段改成了一个与当前服务商不兼容的模型名改成服务商提供的合法模型 ID 就能解决。3.3 提示词工程让审查结果更贴合你的项目同样的代码给模型不同的背景信息审查结果完全不同。如果什么都不说模型只会按通用最佳实践找问题而现实中你的项目有自己的一套语境某些字段是历史遗留、某些文件禁止修改、某些逻辑有特殊业务含义。这些上下文可以在运行 review 时通过 prompt 直接注入。我习惯在 prompt 里写明三件事项目性质、本次变更的目标、特别关心的风险类型。比如这是一个处理用户订单的 Go 服务本次变更主要调整了并发扣减库存的逻辑。请重点检查并发原子性、库存是否可能出现负数、异常路径是否会造成数据不一致。忽略代码风格问题。有了这段上下文模型会从“泛泛的代码顾问”变成“了解业务背景的复审同事”。我实测差别很大同样一段代码不注入上下文时它会报 3 条毫无价值的风格建议注入之后能指出一个真正可能引发超卖的并发问题。3.4 分层设定期望什么该让模型看什么不该用久了你会发现AI 审查的强项是局部扫描弱项是架构判断。局部扫描包括空指针、资源未关闭、错误未处理、并发竞态、危险的字符串拼接架构判断包括模块边界是否合理、接口设计是否优雅、扩展性是否足够——这些它经常给不出有价值的意见甚至会把现有设计瞎批评一通。所以我会把 review 结果按优先级过滤安全问题 逻辑错误 资源管理 可读性 风格。前两类重点关注第三类选择性确认后面的扫一眼就行。这个分层能防止自己被 80 条细碎提示淹没最终错过皇冠上的那颗宝石问题。4. 常见问题与排查技巧实录4.1 登录、组织和连接类问题热词里高频出现“codex登录不上”“codex无法加载组织设置”“codex正在重新连接”“codex一直在reconnecting”。按我的经验这类问题八成不是 Codex 本身坏了而是环境因素网络环境连不上默认服务或者响应超时本地区域服务地址配置错误base_url 写错登录状态过期本地缓存的 token 失效CLI 版本过老新接口不兼容。排查顺序建议是先codex --version看版本再检查配置里的 base_url 是否指向正确地址然后清空 ~/.codex 下的会话缓存重新登录一遍。如果还是不行去官方 GitHub Release 页面下载最新版覆盖安装。Windows 桌面版打不开、安装卡死这类问题多半是 Node 环境或 npm 源的问题更新 Node 到 LTS把 npm 源换到国内镜像基本能解决。4.2 local proxy 报错本地中转服务连接失败有用户会自己搭一个本地中转服务把 Codex 的请求转发到某个兼容 OpenAI 协议的模型接口上目的是统一管理 API Key 或切到更便宜的模型。如果中转服务本身没起来或者 Codex 跟它之间的端口/协议不匹配就会在终端看到类似local proxy failed while handling codex endpoint /responses的报错。处理办法不复杂先确认中转服务进程是否存活用 curl 手动请求一次your_proxy_address/v1/responses看返回再检查 Codex 配置里的 base_url 是否跟中转服务监听地址一致最后看时间同步和超时设置。这类问题独立于 Codex 本体调试思路其实就是通用后端联调。另外有用户报了“vscode写c没有代码提示”这类问题那不是 Codex 的锅多半是 VS Code 的 C/C 插件或编译环境没配置好跟 review 功能是两码事。4.3 审查不准、误报太多怎么办“X 行代码有 NPE 风险”“这里可能未关闭连接”这类提示有时候真的只是误报。原因往往是模型没有上下文或者它把测试代码当成了生产代码。几个实用的缓解手段给定业务背景prompt 注入用 --files 把审查范围限制在真正关注的几个文件明确告诉它忽略测试目录、生成代码、第三方 SDK问它怎么触发这个风险触发不了就别管。还有个技巧遇到一条看起来可疑但不够确定的问题我通常会把它丢回给 AI“假设这段代码在 XX 场景下运行问题会被触发吗”让它推到具体执行路径比让它空谈风险更有价值。4.4 文件太大、diff 太长导致漏检diff 超过一定行数模型会开始遗忘前文review 质量显著下降。我做过一次对比同一个模块一次性审 1200 行 diff输出明显开始重复和自相矛盾拆成 400 行三段分别审问题覆盖度反而更高。所以我现在坚持小步提交。每次改动尽量控制在 300-500 行以内提交前跑一次codex review --since HEAD~130 秒到 1 分钟出结果输出质量稳定还不用跟大 diff 搏斗。如果你确实遇到超长 diff也不要把整个 diff 灌进去先拆成逻辑单元或者让它只审查“新增的函数”和“被修改的关键分支”。4.5 问题排查速查表现象可能原因处理办法登录不上 / 无法加载组织设置网络环境、token 过期、版本过旧升级 CLI、清缓存重新登录、检查 base_url一直在重新连接网络中断或本地中转服务未启动检查服务进程、确认端口可访问local proxy 报错中转网关地址或协议不匹配curl 验证网关、检查 base_urlunrecognized config配置键拼错或位置不对对照文档模板重建 config.toml模型名不支持model 字段与当前服务商不兼容换成服务商提供的合法模型 ID审查误报多缺上下文、范围过大prompt 注入业务背景、用 --files 限制大 diff 漏检上下文窗口溢出小步提交、拆文件分段审查我个人的工作流现在已经变成改完代码先 git diff 自查一遍然后codex review --since HEAD~1把报告中值得看的问题挑出几条该修的让 Codex 直接修修完再跑一遍确认最后才 push。这个过程虽然只有不到两分钟但确实帮我拦住过几次很隐蔽的 bug比如一个边界条件里循环索引写错、一段资源忘记释放。最后分享一个判断标准如果你的 Codex review 每次都是清一色风格建议说明它对你的项目上下文一无所知这时候别急着换模型先想想提示词里有没有告诉它这个项目到底是干嘛的。AI 审查能稳落地靠的不是模型无所不能而是我们愿意给它足够清晰的边界和任务定义。