Codex 代码改完后怎么测试？从 Git Diff 到回归验收的完整清单

苏雨千辞

311人浏览 · 2026-08-14 16:46:21

苏雨千辞 · 2026-08-14 16:46:21 发布

Codex 说代码已经修改完成，但项目启动后仍然报错，到底应该相信 AI，还是应该自己验收？

这个问题我问过自己很多次。

Codex 在聊天框里说“任务已完成”，你满怀期待地运行项目，迎接你的却是依赖未安装的报错、环境变量缺失的异常、或者一堆红色的测试失败。更麻烦的是，它可能“顺手”改了几个无关文件，项目行为完全偏离了预期。

AI 输出“任务完成”，不等于项目已经通过验收。这句话值得贴在屏幕上。

Codex 的本质是语言模型，它“认为”的完成，只是基于上下文生成了看起来合理的代码。它没办法真正执行代码，也没办法感知你的运行环境。“代码写完了”和“项目能跑了”之间，隔着一整套验收流程。

下面是我自己现在用的七步验收清单。每一步都不复杂，但少走一步，就可能多花半小时排查。

第一步：查看 Git Diff，确认 AI 到底改了哪些文件

Codex 说“我改好了”，这句话不能直接信。

第一步不是看它写了什么总结，而是看它实际动了哪些文件。直接运行：

bash

git status
git diff --stat

git diff --stat 会给你一个简明的文件改动列表——改了哪几个文件、增删了多少行。这个信息比 Codex 的任何文字总结都可靠。

看完统计之后，再看完整 diff：

bash

git diff

重点关注三件事：

有没有改到预期之外的文件——你只让它修一个按钮，它却改了路由配置和全局样式？
改动是否集中在目标模块——如果改动散落在五六个不相关的目录里，需要问清楚原因。
有没有删除或移动文件——这种操作影响面最大，必须单独确认。

Codex 的评审面板本质上就是 Git diff 面板，差异可能来自 Codex 生成的修改、开发者手动修改，以及其他未提交的变更。所以不要只看 Codex 的总结，自己看 diff。

第二步：检查依赖、环境变量和配置文件

这是项目跑不起来最常见的原因。

Codex 可能用了新库但没有更新 package.json 或 requirements.txt；可能添加了读取 os.getenv("API_KEY") 的逻辑但 .env 文件里根本没这一项；也可能生成的代码需要 Python 3.11 而你的环境是 3.8。

这一轮检查清单：

□
依赖文件有没有变化（package.json、requirements.txt、Pipfile、go.mod 等）
□
如果有新增依赖，是否已经执行了安装命令
□
环境变量文件（.env、.env.local）有没有新增未配置的变量
□
配置文件（如 config.toml、settings.py）有没有被改动
□
数据库连接、缓存服务等外部依赖是否就绪

如果项目有 AGENTS.md 文件，可以把技术栈、依赖管理方式和启动命令写进去，让 Codex 在修改时参考。但即使有，这一轮人工检查也不能省。

第三步：运行项目构建、代码检查和基础测试

确认文件和依赖都没问题之后，开始跑自动化检查。

按这个顺序来，成本从低到高：

bash

npm run lint          # 代码规范检查
npm run type-check    # TypeScript 类型检查（如果有）
npm run build         # 项目构建
npm run test          # 单元测试

Codex 可以帮你运行这些命令。你可以直接对它说：

“请运行 lint、类型检查和单元测试，把结果告诉我。如果有失败，先分析原因再修改。”

但要注意：Codex 可能写了测试文件却没有真正执行——测试处于“既存在又未验证”的状态。所以不要只看它说“测试通过”，要看命令的实际输出。

如果项目原本就有测试失败，建议在 Codex 修改之前先跑一遍基线测试，记录失败情况，否则很容易把旧问题算到这次修改头上。

第四步：测试被修改的核心功能

自动化测试通过之后，手动验证被修改的功能。

这一步没有标准命令，取决于你的项目类型：

Web 项目：打开浏览器，走一遍被修改的页面流程
API 服务：用 Postman 或 curl 调用被修改的接口
命令行工具：用实际参数运行一遍
脚本/函数：用真实数据调用一次

可以这样问 Codex：

