第一次装 WorkBuddy 的时候我其实没觉得它和普通聊天助手有什么本质区别——左侧一个对话列表中间一个输入框右边偶尔弹几个插件面板。直到后来我花了一个下午把每周最烦的周报汇总流程做成一个“专家”让它自己去查工作文件夹、拉钉钉表格、按模板生成周报我才意识到这软件的真正卖点从来不是聊天而是“自己创建专家”。这篇就来聊聊我怎么从零创建一个属于自己的专家把配置流程、技能挂载、数据接入、记忆迁移和常见故障整个过一遍适合刚入手 WorkBuddy、准备认真玩转自定义专家的人也适合已经在用但只会调内置专家的朋友。1. 先搞懂 WorkBuddy 的专家机制它不是聊天预设而是一套能自动调工具的工作流刚开始用 WorkBuddy 时很多人会犯同一个错误把“专家”理解成“一个换皮的角色扮演对话”。比如建一个叫“翻译专家”的助手然后把系统提示写成“你是一名资深翻译”觉得这样就完事了。实际用下来你会发现这种专家跟普通聊天框没有任何区别翻不翻译还是看模型心情。1.1 专家到底是什么WorkBuddy 里的“专家”本质上是一个可以复用的工作流封装。它至少由四部分组成指令系统告诉专家你的身份、目标、约束、技能/插件让专家具备调用工具的能力比如读文件、查表格、发请求、知识库让专家在你的私有领域里回答问题时不靠瞎编、记忆系统让专家记住你的历史对话、偏好和项目背景。我打个比方。通用聊天助手就像一个临时叫来的自由职业者什么都会一点但每次都得重新交代背景而且没有你的业务语境。而“专家”是你亲手培训过的员工有明确的岗位说明书指令、有自己的工具箱技能、有公司内部资料可以查知识库、有上次干活的记忆记忆。你只需要把活儿丢给它它自己会按流程处理。1.2 为什么专家比通用助手好用真正的区别在于“自动化”这三个字。WorkBuddy 里的专家可以通过触发器和批处理自己启动而不仅仅是陪聊。比如我那个周报专家每周五下午四点自动扫描指定文件夹里的周报文档提取关键数据再按固定模板生成汇总最后推送到群里。中间需要我做的只是看一眼结果。这个能力来自 WorkBuddy 对“专家”这个实体的设计它可以绑定技能、挂数据源、设置触发条件而普通聊天预设只是几段话的组合。所以判断一个专家配置得好不好不是看它聊天多智能而是看它能不能“在不需要你干预的情况下完成一个有明确输入输出的任务”。1.3 CodeBuddy 和 WorkBuddy 不是一回事有人总把 CodeBuddy 和 WorkBuddy 放一起比其实它们是两个物种。CodeBuddy 的核心场景是写代码更像坐在 IDE 里的结对编程助手注重代码补全、解释、重构。WorkBuddy 的核心场景是“工作台”侧重把文档整理、数据汇总、消息推送、定时任务这些办公动作串起来。你当然可以在 WorkBuddy 里创建一个“代码审查专家”让它读仓库里的文件、按规范挑问题、生成审查报告但这不是它的主打方向。如果你要的是一个常驻在编辑器里帮你写代码的工具选 CodeBuddy 更顺手如果你要的是一个能调度文件、表格、IM、定时任务的数字员工WorkBuddy 才是对的那个。两者可以共存不是替代关系。1.4 什么场景值得你动手自建专家我的判断标准很简单凡是每周都会重复、且需要大模型参与的认知劳动都值得做成专家。周报汇总、会议纪要整理、合同要点提取、简历初筛、数据清洗、定时巡检、行业情报抓取这些场景输入输出相对固定做成专家后收益非常明显。反过来那种“今天想聊什么就聊什么”的场景没必要建专家直接用通用助手就行。建专家的成本并不低——你要写指令、配技能、调知识库、跑测试如果这件事本身就不够高频投入产出比不划算。我建议新手从一件“你每周至少要花半小时”的重复工作开始。2. 创建专家前的准备版本选型、模型接入与权限边界在真正动手创建专家之前有两件事没做好后面会反复返工一是装错了版本二是模型没接对。我见过太多人一上来就自建专家结果环境不稳定折腾半天以为是配置问题最后发现是客户端版本和模型接入的问题。2.1 版本怎么选Windows、Ubuntu、网页版、金融版WorkBuddy 的版本线有点杂不同版本对应的使用场景完全不同我按实际用途给个选型参考版本适用场景注意事项Windows 客户端日常主力办公、本地文件操作、插件管理功能最全适合建专家Linux/Ubuntu 版服务器部署、定时任务、无人值守运行更适合跑批处理和自动化网页版临时应急、多设备访问、不装客户端部分本地技能和文件权限被限制金融版/企业定制版政企内网、合规审批流、数据脱敏跟内部系统绑定普通用户用不上我自己是 Windows 客户端做日常配置和调试Ubuntu 服务器跑定时任务和长期挂机任务。建议你也采用这种“本地开发、服务器运行”的组合平时改配置在客户端上操作稳定运行交给服务端。2.2 模型接入云端 Key 和本地模型创建专家前你得先确定这个专家背后用的是什么模型。WorkBuddy 支持云端模型 API 和本地模型两种接入方式。云端的好处是响应快、理解能力强适合处理复杂指令和大量文本本地模型的好处是数据不出内网、无网络依赖但需要一定的显存和算力。我在配置里通常会同时保留两套模型配置默认场景用云端模型涉密数据和离线环境下切到本地模型。具体操作路径不复杂基本上就是在模型设置里填写 API 地址、Key、模型名称有本地部署经验的就直接填 base_url 和模型名。新手最容易踩的坑是上下文长度设置——如果你专家要处理长文档记得把上下文长度调大否则读到一半内容就被截断了专家会一本正经地告诉你“分析完毕”。2.3 设置访问文件夹范围给专家划安全边界这是很多人忽略但非常重要的一步。WorkBuddy 专家要读文件、写文件默认情况下它可以访问整个磁盘这有问题——大模型在指令理解上并不完美一个模糊的指令可能让插件把不该读取的隐私文件卷进去。我会在专家配置里明确指定一个工作目录比如D:\WorkBuddyWorkspace所有数据文件、输出文件都放这个目录里。这样有三层好处一是防止误读隐私文件二是插件搜索文件时范围小、速度快三是导出备份时只需要打包一个目录不会漏东西。建议你在创建每一个专家前先给它划好“工位”再让它干活。2.4 先跑通内置专家再开始自建WorkBuddy 自带一批内置专家我建议你装完软件后先每个试一遍。这不只是看功能而是要确认三件事模型调用是否正常、插件有没有报错、本地文件读写是否顺畅。如果连内置专家都能随机报错那大概率是环境问题而不是你配置的问题。我自己就吃过这个亏。第一次创建专家时模型明明选好了但就是频繁超时我以为是指令写得太复杂反复调整 prompt最后才发现是某个插件更新后把模型请求参数搞坏了。如果当时先跑一遍内置专家这个锅就不会甩给 prompt 了。3. 第一次创建专家把“周报整理”做成一键生成的完整流程下面用一个真实案例完整走一遍创建专家的流程。我选的场景是“周报整理”因为它足够高频、输入输出清晰、也不需要太高级的技能很适合作为第一个自建专家。3.1 从日常场景里拆需求创建专家之前先别急着写 prompt而是把需求拆清楚。我的周报整理需求是这样的每周五我要把团队成员的周报文档汇总成一份周报格式固定内容包含本周完成事项、下周计划、风险与需协调问题。拆成输入输出就是输入是工作目录下的多份周报文档Word/Markdown/PDF 混着来输出是一份格式化汇总文档按姓名归类、按三个维度整理最后还要自动生成一段适合发到群里的摘要。需求拆清楚之后你才知道这个专家需要什么技能读文件、解析多种格式、按模板输出。3.2 写系统指令可直接抄的模板系统的指令是整个专家的灵魂。我用的模板结构是角色定位 目标 输入来源 处理流程 输出格式 约束条件。下面这个模板可以直接抄把括号里的内容换成你的实际场景。你是一位周报汇总专家。 目标根据工作目录下的团队成员周报文件生成一份统一的周报汇总文档。 输入来源读取 {你的工作目录路径} 下的所有周报文件支持 .md/.docx/.pdf 格式。 处理流程 1. 扫描目录按文件名的提交时间排序。 2. 逐个提取本周完成事项下周计划风险与需协调问题三个字段。 3. 对缺失字段做标注不自行编造。 4. 按模板合并所有成员内容。 输出格式 - 生成一份 Markdown 文档标题为第X周周报汇总。 - 每位成员一个小节内容按完成/计划/风险三个列表呈现。 - 文末附一段 200 字以内的群聊摘要。 约束条件 - 如果某个文件无法解析记录文件名并跳过不要中断整个任务。 - 不要修改成员原文中的数字、日期和项目名称确保信息保真。关键点在于“约束条件”和“处理流程”写清楚了“遇到异常怎么办”。如果不写这些专家遇到一个解析失败的文件就会整个任务失败或者在缺失信息时自己脑补这是原创专家最常见的翻车原因。3.3 挂载技能和知识库光有指令还不够专家得真的能读文件。我给它挂上了 WorkBuddy 的文件解析技能让它可以处理 docx、pdf、md 等多种格式。选择技能时注意看技能的权限说明有些技能只读有些技能会执行脚本只读类技能优先。知识库的挂载也很关键。我把团队常用的项目代号、周报模板、KPI 定义整理成一份文档灌进知识库里。这样专家在整理周报时遇到项目代号能正确识别不会把“A 项目启动”理解成“A 项目就是某个完全不相关的东西”。如果你装了类似 Weknora 这类检索技能它会先把问题转成检索 query从知识库里拉出相关片段再生成回答所以知识库文档的质量直接决定专家的回答质量。3.4 用小样本测试别直接上真实数据配置完成之后强烈建议先做一轮小样本测试。我会在测试目录里放 3 份假周报故意留一份格式损坏的、一份字段缺失的看专家怎么处理。这个测试能一次性暴露三类问题指令是否清晰、技能是否够用、知识库是否命中。我第一次测试时专家在生成的汇总里把一位同事的“下周请假”识别成了“风险项”还加了注释说“可能导致项目延期”这就算过度解读。我随后在指令里明确加了“请假、休假等个人安排不算风险项”测试通过后才把真实周报放进正式目录。这个“先造假数据测、再上真实数据”的习惯建议每个专家都这样跑一遍。3.5 三套高频自定义指令模板除了周报我把另外三套日常使用率很高的专家指令模板也放出来供你直接改改用。会议纪要专家输入会议录音转写文本或笔记输出包含时间、参会人、议题、结论、待办事项及责任人的纪要重点是待办要写到“谁、做什么、什么时候完成”的颗粒度遇到不明确的责任人时拉出一份问题清单而不是猜。代码审查专家输入代码仓库路径按指定的代码规范逐文件审查输出按严重程度分级的审计报告每个问题附文件行号和修改建议只用代码块展示修改片段不把整个文件重写一遍。数据清洗专家输入 CSV/Excel 文件路径自动识别重复行、残缺值、异常格式和离群数据生成清洗前与清洗后的对比报告清洗后的文件另存为{原文件名}_cleaned.csv不覆盖原文件所有清洗规则在报告里列清楚方便追溯。这三套模板的共同思路是输出一定要结构化异常一定要有兜底原文件一定要保留。只要把握住这三个原则你自己设计的指令也不会跑偏。4. 让专家接入真实工作流文件夹、钉钉、微信定时推送指令和知识库只能让专家“会干活”但要真正提升效率还得让专家“接进来”——读你的文件、同步你的表格、把结果主动推给你。这一节聊透三个最常见的接入场景。4.1 文件夹接入专家能读到的范围由你决定文件夹接入是所有接入方式里最基础也最常用的一种。原理很简单WorkBuddy 以“工作目录”为单位给专家授权专家可以实时读取目录下的新文件并根据指令做处理。我在周报场景里就建了一个“团队成员周报投递”文件夹大家把周报丢进去专家每周五自动处理。实际操作中要注意如果是多人往同一个文件夹里丢文件尽量让文件名包含人名和时间比如张三_2025W17周报.md这样专家在排序和归属时不容易搞混。另外不要让专家自己往别人的原文件里写东西统一指定一个“输出”子目录只读输入、另写输出这个习惯能让你少挨很多骂。4.2 钉钉多维表定期同步从一次同步到周期任务钉钉多维表是目前团队协作里非常常见的数据源WorkBuddy 通过 OpenAPI 和 Webhook 做集成。第一次配置的时候建议先手动同步一次确认两个关键信息一是表 ID 和视图 ID 对不对二是字段类型映射对不对日期字段、人员字段最容易出问题。首次同步通过后再设置定时触发。我会把同步频率设成每天凌晨执行白天再让专家基于同步后的数据生成分析或日报。这里有一个很隐蔽的坑token 有效期。很多连接器配置完成后当天能用第二天就报鉴权失败大多是因为接入配置里写死了 token 且没有配置自动刷新机制。遇到定时同步中途挂掉先看鉴权日志。4.3 定时发送企业微信消息选合规通道是关键很多人搜“WorkBuddy 定时发送微信消息”其实是想让专家把结果推送到微信上这在办公场景里非常实用。但通道选择直接决定翻不翻车优先用企业微信群机器人 Webhook或者公众号模板消息这两类都算官方合规接口能长期稳定使用。我在周报场景里的做法是配置一个企业微信群机器人把生成的群聊摘要通过 Webhook 推送到团队群里周一早上 9 点自动发出。配置时注意 Webhook 地址不要泄露到公共仓库里可以放环境变量。至于个人微信号自动发消息我不推荐用任何非官方外挂手段去做风控风险太高、稳定性也没保证办公场景选企业微信通道足够满足 90% 的需求。4.4 把多个动作串成批处理单个技能能干一件事多技能串联才是批处理。我的周报专家实际执行链路是定时触发 → 扫描文件夹 → 解析文档 → 生成汇总 → 推送群消息。中间每一步都是独立的技能WorkBuddy 按顺序执行某一步失败时自动重试并记录日志不会把半成品推出去。批处理串好后专家才真正从“对话工具”变成了“数字员工”。试想一下普通聊天方式是你复制粘贴十份周报、让助手整理、再复制结果发群里批处理是你周五下午看一眼推送结果确认没问题。这个体验差别只有你亲自配一次才能体会。5. 记忆管理历史对话、本地记忆迁移与长期记忆创建专家不难难的是让它“越用越懂你”。这就涉及到记忆系统。很多用户觉得 WorkBuddy 的专家总是“忘事”其实是没搞懂它的记忆机制是怎么运作的。5.1 历史对话记录存在哪WorkBuddy 的历史对话记录默认存在本地数据目录里一般是用户目录下的.workbuddy/history之类的文件夹存成 SQLite 或 JSON 文件。网页版的历史记录则存在云端跟本地数据不互通这点建议一开始就知道别在网页版里聊了一堆重要内容本地客户端里什么都看不到。如果你准备长期使用我建议定期把历史记录目录和专家配置目录放到一个总目录下做统一备份。原因很简单记忆是专家资产的一部分丢失了专家就像失忆了一次虽然指令和知识库还在但上下文里的业务细节全没了。5.2 换机迁移记忆的完整操作WorkBuddy 换机是很多人的痛点其实整条链路就三步备份、迁移、验证。第一步在旧机器上把数据目录完整打包里面至少要包含历史记录、专家配置、知识库索引、插件配置四个部分第二步在新机器上安装同版本客户端先把程序跑一次退出再用备份内容覆盖默认数据目录第三步启动后先打开历史对话确认记录还在再运行一个内置专家确认插件正常最后才打开你自建的专家验证配置没有被破坏。迁移时最容易丢的不是历史记录而是知识库索引。很多用户备份了知识库原文档但忘了索引文件新机器上检索效果明显变差误以为模型出问题了。所以迁移时尽量整个数据目录一起搬不要只挑历史记录。5.3 长期记忆和短期记忆的边界WorkBuddy 的记忆要分开看待短期记忆就是对话上下文窗口内的内容窗口一满前面的对话就会逐渐被“忘记”这是模型架构决定的长期记忆则是持续保存在本地的用户偏好、事实信息可以在每次对话开始时自动加载。根据我的实测自建专家最好把“计划性偏好”写进长期记忆比如“每周五下午生成周报”“风险项包含人员请假、关键路径延迟、第三方接口故障”这类因为它们会在每次对话中被自动注入。而临时数据比如某次测试的具体文件名单不用放进长期记忆它会占用上下文空间。5.4 记忆跑偏清理、重置、重建最烦的情况是专家用久了记忆被污染了。比如上个月你临时让它把所有文档都按英文命名处理结果这个偏好被写进长期记忆这周正常中文命名反而被它报错。遇到这种情况我的做法是三步走先打开记忆管理面板逐条检查长期记忆里有哪些“残留偏好”把临时性的条目删掉然后对当前对话执行“重置上下文”让临时记忆清空最后如果需要保留的长期记忆不多就直接清空记忆库重新灌入标准偏好。这个操作比反复调教省钱多了别跟记忆里的烂数据死磕。6. 进阶玩法本地部署、开发者平台与专家资产化当你的专家数量多起来之后就会开始考虑几个问题能不能把它放到服务器上 24 小时运行能不能把自己做的技能打包给别人用能不能把专家资产沉淀成自己的核心竞争力这是从入门到进阶的一道分水岭。6.1 本地部署的两种路线本地部署有两种主流路线容器化部署和裸机部署。容器化部署用 Docker Compose 拉镜像挂载数据目录配置好模型 API 地址后一把梭好处是干净、易迁移服务器换机时直接搬容器配置裸机部署则需要手动装运行时依赖、数据库和 Web 服务适合服务器环境受限、不方便跑 Docker 的场景。我把 WorkBuddy 部署在自己的一台 Ubuntu 小主机上专门跑定时任务客户端在 Windows 笔记本上做日常配置。这样配置与运行分离升级客户端也不会影响线上任务。有一点需要注意本地部署后的默认端口、防火墙规则要提前规划好否则局域网里的其他设备访问不了工作台排查时又以为是软件问题。6.2 开发者平台与 Skill 标准化WorkBuddy 的开发者平台是进阶玩家最值得花时间的地方。你把一段重复执行的技能固化成 Standard Skill 后它就不再是“某个专家里的私货”而是可以被多个专家复用的公共能力。我自己把“读取指定目录下的表格并汇总”做成了一个标准化 Skill结构包含一个描述文件声明功能、参数、权限、一个执行脚本处理实际逻辑、一段使用说明。发布后我在任何新专家里都能一键挂载不必重复编写。开发 Skill 时建议从小而通用的切口入手比如“解析 PDF 提取表格”“按关键词检索本地文档”这样的技能复用的次数最多。6.3 专家包的导入导出与团队共享WorkBuddy 支持把专家配置导出成独立的包包含指令、技能清单、知识库引用和记忆配置。这个能力在团队场景里特别好用你搭好一个专家导出给同事同事导入后只需要改一下模型配置和文件夹路径就能直接用。团队共享时最常遇到的问题就是路径和权限不一样。导出共享的专家包我建议使用相对路径或环境变量来引用目录不要写死D:\张三\周报目录这样的绝对路径。另外共享专家包之前一定要检查有没有泄露 API Key、Webhook 地址之类的敏感信息之前就有同事把企业微信机器人地址直接发到群里整条群消息频道直接废了。6.4 把“专家库”变成个人资产玩到后期你会发现专家库本身就是一笔资产。你在某个垂直领域积累的专家包含了你对业务流程的理解、对提示词的精调、对工具链的取舍这些是无法靠下载一个现成插件获得的。我的建议是给专家库做一个“资产清单”每个专家记录解决的问题、用到的技能、预期投入产出比、最近一次更新时间。这样既能帮助你发现哪些专家价值高、哪些已经过时也能在写简历、写经验分享时快速整理出素材。现在还有对应的效率智能体从业者认证路线可考对想把这条技能路线写进履历的人来说有个认证背书还是比嘴上说更靠谱一些。7. 常见故障复盘启动慢和网络连接 3002 的完整排查链路再好的工具也会遇到问题WorkBuddy 最常见的两个毛病是启动非常慢和网络连接失败 3002。这里把我踩过的坑和排查思路完整复盘一遍能帮你少走不少弯路。7.1 启动慢从日志到插件的五步排查WorkBuddy 启动慢我的排查顺序是从全局到局部第一步看首次启动还是持续启动慢。首次启动要建立索引、加载模型配置慢是正常的如果每次都慢继续往下查。第二步检查插件数量。插件装得越多启动时需要初始化的就越多我遇到过装了 20 多个技能卡片后启动要等一分半的情况禁用掉不常用的插件后恢复到 15 秒内。第三步检查本地模型是否常驻内存。如果你配了本地模型且启动时自动加载初始化会非常慢把模型启动方式改成按需加载一开软件就启动的问题立刻缓解。第四步检查数据目录所在磁盘。机械硬盘和远程映射盘会让索引和日志的读写速度大幅下降把数据目录放在本地固态盘上。第五步开启启动日志看哪一步耗时最长。日志里会明确标注模型加载、插件初始化、索引构建各用多少秒定位到具体瓶颈再对症下药。7.2 网络连接失败 3002连接层问题的定位思路3002 这个报错我遇到过三次每次原因都不一样所以它本质上是一个“连接层失败”的笼统错误不是单一问题。排查链路应该这样走先判断是全局网络问题还是只有 WorkBuddy 连不上目标服务。打开终端对模型 API 的域名做一次 HTTPS 连通性测试如果 ping 不通或超时先解决网络连通性如果网络正常但 WorkBuddy 报 3002大概率是系统级代理设置干扰检查本机系统代理关闭代理后再试一次排除网络和代理后检查系统时间是否同步时间偏差过大会导致 TLS 证书校验失败再检查模型 API 的接入配置包括 Key 是否过期、服务商账号余额是否不足、API 地址是否填错。我自己的经验里3002 的常见原因排序是企业网络对 API 域名做了限制 代理设置残留 证书时间错误 Key 失效。如果你在局域网环境还要同步确认防火墙有没有放行 WorkBuddy 需要访问的目标端口。7.3 专家突然变笨插件冲突与配置回滚“专家突然变笨”是很有迷惑性的问题昨天还好好的今天输出质量断崖式下跌而且没有改过任何配置。大多数人第一反应是模型问题其实更常见的是插件冲突或版本更新导致的配置漂移。排查方法是我前面提到的二分法先把正在用的专家切换成系统内置专家如果内置专家正常说明问题是自建专家专属然后再把自建专家的插件禁用掉一半看问题是否消失没消失就换另一半快速定位到冲突插件。定位后优先更新或卸载那个插件而不是回滚整个专家。如果确实是你改配置改坏的WorkBuddy 对专家配置一般有历史版本记录直接回滚到昨天或上周的可用版本再对比差异项比从头调一遍快得多。我建议在每次调整指令之后都手动记录一下变动内容方便出问题时快速回退。7.4 日志到底怎么看很多用户看到日志就头大其实 WorkBuddy 的日志只需要看两个关键点时间戳和错误级别。启动阶段看 INFO 和 ERROR运行阶段重点看 ERROR 和 WARN。日志文件位置一般在数据目录的 logs 子目录里服务端部署模式下客户端报错信息不够时直接去服务端日志搜时间戳附近的报错堆栈。排查时的操作习惯出错后先复制报错时间再切到日志文件里定位同一时间段的内容把 ERROR 级别的记录一条条看。大部分问题在错误信息里已经写得很直白了要么是权限、要么是超时、要么是格式解析失败。如果日志里已经是 ERROR 而不是直接闪退说明程序把异常兜住了只需要根据报错内容修配置即可。最后说点个人体会。WorkBuddy 这类工具的深入学习不是背功能清单而是练一种“把重复工作拆成流程再固化成专家”的结构化思维。工具本身总有迭代但你自己沉淀出来的专家库和排查思路才是真正留得下来的东西。网上有人问“WorkBuddy 到底是不是小龙虾”这个谐音梗我至今也没考证出官方说法当个乐子看就好。真遇到问题先看日志再关插件基本能解决一大半。