从Codex CLI到WorkBuddy：AI编程工具切换实测与对比

说实话，我一开始并没有打算换掉 Codex CLI。作为一个从命令行时代走过来的开发者，我对这种终端里跑 AI 编程代理的工作方式是有偏好的，甚至花了不少时间研究怎么把 Codex 接到 DeepSeek 上、怎么整理 AGENTS.md 里的项目规则。但前面这半个月，Codex 在我这边的体验直线下滑：长任务跑到一半直接报错、新模型接入各种限制、Windows 桌面版安装反复失败。正当我想发火的时候，看到了 WorkBuddy 的讨论，索性抱着“试试看又不亏”的心态装了一个。这一周下来，两个工具给我最大的感受差异，用一个不恰当的类比来说：Codex 是一把锋利的战术刀，WorkBuddy 更像一张带抽屉的工作台。刀有刀的好，但当你需要在同一张桌子上连续干几天活的时候，抽屉多不多就非常重要了。

下面这一周的真实体感，我把配置过程、踩坑记录、同场景对比都摊开讲。想从 Codex 转战 WorkBuddy 的朋友，希望这篇能帮你少走点弯路。

1. 先说清楚：Codex 不是不好用，是这几个问题我扛不住了

1.1 我原来的 Codex 工作流是什么样

在用 WorkBuddy 之前，我的 Codex 工作流大概持续了三到四个月。日常习惯是开一个终端，进入项目根目录，直接启动 codex，让它基于整个仓库的代码结构去帮我改 bug、加功能、补测试。项目级的行为约束我会写进 AGENTS.md，里面放上了代码风格规范、禁止改动的文件列表、提交信息的格式要求这些东西，相当于在每次会话开始时把自己的“要求清单”先拍在桌面上。

后来社区里很流行把 Codex 接到 DeepSeek，我也跟着配置过。步骤其实不复杂：把 API 的 base URL 换成 DeepSeek 的接口地址，填上自己的 API Key，再指定模型 ID 就行。效果方面，对于代码理解、多文件修改、错误修复这类任务，Codex CLI 确实是我用过的命令行 AI 编程工具里最能打的一个，不是玩具级别。这也是我在遇到后面那些问题之后，依然犹豫了很久才决定换工具的原因。

1.2 三个压垮我的具体问题

先说第一个，也是对我来说最致命的：长任务对话一多，会话就废掉。Codex 的上下文管理策略是“对话压缩”，当上下文接近上限时，它会把历史消息压缩成一段摘要再继续跑。想法很好，但实际执行时我反复遇到一个报错：

error running remote compact task: codex ran out of room in the model's context

字面意思是，模型上下文里已经没有空间去执行压缩任务本身了。翻译成大白话就是：它还没来得及整理包袱，包袱就已经满了。结果就是，一个跑了两个小时的重构任务，在关键收尾阶段直接断掉，会话作废，所有进度丢失。你只能开一个新会话，把需求重新描述一遍，让 AI 重新读一遍代码。这种事发生一次两次还能忍，连续发生三四次之后，我真有点想砸电脑。

第二个问题：新模型的支持严重滞后。我在尝试把一个比较新的模型 ID 配进 Codex 时，它直接拒绝了运行请求，报错如下：

the 'gpt-5.6-sol' model is not supported when using codex with a...

报错语义很明确：这个模型 ID 不在 Codex 当前版本的允许名单里。社区里确实有人通过改包、换兼容模型 ID 的方式绕过去，但每次都要折腾，而且绕过之后的行为是否稳定还得看运气。作为用户，我的核心诉求是用顺手的好模型干活，而不是跟工具的模型白名单玩游戏。

第三个问题是连接和安装层面的不稳定。Windows 桌面版安装时，好几次卡在“安装未完成”的界面；运行过程中动不动提示“正在重新连接”，活干到一半断线重连，之前的上下文和任务状态都要重新确认。另外，在切换不同配置的时候，偶尔还会弹出类似 cc switch local proxy failed while handling codex endpoint /responses 的本地服务报错。这些虽然不致命，但每次打断都会把人从心流状态里拽出来，一天来上几回，工作效率可想而知。

说句公道话，这三个问题不代表 Codex 不行，它更准确的定位是“默认环境下很好用，折腾环境下很受罪”。前两个问题本质上是架构限制，不是换个配置就能彻底解决的。

2. WorkBuddy 上手第一印象：安装比想象中省事，界面完全是另一种思路

2.1 安装过程：没有出现 Windows 安装未完成那种尴尬

