从codex转战workbuddy使用一周的感受最近一周我把主力AI编程工具从codex切到了workbuddy起因是手头一个带复杂上下文的旧项目codex反复出现endpoint报错明明对话轮次不多却不停要重新连接甚至有一两次改到一半直接丢上下文。折腾半天没解决索性换工具试试没想到这一换就用了整整一周。先说结论workbuddy严格来说不算codex的平替它更像是一个“能同时兼容codex和claude code操作习惯”的聚合型编码终端但如果你习惯了codex那种“给任务、看diff、敲y”的强交互节奏切过来几乎零学习成本。这一周里我完成了三个中小型任务包括一个带完整单元测试的golang服务、一个前端数据看板以及一次老项目的依赖升级整体体感比codex稳定不少尤其在大上下文场景下的表现让我意外。这篇文章我会按实际使用顺序把这一周的迁移过程、核心配置、踩坑点、与codex的对照感受全部写清楚尤其会提到workbuddy的skill机制、自定义指令推荐、接deepseek这类第三方模型的配置方式以及几个我在实际项目中反复踩到的坑。如果你正纠结要不要从codex换过来这篇应该能帮你省下不少试错时间。1. 从codex切到workbuddy我到底在解决什么问题1.1 codex用得好好的为什么要换说实话codex刚发布的时候我是相当满意的尤其是它的命令行交互模式你给它一个目标它会自己拆步骤、写代码、跑测试最后把diff亮给你确认这种“监督式”的流程非常符合我这种习惯审代码再落地的开发节奏。我甚至写了个简单的包装脚本把codex的会话记录落盘做成周报方便追踪每天到底改了什么。但问题也恰恰出在“稳定”两个字上。我遇到的最典型的故障有两类第一类是endpoint报错具体表现是会话进行到一半codex直接提示类似cc switch local proxy failed while handling codex endpoint /responses的错误然后整个会话状态丢失需要重新加载。如果只是偶尔一次还能忍但在我那个涉及6个模块、上下文超过3万token的项目里几乎每两三轮就要断一次改一个接口要反复恢复上下文心累。第二类是模型支持问题。我在尝试把codex接到deepseek的时候遇到了the gpt-5.6-sol model is not supported when using codex with a这类报错意思是codex的官方客户端对自定义模型的白名单限制很严格不是你想接哪个就接哪个。这对我来说是个硬伤——我们团队有些场景需要走国产模型的合规链路codex这种封闭生态很难满足。1.2 workbuddy是怎么进入视野的我第一次听说workbuddy是在某个技术群里有人提到它和claude code的skill机制很像但又能兼容codex的配置习惯。后来去翻它的项目文档发现几个吸引我的点一是它支持自定义指令和skill热加载二是模型接入层面比较开放deepseek、openai、anthropic的模型都能配三是它本身是个终端工具跟codex一样是“命令行优先”而不是像某些IDE插件那样把你锁在编辑器里。当时我给自己定的迁移条件是至少能把codex的核心工作流搬到workbuddy上包括任务拆解、diff确认、测试回环、上下文持久化。如果这四样都能满足那换工具就值得一试。事实证明workbuddy在这四点上的完成度比我预期高很多尤其diff确认环节它的交互反馈比codex更细能按文件级别批量接受或拒绝而不是只能一个diff一个diff地过。所以这篇博文的定位不是“workbuddy吊打codex”而是从一个真实迁移者的视角把两边各自擅长的地方、切换时要注意的配置项、容易踩的坑讲清楚。毕竟工具这东西没有绝对好坏只有适不适合。2. workbuddy整体设计与核心配置安装、接入模型、目录结构2.1 安装流程与两个容易忽略的细节workbuddy的安装本身不复杂按照官方文档走一遍就行但我强烈建议不要跳过环境检查。它依赖node环境和git如果你机器上有多个node版本比如nvm管理先确认当前版本符合要求再装否则装完启动就直接报模块版本不匹配。安装完成后首次启动会让你选择“工作台”目录这个设计我很喜欢。codex默认会在当前终端目录起会话换目录等于换上下文workbuddy则是绑定一个工作台根目录所有会话和临时文件都挂在这个目录下切换项目时只需要在workbuddy内部切换工作台不用重新cd、重新加载配置。这里有个关键细节workbuddy在工作台目录下会生成一个隐藏的.wb文件夹里面存放你的会话历史、skill注册表、访问日志。这个文件夹建议纳入gitignore但不要手动删因为一旦删除你所有历史会话的上下文记录就全丢了自定义skill的注册信息也可能失效。安装完成后建议顺手验证一下workbuddy的版本和核心命令是否正常。它的命令风格跟codex高度相似主命令是workbuddy子命令包括init、switch、skill、config等。换句话说你在codex里养成的手速在workbuddy里基本可以直接复用这一点切换成本极低。2.2 模型接入openai、anthropic、deepseek三种配置实测workbuddy的模型配置是我认为它最值回票价的地方。codex对模型的白名单限制极严workbuddy则把模型当作一个可插拔的“后端”来对待。它的配置文件支持provider这个概念每个provider可以指向不同的api地址和模型名。官方默认配置里已经预置了openai和anthropic两个provider。你只需要填入对应的api key就能直接用不需要额外改格式。但如果你像我一样需要接deepseek就要手动加一个provider核心配置示例如下workbuddy config set providers.deepseek.base_url https://api.deepseek.com workbuddy config set providers.deepseek.api_key sk-你的key workbuddy config set providers.deepseek.models gpt-5.6-sol,deepseek-coder这里有个需要特别说明的坑deepseek官方接口的模型命名和openai不完全一致如果你在workbuddy里填的模型名不在deepseek后端支持列表里启动时会直接报模型不存在。我当时把openai的模型名直接填进去结果报错说model not found排查了半天才意识到是名称映射问题。建议填完后先跑一条最简单的指令验证连通性而不是上来就扔一个大型重构任务。另外如果你是想用deepseek当“后端推理引擎”而前端交互仍然走workbuddy自己的编排层那你的成本会比你直接用codex官方要灵活很多。我在这一周里实际测过用deepseek处理一个增量功能开发效果比预期好尤其在中文语义理解上感觉比gpt-5.6-sol更贴我们的业务语境。2.3 工作台、会话与上下文持久化的真实体感关于上下文管理workbuddy的思路和codex有一个本质区别。codex的会话更像是一次性的“任务run”你结束一个会话下次要接续思路就得重新贴上下文workbuddy则将工作台内的会话按项目维度做持久化每次切换回来之前的对话历史、修改过的文件列表、甚至pending状态的diff都会被保留。这个改动对我的日常工作方式冲击很大。以前用codex改大需求我必须把“需求背景改动范围约束条件”完整写在任务描述里否则模型容易跑偏现在用workbuddy我可以把需求拆成多个小会话每个会话聚焦一个模块然后通过工作台内的“暂存区”把各模块的改动累加起来最后统一审查diff再一次性落地。当然持久化不是没有代价。会话文件会随着使用越来越大如果你一个工作台绑定了超大项目.wb目录可能膨胀到上百MB。我的建议是每周做一次“会话整理”把已经落地的会话归档只保留还在进行中的会话这样既能保持上下文连续性又不会拖慢工具加载速度。3. 核心细节与实操拆解skill机制、自定义指令推荐、switch切换3.1 skill机制到底是什么它和codex的plugin有什么不同这一周体验下来我认为workbuddy最值得推荐的特性就是它的skill机制。通俗讲skill相当于给AI定义了一套“可复用的工作方法”比如“帮我写单测时应该遵循什么规范”“做代码审查时重点检查哪些方面”。它不仅仅是把prompt存下来而是能让AI在对应的任务场景里自动按这套规范执行。codex其实也有类似的能力但codex的plugin更偏向于“外部工具集成”例如接入编译工具、测试框架等workbuddy的skill则更偏向于“行为约束”它改变的是模型处理任务的方式而不是调用外部工具的方式。这二者侧重点不同对于我这种需要大量代码审查和重构的人来说skill的实用价值更高。我举个具体例子。我的一个skill文件叫“review-golang”内容大概长这样name: review-golang description: 专门用于review go代码的规范 rules: - 所有错误必须显式返回error不能吞掉 - 并发代码必须说明锁的作用范围 - 对外暴露的函数必须有doc注释 - 优先使用标准库禁止随意引入第三方依赖在codex里我每开一个新review会话都要重新把这几条规则用自然语言写一遍写得长了还容易互相矛盾在workbuddy里我只要在会话开始说“用review-golang技能审查这个包”它就会自动加载这个skill按里面的规则输出审查结果。省事程度不是一个量级。3.2 自定义指令推荐我这一周沉淀下来的五条高价值指令使用一周后我积累了几条高频使用的自定义指令这里直接分享出来供大家参考。这些指令不是网上抄来的而是结合我这边的项目类型和踩坑经验写的不一定万能但至少能给你提供思路。第一条是“完成一个子任务后必须输出修改文件清单和变更摘要”。这条指令能有效防止AI埋头改代码改完你都不知道它动了哪些文件。加了这个约束后每个会话结束时的变更记录都会自动生成后续做code review或者回滚都方便很多。第二条是“遇到不确定的业务逻辑时必须先列出假设再继续执行不要自行假设”。这句话看着简单但对抑制“自作主张”特别有效。模型在上下文不够时会脑补需求有了这条指令它会先把不确定的点列出来由你确认后再走下一步。第三条是“重构时保留原有接口签名只改实现除非你先说明理由”。这条对我的兼容性保障太重要了。AI重构代码的老毛病是顺手把接口签名也改了导致调用方全部翻车。有了这条约束至少它能先解释为什么改再让我决定。第四条是“所有新增依赖必须给出引入理由、替代方案评估”。这一条能有效防止模型胡乱加依赖库保持项目依赖体积可控。我们项目组对第三方依赖审查很严格这条指令帮我省了不少review时间。第五条是“测试用例必须覆盖正常、异常、边界三种情况”。这条是写测试时的硬约束模型默认生成的测试往往只覆盖happy path强行加上边界和异常后测试的含金量明显提升。你可以在workbuddy的配置目录下用workbuddy skill create命令创建自己的skill。它默认是yaml格式支持description和rules两个核心字段也支持更复杂的模板变量不过对大多数人来说先把yaml写好就已经能覆盖大部分场景了。3.3 workbuddy switch多项目多工作台切换的正确姿势workbuddy的switch命令是我这一周用得非常频繁的功能。它的作用是在多个工作台之间快速切换每个工作台可以绑定不同的项目根目录、不同的配置策略甚至不同的模型provider。这意味着我可以给“公司项目A”配置deepseek模型给“个人项目B”配置openai模型需要切哪个就切哪个。第一次用switch的时候我犯了个小错误我在一个工作台里绑定了项目A的目录然后直接用cd命令去项目B的目录想在同一个工作台里操作B。结果发现上下文中还残留着项目A的信息模型经常混淆两个项目的结构。后来我才搞清楚workbuddy的工作台与目录是强绑定关系。正确做法是先执行workbuddy switch选择或创建一个新的工作台让它绑定项目B目录这样两个项目就是完全隔离的会话上下文。比如给每个项目绑定独立工作台后来回切换不会互相污染上下文也不需要反复贴先导信息。另外switch命令还支持跨机器迁移。你可以用workbuddy导出当前工作台的所有配置与skill再到另一台机器导入会话历史虽然不一定完全恢复但技能和模型配置能原样搬过去。我在笔记本和台式机之间就是这样同步的省了很多重复配置的时间。3.4 上下文长度告急时workbuddy是怎么处理的大上下文一直是这类AI编码工具的命门。codex在上下文超长时要么直接报错要么靠截断历史继续但截断之后模型经常“失忆”忘记前面已经确定的实现方案。workbuddy也有限制但它有一套“会话摘要转移”机制。具体来说当会话接近上下文上限时workbuddy会自动生成本轮会话的阶段性摘要并把摘要加入后续请求的前缀中。这样即使历史的原始明细被裁掉模型依然能把握整体方向和已完成决策。这个机制对那种改到一半需要调接口、查文档的长时间任务非常友好。实测下来在一个上下文总量接近6万token的任务里workbuddy的表现是它能继续按照摘要推进不会因为截断而把前文的结论推翻。这一点是我这一周没有切回codex的关键原因之一。codex如果上下文窗口爆了emo情绪严重人根本没法继续干活。4. 实操过程与关键环节实现从安装到完成一个真实任务4.1 第一阶段初始化工作台并完成模型连通性验证我建议任何迁移的人第一次用workbuddy都走一遍完整的初始化流程不要跳步。第一步是建立工作台目录我建了一个专门的文件夹叫wb-workspace然后执行workbuddy init它会自动生成.wb目录和默认配置文件。第二步是配置模型。我先配置了openai provider因为想验证跟codex同样的模型在workbuddy里表现如何。配置命令如下workbuddy config set providers.openai.api_key sk-xxxx workbuddy config set providers.openai.models gpt-5.6-sol配置完后用一条最简单的对话验证连通性workbuddy chat 只回复ok如果它回复ok说明链路通了。接着我又按前面提到的方式配置了deepseek provider。这里再强调一次deepseek的模型名要填deepseek支持的模型名不是openai的模型名。我用deepseek配置成功后还顺手验证了“对话历史是否自动保存”和“切换provider后历史是否还在”两个功能结果都符合预期。4.2 第二阶段为真实任务编写skill并跑通全流程连通性验证通过后我直接用之前那个golang服务当试金石目标是给一个用户服务模块补充单元测试。我先是create了一个名为golang-test的skill把测试规范和覆盖率要求写进rules然后在workbuddy里指定使用这个skill让它在目标目录内自动扫描相关文件生成测试代码。workbuddy的自动化能力还是不错的它会先列出它将要处理的文件清单然后给出一个简短执行计划确认后开始动手。整个过程跟codex的“让AI自己拆解任务”很像但workbuddy的每个步骤都更透明——它会标出当前正在处理哪个文件、下一步要做什么而且大部分时候不会突然跳到计划外的事情上。这个任务当时跑了大概15分钟生成了7个测试文件总计覆盖率从原来的30%提升到了68%。尽管离我理想的80%还差一截但考虑到这个模块本身的依赖结构较复杂这个结果已经很能接受了。关键是整个过程中我没有手动干预过一次它也没出现“改着改着突然跑题”的情况。4.3 第三阶段diff审查、批量接受与回滚策略workbuddy生成的改动默认不会直接写入磁盘而是先进入一个暂存区。这和codex默认的“直接改文件再亮diff”不太一样但更安全。我可以在暂存区里逐个文件看diff选择接受、拒绝或继续修改操作命令和git有点像。对于一个改动量比较大的任务逐文件看diff会有点累但workbuddy支持按目录批量接受也支持对某一个文件追加修改指令。比如我觉得某个文件的实现方式偏复杂可以直接在workbuddy的交互框里说“把这个文件的实现简化去掉不必要的抽象”它会重新生成新方案并保留原diff供我对比。此外workbuddy提供了快照回滚功能。我在动手改一个旧项目之前先创建了一个工作台快照后来改到一半发现方案走错了直接一条命令就恢复了快照。这个能力是codex没有的特别适合那些“先试试看不行再回滚”的探索式开发。4.4 第四阶段接deepseek跑增量开发任务的效果记录除了golang服务我还用workbuddy接了deepseek做了一个前端数据看板的增量功能。这个项目之前是用codexopenai模型完成的这次换成deepseek后端主要是想测试跨语言项目的模型理解能力。我用deepseek完成的是“在现有表格页面增加筛选条件和导出按钮”的需求。整个过程它先准确地找到了表格渲染组件又找到了数据请求接口在不改动后端的前提下用前端参数拼接的方式完成了筛选功能。导出部分它选择了csv方案原因是没有引入额外后端依赖合理性让我比较满意。当然deepseek也不是没有短板。它在处理非常复杂的长链路跨文件重构时偶尔会给出“看起来合理但实际上忽略边界条件”的代码。比如它在一个异步请求场景里没有处理组件卸载后的setState调用导致潜在的警告。这类问题在review时被我逮住了但确实提醒了我接deepseek后review环节不能松懈它的代码生成能力够强但隐性边界把握还是比不上顶级商业模型。5. 一周使用下来的常见问题、坑点与避坑心得5.1 高频报错整理与排查方法我把这一周遇到的各种报错做了个简单汇总这里列几个最常见的方便大家快速定位。如果你看到类似cc switch local proxy failed while handling codex endpoint /responses的报错这多半不是workbuddy的问题而是你在同时使用某种本地代理或端口转发时codex的endpoint被代理拦了。workbuddy本身不依赖本地代理转发所以这种报错在workbuddy里很少出现。但如果你的workbuddy配置里也设置了自定义base_url且那个地址连不通它会报connection refused这时要先检查目标地址和网络连通性。另一个常见问题是“模型名不支持”。报错文本通常带有一句the xxx model is not supported这不一定是workbuddy的限制更像是对接的第三方后端对模型名的白名单限制。处理办法是去对应provider的文档里查当前支持的模型列表然后把模型名改成后端支持的写法。顺便提一下“workbuddy启动时卡在loading”的问题。我遇到过两次后来发现都是因为在某个目录下执行命令时该目录不存在.git目录而workbuddy默认会做git状态检测导致扫描异常。解决办法是在一个git仓库内启动或者用config关闭git检测。5.2 workbuddy与claude code、codex的直观对比这一周里我也重新看了不少关于“claude code和workbuddy对比”的讨论说实话workbuddy确实吸收了claude code的很多设计理念比如skill机制就很有claude code的感觉。但workbuddy在模型接入上比claude code更开放既支持anthropic系模型也支持openai系模型还能接deepseek这一点对国内开发者很有吸引力。和codex相比workbuddy的优势在于上下文管理和多工作台切换缺点是它在一些极端复杂任务的“自主规划能力”上暂时不如codex官方模型那么强悍。简单说如果你喜欢让AI全自动从头做到尾codex更顺手如果你喜欢让AI按你的规范和节奏做事workbuddy会给你更强的掌控感。另外workbuddy对Linux的支持也做得不错。我在一台linux服务器上测试了文本界面的完整工作流基本没遇到兼容性问题。这点要比codex的windows安装体验好得多如果你在windows上装过codex大概率遇到过“codex windows安装未完成”“codex安装包下载失败”这类问题workbuddy在跨平台安装上明显省心。5.3 我最想单独拎出来说的三个坑第一个坑是不要把workbuddy的默认模型设置成deepseek之后就彻底不再管提供商配置。因为deepseek的模型名称和openai不一致如果你在某个工作台里切到了openai provider再切回deepseek provider可能会因为模型名缓存导致启动失败。最好显式地设置provider后重启一次会话再开始干活。第二个坑是临时写的一行式指令也会触发skill。刚开始我没注意一次只写了“修复这个bug”几个字结果workbuddy自动加载了一个我很久之前写的debug规范skill生成了大量与当前bug无关的检查清单。后来我习惯在需要临时自由发挥时先显式声明“不使用任何skill”避免被旧规范带偏。第三个坑是workbuddy的自动化改文件默认走暂存区但如果你的磁盘上已有同名文件且处于“冲突状态”它可能会提示覆盖冲突。如果你不想覆盖一定要在任务开始前明确要求“不要覆盖任何已存在的文件只新增新文件”否则它可能直接覆盖掉你的手改内容。这个坑我踩过一次后来就养成了每次开工前先声明“只新增不修改”的习惯。6. 一个被我忽略但后来发现很实用的功能obsidian与知识库联动我是在整理笔记时无意中发现的workbuddy支持与obsidian联动。它能直接读取obsidian vault里的markdown文件并识别其中的双链笔记结构。这意味着你可以在obsidian里写需求文档、设计方案然后在workbuddy里直接引用这些文档作为任务的背景材料。这个功能对我的工作方式影响很大。以前我处理一个需求要把需求文档里的关键段落手动复制到codex的对话里现在我在workbuddy里只需要说“读取obsidian中关于订单模块的设计文档然后按文档实现接口”它就能自动去vault里找到对应文件并作为上下文的一部分加载进来。我甚至尝试过把“团队编码规范”写成一个skill然后放在obsidian里维护workbuddy每次加载skill时都会引用vault里的最新版本。这样规范文档更新后不需要重新配置工具AI下一次任务自动使用最新规则。对于需要长期维护的知识库团队来说这个组合非常实用。如果你也使用obsidian我强烈建议你在workbuddy里配置一下vault路径。workspace设置里有一个vault字段只需填上vault的根目录路径并在技能描述里注明“读取文档时可参考vault”就能激活这个能力。当然如果vault太大可以限定读取的文件夹范围避免每次任务都全量扫描影响响应速度。7. 最后的实操经验与当前结论一周时间不算长但对我来说足够判断一个工具是否值得长期使用了。目前我的结论是主力编码会继续用workbuddy尤其是涉及多文件、长上下文、需要高频切换项目的场景它的稳定性让我很踏实。codex我也没有完全卸载偶尔做一些一次性脚本生成、需要快速验证思路的小任务时它依然很快很直接。我个人的体会是这类AI编程工具没有“最好”只有“在当前项目状态和协作习惯下更顺手”。如果你跟之前的我一样被endpoint报错、上下文丢失、模型白名单限制折磨得够呛那workbuddy完全值得一试。但如果你对“让AI全自动搞定一切”有很强需求并且不在意模型锁定codex也能继续用。最后分享一个小技巧无论你用哪个工具开工之前花5分钟把项目目录结构、技术栈、关键约束整理成一段“项目先导说明”并让AI在每次会话开始时先复述一遍理解这能显著减少跑偏概率。工具升级再多清晰的需求表达永远是最高杠杆的投入。