Codex 汇报完成以后，验收才刚开始。你需要确认它改了哪些文件，内容是否满足原要求，检查命令有没有通过，最终成果处于本地、已提交还是已部署状态。
本文内容核对到 2026 年 8 月。审查面板的按钮和范围名称可能调整，Git 差异、命令结果与实际页面仍是判断依据。
先对照允许修改的范围
打开审查面板或运行 Git 状态检查，逐个看文件名。审查面板反映整个仓库的状态，里面会包含你原先留下的修改。不要把所有差异都归到最近一轮 Codex 操作上。
任务只允许修改一份文档，结果却出现配置、依赖锁文件或删除记录，应先暂停。让 Codex 说明每个额外文件为何变化，并把与目标无关的内容分开处理。没有确认来源前，不要整批暂存或撤回。
再读文件里的具体变化
文件范围正确以后，逐段看差异。文字任务要核对事实、链接和语气。代码任务要看输入输出、错误分支与相邻调用是否仍然成立。配置任务还应检查开发、测试和生产环境有没有被混用。
审查面板支持在具体行留下意见。指出文件、行和期望结果，会比“这里不对”更容易得到准确修正。/review 也能对未提交改动或基准分支差异做只读检查，并给出经过优先排序的问题。
验证证据要能重复
让 Codex 列出实际运行过的命令和结果。测试显示通过时，还要看它运行的是哪一组测试。只跑一个无关脚本，不能证明目标功能可用。构建成功只说明构建流程通过，界面任务仍需打开页面检查。
有复现步骤的错误修复，应在修改后重新走一遍原步骤。页面改动至少检查目标路由和相关屏幕宽度。没有自动测试的内容，可以用明确的人工清单验收，并记录哪些地方仍未检查。
留意自动生成和批量格式化
依赖锁文件、构建产物和格式化结果可能制造很大的差异。先确认它们是否由本次任务需要的命令产生，再判断要不要保留。业务修改埋在几百行格式变化里时，让 Codex 将无关格式调整移出本次提交，审查会轻松很多。
未跟踪文件也要看。新测试、迁移文件和图片可能还没进入普通差异范围，却会随提交一起影响交付。要求 Codex 列出新增、删除和重命名文件，并说明每一项与目标的关系。
把交付阶段写清楚
本地文件已经变化，不代表提交已经创建。提交存在，也不说明分支已经推送。合并、部署和线上验证各有独立证据。询问 Codex 当前分支、提交编号、测试结果和远端状态，发布任务还要亲自访问真实地址。
代码审查发现的问题也需要二次判断。先看它指出的文件和触发条件，能复现就补测试。证据不足时要求缩小检查范围，别让一条宽泛建议带出新的大改动。
不确定时要求它给证据
可以让 Codex 指出结论对应的文件行、命令输出或官方来源。证据和结论对不上时，先缩小问题，再决定修改。验收的结束点很朴素，你能复述改了什么，也能自己重复关键检查，并且知道成果现在停在哪个阶段。