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，把漏填、错误数值和重复编号列出来，生成浏览器能打开的报告。 先让人看清问题，再决定怎样处理原表。