使用 Codex 做代码审查时最重要的不是提示词写得多复杂而是让它看到正确的变更范围。codex review --base BRANCH 用于审查当前分支相对某个基准分支的全部差异codex review --commit SHA 用于审查某一个提交引入的改动。两者看起来只是参数不同实际回答的是两个不同问题前者关心“这个分支准备合并什么”后者关心“这一笔提交具体改变了什么”。范围选错审查结论可能完整却不适用于你的合并目标。一、--base 适合什么场景功能分支准备合并到 main、develop 或发布分支时使用 --base 最直观。Codex 会把当前工作分支与指定基准的差异作为审查对象适合检查一个 PR 的整体行为包括多个提交共同形成的接口变化、迁移脚本、测试和文档。命令形式可以写为 codex review --base main。运行前应更新远程引用并确认本地 main 是否代表真正的合并基准。若团队 PR 目标是 release/2026.08却固定使用 main审查会混入或漏掉不同的差异。基准名称不是装饰它直接决定比较结果。二、--commit 适合什么场景--commit 适合审查单个提交例如热修复、依赖升级、同事发来的 SHA或在合并前检查某一笔可疑改动。运行 codex review --commit SHA 后审查范围是该提交引入的变化而不是当前分支全部未合并内容。这对堆叠分支尤其有用。一个分支可能包含十个提交你只想检查最新修复是否引入回归使用单提交范围可以减少噪音。不过单提交审查看不到前后提交组合后的最终状态因此不能完全替代分支级审查。三、--uncommitted 又是什么尚未提交的暂存、未暂存和未跟踪改动可使用 --uncommitted。它适合提交前自检。--base、--commit、--uncommitted 和自定义审查提示属于互斥的目标选择命令会要求你明确指定一个范围不应把多个目标参数堆在一起。如果工作树同时存在未提交修改而你运行 --commit不要想当然地认为这些修改也会被审查。先用 Git 查看状态确认自己希望评审的是提交对象还是当前工作现场。范围与预期不一致时应拆成两次审查。四、开始审查前先核对 Git先确认当前仓库根目录、当前分支、目标基准和 HEAD。然后用 Git 自己查看差异统计与文件列表。对于 --base检查 merge base 是否合理对于 --commit确认 SHA 唯一且存在于当前仓库。重写历史、浅克隆和未拉取远程分支都可能让比较失败或范围偏差。CI 的浅克隆常只保留有限历史。若找不到基准或提交不要把错误解释为 Codex 不会审查先补齐所需 Git 历史。仓库包含子模块或生成文件时也要说明哪些变化属于审查范围哪些由构建流程产生。五、怎样写有效的审查要求选择范围后可以补充关注点例如认证绕过、数据迁移兼容、并发竞态或接口向后兼容。要求应与改动业务相关不要只写“认真检查所有问题”。好的说明会交代系统约束和高风险路径让审查优先寻找会导致错误行为的缺陷。同时要求结论引用具体文件和位置并区分阻断问题、一般风险和信息性建议。审查不是代码风格比赛。没有行为影响的个人偏好不应淹没真正的逻辑错误、权限漏洞和缺失测试。如果大家想体验一线 AI 编程模型 codex 和 claude用它们完成分支开发、代码修改、测试和提交前审查可以参考以下教程文档进行接入配置接入配置好后即可使用。文档教程https://my.feishu.cn/wiki/NIgLwuuj1ibzJIkLGM0cgVNinzg六、分支差异为什么可能比预期大目标分支选错是最常见原因。另一个原因是功能分支长期没有同步基准历史中混入重构或格式化。还可能是行尾、文件权限或生成工具版本改变导致大量非业务差异。先用 Git 统计确定异常文件再决定是否整理分支后重跑审查。不要让 Codex 在几万行无关格式化中寻找安全缺陷。把机械变化与业务变化分开提交或使用正确的差异过滤策略会显著提高审查质量。若大变更无法拆分应在要求中指出生成目录和重点模块。七、单次提交审查的盲区一笔提交可能依赖前一笔新增的接口也可能在后一笔才补上测试。只看单次提交时某些调用会显得不存在某些临时状态会被误判为最终设计。审查热修复时应确认该提交可独立应用审查开发历史时则要结合分支最终差异。合并提交也需要特别处理。一个 merge commit 的父提交关系复杂所谓“该提交引入的变化”未必等同于普通提交。遇到合并历史应先用 Git 确认比较语义必要时改用基准分支审查 PR 最终差异。八、如何验证审查结果对每条高严重度发现人工打开相关代码复现触发路径确认它确实由目标差异引入。再运行最相关测试必要时添加回归用例。模型指出“可能为空”并不等于线上一定崩溃同样没有发现也不等于安全。审查结论需要证据闭环。若 Codex 建议修复不要直接扩大改动。优先做最小修复并再次查看 diff确保没有改变公开接口或数据语义。修改后可重新运行同一范围审查但要留意基准是否已经变化。九、团队中怎样固定审查范围PR 流程可以统一使用目标分支作为 --base提交门禁可以对关键 SHA 使用 --commit开发者本地则用 --uncommitted 做提交前检查。三种方式分工清楚就不会用单提交结论代替整分支验收。审查记录应包含目标类型、基准分支或 SHA、运行时 HEAD、关键发现和验证结果。--base 与 --commit 没有谁更高级只有谁更符合当前问题。先把比较对象说清楚再讨论提示词和模型质量代码审查才不会在错误范围里做得很认真。