Codex 跑测试失败时，不要马上让它“全部修好”。更稳的顺序是：复现失败、读第一条关键报错、判断是环境问题还是代码问题、只修相关范围、最后重新跑同一组测试。这样能避免它为了让测试过而改掉真正的业务逻辑。
先区分三类失败
- 环境失败：依赖没装、Node/Python 版本不对、缺少环境变量、服务没启动。
- 测试数据失败：本地没有数据库、fixture 过期、时间或地区导致快照变化。
- 代码失败：这次改动真的破坏了逻辑、类型、样式或接口返回。
你可以直接对 Codex 说：“先不要改代码，解释测试失败原因，并指出最可能相关的文件。”这一步很关键。很多 CI 红灯并不是业务 bug，盲修会制造新问题。
让 Codex 修测试的正确提示
可以这样写：“请复现这个测试失败，保留完整错误上下文。只修改和失败用例相关的实现或测试，不要批量更新快照。修完重新运行同一条测试命令，并说明为什么这样改。”
什么时候可以改测试
如果产品需求变了，测试期望也应该变，这时可以让 Codex 更新测试。但如果只是实现错了，就不要让它通过改测试来掩盖问题。一个判断办法是：先让 Codex 说清旧测试在保护什么，再决定要改实现还是改断言。
CI 失败更要小步处理
CI 里失败的命令，尽量让 Codex 在本地或同等环境复现。复现不了时，让它对比本地和 CI 的 Node 版本、系统依赖、环境变量、缓存和路径差异。不要让它凭感觉连续改很多文件。
测试失败不是坏事，它其实给 Codex 提供了明确反馈。你要做的是把任务从“修好所有东西”缩小成“解释这一条失败并做最小修复”。范围越窄，成功率越高，代码也更容易 review。
