很多人第一次打开WorkBuddy都会下意识把它当成一个AI聊天框。我最初也是这样问几个问题、让它写段话然后就觉得“这不就是个套壳对话工具吗”。直到我把自己重复做了三周的“项目周报整理”交给一个自定义专家来处理才真正意识到WorkBuddy的核心价值从来不是聊天而是“自己创建专家”这件事。这篇攻略就以这个为主线从底层机制、自定义指令编写、Skill挂载、记忆迁移一直到Linux部署和常见报错排查完整过一遍适合想在企业或个人工作流里真正落地WorkBuddy的人。1. WorkBuddy与CodeBuddy不是一回事先搞懂“专家”的底层逻辑1.1 两个产品到底分在哪很多人会在热搜里同时搜CodeBuddy和WorkBuddy然后困惑这两个是不是同一个东西。简单说CodeBuddy是面向开发者的AI编程助手它的主战场是代码续写、解释、重构、修bug围绕IDE和命令行工作。而WorkBuddy是效率智能体工作台它的主战场是整个工作流不只写代码还可以处理文档、对接表格、定时执行任务、编排多个Agent协作。我个人的理解是CodeBuddy帮你“把活干完”WorkBuddy帮你“把活安排明白”。WorkBuddy更像一个你可以自己搭建员工队伍的中控台每个员工就是一位“专家”你负责定义他们的职责、边界、能力和使用的工具。这个区别决定了二者的使用方式完全不同CodeBuddy装好就能用WorkBuddy需要你先花一点时间把专家“造”出来然后才进入真正高效的状态。1.2 所谓“专家”本质是什么如果拆开看WorkBuddy里的一个专家至少包含三部分。角色与指令相当于岗位说明书告诉模型你是谁、你擅长什么、用什么风格回答、绝对不做什么。技能与连接器相当于工具箱Skill可以是内置的文档检索、网页抓取、代码执行能力也可以挂载外部API或自动化脚本。执行边界与记忆相当于工作空间和档案柜专家只能访问你授权的目录同时能读取历史对话和本地记忆保证回答有连续性。你可以把专家理解成“给大模型戴上职业帽子再配齐工具箱最后圈定办公区域”。没有指令模型是万金油有了指令模型才是某个岗位上的熟手。我见过不少团队把WorkBuddy部署完就丢给全员用结果大家感觉“也就那样”原因就是根本没人去定义专家它当然只能像一个什么都会一点的实习生而不是一个能独立扛事的专员。1.3 为什么自己创建专家比用通用助手更值通用AI助手的瓶颈不是模型能力而是没有“上下文约束”。同一个问题你问通用助手它给你一套泛泛的标准答案你问一个绑定了团队规范、历史案例、业务数据的专家它给你的就是可以直接落地的方案。我举一个实际例子我给自己建了一个“技术方案评审专家”只用了大约一个下午写指令、挂Skill之后每次评审方案它都会严格按团队模板输出风险清单、资源估算和上线建议。这个价值不是“省一次提问时间”而是把整个评审流程的隐性经验固化成了可复用的资产。所以这里想强调一句WorkBuddy的真正投入点不是部署那一两个小时而是创建工作区里每位专家所花费的思考时间。这也是这篇攻略后面每一章都在围绕的核心——如何把“专家”这件事做实、做细。2. 手把手创建第一个专家以“技术方案评审专家”为例2.1 别一上来就造“全能专家”第一个专家选什么场景直接决定了你能不能坚持用下去。我的建议是三个条件高频、有明确输出标准、结果容易被判断好坏。拿“技术方案评审专家”来说几乎所有研发团队每周都要评审方案评审结果有固定模板方案好不好看它是否覆盖风险、是否有量化指标就够了。这样的场景做出来见效快也方便你迭代。相反如果你一上来就想做一个“全知型业务顾问”没有明确输出标准你会发现改了三天指令还是不满意然后就放弃了。这不是WorkBuddy不行是场景选错了。先把一个最痛的重复劳动拿出来做成全自动或半自动再考虑扩展到其他领域。2.2 自定义指令模板可以直接抄的版本写自定义指令是创建专家最关键的一步。我自己的经验是不要写成“絮絮叨叨的说明书”而要按“角色目标、能力边界、工作流程、输出格式、硬性禁忌”五段式来写。下面这个模板是我在做的“技术方案评审专家”指令拿去改一改就能用。你是技术方案评审专家负责对开发团队提交的技术方案进行评审。 你的目标 1. 发现方案中的技术风险、资源缺口和逻辑漏洞。 2. 给出可执行的改进建议而不是只指出问题。 3. 输出统一格式的评审意见便于直接贴进评审单。 能力边界 - 你有权调用团队知识库中的历史方案和架构规范。 - 如果涉及具体代码你只能分析伪代码或片段不能假设仓库结构。 - 对于你不确定的部署环境细节必须明确标注“需要补充确认”。 评审流程按顺序执行 1. 先理解方案的业务目标和成功标准。 2. 再检查技术选型、架构设计、数据模型、接口设计、安全与合规。 3. 最后评估实施计划、里程碑和回滚方案。 输出格式 ## 评审结论通过/有条件通过/不通过 ## 主要风险按严重程度排序 ## 资源与时间评估 ## 具体改进建议 ## 需要补充的信息 硬性禁忌 - 不要输出空泛的赞美。 - 不要忽略安全合规问题。 - 如果输入内容与方案评审无关直接提示并提供正确用法。这里有一个细节你可能一开始会忽视最后一条“硬性禁忌”特别重要。不加这条专家在被问无关问题时也会一本正经地答看起来就很“AI”。加上之后它就像一个真的在职员工知道自己的岗位边界。2.3 创建与绑定的完整操作路径在WorkBuddy工作台里一般路径是“创建专家 - 填写名称和描述 - 粘贴指令 - 选择模型参数 - 添加Skill或连接器 - 保存”。我实际使用中的建议名称尽量用“岗位场景”组合比如“技术方案评审专家”就比“方案助手”好用因为后面专家数量多了之后搜索和切换都靠名称。模型参数这里值得多说一句。如果你用的专家任务偏逻辑分析比如评审、审计、排障温度参数建议调低默认的随机性会让它输出不够稳定如果是创意写作类专家可以适当调高。这个参数不是越大越聪明而是控制输出的随机程度。评审专家我通常会调到接近最低档。保存之后找一个真实的历史方案喂进去做测试。注意这里的测试不是看它说得好不好听而是对照你的输出格式模板逐项核对是否有遗漏。第一次跑完大概率有格式不标准、语气不对的问题这很正常进入下一步迭代。2.4 迭代比一次写完美重要我踩过最大的坑就是想一次性把指令写到“完美”结果一上午都在改字句。后来我调整了策略第一版能用就行然后每周把实际评审中出现的“好答案”和“差答案”反哺回指令里。比如有一次专家漏掉了回滚方案我在指令的评审流程里加了一行“回滚方案必须是单独小节”又比如它总爱用“整体来看”开头我在硬性禁忌里加了“禁止使用空泛开场白”。这种“用例反哺”的方式本质上是在给专家积累经验。时间越长专家越贴合你的团队风格。所以如果你问我WorkBuddy的投入产出比什么时候会出现拐点我的体感是大约两周也就是迭代了三四轮之后。3. 让专家真正干活Skill连接器、UI自动化与定时任务实战3.1 Skill机制和WeKnora知识库怎么用只靠指令的专家本质上还是一个“聪明但没资料”的顾问。要让它在具体领域里靠谱必须挂Skill。Skill在WorkBuddy里可以理解成可复用的能力单元文档解析、网页检索、代码执行、数据同步都算Skill。很多人问WeKnora在WorkBuddy里怎么用。我自己的理解WeKnora是WorkBuddy里的知识库/检索组件它做的事情是把你的本地文档切成片段、做向量化然后让专家在回答时先检索这些片段再生成答案。你可以把WeKnora当成“专家专用的资料室”没有它专家靠的是通用训练数据里的记忆有了它专家回答问题时可以先翻你指定的资料。操作上一般是两步先在知识库管理里上传文档、建立索引然后在创建或编辑专家时勾选这个知识库。这里有一个容易被忽略的参数——检索返回的片段数量。默认值往往偏保守导致专家只看到一两段资料就急着回答遇到复杂问题容易片面。我通常会把top-k调到5到8左右同时把相似度阈值设得稍微高一点避免无关文档干扰回答。不过这个参数没有绝对标准跟你文档切分的粒度有关建议在你的真实文档上多做几次实验。3.2 连接器钉钉多维表定期同步的配置经验热词里频繁出现“WorkBuddy钉钉多维表定期同步”说明很多人和我一样是想让它自动从钉钉多维表拉数据再生成周报或汇总。这个需求实现起来并不复杂核心是连接器和定时任务两块。连接器本质上是一个授权通道让专家能读写钉钉多维表。配置时要注意三点授权范围按最小化原则只授权需要同步的那几张表不要一上来就授全部文档权限。字段映射要先在Excel或CSV里排好多维表里的“日期”字段在WorkBuddy里经常被识别成字符串导致排序错误建议在同步逻辑里统一做一次类型转换。定时任务建议先用手动触发跑通再设置每天或每周的周期否则你面对的可能是一个半夜三点跑失败的任务第二天看到一堆重复数据。同步任务建立之后专家相当于有了“自动取数”的能力。我实际用下来最大的收益不是省了复制粘贴的时间而是数据到了WorkBuddy之后可以立刻接上后续的整理、汇总、生成报告形成一个完整的自动化链路。3.3 用WorkBuddy做UI自动化的思路用WorkBuddy做UI自动化是热搜里的另一个高频话题。很多人以为这是像RPA那样录制一遍鼠标键盘就完事其实WorkBuddy做UI自动化的思路更像“让专家看懂界面再操作”。它可以结合视觉模型识别页面元素再调用自动化脚本执行点击、填表、提交。我的实践是在一个内部系统的数据录入场景里用起来的原本每天要手工把几十条数据从Excel粘到网页表单里我写了一个带UI自动化Skill的专家专家负责读Excel、解析字段、定位页面输入框、逐个填写并校验结果。中间遇到的最大坑是页面元素会动态变化硬编码坐标完全不可靠。后来改用“先让模型描述看到的界面再生成对应元素定位器”的方式稳定性才上来。这个方向门槛不低但回报也很直接。如果你所在团队的日常有大量重复网页操作非常值得投入。我个人的经验是不要试图一开始就做一个全自动无人值守的方案而是先做“专家执行、人工抽查”。跑一周确认稳定之后再把人工环节去掉。3.4 定时发送消息用Webhook而不是个人号自动化关于“WorkBuddy定时发送微信消息”必须提醒一句个人微信的自动化存在很大的账号风险我不建议你往那个方向折腾。安全可控的做法是用企业微信机器人或钉钉机器人的Webhook地址让专家在任务完成后往群里推送一条汇总消息。实现上并不复杂在群里添加一个自定义机器人拿到Webhook URL然后在WorkBuddy的Skill或定时任务里配置一个HTTP请求把专家生成的内容以JSON格式POST过去。我目前的一个常规流程是每周五下午四点专家自动汇总本周钉钉多维表里的任务进度生成一段简洁总结推送到团队群。整个链路跑了几周最大的感受是“定时任务的价值不是提醒而是逼着专家在一个固定节奏里产出固定格式的结果”这对团队管理的帮助比想象中大。4. 记忆与上下文管理历史记录迁移和本地文件范围4.1 历史对话记录和本地记忆怎么迁移WorkBuddy用久了每个专家都会积累不少历史对话这些对话里往往藏着很多有效的上下文信息。我重装系统的时候最担心的就是这些记录丢。WorkBuddy的数据一般存放在本地配置目录里包含各个专家的历史消息、导入的知识库索引、以及用户级设置。迁移其实不复杂三步就能做完先退出WorkBuddy确保没有进程在写数据。把整个配置数据目录打包备份目录位置每个平台不完全一样但从你安装时指定的数据路径就能找到。到新机器上装好同版本WorkBuddy先启动一次让它生成默认目录再退出把备份内容覆盖回去。这里有个细节不要直接覆盖正在运行中的目录否则容易出现索引文件损坏。我第一次迁移时图省事没退进程就拷文件结果知识库索引坏了只能重新建那个教训挺深刻。另外历史记录迁移不迁移模型缓存的模型文件体积大且可以重新下载一般不用一起搬。4.2 用户目录前面那个点是什么搜“workbuddy 目录 前面 有个.”的人多半是在Linux或者macOS上安装之后发现用户目录下多了一个以点开头的隐藏目录。这不是病毒也不是Bug。Linux和macOS的惯例就是用点开头表示隐藏目录WorkBuddy把配置、日志、缓存和本地数据放在这里是为了不干扰你日常工作目录的整洁。你不需要手动删除它也不需要每天进去看。它里面通常有几个子目录配置目录、日志目录、缓存目录、专家数据目录。维护时真正需要关心的是磁盘占用。因为知识库索引和模型缓存可能体积不小如果你发现空间紧张可以进去看缓存目录能否清理但要保留配置和专家数据。4.3 设置访问文件夹范围给专家划好“工位”安全这件事很多人一开始不在乎等出了问题才后悔。WorkBuddy中一个被低估的功能就是“访问文件夹范围”设置。如果不设置专家理论上在回答时可能会读取系统中大量文件既影响隐私也会让检索变慢。我的做法是为每位专家设置独立的白名单目录。比如“技术方案评审专家”只允许读团队的方案归档目录不允许访问个人下载目录和系统目录“数据处理专家”只允许读数据源目录写结果时也只能写到指定输出目录。设置方式通常在专家的权限或安全配置里可以在创建时指定也可以后续编辑。这个习惯带来的直接好处有两个一是避免敏感资料被无关专家读到二是检索性能有明显改善。因为模型在回答时会优先在授权目录里找信息范围小了命中率和速度都会上升。5. Linux部署实录启动慢、网络连接失败3002与目录细节5.1 Linux/Ubuntu安装步骤WorkBuddy支持Linux这对不少运维和开发同学来说是好消息。以Ubuntu为例安装前建议先确认系统满足基本依赖包括较新版本的Python、常用的构建工具和网络环境。具体安装命令取决于你拿到的安装包形式但一般流程是# 解压安装包到指定目录 tar -xzf workbuddy-linux-x86_64.tar.gz -C ~/apps/workbuddy # 进入目录执行安装脚本 cd ~/apps/workbuddy ./install.sh # 安装完成后启动 ./workbuddy start安装过程中最容易被忽略的是启动方式。WorkBuddy是带后台服务的如果你直接用前台方式跑关掉终端它就停了。我建议使用systemd或者你习惯的进程守护工具把它托管起来同时把日志输出到固定文件这样排查问题时才有据可查。5.2 启动非常慢的原因和提速方案“WorkBuddy启动非常慢”是求助热词里的常客。根据我自己的观察慢的主要原因通常有三个。第一是首次启动时要建立本地索引。尤其是你授权了很大的目录范围它会扫描并切分文档这一步第一次特别慢。解决方案是缩小扫描范围只在需要检索的目录上建立索引别把整个home目录都丢进去。第二是启动时要检查网络和同步远端配置。如果你的网络环境不稳定启动过程会在超时重试上耗费大量时间。日志里通常能看到反复的连接超时记录。解决方案是把超时时间调短或者确认服务端地址配置正确。第三是模型加载和缓存预热。如果你本地部署了较大体积的模型冷启动加载就要吃掉不少时间。这个场景下可以考虑模型常驻内存或者只在需要时加载。排查启动慢我的建议是不要瞎猜先看启动日志。日志会明确告诉你时间花在哪一步。热词里那句“启动非常慢”八成就是以上三种原因的组合顺序排查下来基本能找到瓶颈。5.3 网络连接失败3002排查链路3002这个报错我在社区看到不少人遇到过。它的本质是WorkBuddy客户端无法连接到它所依赖的服务端。常见的排查链路我整理成表格你按顺序过一遍定位效率会高很多。排查步骤具体操作说明检查服务端进程 | 执行workbuddy status或查看端口监听 | 确认服务是真的起来了而不是只启动了客户端检查网络连通性 | ping或curl服务端地址和端口 | 确认本机到服务端的网络路径是通的检查证书配置 | 查看配置中服务端地址是否为http/https证书是否有效 | 自签名证书场景常见需要手动信任检查时间同步 | date命令确认系统时间是否正确 | 时间偏差过大时TLS握手会失败查看详细日志 | 找到日志文件检索3002附近的异常堆栈 | 日志是最终判断依据不要跳过这里要特别提醒排查网络问题一定先确认基础网络设置不要一上来就怀疑是产品问题。我遇到过不少次3002最后发现是服务端地址配置错误或证书过期。按表格从第一步开始很少需要走到第五步以后。5.4 开发者平台与OBC从业者认证最后聊一下生态。WorkBuddy有对应的开发者平台你创建好的专家除了自用还可以考虑发布到团队或更大的范围复用。腾讯效率智能体OBC从业者认证这类体系本质上是在培养一批能把WorkBuddy和智能体工作流落地的人。如果你要负责把WorkBuddy引入团队我建议去了解一下认证内容它会帮你把“会用”升级成“会设计”尤其是工作流编排和专家治理这部分光靠看文档学不来的。从我这几周的实践来看创建专家的过程其实也是梳理自己工作流程的过程。你被迫把那些“只可意会”的做事方法写成指令、配成Skill、圈定边界这件事本身就是效率提升。如果你正准备开始我的建议很简单选一个最让你头疼的重复任务按第二章的方法先创建一个专家剩下的问题等你在实际使用中遇到了再回来翻这篇攻略。