说实话我一开始并没有打算换掉 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 models 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 和 LinuxUbuntu 的 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 CLIWorkBuddy安装体验Windows 下容易卡在“安装未完成”图形化安装Windows/Linux 都有配置复杂度依赖命令行参数和配置文件设置面板可视化配置上下文管理自动压缩但长任务容易溢出报错任务持久化支持会话切换与恢复长任务稳定性压缩失败会丢进度一周内没出现因上下文导致的会话丢失交互模式纯终端命令行可视化工作台支持任务卡片管理项目规则AGENTS.md 静态文本全局/项目指令 Skill 操作包模型接入需改配置新模型支持滞后图形化配置支持 DeepSeek 等常见 API扩展性有限依赖社区 hackSkillHub 社区市场可沉淀流程资源占用轻量终端运行桌面应用相对更重适合场景短平快、单任务、极客流多任务并行、长周期重构、需要记录复盘这张表不是我凭想象画的是我这一周真实体验的产物。打个比方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 配好再决定要不要把主力工作流挪过来。工具这东西用着顺手永远比看起来高级更重要。