Codex 修改代码后如何验收：测试、构建与差异检查

Codex 完成代码修改，只表示文件发生了变化，不表示功能已经正确。可靠的交付必须回答三个问题：改了什么、如何证明有效、还有哪些未验证风险。测试和构建是证据的一部分，不能由口头总结替代。

## 修改前先定义验收标准

验收标准应在写代码前确定，例如接口返回什么、异常如何处理、旧行为是否兼容、哪些测试必须通过。没有验收标准，代理可能实现一个“看起来合理”但不符合业务的方案。

对于修复问题，最好先描述可复现步骤和期望结果；对于新功能，至少明确输入、输出、权限、数据变化和失败场景。

## 分层执行验证

1. 语法和静态检查：确认代码能被解析，格式与类型符合要求。 2. 相关单元测试：优先运行修改模块的快速测试。 3. 集成测试：验证数据库、网络或跨模块行为。 4. 完整构建：确认打包流程和生产依赖没有遗漏。 5. 手工检查：在真实页面或接口上走关键路径。

不要一开始只跑最慢的全量测试。先用快速反馈定位明显问题，再执行完整验证，更容易判断失败来源。

## 检查实际差异

测试通过也要查看 diff。重点检查是否修改了无关文件、删除了已有逻辑、提交了密钥、改变了配置默认值，或把生成产物混入源码。对依赖锁文件和数据库迁移要单独审查，因为它们可能影响整个环境。

## 让失败保持可见

如果某个测试因环境缺失无法运行，应明确记录命令、错误和缺少的条件，不要写成“全部通过”。如果只能做局部验证，也要说明未覆盖的路径和建议的后续检查。

## 前后端联合验收

- 后端接口状态码、字段和权限是否符合约定。 - 前端加载、空状态、错误提示和刷新行为是否正常。 - 数据库结构是否需要迁移，旧数据是否兼容。 - 构建产物是否来自当前源码和正确环境变量。 - 部署后健康检查与回滚命令是否准备好。

## 推荐交付格式

交付时列出修改摘要、文件范围、执行过的命令、测试结果和剩余风险。对于未验证事项使用明确表述，不要用模糊的“应该可以”。只有证据完整、差异合理且回滚可行，代码才适合进入下一阶段。