Codex 改完功能后，怎么做验收才不容易漏问题？

Codex 能帮开发者快速改代码，但功能改完不等于可以上线。真正需要建立的是一套验收清单，让 AI 辅助产出的修改也能被人、测试和日志共同检查。

先把“完成”写成可检查结果

很多问题不是 Codex 不会改，而是任务描述只写了“优化页面”“修一下接口”“加个按钮”。这种描述没有明确验收条件，AI 改完后人也只能凭感觉看。开始前应把需求卡片写成三段：用户在什么场景下操作，系统应该出现什么结果，哪些旧行为不能被破坏。Codex 可以参与拆解需求，但最终验收句子要由负责人确认。

如果接手的是旧项目，可以先参考 旧仓库上下文整理步骤，把启动命令、测试方式和关键模块找出来。验收清单建立在这些信息之上，否则每次改动都会变成临时摸索。

第一步：列影响范围

让 Codex 在动手前输出“预计会影响哪些文件、接口、页面、数据表和配置”。改完后再让它对照实际 diff 复盘一次，看是否出现额外影响。如果新增了 AI 模型接口、AI API 接入配置或后台任务，还要确认模型名、环境变量、超时设置和日志字段是否进入部署清单。

影响范围不只看代码文件。前端按钮文案、移动端布局、数据库默认值、权限判断、缓存策略、失败提示都可能被牵连。小团队可以把范围分成必须测、建议测、暂不相关三类，避免因为清单过长而没人执行。

第二步：跑可重复验证

每次 Codex 改完功能，至少执行三类验证：自动化测试、构建或类型检查、手工路径检查。自动化测试看核心逻辑是否被破坏；构建检查能发现依赖、类型和打包问题；手工路径检查则覆盖真实用户的点击、输入、刷新和失败提示。

建议把命令写进验收记录，例如 npm test、pytest、go test、pnpm build 或项目自己的检查脚本。不要只写“测试通过”。如果某个测试暂时不能跑，也要写清原因和替代检查。开发者 AI 调用越频繁，越需要把可重复验证放在聊天记录之外，沉淀到仓库文档或任务系统里。

第三步：观察日志和失败路径

功能验收经常只看成功路径，但线上问题多数出在失败路径。要主动测试空输入、无权限、接口超时、余额不足、模型调用失败、网络中断和重复提交。涉及 AI 模型接口时，还要记录请求入口、模型名、状态码、耗时和错误摘要，方便后续模型调用管理。

如果页面和接口都正常，再看日志是否出现异常堆栈、重复请求或意外降级。站点层面的例行检查可参考 站长日常巡检清单，但功能验收要更贴近本次改动的业务路径。

上线前检查点

• 需求卡片写明场景、预期结果和不能破坏的旧行为。
• Codex 输出的影响范围与实际改动一致，额外改动已有解释。
• 测试命令、构建命令和手工路径都有记录。
• 失败路径至少覆盖无权限、空输入、接口超时和重复提交。
• 回滚方案明确到文件、配置、数据库变更和负责人。

常见避坑

不要把 Codex 的总结当成最终验收。总结能帮助理解，但它不能替代真实命令、真实页面和真实日志。也不要在没有回滚方案时连续合并多次 AI 辅助修改；一旦问题出现，很难判断是哪次改动引入。永沃云枢建议把每次 Codex 接入开发都看作“小变更、小验证、小复盘”。