使用 Codex 进行代码审查、测试与修复
发布于 2026年7月17日更新于 2026年7月17日作者：Codex 中文指南
Codex 很适合审查跨文件改动，因为它可以同时读取差异、调用方和测试。但有效审查需要把重点放在行为回归、数据风险和缺失验证上，而不是输出大量风格建议。
审查前准备
先明确比较基线。当前工作区、某次提交和整个功能分支的范围不同：
bash
git status --short
git diff --stat
git diff main...HEAD --stat如果工作区有未提交改动，告诉 Codex 它们是否属于审查范围。不要让它误把本地实验当成分支实现，或忽略尚未暂存的关键文件。
一条高信号审查提示
text
审查当前分支相对 main 的改动。
优先检查行为错误、权限绕过、数据损坏、并发问题、兼容性回归和缺失测试。
每个问题给出严重程度、文件与行号、触发条件和影响。
不要把纯风格偏好列为问题；先不要修改代码。“先不要修改代码”能把发现问题和实施修复分开。你可以先判断问题是否成立，再选择要处理的项。
从测试复现开始修复
对于已确认缺陷，优先要求一个能够失败的测试：
- 用最小输入稳定复现问题。
- 确认测试在修复前失败，且失败原因正确。
- 实施范围最小的修复。
- 运行新测试和相关回归测试。
- 查看差异，确认没有无关重构。
如果无法在当前环境复现，应让 Codex 说明缺少的服务、数据或权限，不要用“理论上通过”替代实际结果。
测试选择要与风险匹配
修改一个纯函数时，单元测试通常足够；修改共享鉴权、中间件或数据库事务时，应扩大到集成测试。前端交互还要检查加载、错误、空数据和移动端状态。
可以要求 Codex 先列出影响链：修改的函数被哪些模块调用、哪些测试覆盖这些路径、是否存在无法本地验证的外部系统。这样测试范围来自实际依赖，而不是机械地运行整个仓库。
审查 Codex 自己的改动
Codex 完成功能后，可以在新会话中进行独立审查，减少同一上下文中的确认偏差。审查者应读取实际差异，不只读取前一个会话的总结。
重点检查：
- 是否满足原始验收条件。
- 是否改动了未授权的公共接口或配置。
- 新测试是否真的会在旧实现上失败。
- 错误处理是否泄露敏感信息。
- 边界值、并发、重试和回滚路径是否合理。
- 依赖或锁文件变化是否必要。
最终交付应包含什么
一个可信的完成总结应列出改动目的、关键文件、运行过的准确命令和结果，以及没有验证的风险。不要接受只有“已修复并通过测试”的总结；它至少要说明测试名称或命令。
如果项目通过第三方模型提供商运行 Codex，例如 APIBest，工具调用、长上下文和结构化输出能力可能因上游模型及协议转换而不同。涉及关键审查时仍应查看实际代码和测试证据，不要把模型名称当成质量保证。