最近体验了一下 WorkBuddy。
刚打开的时候，我第一感觉就是界面和 Codex 挺像。不过这次我没有专门找 Demo 测试，而是直接拿了一个工作里正在做的真实需求来试。
这个需求原本是先交给 Codex 完成的。
先让 Codex 根据原型完成业务代码
需求本身不算特别简单。
我手里有墨刀原型，但其中一些业务逻辑我自己也不能完全确定，需要参考老系统。麻烦的是老系统代码还需要反编译，而且原来的功能只能单个操作。
现在的新需求是在沿用原有业务逻辑的基础上改成批量操作，最后还涉及新老两边的数据同步。
所以我先把原型交给 Codex，让它结合现有项目完成整个业务代码。
Codex 写完以后，这次我没有马上自己验证，而是把同一份墨刀原型直接交给 WorkBuddy，让它重新检查 Codex 写出来的代码。
我这次在 WorkBuddy 里使用的是 DeepSeek-V4.1-Flash。
它确实检查出了 Codex 实现里的问题
这次让我印象比较深的是导入数据时的匹配逻辑。
Codex 原来的实现需要进行很多次匹配。WorkBuddy 检查以后，提出可以先对数据进行分组、去重，再进行后续匹配。
我重新看了一下这个逻辑，这个优化确实成立。
原来需要重复匹配的数据，在提前分组处理以后，可以明显减少后续的匹配次数。
另外，它还检查出了代码里存在循环执行数据库操作的问题。
这一点也是我最近使用 Codex 时比较在意的地方：AI 把功能写出来通常很快，但功能能正常运行，并不代表实现方式就一定没有问题。
这次用另一个 AI 再做一遍 Code Review，至少确实找到了几个值得修改的地方。
WorkBuddy 的总结方式我比较喜欢
除了检查代码以外，WorkBuddy 还有一点让我感觉比较舒服。
它会根据原型和代码整理整个业务流程，并用图把流程展示出来，包括前端操作以后接口调用的大致先后顺序。
对于这种自己本来就不算特别熟悉的业务，这种方式比单纯给我输出一大段文字更直观。
这一点目前我觉得比 Codex 做得更人性化一些。
但它有时候也真的太啰嗦
当然，也不是所有体验我都喜欢。
我目前比较不习惯的一点就是：输出有时候太多了。
有些问题我只是想快速确认“这样做行不行”，或者得到一个比较明确的结论，并不需要特别长的解释。
WorkBuddy 有时候会把回答展开得比较多，对我来说反而增加了阅读成本。
如果是复杂业务总结，我觉得详细一点没问题；但简单问题我还是更喜欢直接给结论。
速度比我平时用的 GPT-5.6 快
这次使用 DeepSeek-V4.1-Flash，主观感受速度比我平时在 Codex 里使用的 GPT-5.6 更快。
至于和 GPT-6 Astra 相比谁更快，我没有做同任务测试，所以这里不做判断。之前我用 Astra 时感觉额度消耗比较快，现在日常开发还是以 GPT-5.6 为主。
WorkBuddy 的上下文目前我也没有充分测试。
它可以选择 300K 或 1M 上下文，我这次使用的是默认 300K，而且这个任务规模还没有大到足以测试上下文极限，所以暂时还不能判断它和 Codex 在长上下文处理上谁更好。
我目前更愿意把它当成第二个检查者
体验下来，我暂时不会因为 WorkBuddy 就不用 Codex。
但这次让我觉得比较有价值的一种用法是：
让一个 AI 完成功能，再让另一个 AI 从不同角度检查一遍。
尤其是现在 AI 生成代码越来越快，我自己不可能把每一段代码都重新从头研究一遍。用第二个工具帮忙检查性能问题、数据库操作和业务流程，再由我判断这些建议到底成不成立，对我来说还是有实际价值的。
如果你也想体验一下 WorkBuddy，可以通过下面的链接注册。目前还有注册获取 2000 积分的活动，可以直接拿来体验。