ARTICLE DETAIL

建站实战干货

来自一线的建站与推广经验沉淀,每一条都经过真实交付验证。

WorkBuddy专家创建全流程:从人设设计到知识库配置与迭代

2026/9/12 3:11:34 拓冰建站 浏览量
WorkBuddy专家创建全流程:从人设设计到知识库配置与迭代 最近好几个朋友来问我同一件事WorkBuddy里到底怎么自己创建专家他们大多是冲着AI办公自动化来的结果进了工作台看到一堆按钮不知道从哪下手好不容易建出来的专家回答又空又官方跟官方演示里那种懂行的感觉差太远。我的看法是这类智能体工作台的核心价值不在开箱即用而在你愿不愿意花半小时把专家的人设流程边界讲清楚。这篇内容就是把从零创建WorkBuddy专家的完整过程拆开讲清楚前置设计怎么做、自定义指令怎么写、知识库怎么配、记忆和迭代怎么管最后配上我实测踩过的坑。无论你是第一次打开WorkBuddy还是已经建过一两个但效果不理想都可以直接把这套流程搬到自己的工作台里试一遍。1. 先搞明白WorkBuddy是什么角色它和CodeBuddy的分工决定你的用法1.1 一个数字员工平台而不是又一个ChatGPT外壳CodeBuddy和WorkBuddy这两个名字经常一起出现很多新手以为它们是同一个产品的不同入口实际使用姿势完全不同。CodeBuddy的战场在IDE里核心是写代码、查报错、做代码评审这类研发活WorkBuddy则是一个更通用的智能体工作台面向的是日常办公、信息整理、流程执行这类偏业务和运营的场景。简单类比一下CodeBuddy是帮你写代码的资深研发同事WorkBuddy是你自己培养的数字员工——你可以把岗位职责、工作流程、说话话术都定义好然后它按你的要求干活。这也是为什么WorkBuddy里会有专家这个概念。第一次看到这个词时我一度以为它只是更聪明的助手后来用下来才意识到完全不是一回事。专家等于一套完整的数字员工配置包括角色定义、行为规则、知识来源、可用工具、记忆状态。同一个底层模型配不同的指令和知识库输出完全可以像两个不同的人一个可以严谨到每条结论都标数据来源另一个也可以像闲聊助手一样随性。理解这一层你才算真正理解了WorkBuddy的用法。1.2 创建专家解决的是复用和标准化的效率问题单独一个人创建一个专家价值可能没那么明显因为你直接打开对话框问模型也一样能得到答案。但放到团队场景里专家的价值立刻体现出来调好一个专家后团队里所有人都能调用同一个口径的AI输出不用每个人都从零写一遍提示词也不会出现同一个问题四个人问出四种答案的情况。这种标准化输出在我看来是企业场景里比单次问答质量重要得多的东西。所以当你准备在WorkBuddy里创建专家时先想清楚一个问题这个专家是给谁用的如果只是自己偶尔用指令随便写都行如果要共享给团队就得在角色定义、规则约束、输出格式上多花精力因为别人不会像你一样知道这个专家当初是怎么想的。1.3 先分清你是要助手还是要专家这是创建前必做的选择题。维度泛用助手专属专家职责范围宽泛什么都能聊聚焦单一职责主动拒绝范围外任务指令长度短几十字即可长通常几百字起步知识库可有可无几乎必须配置记忆要求无所谓需要长期记忆和上下文适用场景个人尝鲜、临时问答团队固定流程、批量任务我见过不少人在新建专家页面上随手填了个名字、写了一行提示词然后把它当成高级版对话机器人最后效果不满意就得出WorkBuddy不行的结论。其实是定位没选对。如果你需要的是专家就要接受它需要更长的指令、更明确的知识库和更长的调试周期。想清楚这一点后面的每一步才有意义。2. 创建专家前先把人设定好职责、流程、知识库三件套2.1 用一页纸写下职责边界而不是直接打开对话框我说个自己的真实教训。第一次创建专家时我直接打开配置页开始写指令写了删、删了写折腾两小时还是觉得不对。后来换了个方法先关掉WorkBuddy拿一张纸把下面三个问题写清楚这个专家要解决什么高频任务比如把会议录音转成结构化纪要把零散工作记录整理成周报。哪些任务坚决不接比如不做项目进度总结不提供建议只做事实整理。遇到超出范围的任务怎么处理比如统一回复固定话术并引导用户联系对应负责人。如果这三条你用一句话答不出来说明这个专家还没到你动手创建的时候。职责边界想清楚之后会直接决定后面的自定义指令写什么、知识库放什么、技能开哪些。边界不写清楚AI就默认什么都能聊输出自然容易跑偏。2.2 把输入-处理-输出的链路定义到可直接执行有了职责边界下一步是把工作流拆成三段输入什么、怎么处理、输出成什么样。同一件事定义得越细专家越不需要用户额外解释。举个例子周报整理专家的链路可以是输入本周完成事项的零散记录处理按成果/问题/计划分类、去重、压缩要点输出三段式Markdown周报每段不超过5条每条尽量带上可量化数据。这样的链路定义有一个额外好处专家会主动引导用户给素材。你不需要每次都对它解释我要什么格式它自己就会按规则来。很多专家用起来笨不是模型不行而是你根本没告诉它流程是什么它只能靠猜。2.3 知识库素材的准备别什么都往里面塞知识库是专家专业感的主要来源但也不是越多越好。按我的经验适合放进知识库的素材主要有四种企业内部规范、领域术语表、历史案例、高质量模板范例。不适合放的是那些模型本身已经掌握得很好的通用常识比如什么是复利这种你放进去反而可能干扰模型原有的判断。文件格式上WorkBuddy一般支持纯文本、Markdown、PDF等常见格式。上传前有个小技巧把长篇文档拆成主题明确的小文件用清晰的文件名比如2025-Q3-资讯整理规范.md而不是丢一个几百页的PDF进去。长篇文档虽然也能解析但检索精度会明显下降拆开后命中率会好很多。知识库的更新机制也得提前想好。我见过不少团队的专家刚建完很能打两个月后知识过期了也没人维护输出质量慢慢崩掉。建议在团队里指定一个负责人至少每周过一遍知识库增量有变更及时替换。2.4 判断要不要开联网和技能原则是能不开就不开有些任务需要实时信息比如查当天汇率、看最新政策有些任务只需要本地资料。默认情况下我建议先把专家做瘦——用最少的技能把核心流程跑通再按需添加。原因很简单能力和技能开得越多模型在生成时就越容易混杂不相关的东西维护成本也越高。比如一个周报整理专家完全不需要联网和网页抓取而一个资讯整理专家才需要考虑挂载网页正文提取这类技能。3. 核心实操从新建专家到第一次像样的对话3.1 新建专家入口与基础信息名称就是第一份指令登录WorkBuddy工作台之后在专家列表的底部或者页面右上角一般能找到新建专家入口。创建时要填名称、头像和简介。这里我强烈建议名称直接用职责对象的格式比如周报整理专员竞品信息分析员会议纪要整理专家不要起小智大白这种只有自己懂的名字。因为专家一旦共享给团队别人在列表里是靠名称来认它的。简介也别写空话写清楚这个专家能用它干什么方便团队其他成员快速判断要不要用。3.2 自定义指令System Prompt专家的岗位说明书自定义指令是整个创建过程的重头戏WorkBuddy里一般叫自定义指令或系统提示词。它的作用等价于给这个专家写一份岗位说明书和工作手册。写的时候别丢一行你是个AI助手就完事我用的是一套固定的黄金结构# 角色 你是... # 目标 你负责完成... # 工作流程 1. 收到输入后先... 2. 然后... 3. 最后... # 规则 - 必须... - 禁止... # 输出要求 - 使用Markdown - 结构包括... # 边界 - 当遇到...时回复...不自行处理这套结构的好处是把身份、目标、流程、规则、格式、边界六个要素都覆盖到了模型拿到之后很清楚自己该干什么。我拿周报整理专员举个完整示例# 角色 你是某科技公司的周报整理专员负责把员工的零散工作记录整理成规范周报。 # 目标 产出一份可直接提交的周报包含成果、问题、计划三部分。 # 工作流程 1. 读取用户提供的原始记录 2. 按成果/问题/计划分类去除重复和无价值信息 3. 将每条要点压缩到20字以内尽量带上可量化数据 4. 按输出格式生成周报并在末尾列出待补充信息。 # 输出要求 使用Markdown包含 - 本周成果最多5条 - 遗留问题最多3条 - 下周计划最多5条 - 数据待补充如有单独列出 # 边界 用户请教的非周报问题统一回复我只负责周报整理请把问题发给对应负责人。写完指令先别追求完美保存后立刻做一轮测试对话看看输出符不符合预期再根据实际问题修改。3.3 知识库上传与实际操作细节在专家配置页面找到知识库入口上传你准备好的文件或文档。上传后系统会做向量化处理这一步通常需要几分钟。注意一个细节不要在向量化还没完成时就开始测试否则大概率检索不到内容你会误以为知识库失效。我的习惯是上传后先去干别的回来看到状态变成已完成再测试。如果同一个专家需要多个知识库来源建议按主题分开建比如术语库历史案例库规范文档库。检索时会自动匹配最相关的片段分开建比塞一个混合大文件效果好得多。3.4 Skill技能挂载给专家装工具但要限定触发条件技能Skill是WorkBuddy的扩展能力入口相当于给专家安装工具插件。比如需要搜索网页、解析特定格式文件、访问企业内部系统都可以通过技能实现。这里最容易犯的错误是把所有技能一股脑全挂上去。挂得越多专家越容易在日常对话里误用反而影响输出质量。我给每个技能都会写明触发条件比如仅在用户明确要求查询实时信息时才调用网页搜索技能这样专家就知道什么时候该用、什么时候不该用。3.5 保存、发布与共享范围先私有再小范围后全员配置完成后点击保存通常会让你选择可见范围仅自己可见、指定成员可见、团队共享。我的建议是走三步走先用私有范围自己测试测到基本稳定后分享给三五个人小范围试用收集真实反馈最后再开放全员。直接全员开放的后果往往是暴露问题后众口难调你反而不知道怎么改。4. 让专家从能用到好用指令打磨、记忆管理与迭代测试4.1 自定义指令的进阶改写技巧第一版指令跑通之后重点进入打磨阶段。几个非常有效的改写技巧把模糊要求改成可执行动作。输出要专业不如每个结论都必须给出依据或数据来源语气要友好不如回答开头先用一句话概括结论再展开细节。用示例代替规则。给模型一两个输入→输出的示例效果比写十条抽象规则都明显。示例就是最直接的模板模型会模仿它的结构和风格。所以指令里可以放一小段示例对话不用太长。少用否定句多用肯定句。AI对不要做什么的理解经常不如应该做什么可靠。与其写不要闲聊不如写用户问无关话题时回复……并按流程转交。这样一来模型有明确的替代动作可执行而不是停留在抽象层面。4.2 历史对话记录与本地记忆记得住好记太多未必好WorkBuddy的专家会积累历史对话记录和记忆这是它能越用越顺的原因之一。但记忆也是一把双刃剑。如果专家把临时任务信息当成长期背景后面反而会干扰判断。比如你上周让它临时记住某次周报的特殊格式这周它可能还按那个特殊格式输出。我的习惯是定期检查专家记忆。WorkBuddy一般可以在专家详情里查看历史对话记录我会每两周清理一次明显过期的临时信息只保留两类东西用户固定的偏好、项目长期背景。判断标准很简单这条信息三个月后还有用吗没用就清掉。4.3 本地记忆迁移换电脑、重装系统的正确姿势很多人搜索历史对话记录、本地记忆迁移多半是遇到了换电脑之后专家还在但记忆和聊天历史不见了的情况。我的经验是先在网页版登录同一个账号看看因为云端配置和部分记忆是跟着账号走的如果网页版有、客户端没有那问题大概率出在本地缓存上需要检查客户端的本地数据目录或重新同步。这里给一个实用建议每次调完指令、更新完知识库随手导出一次专家配置做备份。WorkBuddy不同端网页版、桌面客户端、Linux版的同步策略不完全一样养成备份习惯之后任何时候重装系统都不慌。别等数据丢了才想起来备份。4.4 迭代测试方法先正常路径再对抗测试建好专家后我一般做两轮测试。第一轮是正常路径测试用最典型的任务喂进去看输出符不符合指令里写的格式和要求。第二轮是边界对抗测试故意问范围外的问题、给空输入、给模糊输入看专家会不会失控。这两轮跑完专家的下限基本就清楚了。记录问题的时候每条问题都要能对应到指令的某一条规则。修改时坚持一次只改一处原则改完重新测试再进入下一轮。这个原则和改代码完全一样同时改五处出了问题你不知道是哪条规则引起的。我实测下来绝大多数专家经过三轮测试-修改-回归就能达到可用状态完全没有必要追求一次写完美。5. 实战拆解一个金融版资讯整理与合规检查专员的完整配置5.1 需求背景与场景价值这个案例来自我帮一个做行业信息处理的团队做的配置。他们的日常工作量很大每天要浏览大量行业资讯整理成内部简报还要核对摘要里有没有合规敏感点比如是否存在夸大收益、缺少风险提示这类问题。人工做费时且口径不一每个人整理出来的风格都不一样领导看着头疼。于是目标很明确用一个专家把信息收集—摘要提炼—合规提示的流程标准化。这里要特别说明一下我讲的金融版是指WorkBuddy针对金融行业工作场景的一类配置思路核心是资讯整理和内容检查不涉及任何投资建议。这个案例的思路其实可以平移到任何需要信息整理合规检查的行业里。5.2 自定义指令全文每条规则都有针对性我最终采用的指令大致如下# 角色 你是金融行业资讯整理与合规检查专员服务于内部信息组。 # 目标 把用户提供的行业资讯原文或链接整理成内部简报并对明显的合规敏感点给出提示。 # 工作流程 1. 读取原文提取时间、主体、事件、影响范围四个要素 2. 按行业分类市场动态、监管政策、公司信息、技术进展 3. 每条要点概括到80字以内 4. 识别原文中可能与收益承诺、风险披露、夸大表述相关的内容单独列入合规提示 5. 不确定的信息写入待核实不得编造。 # 输出要求 输出Markdown简报包括 - 行业动态列表每条含时间、主体、影响范围 - 合规提示 - 待核实清单 # 边界 本专家只做资讯整理与合规检查不提供投资建议用户询问买卖建议时统一回复这超出我的职责范围请联系相关业务负责人。注意里面的细节每个要素都对应一个输出字段模型就不会漏不提供投资建议直接写进了边界这是为了从源头防止专家跑偏成荐股助手。5.3 知识库与技能的具体配置知识库方面我给它配了两个文件一份行业术语库.txt把团队常用的简称、专有名词都收进去一份历史合规案例.md里面收录了过去出现过的合规敏感表述和对应处理方式。这两个都是纯文本/Markdown格式上传后向量化很快。技能方面只挂载了两个网页正文提取和长文本解析。其他能力一律没开。理由还是那句能力越少越不容易在输出里夹带不相关的东西。5.4 三轮迭代记录从像新闻摘要到能用第一轮测试结果输出太像新闻摘要堆砌缺少结构化的要素标注。修改方案在输出格式里强制要求每条动态必须标注时间、主体、影响范围三个字段。第二轮测试结果合规提示误报率偏高把正常的宣传语也当成了风险。修改方案在合规检查规则里收紧范围——只提示与收益承诺、风险披露、夸大表述相关的表述并且把两个误报案例作为示例写进指令让模型有参照。第三轮测试结果边界对话处理太生硬用户问投资建议时回复像在念警告。修改方案把边界回复改成了一段固定话术语气更自然同时不模糊职责边界。三轮下来这个专家基本达到了可以直接交给团队成员使用的状态。这个案例给到你的参考价值不在于照抄指令而在于看我是怎么通过测试发现问题和定向调整的。6. 高频问题排查记录启动慢、网络失败、跨端选型与插件6.1 启动非常慢先别急着重装按顺序排查WorkBuddy启动非常慢是很多人都会碰到的情况。我的排查顺序是这样第一次启动慢是正常的。工作台要初始化本地资源、加载配置等几分钟是常有的事不是故障。后续启动依然慢优先检查客户端缓存目录。用久了缓存会越来越大清理缓存后启动速度会明显回升。如果一直卡在加载界面检查网络是否稳定。工作台很多组件需要在线加载网络差会表现为假死。老的客户端版本偶尔会有资源占用异常优先升级到最新版再判断。按这个顺序走完90%的启动慢问题能解决。不要一上来就卸载重装折腾半天可能只是缓存问题。6.2 网络连接失败绝大多数是环境问题不是软件坏了报网络连接失败时第一步不是找客服而是先做个对照实验直接用浏览器打开WorkBuddy网页版看能不能正常访问。如果网页版能访问说明账号和服务器都正常问题基本在客户端所在的本机网络环境。接下来检查本机系统代理设置和防火墙规则有异常拦截先临时调整再把WorkBuddy客户端加入防火墙白名单。这两步做完还不行再考虑卸载重装——但重装前一定要先备份本地记忆和专家配置别把积累的状态弄丢了。6.3 网页版、客户端与Linux/Ubuntu环境的选型很多用Linux的同学在搜索workbuddy ubuntuworkbuddy linux说明Linux版确实有不少人用。我整理过三种使用端的选型思路列成表供参考使用端适用场景主要注意点网页版临时使用、换设备需要稳定网络长时间会话可能超时桌面客户端日常主力启动快、有本地缓存需要定期清理Linux/Ubuntu版开发运维人群按官方文档装齐系统依赖库缺库会导致启动失败Linux版装完启动不了或启动报错最常见的根因就是缺了系统依赖库。建议对照官方文档里的依赖清单用系统包管理器逐项装齐不要跳步。6.4 插件生态与辅助功能按需启用别什么都装WorkBuddy支持插件扩展可以给专家挂载更多外部能力。但插件和技能一样装多了会拖慢加载速度、增加误用风险。我对插件的态度是按需启用先跑通核心流程再加一个测试一个不用的插件及时停用。另外工作台里有些版本还有宠物之类的辅助组件主要提供任务打卡、进度提醒这类陪伴向功能。它对核心专家能力没有帮助属于锦上添花。个人使用喜欢就开着团队办公建议关掉减少干扰。还有朋友问过WorkBuddy开发者平台它主要面向更深度的自定义开发和能力接入普通用户如果只是想创建专家用标准工作台入口就够了暂时不用碰开发者后台。最后说点个人体会。我在WorkBuddy里反复创建过好几个专家最大的教训就是一开始追求完美结果迟迟不落地。现在我习惯先花10分钟搭一个80分的版本跑起来用真实任务去测再用三轮迭代把分数拉到90以上。指令里的每一句话都可能影响输出方向而最有价值的修改往往来自你真实业务里的反例。如果你想自己创建一个专家建议从手头最重复、最耗时的一个任务开始按这篇文章的流程走一遍。做完你就会明白工作台这个词不是白叫的——它给你的不是一堆功能按钮而是一个可以把你的工作方法沉淀下来、反复使用的地方。