1. 为什么我要认真写这篇 WorkBuddy 实战指南第一次接触 WorkBuddy 是在一个赶项目的深夜。当时手头堆着三份文档要整理、两个数据表要合并、还有一堆重复性的文件重命名工作整个人处于一种机械劳动把人逼疯的状态。朋友甩过来一句你试试 WorkBuddy腾讯出的 AI 工作台我抱着试试看的心态装上了结果那一晚我少熬了两个小时。从那之后我开始系统性地研究这个东西——它到底能干什么、怎么配置才顺手、哪些坑必须提前避开。WorkBuddy 是腾讯推出的一款 AI 工作台产品核心定位是把 AI Agent 的能力封装成一个可以日常使用的桌面工具。你可以把它理解成一个能听懂人话、能动手干活的助手它不只是聊天还能读写文件、执行命令、调用各种 Skill 来完成具体任务。和它经常被一起提起的还有 CodeBuddy两者同源但侧重点不同——CodeBuddy 更偏向代码开发场景WorkBuddy 则把触角伸向了更广泛的工作场景文档处理、数据分析、自动化流程都能覆盖。这篇文章适合几类人看刚听说 WorkBuddy 想上手但不知道从哪开始的新手已经装了但配置一直没搞明白、用起来磕磕绊绊的 intermediate 用户以及想把它用到团队工作流里、需要了解自定义模型配置和 Skill 机制的技术负责人。我会从安装讲到配置从核心功能讲到避坑经验把这一路踩过的坑和总结出来的技巧都摊开说。全文基于我自己的实际使用和反复测试不是官方文档的复述而是一个真实用户怎么把它用顺手的记录。2. 安装与初始配置从零到能跑起来2.1 安装前的环境确认与版本选择装 WorkBuddy 之前有几件事必须先确认清楚否则装到一半卡住会非常难受。首先是操作系统版本WorkBuddy 目前对 Windows 和 macOS 都有支持Linux 用户也有对应的安装包但不同平台的安装方式和依赖略有差异。Windows 建议 Win10 1903 及以上macOS 建议 12 以上Linux 则要看具体的发行版和桌面环境。其次是磁盘空间。WorkBuddy 本体安装包不算大但它的系统缓存目录会随着使用不断增长——尤其是你频繁让它处理大文件、生成内容的时候。我见过有人 C 盘只剩几个 G 就硬装结果用了两周系统盘爆红。所以安装前至少预留 10GB 以上的可用空间如果你打算重度使用20GB 更稳妥。版本选择上WorkBuddy 有国内版和国际版之分。国内版在模型接入、网络环境适配上更贴合国内用户国际版则在某些模型和服务的可及性上有差异。如果你主要处理中文内容、使用国内常用的办公文件格式国内版是更自然的选择。国际版适合有跨境协作需求、或者需要调用特定海外模型的场景。两个版本的核心功能框架是一致的差异主要在模型池和服务接入层面。提示不要同时安装国内版和国际版到同一台机器上两者的缓存目录和配置文件可能产生冲突导致启动异常。如果确实需要两个版本建议装在不同的用户账户下或者用虚拟机隔离。2.2 安装步骤与首次启动的关键设置安装过程本身不复杂下载对应平台的安装包双击运行按提示走就行。但有几个细节值得单独拎出来说。Windows 平台安装时如果系统弹出了 SmartScreen 拦截提示这是正常现象选择仍要运行即可。安装路径建议不要选默认的 C 盘 Program Files改到一个空间充裕的分区比如 D 盘或 E 盘。原因很简单后续缓存目录默认也在 C 盘用户目录下两个大头挤在一起C 盘压力太大。macOS 平台安装后首次启动可能会提示无法验证开发者这时候去系统设置 - 隐私与安全性里点仍要打开就行。Linux 平台如果是用安装包方式注意依赖库的完整性缺库的话启动会直接报错根据报错信息补装对应的依赖即可。首次启动后WorkBuddy 会引导你做一些初始设置。这里有几个关键选择登录方式支持账号登录登录后可以同步部分配置和积分信息。如果你打算用它的积分体系来调用某些高级能力登录是必须的。工作目录设置这是最重要的一步。WorkBuddy 需要一个默认的工作目录它后续读写文件、执行任务都会在这个目录及其子目录下进行。建议单独建一个目录比如D:\WorkBuddyWorkspace不要直接指向你的桌面或者文档根目录否则文件管理会非常混乱。模型配置首次启动通常会让你选择默认模型。如果你还没有自定义模型的需求先用内置的默认模型跑起来后面再改。2.3 系统缓存目录迁移到 D 盘的正确姿势这是被问得最多的一个问题WorkBuddy 的系统缓存目录能改到 D 盘吗答案是能而且强烈建议改。默认情况下WorkBuddy 的缓存目录在用户目录下Windows 上是C:\Users\你的用户名\.workbuddy或类似路径macOS 上是~/.workbuddy。这个目录会存放模型缓存、临时文件、日志、Skill 运行产生的中间数据等等。用久了轻松几个 G 甚至十几个 G。迁移方法有两种。第一种是在 WorkBuddy 的设置界面里找缓存目录或存储路径选项直接改成你想要的路径。这是最干净的方式改完之后新产生的缓存就会写到新位置。第二种是如果设置界面没有提供这个选项某些版本确实没有可以通过创建符号链接的方式把默认目录骗到 D 盘先把原目录整个剪切到 D 盘目标位置然后在原位置创建一个指向新位置的符号链接。Windows 上用mklink /J命令macOS 和 Linux 上用ln -s。# Windows 示例需要管理员权限的命令行 mklink /J C:\Users\你的用户名\.workbuddy D:\WorkBuddyCache # macOS / Linux 示例 ln -s /Volumes/Data/WorkBuddyCache ~/.workbuddy注意做符号链接之前一定要先关闭 WorkBuddy否则文件被占用会导致操作失败。另外迁移完成后第一次启动可能会重新下载一些缓存这是正常的不要以为出问题了。3. 核心功能拆解AI Agent 到底怎么干活3.1 从聊天到执行Agent 模式的工作逻辑很多人第一次用 WorkBuddy 会把它当成一个聊天机器人问它问题、让它写点东西然后觉得也就那样。这就完全没用到它的核心能力。WorkBuddy 的真正价值在于 Agent 模式——它不只是生成文本而是能规划任务、调用工具、操作文件、执行命令最终交付一个具体的结果。举个例子。你让它把这个文件夹里所有的 Word 文档转成 PDF然后按修改日期重命名在聊天模式下它只会告诉你你可以用某某工具来做但在 Agent 模式下它会自己去读文件夹、识别文件、调用转换能力、执行重命名最后告诉你完成了一共处理了 12 个文件。这个差别是本质性的。Agent 的工作逻辑大致是这样的接收任务后先做任务分解把一个大目标拆成若干可执行的步骤然后逐步执行每一步可能涉及读取文件、调用 Skill、执行命令、生成内容执行过程中会根据中间结果动态调整最后汇总输出。这个过程中它会和你确认关键决策点比如我准备删除这三个文件确认吗——这个确认机制很重要是防止误操作的最后一道防线。理解了这个逻辑你就知道该怎么给它下指令了。模糊的指令会得到模糊的结果具体的、带约束条件的指令才能让它精准执行。比如帮我整理一下文件就不如把 Downloads 文件夹里所有超过 30 天没修改过的安装包移到 D 盘的 Archive 文件夹来得有效。3.2 Skill 机制WorkBuddy 的能力扩展核心Skill 是 WorkBuddy 最值得深入研究的机制。你可以把 Skill 理解成插件或者技能包——每一个 Skill 封装了一类特定的能力WorkBuddy 在执行任务时按需调用。内置的 Skill 覆盖了常见场景文件操作、文档处理、数据分析、网页内容抓取、代码执行等等。但真正让 WorkBuddy 变得强大的是它支持自定义 Skill 和 MCP Skill。MCP 是一种标准化的能力接入协议通过它可以把外部工具、API、服务接入到 WorkBuddy 的工作流里。哪些 Skill 最好用根据我的实际使用频率排在前面的有Skill 类型典型用途使用频率文件操作类批量重命名、格式转换、目录整理极高文档处理类Word/PDF/Excel 内容提取与生成高网页抓取类获取网页内容、结构化数据提取中高代码执行类运行脚本、数据处理、自动化任务中自定义 MCP Skill接入内部系统、特定 API按需自定义 Skill 的配置通常在 WorkBuddy 的 Skill 管理界面里进行你需要提供 Skill 的名称、描述、触发条件、执行逻辑可能是一段脚本或一个 API 调用配置。描述写得越清晰WorkBuddy 越容易在合适的时机调用它。实操心得给自定义 Skill 写描述时不要只写这个 Skill 能做什么还要写什么时候该用它。比如当用户要求处理 Excel 文件且涉及多表合并时使用此 Skill这样能显著提高调用的准确率。3.3 自定义模型配置与 models.json 详解WorkBuddy 支持自定义模型配置这是它区别于很多同类产品的一个亮点。你可以接入自己的模型服务而不局限于内置的模型池。配置文件通常是models.json放在配置目录下。这个文件的结构大致是这样的一个模型列表每个模型包含名称、类型、接入地址、认证信息、参数等字段。下面是一个示例结构具体字段名以你使用的版本为准{ models: [ { name: my-custom-model, provider: openai-compatible, baseUrl: https://your-model-endpoint/v1, apiKey: your-api-key, model: model-name, maxTokens: 4096, temperature: 0.7 } ] }配置自定义模型时有几个关键点。第一baseUrl要填对很多接入问题都出在这里——少个斜杠、多个路径都会导致调用失败。第二apiKey的权限要确认有些 key 只能调特定模型。第三maxTokens和temperature要根据你的使用场景调做文档处理时 temperature 低一点更稳定做创意生成时可以高一点。改完models.json后需要重启 WorkBuddy 才能生效。如果重启后模型列表里没出现你配置的模型先检查 JSON 格式是否合法可以用在线的 JSON 校验工具过一遍再检查网络是否能通到baseUrl。3.4 跨对话记忆与自定义指令让 WorkBuddy 记住你的习惯WorkBuddy 有一个跨对话记忆的能力配合自定义指令使用效果很好。跨对话记忆的意思是你在一次对话里告诉它的偏好、规则、背景信息它可以在后续的对话里继续沿用而不是每次都要重新说一遍。自定义指令则是你预先设定好的一组规则比如回答时优先用中文、处理文件时先备份再操作、生成文档时使用 Markdown 格式。这些指令设定一次后续对所有任务都生效。我自己的自定义指令里有一条是任何删除操作前必须先列出待删除文件清单并等待确认这条规则帮我避免过至少两次误删。还有一条是处理 Excel 时默认保留原始文件输出到新文件也是血泪教训换来的。设置路径一般在设置界面的指令或偏好区域。写指令的原则是具体、可执行、有明确的触发条件。不要写认真一点这种模糊的话要写每次生成代码后附上运行说明这种能直接落地的规则。4. 实操全流程从任务下达到结果交付4.1 一个完整任务的执行过程拆解光说概念没意思我拿一个真实做过的任务来完整走一遍。任务背景我有一批从各处收集来的 PDF 文献大概 40 多篇文件名乱七八糟需要整理成统一的命名格式提取每篇的标题和作者信息生成一个索引表。第一步我把所有 PDF 放到工作目录下的papers文件夹里然后在 WorkBuddy 里下达任务读取 papers 文件夹下所有 PDF提取每篇的标题、作者、年份按年份-作者-标题的格式重命名文件并生成一个 index.md 索引表。第二步WorkBuddy 开始规划。它先列出了它打算执行的步骤扫描文件夹、逐个读取 PDF、提取元数据、重命名、生成索引。然后它问我部分 PDF 可能没有完整的元数据遇到这种情况怎么处理我回复用文件名里的信息尽量推断推断不出来的标记为 unknown。第三步执行。这个过程花了大概几分钟它逐个处理文件中间有几次停下来问我确认——比如有两个文件提取出的标题完全一样它问是不是重复文件。这种交互设计很合理避免了它自作主张。第四步交付。最后它生成了index.md里面是一个表格包含原始文件名、新文件名、标题、作者、年份。我检查了一遍40 多篇里有 3 篇标记为 unknown手动补了一下其余都准确。这个流程走下来我大概花了 10 分钟如果手动做至少两个小时。这就是 Agent 模式的价值——它不是替你想而是替你做。4.2 参数计算与选择以批量文件处理为例在批量处理任务里有几个参数需要你根据实际情况做选择选错了要么效率低要么出问题。并发数WorkBuddy 处理批量任务时可能会并发执行。并发数高了快但对系统资源占用大而且如果任务涉及外部 API 调用可能触发限流。我的经验是纯本地文件操作可以开到 4-8 并发涉及网络请求的降到 2-3。超时时间单个文件的处理超时设置。默认值通常够用但如果你处理的是超大文件比如几百 MB 的 PDF需要适当调大。计算方式很简单估算单个文件平均处理时间乘以 3 作为超时值。重试次数遇到临时性错误比如文件被占用时的重试次数。建议设 2-3 次太多会拖慢整体进度太少容易因为偶发问题失败。输出编码处理中文文件时编码问题是大坑。统一用 UTF-8如果源文件是 GBK 编码需要先转换。这个在 WorkBuddy 里可以通过指令指定所有文本输出使用 UTF-8 编码。这些参数在哪里调一部分在设置界面的高级选项里一部分可以在任务指令里直接指定。我倾向于在指令里指定因为不同任务的需求不一样全局设置改来改去反而乱。4.3 生成网站并发布WorkBuddy 的进阶用法WorkBuddy 有一个让我比较惊喜的能力它可以帮你从零生成一个静态网站并发布。流程大致是你描述网站的需求它生成 HTML/CSS/JS 文件然后通过集成的发布能力把网站部署出去。我试过一次需求是做一个个人作品集页面包含头像、简介、三个项目卡片、联系方式风格简洁现代。它生成的页面结构清晰样式也过得去我改了几个颜色和间距就用了。发布环节它会引导你选择发布方式按提示操作即可。这个功能的实用场景包括快速做 landing page、做活动页面、做个人简历页。不适合做复杂的动态网站但对于静态展示类需求效率很高。注意生成网站后一定要在本地预览确认检查移动端适配和链接有效性。AI 生成的代码偶尔会有小问题比如某个 CSS 属性写错导致布局错乱提前发现比发布后再改省事。4.4 本地部署与私有化部署的考量对于有数据安全要求或者想深度定制的用户WorkBuddy 支持本地部署和私有化部署。本地部署指的是把 WorkBuddy 运行在你自己的机器上数据不出本地私有化部署则是部署到内部服务器供团队使用。本地部署的要点确认机器配置够用主要是内存和磁盘模型可以选择本地运行的模型或者接入外部模型服务。如果选本地模型对硬件要求会高不少尤其是想跑大参数模型的时候。私有化部署涉及的东西更多服务器环境准备、依赖安装、配置管理、用户权限、日志审计等等。如果团队规模不大我建议先用本地部署跑一段时间确认工作流顺畅了再考虑私有化。私有化部署的维护成本不低不要为了看起来专业而过度工程。Docker 部署是一种常见方式把 WorkBuddy 及其依赖打包成容器部署和迁移都方便。如果你熟悉 Docker这条路会顺很多。5. 避坑指南那些我踩过的坑和总结的经验5.1 安装与配置阶段的常见问题问题一启动后一直转圈进不去界面。最常见的原因是缓存目录权限问题或者缓存文件损坏。解决办法关闭 WorkBuddy找到缓存目录把里面的临时文件和锁文件删掉不要删配置文件重启。如果还不行把整个缓存目录重命名备份让它重新生成。问题二自定义模型配置后不生效。按这个顺序排查JSON 格式是否合法 → baseUrl 是否可达用 curl 或浏览器访问一下→ apiKey 是否有效 → 模型名称是否拼写正确 → 是否重启了 WorkBuddy。90% 的问题出在前两步。问题三中文乱码。在指令里明确指定编码或者在设置里把默认编码改成 UTF-8。如果处理的是 Windows 下生成的 GBK 文件需要先转码再处理。问题四积分不够用。WorkBuddy 的部分高级能力消耗积分。省积分的技巧把复杂任务拆成简单任务分步执行避免让它做无意义的重复操作善用本地 Skill 减少模型调用。5.2 使用过程中的典型故障与排查现象可能原因排查方法解决方式任务执行到一半卡住某个文件被占用或损坏查看日志最后一条记录跳过问题文件单独处理生成内容质量差指令太模糊或模型选择不当检查指令具体程度细化指令换更合适的模型Skill 调用失败Skill 配置错误或依赖缺失查看 Skill 日志重新配置或补装依赖响应速度突然变慢缓存过大或系统资源紧张查看缓存目录大小和内存占用清理缓存关闭其他程序文件操作结果不符合预期路径理解偏差或权限不足检查实际文件系统状态明确路径确认权限排查的核心思路是先看日志再看配置最后看环境。WorkBuddy 的日志通常在缓存目录下的logs文件夹里出问题时第一时间去看比瞎猜有效得多。5.3 安全审核与使用边界WorkBuddy 有安全审核机制某些操作会被拦截或要求确认。这是好事不要想着绕过它。我理解有些用户会觉得审核太严影响效率但从实际使用来看真正被拦的往往是确实有风险的操作比如批量删除、修改系统文件、执行来源不明的脚本。使用边界方面我的建议是不要让 WorkBuddy 直接操作你唯一一份的重要数据先备份不要给它系统级的管理员权限用普通用户权限跑就行涉及敏感信息的任务确认数据流向必要时用本地部署模式。5.4 和其他工具的比较WorkBuddy、CodeBuddy、Trae 怎么选经常有人问这几个工具怎么选。我的看法是看场景WorkBuddy通用工作场景文档处理、数据分析、自动化流程、内容生成。适合非纯开发岗位的职场人。CodeBuddy代码开发场景写代码、调试、代码审查、项目管理。适合开发者。Trae也是开发向的工具在某些开发工作流上有自己的特色。如果你主要写代码CodeBuddy 或 Trae 更对口如果你做的是综合性的工作需要处理各种类型的任务WorkBuddy 更合适。当然这几个工具并不是互斥的很多人是组合使用。6. 进阶技巧把 WorkBuddy 用出花来6.1 自定义指令的黄金法则写自定义指令有几个原则是我反复调整后总结出来的。第一条规则要可判定。认真处理这种没法判定每次输出前检查文件是否存在这种可以判定。可判定的规则才能被稳定执行。第二条规则要分层。全局规则放设置里任务级规则在指令里说。不要把任务级的规则写到全局设置里会互相干扰。第三条规则要精简。我见过有人写了三十多条自定义指令结果 WorkBuddy 执行时顾此失彼。核心规则控制在 5-8 条覆盖最高频的场景就够了。第四条定期复盘。用一段时间后回顾哪些规则真正起了作用哪些从来没触发过把没用的删掉。6.2 用 WorkBuddy 写文献综述的实操写文献综述是 WorkBuddy 的一个高频使用场景。我的流程是这样的先把相关文献的 PDF 放到一个文件夹让 WorkBuddy 提取每篇的核心观点、研究方法、结论。然后让它按主题聚类生成一个初步的综述框架。接着针对每个主题让它整合多篇文献的观点生成段落初稿。最后我自己通读修改补充批判性分析和自己的观点。这个流程里WorkBuddy 承担的是信息提取和初步整合的工作我承担的是判断和深化的部分。不要指望它直接生成一篇能用的综述但它能把最耗时的信息整理环节压缩到原来的十分之一。实操心得让它提取文献信息时明确要求引用原文关键句这样后续核对和引用时方便得多。另外让它标注每篇文献的来源信息避免后续找不到出处。6.3 团队协作场景下的配置建议如果要在团队里推广 WorkBuddy有几个配置建议。统一工作目录规范约定好项目文件放在哪、输出放在哪、临时文件放在哪。目录结构清晰了协作才顺畅。共享自定义指令把团队通用的规则整理成一份指令模板新成员直接导入减少重复配置。Skill 共享把团队常用的自定义 Skill 导出分享保证大家用的是同一套能力。权限管理如果涉及敏感数据明确哪些任务可以用云端模型哪些必须用本地模型。版本统一尽量让团队成员用同一个版本避免因为版本差异导致的行为不一致。7. 我个人的一些使用体会用 WorkBuddy 这段时间最大的感受是它的价值不在于替代人而在于把人从机械劳动里解放出来。那些重复性的、规则明确的、不需要创造性判断的工作交给它做效率提升是数量级的。但需要判断、需要权衡、需要创造性的部分还是得人来。另一个体会是工具的上限取决于使用者的指令能力。同样一个 WorkBuddy有人用起来觉得不过如此有人用起来觉得效率翻倍差别就在会不会下指令、会不会配置。这东西有点像开车车本身性能差不多但老司机和新手开出来的效果完全不同。最后分享一个小技巧每次完成一个比较复杂的任务后让 WorkBuddy 把这次的任务流程总结成一个可复用的模板或者 Skill。下次遇到类似任务直接调用省去重新描述的时间。这个习惯坚持下来你的 WorkBuddy 会越来越懂你用起来越来越顺手。
腾讯WorkBuddy实战指南：AI Agent配置、Skill机制与避坑全解析
1. 为什么我要认真写这篇 WorkBuddy 实战指南第一次接触 WorkBuddy 是在一个赶项目的深夜。当时手头堆着三份文档要整理、两个数据表要合并、还有一堆重复性的文件重命名工作整个人处于一种机械劳动把人逼疯的状态。朋友甩过来一句你试试 WorkBuddy腾讯出的 AI 工作台我抱着试试看的心态装上了结果那一晚我少熬了两个小时。从那之后我开始系统性地研究这个东西——它到底能干什么、怎么配置才顺手、哪些坑必须提前避开。WorkBuddy 是腾讯推出的一款 AI 工作台产品核心定位是把 AI Agent 的能力封装成一个可以日常使用的桌面工具。你可以把它理解成一个能听懂人话、能动手干活的助手它不只是聊天还能读写文件、执行命令、调用各种 Skill 来完成具体任务。和它经常被一起提起的还有 CodeBuddy两者同源但侧重点不同——CodeBuddy 更偏向代码开发场景WorkBuddy 则把触角伸向了更广泛的工作场景文档处理、数据分析、自动化流程都能覆盖。这篇文章适合几类人看刚听说 WorkBuddy 想上手但不知道从哪开始的新手已经装了但配置一直没搞明白、用起来磕磕绊绊的 intermediate 用户以及想把它用到团队工作流里、需要了解自定义模型配置和 Skill 机制的技术负责人。我会从安装讲到配置从核心功能讲到避坑经验把这一路踩过的坑和总结出来的技巧都摊开说。全文基于我自己的实际使用和反复测试不是官方文档的复述而是一个真实用户怎么把它用顺手的记录。2. 安装与初始配置从零到能跑起来2.1 安装前的环境确认与版本选择装 WorkBuddy 之前有几件事必须先确认清楚否则装到一半卡住会非常难受。首先是操作系统版本WorkBuddy 目前对 Windows 和 macOS 都有支持Linux 用户也有对应的安装包但不同平台的安装方式和依赖略有差异。Windows 建议 Win10 1903 及以上macOS 建议 12 以上Linux 则要看具体的发行版和桌面环境。其次是磁盘空间。WorkBuddy 本体安装包不算大但它的系统缓存目录会随着使用不断增长——尤其是你频繁让它处理大文件、生成内容的时候。我见过有人 C 盘只剩几个 G 就硬装结果用了两周系统盘爆红。所以安装前至少预留 10GB 以上的可用空间如果你打算重度使用20GB 更稳妥。版本选择上WorkBuddy 有国内版和国际版之分。国内版在模型接入、网络环境适配上更贴合国内用户国际版则在某些模型和服务的可及性上有差异。如果你主要处理中文内容、使用国内常用的办公文件格式国内版是更自然的选择。国际版适合有跨境协作需求、或者需要调用特定海外模型的场景。两个版本的核心功能框架是一致的差异主要在模型池和服务接入层面。提示不要同时安装国内版和国际版到同一台机器上两者的缓存目录和配置文件可能产生冲突导致启动异常。如果确实需要两个版本建议装在不同的用户账户下或者用虚拟机隔离。2.2 安装步骤与首次启动的关键设置安装过程本身不复杂下载对应平台的安装包双击运行按提示走就行。但有几个细节值得单独拎出来说。Windows 平台安装时如果系统弹出了 SmartScreen 拦截提示这是正常现象选择仍要运行即可。安装路径建议不要选默认的 C 盘 Program Files改到一个空间充裕的分区比如 D 盘或 E 盘。原因很简单后续缓存目录默认也在 C 盘用户目录下两个大头挤在一起C 盘压力太大。macOS 平台安装后首次启动可能会提示无法验证开发者这时候去系统设置 - 隐私与安全性里点仍要打开就行。Linux 平台如果是用安装包方式注意依赖库的完整性缺库的话启动会直接报错根据报错信息补装对应的依赖即可。首次启动后WorkBuddy 会引导你做一些初始设置。这里有几个关键选择登录方式支持账号登录登录后可以同步部分配置和积分信息。如果你打算用它的积分体系来调用某些高级能力登录是必须的。工作目录设置这是最重要的一步。WorkBuddy 需要一个默认的工作目录它后续读写文件、执行任务都会在这个目录及其子目录下进行。建议单独建一个目录比如D:\WorkBuddyWorkspace不要直接指向你的桌面或者文档根目录否则文件管理会非常混乱。模型配置首次启动通常会让你选择默认模型。如果你还没有自定义模型的需求先用内置的默认模型跑起来后面再改。2.3 系统缓存目录迁移到 D 盘的正确姿势这是被问得最多的一个问题WorkBuddy 的系统缓存目录能改到 D 盘吗答案是能而且强烈建议改。默认情况下WorkBuddy 的缓存目录在用户目录下Windows 上是C:\Users\你的用户名\.workbuddy或类似路径macOS 上是~/.workbuddy。这个目录会存放模型缓存、临时文件、日志、Skill 运行产生的中间数据等等。用久了轻松几个 G 甚至十几个 G。迁移方法有两种。第一种是在 WorkBuddy 的设置界面里找缓存目录或存储路径选项直接改成你想要的路径。这是最干净的方式改完之后新产生的缓存就会写到新位置。第二种是如果设置界面没有提供这个选项某些版本确实没有可以通过创建符号链接的方式把默认目录骗到 D 盘先把原目录整个剪切到 D 盘目标位置然后在原位置创建一个指向新位置的符号链接。Windows 上用mklink /J命令macOS 和 Linux 上用ln -s。# Windows 示例需要管理员权限的命令行 mklink /J C:\Users\你的用户名\.workbuddy D:\WorkBuddyCache # macOS / Linux 示例 ln -s /Volumes/Data/WorkBuddyCache ~/.workbuddy注意做符号链接之前一定要先关闭 WorkBuddy否则文件被占用会导致操作失败。另外迁移完成后第一次启动可能会重新下载一些缓存这是正常的不要以为出问题了。3. 核心功能拆解AI Agent 到底怎么干活3.1 从聊天到执行Agent 模式的工作逻辑很多人第一次用 WorkBuddy 会把它当成一个聊天机器人问它问题、让它写点东西然后觉得也就那样。这就完全没用到它的核心能力。WorkBuddy 的真正价值在于 Agent 模式——它不只是生成文本而是能规划任务、调用工具、操作文件、执行命令最终交付一个具体的结果。举个例子。你让它把这个文件夹里所有的 Word 文档转成 PDF然后按修改日期重命名在聊天模式下它只会告诉你你可以用某某工具来做但在 Agent 模式下它会自己去读文件夹、识别文件、调用转换能力、执行重命名最后告诉你完成了一共处理了 12 个文件。这个差别是本质性的。Agent 的工作逻辑大致是这样的接收任务后先做任务分解把一个大目标拆成若干可执行的步骤然后逐步执行每一步可能涉及读取文件、调用 Skill、执行命令、生成内容执行过程中会根据中间结果动态调整最后汇总输出。这个过程中它会和你确认关键决策点比如我准备删除这三个文件确认吗——这个确认机制很重要是防止误操作的最后一道防线。理解了这个逻辑你就知道该怎么给它下指令了。模糊的指令会得到模糊的结果具体的、带约束条件的指令才能让它精准执行。比如帮我整理一下文件就不如把 Downloads 文件夹里所有超过 30 天没修改过的安装包移到 D 盘的 Archive 文件夹来得有效。3.2 Skill 机制WorkBuddy 的能力扩展核心Skill 是 WorkBuddy 最值得深入研究的机制。你可以把 Skill 理解成插件或者技能包——每一个 Skill 封装了一类特定的能力WorkBuddy 在执行任务时按需调用。内置的 Skill 覆盖了常见场景文件操作、文档处理、数据分析、网页内容抓取、代码执行等等。但真正让 WorkBuddy 变得强大的是它支持自定义 Skill 和 MCP Skill。MCP 是一种标准化的能力接入协议通过它可以把外部工具、API、服务接入到 WorkBuddy 的工作流里。哪些 Skill 最好用根据我的实际使用频率排在前面的有Skill 类型典型用途使用频率文件操作类批量重命名、格式转换、目录整理极高文档处理类Word/PDF/Excel 内容提取与生成高网页抓取类获取网页内容、结构化数据提取中高代码执行类运行脚本、数据处理、自动化任务中自定义 MCP Skill接入内部系统、特定 API按需自定义 Skill 的配置通常在 WorkBuddy 的 Skill 管理界面里进行你需要提供 Skill 的名称、描述、触发条件、执行逻辑可能是一段脚本或一个 API 调用配置。描述写得越清晰WorkBuddy 越容易在合适的时机调用它。实操心得给自定义 Skill 写描述时不要只写这个 Skill 能做什么还要写什么时候该用它。比如当用户要求处理 Excel 文件且涉及多表合并时使用此 Skill这样能显著提高调用的准确率。3.3 自定义模型配置与 models.json 详解WorkBuddy 支持自定义模型配置这是它区别于很多同类产品的一个亮点。你可以接入自己的模型服务而不局限于内置的模型池。配置文件通常是models.json放在配置目录下。这个文件的结构大致是这样的一个模型列表每个模型包含名称、类型、接入地址、认证信息、参数等字段。下面是一个示例结构具体字段名以你使用的版本为准{ models: [ { name: my-custom-model, provider: openai-compatible, baseUrl: https://your-model-endpoint/v1, apiKey: your-api-key, model: model-name, maxTokens: 4096, temperature: 0.7 } ] }配置自定义模型时有几个关键点。第一baseUrl要填对很多接入问题都出在这里——少个斜杠、多个路径都会导致调用失败。第二apiKey的权限要确认有些 key 只能调特定模型。第三maxTokens和temperature要根据你的使用场景调做文档处理时 temperature 低一点更稳定做创意生成时可以高一点。改完models.json后需要重启 WorkBuddy 才能生效。如果重启后模型列表里没出现你配置的模型先检查 JSON 格式是否合法可以用在线的 JSON 校验工具过一遍再检查网络是否能通到baseUrl。3.4 跨对话记忆与自定义指令让 WorkBuddy 记住你的习惯WorkBuddy 有一个跨对话记忆的能力配合自定义指令使用效果很好。跨对话记忆的意思是你在一次对话里告诉它的偏好、规则、背景信息它可以在后续的对话里继续沿用而不是每次都要重新说一遍。自定义指令则是你预先设定好的一组规则比如回答时优先用中文、处理文件时先备份再操作、生成文档时使用 Markdown 格式。这些指令设定一次后续对所有任务都生效。我自己的自定义指令里有一条是任何删除操作前必须先列出待删除文件清单并等待确认这条规则帮我避免过至少两次误删。还有一条是处理 Excel 时默认保留原始文件输出到新文件也是血泪教训换来的。设置路径一般在设置界面的指令或偏好区域。写指令的原则是具体、可执行、有明确的触发条件。不要写认真一点这种模糊的话要写每次生成代码后附上运行说明这种能直接落地的规则。4. 实操全流程从任务下达到结果交付4.1 一个完整任务的执行过程拆解光说概念没意思我拿一个真实做过的任务来完整走一遍。任务背景我有一批从各处收集来的 PDF 文献大概 40 多篇文件名乱七八糟需要整理成统一的命名格式提取每篇的标题和作者信息生成一个索引表。第一步我把所有 PDF 放到工作目录下的papers文件夹里然后在 WorkBuddy 里下达任务读取 papers 文件夹下所有 PDF提取每篇的标题、作者、年份按年份-作者-标题的格式重命名文件并生成一个 index.md 索引表。第二步WorkBuddy 开始规划。它先列出了它打算执行的步骤扫描文件夹、逐个读取 PDF、提取元数据、重命名、生成索引。然后它问我部分 PDF 可能没有完整的元数据遇到这种情况怎么处理我回复用文件名里的信息尽量推断推断不出来的标记为 unknown。第三步执行。这个过程花了大概几分钟它逐个处理文件中间有几次停下来问我确认——比如有两个文件提取出的标题完全一样它问是不是重复文件。这种交互设计很合理避免了它自作主张。第四步交付。最后它生成了index.md里面是一个表格包含原始文件名、新文件名、标题、作者、年份。我检查了一遍40 多篇里有 3 篇标记为 unknown手动补了一下其余都准确。这个流程走下来我大概花了 10 分钟如果手动做至少两个小时。这就是 Agent 模式的价值——它不是替你想而是替你做。4.2 参数计算与选择以批量文件处理为例在批量处理任务里有几个参数需要你根据实际情况做选择选错了要么效率低要么出问题。并发数WorkBuddy 处理批量任务时可能会并发执行。并发数高了快但对系统资源占用大而且如果任务涉及外部 API 调用可能触发限流。我的经验是纯本地文件操作可以开到 4-8 并发涉及网络请求的降到 2-3。超时时间单个文件的处理超时设置。默认值通常够用但如果你处理的是超大文件比如几百 MB 的 PDF需要适当调大。计算方式很简单估算单个文件平均处理时间乘以 3 作为超时值。重试次数遇到临时性错误比如文件被占用时的重试次数。建议设 2-3 次太多会拖慢整体进度太少容易因为偶发问题失败。输出编码处理中文文件时编码问题是大坑。统一用 UTF-8如果源文件是 GBK 编码需要先转换。这个在 WorkBuddy 里可以通过指令指定所有文本输出使用 UTF-8 编码。这些参数在哪里调一部分在设置界面的高级选项里一部分可以在任务指令里直接指定。我倾向于在指令里指定因为不同任务的需求不一样全局设置改来改去反而乱。4.3 生成网站并发布WorkBuddy 的进阶用法WorkBuddy 有一个让我比较惊喜的能力它可以帮你从零生成一个静态网站并发布。流程大致是你描述网站的需求它生成 HTML/CSS/JS 文件然后通过集成的发布能力把网站部署出去。我试过一次需求是做一个个人作品集页面包含头像、简介、三个项目卡片、联系方式风格简洁现代。它生成的页面结构清晰样式也过得去我改了几个颜色和间距就用了。发布环节它会引导你选择发布方式按提示操作即可。这个功能的实用场景包括快速做 landing page、做活动页面、做个人简历页。不适合做复杂的动态网站但对于静态展示类需求效率很高。注意生成网站后一定要在本地预览确认检查移动端适配和链接有效性。AI 生成的代码偶尔会有小问题比如某个 CSS 属性写错导致布局错乱提前发现比发布后再改省事。4.4 本地部署与私有化部署的考量对于有数据安全要求或者想深度定制的用户WorkBuddy 支持本地部署和私有化部署。本地部署指的是把 WorkBuddy 运行在你自己的机器上数据不出本地私有化部署则是部署到内部服务器供团队使用。本地部署的要点确认机器配置够用主要是内存和磁盘模型可以选择本地运行的模型或者接入外部模型服务。如果选本地模型对硬件要求会高不少尤其是想跑大参数模型的时候。私有化部署涉及的东西更多服务器环境准备、依赖安装、配置管理、用户权限、日志审计等等。如果团队规模不大我建议先用本地部署跑一段时间确认工作流顺畅了再考虑私有化。私有化部署的维护成本不低不要为了看起来专业而过度工程。Docker 部署是一种常见方式把 WorkBuddy 及其依赖打包成容器部署和迁移都方便。如果你熟悉 Docker这条路会顺很多。5. 避坑指南那些我踩过的坑和总结的经验5.1 安装与配置阶段的常见问题问题一启动后一直转圈进不去界面。最常见的原因是缓存目录权限问题或者缓存文件损坏。解决办法关闭 WorkBuddy找到缓存目录把里面的临时文件和锁文件删掉不要删配置文件重启。如果还不行把整个缓存目录重命名备份让它重新生成。问题二自定义模型配置后不生效。按这个顺序排查JSON 格式是否合法 → baseUrl 是否可达用 curl 或浏览器访问一下→ apiKey 是否有效 → 模型名称是否拼写正确 → 是否重启了 WorkBuddy。90% 的问题出在前两步。问题三中文乱码。在指令里明确指定编码或者在设置里把默认编码改成 UTF-8。如果处理的是 Windows 下生成的 GBK 文件需要先转码再处理。问题四积分不够用。WorkBuddy 的部分高级能力消耗积分。省积分的技巧把复杂任务拆成简单任务分步执行避免让它做无意义的重复操作善用本地 Skill 减少模型调用。5.2 使用过程中的典型故障与排查现象可能原因排查方法解决方式任务执行到一半卡住某个文件被占用或损坏查看日志最后一条记录跳过问题文件单独处理生成内容质量差指令太模糊或模型选择不当检查指令具体程度细化指令换更合适的模型Skill 调用失败Skill 配置错误或依赖缺失查看 Skill 日志重新配置或补装依赖响应速度突然变慢缓存过大或系统资源紧张查看缓存目录大小和内存占用清理缓存关闭其他程序文件操作结果不符合预期路径理解偏差或权限不足检查实际文件系统状态明确路径确认权限排查的核心思路是先看日志再看配置最后看环境。WorkBuddy 的日志通常在缓存目录下的logs文件夹里出问题时第一时间去看比瞎猜有效得多。5.3 安全审核与使用边界WorkBuddy 有安全审核机制某些操作会被拦截或要求确认。这是好事不要想着绕过它。我理解有些用户会觉得审核太严影响效率但从实际使用来看真正被拦的往往是确实有风险的操作比如批量删除、修改系统文件、执行来源不明的脚本。使用边界方面我的建议是不要让 WorkBuddy 直接操作你唯一一份的重要数据先备份不要给它系统级的管理员权限用普通用户权限跑就行涉及敏感信息的任务确认数据流向必要时用本地部署模式。5.4 和其他工具的比较WorkBuddy、CodeBuddy、Trae 怎么选经常有人问这几个工具怎么选。我的看法是看场景WorkBuddy通用工作场景文档处理、数据分析、自动化流程、内容生成。适合非纯开发岗位的职场人。CodeBuddy代码开发场景写代码、调试、代码审查、项目管理。适合开发者。Trae也是开发向的工具在某些开发工作流上有自己的特色。如果你主要写代码CodeBuddy 或 Trae 更对口如果你做的是综合性的工作需要处理各种类型的任务WorkBuddy 更合适。当然这几个工具并不是互斥的很多人是组合使用。6. 进阶技巧把 WorkBuddy 用出花来6.1 自定义指令的黄金法则写自定义指令有几个原则是我反复调整后总结出来的。第一条规则要可判定。认真处理这种没法判定每次输出前检查文件是否存在这种可以判定。可判定的规则才能被稳定执行。第二条规则要分层。全局规则放设置里任务级规则在指令里说。不要把任务级的规则写到全局设置里会互相干扰。第三条规则要精简。我见过有人写了三十多条自定义指令结果 WorkBuddy 执行时顾此失彼。核心规则控制在 5-8 条覆盖最高频的场景就够了。第四条定期复盘。用一段时间后回顾哪些规则真正起了作用哪些从来没触发过把没用的删掉。6.2 用 WorkBuddy 写文献综述的实操写文献综述是 WorkBuddy 的一个高频使用场景。我的流程是这样的先把相关文献的 PDF 放到一个文件夹让 WorkBuddy 提取每篇的核心观点、研究方法、结论。然后让它按主题聚类生成一个初步的综述框架。接着针对每个主题让它整合多篇文献的观点生成段落初稿。最后我自己通读修改补充批判性分析和自己的观点。这个流程里WorkBuddy 承担的是信息提取和初步整合的工作我承担的是判断和深化的部分。不要指望它直接生成一篇能用的综述但它能把最耗时的信息整理环节压缩到原来的十分之一。实操心得让它提取文献信息时明确要求引用原文关键句这样后续核对和引用时方便得多。另外让它标注每篇文献的来源信息避免后续找不到出处。6.3 团队协作场景下的配置建议如果要在团队里推广 WorkBuddy有几个配置建议。统一工作目录规范约定好项目文件放在哪、输出放在哪、临时文件放在哪。目录结构清晰了协作才顺畅。共享自定义指令把团队通用的规则整理成一份指令模板新成员直接导入减少重复配置。Skill 共享把团队常用的自定义 Skill 导出分享保证大家用的是同一套能力。权限管理如果涉及敏感数据明确哪些任务可以用云端模型哪些必须用本地模型。版本统一尽量让团队成员用同一个版本避免因为版本差异导致的行为不一致。7. 我个人的一些使用体会用 WorkBuddy 这段时间最大的感受是它的价值不在于替代人而在于把人从机械劳动里解放出来。那些重复性的、规则明确的、不需要创造性判断的工作交给它做效率提升是数量级的。但需要判断、需要权衡、需要创造性的部分还是得人来。另一个体会是工具的上限取决于使用者的指令能力。同样一个 WorkBuddy有人用起来觉得不过如此有人用起来觉得效率翻倍差别就在会不会下指令、会不会配置。这东西有点像开车车本身性能差不多但老司机和新手开出来的效果完全不同。最后分享一个小技巧每次完成一个比较复杂的任务后让 WorkBuddy 把这次的任务流程总结成一个可复用的模板或者 Skill。下次遇到类似任务直接调用省去重新描述的时间。这个习惯坚持下来你的 WorkBuddy 会越来越懂你用起来越来越顺手。