这一周我把主力AI编程工具从Codex换成了WorkBuddy整个过程从迁移到磨合刚好七天。起因不复杂Codex底子不差但到了后半程我实在受够了它那套封闭又固定的工作流——换个模型要折腾半天遇到“model not supported”就只能翻配置agent内部在做什么也看不到。正好社区里有人把WorkBuddy和DeepSeek串在一起用灵活度高一个量级我就决定做一个迁移实验先花一天清理掉旧环境再把WorkBuddy跑起来用一周时间完成一个小项目的迭代顺便验证它能不能替代原来的日常编码流程。这篇文章就是这一周的完整记录包含迁移思路、接DeepSeek的具体步骤、Skill机制的使用方法以及我自己踩过的一些坑。如果你也在Codex和WorkBuddy之间犹豫或者刚装好WorkBuddy不知道从哪里入手这篇应该能给你一个比较完整的参考。1. 为什么转Codex的“好用”与“难受”同时存在1.1 Codex给我留下的最后印象先说Codex好的地方。它把终端里的Agent工作流带到了一个新的高度会话连贯性做得确实到位我让它修一个跨模块的bug它能自动去翻相关文件、定位问题、改完代码后自己跑测试整个体验非常有“真人结对编程”的感觉。这也是我一开始愿意把日常开发押在它身上的原因。但问题也在这里。Codex的定位明显更偏“官方全家桶”底层能用的模型是限定的你想把它切到一个别的模型上去用官方支持非常有限。我后来查了一圈社区方案才发现很多人都在吐槽同一个点这工具哪里都好就是太“轴”了你想绕开官方模型体系去接自己的网关几乎每一步都在跟它的设计理念做对抗。1.2 真正推动迁移的三个导火索促使我动手迁移的直接原因有三个都是实际开发中撞上的。第一个是模型绑定的问题。我在本地配置里写了gpt-5.6-sol这个模型名结果运行时直接报the gpt-5.6-sol model is not supported when using codex with a...。我一开始以为是配置写错了试了几次发现这根本不是拼写问题而是Codex这套工具链对非官方模型的支持天然就有限你传进去的模型名它自己不认识就会果断拒绝。第二个是本地接口路由的问题。那几天我还遇到了一个很典型的报错cc switch local proxy failed while handling codex endpoint /responses. provi...。对应到实际操作里就是我已经按照社区教程把请求路由切到了本地网关可一旦真正发起对话Codex的/responses端点就无法被正确转发服务端直接报错会话根本建立不起来。这个错在网上能找到的信息非常少几乎全靠自己猜。第三个是调试不透明。Codex跑起来之后整个过程像一个黑盒它到底调用过哪些文件、执行过什么命令、为什么最终放弃了某个方案日志里很难看懂。代码出了问题时我只能盲猜是上下文问题、模型问题还是工具配置问题。作为一个需要写文档、给团队复现问题的人这种不可观测性会消耗大量时间。把这三个导火索摆在一起结论已经很明显我需要一个模型接入更开放、运行过程更可见、自定义能力更强的Agent工作台。于是WorkBuddy进入了我的备选清单。2. 迁移首日安装、配置与把DeepSeek接进WorkBuddy2.1 WorkBuddy安装与初始化我是在Linux环境下做的迁移安装过程整体比预想中顺利。第一步是下载对应架构的二进制包解压后丢到/usr/local/bin下并给足执行权限。如果你用Windows建议直接用管理员身份打开终端再安装后面我会专门讲Windows安装未完成这个坑。装好之后第一次执行初始化命令会生成配置文件默认路径类似~/.workbuddy/config.json。这一步非常关键因为后面所有模型、Skill、知识库路径的配置都会汇总到这个文件里。我建议执行完初始化之后马上打开配置文件看一眼结构确认profile、model、skill、context这些核心字段是否存在别等到后面报错了才回来补课。登录环节看具体发行版有的版本需要联网登录账号有的部署模式可以直接走离线配置。我选的是离线模式好处是后续迁移到其他机器时只要复制配置文件和Skill目录就能整体搬走。提醒一句无论用什么方式安装先把配置目录备份一份。我见过太多人改配置改到一半文件语法出错导致工具完全无法启动而默认配置早被覆盖了。备份一下真的不亏。2.2 接入DeepSeek接DeepSeek是这次迁移的核心需求。整个配置逻辑其实不难本质就是告诉WorkBuddy有一个新的模型提供方它在什么地址、用什么Key、提供哪些模型。具体到配置上需要新增一个provider段落常见的配置大概是这样的{ provider: deepseek, base_url: https://api.deepseek.com/v1, api_key: sk-你的key, model: deepseek-chat, temperature: 0.3, max_tokens: 8192, timeout: 120 }这里我踩的第一个关键点是模型名的选择。DeepSeek现在常用的两个模型方向一个是通用对话模型deepseek-chat一个是推理模型deepseek-reasoner。日常写代码、改bug、补注释我会用deepseek-chat速度和稳定性更好遇到需要复杂推理、跨模块推演的问题再临时切到deepseek-reasoner。配置完成后我先用一句话验证链路是否通畅“打印当前工作目录并说明这个仓库的依赖关系。”如果它能正确调用ls、读取package.json并给出有条理的回答说明整条链路已经通了。2.3 环境踩坑实录本地路由与模型不支持第一天的迁移并不全是顺利的Codex时代那两个报错虽然不再阻塞但转战初期我还是被类似的配置问题折磨了一阵子。先说cc switch local proxy failed while handling codex endpoint /responses这个问题的根因我没有继续在Codex里面硬碰硬而是把它当成一个“本地API网关配置”的典型疑难杂症来处理。排查思路是这样的先看代理目标是否真的通过/responses这个路径提供服务如果上游接口根本不识别这个路径那问题就不在WorkBuddy这边再看配置文件里的模型名是否和上游网关的模型别名一致很多模型名只是在网关侧做了映射真实模型名可能完全不同最后用curl直接手动请求一次网关接口绕开所有Agent工具单独验证模型名是否有效。顺着这个思路往回翻我发现大部分所谓的“模型不支持”报错本质都是模型名透传映射出了问题。比如你在Codex配置里写了gpt-5.6-sol这个模型名会透传到网关而网关并不认识这个别名自然就返回了model is not supported。也就是说遇到这类报错不要第一时间怀疑工具坏了先去手动测一下模型名。很多所谓“换模型就崩”的问题真的只是名字对不上号而已。3. 一周体验WorkBuddy与Codex的工作流差异观察3.1 Skill机制让我重新理解了“自定义指令”用过Codex的人应该都有体会它的自定义指令更像是一个“总开关”你把它写进配置它就跟背景设定一样附着在每一次对话里。缺点是一旦指令多了整个Agent会变得混乱它不是按需触发而是每条指令都在同时影响模型的行为。WorkBuddy的Skill机制完全改变了这个用法。Skill不是“一条背景设定”而是一个有结构、可触发、可复用的能力单元。它的目录结构类似这样~/.workbuddy/skills/review/ ├── SKILL.md ├── examples/ │ ├── example1.md │ └── example2.md └── scripts/ └── collect_diff.shSKILL.md里描述这个Skill负责什么、在什么场景下触发、需要哪些输入最后给出标准输出格式。我实际写了一个reviewSkill作用是每次在会话中输入/review时它先收集当前分支的改动再按提交记录清晰度、错误处理是否完善、安全风险这几个维度逐项检查最后输出一个结构化的评审结论。这套机制最大的好处是把原本写死在prompt里的东西变成了“工具”。prompt工程从“写一段好话让模型记住”变成了“做一个好用的工具让模型按需调用”。团队协作也方便很多我写好的Skill直接推到共享目录别人拉下来就能用不需要理解我当初为什么要用那套提示词。3.2 工作台与纯终端的差距Codex是标准纯终端风格好处是轻量、简单、不打扰但一旦同时处理多个任务比如这边在修bug、那边要写测试、还要查历史提交信息纯终端就很容易乱。WorkBuddy的“工作台”思路更接近一个可视化的开发面板。你可以把不同任务放到不同的会话标签页里每个会话都有独立的上下文互不干扰。更重要的是工作台会把Agent的操作过程展开给你看调用了哪个文件、执行了哪条命令、读到了什么内容全部是可折叠的日志。对于我这种需要事后整理思路、复盘操作过程的人来说这个“打开看历史”的能力非常救急。刚开始我担心可视化的东西会不会更重、更慢但实际跑了一周发现它对终端性能的影响可以忽略不计而每次调试时节省下来的时间非常可观。3.3 实测对比谁更适合日常开发为了验证WorkBuddy是否能作为Codex的替代品我做了三组对比测试写一个RESTful API服务、重构一个已有模块里的不健康函数、为一段核心逻辑补单元测试。每组都用相同的需求描述分别交给两个工具执行。结果大概是这样对比维度CodexWorkBuddy代码理解深度强默认模型对代码库的理解很稳强我接的是DeepSeek理解力也可接受模型灵活性弱基本限定在官方模型体系强可随意切换多个模型提供方自定义指令有但偏全局背景不够结构化Skill机制按需触发、可复用、可共享会话并行一般支持多任务标签页并行体验好调试可见性黑盒感强只能看最终结果操作过程可见日志可折叠回看初始配置成本低开箱即用高一些但迁移完成后收益明显如果只看“开箱即用”Codex确实更省心但如果你有换模型、自定义工作流、多任务并行的需求WorkBuddy的灵活度是Codex比不了的。就我个人场景来说日常开发已经彻底回不去了。3.4 与Claude Code、CodeBuddy的横向比较最近社区里经常有人问“WorkBuddy和Claude Code怎么选”“CodeBuddy和WorkBuddy是不是同一个东西”我在这里也顺便说说我的理解。Claude Code的优势在于上下文建模和代码理解能力很强而且在长会话中的保持力非常出色适合复杂项目里的长时间深度介入。但它的默认生态也绑定了Claude模型家族你想接DeepSeek或者别的模型同样需要额外操作。如果你就是Claude的重度用户Claude Code自然是首选但如果你希望模型层可以被自由替换WorkBuddy的开放性是更明显的。至于CodeBuddy它和WorkBuddy是两条完全不同的产品路线。CodeBuddy更偏IDE插件生态是基于编辑器场景做的AI扩展WorkBuddy则更接近一个独立的Agent工作台强调多模型接入和Skill体系。很多人搜索时把这两个名字混在一起实际上它们解决的问题并不一样也没有必要强行对比。另外还有人拿豆包这类偏聊天问答的产品来比较我觉得这可能是个误区。那个方向的产品主战场在对话交互而不是代码工程里的高频Agent场景。如果你要的是“帮我改代码、跑测试、写提交信息”那还是要用WorkBuddy、Codex这一类真正面向开发流程的工具。4. 进阶玩法把WorkBuddy调教成自己的主力工作台4.1 自定义指令推荐用了一周之后我总结出几条提升明显的自定义指令直接可以用到日常项目里。第一条是代码风格约束。不要只跟模型说“写代码要规范”它很快就会变得泛泛而谈。我的做法是把具体规则写清楚变量命名用有业务含义的完整单词函数长度尽量控制在50行内错误处理必须区分业务异常和系统异常并给出一段示例代码。这套约束放进Skill里之后生成代码的风格一致性改善非常明显。第二条是任务拆解指令。以前让Agent直接改一个复杂功能它常会试图一次完成所有事中间一旦出错就是连环错误。现在我会先用一条指令让它输出TODO列表等它规划完我再逐个节点让它推进。表面上多了一步交互实际上大幅减少了返工。第三条是提交信息生成。我把它设定成必须遵循Conventional Commits规范提交类型只能是feat、fix、refactor、docs、test这些固定选项并且要求说明变更原因而不是只描述改动内容。这条指令几乎是所有团队的刚需因为提交信息的质量直接决定后面回溯变更的成本。第四条是变更总结用于生成合并请求描述。它要求Agent先列出涉及的文件、核心变更点、影响范围再给出测试建议。这个指令省下了我每次写变更说明的时间而且在多人协作时非常友好。4.2 联动Obsidian做知识库这是这一周里最意外的收获。原来我以为WorkBuddy只能处理当前仓库的代码后来发现它完全可以联动本地知识库而Obsidian就是很好的载体。配置方式也不复杂我建立一个专用目录专门存项目文档然后在配置里声明vault路径或者单独写一个文档读取的Skill让Agent在需要时用glob规则去读取指定文件夹里的markdown文件。实际场景中我把项目的架构决策记录放在vault里每次让它开发新功能前先读对应目录下的ADR避免反复解释项目背景。这里有一个重要的建议不要让Agent一次性把整个vault塞进上下文里。那样做不仅费token还会让模型在大量无关信息里迷失重点。我的做法是规定它只能读取docs/adr/**这类明确子目录并且要求在总结背景时引用具体文件路径保证上下文可控。4.3 SkillHub与团队沉淀WorkBuddy生态里有个概念叫SkillHub我没有把它当成一个简单的插件市场而是理解成“Agent技能的分发中心”。这种机制把零散的prompt变成了可以安装的能力包团队里任何一个人写好了其他人一键就能使用。从团队沉淀的角度我建议的流程是先在个人会话里反复调试某条临时指令直到它稳定解决某类问题再把它固化成Skill写清触发场景和输出格式接着补上一两个示例文件方便别人理解边界最后推送到团队的共享目录。这套流程跑顺之后团队里的Agent会越来越“懂”团队的业务上下文而不是每次都要从头解释。5. 一周内遇到的高频问题与排查心得5.1 常见报错速查表这一周我踩了不少坑也浏览了大量社区讨论。整理了一份高频问题速查表按“症状-原因-处理”三列排好方便直接对照排查。症状常见原因处理方式API请求返回401Key失效或base_url填错检查配置里的provider地址和Key手动用curl验证报错model not supported模型名透传映射不对查询网关支持的模型别名建立映射后再用本地接口路由切换失败上游接口与期望的endpoint不匹配用curl手动请求接口确认路径和方法上下文超长导致回答质量下降单次会话塞入信息过多收窄读取范围或改用检索方式只取关键段落Skill一直不生效目录结构或SKILL.md格式不正确检查触发词、frontmatter是否规范确认放在skills目录下输出乱码或终端宽度异常TUI渲染问题调整面板宽度或重开会话让渲染层重置这个表格是我每天结束时迭代更新的前两天的排查速度明显慢后几天基本遇到问题就能快速定位。5.2 几个让我印象深刻的故障现场第一个故障现场是本地路由切换失败那晚。我一开始以为是自己操作步骤不对连续重试了三次切换命令结果不仅没修好还把原来的配置文件覆盖了。那一次的经历让我养成了“改配置前先备份”的习惯现在任何Agent类工具我都严格遵守这个原则。第二个故障现场是DeepSeek推理模型超时。切到推理模型后它在复杂问题上会保持长时间的思考链我的timeout参数一开始设得太小导致会话直接中断。重新把超时时间从60秒调到120秒之后长推理任务才稳定下来。这个参数日常写代码时不觉得重要但一旦切推理模型就变成关键瓶颈。第三个故障现场是在Windows环境安装未完成。这个问题在社区讨论里出现的频率很高大多数情况是安装目录没有写入权限或者PATH没有生效。解决方法是回到管理员终端重新下载安装包然后手动检查环境变量是否包含安装路径最后重新启动终端再验证。细节都在权限和路径上和工具本身无关。结尾一周用下来我的结论很明确WorkBuddy不是Codex的简单仿品它更像是一个把“模型自由”和“技能沉淀”当成核心的Agent工作台。Codex的优点是开箱即用、体验顺滑但封闭的模型体系让它在进阶场景里显得束手束脚WorkBuddy的迁移成本更高可一旦把Skill、模型、知识库全部配置到位它提供的灵活度和掌控感是Codex给不了的。最后再分享一个小技巧给Agent留一个fallback模型。我在配置里把默认模型设为DeepSeek通用模型一旦遇到推理超额或服务波动就临时切回备用模型继续完成任务。这个兜底方案看起来简单但真实开发中经常因为一条链路不可用就卡住整个下午。先把配置写好比事后再手忙脚乱强得多。