写下这篇的时候我正好把主力AI编程助手从codex切到workbuddy满一周。这一周里我顶着各种习惯上的不适应把codex之前拖了我很久的几个痛点挨个验证了一遍也把workbuddy的安装、模型接入、skill配置、自定义指令这些核心功能从头到尾撸了一遍。结论先放在前面如果你只想要一个能对话、能改代码的命令行助手codex依然很顺手但如果你需要的是一套能自由接模型、能定制流程、能长期沉淀自己工作方式的AI工作台workbuddy的底子明显更厚。这篇就聊聊我为什么转workbuddy到底是个什么东西以及这一周我实际跑通的完整流程和踩过的坑。想直接抄作业的重点看第三部分和第五部分。1. 从codex转到workbuddy我的真实理由和踩坑起点1.1 codex让我上头的三个瞬间先说公道话codex不是不好用。我刚接触codex的时候确实有几次被它惊艳到。最典型的场景是我随手写了一句“把项目里所有没用到的import清理掉”它能自己翻遍整个src目录逐个文件分析依赖关系然后动手改代码最后还能跑一遍测试给我看结果。这种“理解项目结构—主动执行—汇报结果”的连贯体验确实让我觉得AI编程助手已经进化到了新阶段。第二个让我上头的地方是它的上下文管理能力。codex对当前工作区的上下文感知做得很细它知道哪些文件是核心业务哪些只是配置文件。你在对话里让它“改一下用户登录的逻辑”它会自己找到对应的service层和controller层而不是像早期工具那样问东问西或者随便改错地方。第三个是它的纯命令行交互姿态。对一个常年泡在终端里的人来讲不用开IDE不用切窗口在终端里就能完成从需求到代码的全流程这种效率感是实打实的。1.2 真正劝退我的其实是这几件事但用久了问题就开始浮出来了。第一个让我烦的是安装这件事本身就折腾。我身边几个同事在Windows上装codex都遇到过安装进行到一半卡住、反复提示安装未完成的情况。我自己虽然没有卡在安装但启动时频繁遇到“正在重新连接”的状态经常打开就转圈严重的时候得反复重启进程才能恢复到可交互状态。第二个劝退点是它对本地链路的稳定性要求比较高。codex在调用远端模型的时候对本地网络和端点的切换很敏感。我试过在公司和家里两个网络环境下切换使用偶尔会碰到切换本地端点失败的报错英文提示大致就是切换端点时出现了本地链路问题。这种报错一旦出现后面连续几次对话都会受影响得手动清理状态重新初始化挺影响节奏。第三个问题更本质codex的模型调用限制比较大。它会校验你当前使用的模型是否在允许列表里我中间想试着接入其他模型走通一些本地小任务结果直接提示“该模型在使用codex时不受支持”。这种封闭性让我觉得工具的上限被厂家锁死了我作为一个开发者反而没有多少选择权。还有一个细节codex的自定义能力偏弱。它虽然有system prompt之类的基础设置项但想要做一套符合我个人工作习惯的指令集每次都感觉很别扭——不是字段不够用就是格式限制太死。慢慢地我从“想要一个AI帮我写代码”变成了“想要一个我能完全掌控规则和模型的AI工作台”。于是我把目光转向了workbuddy。2. workbuddy是什么先搞清楚它和codex的根本区别2.1 一句话定位本地AI工作台而不只是一个编码代理如果非要用一句话概括我会说workbuddy是一个本地运行的、支持多模型接入的AI工作台。它和codex最大的区别在于codex更像一个内置了固定模型和固定规则的“编码代理”你喊它一声它帮你干活而workbuddy更像一间“工作室”模型可以自己接工具可以自己装行为规则可以自己定AI只是这个工作室里的执行单元。我用一个生活化类比来解释。codex好比你去一家餐厅点菜菜单是定好的你只能在厨师擅长的菜系里选。workbuddy则像是你租了一个厨房炉灶、锅碗瓢盆都是现成的食材模型可以按需采购做菜流程自定义指令和skill可以完全按你的习惯来。前者省心后者自由就看你更需要哪个。这种定位差异直接体现在日常使用上。用workbuddy的时候我可以同时配置多套模型环境比如日常任务走更经济的模型复杂代码生成走更强的模型场景切换就是改一个配置项的事。这正好回应了我用codex时最憋屈的那个点——模型不支持就是真的不能用没有绕的余地。2.2 核心机制拆解workbench、skill和自定义指令workbuddy有三个核心概念理解了这三个词基本就理解了整个工具的使用逻辑workbench工作台、skill技能包、自定义指令。workbench可以理解为一个独立的任务空间。每个workbench里可以配置自己需要的模型、指令集和上下文内容。比如我可以开一个“代码重构”的workbench专门放代码审查规则和重构偏好再开一个“内容批量处理”的workbench放文本处理的指令模板。切换工作台就是切换整套工作环境互不干扰。skill是workbuddy里最有特色的设计。它本质上是一个封装好的能力模块里面可以包含指令、参考文档、执行脚本等。官方有一个skillhub技能市场可以直接拉取别人写好的技能包也可以自己写skill放进去。这个设计让很多重复性的工作可以沉淀下来下次直接复用。自定义指令则更轻量适合放你不希望每次重复输入的规则比如“所有生成的代码都要带类型标注”“生成文件前先列出影响范围”等等。把这类偏好固化成指令以后AI每次执行任务的起点就不是一张白纸而是先遵循你的规则再动手。这三个层级组合起来workbuddy就从一个单纯的“对话机器”变成了一个可以不断自我演化的“工作系统”。这一点的感知用上一周之后会越来越明显。3. 一周实操全记录从安装、接deepseek到跑通完整工作流3.1 安装与初始化选择版本和完成首次启动先聊安装。workbuddy的安装过程整体比codex在Windows上的体验要顺不少。它提供了桌面版和命令行两种形态我自己用的是命令行为主因为更习惯终端工作流。官方也提供了Linux版本我在一台Ubuntu的机器上装了同样的环境跨平台的一致性做得还不错。安装后的初始化向导会要求你创建第一个workbench并选择默认连接的模型服务商。这里我强烈建议你不要跳过初始化的配置步骤因为它会把API接入格式、默认指令路径这些基础信息一次性写好后面再改反而多花时间。需要注意一点workbuddy对本地环境的依赖比较“整洁”它会在你的用户目录下建立独立的配置目录用来存放工作台配置、skill文件、日志等。这意味着迁移环境非常方便把那个配置目录打包带走到新机器上重新指定路径就能恢复整套环境。这个设计对经常换机器的人来说非常友好。3.2 把deepseek接进来API配置全流程我这一周的主要动力之一就是把deepseek接进workbuddy绕开codex的模型限制。这一步走通之后整个体验才真正打开。整体流程不复杂先在deepseek的开放平台拿到API Key然后在workbuddy里新增一个provider配置填上base endpoint和模型名再拉通测试一次就算完成。我贴一下我所用的配置片段字段名以实际版本为准但思路是一样的{ provider: deepseek, api_key_env: DEEPSEEK_API_KEY, base_url: https://api.deepseek.com, models: [deepseek-chat, deepseek-reasoner], default_model: deepseek-chat }这里我特别提醒三点。第一API Key不要直接写死在配置文件里优先通过环境变量引用避免配置文件不小心提交到代码仓库里。第二base_url不要画蛇添足加多余的路径后缀很多人在这一步反复报错其实就是因为多写了一层路径。第三default_model建议先用便宜快速的模型调试流程确认链路没问题后再切到更耗资源的推理模型省得一开始就烧钱。我第一次配置好之后直接在workbuddy里输入了一个简单任务让它跑发现响应速度和稳定性都超出预期。“codex不让用的模型workbuddy里自己接进来用”这件事给我的自由度感知是很直观的提升。3.3 实战一用自定义指令实现批量文件重命名配置好模型之后我做的第一件事是把之前遗留的一个文件整理任务用workbuddy跑了一遍。需求本身很简单某个目录下有一批命名混乱的素材文件比如“最终版_v3(1).pdf”“未命名2.docx”这种我需要按照“项目名_日期_序号_描述”的格式统一重命名。在codex里我也可以做但每次都要重新描述一遍需求换一个目录又要重新交代。这次我在workbuddy里直接把规则写成了自定义指令一次性把流程固定下来。我定义指令时用了类似这样的结构## 批量重命名任务规则 - 扫描目标目录下所有文件排除隐藏文件和临时文件 - 提取文件类型、创建时间、原始文件名中的版本信息 - 输出重命名预览表列出旧名 | 新名 | 变更原因 - 确认后再执行实际重命名操作 - 禁止覆盖同名文件遇到重名自动追加后缀把这个指令配置到workbench之后每次我要整理新目录只需要告诉它“用重命名指令处理某某目录”它就会自动执行整套流程。这比我用codex时那种“每次重新说一遍全部要求”的方式效率提升非常明显。这种“把经验沉淀成指令”的能力适合任何需要重复执行的任务流程。一周下来我建了大概五六个这样的指令覆盖了文件重命名、TODO扫描整理、日志分析摘要等工作日常重复劳动被压缩得很快。3.4 实战二写代码加自动执行的网页抓取任务第二个场景更偏开发一点。我需要从某个开放的资讯页面抓取标题和摘要整理成结构化表格输出。workbuddy的优势在于它不只负责生成代码还能在许可范围内直接帮我把代码跑起来并汇报结果。我的要求是写一个Python脚本用requests加BeautifulSoup抓取页面上的指定区块清洗文本后输出CSV。我没有手写核心逻辑只是在workbench里描述清楚目标页面结构、选择器特征和输出格式它就直接把脚本生成出来了还主动提示我需要安装两个依赖库。脚本跑通之后我发现它生成的代码里有一个小瑕疵处理超时异常时的重试逻辑写得不严谨遇到连续失败时会卡住整批任务。我提出这个反馈让它修正逻辑并重新执行这次给出的版本加入了重试上限和失败记录行为合理很多。这让我明显感觉到workbuddy的执行链路是“生成—运行—检查—修正”的闭环而不是只给我一段代码让我自己去跑。对不想频繁切窗口的开发者和技术运营人员来说这种体验相当加分。3.5 实战三和Obsidian联动让AI整理笔记第三个场景来自我个人的知识管理需求。我用Obsidian做资料库积压了大量随笔和摘录一直懒得分类整理。workbuddy有一个比较活跃的社区方向就是把它和Obsidian这类本地知识库联动实现自动化整理。实际跑通的步骤大致是让workbuddy读取指定笔记库目录下的未整理文件识别标题、标签、正文内容按主题给出分类建议我确认后它直接生成带有frontmatter的建议文件头包括标签、目录归属和相关笔记链接我再手动挪动文件位置。这个过程真正帮我省时间的不是AI写的内容多好而是它把“格式规范化”这件事自动做掉了。之前我整理一篇笔记需要同时想清楚标签、关联、格式现在这些统一由模板处理我只负责判断AI的归类是否合理。一周下来我的资料库被整理出了一版比较清晰的结构。4. codex和workbuddy的真实对比功能、稳定性、扩展性4.1 从功能到体验一张表看清差异以下是我自己一周使用下来最直观的对比列成表格方便你参考对比维度codexworkbuddy安装体验Windows上有安装未完成的概率启动偶发重连安装顺畅Windows/Linux均验证可用模型支持限制较严格非白名单模型直接报错可自由接入多种模型支持自配endpoint自定义能力有基础设置项结构偏固定自定义指令skill体系可沉淀可复用执行闭环能改代码重执行能力中等生成—运行—检查—修正的闭环更完整工作场景管理单会话为主场景切换靠人肉切换目录多workbench隔离一套规则一套环境插件扩展生态生态较新可选扩展有限skillhub可获取现成技能包扩展更丰富本地链路稳定性对切换和链路异常较敏感本地环境更可控配置项更透明这张表不是要分个高低而是想说明它们的设计导向完全不一样。codex更像是“开箱即用的专用工具”面向那些希望立刻投入编码、不想折腾配置的人。workbuddy则更像“可组装的工作平台”面向那些有明确工作流、愿意花一点时间配置来换取长期效率的人。4.2 什么场景我还会切回codex虽然我现在已经把workbuddy当主力但我不认为codex就该被否定。有些场景我依然会用回codex。比如在快速原型验证的时候我不想做任何配置只想赶紧跟AI对话写一小段代码codex的上手成本确实更低输入一句话就能开始不用考虑workbench和指令这些概念。再比如当你有大量代码阅读和修改工作并且项目结构又比较标准时codex对项目级上下文的捕捉做得确实成熟。它那种“项目内置代理”的感觉在某些具体场景下比workbuddy更顺手。所以我的建议是不要非黑即白地选边站。用workbuddy做那些需要长期沉淀、反复重用的流程用codex做快速交互和临场写码两者各干各擅长的事才是最舒服的状态。4.3 提一嘴codebuddy、workbuddy、claude code别搞混这里必须帮大家避一个坑。我在搜资料的时候发现很多人把codebuddy和workbuddy搞混。这俩名字确实像但完全不是一回事。codebuddy更多是面向结对编程和企业级代码助手的定位workbuddy则是一个本地AI工作台核心价值在多模型接入、skill扩展和工作流管理上。还有claude code和workbuddy也有不少人在对比。claude code的优势在模型能力和对话体验上底层走的是Anthropic自家模型workbuddy则更强调“模型无关”和“可编排”。它们在功能上有些重叠但理念差别挺大。选型的时候先想清楚你是要“一个好助手”还是要“一套自己的工作系统”再去看名称就自然不会晕了。5. 一周内踩过的坑按阶段整理成排查手册5.1 安装与启动阶段第一个坑是Windows安装未完成的问题。我在一台Windows机器上尝试时也遇到了类似情况后来排查发现多半是安装目录权限不足或者安装包被安全软件拦截了部分写入操作。解决思路很简单用管理员身份运行安装程序并且关闭实时防护再装一次成功率会高很多。第二个坑首次启动时卡在空白界面。这个问题一般是配置目录损坏或者上一次异常退出留下了锁文件。workbuddy会在用户目录下生成配置目录里面有一个lock标识文件如果非正常退出下次启动就会卡住。我把lock文件删掉后重启就恢复了。这里也提醒自己退出workbuddy时尽量用命令退出不要直接杀进程。5.2 连接与模型配置阶段这个阶段我踩得最深的坑就是切换端点失败的问题。我在尝试从默认服务切换到自配endpoint时遇到过和codex类似的情况切换本地服务端点失败后面连续几次请求都没有响应。我当时的处理过程是先检查配置项里的base_url是否书写正确再确认是否有多余的空格或转义字符然后把API Key改为环境变量引用确保没有隐藏的换行符混进去最后重启workbuddy清掉全部连接缓存。这套组合拳下来问题基本就消失了。另一个坑是用自定义模型名时提示“模型不受支持”。这个在workbuddy里出现的话先别急着认为是工具问题大概率是你在配置里填的模型名和服务商平台公布的模型标识不一致。比如deepseek的模型名是deepseek-chat如果你填的是对话界面显示的名称就会校验失败。到服务商的文档里查准确名称再同步过来就好。5.3 skill和自定义指令阶段skill不生效是很常见的问题。我一开始从skillhub拉了一个技能包但调用时总提示找不到模块。翻看日志才发现workbuddy不会自动把新拉取的skill绑定到当前workbench需要手动在workbench设置里启用这个技能包。这个操作在界面上藏得比较深不熟悉的人很容易忽略。自定义指令加多了也会出问题。我有一次连续加了五六条指令结果后续任务响应变得很奇怪行为逻辑出现冲突它既想遵守A规则又想满足B规则最后两头都没做好。后来我学会把指令按“全局基础规则”和“单工作台专用规则”分开存放全局只放不得违背的底线规则具体任务规则才放工作台里冲突概率大大降低。5.4 给新手的四点建议第一刚开始用不要贪多。先把一个workbench、一个模型、一条自定义指令跑通再慢慢加skill不要第一天就塞满一整面配置。第二API Key管理要养成安全习惯。尽量全走环境变量不要硬编码在配置文件里也不要截图发给别人看。第三定期备份配置目录。workbuddy的配置目录非常便携每周打包一次放网盘或者git私有仓库换机器、重装系统都不慌。第四skill和指令宁缺毋滥。每一条规则都会增加AI的理解成本质量永远比数量重要。留下真正高频、真正有用的其余删掉。这一周从codex转战workbuddy我最大的体会是工具好不好用一半看工具本身另一半看你有没有花时间去调教它。workbuddy给了我把AI工作流固化成资产的路径这是它最打动我的地方。后面我会继续把自定义指令库扩得更细把这个工作台真正变成我自己顺手的样子。