用了一周 WorkBuddy最大的感受就是早该转了。我之前是 Codex 的深度用户前后折腾了一个多月经历了安装失败、登录回环、模型不认、连接反复重连平均每天能稳定干活的时间真的不到一半。后来一咬牙切到 WorkBuddy才把整个 AI 编程工作流顺下来。这篇文章不吹不黑把我从 Codex 迁移到 WorkBuddy 的完整过程、踩过的坑、配置细节和一周实战体验全部写出来适合正在纠结换工具、或者被 Codex 各种报错折磨到崩溃的开发者参考。1. 先说为什么要从 Codex 换到 WorkBuddy1.1 我在 Codex 上遇到的几个真实瓶颈先说清楚我不是 Codex 黑粉。Codex 刚出来的时候我用得很兴奋毕竟在终端里用自然语言直接驱动编码这种体验确实很爽。但用着用着就发现问题了而且基本都是绕不过去的问题。第一个是安装环节。我最早是在 Windows 上装的 Codex下载安装包之后卡在某个初始化步骤进度条走到一半就停了提示“Windows 安装未完成”。试过重新下载、清理缓存、以管理员身份运行问题依旧。后来在社区里看到有人说是安装器对某些系统环境变量处理有问题但我按网上教的方法改了 PATH 和用户目录之后依然不稳定装完经常打不开。第二个是登录问题。Codex 的认证流程跟其他工具不太一样登录之后会反复跳回登录页有时候明明显示“已登录”一发请求就告诉你未授权。我试过重新登录、删配置目录、换网络环境最多只能在某个时间段内保持正常过不了多久又开始抽风。最夸张的一次我下午刚搞定睡个午觉起来再打开又回到了“登录已过期”的状态那感觉真是够崩溃的。第三个是模型兼容性问题。我当时为了省成本想把 Codex 接到 DeepSeek 或者其他兼容 OpenAI 协议的模型上结果 Codex 有自己的模型白名单不是它认识的模型名直接报错。我记得最清楚的一条错误是the gpt-5.6-sol model is not supported when using codex with a...。我配置了 base_url 指向 DeepSeek 的接口也填了正确的 key但就因为模型名不在 Codex 的默认支持列表里整条链路直接断掉。社区里有人教了各种绕过方法又是改环境变量又是改配置文件的折腾一圈稳定性还是看运气。第四个是网络稳定性问题。我用 Codex 的时候经常遇到“正在重新连接”的提示尤其是跑长任务的时候稍微等久一点连接就断了。更麻烦的是我尝试用 CC Switch 这类工具做多 provider 切换时经常报cc switch local proxy failed while handling codex endpoint /responses。这个报错的意思是说CC Switch 在处理 Codex 的/responses端点请求时本地转发服务没有正常启动或者返回异常。这个问题排查了很久最后发现是 Codex 官方的 responses API 和第三方模型的兼容度不够本地转发层根本处理不了某些请求格式。这些问题的本质在于Codex 本身是一个绑定自家服务的官方 CLI我硬要把它当成通用网关来用等于是在一个封闭系统上做各种逆向集成不稳定是必然的。1.2 同赛道选手对比Claude Code、CodeBuddy、豆包为什么是 WorkBuddy在决定换掉 Codex 之后我其实先把市面上的同类工具都看了一遍包括 Claude Code、CodeBuddy、豆包还有一些小众的工作台工具最终才锁定 WorkBuddy。这里把我的对比逻辑写一下大家可以根据自己的情况判断。先说 Claude Code。Claude Code 在代码能力上确实强尤其是在复杂业务逻辑的理解和长文件的编辑上表现比 Codex 还稳。但问题也很明显它默认也是绑定自家 Claude 模型的虽然支持改配置接第三方模型但稳定性同样依赖 API 兼容层。另外 Claude Code 的授权和订阅成本不低对于我这种个人开发者来说长期使用的经济压力比较大。再说 CodeBuddy。CodeBuddy 的定位和 WorkBuddy 有重叠都是做 AI 编程工作台但我在实际体验中感觉 CodeBuddy 更偏 IDE 插件方向和我的终端工作流不太契合。我习惯的是在命令行的自由操作而不是在编辑器里被各种面板框住。豆包我也试过。豆包的优势是免费额度大、上手门槛低日常问答和简单脚本生成完全够用。但一旦涉及多步骤的编码任务上下文长了之后豆包的输出稳定性和代码质量会明显下降而且它的自定义能力和插件生态比较弱不适合作为主力工具。最后对比下来WorkBuddy 胜出的核心原因有几个。第一它的模型接入是开放的任何 OpenAI 兼容接口都能配置DeepSeek、通义、本地模型都能直接接不用像 Codex 那样死磕白名单。第二它有完整的 Skill 体系可以定义自己的工具链和指令模板这个对效率的提升是革命性的。第三它支持 Obsidian 知识库联动这意味着我可以把积累的 markdown 笔记直接变成 AI 的上下文。第四它有 Linux 和 Windows 桌面版本跨平台体验一致不像 Codex 在 Windows 上安装那么费劲。对比项CodexClaude CodeCodeBuddy豆包WorkBuddy模型接入灵活性低白名单限制中需配置中低高OpenAI 兼容全支持安装难度中高Windows 易失败中低低低全平台Skill 扩展弱中中弱强有 Skill Hub知识库联动无弱弱无支持 Obsidian成本控制高高中低中可接廉价模型稳定性中高但封闭中中高2. WorkBuddy 安装与首次配置从零到能跑2.1 安装环节Windows / Linux 实测WorkBuddy 的安装比 Codex 顺利太多了。我第一台设备是 Windows 笔记本直接从官网下了 Windows 桌面版安装包双击之后一路 Next 就装完了没有出现 Codex 那种“安装未完成”的诡异问题。整个安装包大概几百 MB包含运行环境、内置模型管理器和工作台界面不需要额外装依赖对新手友好不少。这里有一个细节我第一次下载的是默认版本后来发现官网还提供国际版。简单说国际版在功能更新上更快有些新出的 Skill 和模型配置模板会更早推送。如果你习惯用英文界面或者想最早体验新功能可以直接选国际版如果只想稳定用默认版本完全够了。Linux 版本我也装了用来跑一些自动化任务。它的 Linux 版是一个压缩包解压就能运行不像某些工具需要自己配置一堆编译环境。我是在 Ubuntu 22.04 上测试的解压之后进入目录运行启动脚本就起来了。唯一要注意的是如果你的系统缺少某些图形库启动时可能会有警告但只要你是通过 CLI 方式调用完全不影响使用。安装完成之后第一次打开 WorkBuddy 工作台界面逻辑比 Codex 清晰很多。左侧是项目列表中间是会话窗口右侧是 Skill 和文件树顶栏能直接切换模型供应商。我开始还担心这种图形化界面会不会限制终端用户的自由度实际用下来发现它的命令行模式完全保留工作台只是一个更直观的控制面板。喜欢干净的人可以直接用纯命令行模式喜欢可视化的人可以留在工作台里。2.2 关键配置接入 DeepSeek 与模型路由安装完成以后最重要的一步就是配模型。WorkBuddy 的配置逻辑跟 Codex 最大的不同在于它默认就支持多供应商不需要你改什么玄学配置。我第一个接入的是 DeepSeek毕竟综合性价比确实能打。步骤非常简单在设置里找到“模型供应商”点新增选择 OpenAI 兼容接口然后填三样东西接口地址、API Key、模型名称。接口地址填 DeepSeek 的官方 OpenAI 兼容地址模型名填deepseek-chat或者你实际使用的模型名保存之后就能直接对话。整个配置过程大概一分钟全程没有遇到 Codex 那种模型白名单报错。后来我又把本地模型也接进去了。WorkBuddy 对本地模型的支持是通过兼容 OpenAI 协议的本地服务实现的你只要确保本地服务的地址能被访问到然后在供应商列表里填上对应的 base_url 和模型名即可。我实测下来本地模型在代码补全和简单重构任务上响应够快但复杂逻辑生成还是云端模型更强。所以我的策略是简单任务走本地模型复杂任务走 DeepSeek在 WorkBuddy 里切换供应商只需要在顶栏下拉框点一下不像之前用 CC Switch 那么折腾。2.3 第一次打开 WorkBuddy 工作台配好模型之后我花了一点时间熟悉工作台的布局。左侧的项目面板可以导入本地代码目录WorkBuddy 会扫描项目结构并建立索引这样它回答问题时就能基于你的真实代码上下文。中间会话窗口的输入框有一个醒目的功能就是“任务模式”选择。你可以用普通问答模式也可以切换到“任务执行模式”在这个模式下 WorkBuddy 会自动分析你的需求拆解步骤然后逐个执行。这个模式是 WorkBuddy 和普通聊天工具拉开差距的核心功能后面我会详细讲。右侧的 Skill 面板一开始是空的只有几个内置的示例。我需要自己去 Skill Hub 里找或者自己写。这一步是学习成本最高的环节但一旦上手生产力提升非常明显。我是从官方示例开始看的花了一个小时弄懂了 Skill 的定义语法和调用逻辑然后把 Codex 时代那些用不上的 prompts 全部整理成了自己的 Skill。3. 一周实战我用 WorkBuddy 做了什么3.1 场景一日常编码任务切换后的第一天我直接拿一个老项目做测试任务是重构一个服务端的请求处理逻辑。这个项目是我写的一个内部工具代码比较乱以前用 Codex 处理这种重构任务最大的问题是它对项目整体结构的理解不够经常改一处漏三处。WorkBuddy 的做法不太一样。它在任务模式下会先扫描项目把入口文件、依赖关系、核心模块都过一遍然后生成一个修改计划最后再逐文件修改。我执行完一次重构它把主要逻辑拆分成了三个独立模块并且没有破坏原有接口。我检查了一遍改动基本可以直接合入。更让我惊喜的是它对长文件的操作能力。之前 Codex 处理超过一千行的文件时会变得迟钝甚至会出现只改开头不改正文的问题。WorkBuddy 在这个场景下表现稳定可能是因为它在模型层之上增加了上下文压缩和分段处理机制把长文件拆成了可控的片段然后按顺序处理。实测下来一个八百行的文件让它加一个功能模块它能在一次任务里完成没有漏改。3.2 场景二Skill Hub 与自定义指令WorkBuddy 的 Skill 体系是我认为它最值钱的功能。所谓 Skill就是一组定义好的指令模板和工具调用逻辑。比如我写了一个“代码审查 Skill”只要我输入/review它就会自动加载项目里的所有改动文件按规范检查代码风格、潜在 bug、安全性问题然后输出一份结构化审查报告。我在 Skill Hub 上还找到了一些别人分享的高质量 Skill比如“数据库迁移生成器”、“测试用例生成器”、“Git 提交信息生成器”。这些 Skill 省去了我大量重复写 prompt 的时间。自定义指令的语法也很简单本质上是一个 markdown 文件包含触发词、描述、指令正文和参数定义。我自己写了一个“接口文档生成”的 Skill核心就是让模型读取 controller 文件解析路由和参数输出 OpenAPI 格式的文档。这个 Skill 在以前要反复用一大段规范提示词去约束模型现在一条命令搞定而且每次的格式都高度一致。3.3 场景三Obsidian 知识库联动我长期用 Obsidian 做技术笔记积累了上千条 markdown 文档。以前这些笔记和 AI 工具是割裂的我需要手动把笔记内容粘到对话窗口里效率很低。WorkBuddy 的 Obsidian 联动功能解决了我最大的痛点。配置方式很直接在 WorkBuddy 里指定 Obsidian 的 vault 目录它就能读取里面的所有笔记。我在任务模式下提问时可以要求它“先阅读知识库中关于数据库分库分表的笔记再根据我当前的表结构给出建议”。它会自动检索相关的笔记提取内容和当前项目上下文融合然后给出回答。这个功能对我的价值在于我不用再让模型“凭空创造”了。以前 AI 给的建议经常是通用答案但结合了我自己的笔记和实际项目数据之后它给出的方案更贴合我的历史决策和偏好。3.4 场景四用 WorkBuddy 做一个小软件为了测试 WorkBuddy 的完整能力我这一周还做了一个小的命令行工具用来批量处理本地图片的压缩和格式转换。整个需求是我用自然语言描述的说了功能点、输入输出格式和一些细节要求。WorkBuddy 在任务模式下自动完成了项目初始化、依赖选择、核心逻辑编写、CLI 参数解析、错误处理、README 文档生成。整个过程我介入的次数很少只在它选择图像处理库的时候我确认了一下。从零到可运行的成程序大约花了四十分钟这要是在以前我至少得花半天。当然它生成的第一版代码不是完美的在处理超大图片时内存占用量偏高我指出了这个问题它在一次对话里就定位到了原因并改成流式处理然后提供了一个对比测试结果。这种“发现问题-修改-验证”的闭环在 WorkBuddy 里跑得很顺因为它有足够的上下文来记忆我之前提出的所有约束。4. 深度体验WorkBuddy 比 Codex 好在哪又缺什么4.1 任务记忆与上下文管理WorkBuddy 在会话管理上的设计值得单独说说。Codex 的会话开多了之后很容易把上下文搞混有时下一条命令会莫名地引用上一条任务的内容。WorkBuddy 则把每个任务隔离在独立的会话里并且允许我在任务中途把当前上下文“钉住”然后切换到另一个任务再切回来时之前的上下文还在。这一点在实际工作中非常有用。我经常同时处理两三个模块一会儿改前端一会儿调后端。在 Codex 里我只能开两个终端窗口分别跑还容易互相干扰在 WorkBuddy 里我可以直接在同一个窗口下切任务它能够记住每个任务的进度和约束条件不会串味。另一个让我满意的点是它支持“项目级记忆”。也就是说我在之前的会话里对项目做过的决策在之后的会话中依然能生效。比如我第一天告诉它“返回格式统一为 JSON错误码前缀用 APP_”第二天新开会话继续开发它仍然记得这些规则。这种能力不是靠无限扩大上下文实现的而是在底层把关键决策提取出来存储到了项目知识库中。4.2 模型兼容性与供应商切换在模型兼容性上WorkBuddy 确实是目前我用过的工具里最开放的。它把模型抽象成统一的接口不管你在后面放的是 DeepSeek、智谱、本地 Llama 还是 OpenAI 官方模型它都能以一致的协议来调用。这意味着我可以按任务特征选择最合适的模型而不是被工具绑定到单一模型上。供应商切换的体验也比 CC Switch 那种第三方工具稳定得多。CC Switch 本质上是一个把供应商信息写入 Codex 配置的脚本它对 Codex 原生模型的支持尚可但一旦涉及/responses端点这类底层协议差异就容易出现cc switch local proxy failed while handling codex endpoint /responses这样的报错。WorkBuddy 没有这个问题因为它的请求层本身就是按 OpenAI 兼容协议设计的不存在官方客户端和第三方网关之间的协议拉扯。4.3 目前还存在的短板虽然这一周用下来整体很满意但 WorkBuddy 也有一些明显的短板我实话实说不吹不黑。首先是 Skill 社区的内容质量参差不齐。Skill Hub 里虽然有不少人分享但很多是简单的 prompt 套壳离真正可复用的工作流还差得远。我下载过的十个 Skill 里真正能直接用的大概只有一半其他的都需要我自己改。其次是它在某些极端复杂的代码推理任务上输出的逻辑严谨性还是不如 Claude Code。我做过一次比较复杂的算法迁移测试WorkBuddy 生成的版本能跑但边界条件处理得不够细致Claude 在这类问题上确实更老练。但是由于我可以随时切换供应商这个问题并不致命需要严谨推理时就临时切到更聪明的模型。还有一个问题是桌面应用的内存占用偏高。开着工作台再开一个项目的本地索引再加上 IDE我这台 16G 内存的笔记本已经有点吃力了。如果项目特别大建议只让 WorkBuddy 索引关键目录不要全盘扫描。5. 常见问题与排查技巧实录5.1 Codex 端常见报错速查表这一周我在迁移过程中也帮朋友处理过一些 Codex 报错索性把最常遇到的问题整理成速查表给还在 Codex 上挣扎的朋友一个参考。报错 / 现象常见原因快速处理思路Windows 安装未完成系统环境变量或安装器权限问题以管理员身份安装清理%USERPROFILE%\.codex残留目录后重试登录后反复退出认证令牌本地存储失效删除本地配置目录后重新登录或者重置密码后重试codex 打不开 / 启动卡死网络连接异常或配置目录损坏备份后删除.codex配置重新初始化正在重新连接请求超时或长任务断开缩短单次输入长度开启断点续跑功能model is not supported模型名不在白名单换官方支持模型或改用兼容层工具cc switch local proxy failed while handling codex endpoint /responses第三方网关与官方端点协议不兼容更新 CC Switch 到最新版本或直接换原生兼容的工具5.2 WorkBuddy 使用中的几个典型问题WorkBuddy 虽然整体稳定但也有几个使用中容易踩的坑。第一个是接入自定义模型时报连接超时或者 401 错误。这个问题大多数时候不是 WorkBuddy 的问题而是你填的接口地址或密钥不对。我建议在接入任何模型前先用 curl 手动请求一次接口地址确认能拿到正常返回再去 WorkBuddy 里填配置。这样排查起来快很多。第二个是 Obsidian 扫描不到笔记。如果你把 vault 配到了一个子目录而 WorkBuddy 的索引服务和 Obsidian 的同步锁冲突会出现读不到内容的情况。解决办法是把配置指向 vault 的根目录并且在 Obsidian 里关闭“只使用第三方编辑器打开”的选项让 WorkBuddy 能正常读取文件。第三个是任务模式的步骤卡住。有时候模型会在中间等待某个工具的返回而你又没有给工具授权任务就卡在那里不动。这时候大概率是工具权限问题去权限设置里看看是否拒绝了某个工具调用允许之后重新运行任务即可。5.3 独家避坑技巧最后分享几个我这一周沉淀下来的实操技巧这些是从官方文档里学不到的。第一个技巧刚开始用 WorkBuddy 时不要贪多先只接一个供应商、只学一个核心 Skill跑通一个小项目。我一开始想着把所有模型都接好把十几个 Skill 全装上结果反而不知道重心在哪里。后来收敛下来专注用 DeepSeek 跑日常编码只维护三个核心 Skill效率反而直线上升。先把主干跑顺再慢慢加东西。第二个技巧对于复杂的项目建议在 WorkBuddy 里建立一个“项目规范”文档把代码风格、目录结构、命名规则、接口约定都写进去然后在配置里把这个文档指定为核心上下文。这样不管新建多少个会话WorkBuddy 都会先读这个规范输出的一致性会提升很多。我在 Codex 时代没有这种概念到了 WorkBuddy 才体会到“让 AI 先懂规矩再干活”的威力。第三个技巧遇到长任务时把大目标拆成小步骤比让它一步到位稳定得多。我一开始尝试让它“帮我给整个项目加测试”结果它跑了一半就绕进了细节里。后来我改成先让它分析测试覆盖率再生成测试计划然后逐步实现每个模块的测试整个过程顺利了很多。使用 AI 工具时拆解粒度直接影响成率这个习惯在任何工具上都适用。我个人在实际操作中的体会是工具迁移的收益不在于换了一个更炫酷的界面而在于它是否解决了你工作流中的真实阻塞点。Codex 不是不好它只是太封闭、太依赖官方生态对想要自由配置模型的开发者来说限制太多了。WorkBuddy 这一周让我把精力从“修连接、调配置”重新拉回到了“写代码、做设计”上单凭这一点这次转战就是值得的。最后再分享一个小技巧无论你用哪款工具记得把常用指令沉淀成自己的可复用资产这才是 AI 编程时代真正属于你的竞争力。
从Codex到WorkBuddy：AI编程工作流迁移实战与避坑指南
用了一周 WorkBuddy最大的感受就是早该转了。我之前是 Codex 的深度用户前后折腾了一个多月经历了安装失败、登录回环、模型不认、连接反复重连平均每天能稳定干活的时间真的不到一半。后来一咬牙切到 WorkBuddy才把整个 AI 编程工作流顺下来。这篇文章不吹不黑把我从 Codex 迁移到 WorkBuddy 的完整过程、踩过的坑、配置细节和一周实战体验全部写出来适合正在纠结换工具、或者被 Codex 各种报错折磨到崩溃的开发者参考。1. 先说为什么要从 Codex 换到 WorkBuddy1.1 我在 Codex 上遇到的几个真实瓶颈先说清楚我不是 Codex 黑粉。Codex 刚出来的时候我用得很兴奋毕竟在终端里用自然语言直接驱动编码这种体验确实很爽。但用着用着就发现问题了而且基本都是绕不过去的问题。第一个是安装环节。我最早是在 Windows 上装的 Codex下载安装包之后卡在某个初始化步骤进度条走到一半就停了提示“Windows 安装未完成”。试过重新下载、清理缓存、以管理员身份运行问题依旧。后来在社区里看到有人说是安装器对某些系统环境变量处理有问题但我按网上教的方法改了 PATH 和用户目录之后依然不稳定装完经常打不开。第二个是登录问题。Codex 的认证流程跟其他工具不太一样登录之后会反复跳回登录页有时候明明显示“已登录”一发请求就告诉你未授权。我试过重新登录、删配置目录、换网络环境最多只能在某个时间段内保持正常过不了多久又开始抽风。最夸张的一次我下午刚搞定睡个午觉起来再打开又回到了“登录已过期”的状态那感觉真是够崩溃的。第三个是模型兼容性问题。我当时为了省成本想把 Codex 接到 DeepSeek 或者其他兼容 OpenAI 协议的模型上结果 Codex 有自己的模型白名单不是它认识的模型名直接报错。我记得最清楚的一条错误是the gpt-5.6-sol model is not supported when using codex with a...。我配置了 base_url 指向 DeepSeek 的接口也填了正确的 key但就因为模型名不在 Codex 的默认支持列表里整条链路直接断掉。社区里有人教了各种绕过方法又是改环境变量又是改配置文件的折腾一圈稳定性还是看运气。第四个是网络稳定性问题。我用 Codex 的时候经常遇到“正在重新连接”的提示尤其是跑长任务的时候稍微等久一点连接就断了。更麻烦的是我尝试用 CC Switch 这类工具做多 provider 切换时经常报cc switch local proxy failed while handling codex endpoint /responses。这个报错的意思是说CC Switch 在处理 Codex 的/responses端点请求时本地转发服务没有正常启动或者返回异常。这个问题排查了很久最后发现是 Codex 官方的 responses API 和第三方模型的兼容度不够本地转发层根本处理不了某些请求格式。这些问题的本质在于Codex 本身是一个绑定自家服务的官方 CLI我硬要把它当成通用网关来用等于是在一个封闭系统上做各种逆向集成不稳定是必然的。1.2 同赛道选手对比Claude Code、CodeBuddy、豆包为什么是 WorkBuddy在决定换掉 Codex 之后我其实先把市面上的同类工具都看了一遍包括 Claude Code、CodeBuddy、豆包还有一些小众的工作台工具最终才锁定 WorkBuddy。这里把我的对比逻辑写一下大家可以根据自己的情况判断。先说 Claude Code。Claude Code 在代码能力上确实强尤其是在复杂业务逻辑的理解和长文件的编辑上表现比 Codex 还稳。但问题也很明显它默认也是绑定自家 Claude 模型的虽然支持改配置接第三方模型但稳定性同样依赖 API 兼容层。另外 Claude Code 的授权和订阅成本不低对于我这种个人开发者来说长期使用的经济压力比较大。再说 CodeBuddy。CodeBuddy 的定位和 WorkBuddy 有重叠都是做 AI 编程工作台但我在实际体验中感觉 CodeBuddy 更偏 IDE 插件方向和我的终端工作流不太契合。我习惯的是在命令行的自由操作而不是在编辑器里被各种面板框住。豆包我也试过。豆包的优势是免费额度大、上手门槛低日常问答和简单脚本生成完全够用。但一旦涉及多步骤的编码任务上下文长了之后豆包的输出稳定性和代码质量会明显下降而且它的自定义能力和插件生态比较弱不适合作为主力工具。最后对比下来WorkBuddy 胜出的核心原因有几个。第一它的模型接入是开放的任何 OpenAI 兼容接口都能配置DeepSeek、通义、本地模型都能直接接不用像 Codex 那样死磕白名单。第二它有完整的 Skill 体系可以定义自己的工具链和指令模板这个对效率的提升是革命性的。第三它支持 Obsidian 知识库联动这意味着我可以把积累的 markdown 笔记直接变成 AI 的上下文。第四它有 Linux 和 Windows 桌面版本跨平台体验一致不像 Codex 在 Windows 上安装那么费劲。对比项CodexClaude CodeCodeBuddy豆包WorkBuddy模型接入灵活性低白名单限制中需配置中低高OpenAI 兼容全支持安装难度中高Windows 易失败中低低低全平台Skill 扩展弱中中弱强有 Skill Hub知识库联动无弱弱无支持 Obsidian成本控制高高中低中可接廉价模型稳定性中高但封闭中中高2. WorkBuddy 安装与首次配置从零到能跑2.1 安装环节Windows / Linux 实测WorkBuddy 的安装比 Codex 顺利太多了。我第一台设备是 Windows 笔记本直接从官网下了 Windows 桌面版安装包双击之后一路 Next 就装完了没有出现 Codex 那种“安装未完成”的诡异问题。整个安装包大概几百 MB包含运行环境、内置模型管理器和工作台界面不需要额外装依赖对新手友好不少。这里有一个细节我第一次下载的是默认版本后来发现官网还提供国际版。简单说国际版在功能更新上更快有些新出的 Skill 和模型配置模板会更早推送。如果你习惯用英文界面或者想最早体验新功能可以直接选国际版如果只想稳定用默认版本完全够了。Linux 版本我也装了用来跑一些自动化任务。它的 Linux 版是一个压缩包解压就能运行不像某些工具需要自己配置一堆编译环境。我是在 Ubuntu 22.04 上测试的解压之后进入目录运行启动脚本就起来了。唯一要注意的是如果你的系统缺少某些图形库启动时可能会有警告但只要你是通过 CLI 方式调用完全不影响使用。安装完成之后第一次打开 WorkBuddy 工作台界面逻辑比 Codex 清晰很多。左侧是项目列表中间是会话窗口右侧是 Skill 和文件树顶栏能直接切换模型供应商。我开始还担心这种图形化界面会不会限制终端用户的自由度实际用下来发现它的命令行模式完全保留工作台只是一个更直观的控制面板。喜欢干净的人可以直接用纯命令行模式喜欢可视化的人可以留在工作台里。2.2 关键配置接入 DeepSeek 与模型路由安装完成以后最重要的一步就是配模型。WorkBuddy 的配置逻辑跟 Codex 最大的不同在于它默认就支持多供应商不需要你改什么玄学配置。我第一个接入的是 DeepSeek毕竟综合性价比确实能打。步骤非常简单在设置里找到“模型供应商”点新增选择 OpenAI 兼容接口然后填三样东西接口地址、API Key、模型名称。接口地址填 DeepSeek 的官方 OpenAI 兼容地址模型名填deepseek-chat或者你实际使用的模型名保存之后就能直接对话。整个配置过程大概一分钟全程没有遇到 Codex 那种模型白名单报错。后来我又把本地模型也接进去了。WorkBuddy 对本地模型的支持是通过兼容 OpenAI 协议的本地服务实现的你只要确保本地服务的地址能被访问到然后在供应商列表里填上对应的 base_url 和模型名即可。我实测下来本地模型在代码补全和简单重构任务上响应够快但复杂逻辑生成还是云端模型更强。所以我的策略是简单任务走本地模型复杂任务走 DeepSeek在 WorkBuddy 里切换供应商只需要在顶栏下拉框点一下不像之前用 CC Switch 那么折腾。2.3 第一次打开 WorkBuddy 工作台配好模型之后我花了一点时间熟悉工作台的布局。左侧的项目面板可以导入本地代码目录WorkBuddy 会扫描项目结构并建立索引这样它回答问题时就能基于你的真实代码上下文。中间会话窗口的输入框有一个醒目的功能就是“任务模式”选择。你可以用普通问答模式也可以切换到“任务执行模式”在这个模式下 WorkBuddy 会自动分析你的需求拆解步骤然后逐个执行。这个模式是 WorkBuddy 和普通聊天工具拉开差距的核心功能后面我会详细讲。右侧的 Skill 面板一开始是空的只有几个内置的示例。我需要自己去 Skill Hub 里找或者自己写。这一步是学习成本最高的环节但一旦上手生产力提升非常明显。我是从官方示例开始看的花了一个小时弄懂了 Skill 的定义语法和调用逻辑然后把 Codex 时代那些用不上的 prompts 全部整理成了自己的 Skill。3. 一周实战我用 WorkBuddy 做了什么3.1 场景一日常编码任务切换后的第一天我直接拿一个老项目做测试任务是重构一个服务端的请求处理逻辑。这个项目是我写的一个内部工具代码比较乱以前用 Codex 处理这种重构任务最大的问题是它对项目整体结构的理解不够经常改一处漏三处。WorkBuddy 的做法不太一样。它在任务模式下会先扫描项目把入口文件、依赖关系、核心模块都过一遍然后生成一个修改计划最后再逐文件修改。我执行完一次重构它把主要逻辑拆分成了三个独立模块并且没有破坏原有接口。我检查了一遍改动基本可以直接合入。更让我惊喜的是它对长文件的操作能力。之前 Codex 处理超过一千行的文件时会变得迟钝甚至会出现只改开头不改正文的问题。WorkBuddy 在这个场景下表现稳定可能是因为它在模型层之上增加了上下文压缩和分段处理机制把长文件拆成了可控的片段然后按顺序处理。实测下来一个八百行的文件让它加一个功能模块它能在一次任务里完成没有漏改。3.2 场景二Skill Hub 与自定义指令WorkBuddy 的 Skill 体系是我认为它最值钱的功能。所谓 Skill就是一组定义好的指令模板和工具调用逻辑。比如我写了一个“代码审查 Skill”只要我输入/review它就会自动加载项目里的所有改动文件按规范检查代码风格、潜在 bug、安全性问题然后输出一份结构化审查报告。我在 Skill Hub 上还找到了一些别人分享的高质量 Skill比如“数据库迁移生成器”、“测试用例生成器”、“Git 提交信息生成器”。这些 Skill 省去了我大量重复写 prompt 的时间。自定义指令的语法也很简单本质上是一个 markdown 文件包含触发词、描述、指令正文和参数定义。我自己写了一个“接口文档生成”的 Skill核心就是让模型读取 controller 文件解析路由和参数输出 OpenAPI 格式的文档。这个 Skill 在以前要反复用一大段规范提示词去约束模型现在一条命令搞定而且每次的格式都高度一致。3.3 场景三Obsidian 知识库联动我长期用 Obsidian 做技术笔记积累了上千条 markdown 文档。以前这些笔记和 AI 工具是割裂的我需要手动把笔记内容粘到对话窗口里效率很低。WorkBuddy 的 Obsidian 联动功能解决了我最大的痛点。配置方式很直接在 WorkBuddy 里指定 Obsidian 的 vault 目录它就能读取里面的所有笔记。我在任务模式下提问时可以要求它“先阅读知识库中关于数据库分库分表的笔记再根据我当前的表结构给出建议”。它会自动检索相关的笔记提取内容和当前项目上下文融合然后给出回答。这个功能对我的价值在于我不用再让模型“凭空创造”了。以前 AI 给的建议经常是通用答案但结合了我自己的笔记和实际项目数据之后它给出的方案更贴合我的历史决策和偏好。3.4 场景四用 WorkBuddy 做一个小软件为了测试 WorkBuddy 的完整能力我这一周还做了一个小的命令行工具用来批量处理本地图片的压缩和格式转换。整个需求是我用自然语言描述的说了功能点、输入输出格式和一些细节要求。WorkBuddy 在任务模式下自动完成了项目初始化、依赖选择、核心逻辑编写、CLI 参数解析、错误处理、README 文档生成。整个过程我介入的次数很少只在它选择图像处理库的时候我确认了一下。从零到可运行的成程序大约花了四十分钟这要是在以前我至少得花半天。当然它生成的第一版代码不是完美的在处理超大图片时内存占用量偏高我指出了这个问题它在一次对话里就定位到了原因并改成流式处理然后提供了一个对比测试结果。这种“发现问题-修改-验证”的闭环在 WorkBuddy 里跑得很顺因为它有足够的上下文来记忆我之前提出的所有约束。4. 深度体验WorkBuddy 比 Codex 好在哪又缺什么4.1 任务记忆与上下文管理WorkBuddy 在会话管理上的设计值得单独说说。Codex 的会话开多了之后很容易把上下文搞混有时下一条命令会莫名地引用上一条任务的内容。WorkBuddy 则把每个任务隔离在独立的会话里并且允许我在任务中途把当前上下文“钉住”然后切换到另一个任务再切回来时之前的上下文还在。这一点在实际工作中非常有用。我经常同时处理两三个模块一会儿改前端一会儿调后端。在 Codex 里我只能开两个终端窗口分别跑还容易互相干扰在 WorkBuddy 里我可以直接在同一个窗口下切任务它能够记住每个任务的进度和约束条件不会串味。另一个让我满意的点是它支持“项目级记忆”。也就是说我在之前的会话里对项目做过的决策在之后的会话中依然能生效。比如我第一天告诉它“返回格式统一为 JSON错误码前缀用 APP_”第二天新开会话继续开发它仍然记得这些规则。这种能力不是靠无限扩大上下文实现的而是在底层把关键决策提取出来存储到了项目知识库中。4.2 模型兼容性与供应商切换在模型兼容性上WorkBuddy 确实是目前我用过的工具里最开放的。它把模型抽象成统一的接口不管你在后面放的是 DeepSeek、智谱、本地 Llama 还是 OpenAI 官方模型它都能以一致的协议来调用。这意味着我可以按任务特征选择最合适的模型而不是被工具绑定到单一模型上。供应商切换的体验也比 CC Switch 那种第三方工具稳定得多。CC Switch 本质上是一个把供应商信息写入 Codex 配置的脚本它对 Codex 原生模型的支持尚可但一旦涉及/responses端点这类底层协议差异就容易出现cc switch local proxy failed while handling codex endpoint /responses这样的报错。WorkBuddy 没有这个问题因为它的请求层本身就是按 OpenAI 兼容协议设计的不存在官方客户端和第三方网关之间的协议拉扯。4.3 目前还存在的短板虽然这一周用下来整体很满意但 WorkBuddy 也有一些明显的短板我实话实说不吹不黑。首先是 Skill 社区的内容质量参差不齐。Skill Hub 里虽然有不少人分享但很多是简单的 prompt 套壳离真正可复用的工作流还差得远。我下载过的十个 Skill 里真正能直接用的大概只有一半其他的都需要我自己改。其次是它在某些极端复杂的代码推理任务上输出的逻辑严谨性还是不如 Claude Code。我做过一次比较复杂的算法迁移测试WorkBuddy 生成的版本能跑但边界条件处理得不够细致Claude 在这类问题上确实更老练。但是由于我可以随时切换供应商这个问题并不致命需要严谨推理时就临时切到更聪明的模型。还有一个问题是桌面应用的内存占用偏高。开着工作台再开一个项目的本地索引再加上 IDE我这台 16G 内存的笔记本已经有点吃力了。如果项目特别大建议只让 WorkBuddy 索引关键目录不要全盘扫描。5. 常见问题与排查技巧实录5.1 Codex 端常见报错速查表这一周我在迁移过程中也帮朋友处理过一些 Codex 报错索性把最常遇到的问题整理成速查表给还在 Codex 上挣扎的朋友一个参考。报错 / 现象常见原因快速处理思路Windows 安装未完成系统环境变量或安装器权限问题以管理员身份安装清理%USERPROFILE%\.codex残留目录后重试登录后反复退出认证令牌本地存储失效删除本地配置目录后重新登录或者重置密码后重试codex 打不开 / 启动卡死网络连接异常或配置目录损坏备份后删除.codex配置重新初始化正在重新连接请求超时或长任务断开缩短单次输入长度开启断点续跑功能model is not supported模型名不在白名单换官方支持模型或改用兼容层工具cc switch local proxy failed while handling codex endpoint /responses第三方网关与官方端点协议不兼容更新 CC Switch 到最新版本或直接换原生兼容的工具5.2 WorkBuddy 使用中的几个典型问题WorkBuddy 虽然整体稳定但也有几个使用中容易踩的坑。第一个是接入自定义模型时报连接超时或者 401 错误。这个问题大多数时候不是 WorkBuddy 的问题而是你填的接口地址或密钥不对。我建议在接入任何模型前先用 curl 手动请求一次接口地址确认能拿到正常返回再去 WorkBuddy 里填配置。这样排查起来快很多。第二个是 Obsidian 扫描不到笔记。如果你把 vault 配到了一个子目录而 WorkBuddy 的索引服务和 Obsidian 的同步锁冲突会出现读不到内容的情况。解决办法是把配置指向 vault 的根目录并且在 Obsidian 里关闭“只使用第三方编辑器打开”的选项让 WorkBuddy 能正常读取文件。第三个是任务模式的步骤卡住。有时候模型会在中间等待某个工具的返回而你又没有给工具授权任务就卡在那里不动。这时候大概率是工具权限问题去权限设置里看看是否拒绝了某个工具调用允许之后重新运行任务即可。5.3 独家避坑技巧最后分享几个我这一周沉淀下来的实操技巧这些是从官方文档里学不到的。第一个技巧刚开始用 WorkBuddy 时不要贪多先只接一个供应商、只学一个核心 Skill跑通一个小项目。我一开始想着把所有模型都接好把十几个 Skill 全装上结果反而不知道重心在哪里。后来收敛下来专注用 DeepSeek 跑日常编码只维护三个核心 Skill效率反而直线上升。先把主干跑顺再慢慢加东西。第二个技巧对于复杂的项目建议在 WorkBuddy 里建立一个“项目规范”文档把代码风格、目录结构、命名规则、接口约定都写进去然后在配置里把这个文档指定为核心上下文。这样不管新建多少个会话WorkBuddy 都会先读这个规范输出的一致性会提升很多。我在 Codex 时代没有这种概念到了 WorkBuddy 才体会到“让 AI 先懂规矩再干活”的威力。第三个技巧遇到长任务时把大目标拆成小步骤比让它一步到位稳定得多。我一开始尝试让它“帮我给整个项目加测试”结果它跑了一半就绕进了细节里。后来我改成先让它分析测试覆盖率再生成测试计划然后逐步实现每个模块的测试整个过程顺利了很多。使用 AI 工具时拆解粒度直接影响成率这个习惯在任何工具上都适用。我个人在实际操作中的体会是工具迁移的收益不在于换了一个更炫酷的界面而在于它是否解决了你工作流中的真实阻塞点。Codex 不是不好它只是太封闭、太依赖官方生态对想要自由配置模型的开发者来说限制太多了。WorkBuddy 这一周让我把精力从“修连接、调配置”重新拉回到了“写代码、做设计”上单凭这一点这次转战就是值得的。最后再分享一个小技巧无论你用哪款工具记得把常用指令沉淀成自己的可复用资产这才是 AI 编程时代真正属于你的竞争力。
