codex“测试通过”不等于功能可用，需验证命令是否真实执行（codex status）、检查stdout结尾信号、确认exit code为0、手动复现测试命令，并通过浏览器network/console及git status四步交叉验证真实环境表现。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
当你在终端输入 codex test 或让 Codex 运行测试后，它返回“测试通过”或“任务完成”，但项目一启动就报错、页面白屏、接口 500，说明你还没真正确认测试是否真的执行成功——Codex 可能只跑了部分用例、跳过了失败项、甚至根本没触发本地测试命令。
先确认 Codex 是否真的调用了测试命令
打开终端，执行：
codex status
查看最近一条记录的「Command」字段。如果显示的是 test、jest、pytest 或 npm test，说明它确实发出了测试指令；如果显示的是 ls、cat、pwd 或 update_plan，那它压根没跑测试，只是在侦察环境。
【注意：codex test 不等于 npm test】 Codex 默认会先做一层模型分析：读取测试文件→解析报错→生成修复建议→再决定是否重试。这中间可能卡在分析阶段，根本没把命令交给 shell。
看懂测试输出里的关键信号
方法一：检查 stdout 中是否出现「PASS」「✓」「1 passed」等字样
直接找终端输出里最靠下的几行，不是第一行，也不是中间某段日志。真正的执行结果一定出现在最后 3 行内。如果结尾是「command execution fails」或「Bash tool returns error」，测试根本没跑起来。
方法二：验证 exit code 是否为 0
在 codex test 执行完后，立刻输入：
echo $?
返回 0 表示命令本身执行成功（不管测试用例是否通过）；返回 1 表示命令执行失败（比如 jest 命令不存在、配置文件缺失、权限不足）。只有 exit code 为 0，才值得继续看测试用例结果。
通过本地 Codex 或 OpenClaw OAuth 凭证直接调用 ChatGPT/Codex Responses 的 image_generation 工具来生成或编辑光栅图像，然后保存
方法三：核对实际运行的测试文件数量
在 codex test 输出中搜索「Running」或「Found」开头的行。例如：
Running 7 tests from 3 test files
如果显示「0 tests found」或「No tests matched」，说明它根本没识别到你的测试目录结构，可能是 __tests__ 路径没被扫描，也可能是 tsconfig.json 里 exclude 了测试文件。
验证测试是否覆盖真实路径
第一步：找出 Codex 实际执行的命令完整路径
执行 codex test 后，立刻运行：
ps aux | grep -E "(jest|pytest|npm test)" | grep -v grep
第二步：复制该命令，在终端里手动粘贴运行一次
这一步必须做。Codex 的沙盒环境和你当前 shell 的 PATH、NODE_ENV、.env 配置可能不一致。手动运行能暴露真实环境问题，比如 missing module、ESM 导入错误、mock 文件未加载。
第三步：对比两次输出的差异点
重点关注：
- 第一次（Codex 跑）是否跳过了某些 test 文件？
- 第二次（手动跑）是否多出「ReferenceError: jest is not defined」？
- 两次失败用例是否完全相同？如果不同，说明 Codex 没用你当前分支的代码，而是缓存了旧版本上下文。
【关键前提：手动运行命令时 pwd 必须和 Codex 启动时完全一致】 否则你会误判为 Codex 报错，其实是路径错了。
检查测试通过是否等于功能可用
① 打开浏览器，访问你修改的功能页面，输入一组正常数据，点击触发操作
② 打开开发者工具 → Network 标签页，确认请求 URL、method、payload、status code 全部符合预期
③ 切换到 Console，检查是否有 Uncaught TypeError、Cannot read property 'xxx' of undefined 等运行时错误
④ 回到终端，执行 git status，确认 Codex 没有意外删掉 import 语句、改错函数名、或把 async/await 去掉导致 Promise 未处理
这四步做完，你看到的才是真实可用的结果。Codex 的“测试通过”只代表它跑完了那些用例，不代表你写的代码能在真实环境中执行。