“请给出这次修改涉及的核心功能的验证步骤，包括：如何启动、如何操作、预期结果是什么。”

然后你自己按步骤走一遍。不要只看 Codex 说“可以了”，要亲眼看到页面能打开、接口返回正确数据。

第五步：检查是否影响其他模块

改了一个功能，影响了另一个模块——这是最让人头疼的情况。

回归测试的核心价值，是把真实操作沉淀成可回放、可批量执行的验证。如果项目有完整的测试套件，这一步相对简单——跑一遍集成测试或 E2E 测试就能覆盖大部分风险。

如果没有完善的自动化测试，可以这样做：

列出被修改模块的上游调用方和下游依赖——谁调用了这个函数？这个函数调用了谁？
手动验证与被修改功能相邻的 2-3 个功能点——比如改了订单列表，顺手看一下订单详情和创建订单
让 Codex 做一次回归风险分析：

“请分析这次修改可能影响哪些其他模块或功能，列出潜在风险点和建议验证的场景。”

这一步不能完全交给 AI，但可以用 AI 来辅助发现盲区。

第六步：记录错误、让 Codex 根据日志继续修复

如果以上任何一步发现了问题——别急着手动改。

把完整的错误日志给 Codex，让它根据日志来修复。Codex 擅长“看报错→改代码→再验证”这个循环。

这样做：

复制完整的错误堆栈或测试失败输出
告诉 Codex：“这是运行 [命令] 后的报错，请分析原因并修复”
等它改完，重新从第三步或第四步开始验证

不要只给一句“还是不行”。给日志。日志越完整，Codex 定位问题越准。

如果连续两三轮修复都失败，停下来判断：是 Codex 理解不了项目上下文，还是任务本身太复杂需要拆分成更小的步骤？

第七步：形成一份项目验收清单

把上面的步骤沉淀成一份可复用的清单。每次 Codex 完成修改后，对照检查：

□
运行 git diff --stat，确认改动范围
□
检查依赖文件和环境变量是否有未同步的变化
□
运行 lint、类型检查、构建
□
运行单元测试和集成测试
□
手动验证核心功能
□
检查 2-3 个相邻功能点（回归）
□
如有报错，给 Codex 提供日志并迭代修复

这份清单可以写在项目的 AGENTS.md 里，让 Codex 在每次任务完成后自动对照执行。

一份可以直接复制使用的 Codex 代码验收指令

把下面这段直接发给 Codex：

text

请对本次修改进行完整验收，按以下顺序执行：

1. 运行 git diff --stat，列出所有修改的文件和改动量
2. 检查依赖文件（package.json / requirements.txt 等）是否有变化，如有变化说明新增了什么
3. 运行项目的 lint 检查
4. 运行项目的类型检查（如有）
5. 运行项目的构建命令
6. 运行项目的测试套件，给出通过/失败摘要
7. 列出本次修改涉及的核心功能，并给出人工验证步骤
8. 分析本次修改可能影响的其他模块，列出回归风险点

每一步请给出实际命令的输出结果，不要只总结“已通过”。

这个指令的核心是要求 Codex 输出证据，而不是结论。

什么时候是代码问题，什么时候是任务拆分、上下文管理或使用量问题？

不是所有问题都出在“代码写得不对”上。

代码问题：逻辑错误、语法错误、边界条件遗漏——这些可以通过上面的验收流程发现，让 Codex 根据日志修复。

任务拆分问题：你让 Codex 一次性完成“重构整个用户模块”，它可能在上下文窗口里塞进太多文件，导致顾此失彼。这种情况应该把大任务拆成 3-5 个小任务，逐个完成、逐个验收。

上下文管理问题：Codex 记不住项目早期的约定，或者忘了你两轮对话前说的约束。解决办法是把关键约束写进 AGENTS.md 或每次任务开始时重申。

使用量问题：如果项目规模较小、只是修改单个函数，基础套餐通常可以完成。但如果需要反复读取完整代码仓库、持续修改多个文件、运行测试并多轮修复，任务对额度的消耗会明显增加。这种情况下，应该先记录自己的实际使用频率和任务复杂度，再判断是否需要更高等级的方案。不要把 Plus 或 Pro 当成万能解决方案——适合别人的不一定适合你。