Codex 帮我定位一次测试失败：先看报错，再列排查清单

゛刘二柳

587人浏览 · 2026-08-20 15:57:00

゛刘二柳 · 2026-08-20 15:57:00 发布

Codex 帮我定位一次测试失败：先看报错，再列排查清单

不会安装 Codex CLI？先看上一篇 Windows 一键安装教程：windows一键安装

测试失败后，我不准备马上让 Codex 改代码。报错、输入和业务规则还没对应清楚时，直接修改很容易把问题“改没”，却说不清为什么这样改。

这次用一个故意失败的 Node.js 项目演示：先保存失败现场，再把 "1.5" 沿代码路径推一遍，第一轮只让 Codex 做只读分析。当前失败基线已经真实运行，Codex 的分析和修复仍待验证，正文不会用模拟回答冒充结果。

1. 示例项目与当前实现

项目名是 codex-test-failure-triage-demo：

codes/codex-test-failure-triage-demo/
├── README.md
├── package.json
├── src/limit.js
└── test/limit.test.js

当前函数：

export function normalizeLimit(value) {
  const limit = Number(value);

  if (!Number.isFinite(limit) || limit <= 0) {
    return null;
  }

  return limit;
}

测试分别覆盖正整数和小数：

assert.equal(normalizeLimit("2"), 2);
assert.equal(normalizeLimit("1.5"), null);

在这里插入图片描述

图 1：当前实现没有整数判断，测试明确要求拒绝 1.5。

2. 先保存失败现场

Set-Location .\codes\codex-test-failure-triage-demo
npm test
$LASTEXITCODE

真实结果：

测试总数：2
通过：1
失败：1
失败测试：rejects a decimal value
实际值：1.5
期望值：null
退出码：1

在这里插入图片描述

图 2：正常用例仍然通过，问题集中在小数边界。

只写“测试失败”不够。至少要记录测试名称、输入、期望值、实际值和退出码，后续修复才能回到同一个现场核对。

3. 只读分析前确认文件状态

git status --short -- .

在这里插入图片描述

图 3：命令无输出，说明示例目录当前没有未提交文件变化。

Codex 只读分析结束后要再运行一次。如果出现新文件或 diff，应先查清写入来源，不能把这次运行记录成“只读完成”。

4. 把 1.5 沿代码路径推一遍

失败输入是字符串 "1.5"：

Number("1.5") 得到数字 1.5。
Number.isFinite(1.5) 为 true。
1.5 <= 0 为 false。
两个拒绝条件都没有命中。
函数最终返回 1.5。

我用一条不写文件的 Node.js 命令打印了每个判断：

在这里插入图片描述

图 4：Number.isInteger(1.5) 为 false，当前实现却没有这项检查。

这条链路已经能解释测试中的实际值，不需要先怀疑测试框架或运行环境。

5. 第一轮只给 Codex 分析权限

请只读分析当前项目中的测试失败，不要修改任何文件。

请读取 README.md、package.json、src/limit.js 和 test/limit.test.js。
1. 写出失败测试名称、输入、期望值和实际值。
2. 逐步说明实际值沿哪条代码路径产生。
3. 区分文件中能确认的事实和仍需确认的业务规则。
4. 指出最小修复位置，但不要修改文件。
5. 列出修复后建议补充的边界测试。

使用本机帮助中已确认的参数时，可按下面的形式执行：

$prompt = @'
请读取 README.md、package.json、src/limit.js 和 test/limit.test.js。
只读分析失败原因、代码路径、最小修复位置和建议边界测试。
不要修改文件，不要猜测文件中没有写明的规则。
'@

codex exec `
  --sandbox read-only `
  --skip-git-repo-check `
  --ephemeral `
  $prompt

参数是否可用应以本机 codex exec --help 为准。本篇尚未实际运行这条 Codex 命令，所以不展示虚构回答。

6. 什么样的分析才有用

一份可采用的结果至少包含：

现象：rejects a decimal value 失败，实际 1.5，期望 null
路径："1.5" -> Number -> 1.5 -> 拒绝条件未命中 -> 返回 1.5
规则：项目材料和测试要求 limit 为正整数
位置：src/limit.js 缺少整数检查

“可能是类型转换问题”太宽泛。直接建议 parseInt 也有风险，因为 parseInt("1.5") 会得到 1，可能把错误输入悄悄变成合法值。

7. 改实现还是改测试

如果 README、接口文档或已确认需求要求正整数，而且测试表达同一规则，应修改实现。当前示例属于这一类。

如果文档明确允许正小数，而测试却要求返回 null，就应先检查测试。若项目里找不到规则，则应该标记“规则待确认”，不能让模型替项目决定业务契约。

8. 修复阶段与验收

规则确认后，第二个任务可以写成：

已确认 normalizeLimit 只接受正整数。
请只修改 src/limit.js，使小数返回 null。
不要修改测试、README 或 package.json，不增加依赖。
完成后运行 npm test，并列出修改文件和退出码。

修复后检查：

git diff --name-only -- .
git diff -- .\src\limit.js
git diff --check -- .
npm test
$LASTEXITCODE

预期只修改 src/limit.js，2 项测试全部通过，退出码为 0。这些现在仍是验收目标，不是已经发生的结果。

后续还可以根据真实规则考虑 "0"、"-1"、"abc"、"Infinity"、空字符串和非常大的整数，不能为了测试数量擅自增加未确认限制。

9. 最终排查清单

[ ] 已记录失败测试、输入、期望值、实际值和退出码
[ ] 已确认正常用例仍然通过
[ ] 已把失败输入逐步对应到源码判断
[ ] 已从文档、测试或需求确认业务规则
[ ] 只读分析前后没有文件变化
[ ] 修复只触及允许文件，没有新增依赖
[ ] 已查看具体 diff，并运行 git diff --check
[ ] 已重跑完整测试并记录退出码