Codex 改完代码后怎么确认没误改？

Codex 能很快改完一组文件，但真正让团队紧张的是“它有没有顺手改到不该动的地方”。变更审计不是重复看一遍 diff，而是把文件、命令、风险和验收结果重新串起来。

适用场景：改动能跑通，但担心范围失控

这篇适合 Codex 修改前端组件、后端接口、脚本任务、AI 自动化办公流程或模型调用管理配置之后使用。典型表现是功能看起来正常，但 diff 里出现了额外格式化、依赖版本、测试快照、环境配置或文案改动。大仓库边界可以先看 大项目里怎么让 Codex 只改该改的文件，命令风险可结合 让 Codex 执行命令前怎么确认风险。

先把变更分成三类

第一类是目标变更，直接解决本次问题。第二类是支撑变更，例如补测试、改类型、更新文档。第三类是可疑变更，例如无关格式化、配置漂移、锁文件变化和生成物覆盖。审计时不要只问“代码能不能跑”，要问每一类变更有没有理由、有没有验证、有没有回滚办法。

操作步骤：从文件清单审到验收证据

1. 导出文件清单和修改理由

让 Codex 按文件列出“为什么改、属于目标还是支撑、怎么验证”。如果某个文件说不清理由，就先标成可疑，不要急着上线。没有 Git 的目录也可以用修改时间和备份对照；有 Git 时再结合 git diff --stat、git diff --name-only 看范围。

2. 回放关键命令

把 Codex 跑过的测试、构建、格式化、同步命令列出来，确认哪些是只读检查，哪些会写文件。涉及 AI API 接入、CCSwitch 配置或远程服务时，要特别标明命令在哪个环境执行，避免把测试 profile 的结果当成正式环境证据。

3. 对 diff 做意图分组

不要从第一行看到最后一行。先按模块分组，再按意图分组：业务逻辑、错误处理、配置、测试、文案、生成物。Codex 改完要交给同事 Review 时，可以延续 Codex 改完代码后怎么交给同事 Review 的交接格式，但在前面加一段“可疑变更清单”。

4. 设置人工复核点

风险较高的变更不要让 Codex 自己判定通过。比如权限判断、金额计算、批量写入、搜索引擎推送、模型调用计费、客户资料处理，都要有人工复核点。静态页面发布还要查 UTF-8、canonical、sitemap 和线上乱码，可参考 Codex 生成静态 SEO 页面后中文乱码怎么办。

常见问题/避坑：最危险的是“顺手优化”

第一个坑是把自动格式化当成无风险。格式化本身可能改动几百行，让真正的逻辑差异被淹没。第二个坑是只看测试通过，不看测试覆盖了什么。第三个坑是把 Codex 的解释当证据，实际上证据应该来自命令输出、页面响应、日志和人工抽样。

第四个坑是没有记录失败表现。Codex 可能先尝试过一条命令失败，后来换了路径跑通。如果失败命令涉及依赖安装、数据库迁移或远程同步，就应该写进审计记录。否则下次同事复现时，会以为所有步骤都很顺。

如果改动涉及开发者 AI 调用，还要审计请求样本、模型名、Key 来源、日志字段和成本影响。AI API 错误码可以参考 AI API 返回 401、429、500 怎么分工排查。不要让 Codex 把报错吞掉，也不要把本地 mock 的成功当成上游接口成功。

我通常会要求最终说明里出现三个句子：哪些文件是本次目标变更，哪些文件只是支撑变更，哪些文件需要人工再看。这样 Review 人不用从大段 diff 里猜意图，也方便后续回滚时只退掉真正相关的部分。

如果审计时发现 Codex 同时改了配置、文案和测试，不要急着全部保留。先把本次真实问题对应的最小变更留下，再判断其它改动是否能独立解释。不能解释的内容可以放到下一次任务，而不是混在当前上线包里。

检查清单：提交前逐项确认

• 是否列出所有被修改、创建、删除的文件。
• 每个文件是否能说清修改理由和所属意图。
• 是否回放过测试、构建、页面检查或接口检查命令。
• 是否标出无关格式化、锁文件、配置和生成物变化。
• 涉及 AI 模型接口、CCSwitch 或生产数据时，是否说明环境和权限来源。
• 是否写出人工复核点、剩余风险和回滚方法。

验收标准：审计记录能让别人接手

合格的 Codex 变更审计，不是证明 AI 一定没有错，而是让风险可见、证据可查、后续可回滚。永沃云枢建议把这套审计清单和 Codex 安装专题 一起维护，后续在 https://ai.jn83.com 做 Codex 接入、AI API 接入或 AI 自动化办公时，能把每次改动沉淀成可复用经验。