Codex 说完成了，但结果还不能用：怎么补上验证闭环

“已经写入文件”、“构建通过”和“用户报告的问题已经解决”是三个不同结论。如果任务只停在第一个结论，就容易出现“Codex 说完成了，我打开页面却还是错的”。

四层验证

层级	要回答的问题	常见方式
改动审查	改了什么，是否混入无关变更	git diff --check、阅读 diff
静态检查	代码是否满足项目基本约束	lint、typecheck、格式检查
目标验证	原始失败是否真的恢复	失败测试、原请求、特定脚本
运行时验证	用户实际使用时是否正常	启动服务、页面操作、API 探测、部署后检查

不是每个任务都要跑全仓库所有检查。验证应该与风险成比例：改一段文案与改计费、身份验证或生产部署，所需证据不会相同。

在任务开始前写验收标准

模糊的验收：

改完后测试一下。

可执行的验收：

完成后：
1. 运行 npm test -- checkout；
2. 用失败请求中的相同输入重试；
3. 确认返回状态为 200，且 amount 与预期一致；
4. 检查 diff 中没有计费模块之外的改动；
5. 如果某一步无法执行，说明原因，不要将它写成已验证。

没有现成测试时怎么办

没有自动化测试不等于只能相信代码。可以选择离用户报告最近的证据：

• 页面问题：启动本地页面，按原步骤点击并截图。
• API 问题：用脱敏后的原请求重放，检查状态码和关键字段。
• 命令行问题：重跑原命令，同时保留退出码和标准错误。
• 文档链接：检查生成路由、链接状态与移动端排版。
• 部署问题：区分本地构建成功和公网运行正常，部署后再做一次外部探测。

如何记录“未验证”

一个可靠的交付总结应该把结果分开：

已完成：
- [实际改动]

已验证：
- [命令或操作] -> [结果]

未验证：
- [无法执行的检查] -> [原因]

剩余风险：
- [仍然需要人工或生产环境确认的事项]

完成检查

• 验收方式在实施前已经确定。
• 原始失败路径已经重试，不只是另外一条方便的路径。
• diff 与验证命令都有实际记录。
• 构建成功没有被当成所有运行时问题的证明。
• 未验证项和剩余风险已经说明。

站内延伸阅读：任务执行与验证闭环 和 从 CI 日志完成修复。