决定试 WorkBuddy 之后，我第一件事是去翻了它的安装方式。它同时提供 Windows 和 Linux（Ubuntu 的 deb 包）版本，还看到有社区在交流 Mac 下的用法。我自己的主力环境是 Windows + Ubuntu 双机，就直接在 Windows 上先装了。

整个过程比 Codex 顺心太多：下载安装包、双击、下一步下一步，装完直接就能从桌面图标启动。没有遇到像 Codex Windows 安装未完成那样的尴尬。装好之后打开，它是一个完整的图形化工作台界面，而不是一个黑乎乎的终端窗口。左边是项目和任务列表，中间是对话和代码差异区，右边是上下文、技能和信息面板。老实说，第一眼看到这个界面，我心想“这不就是个套壳聊天软件吗”，但实际用它跑了一个任务之后，我发现它跟我想象的不太一样——它不是简单的聊天框，而是把“项目”“任务”“技能”几个概念做成了一等的管理对象。

2.2 接 DeepSeek 的配置比 Codex 直观

由于我不想为了 WorkBuddy 再单独开一个大模型的订阅，所以我的第一个目标就是把 DeepSeek 接进去。WorkBuddy 在模型接入上走的是“兼容多种 API”的路线，设置面板里既可以填 DeepSeek 的 API Key，也可以填 OpenAI 兼容接口的信息，甚至能看到不少人用的本地模型方案。

具体操作上，我在设置里选择模型供应商，填上 DeepSeek 的 API Key，模型 ID 选择对应的 DeepSeek 模型，保存之后测试对话，直接就通了。不需要像 Codex 那样去改配置文件、折腾环境变量和命令行参数。整个过程大概两分钟。这点我要给 WorkBuddy 加分，它把“接一个模型”这个高频操作做成了图形化的三选一配置，而不是让用户去啃文档。

2.3 可视化工作台和纯命令行的交互逻辑差异

用了一周之后，我对“图形工作台 vs 命令行”的差异有了更具体的认知。Codex 的优势在于轻、快、离开发者近，适合那种“开个终端，十分钟改完一个 bug”的短平快场景。WorkBuddy 则把“领域（domain）”“会话”“任务”全部可视化管理，适合一个上午甚至一整天泡在里面，连续处理多个需求的场景。

举个例子，在 Codex 里你很难直观地看到当前项目一共有哪些任务在跑、每个任务消耗了多少 token、上下文占用到了什么程度。但在 WorkBuddy 里，这些都以卡片和进度条的形式展示着，我可以随时切回某个之前跑了一半的任务，接着原来的上下文继续。对于我这种同时要维护三四个项目的开发者来说，这种“任务间切换”的能力比想象中重要得多。

3. 一周实测：我拿 WorkBuddy 干了哪些具体的活

3.1 老项目重构：从“它自己干”变成“我指挥它干”

我这一周最重要的一项工作是接手一个历史遗留模块的重构。这个模块之前用 Codex 跑过一半，结果遇到上下文压缩报错，进度全丢，一直没捡起来。这次我把任务交给了 WorkBuddy。

我的做法是：在 WorkBuddy 里新建一个项目关联到本地仓库，然后把重构需求写成一段详细的任务描述，指定涉及的文件范围，并且明确要求“先输出重构方案，不要直接动代码”。WorkBuddy 会先基于仓库理解生成一份改动方案，包括涉及哪些文件、每个文件大概要改什么、风险点在哪里。我在界面上逐个确认之后，它才开始执行。

这个过程和 Codex 那种“一股脑把所有文件都改完”的风格很不一样。Codex 在快节奏下很爽，但遇到需要谨慎对待的老代码时，缺少一个“方案确认”的中间环节。WorkBuddy 的确认制确实更稳。对于生产环境的保守重构，这种“人先看方案，再让 AI 动手”的交互方式，我觉得是更合适的选择。

3.2 日常脚本和小任务：两边的差距没有想象中大

除了重构，这周我还用 WorkBuddy 处理了不少零碎任务：写一个批量处理 CSV 的 Python 脚本、修 CI 配置里一个正则写错的步骤、把一段旧代码改成用新 API 实现、生成几个符合 conventional commits 格式的提交信息。

这类短任务的完成质量，WorkBuddy 和 Codex 差距不大，毕竟底层模型能力是接近的。但有一个细节值得说：WorkBuddy 的会话记录和任务结果是持久化的，第二天回来打开软件，之前的任务、方案、代码 diff 都还在。Codex 的会话在压缩失败或断线之后，经常就找不回来了。这个差异在只做一两个短任务时感觉不明显，但当你同时推进多个事情时，“记录还在”和“一切归零”的差距会被无限放大。

