- 发布于
WorkBuddy 突然登场，与 它 一起工作的问题
- 作者
- Name
- 王华江 (Huajiang Wang)
前些日子，我才刚整理完关于 OpenClaw 的一些体验心得。在那篇文字里，我还在惊叹于手机化作一只“远程机械臂”的可能性，心中却也不免有些游移：若是将这类严谨且需长久维护的“结构化”任务，托付给像 Trae 这样更为稳健的工具，或许在直觉上会更让人安心一些。
未曾想，WorkBuddy 的公测消息竟先行一步，其节奏之快，倒显得有些出人意料。
于是，便有了这一篇文字——它记录了我在 OpenClaw 之后，与 WorkBuddy 之间的一场不期而遇。
一、理想之外，绕不过去的几个现实问题
任何新工具，尤其是和“智能”挂钩的工具，在初次接触时都带着一点兴奋感。但用着用着，一些不太容易忽略的问题，就会浮上来。
1. 模型固定，选择消失
WorkBuddy 默认使用的是某一个 AI 模型，大多数时候表现得中规中矩，足以应付日常问答和补全。
但偶尔，我也会希望能换一种“思路”，比如切换到 MiniMax M2 这类在某些任务上更擅长的模型，看看会不会得到一套不同的方案。问题在于，目前这种切换只能在本地电脑上手动操作，并没有为普通用户提供更便捷的切换入口，更无法在远程使用手机时，通过对话让智能体“自己切换模型”——它并没有这样的自主权。
2. 高峰期的不稳定，比错误本身更让人无力
关于 AI 服务在高峰期变慢、请求超时，这已经是老生常谈。但在 WorkBuddy 这里，这个问题显得格外刺眼，也更直接地考验它“能不能被长期信任”。
在使用人数较多的时间段里，响应会明显变慢，有时会直接报错。 这种时候，你必须守在电脑客户端前，手动点击那个“重试”按钮。而一旦你身处远程（比如手机端），面对这样的超时报错就彻底束手无策，只能眼睁睁看着流程卡在那里。
3. 扩展能力被锁住，想象空间被压缩
对很多开发者来说，一个工具是否“好用”，往往不止看它当前的功能，更看它的边界画在何处。
出于好奇，我尝试在 WorkBuddy 里接入自定义的 **MCP（Model Context Protocol）**插件，希望能把自己熟悉的工具链整合进来，比如连接 fastNotionMCP，或者对接一些已有的数据服务。结果发现，目前 WorkBuddy 并不支持用户自由添加 MCP 或插件。
4. 文件卡在本地，故事卡在半路
还有一个问题，听上去非常琐碎，却极其现实：在 WorkBuddy 里写好的内容，如何方便地从那台电脑，流动到其他设备上？
有一天我在公司，用 WorkBuddy 把一篇博客慢慢打磨好。关机那一刻挺有成就感。
到了地铁上，掏出手机想再读一遍，才反应过来：那篇文章还关在公司那台电脑里，跟我一起下班的，只有空空的手机屏幕。
WorkBuddy 没有内置邮件发送，也没有一键云同步。临时开一个本地 HTTP 服务，只能在内网里访问；一旦离开公司网络，手机就再也够不到它。最后，只有让朋友帮忙通过微信转发文件。
这当然不算什么技术难题，只是和“AI 深度融合”的宏大叙事比起来，显得有点滑稽：我们可以在本地享受复杂的智能补全和任务规划，却还得靠一次次“人工接力”来解决最基础的文件流转。
5. 网络访问的不完整，让信息变得片面
在某些场景下，我会希望 WorkBuddy 能代替我去查一查最新的技术文档，或是看看 GitHub 上某个开源项目的实现。但现实情况是，它对部分网站的访问并不稳定，尤其是 GitHub 这类关键站点，经常出现超时。
这背后牵扯的是网络环境、访问策略乃至合规等更大范围的问题，不能简单归咎于某一个产品。但对最终使用者而言，感受到的只是一个简单的事实：有时候，它看不到我希望它看到的那一部分世界。
二、在限制之内，寻找一些自救的办法
面对这些不尽如人意之处，我并没有立刻卸载 WorkBuddy，而是先把它放在一边，再在它现有的边界内，摸索一些自救的方式。
1. 借第三方平台做“桥”
针对文件跨设备访问的问题，一个朴素但有效的做法，是引入现有的第三方平台，把 WorkBuddy 生成的内容“托管”出去。
语雀、腾讯文档、GitHub Gist、Notion 等工具，各有不同的侧重点：
- 语雀：国内访问顺畅，对 Markdown 友好，适合中长期存放。
- 腾讯文档：在微信里直接打开，适合“路上随手看一眼”的场景。
- GitHub Gist：适合和代码世界保持连接，长期保存也没太大压力。
- Notion：跨平台同步体验不错，但初次配置略有门槛。
它们都不完美，却足以解决“我想在手机上看看刚写好的内容”这样具体而简单的需求。
2. 用脚本补上“缺席的能力”
虽然 WorkBuddy 暂时不支持用户自由添加 MCP 或插件，但这并不意味着所有扩展能力都无路可走。
以 Notion 为例，如果你希望把 WorkBuddy 里生成的内容自动同步过去，可以在本地提前写好一套 Python 脚本，利用 Notion API 做插入或更新操作，把 Token 和数据库 ID 配置好。之后，当一篇文章在 WorkBuddy 里写完，只需要调用这段脚本，就能把内容推送到 Notion 中，手机和平板自然就能看到。
这当然不如“原生集成”来得优雅，却是一种务实的折中方案：让 WorkBuddy 专注在本地的创作体验，把对外的联通交给脚本去完成。一次配置，多次复用，长远看，也算得上是一种“累积性的解决办法”。
3. 把问题讲清楚，然后交给时间
至于模型无法切换、服务高峰期不稳定这些问题，从个人用户的角度，很难找到立刻奏效的对策。我能做的，大概就是在遇到问题时，把场景、次数、影响记录下来，然后通过官方渠道反馈。这听上去有些温吞，却可能比简单的抱怨更有用——很多产品的改进，往往就生长在一条条看似琐碎的使用记录之上。
三、优点依然存在，只是需要被放在恰当的位置上看
说了这么多不足，很容易让人误以为 WorkBuddy 是一个“问题大于价值”的工具。实际上，如果只看它已经做好的那一部分，它依然值得一提。
至少在以下几个方面，它已经交出了一份不错的答卷：
- 代码补全足够聪明：能理解上下文，不是机械地填充标识符，而是帮你补上那些你原本也会写、只是需要时间才能写完的代码。
- 三种工作模式划分清晰：Ask、Craft、Plan 三者的边界让人一眼就能理解，也让你对它“现在准备做什么”有明确预期。
- 界面设计克制、不炫技：上手成本低，不需要学习一套全新的操作习惯，就能开始使用。
- 云服务的基础集成已经铺好：诸如 CloudBase、Supabase 等生态的支持，让它在一些项目里，有机会成为一站式的开发入口。
这些优点并不会因为缺点的存在而消失，只是它们与那些现实的掣肘，会同时被放在同一张天平上权衡。
四、对 WorkBuddy 的期待，也是对 AI 编程助手的期待
如果要用几句话概括我对 WorkBuddy 的期望，大概会落在这几个方向：
- 在关键时刻，不要掉链子——服务稳定性，是一切“智能能力”的地基。
- 在选择上，多给用户一点空间——无论是模型切换，还是扩展接口，都尽量保留一些可自定义的余地。
- 在实际场景里，走得再近一些——文件传输、跨设备访问、网络受限下的信息获取，这些看上去不起眼的细节，往往决定了工具能否真正融入日常。
换个角度看，AI 编程助手之间的竞争，未必在于谁的模型更强、参数更多，而是在于谁更懂得在人与工具之间，留出一个舒适的距离。
WorkBuddy 现在当然谈不上完美，有亮点，也有短板。但它至少做了一件有意义的事：尝试让 AI 不再只是停留在浏览器里的一个对话框，而是变成编辑器中的一位“常驻同事”。
五、写在最后：工具之外，还有人与关系
这篇文章，不是一纸草率的判决书。它只是我个人在特定时间段内，与 WorkBuddy 短暂相处的一份记录。
里面有惊喜，也有失望；有顺畅的时刻，也有上下文被清空的无奈。
在我的日常里，Trae 更像是一位已经融入工作流的“老同事”，擅长啃复杂代码、整理长期上下文；WorkBuddy 则是刚刚加入团队的新伙伴，把 AI 尽量安顿进编辑器本身。前一篇写 OpenClaw，更多是在想象“手”能伸多远；这一篇写 WorkBuddy，则是在观察 AI 如何坐进桌面。而把这两者和 Trae 放在一起看，恰好勾勒出一条从远程控制，到编辑器一体化，再到深度工程助手的光谱。
我并不急着给 WorkBuddy 贴上“好”或“不好”的标签。AI 编程助手这个方向本身还在快速变化，今天的缺陷，可能在下一次更新里就有了一个还算体面的补丁。
对我而言，更重要的是在这个过程中，慢慢摸索出一种新的相处方式：既不过度依赖，也不过度防备；既看到工具的局限，也承认它带来的真实帮助。
毕竟，工具终究是拿来用的，而不是拿来崇拜或憎恨的。至于 WorkBuddy 和 Trae 各自会走向哪里，就交给时间和使用它们的人来回答吧。