1. 从热搜词看 WorkBuddy 的真实使用场景先把热搜词摊开来看会发现一个很有意思的现象搜workbuddy使用教程、workbuddy安装教程、workbuddy下载的人和搜workbuddy缓存目录怎么更改、workbuddy 搬迁项目 win、ubuntu安装workbuddy的人其实是两拨完全不同的用户。前者是刚听说这个工具、想上手试试的新人后者是已经用了一段时间、开始遇到工程化问题的老用户。而workbuddy和codebuddy、workbuddy 科研、workbuddy 小程序教学应用案例这几个词又暴露出第三类需求——想知道这东西到底能用在哪些具体场景里。我自己是从去年开始把 WorkBuddy 当作日常工作台来用的中间踩过缓存目录爆盘、Windows 项目搬迁路径错乱、Linux 下装完是英文界面这些坑。所以这篇不打算写成一份官方文档的复述而是按一个真实用户从装到用、从用到调优的顺序把 WorkBuddy 这个工作台讲透顺带把 Space-Bunny 这个匿名模型接入之后带来的变化说清楚。WorkBuddy 本质上是一个面向开发者和科研人员的本地工作台它把项目管理、代码编辑、模型调用、任务编排这几件事收拢到一个界面里。你可以把它理解成一个带 AI 能力的项目容器——你往里丢项目它帮你管依赖、管缓存、管模型调用。而 Space-Bunny 是这次独家接入的匿名模型主打的是在不上传敏感上下文的前提下完成推理任务这对科研和涉及内部代码的场景比较友好。适合谁看这篇刚下载完 WorkBuddy 还没搞明白界面的人、想把现有项目迁进 WorkBuddy 的人、被缓存目录和语言设置折腾过的人以及想知道 Space-Bunny 到底值不值得在折扣期入手的人。下面按实际使用链路往下讲。2. 安装这一步Windows 和 Ubuntu 的坑完全不一样2.1 Windows 安装别急着点下一步Windows 下的安装包本身没什么难度双击、选路径、等进度条。但有两个细节决定了你后面顺不顺。第一个是安装路径不要带中文和空格。我见过有人装在D:\我的工具\WorkBuddy 工作台\下面结果后面调用模型时路径解析直接报错。原因是 WorkBuddy 内部有些组件走的是命令行调用中文路径在编码转换时会出问题。稳妥做法是D:\WorkBuddy\这种纯英文短路径。第二个是首次启动会让你选工作区根目录。这个目录后面会存放所有项目的缓存、索引和临时文件默认在 C 盘用户目录下。如果你 C 盘本来就紧张这一步就要改掉别等装完再迁移。我第一台机器就是没注意用了两周 C 盘少了 30 多个 G全是索引缓存。安装完成后如果界面是英文的别慌这不是装错了版本。workbuddy下载后是英文版这个搜索词说明很多人遇到过。语言切换在设置里的Appearance或者Language项切完要重启一次才生效。有些版本的语言包是懒加载的第一次切换会卡几秒正常现象。2.2 Ubuntu 安装依赖和权限是两道坎ubuntu安装workbuddy这个需求背后通常是想在服务器或者开发机上跑。Linux 下的安装和 Windows 逻辑不同它更依赖系统级的运行库。我实测下来Ubuntu 20.04 和 22.04 都能装但 22.04 更省心。安装前先确认几个依赖sudo apt update sudo apt install -y libgtk-3-0 libnotify4 libnss3 libxss1 libxtst6 xdg-utils libatspi2.0-0 libsecret-1-0这几行不是随便列的。libgtk-3-0是界面渲染的基础缺了直接白屏libnss3关系到网络请求的证书校验libsecret-1-0是凭据存储用的缺了会导致登录状态存不住每次开都要重新登录。我一开始只装了前两个结果登录态一直丢排查了半天才发现是libsecret没装。安装包给的是.deb用sudo dpkg -i装完之后如果提示依赖不满足再补一句sudo apt install -f自动修复。装完第一次启动建议用普通用户身份不要用 root否则生成的配置文件属主是 root后面普通用户改设置会没权限。提示Ubuntu 下如果启动后界面是英文除了在设置里切语言还要确认系统装了中文语言包sudo apt install language-pack-zh-hans否则 WorkBuddy 读不到中文选项。2.3 安装后的第一件事确认缓存目录在哪不管哪个平台装完第一件事我都建议先找到缓存目录。因为后面workbuddy缓存目录怎么更改这个问题你得先知道默认在哪才能改。Windows 默认C:\Users\你的用户名\AppData\Roaming\WorkBuddy\cacheUbuntu 默认~/.config/WorkBuddy/cachemacOS 默认~/Library/Application Support/WorkBuddy/cache找到之后先看一眼体积。如果刚装完就几百兆那是正常的索引文件如果用了几天涨到几十 G就该考虑迁移了。下一节专门讲怎么改。3. 缓存目录迁移为什么直接剪切文件夹会出事3.1 缓存目录到底存了什么很多人以为缓存就是临时文件删了无所谓。WorkBuddy 的缓存目录里其实混着三类东西性质完全不同内容类型作用能否直接删项目索引加速代码搜索和跳转可删但删后首次打开项目会重建慢模型调用缓存存 Space-Bunny 等模型的推理结果可删但重复问题会重新计费会话与配置快照保存工作台状态、插件配置不能删删了配置丢失这就是为什么不能简单粗暴地剪切文件夹到 D 盘再改个路径。因为配置快照里存的是绝对路径你把文件夹挪走WorkBuddy 启动时按老路径找不到就会重新初始化一份空配置你之前的插件设置、模型偏好全没了。3.2 正确的迁移姿势正确做法是先改配置指向新路径再迁移数据最后删旧目录。顺序错了就出问题。第一步完全退出 WorkBuddy包括托盘里的后台进程。Windows 下可以在任务管理器确认没有残留进程。第二步找到配置文件。Windows 在%APPDATA%\WorkBuddy\config.jsonUbuntu 在~/.config/WorkBuddy/config.json。用文本编辑器打开找到类似这样的字段{ cacheDir: C:/Users/yourname/AppData/Roaming/WorkBuddy/cache, workspaceRoot: C:/Users/yourname/WorkBuddyProjects }把cacheDir改成新路径比如D:/WorkBuddyCache。注意 Windows 下路径用正斜杠或者双反斜杠单反斜杠会被当成转义符。第三步把旧缓存目录里的内容复制不是剪切到新路径。复制完先别删旧的。第四步启动 WorkBuddy随便打开一个项目确认索引正常、模型调用正常。确认没问题了再回去删旧目录。我踩过的坑是第二步和第三步顺序反了先挪了文件夹再改配置结果启动后配置重置插件全没了重新配了半小时。所以顺序一定要记牢。3.3 用软链接的偷懒方案如果你不想改配置还有个取巧办法把旧缓存目录整个移到新盘然后在原位置建一个软链接指过去。Windows 下需要管理员权限mklink /J C:\Users\yourname\AppData\Roaming\WorkBuddy\cache D:\WorkBuddyCacheUbuntu 下mv ~/.config/WorkBuddy/cache /data/workbuddy-cache ln -s /data/workbuddy-cache ~/.config/WorkBuddy/cache这样 WorkBuddy 以为缓存还在老地方实际数据在新盘。好处是不用改配置、不怕配置重置坏处是软链接在某些备份工具里会出问题而且换机器时要重新建。我个人在开发机上用软链接在主力工作机上用改配置的方式看你更在意省事还是更在意干净。4. 项目搬迁到 WorkBuddyWindows 下的路径陷阱4.1 为什么搬迁项目 win是个高频问题workbuddy 搬迁项目 win这个词能上热搜说明大量用户是想把已有的项目从别的编辑器或旧目录迁进 WorkBuddy 的工作区。这件事听起来就是复制粘贴但 Windows 下有几个隐藏问题。第一个是依赖路径。很多项目里的配置文件比如 Python 的虚拟环境、Node 的node_modules里存的是绝对路径。你把项目从D:\old\project挪到D:\WorkBuddy\project这些路径就失效了。表现是项目能打开但一跑就报模块找不到。第二个是大小写敏感。Windows 文件系统不区分大小写但有些项目里import Foo和文件名foo.py混用在 Windows 下能跑迁到 WorkBuddy 如果开了某种严格模式就会报错。这个坑比较隐蔽。第三个是长路径限制。Windows 默认路径长度上限 260 字符WorkBuddy 的工作区如果嵌套很深加上node_modules那种超长目录很容易超限。表现是复制到一半报错。4.2 搬迁的标准流程我的做法是分三步走不直接拖文件夹。第一步在新位置重建项目而不是复制。对于有版本控制的项目直接git clone到 WorkBuddy 工作区这样依赖路径是干净的。对于没有版本控制的先复制源码文件排除node_modules、venv、__pycache__这些再在新位置重新装依赖。第二步重建虚拟环境。Python 项目删掉旧的venv重新python -m venv venvNode 项目删掉node_modules重新npm install。这一步多花几分钟但能避免 90% 的路径问题。第三步在 WorkBuddy 里用导入现有项目而不是新建项目。导入时它会扫描项目结构、建索引比新建再手动指路径靠谱。如果项目路径确实很深可以在 Windows 上开启长路径支持reg add HKLM\SYSTEM\CurrentControlSet\Control\FileSystem /v LongPathsEnabled /t REG_DWORD /d 1 /f改完要重启。这个注册表项是系统级的开了之后所有程序都受益。4.3 搬迁后必做的三项检查迁完之后别急着写代码先做三个检查跑一次构建或测试。哪怕只是npm run build或者pytest能跑通说明依赖路径没问题。检查 WorkBuddy 的索引状态。在项目面板看索引是否完成没完成的话代码跳转会不准。确认模型调用正常。随便问 Space-Bunny 一个关于当前项目的问题看它能不能读到项目上下文。这三项过了搬迁才算真正完成。我见过有人迁完直接开写写到一半发现跳转全乱回头排查更费时间。5. Space-Bunny 接入后工作台的用法变了什么5.1 匿名模型解决的是什么问题space-bunny是什么公司的、space-bunny模型、space-bunny官网这几个词说明大家对它的来历和定位还不清楚。从实际使用角度看Space-Bunny 的核心卖点是匿名推理——你的上下文在推理过程中不会被关联到具体身份也不会被用于训练。这对两类人特别有用。一类是科研人员workbuddy 科研这个搜索词背后就是他们实验数据、未发表的思路不想外泄。另一类是处理内部代码的开发者公司代码不能随便往外部模型送。Space-Bunny 的匿名机制让这两类场景能放心用。但要注意匿名不等于绝对安全。我的建议是真正敏感的密钥、密码、个人身份信息任何模型都不要喂。匿名模型解决的是上下文关联层面的隐私不是内容本身层面的。这个边界要清楚。5.2 在 WorkBuddy 里怎么调用 Space-Bunny接入方式比想象中简单。WorkBuddy 的模型设置里会多出一个 Space-Bunny 的选项选中之后工作台里的 AI 对话、代码补全、项目问答都会走这个模型。具体路径设置 → 模型管理 → 添加模型 → 选择 Space-Bunny → 填入接入凭证。凭证从哪来取决于你的获取渠道折扣期通常会有对应的兑换流程。调用时有个细节值得说Space-Bunny 对上下文长度的处理和普通模型不太一样。它更擅长处理结构化的项目上下文也就是你通过 WorkBuddy 的引用项目功能带进去的内容而不是你手动粘贴一大段代码。所以用的时候尽量用工作台的项目引用功能而不是复制粘贴效果会好很多。5.3 折扣期值不值得入手标题里说限时折扣到 10 月 7 日。我的判断逻辑是这样的如果你已经在用 WorkBuddy 做日常开发且对隐私有要求那折扣期入手是划算的因为你会高频使用摊薄下来成本低。如果你只是好奇想试试那先想清楚自己有没有匿名推理的真实需求——没有需求的话再便宜也是浪费。workbuddy和codebuddy这个搜索词说明有人在对比同类工具。我的看法是WorkBuddy 的定位更偏工作台项目容器CodeBuddy 更偏纯编码助手。如果你需要的是把项目管理、模型调用、任务编排揉在一起WorkBuddy 更合适如果你只要一个写代码时的补全工具那可能另一个更轻。Space-Bunny 的接入是 WorkBuddy 的加分项但不是唯一决定因素。6. 科研和小程序教学两个被低估的用法6.1 科研场景下的工作台配置workbuddy 科研这个需求我理解下来核心是数据管理 可复现。科研项目的特点是数据文件大、实验脚本多、需要记录每次实验的参数和结果。用 WorkBuddy 做科研我建议这样配把每个实验作为一个独立项目导入而不是所有实验堆在一个大项目里。这样索引清晰模型问答时上下文也干净。用工作台的任务功能记录实验步骤每次跑实验前把参数写进任务描述。Space-Bunny 可以基于这些描述帮你生成实验记录草稿。缓存目录单独指到大容量盘。科研数据动辄几十 G缓存和索引会跟着涨别放系统盘。有个细节科研代码里经常有matplotlib画图、pandas读大文件这类操作WorkBuddy 的索引可能会把这些数据文件也扫进去导致索引体积暴涨。可以在项目设置里把数据目录加入忽略列表只索引代码。6.2 小程序教学应用案例的落地思路workbuddy 小程序教学应用案例这个词挺具体说明有老师在用 WorkBuddy 教小程序开发。这个场景我觉得 WorkBuddy 的优势在于统一环境。教学最头疼的是学生环境不一致有人 Node 版本不对有人依赖装不上。用 WorkBuddy 的话可以把项目模板和依赖配置固化下来学生导入即用。老师这边可以用 Space-Bunny 生成教学用的示例代码和讲解因为匿名机制学生的作业代码也不会被关联。具体做法老师建一个标准的小程序项目模板配好package.json和构建脚本放进 WorkBuddy 工作区。学生导入后WorkBuddy 会自动识别项目类型、提示装依赖。遇到报错时学生可以直接问工作台里的 Space-Bunny它会结合项目上下文给建议比单纯搜报错信息精准。注意教学场景下建议关闭模型的自动代码修改功能只让它给建议。否则学生容易直接接受修改学不到排查过程。7. 那些文档里不会写的实操心得7.1 关于语言和版本的坑workbuddy下载后是英文版这个问题除了前面说的语言设置还有一种情况是下载到了国际版。workbuddy 国际版这个搜索词说明确实存在版本差异。国际版默认英文且部分功能比如某些模型接入和国内版不同。如果你需要中文界面和完整的模型接入确认下载的是对应版本。判断方法看安装包文件名和设置里的关于页面。国际版通常会在版本号后面带区域标识。装错了就卸载重装别想着在设置里硬切有些功能模块是编译期决定的切不过来。7.2 缓存清理的正确频率缓存目录不是越勤清理越好。我的经验是索引缓存不用主动清WorkBuddy 会在项目变更时增量更新。只有索引明显变慢或出错时才清。模型调用缓存如果 Space-Bunny 是按调用计费的这个缓存能帮你省钱重复问题直接命中缓存不重新计费。别乱清。日志文件这个可以定期清一般放在缓存目录的logs子目录下超过一个月的可以删。我一般一个月看一次缓存体积超过 20G 就检查是不是有异常增长。正常使用的话一个中等规模项目加日常模型调用缓存稳定在 5-10G 是合理的。7.3 多平台同步的注意事项如果你在 Windows 和 Ubuntu 上都用 WorkBuddyworkbuddy switch这个需求可能就是指切换平台。跨平台同步项目时注意两点一是换行符。Windows 用 CRLFLinux 用 LFGit 配置里最好设core.autocrlf否则每次切换平台都显示整个文件被修改。二是路径分隔符。项目里如果有硬编码的路径跨平台必挂。用相对路径或者语言提供的路径处理库别手写\或/。三是缓存不要同步。缓存目录里存的是平台相关的索引跨平台同步会出问题。每个平台各自维护自己的缓存项目源码通过 Git 同步就够了。7.4 关于折扣期的理性建议最后说回折扣这件事。限时折扣到 10 月 7 日这种时间压力容易让人冲动。我的建议是先算清楚你的使用频率。如果你每天都会用 WorkBuddy 处理项目那折扣期买是省钱的如果你一周用不了一次那折扣对你意义不大先把手头的免费额度用明白再说。Space-Bunny 的匿名特性是真需求还是伪需求也只有你自己清楚。我见过有人冲着匿名买了结果发现自己根本没什么敏感内容要处理纯属被概念吸引。工具是拿来解决问题的不是拿来收藏的。我自己是在确认了每周至少三次的科研项目问答需求之后才决定在折扣期续的用下来 Space-Bunny 在长上下文项目问答上的表现确实比通用模型稳尤其是它能记住整个项目的结构不用每次重新解释。这个体验上的差异才是我愿意付费的真正原因。