3.3 值得聊一聊的附加功能：宠物系统、Obsidian 和金融版

WorkBuddy 里有一个宠物系统，完成任务、积累使用时长会给宠物喂经验升级。说实话，我一开始觉得这东西有点花哨，一个编程工具整什么养成系？但实际用下来，我发现自己确实会因为“这个任务做完宠物就能升级”而去把一些本来想拖一拖的收尾工作干掉。这是一种很轻度的游戏化激励，不打扰干活，但确实增加了持续使用的动力。

还有 Obsidian 集成，这个我比较喜欢。我平时会把项目笔记和技术决策记录放在 Obsidian 里，WorkBuddy 可以和 Obsidian 库打通，把 AI 会话中生成的重点内容、方案摘要直接写入笔记库。相当于自动维护了一本项目决策日志，对后续复盘很有用。

另外我了解到还有 WorkBuddy 金融版，面向金融行业的用户，内置了一些行业化的指令模板和合规要求。这个方向我暂时用不上，但能看出这个工具在往垂直领域做深耕。

4. 自定义指令和 Skill 机制：这是 WorkBuddy 最值得折腾的部分

4.1 自定义指令怎么配，我推荐这几条

WorkBuddy 的自定义指令系统，相当于一个“全局规则包”，你可以把对 AI 编程行为的通用要求写进去，所有项目都会默认遵守。它在配置层面区分了全局指令和项目级指令，项目级会覆盖或者叠加在全局指令之上。

我个人强烈建议配这几条，基本上是通用最佳实践：

1. 代码风格：始终遵循项目现有代码风格，不得对无关代码做格式化改动。 2. 测试要求：修改任何逻辑后，必须提供对应的测试用例或说明你的变更如何被验证。 3. 提交信息：按 Conventional Commits 规范生成提交信息，包含 type、scope 和 description。 4. 安全底线：删除文件或修改关键配置前必须向用户确认，未经许可不得执行破坏性操作。 5. 上下文控制：回答问题时先定位相关代码，引用文件路径和行号，避免凭空推断。

这几条指令配置好之后，WorkBuddy 在后续任务中的表现明显更“懂事”。特别是第 4 条，避免了很多次 AI 自作主张删东西的惊魂时刻。配置入口就在设置面板里，不用写代码。

4.2 Skill 和 AGENTS.md 的本质区别

如果你用过 Codex，肯定知道 AGENTS.md 的作用——把项目规则写成一个 Markdown 文件，让 AI 每次会话自动读取。WorkBuddy 的 Skill 机制，表面上看和 AGENTS.md 有点像，实际用起来区别很大。

AGENTS.md 本质上是一个“静态规则文本”，它告诉 AI“要怎么做”，但 AI 仍然只能依靠自己的推理去执行。Skill 则是“可执行的操作包”——它不只是提示词，还可以附带脚本、模板和一套流程定义。举个例子：一个“代码审查” Skill，它不仅会告诉模型“你要审查代码”，还会加载审查规则列表、调用本地脚本来扫描变更文件、最后按固定模板输出审查报告。也就是说，Skill 能把“AI 的行为方式”和“具体的工具脚本”组合成一个闭环。

这一点是 WorkBuddy 和 Codex 在架构理念上的真正分水岭。Codex 把一切都押在“模型理解和智能”上，WorkBuddy 则多提供了一层“结构化技能”的载体，让使用者的经验可以被沉淀和复用。也就是说，一次调试好的流程可以变成 Skill，下次直接调用。

4.3 在 SkillHub 上找现成 Skill 的实用方向

WorkBuddy 有 SkillHub 社区市场，里面有很多现成的 Skill 可以直接导入。我这一周扒了不少，实际留下并且真正用上的方向主要有这几个：

• 代码审查类 Skill：它会按通用 checklist 检查代码质量、安全漏洞、潜在 bug，输出结构化报告。
• 重构类 Skill：适合那种“先把方案列出来再动手”的重构流程，配合我前面说的确认机制很好用。
• 测试生成 Skill：自动分析函数依赖并生成单测，覆盖边界情况。
• Docker 相关 Skill：帮助生成和检查 Dockerfile、docker-compose 配置的规范性。

在使用这些现成 Skill 前，建议先点开看一眼里面的提示词内容。SkillHub 上作者水平参差不齐，有些写得很好，有些只是把一段话包装成 Skill，质量一般。看一遍再决定是否导入，能帮你避开不少坑。

