1. 为什么我要认真聊聊 WorkBuddy 这个 AI 工作台第一次接触 WorkBuddy 是在一个做企业数字化的朋友那里。他当时丢给我一句话“你把它当成一个能自己动手干活的 AI 同事而不是一个只会聊天的机器人。”这句话基本概括了 WorkBuddy 的定位——腾讯推出的 AI 工作台核心能力是把大模型、工具调用、技能插件Skill和本地文件系统串起来让 AI 从“回答问题”进化到“完成任务”。很多人第一次打开 WorkBuddy 会有点懵它不像普通的对话式 AI 那样只有一个输入框而是有工作区、有文件、有技能、有配置。这恰恰是它的价值所在。你可以让它读取你本地的项目文件、调用你写好的 Skill 脚本、按照你设定的规则持续执行任务甚至把一整套工作流固化下来反复使用。对于每天要处理大量重复性工作的开发者、运营、数据分析师来说这种“可编排的 AI 工作台”比单纯的聊天窗口实用得多。这篇内容适合三类人一是刚听说 WorkBuddy、想搞清楚它和普通 AI 助手区别的新手二是已经装了但卡在配置、Skill 编写、缓存目录这些细节上的进阶用户三是想把它纳入团队工作流、需要一套可复现方案的技术负责人。我会从安装讲到避坑把 models.json、Skill 机制、规则设定、缓存迁移这些容易踩雷的地方一次讲透。文中涉及的具体参数和目录结构部分是基于常见实践的合理补充实际以你本地版本为准。2. WorkBuddy 到底是什么核心概念一次理清2.1 AI 工作台与普通对话 AI 的本质区别普通对话 AI 的工作模式是“你问我答”每次对话都是独立的它不记得你的文件、不知道你的项目结构、也没法主动去执行一个多步骤任务。WorkBuddy 的定位是AI Agent 工作台关键词是“Agent”——智能体。它具备三个普通对话 AI 没有的能力持久化的工作区、可调用的工具与技能、可配置的行为规则。持久化工作区意味着你有一个固定的目录AI 可以读写里面的文件你的项目上下文不会因为关掉窗口就消失。可调用的工具与技能意味着 AI 不只是“说”还能“做”——比如运行一段脚本、生成一个网站、处理一批数据。可配置的行为规则意味着你可以给 WorkBuddy 定几条规矩后续所有任务都按这个规矩来不用每次重复交代。这三点叠加起来它才配得上“工作台”这个称呼。我自己的理解是对话 AI 是顾问WorkBuddy 是同事。顾问给你建议同事帮你把活干了。这个区别决定了你使用它的方式——你不能只丢一个问题过去而要像给同事派活一样把背景、目标、约束条件说清楚。2.2 models.json、Skill、规则系统三件套WorkBuddy 的核心配置可以归纳为三件套。第一件是models.json这是模型配置文件决定了 WorkBuddy 背后调用哪个大模型、用什么样的参数。你可以把它理解成工作台的“发动机选择器”——换一个模型AI 的推理风格、速度、成本都会变。这个文件通常放在配置目录下格式是标准的 JSON里面包含模型名称、接口地址、密钥占位、温度参数等字段。第二件是Skill也就是技能插件。Skill 是 WorkBuddy 最核心的扩展机制一个 Skill 本质上是一段可被 AI 调用的能力封装可以是一个脚本、一个 API 封装、一套提示词模板。热词里出现的“skill 编码 247”“仓颉 skill”“数学建模 skill”“unity skill attack indicators”其实都是不同场景下的 Skill 实例。你可以自己写 Skill也可以用别人分享的。Skill 让 WorkBuddy 从“通用助手”变成“你的专属助手”。第三件是规则系统。你可以给 WorkBuddy 定几条规则比如“所有输出用中文”“代码必须带注释”“文件统一存到 workspace 目录”设定之后后续对所有任务都生效。这个机制解决了一个大痛点不用每次对话都重复交代同样的要求。规则系统配合 Skill基本就能把一套工作流固化下来。2.3 WorkBuddy 和 CodeBuddy 的区别在哪热词里反复出现“workbuddy 和 codebuddy 的区别”这里必须说清楚。CodeBuddy 更偏向编码场景核心是帮开发者写代码、补全、调试交互形态更接近 IDE 插件或编码助手。WorkBuddy 的覆盖面更广它是通用工作台编码只是它能做的事情之一它还能处理文档、数据、网站生成、流程编排等任务。打个比方CodeBuddy 是一把专业的螺丝刀WorkBuddy 是一个工具箱。如果你只写代码CodeBuddy 可能更聚焦如果你要处理的是“从需求到交付”的完整链路WorkBuddy 的编排能力更合适。当然两者在底层模型能力上有重叠实际选择看你的工作场景。我个人的用法是纯编码任务用 CodeBuddy 提效跨环节的复合任务交给 WorkBuddy 编排。3. 安装与初始配置从零到能跑起来3.1 安装前的环境准备与版本选择安装 WorkBuddy 之前先确认你的操作系统。目前主流支持 Windows、macOSLinux 版本在热词里也被频繁提到“workbuddy linux”说明不少用户在服务器环境部署。Windows 用户建议 Win10 以上macOS 建议较新的版本Linux 用户注意依赖库的完整性。另外确认你有稳定的网络环境用于下载安装包和后续的模型调用。版本选择上热词里出现了“workbuddy 国际版”和“workbuddy 网页版”。国际版通常在模型接入和界面语言上有差异网页版则省去了本地安装的步骤适合快速体验。我的建议是想深度使用、需要本地文件读写和 Skill 执行的装桌面版只想先感受一下交互逻辑的先用网页版。桌面版才是完整体Skill 和本地工作区的能力在网页版上会受限。安装包下载后按向导走即可注意安装路径不要选带中文和空格的目录这是很多工具的通病WorkBuddy 也不例外。路径里有中文可能导致 Skill 脚本执行时找不到文件。我踩过一次坑装在“D:\我的工具\WorkBuddy”下面结果某个 Skill 读取相对路径一直失败换成纯英文路径后立刻正常。3.2 首次启动与 models.json 配置要点首次启动 WorkBuddy它会引导你做基础配置核心就是 models.json。这个文件决定了 AI 的“大脑”。配置项通常包括模型标识、接口地址、认证信息、生成参数。这里有个关键点温度参数temperature的设置直接影响输出风格。做代码和结构化任务时温度建议调低0.2 到 0.4输出更稳定做创意文案时可以调到 0.7 以上。配置 models.json 时最容易出错的地方是 JSON 格式。少一个逗号、多一个括号整个文件就解析失败WorkBuddy 会报“模型不可用”。我的习惯是改完先用在线 JSON 校验工具过一遍确认无误再重启。另外密钥这类敏感信息不要直接写死在文件里明文保存能用环境变量引用就用环境变量这是基本的安全习惯。配置完成后建议先做一个最小验证让 WorkBuddy 回答一个简单问题确认模型通了。如果报错优先检查三处——网络是否可达、密钥是否有效、JSON 是否合法。这三处覆盖了九成的首次配置问题。3.3 工作区目录规划与缓存迁移到 D 盘WorkBuddy 默认会在系统盘创建缓存和工作区目录。热词里“workbuddy 系统缓存目录能改到 d 盘吗”是个高频问题答案是能而且建议改。原因很简单AI 工作台运行过程中会产生大量缓存、日志、临时文件长期使用会吃掉系统盘空间系统盘满了会影响整机性能。迁移方法通常是找到配置文件里的路径设置项把默认路径改成 D 盘的目标目录然后重启。注意迁移时要先关闭 WorkBuddy把原有缓存目录整体复制过去再改配置最后重启验证。直接改配置不搬文件可能导致历史工作区丢失。我一般会在 D 盘建一个结构清晰的目录比如D:\WorkBuddy\workspace、D:\WorkBuddy\cache、D:\WorkBuddy\skills分开管理后续排查问题也方便。提示迁移缓存目录后第一次启动可能会重新索引工作区速度稍慢是正常的不要以为卡死了就强制关闭。4. Skill 机制深度拆解WorkBuddy 的真正杀手锏4.1 Skill 是什么从“会聊天”到“会干活”的桥梁Skill 是 WorkBuddy 的能力扩展单元。没有 Skill 的 WorkBuddy 是一个聪明的对话助手有了 Skill 它才变成能执行具体任务的 Agent。一个 Skill 可以封装一段脚本、一个外部接口调用、一套固定的处理流程。当你的任务匹配到某个 Skill 时WorkBuddy 会调用它来完成任务而不是只用语言模型“凭空生成”。热词里“book to skill”“skill 脚本”“skill 插件”“skill 开发指南”都指向同一个核心Skill 是可开发、可复用、可分享的。你可以把日常重复的工作写成 Skill比如“把 Markdown 转成带样式的 HTML”“批量重命名文件”“从一段文本里抽取结构化数据”。写一次以后每次都能调用这就是 Skill 的价值。我个人的经验是判断一个任务值不值得写成 Skill看它是否重复出现且步骤固定。如果一件事你一周要做三次以上且每次流程一样那就值得封装成 Skill。反之一次性的任务直接对话解决就行没必要过度工程化。4.2 一个 Skill 的典型结构与编写流程一个典型的 Skill 通常包含几个部分元信息名称、描述、触发条件、输入定义需要哪些参数、执行逻辑具体干什么、输出格式返回什么。元信息里的描述很关键它决定了 WorkBuddy 在什么情况下会想到调用这个 Skill。描述写得越清晰匹配越准。编写流程上一般是先明确任务边界再定义输入输出然后写执行逻辑最后本地测试。测试环节不能省——我见过太多人写完 Skill 直接上线结果参数类型不对、路径处理有 bug调用时直接报错。本地测试时建议用几组边界数据比如空输入、超长输入、特殊字符输入看看 Skill 是否稳健。Skill 的存放位置通常在 skills 目录下每个 Skill 一个子目录里面放脚本和配置文件。命名建议用英文小写加下划线避免空格和特殊字符这样跨平台兼容性最好。热词里提到的“skill 编码 247”这类编号可能是某个 Skill 集合里的序号实际使用时按你自己的命名规范来就行。4.3 Skill 的触发逻辑与调试技巧Skill 的触发有两种常见模式自动匹配和显式调用。自动匹配是 WorkBuddy 根据你的任务描述判断该用哪个 Skill显式调用是你直接点名要用某个 Skill。自动匹配方便但可能不准显式调用精准但需要你记住 Skill 名字。实际使用中重要任务建议显式调用避免 AI 选错工具。调试 Skill 时最有效的方法是看日志。WorkBuddy 调用 Skill 的过程通常会记录在日志里包括传入的参数、执行结果、报错信息。Skill 不生效时先看日志确认它有没有被触发如果触发了但结果不对看传入参数是否符合预期如果根本没触发检查 Skill 的描述和触发条件是否写得太窄。注意Skill 执行涉及文件读写时务必确认工作目录权限。权限不足是 Skill 静默失败的头号原因日志里往往只报一个模糊的错误实际是没权限写文件。5. 规则系统与工作流固化让 AI 记住你的习惯5.1 给 WorkBuddy 定规则的正确姿势规则系统的价值在于“一次设定长期生效”。热词里“给 workbuddy 定几条规则后续对所有任务都生效”说的就是这个。规则可以覆盖输出语言、代码风格、文件存放位置、命名规范、安全约束等。设定规则后你就不用每次对话都重复“请用中文回答”“代码要加注释”这类话。写规则有几个要点。第一规则要具体可执行不要写“输出质量要高”这种没法量化的要写“所有代码块必须标注语言类型”。第二规则之间不要冲突比如同时写“输出尽量简洁”和“每个步骤都要详细展开”AI 会无所适从。第三规则数量适度太多规则会稀释重点我一般控制在十条以内只保留真正高频的需求。规则生效后建议做一次验证故意提一个可能违反规则的任务看 WorkBuddy 是否遵守。比如你定了“文件统一存到 workspace 目录”就让它生成一个文件看它存哪了。验证通过说明规则真正生效了。5.2 用规则加 Skill 搭建可复用的工作流规则和 Skill 组合起来就能搭建可复用的工作流。举个我自己的例子我经常需要把一段原始素材整理成结构化的博文。我写了一个 Skill 负责“素材转结构化大纲”又定了规则“输出必须用 Markdown、标题必须编号、禁止使用 emoji”。这样每次我只要把素材丢进去WorkBuddy 就会按我的规则和 Skill 自动产出符合要求的初稿。这种工作流的价值在于降低重复沟通成本。没有工作流时我每次都要重新交代格式要求有了工作流我只需要关注内容本身。对于团队协作工作流还能保证输出一致性——不同的人用同一套规则和 Skill产出风格统一后续汇总和审核都省事。搭建工作流时建议先手动跑通一遍完整流程确认每一步都可行再把它固化成规则和 Skill。跳过手动验证直接固化很容易把隐藏的问题一起固化进去后面改起来更麻烦。6. 常见问题与避坑实录6.1 安装与配置阶段的典型坑安装配置阶段最高频的问题是模型连不上。排查顺序建议是先确认网络能访问模型接口地址再确认密钥有效且没过期最后确认 models.json 格式合法。这三步能解决大部分“模型不可用”。另一个常见坑是路径含中文导致 Skill 失败前面提过这里再强调一次安装路径、工作区路径、Skill 路径全部用纯英文。还有用户反馈首次启动后界面卡顿。这通常是首次索引工作区导致的等几分钟就好。如果长时间卡死检查工作区目录是不是放了超大文件AI 索引大文件会拖慢启动。建议工作区只放当前项目相关文件历史归档文件移到别处。6.2 Skill 不生效的排查思路Skill 不生效分三种情况没触发、触发了但报错、触发了但结果不对。没触发就检查 Skill 描述和触发条件报错就看日志里的异常信息结果不对就检查传入参数和执行逻辑。我整理了一个速查表方便对照排查。现象可能原因排查动作Skill 完全没反应描述太窄或未注册检查 Skill 是否在 skills 目录、描述是否匹配任务调用后报错参数类型不符或权限不足看日志异常栈确认参数和目录权限结果不符合预期执行逻辑有 bug本地单独跑 Skill 脚本用边界数据测试时好时坏输入数据不稳定检查是否有空值、特殊字符未处理6.3 缓存与性能相关的避坑经验缓存目录放系统盘是长期使用的大坑。系统盘空间被缓存吃掉后整机都会变慢WorkBuddy 本身也会受影响。迁移到 D 盘是推荐做法迁移后记得定期清理过期缓存。我一般一个月清一次保留最近的工作区删掉临时文件。性能方面如果发现 WorkBuddy 响应变慢先看是不是同时开了太多任务。AI 工作台并发执行多个 Skill 时会争抢资源建议重要任务单独跑。另外模型选择也影响速度大模型能力强但慢小模型快但能力弱按任务重要性权衡。7. 我的实操心得与后续扩展方向用 WorkBuddy 这段时间最大的体会是把它当同事而不是当搜索引擎。搜索引擎给你链接同事帮你干活。你要做的是把任务描述清楚、把规则定好、把常用能力封装成 Skill剩下的交给它执行。刚开始可能会觉得配置麻烦但配置一次后面省下的是大量重复沟通的时间。另一个心得是从小处着手。不要一上来就想搭建一个覆盖所有场景的复杂工作流先从一个高频小任务开始写一个 Skill定两条规则跑通了再扩展。我最初就是从“自动整理文件命名”这个小 Skill 开始的跑顺了才逐步加上内容处理、格式规范这些能力。渐进式搭建比一次性大而全更稳。后续这个工作台还能往几个方向扩展一是把更多外部工具封装成 Skill扩大能力边界二是把团队共用的规则和 Skill 沉淀成模板新成员直接复用三是结合定时任务让 WorkBuddy 在固定时间自动执行例行工作。这些方向我还在逐步尝试有新的踩坑经验再单独整理分享。