Codex 和 WorkBuddy 怎么选，可以先问自己：这次要交付的是一个代码改动，还是一份文档、表格与报告？先选一个小任务试，比只对着功能清单比较更容易得出自己的答案。 本文按官方文档梳理入口与核对方法，没有做两款工具的同任务性能或费用实测。

想用 Codex 做一个用得上的小工具，可以从规则明确的数据检查开始。这次的任务是读取商品 CSV，把漏填、错误数值和重复编号列出来，生成浏览器能打开的报告。 先让人看清问题，再决定怎样处理原表。

拿到一份能运行的代码，却不知道从哪里改，先让 Codex 读一遍项目，给出带文件路径的说明，会比立即发一个大改造需求更容易核对。 重点是把“看懂项目”和“已经运行验证”分开。

AI 写的网页能打开，接下来怎么验收？拿一个保存在浏览器本地的待办页来说，可以沿着五个具体场景检查。 它们不用覆盖整个项目，却能抓住不少“第一次点起来没问题，刷新就坏了”的情况。

同一个待办网页，换个浏览器打开却是空的，先看它把数据存在哪里。本例只用了当前浏览器的本地存储，没有自动同步功能。 把数据带走，可以先做一条能核对的路线： 导出文件 → 预览内容 → 确认导入 。

一堆图片叫 IMG_1032.png 、 IMG_1051.png ，想整理成“活动照片_001、002……”，可以让 Codex 写一个小工具。第一步先生成改名清单，核对完再执行。 原演示用了8张程序生成的示例 PNG，目的是验证改名流程，不是真实照片整理记录。

待办清单刷新后还在，只说明浏览器里留住了数据。想在清理浏览器之前留一份副本，需要把它导出成真正的文件。 这个小需求很适合交给 Codex：范围清楚，结果也容易检查。

“保持样式”“别加后端”“改完跑测试”反复说了几次，就值得写进项目说明。 AGENTS.md 适合留下长期有效的约束，下一次接手项目时更容易找回这些要求。 文件不用长，先把项目范围、修改边界和检查方法写明白。

新增任务、刷新、确认它还在——手动点一次不难。每次改代码都重复点，容易漏掉一步。可以把这些动作写成浏览器测试，让它反复检查同一个结果。 这篇沿用待办清单项目，用 Playwright 把“改好了”变成可检查的行为。

待办清单能添加、能删除，一刷新却全没了，通常要先看数据是不是只放在页面的内存数组里。 这个教学项目把任务数组保存为文本，再在启动时读回来。重点有两个：每次修改都保存，读取失败也别把整个页面卡住。