库存填了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 确实是正确版本时使用。

把“报错了，帮我修一下”换成四样具体信息，通常能少来回追问几轮：执行了什么、实际报了什么、原本想得到什么、哪些东西必须保留。 下面用商品表检查工具的一次目录冲突演示。这个问题最后没有修改程序，换一个输出目录就解决了。