导入失败后，程序只留下一个错误代码。知道失败了，却不知道要检查哪条记录，也不知道能不能直接重试。 接着 预览过期检查 的自建 JSON 库存教学项目，这次给失败结果加一个 只读说明器 。它读取失败输出，保留原始代码，并对约定内的错误补充位置、原因和下一步；它本身不执行导入、不修改...

导入预览看起来没问题，准备提交时，原文件却被另一个操作改过了。之前确认的预览，还能直接执行吗？ 这次接着 整批校验后再写文件 的教学例子，把预览和提交拆成两次操作，中间多加一次输入对照。数据仍是自建 JSON，不是真实库存。

批量导入最难发现的问题，有时不是报错，而是报错前已经写进去一半。怎样让 Codex 把“原文件没被部分覆盖”也纳入验收？ 这里沿用 库存 0 校验的教学例子 ，用自建 JSON 文件演练：原文件一行，待导入两行。它不是实际库存或客户事故。

想用 Codex，第一关却卡在微软商店：页面一直转圈，下载按钮点不动。 可以换个入口试试： 不用打开商店窗口，直接用 Windows 的 winget 安装。 从点开 PowerShell 开始，下面一步步来；找不到 PowerShell，CMD 也能用。

库存填了0，程序却提示“漏填”，问题可能藏在一句 if not value 里。Python 中0和 None 都是假值，但它们在业务上的含义并不相同。 这个例子用自建 JSON 教学样本，故意在修前版保留错误判断，再用同一套验收检查修复。它不是客户事故，也不是真实库存表。

“API 报错了”后面，最有用的是刚才做了什么、服务实际返回什么，以及还缺哪些信息。把这些填进一张求助单，可以少走几轮猜测。 不知道的字段直接写“不知道”，比凭印象补齐更有价值。

Codex 请求返回429，先别急着判断余额不够。相同的 HTTP 状态可能对应请求太密，也可能指向余额或不同层级的限制。 先确认错误来自哪家服务，再看具体错误正文。下面只整理 OpenAI 官方 API 的排查方向。

Codex 显示“登录成功”，是否代表 API 已经能调用？还差一步验证。本地记录了认证状态、在线请求成功、任务通过验收，是三件不同的事。 原实验用一个故意无效的测试输入，检查 CLI 的本地登录提示，没有发起模型请求。

Codex 订阅和 API 哪个更划算，不能从一次额度百分比变化直接算出来。先确认两边的计费路径，再把自己的实际用量、完成结果和等待情况放在一起看。 这篇给出记录方法，不提供成本排名或金额预测。没有真实账单与同任务对照，就不该用虚构数字代替答案。

WorkBuddy、CodeBuddy，名字只差几个字，先别靠名字选。看这次需要交付什么，再决定先试哪个入口。 两者都来自腾讯，产品定位和使用形态有交集，也各有侧重。