直接答案
让 Codex 优先发现可证明的行为问题，再用仓库测试和人类审阅验证；不要用泛化风格建议淹没真正缺陷。
这篇内容解决什么问题
使用 Codex CLI 审查代码并验证测试结果
先明确审查对象和基线
审查前记录当前分支、工作树和目标基线。未跟踪文件、生成文件与已有用户改动都可能改变审查范围，不能只依赖提交标题。
大型变更先阅读需求与接口契约，再按模块或风险分段审查。单次把整个仓库交给模型通常会降低具体性。
git status --short --branch
git diff --stat
git diff --cached --stat
git log --oneline --decorate -n 8
选择正确的 review 模式
--uncommitted 审查暂存、未暂存和未跟踪变化；--base 比较当前分支与指定基线；--commit 聚焦一个提交。一次只选择与问题相符的范围。
基线分支名因仓库而异，不要默认一定是 main。先查看远端默认分支和任务上下文。
codex review --uncommitted
codex review --base main
codex review --commit "$(git rev-parse HEAD)"要求可定位、可验证的发现
自定义审查说明应指出风险领域和输出标准。要求每条发现包含文件位置、触发条件、实际影响和修复方向，并跳过没有行为影响的偏好。
安全、并发、兼容性和错误处理需要结合代码路径判断。不要仅凭模式匹配给出高严重级别。
codex review --base main "优先寻找会导致错误结果、数据损坏、安全问题或兼容性回归的缺陷。每条发现给出文件位置、可触发场景和证据；忽略纯风格偏好，并指出缺失的关键测试。"先复现，再写回归测试和修复
处理缺陷时先运行最窄复现，确认测试在旧行为上失败，再实现修复。只在修改后新增一个立即通过的测试，无法证明它覆盖了原问题。
要求测试描述用户可观察行为，避免绑定私有实现。错误路径、边界值、并发和回滚通常比 happy path 更值得补充。
codex -C /path/to/repo -s workspace-write -a on-request "先用现有命令复现 issue；新增一个在修复前失败的最小回归测试，再实现修复。运行目标测试和相关测试组，保留原始失败证据，不要放宽断言。"建立分层验证栈
从快速、局部检查开始，再扩展到模块和仓库级门禁。git diff --check 只能发现空白错误，不能替代测试；构建成功也不能证明行为正确。
真实命令应来自 AGENTS.md、README 或 CI。下面的占位符必须替换，不能原样放进自动化。
# 依次运行仓库规定的目标测试、模块测试、类型检查和 lint
git diff --check
git status --short复核发现并记录残余风险
对每条发现尝试复现或追踪调用链，区分真实缺陷、条件不成立和设计取舍。修复后重新运行相同审查范围，确认没有引入新的差异问题。
最终报告列出实际运行的检查、没有运行的检查及原因、剩余风险和需要人工决定的事项。不要把无法访问环境的测试标为通过。
- 严重级别由可触发影响决定。
- 引用具体文件和行为，不引用臆测。
- 用测试或调用链验证修复。
- 保留业务与安全所有者审批。
官方来源与核验范围
本文以公开官方文档为事实依据；命令和配置可能随客户端版本变化，执行前请同时核对对应来源。
查看技术核验方法