这周我把主力编码 Agent 从 Codex 换成了 WorkBuddy用满七天感受挺多挑重点写一篇。先说背景我从 Codex 出的第一天就开始折腾它CLI 加桌面版都装过最开始确实有惊艳感但用着用着问题就来了——开启工作前经常提示 auth token 不可用Windows 上装桌面版装到一半卡死想接 DeepSeek 等模型时又频繁报“endpoint 处理失败”之类的配置错误单个看都能忍凑在一起就成了每次开工前的仪式性劝退。正好有朋友推了 WorkBuddy说这东西是个把模型切换、自定义指令、Skill 技能包整合起来的 AI 工作台我抱着试试的心态用了一周。今天这篇文章就把两边到底差在哪、迁移过程踩了哪些坑、以及现阶段我更推荐谁用哪个一次性讲清楚。1. 为什么从 Codex 转到 WorkBuddy先搞清楚两边到底差在哪1.1 Codex 用得越久越难受的几个点Codex 刚出来那阵我是真觉得它能干活。代码仓库丢给它能自己读文件、跑命令、改代码那种“代理式”的交互比早期单纯补全要先进一个量级。但高强度用了半个多月问题开始集中在几个固定的地方。第一是认证状态不稳定。有阵子经常弹出“auth token 不可用”之类的提示登录状态说丢就丢命令行里重新登录好几遍才能恢复。第二是模型兼容卡得死社区里大家都想接第三方模型来省钱或者试新模型但 Codex 对端点和模型名的校验很严格我曾经拿着一个刚出的模型试过直接返回“当前模型不受支持”。第三是桌面版安装体验差Windows 上装到一半卡住的情况我遇到不止一次最后只能退回去用命令行。第四是 CC Switch 这类配置切换工具偶尔会出问题我一度用它统一管理多个工具的 API 配置但时不时就报“endpoint 处理失败”每次都要重启服务很影响连续工作的节奏。这些问题的共性是它们都不是“能力不够”而是“周边设施拖后腿”。Codex 的核心生成能力没问题可一旦牵扯到多模型管理、配置切换、跨平台使用体验就变得很碎片。对偶尔用一下的人来说无所谓但每天都要开工的人光伺候这些配置就能消磨掉不少耐心。1.2 WorkBuddy 的定位不是替代品是另一种工作方式WorkBuddy 给我的第一观感是它把“模型”这件事放到了后台把“工作台”放到了前台。打开之后是一个主工作界面左边是会话和任务列表中间是对话区右边是文件预览、指令和 Skill 的快捷面板。你不需要先想好“我要用哪个模型的哪个参数”而是在一个统一的工作区里随时切换当前任务绑定的模型。它内部的管理方式对我这种多模型用户很友好。OpenAI 兼容接口、DeepSeek、各类第三方端点都可以在设置里配好然后在会话里切换。这个机制有点像我在 Codex 时代用 CC Switch 想实现的效果但 WorkBuddy 是内置的不用再额外维护一套本地配置服务也不容易出现“某个工具改了配置、另一个工具不知道”的状态不同步问题。另外它的“Skill”体系是我决定深入用的关键。简单理解Skill 就是把一段固化的提示词、操作流程和文件处理规则打包成一个可复用的技能按钮点一下Agent 就知道要按什么流程干活。这个设计比我手动复制粘贴大段提示词要省事太多后面我会单独展开讲。1.3 两类工具的适用人群为了让没接触过这两个工具的人快速定位我做了个粗略对照维度CodexWorkBuddy使用形态以命令行为主桌面版体验一般桌面工作台为主图形化程度高模型来源官方模型为主接第三方较折腾多模型集中配置切换方便自定义方式配置文件加提示词自定义指令加 Skill 技能包典型用户熟悉 CLI、喜欢极致轻量的开发者需要同时管理多个模型和任务的知识工作者、开发者上手成本门槛偏高出问题要自己排门槛较低图形界面引导清晰周边生态依赖外部工具补全配置管理内置配置切换、技能市场、知识库联动看完这表你应该能理解为什么我的结论是“不是替代品而是另一种工作方式”。Codex 适合那种专注在单个模型生态里、愿意折腾命令行的用户WorkBuddy 则适合更看重“开箱即用”和“多模型统一管理”的人。我自己属于后者所以这一周的迁移本质上是换了一种和 AI 协作的姿势。2. 安装与初始化这一周我踩过的配置细节2.1 Windows 和 Linux 安装实录先说安装。Codex 时代我最大的噩梦之一就是 Windows 桌面版装到一半卡住最后不得不退回命令行。WorkBuddy 在这块的体验让我有点意外Windows 版本我从官网下载安装包到打开主界面全程大概三分钟没有出现需要手动修环境变量的情况。我日常开发的主力是 Windows但家里还有一台 Linux 机器跑定时任务所以 Linux 版本也在我的测试范围内。WorkBuddy 的 Linux 版给的是 AppImage 包直接给执行权限就能跑。我一开始担心权限和沙箱问题实测下来只要系统装了 FUSE 基础库启动基本无感。需要注意的一点是如果你用的是精简版发行版缺少某些图形依赖库首次启动可能会报错安装对应的系统依赖包就能解决我在后文问题排查里会详细说。安装完成后的初始化流程WorkBuddy 比 Codex 更“向导化”。它会一步步引导你创建本地工作目录、选择默认使用的模型来源、设置语言偏好。Codex 那套需要手动敲命令的方式对老手还算友好但对想快速上手的人来说这种向导确实省心不少。我的建议是安装时不要跳过“选择工作目录”这一步后续所有 Skill 和自定义指令都基于这个目录来组织先想清楚再填能省掉后面很多路径混乱的麻烦。2.2 模型接入把 DeepSeek 和 OpenAI 兼容接口都配一遍对从 Codex 转过来的人来说最关心的肯定是“我现有的模型能不能用”。答案是可以而且配置方式比 Codex 时代简单很多。WorkBuddy 的模型设置界面里可以直接添加“OpenAI 兼容接口”类型的端点。你只需要填三样东西接口地址、API Key、模型标识。我在迁移后的第一天就把 DeepSeek 的接口配了上去流程就是复制接口地址、粘贴密钥、选模型名然后保存。这里有个细节不同提供方的模型标识字符串不一样比如 DeepSeek 的模型名要写它的官方标识不能想当然写别的名字否则调用时会报“模型不存在”。配好之后在会话界面有一个模型选择下拉框切换模型是即时的不用重启也不用像以前那样去改全局配置。这一点对我这种既想用主力模型写复杂代码、又想用便宜模型跑批量任务的人来说价值非常大。实操心得如果你同时接了多个模型建议给每个端点都起一个容易认的名字比如“DS-主力”“DS-便宜”“OAI-备用”。因为会话切换模型时显示的是端点名称命名清晰能避免切错。我一开始图省事全叫“默认”结果有一次批量跑任务切错了模型多花了两倍的调用费用血的教训。2.3 自定义指令别照抄网上的模板照着这个思路写WorkBuddy 里有“自定义指令”功能相当于给 Agent 设定一个长期生效的系统提示词。刚开始我从网上找了一大段所谓的“最强指令”粘进去结果发现效果反而不如简明扼要的版本。原因很简单指令越长模型越容易在执行时迷失重点尤其是那些堆砌了大量形容词的模板输出反而变得啰嗦。我现在的自定义指令是这么写的你可以直接抄你是我的编程助手。在回答任何代码问题前先确认需求 当你不确定时主动提出最多两个关键问题 代码输出使用 markdown 代码块并注明运行环境 涉及修改文件时先说明修改原因再给出完整 diff 不要省略错误处理逻辑遇到权限或路径问题先检查工作目录。这套指令的核心是“约束行为而不是约束风格”。它明确了几件事什么时候该提问、代码以什么格式输出、修改文件时先解释再动手。相比网上一堆“你是一个拥有十年经验的全栈架构师”这类人设模板这种操作性强的指令对模型输出的改善更明显。我强烈建议你也按这个思路把指令内容限定在“行动规则”层面。比如你想让 Agent 写更安全的代码就加一条“涉及用户输入时强制使用参数化查询”你想要更清晰的日志就加一条“日志必须包含时间戳和函数名”。这些具体的约束比抽象的风格描述有用得多。3. Skill 与自动化WorkBuddy 最值钱的玩法3.1 Skill 到底是什么和自定义指令有什么区别很多人分不清 Skill 和自定义指令我一开始也困惑。用一句话说明白自定义指令是“全局的行为准则”Skill 是“某个特定任务的专业操作流程”。举个例子。我的自定义指令里有一条“先确认需求再回答”这是全局生效的。而我写了一个叫“代码审查”的 Skill它内部定义的是读取指定目录下最近变更的文件逐个检查潜在 bug、安全风险、性能问题然后按严重程度输出报告。这套流程只有在触发这个 Skill 时才会执行不会干扰其他对话。在 WorkBuddy 里Skill 通常以一个配置结构的形式存在包含触发条件、执行步骤、输出格式、用到的工具清单。它的价值在于把一套经过实践验证的流程沉淀下来下次遇到同类任务点一下就能复现不用重新组织语言描述需求。这跟把几个人工流程脚本化、工具化是一个思路减少重复劳动稳定输出质量。3.2 SkillHub 里值得装的几个技能WorkBuddy 有技能市场官方和社区都有人上传现成的 Skill我这一周亲测下来觉得这几个最值得装代码审查技能这个我几乎每天用。以往我自己人工过一遍代码至少要二十分钟现在丢给 Skill 先做一轮自动化检查重点看它指出的安全问题和逻辑漏洞效率提升很明显。当然它不能代替人做最终决策但它能帮你把明显的问题捞出来。需求拆解技能输入一段模糊的产品需求它会输出任务清单、技术难点、交付顺序。我用来处理那种“你帮我做一个某某系统”类型的需求它能把大需求拆成 AI 能逐个完成的小任务这对控制生成质量非常关键。数据库运维技能它会按固定流程检查表结构、索引合理性、慢查询风险。虽然我的使用频率不算高但每次涉及数据库调整时调用它都能及时拦住一些低级错误。自动签到技能这个是从社区学的理论上可以把一些重复性的网络操作写成定时任务。说实话这个技能我踩过坑后面问题排查会专门讲。我的建议是刚开始不用装太多装两三个覆盖你最高频的任务就好。Skill 装多了Agent 在判断用哪个技能时也会犹豫反而拖慢响应。先跑一周把真正高频的任务挑出来再去扩充你的技能库。3.3 用 WorkBuddy 从零做了一个小工具光说不练没意义我这周用 WorkBuddy 实际做了一个内部用的命令行小工具作用是批量整理日志文件按天压缩归档。整个流程走下来我对这套工作方式的体会更深了。需求很简单每天有几十个日志文件散落在不同子目录需要按日期归类再打包。我把需求直接描述给 WorkBuddy“写一个 Python 脚本扫描指定目录下所有 .log 文件按日志文件名里的日期字段分类每天的文件打成一个 tar.gz 包放到 archive 目录处理过的文件移动到一个 done 目录。”我没有让它一次性生成全部代码而是先让它基于需求拆解任务然后分步实现。第一步写文件扫描模块运行测试第二步写日期解析和归档逻辑再运行测试最后补上参数化和异常处理。整个过程 WorkBuddy 的代码补全和错误修正都比较流畅遇到路径写错的问题它会主动检查工作目录结构再修正这个行为要归功于我自定义指令里设置的“遇到权限或路径问题先检查工作目录”。最有价值的一点是整个过程被 WorkBuddy 记录成了带上下文的会话。做到一半切换到别的任务再切回来它能接着之前的进度继续不会像某些工具一样一换对话就失忆。这种“长会话连续性”对复杂任务太重要了。4. Obsidian 联动与知识库场景4.1 为什么要把笔记工作流接进来我平时有个习惯所有技术方案和踩坑记录都写在 Obsidian 的 Vault 里。长期以来笔记和 AI 工具是割裂的AI 只处理当前会话内容我的历史经验它看不见笔记里的信息要靠手动复制粘贴才能喂给模型。WorkBuddy 支持连接 Obsidian 本地 Vault这对我来说是一个加分项。连接之后Agent 可以读取指定笔记文件作为上下文也可以把生成的整理结果写回 Vault。这意味着我的历史经验真正参与到了 AI 的决策过程中而不只是靠模型自身的训练知识。对于很多重复踩坑的领域这个能力非常实用。4.2 配置方式和我的用法配置比我预想的简单。在 WorkBuddy 的设置里找到知识库或 Obsidian 相关的选项填入 Vault 的本地路径它会自动扫描可以访问的笔记目录。我出于隐私考虑给了一个单独的“AI 可用”文件夹只把允许 AI 读取的笔记放进去其他私人内容不放。我现在的用法有两种。第一种是“检索型”遇到问题先让 Agent 读相关的历史笔记比如“把 Vault 里所有关于日志采集的笔记要点整理给我”它会把相关内容聚合后输出省去我自己翻阅时间。第二种是“回写型”每次排查完一个复杂问题我会要求 Agent 把“问题现象、原因、解决方案、关键命令”整理成一篇结构化笔记存回 Vault。这样这次的经验就固化了下次遇到还能检索到。这套流程跑通之后我的笔记库不再是沉睡的资料堆而是变成了持续更新的知识资产。我建议有同样习惯的人一定要尝试这个联动价值不在于读笔记本身而在于形成“踩坑→解决→沉淀→复用”的闭环。4.3 一个能直接抄的“读笔记整理”指令如果你也想让 WorkBuddy 帮你整理笔记这里给一个可以直接用的指令也是我目前保留在模板里的请阅读以下路径中的笔记提取与【主题】相关的内容 输出格式先给三点核心结论再给时间线和关键细节 如果笔记中有互相矛盾的信息单独列出来并说明 整理完成后把结果保存为新的笔记文件路径为【目标路径】。这条指令的几个设计点值得说说要求先给核心结论是为了避免长篇流水账要求标注矛盾信息是因为我的笔记里确实存在不同时期的认知冲突AI 把冲突点列出来能帮我意识到认知变化最后要求保存为新笔记是为了避免污染原始记录。这种“指令模板”是可以根据你自己的笔记习惯调整的核心思路就是让 AI 不只看还要按你的使用偏好输出。5. 实战一周的高频问题与排查记录5.1 502 write EACCES文件权限导致任务中断这一周遇到最典型的报错是“502 write EACCES”主要发生在 WorkBuddy 尝试往某些目录写入文件时。第一次碰到我以为是工具本身的问题排查之后发现是工作目录的写权限不足。现象是这样的我分配的工作目录在系统盘的某个受保护位置WorkBuddy 进程没有该路径的写入权限于是每次生成文件时都报权限错误。解决办法是把工作目录改到用户目录下的自定义路径比如D:\WorkBuddy\workspace或 Linux 下的~/workspace。在 Linux 上还需要注意目录归属我用chown -R 用户名:用户名 目录路径调整了归属之后再没出现这类问题。排查思路也分享给你遇到 EACCES 类错误先确认进程身份再确认目标目录的权限位最后检查是不是被安全软件拦截了写入。前两步能覆盖 90% 的情况。5.2 自动签到类重复任务为什么总是翻车我在 SkillHub 看到自动签到技能时很心动想着把每天要手动操作的签到流程自动化。实际用下来这个技能在我这里翻车率很高问题不在 WorkBuddy而在任务本身的复杂度。自动签到涉及登录、页面定位、按钮点击、验证码处理等环节任何一个环节页面结构变化都会导致整个流程失败。我第一天跑通第二天网站改版就挂了。后来我想明白了这类技能适合的其实是“接口型”而不是“页面型”任务。如果你的目标是调用一个固定 API 去签到参数稳定那自动化完全可行如果是模拟浏览器操作网页那就要做好随时失效、随时维护的心理准备。我的建议是别把精力花在维护脆弱的页面自动化上优先把有稳定 API 的任务做成 Skill。实在要做网页操作就引入重试机制和失败告警至少失败时能及时通知你人工处理而不是静默失败。5.3 模型切换丢失上下文的应对WorkBuddy 虽然支持会话内切换模型但我的实测体验是从上下文规模小的模型切到规模大的模型前面的对话内容基本都能延续但如果切到上下文窗口比较小的模型后面生成时会出现“记不得前面说了什么”的情况。这不算 Bug是模型本身的容量限制。应对方法有两个。第一重要信息不要只依赖上下文传递养成“让 Agent 在关键节点生成进度小结”的习惯切换模型后把小结作为新输入喂回去。第二任务太长时主动分段每一个阶段结束让它输出阶段成果文档存到工作目录下一个阶段基于文档继续而不是基于对话继续。这其实就是我在自定义指令里强调的“先说明再动手”的延伸——让 AI 主动物化它的进度而不是让进度只存在于脆弱的上文记忆里。5.4 高频问题速查表我把这一周遇到的典型问题和处理方式整理成一张表方便你直接对照现象可能原因处理办法502 write EACCES工作目录无写权限调整目录权限或改用用户目录下的工作目录模型切换后遗忘前文目标模型上下文窗口较小定时生成进度小结切换后回填Linux 首次启动图形界面崩溃缺少 FUSE 或图形依赖库安装 libfuse2 和相关依赖后重试API 接入后报模型不存在模型标识字符串填错核对官方模型标识不要填展示名自定义指令不生效指令写在错误的配置层级检查指令是否保存在全局配置而非会话级自动签到技能静默失败页面结构变化或未加告警优先选 API 方案加失败通知机制这张表会在后续使用中持续更新我建议你也留一份自己的排查笔记用前文说的 Obsidian 联动把它沉淀下来长期看收益比任何工具本身都大。6. 一周之后我给两类场景的最终建议6.1 留在 Codex 的场合我必须客观地说Codex 没有我说的那么不堪它仍然有自己不可替代的场景。第一类是追求极致轻量的人一个终端窗口就能完成所有工作不需要任何图形界面第二类是你已经完全跑通了它的工作流模型用的就是官方那套不折腾第三方接入那么它的稳定性其实相当好第三类是你需要和命令行生态深度集成比如通过脚本批量触发任务Codex 在这种场景下的可编程性依然是有优势的。如果你属于这三类我不建议你轻易迁移迁移成本大概率高于收益。工具从来不是越新越好而是越适合越好。6.2 转 WorkBuddy 的场合反过来如果你有以下特征我建议你认真考虑 WorkBuddy需要使用多个模型并且经常需要切换希望有一个图形化界面来管理任务、文件、指令需要把 AI 能力嵌入到知识管理工作流里或者你刚刚接触代理式编码工具需要一个上手门槛更低的入口。对我来说WorkBuddy 解决的最大问题不是“生成代码的能力更强”而是“让 AI 融入工作流的摩擦更小”。Codex 让我觉得是在“用 AI”WorkBuddy 让我觉得是在“和工作流里的 AI 协作”。这两者体验上的差异一周用下来感受非常明显。6.3 我当前的最终配置与习惯最后交个底我这周稳定下来的配置是主力对话和代码生成用 DeepSeek 接口便宜量大代码能力足够复杂架构设计时才切到 OpenAI 兼容接口的强模型所有会话统一用一套我前面贴的自定义指令Skill 只保留了代码审查和需求拆解两个Obsidian 联动开着每个排查过的坑都会整理成笔记回写。日常习惯上我给自己定了一条规则任何超过半小时的任务必须让 WorkBuddy 在关键节点输出一份进度文档。这条规则帮我避免了很多次“上下文丢失从头再来”的灾难。归根结底工具能帮你省时间但怎么组织工作流、怎么沉淀经验还是要靠你自己。最后再分享一个小技巧如果你刚开始用 WorkBuddy先别急着装一堆 Skill 和模板指令花一整天把它当作普通对话工具用记录下自己重复了两遍以上的任务第二天再针对这些任务去配置指令和 Skill。这样配出来的工作台才是最贴合你需求的而不是照着别人的配置抄一遍。我这一周最满意的部分恰恰是那些单独为我定制的小流程而不是从市场里一键装来的现成技能。