导入预览看起来没问题，准备提交时，原文件却被另一个操作改过了。之前确认的预览，还能直接执行吗？

这次接着整批校验后再写文件的教学例子，把预览和提交拆成两次操作，中间多加一次输入对照。数据仍是自建 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，名字只差几个字，先别靠名字选。看这次需要交付什么，再决定先试哪个入口。

两者都来自腾讯，产品定位和使用形态有交集，也各有侧重。

用 Codex 一定要先买 ChatGPT 订阅吗？先看自己准备使用的入口与认证方式，再决定需要什么。

对于使用 OpenAI 模型的本地 Codex 工作流，官方文档列出了 ChatGPT 登录与 OpenAI API Key 登录两条路径。它们的计费与功能范围需要分开核对。

按月份、项目汇总工时，最容易出问题的往往不是相加，而是把“待确认”、错误日期或缺项目的行也混了进去。

这个小工具先分出有效行与异常行，再做汇总。异常保留行号和原因，方便回到原表处理。

一个文件改坏了，其他文件里还有自己没提交的工作，怎样只撤回目标文件？先检查 Git 基线和修改范围，再决定是否做整文件恢复。

下面的命令会覆盖目标文件的工作区内容。只在确认该文件里的未提交改动都准备放弃、而 HEAD 确实是正确版本时使用。

把“报错了，帮我修一下”换成四样具体信息，通常能少来回追问几轮：执行了什么、实际报了什么、原本想得到什么、哪些东西必须保留。

下面用商品表检查工具的一次目录冲突演示。这个问题最后没有修改程序，换一个输出目录就解决了。

Codex 和 WorkBuddy 怎么选，可以先问自己：这次要交付的是一个代码改动，还是一份文档、表格与报告？先选一个小任务试，比只对着功能清单比较更容易得出自己的答案。

本文按官方文档梳理入口与核对方法，没有做两款工具的同任务性能或费用实测。

想用 Codex 做一个用得上的小工具，可以从规则明确的数据检查开始。这次的任务是读取商品 CSV，把漏填、错误数值和重复编号列出来，生成浏览器能打开的报告。

先让人看清问题，再决定怎样处理原表。

拿到一份能运行的代码，却不知道从哪里改，先让 Codex 读一遍项目，给出带文件路径的说明，会比立即发一个大改造需求更容易核对。

重点是把“看懂项目”和“已经运行验证”分开。

AI 写的网页能打开，接下来怎么验收？拿一个保存在浏览器本地的待办页来说，可以沿着五个具体场景检查。

它们不用覆盖整个项目，却能抓住不少“第一次点起来没问题，刷新就坏了”的情况。

同一个待办网页，换个浏览器打开却是空的，先看它把数据存在哪里。本例只用了当前浏览器的本地存储，没有自动同步功能。

把数据带走，可以先做一条能核对的路线：导出文件 → 预览内容 → 确认导入。