WorkBuddy 和 Codex 怎么选？看你要它交什么活
WorkBuddy 和 Codex 各适合什么任务？从办公文件、代码项目、任务描述、协作交接和实际成本，讲清怎样选、怎样用。
如果你主要处理文档、表格、PPT，我会先推荐 WorkBuddy。如果你每天都在项目目录里改代码、查报错、跑测试，我会优先推荐 Codex。
两者都会写代码、处理文件。真要选，得看你的工作从哪里开始，最后要交出什么。只问“哪个更聪明”，很难选明白。
一个从办公任务进，一个更方便接开发流程
WorkBuddy 是腾讯的全场景 AI 工作台。官方提供文档、表格、PPT、资料整理等能力，也能读项目、写代码，通过技能和连接器扩展。拿一批材料进去，说清楚要什么结果，这是比较自然的用法。
Codex 提供终端、IDE 和云端等入口。本地开发时，它能读取项目、修改文件、执行命令，用机器上已有的工具检查结果。原来的构建、测试、Git 流程可以接着用。
我会按下面这个顺序选。这是分工建议，不是两者的能力边界。
| 手头的活 | 优先用谁 | 重点看什么 |
|---|---|---|
| 查竞品、整理资料、做报告 | WorkBuddy | 来源齐不齐，结论有没有依据 |
| 合并表格、做 PPT | WorkBuddy | 字段有没有丢，文件能不能直接用 |
| 接着现有项目加功能 | Codex | 有没有沿用现有结构，改动是否合理 |
| 修 Bug、补测试、审查代码 | Codex | 原因找没找对，修完能不能验证 |
| 做新网站或小工具 | 两者都可以试 | 哪个更容易接上后续维护方式 |
还有一个容易混的地方：工具名不等于模型名。模型、推理强度、权限和连接服务不同，同一个工具的表现也会不同。任务失败，先看它缺了什么：资料没拿到、命令不能执行，还是需求没说清。别马上给整个产品下结论。
用 WorkBuddy，说清楚你要拿走什么
“帮我分析竞品”太宽。它可能写很多，但你还是得自己整理。
换成这样就具体多了：
根据这三个产品官网，做一张对比表，包含价格、主要功能和适用人群，每项附来源。找不到的信息标“未确认”，最后给三个选择建议。交付可编辑表格和一页总结。
材料、范围、格式都有了，也知道什么时候算做完。处理文件时，同样把规则说清楚：按哪个字段去重，金额是什么单位，缺失项怎么处理。别让它猜完，你再逐条纠正。
大任务可以拆两步。先整理事实和表格，你确认方向后，再做报告或 PPT。事实还没核对就开始排版，内容一变，前面做的页面又得返工。
经常做的报告，把模板和规则放进项目资料或技能。下次只换材料，不用重新解释整套要求。真正能省下来的，往往就是这些重复沟通。
用 Codex，把它放进项目，给它能检查的目标
“优化一下网站”很容易变成一堆改动，最后却说不清哪里更好了。
如果问题是手机端表格溢出，就直接交代：
修复手机端文章表格溢出。保留横向滚动，检查中英文页面。改完说明原因、改了哪些文件、怎么确认修好了。
后端报错也是一样：给出触发方式、关键日志和预期行为。任务涉及多个模块时，先让它定位原因、说清准备改哪里，再动手，省得一边猜一边扩大改动。
项目长期规则放进 AGENTS.md，例如用什么构建命令、哪些目录不能改、部署怎么做。只写会影响工作的规则，别塞一份大而全的公司手册。
模型也不用每次都选最贵、推理最重的。改文案、调样式、批量替换，可以先用响应更快的配置。跨模块改造、难复现的 Bug、复杂代码审查，再提高推理强度。具体档位要看当前可用模型，没有一个配置适合所有任务。
验收很直接：看改动，重跑原来失败的场景，确认结果。它说“完成了”可以作为通知，代码和运行结果才是依据。
两个一起用，别重复劳动
拿博客举例，可以让 WorkBuddy 整理选题、来源和提纲；涉及页面、多语言结构、API 和部署的工作，交给 Codex。需要报告或渠道文案，再按产物需求分配。
交接给对方的是文件和决定：用了哪些资料，确定了什么，还要做什么，哪些地方待确认。别把一长串聊天记录扔过去，让另一个工具重新猜。
同一份代码也别让两个 Agent 同时改。一个负责实现，另一个做只读审查；确实要并行开发，就分开分支或工作目录。否则一边刚修好，另一边又覆盖，最后得你收拾。
成本别只比月费，也别只看一次回答多快。拿三五个常做的任务试试，记录完成时间、用量，以及你还花了多久修改。输出很漂亮，最后还要自己重做，就不算省事。
只想先用一个，就选最贴近日常工作的那个。等真遇到缺口，再加另一个。两个工具各自做完一件事，比来回切换、两边重复问，更有效。
分工建议基于官方功能定位，不是两款产品的横向实测排名。