从codex迁移到workbuddy：本地AI工作台多模型接入实战

写下这篇的时候，我正好把主力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 从功能到体验，一张表看清差异

以下是我自己一周使用下来最直观的对比，列成表格方便你参考：

这张表不是要分个高低，而是想说明它们的设计导向完全不一样。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工作流固化成资产的路径，这是它最打动我的地方。后面我会继续把自定义指令库扩得更细，把这个工作台真正变成我自己顺手的样子。