最近一周我把日常写代码的主力工具从 Codex 换成了 WorkBuddy。说实话一开始只是想着试试看没想到这一周下来两个工具在“跟代码上下文交互”的方式上差别还挺大。如果你正好也在 Codex 和 WorkBuddy 之间犹豫这篇文章应该能帮你少踩几个坑。先交代一下背景我平时主要做 Python 和 TypeScript 的项目之前的日常是开着 Codex CLI 帮自己写脚本、做重构、补测试。Codex 的优势我很清楚但它有几个让我越来越难受的点比如会话上下文短、自定义指令不够灵活以及想接国内模型时配置非常绕。所以当朋友推荐 WorkBuddy 时我抱着“不行就换回去”的心态装了一个结果一发不可收拾。下面就是我这一个星期的真实使用记录包括安装配置、切换模型、自定义指令、配合文档工具的经验以及踩过的一些坑。1. 先说结论这一周下来我最真实的感受1.1 Codex 和 WorkBuddy 到底是什么Codex 是 OpenAI 推出的命令行编程代理你可以在终端里用自然语言让它读代码、改代码、跑命令。它更像是“长在终端里的 AI 结对编程伙伴”优点是对 GitHub 仓库的理解比较直接缺点则是官网账号体系和模型绑定得比较死。WorkBuddy 则是一个更开放的 AI 编程工作台它不锁定某一家模型厂商你可以在里面配置 OpenAI、DeepSeek、Ollama 本地模型等。它的核心设计是“Skill”也就是预先写好的指令集可以在不同项目之间复用。对我这种需要同时维护好几个项目的开发者来说这一点非常实用。简单打个比方Codex 像是一个很聪明的实习生但你每次都得把要求重新讲清楚WorkBuddy 更像是一个带工位、带工具箱的协作台你会提前把规则贴在桌上它自动按规则执行。1.2 为什么我会选择换掉 Codex促使我换工具的直接原因有两个。第一个是模型切换成本。Codex 虽然也能通过环境变量方式接入其他模型但步骤比较绕而且官方并不推荐。我有段时间想用 DeepSeek 来降低日常小额任务的费用在 Codex 里配置了半天不是鉴权报错就是模型名不兼容浪费了不少时间。第二个是长会话场景下的体验。Codex 在处理超过一两个小时的大任务时上下文窗口很容易被塞满经常聊着聊着它就忘了最开始的需求。对我来说最崩溃的是让它改一个模块它会把另一个模块的代码风格也带偏非常折磨。而 WorkBuddy 的默认工作区模式会把每个项目的上下文拆得比较清楚模型接入做得简单粗暴配置文件改一下就能用所以我才决定把它作为主力工具用一周试试。2. 安装与上手从 Codex 环境切到 WorkBuddy 的完整流程2.1 安装 WorkBuddy 并完成基础认证我用的 WorkBuddy 版本提供桌面客户端和命令行工具我是直接在官网下载安装包完成的。安装过程比 Codex 更“现代”没有太复杂的依赖要求。装完后先启动客户端它会要求你登录账号并创建一个工作区。这一步和 Codex CLI 的体验差别不大都是扫码或者用 Token 登录。需要提醒的是如果你之前已经装过 Codex系统可能同时存在两套命令行环境变量WorkBuddy 安装后最好新开一个终端窗口避免 PATH 冲突。我第一次装完就遇到命令找不到的问题后来确认是新终端没刷新环境变量导致的。登录完成后WorkBuddy 会引导你选择一个默认模型。这里有个小细节它内置了模型模板但服务地址默认指向官方接口。如果你想用 DeepSeek 或其他兼容 OpenAI 格式的服务需要在设置里手动改配置。2.2 配置 DeepSeek 作为后端模型把 WorkBuddy 接到 DeepSeek 是我这次切换的核心诉求。具体操作并不复杂在配置文件里指定模型供应商和 API 地址就行。我用的配置大概长这样{ model: { provider: deepseek, name: deepseek-chat, api_base: https://api.deepseek.com/v1, api_key_env: DEEPSEEK_API_KEY }, workbuddy: { auto_approve: false, max_turns: 20, working_dir: ./workspace } }api_key_env是环境变量名我习惯把 Key 写到~/.bashrc里而不是直接明文写在配置文件中这样即使把配置分享给别人也不会泄露密钥。配置完成后重启 WorkBuddy在模型选择里切换到 DeepSeek然后跑一个简单的提问例如“输出一段快速排序代码”如果能正常回复说明链路已经通了。对比来看Codex 想接 DeepSeek 就麻烦得多。因为它的鉴权和模型列表是绑定在官方体系里的你要手动为它“补充”模型注册逻辑改完还不一定生效。WorkBuddy 的做法则更符合国内开发者的使用习惯API 地址、模型名、密钥全都是开放字段一次配置全局生效。2.3 用自定义指令Skill替代原来的提示词模板这是 WorkBuddy 最让我惊喜的功能。以前用 Codex 的时候我每个任务都要在 Prompt 里重复写一堆规则比如“先读 README再理解代码风格最后给出最小改动”。现在 WorkBuddy 的 Skill 功能把这些沉淀成了可复用的指令块。我创建项目级 Skill 的时候会在工作区里新增一个.workbuddy/skills/目录里面每个 Markdown 文件就是一个 Skill例如code-review.md# Code Review 你是一个严格的代码审查者。请按下面顺序执行 1. 先输出本次改动涉及的文件列表 2. 检查是否有明显安全问题比如硬编码密钥、SQL 注入 3. 检查是否有无法到达的分支或死代码 4. 对每个问题给出修改建议标注严重级别之后再需要 Code Review 时我只需要在 WorkBuddy 的输入框里写“对最近的改动执行 code-review”它就会自动加载这个 Skill。这点比 Codex 里纯粹靠 Prompt 复制粘贴要舒服很多规则只需要写一次后续所有项目都能复用。3. 一周实操记录写代码、重构、调试、文档3.1 新项目初始化与代码生成这周我开了一个新的 FastAPI 小项目用 WorkBuddy 完成了初始化。我给它下了一个指令“创建项目结构包含 app/main.py、app/api、app/core、app/models使用 FastAPI 框架并写好 requirements.txt。”它很快就把目录结构搭好了每个文件的初始代码质量也在预期范围内。和 Codex 相比WorkBuddy 在生成新项目时更“听话”。Codex 在生成文件时偶尔会自作主张增加一些额外依赖特别是当你没明确“不要安装额外包”时。WorkBuddy 则更多是按照 Skill 里约定的目录规范来执行。如果你提前在 Skill 里写了“除非用户要求不要自动安装任何 pip 包”它能很好地遵守。当然它不是完美的。在项目初始化过程中它生成的数据库模型和我的预期有出入字段类型不够细致。但好在我可以直接在终端里跟它继续强调需求它会根据历史上下文修正不需要重新开一个会话这种连续性是我在 Codex 里很少体验到的。3.2 旧项目重构与 Bug 修复重构和修 Bug 是我日常最看重的能力。这次我拿一个以前用 Codex 写的老模块做测试这个模块里有一个函数有递归调用但基准条件写错了我一直没发现。WorkBuddy 在“代码审查”模式下直接指出了第 47 行可能无限递归并给出了修复建议。更让我惊喜的是它对“最小改动”的理解。一开始我担心它会大范围重写但实际上它只改了递归基准条件和返回值处理没有动其他无关部分。后来我对比过 Codex 在这类问题上的输出Codex 倾向于做更大胆的重构适合新代码但稍不注意就会把业务逻辑改歪WorkBuddy 则默认更保守适合成熟项目。不过WorkBuddy 也有它的短板当项目文件非常多、相互依赖复杂时它的上下文加载速度会变慢。我在一个接近 2 万文件的 monorepo 里测试过首次加载代码索引大约要一分钟后续响应速度才恢复正常。如果你日常也在超大仓库里工作这一点需要提前有心理准备。3.3 测试用例与文档生成写单元测试和项目文档是这周体验中收益最大的部分。WorkBuddy 会根据你选中的函数自动生成 pytest 测试用例而且会主动问你“是否需要覆盖边界条件”。我实测了它生成的测试代码大部分可以直接跑过个别用例断言条件过宽比如只检查返回类型而不检查值。但整体节省了我至少一半的写测试时间。文档生成方面我让它基于 README 草稿生成完整的 API 文档和部署说明。它生成的 Markdown 结构清晰还顺带帮我把环境变量说明表格补全了。这里有个经验分享生成文档前最好在 Skill 里定义文档风格比如“标题层级要一致代码块必须带语言标签关键词需要加粗”否则它默认风格可能会和你团队现有文档不一致。关于 Codex 和 WorkBuddy 在文档场景的对比Codex 生成的文档偏“短文风”适合快速记录WorkBuddy 更适合生成长篇、结构化文档因为它能在上下文里同时保持对代码结构、配置文件、依赖关系等多个对象的引用。3.4 对比 Codex响应速度、上下文、费用体感把两者放到一起对比的话主要差距集中在三点。响应速度方面如果后端都接入同等级的模型两者差别不大。真正影响体验的是 WorkBuddy 在处理多文件上下文时会有额外的索引开销初期稍慢后续稳定后跟 Codex 没明显区别。上下文管理方面Codex 的对话更像“单线程”你让它改 A 文件它会把注意力集中到 A 文件等你又说改 B 文件时它可能逐渐遗忘 A 的上下文。WorkBuddy 则通过工作区的方式把相关文件纳入一个“任务盒子”只要不手动切换任务它会一直记得这个盒子里所有文件的状态。这意味着复杂任务可以拆成多轮对话而不必担心前面的事被忘掉。费用体感方面因为我切换到 DeepSeek 作为后端模型日常简单任务的成本明显下降。之前用 Codex 官方模型跑一天代码审查费用有点肉疼现在大多数轻量任务都由 DeepSeek 承担有些重复性的重构工作我用本地模型配合 WorkBuddy 也能应付账单数字舒服了很多。4. 常见问题与避坑指南4.1 服务状态没起就报错怎么办WorkBuddy 在启动任务时偶尔会提示“无法连接到本地服务”或者“处理 codex endpoint /responses 时本地服务切换失败”。我最早遇到这个问题时很慌后来发现绝大部分是缓存和进程残留导致的。我的排查步骤是先退出 WorkBuddy 客户端然后在终端里查看是否有残留进程占用相关端口再删除工作区缓存目录一般在~/.workbuddy/cache下最后重启。如果还不行就检查环境变量里是否同时设置了多套模型密钥尤其是OPENAI_API_KEY和DEEPSEEK_API_KEY混在一起时服务启动会困惑到底该用哪个鉴权。4.2 模型切换不生效的排查方法第一天配置 DeepSeek 之后我发现修改模型配置后需要完全重启客户端才会生效光是切换界面里的下拉框不够。后来我在文档里看到WorkBuddy 的模型配置是按“工作区”隔离的也就是说我改了全局配置但某个老项目工作区可能还留着旧模型的缓存。正确做法是到具体工作区的配置文件里确认model段是否覆盖了全局设置。如果你希望所有项目默认都走 DeepSeek就不要在工作区里单独写model字段。排查时可以用一个最简单的提问来判断当前模型是谁在处理比如直接问“你现在是什么模型”它能回答出模型名称就说明切换成功。4.3 账号、API Key 和工作区隔离的经验多项目并行开发时账号和 API Key 的隔离很重要。WorkBuddy 支持不同工作区使用不同的模型配置这一点我很喜欢。但要注意如果你用 Git 管理项目仓库千万不要把包含 API Key 的配置文件提交到仓库里。我的习惯是全局配置里只写api_key_env然后每个项目通过.env文件注入密钥并在.gitignore里忽略.env。这样可以避免多个项目之间密钥互相覆盖也方便同事各自维护自己的账号。Codex 的账号体系相对封闭切项目时经常是同一个 Token 走天下权限边界没那么清晰。WorkBuddy 在这方面灵活很多但灵活也意味着用户自己要管理好配置否则容易乱。4.4 WorkBuddy 适合谁不适合谁根据这一周的体验我觉得 WorkBuddy 适合这几类人一是日常要切换多个 AI 模型来平衡成本和效果的开发者二是需要沉淀团队规范、用统一指令约束 AI 行为的团队三是经常做长链路任务、对上下文连贯性要求高的人。不适合的人也有如果你只是偶尔写几行脚本不想折腾配置文件那 WorkBuddy 的灵活反而是一种负担直接用 Codex 官方默认体验会更省心。另外如果你特别依赖 OpenAI 官方模型的某些实验特性比如最新的推理模型WorkBuddy 接入这些模型后可能无法 100% 还原官方客户端的全部能力最多是靠配置补特性跟随有滞后。不过这周我用下来真正让我留下来的原因不是某个单一功能而是“换了模型、改了规则、项目上下文也不会丢”的整体体验。现在我已经把几个核心项目的默认配置都迁到 WorkBuddy 上了短期应该不会再折腾回 Codex。最后再分享一个小技巧我会把 WorkBuddy 和 Obsidian 搭配使用用 Obsidian 记录每次任务的输入输出摘要然后在 WorkBuddy 的 Skill 里引用这些笔记作为背景知识。这样跨天、跨项目再来继续任务时AI 能参考我当时的决策原因而不只是看代码本身。这个玩法目前还不算热门但实测下来对长期项目的连续性帮助非常大。