1. 我为什么决定用WorkBuddy自建一个“专家”大概半年前我还在各种通用AI助手之间反复横跳。每次想让它帮我整理周报、汇总表格、写一段固定风格的文案都得临时写一大段提示词而且换一个场景就要重新调一遍。后来无意间看到有人在聊WorkBuddy说可以把常用的指令、流程、工具全部固化成一个“专家”下次直接调用就行。我第一反应是这不就是给AI套了一层自定义外壳但真正用起来之后我发现事情没那么简单。WorkBuddy的本质是一个效率智能体平台。它和普通聊天助手的最大区别在于——你可以在里面创建多个“专家”每个专家绑定自己专属的Skill技能、上下文、工具权限和对话风格。说得直白一点通用助手像是你雇了一个什么都会一点但什么都不精的全能实习生而WorkBuddy里的专家是你亲手训练出来、只负责某一类任务的专项员工。这篇文章适合谁看如果你平时要用AI处理大量重复性工作比如周报、数据清洗、报表汇总、定时提醒、文本转换或者你想把一套固定的业务流程交给AI去跑那WorkBuddy的自建专家功能会非常对胃口。我会从安装、建专家、写Skill、绑定工作流、上线使用到排查各种奇奇怪怪的报错完完整整走一遍。我用的版本是Windows端的稳定版Linux也装了整体流程大同小异。下面我会尽量按实际操作顺序来写你照着走基本不会翻车。在开始之前先劝退一波如果你只是拿AI聊聊天、写写朋友圈文案那WorkBuddy对你是过剩的。它是给“有固定工作流”的人准备的。你有多条重复性的任务路径它就能帮你省多少事。没有固定任务的人建了专家也是吃灰。2. 动手前必须搞懂的三个核心概念1.1 Expert专家到底是什么在WorkBuddy里“专家”Expert就是一个容器。你给它起名字、写人设、配置技能它就变成一个独立的对话入口。你可以同时创建多个专家比如一个专门处理Excel的“表哥专家”、一个专门写公众号的“文案专家”、一个帮你盯监控的“运维助手”它们之间互不干扰。我个人的理解是专家相当于一个“带专职岗位的AI同事”。它自带一套系统提示词System Prompt决定它面对用户时怎么思考、怎么回答、能调用哪些工具。不同专家之间不共享上下文这既是优点也是缺点——优点是每个专家的行为很稳定缺点是如果你有跨专家的信息同步需求得自己想办法。创建专家的入口在WorkBuddy的开发者平台里也有客户端内直建的方式。你需要填的核心字段就三个名称、描述、系统设定。系统设定是重中之重它决定了这个专家的“性格”和“能力边界”这一段写得好不好直接决定了专家聪明不聪明。后面我会专门拿一小节来细讲怎么写。1.2 Skill技能是整个系统的灵魂如果专家是“身体”那Skill就是“器官”。没有Skill的专家最多只能聊聊天、答答疑有了Skill专家才能真正动手干活。Skill可以理解为一个“可调用的功能模块”。它可以是一段写死的提示词比如“把这段文本改成周报格式”也可以是一段可执行的工作流比如“读取钉钉多维表→合并数据→生成日报→发送到微信群”还可以是外部API的调用封装比如“把内容推送到企业微信机器人”。WorkBuddy的好处是它的Skill不只是简单的Prompt模板而是支持一定的逻辑编排。你可以在一个Skill里串联多个步骤加上条件判断、循环、定时触发这些能力。这就让它从一个“聊天框里的咒语”变成了真正的自动化工具。这里的重点是Skill的创建不需要很强的编程能力。WorkBuddy官方提供了一个可视化编排界面拖拖拽拽就能完成大部分流程。真正的高级玩法是写JSON/Schema定义Skill的输入输出结构让专家能够自动识别参数、自动调用正确的Skill——这一部分我会在第五节详细展开。1.3 开发者平台、客户端和本地部署的关系很多人一开始会困惑这三个东西到底是什么关系。开发者平台浏览器里打开的网页控制台用来创建专家、配置Skill、管理数据源、查看日志。你建专家和写Skill基本都在这里完成。客户端/工作台安装在本地电脑上的应用它有两个作用一是把开发者平台上的配置同步下来让你在本地以对话形式使用专家二是支持一些本地能力比如读本地文件、执行定时任务。本地部署这是进阶玩法。WorkBuddy支持把核心引擎部署到自己的服务器上数据不出内网适合对数据安全要求高的团队。个人用户一开始不需要碰这个等跑通了流程再考虑。我踩过的一个坑是在开发者平台里改完配置本地客户端有时候不会自动更新。遇到这种情况手动重启客户端或者在客户端里手动触发一次“同步配置”否则你永远是拿老版本在测试。3. 第一个自建专家从零到一的完整实操2.1 环境准备与安装Windows / macOS / Linux安装这块比较省心WorkBuddy官网提供了三大平台的安装包。以Windows为例下载安装包后一路Next就行初次启动会让你登录账号。macOS用户注意一下如果你是从网上下载的dmg第一次打开被Gatekeeper拦截的话需要到“系统设置→隐私与安全性”里手动允许。Linux版本要稍微多讲两句。如果你用的是Ubuntu 22.04以上下载deb包安装后大概率能直接跑起来。但是我在Ubuntu 20.04上遇到过一个坑——缺少一些系统依赖库日期时间相关的tzdata和网络相关的ssl证书导致启动后一直卡在初始化界面。解决办法是sudo apt update sudo apt install ca-certificates tzdata -y装完依赖重新启动就好了。另外Linux版对显卡的要求不高CPU跑也完全够用不过如果你要处理的文本量巨大内存建议16G起步。安装完成之后进入主界面你会看到左侧栏有“专家列表”。默认情况下系统会自带几个官方专家比如通用助手、翻译专家、写手专家这些。这些官方专家可以作为参考模板但真正的好戏是创建自己的。2.2 用开发者平台创建自己的专家我建议在开发者平台做这一步因为网页端的表单更完整还能顺手配置Skill。进入开发者平台后找到“专家管理”点“新建专家”你会看到两个关键区域基础信息区专家名称建议用“职责角色”的格式比如“周报生成器”不要用“小助手”这种没有区分度的名字。描述这个字段会被用于智能匹配用户提问时系统会优先调用描述匹配的专家。所以要写得像给搜索引擎看的摘要比如“擅长把杂乱工作记录整理成结构化周报支持Excel数据导入”。系统设定区System Prompt 这是整个专家的大脑。我强烈建议你在这个字段里写清楚以下几件事专家的身份和职责边界。处理任务的固定流程。输出格式要求。不能做什么负向约束。拿我的“周报生成器”举例我的系统设定是这样写的你是一名资深项目助理负责把用户提供的碎片化工作记录整理为专业周报。你的工作流程是第1步识别记录中的任务、进展、风险和下一步计划第2步按时间线排序第3步输出Markdown格式的周报。你只负责整理和归纳不添加任何原始记录中不存在的信息。如果信息不足明确告知用户缺少哪些内容。这段设定看着简单实际效果比那些写了一大段空话的Prompt要好得多。核心原因在于——我给它定义了清晰的操作步骤和明确的负向约束。系统设定保存后这个专家就已经可以对话了。你可以先回去测试一轮确认它理解你的设定然后再去配置Skill。2.3 绑定Skill并做第一轮对话测试第一次创建专家没有绑定任何Skill时它只能靠系统设定里的要求进行对话。这时候你丢给它一个Excel文件它是处理不了的——因为它没有读取本地文件的权限。所以第二步是给专家绑定Skill。Skill的创建入口也在开发者平台里点“Skill管理→新建Skill”。系统会让你选择技能类型我用的是“数据处理”模板它会预置好读取文件、解析内容的框架你只需要微调参数。Skill创建完回到专家编辑页面把刚才建好的Skill勾选绑定。这里注意一个细节每个Skill可以设置“触发关键词”比如你设置“读取表格”作为触发词那用户说了“读取表格”四个字专家就会自动调用这个Skill。触发词不要设太窄否则容易被绕过去。绑定完成后我建议做一轮完整测试用真实场景、真实文件去对话而不要用“你好”这种测试语。我第一次测试时直接丢了一个真实的项目进度表让它输出周报结果它把表格里的原始数据原封不动地复制了一遍根本没有整理。后来问题定位在系统设定里缺了“识别关键信息”的指令加上去之后就好了。4. Skill设计与指令调优决定专家“聪明不聪明”的关键3.1 普通技能、代码技能、工作流技能怎么选WorkBuddy里的Skill分几个类型选错了后面会很别扭。第一种是Prompt技能也可以叫普通技能。它本质上就是一段高级提示词用户触发后专家会用这段提示词替代默认设定来回答。适合场景文本改写、格式转换、翻译这些不需要外部工具的任务。创建最简单改起来也最快。第二种是代码技能。它会运行一段脚本支持Python和Node.js用来处理更复杂的逻辑。比如你要对一堆量级很大的数据进行清洗、去重、合并只靠提示词是做不到的需要Python的pandas库来跑。创建代码技能时系统会提供一个在线编辑器你可以在里面写代码、测试运行确认没问题后保存。第三种是工作流技能。这是WorkBuddy最有含金量的一种它支持把多个步骤串联成一个自动流水线。比如触发条件定时/手动→ 读取多维表 → 数据清洗 → 调用LLM生成摘要 → 发送到微信/钉钉工作流里可以有条件分支“如果数据量大于100条执行A方案否则执行B方案。”这一点对重复性数据处理特别有用。我个人的建议是能用Prompt技能解决的不要上代码能用代码解决的不要硬凑工作流。每多一层复杂度排查问题的成本就多一分。我的“周报生成器”一开始用了代码技能后来发现Prompt就能满足80%的场景果断降级了。3.2 自定义指令的推荐写法让专家秒懂你的要求刚才提到了系统设定的写法这一节我专门讲讲Skill内部的自定义指令怎么写因为很多人建了Skill之后发现专家根本不听指挥问题就出在这。自定义指令有一个万能公式角色 任务 输入格式 输出格式 约束条件。举个例子我一个“销售日报生成器”的Prompt技能指令是这样写的你是销售运营助手。用户的输入是当日销售明细文本。你的任务是从中提取订单量、销售额、新客数、退款数并与昨日数据对比。输出要求先用一句话概括当日表现再用表格展示关键指标含环比最后列出1条最需要注意的风险。如果用户没有提供昨日数据只输出当日数据表不做对比。这个写法好在哪里好在你给了专家一个非常明确的“输入处理流程”它不需要猜你想要什么。我见过很多失败的自定义指令要么是只有“帮我写销售日报”一句话要么是事无巨细写了几千字把重要的操作步骤淹没在了大段描述里。还有一个值得推荐的技巧在指令里加入“少样本示例”Few-shot。WorkBuddy支持在Skill里附上一段示例对话比如用户输入什么样、专家应该输出什么样。我实测下来加了两个好的示例之后专家的输出质量提升非常明显比在系统设定里反复强调“要专业”“要准确”有效得多。3.3 多Skill组合让专家自动选择工具一个专家可以绑定多个Skill但WorkBuddy默认是“按触发词匹配”来选择调用哪个Skill的。如果你的专家绑了五六个Skill触发词又设得不好就会出现一个经典问题用户明明想让你读文件专家却去调用了写文案的Skill。我的做法是每个专家只绑定2-3个核心Skill且Skill之间的边界要画清楚。比如“周报生成器”下面我就挂了两个Skill“Excel数据提取”和“周报文本生成”。前者负责拿到文件转成结构化数据后者负责把结构化数据变成周报。至于如何让专家在面对复杂请求时自动选择合适的Skill我的经验是在系统设定里明确写一句“如果你收到的输入包含文件附件优先调用Excel数据提取技能如果输入是纯文本直接调用周报文本生成技能”。把这个判断逻辑写进系统设定里比在Skill层面做多少设置都管用。说到底多Skill组合的本质是让专家“有分工意识”。你越早规划清楚每个Skill的职责边界后面维护起来就越省心。这也是我反复强调“先想清楚再做”的原因——WorkBuddy的强大之处不是能绑定多少Skill而是你能把一个复杂任务拆成几个干净利落的子任务。5. 实战扩展把专家接入真实工作流4.1 定时发送微信消息让专家主动干活用WorkBuddy做定时任务是我觉得最“回本”的功能之一。很多人用AI都是“你问我答”但WorkBuddy可以做到“你不用管到点它自己干活”。具体来说在开发者平台的“定时任务”里你可以新建一个周期触发器设定执行频率每天上午9点、每周一早上等然后再绑定一个动作调用某个专家的Skill。这样到了设定时间WorkBuddy会自动唤醒对应专家执行Skill里的流程并把结果推送到你绑定的渠道。我日常有两个定时任务跑得最勤每天早上8点半让“早报专家”去抓取我的项目面板数据生成一份简短的项目健康报告每天中午12点让“公众号排版助手”把前一天写的草稿自动转成指定的排版格式并存到指定文件夹。关于推送渠道WorkBuddy支持绑定微信、钉钉和企业微信。绑微信的时候要注意它走的是个人微信的消息接口不是公众号接口所以你需要确保客户端在你的电脑上保持登录状态。如果换了电脑或者掉线了定时任务的推送就会失败。我一开始没注意这个有几天早报突然不发了排查半天才发现是客户端更新后需要重新扫码登录。4.2 钉钉多维表定期同步跨系统数据连接如果你所在团队用钉钉的多维表类似在线表格来管理任务那你可能会遇到一个头疼的事数据散落在各个人的表里汇总起来极其痛苦。WorkBuddy解决这个问题的方式是通过开放API把多维表变成一个数据源。原理是在Skill里配置好多维表的AppKey和表ID然后通过工作流里的“HTTP请求”节点定时把表里的数据拉下来经过清洗、合并后输出到目标表或文档里。我具体是怎么做的呢我建了一个“报表自动同步”的工作流Skill触发方式是每天早上9点。流程如下第1步调用钉钉开放平台接口获取多维表中今天更新的记录第2步用Python脚本做字段映射和数据清洗去掉空行、统一日期格式第3步将处理结果写入本地Excel并按项目名分sheet存储第4步生成一段文字摘要推送到钉钉群。这里要特别提醒一件事把多维表的视图ID和字段名配对写对。WorkBuddy在调用API时填错字段名不会报明显的错误它只会返回空数据你检查起来非常费劲。我推荐的排查方式是在工作流里临时加一个“输出原始响应”的节点先把API返回的JSON打印出来再对照字段名排查。成功跑通之后再把调试节点删掉。4.3 历史对话记录与本地记忆迁移WorkBuddy默认的对话历史是保存在本地的好在它支持手动导出和导入。如果你经常在Windows和Linux两台机器之间切换或者重装系统这个功能就是救命稻草。导出路径在各平台的设置里都能找到点击“导出全部数据”会生成一个压缩包里面包含了所有专家配置、Skill定义和对话记录。换到新机器后在设置里选择“导入数据”选择对应的压缩包就能完整恢复。有几个细节我踩过坑一是导出数据里虽然包含Skill的代码但如果你用了自定义Python包新机器上必须手动装好依赖否则Skill会报“模块找不到”二是导入后建议重启一次客户端否则部分技能不会注册成功三是本地记忆即专家在不同会话之间记住的用户偏好在导出时有时会丢失因为它是增量存储的如果你发现新机器上专家“失忆”了大概率是记忆文件没导全重新同步一次就好。6. 常见问题排查实录那些让人抓狂的报错5.1 网络连接失败3002这是我被问得最多的问题。WorkBuddy在启动或使用过程中如果弹出“网络连接失败错误码3002”大概率不是你断网了而是客户端和服务器之间的长连接断开了但客户端没有自动重连。典型的触发场景有三种电脑睡眠唤醒、切换了WiFi网络、公司的防火墙断开了空闲连接。最简单的解决办法是完全退出WorkBuddy注意是退出系统托盘图标不是只关窗口然后重新启动。如果重启几次还是报3002那就去设置里检查一下代理配置——很多人的电脑挂了局域网代理WorkBuddy默认不走系统代理你需要在设置里手动把代理地址填进去。还有一个很少人知道的原因系统时间不对。WorkBuddy的握手协议对时间戳校验很严格如果你电脑的系统时间比实际时间快了超过两分钟就会不断断连。调好时间之后问题马上消失。5.2 启动非常慢从十几秒到两三分钟很多人安装新版WorkBuddy之后发现启动时间变得非常长。这个问题在热词里也出现了我实测下来原因主要是两个第一历史对话记录太多。WorkBuddy在启动时会加载所有专家的历史会话索引如果你的对话记录积攒了几个月启动速度就会断崖式下降。解决办法是定期清理不重要的会话或者把旧会话导出存档后从本地删除。第二本地模型加载。如果你开启了本地语义搜索功能它会额外加载一个嵌入模型到内存里这会显著拖慢启动速度。如果你的机器配置一般建议在设置里关掉“启动时预加载搜索模型”改成按需加载启动时间能缩短一半以上。5.3 Linux/Ubuntu下跑不起来的坑Linux版本我遇到过的最典型的问题是缺少图形界面的渲染依赖。如果你用的是带桌面环境的Ubuntu还好但如果是纯服务器环境无显示器WorkBuddy客户端是起不来的——因为它必须依托图形界面运行。如果你确实需要在一台无显示器Linux服务器上跑WorkBuddy我的建议是放弃使用客户端改用Web版。Web版的官方入口可以远程访问功能上除了无法读取本地文件外大部分核心功能都在。另外Ubuntu 24.04上如果你用Wayland会话有概率遇到右键菜单显示异常的情况。临时切回Xorg会话能绕过去不过这属于系统显示栈兼容性问题等待官方后续修复更稳妥。5.4 访问文件夹范围与快捷键设置新手经常忽略的一个安全设置是WorkBuddy默认可以访问你电脑上的所有文件。这是很危险的——如果某个专家被恶意Prompt劫持理论上它可以读取你的私人文件。在客户端的设置里有一个“文件夹访问权限”的选项你可以限定每个专家能访问的目录范围。比如我的“Excel网关专家”只允许访问D:\工作数据\这个目录其他位置一律拒绝。这个设置虽然平时没存在感但在你把专家分享给别人时就是一道非常关键的防护。快捷键方面WorkBuddy支持自定义全局唤起快捷键。Windows端我设置的是CtrlAltSpace使用体验非常顺滑。Linux端要注意如果你用的是GNOME桌面部分全局快捷键会被系统抢占需要在系统设置里先解除占用再在WorkBuddy里设置。7. 创建专家的避坑心得与经验总结6.1 我自己踩过的三个大坑第一系统设定里写太多“形容词”而不是“动词”。最开始我给专家设定的风格是“专业、高效、细致”但它根本不懂怎么落实后来改成“先列出结论再展开论据每段不超过5行”输出立刻变得符合预期。AI专家不需要你用形容词给它的角色贴金它需要的是可执行的动词指令。第二盲目把所有工作都塞进一个Skill里。有一次我试图做一个“万能办公助手”一个Skill里既做文件读取、又做数据清洗、还做摘要生成结果每次运行到一半就报错排查起来极其痛苦。后来拆成三个独立Skill每个只做一件事稳定性大幅提升。专家这个架构设计的初衷就是要让任务边界清晰不要贪心。第三忽视版本更新带来的破坏。WorkBuddy的迭代速度很快有一次更新后我之前的Skill里使用的某个内置函数被标记为废弃导致所有定时任务全部失败。这个问题的常态化解决方案是——每次更新客户端后先跑一遍定时任务和关键Skill的测试用例不要等到第二天发现早报没推送才去追责。6.2 给刚入手的朋友的几条操作建议如果你刚接触WorkBuddy不用急着追求复杂的功能。我的建议路线是第一周先创建第一个专家只用系统设定不用Skill把对话调顺第二周尝试挂一个最简单的Prompt技能比如“转发周日报”第三周再去研究代码技能和工作流探索定时任务和外部API集成。WorkBuddy的成长空间其实很大后续我还在琢磨怎么把多个专家串成一条流水线——让“数据抓取专家”把结果丢给“数据分析专家”再让“报告生成专家”接手。目前WorkBuddy对跨专家调用的支持还不够透明但有社区经验提到可以通过共享存储文件的方式绕路实现。等我把这个链条跑通了再来写一篇进阶心得。另外说一个使用习惯我建议每个专家都固定一个使用场景不要频繁改系统设定。你可以通过创建新的专家副本来试新的设定而不是在线上专家上反复折腾。这样即使改崩了线上专家还是稳定的不影响日常使用。这是我在生产环境裸奔一个多月换来的教训。