5. Codex 和 WorkBuddy 同场景正面较量

5.1 同一个重构任务，两边各自的处理过程

为了给你一个更直观的对比，我说一个在这周里实际做的对照实验。任务是把一个老模块的回调式异步逻辑改写成 async/await 风格，涉及大约 12 个文件，里面还有一些嵌套很深的回调地狱。

Codex 的处理方式是：一次性把所有文件都改掉，几分钟内输出一大片代码 diff，效率确实高。但问题是中间几乎没有干预点，你只能等它全部改完再 review。如果恰好触发了上下文压缩并且失败，那整个会话就废了，前面几十分钟的工作瞬间归零。

WorkBuddy 的处理方式是：先生成一份重构方案，列出每个文件的改动策略和依赖关系，我确认后才开始逐个文件执行。每个文件改完，我都可以看到对应的 diff 并决定是继续还是回退。最后它还帮我生成了一份重构说明，内容包括改了哪些结构、有没有行为变化、建议做哪些验证。整个过程大概花了 Codex 的两倍时间，但每一步都心里有数。

说实话，两者都能完成这个任务。但如果你做的是核心业务模块的重构，过程可控性的价值是高于那点时间节省的。

5.2 一张表把关键差异说清楚

这张表不是我凭想象画的，是我这一周真实体验的产物。打个比方：Codex 像是露营用的战术斧头，砍柴效率极高，但你要在工地干一个月的活，还是得上工具箱。

6. 一周后的真实结论：什么情况建议你也转，什么情况先别动

6.1 WorkBuddy 目前还没解决的问题

先说 WorkBuddy 做得还不够好的地方，免得你看完前面觉得它是完美的。第一个问题是功能多导致设置项入口有点分散，新手刚进去容易迷路。比如“全局指令”和“项目指令”不在同一个入口，Skill 的启用在另一个面板，模型的参数调节又在别的地方。我一个老手都花了一点时间才把这些入口摸清楚，更不用说新手。

第二个问题是部分 Skill 的质量不稳定。SkillHub 上有些作品明显只是把一段提示词包装了一下，没有真正利用 Skill 的可执行能力，导入之后对任务流程的帮助有限。我在导入前面推荐的几个 Skill 的时候，也遇到过一个 Skill 生成的审查报告格式跟预期完全不符的情况，最后还是自己改了一版才顺手。

第三个问题是资源占用和启动速度。作为一个桌面应用，它比终端工具重不少。我 Ubuntu 那台机器上，如果同时开着浏览器、JetBrains IDE 和 WorkBuddy，内存压力会比较明显。如果你是很吃性能的开发者，这一点要做好心理准备。

6.2 什么样的人适合留在 Codex

这一周用下来，我并不认为所有人都有必要从 Codex 转战 WorkBuddy。如果你符合下面这些特征，继续用 Codex 完全没问题：

• 你大多数任务是短平快的：改一个 bug、写一个函数、修一个测试，不需要长时间保持一个上下文。
• 你习惯纯终端工作流，依赖脚本和快捷键，不想打开一个重量级桌面应用。
• 你用官方默认模型、默认配置就能跑得很顺，没遇到我前面说的连接和上下文问题。
• 你基本不做需要长周期跟进的重构，代码库不大，AI 不需要反复读大量文件。

这种情况下，Codex 的轻量和直接反而是优势。工具终归要适配场景，而不是反过来让自己去迁就工具。

6.3 我的选择：双轨制，而不是二选一

经过这一周的体验，我最终的结论是采取“双轨制”而不是彻底卸载 Codex。日常的快速修改、临时脚本、在终端里顺手就能解决的小问题，我会继续用 Codex CLI，它的快是 WorkBuddy 比不了的。而涉及大型重构、多任务并行、需要记录过程和复盘的工作，我会放到 WorkBuddy 里做，它的任务持久化和 Skill 机制正好补上 Codex 的短板。

最后分享一个我在这一周里调出来的小技巧：在 WorkBuddy 里给每个项目单独配置一份项目级指令，不要只依赖全局指令。全局指令放通用的代码规范和底线要求，项目级指令放这个项目特有的技术栈约束、目录结构和易错点。这样搭配着用，AI 输出的上下文相关性和准确率都会上一个台阶。如果你正在两个工具之间摇摆，我的建议是别急着全量迁移，先拿一个不紧急的项目跑一周，把自定义指令和 Skill 配好，再决定要不要把主力工作流挪过来。工具这东西，用着顺手永远比看起来高级更重要。