1. 先从被问烂的问题说起WorkBuddy 是 CodeBuddy 的办公版吗1.1 产品定位一个带技能包的 AI 工作台我本来对AI 办公助手这类东西有点免疫。市面上打着这个旗号的产品太多了装完、点开、玩两分钟最后基本都躺在 Dock 栏里吃灰。但这次不太一样因为内测群里一个做算法的老哥发了句话你试试把一本技术书丢进 WorkBuddy 的 Book to Skill它能把整本书变成可以和你对话的专家。冲着这句话我花了三周时间认真实测了腾讯出的这款 WorkBuddy结论是它确实不是又一个套壳聊天框。先回答那个被问烂的问题WorkBuddy 和 CodeBuddy 到底什么关系我在腾讯做后端日常接触 CodeBuddy 比较多那是 IDE 里辅助写代码的插件定位是程序员的结对编程搭档。WorkBuddy 则是一个独立产品面向更泛的办公场景从网页端和 Linux 客户端都能进里面可以切换不同的大模型可以上传文档、管理知识库、执行自动化任务核心的差异化设计是它的 Skill 技能包体系。我的理解是WorkBuddy 本质上是一个AI 工作台。普通聊天工具是一问一答它则把一堆能力——模型对话、技能包、指令模板、工作流——都收拢到一个页面里让你在同一个界面里完成收集信息、处理文档、产出成果这条完整链路。如果只把它当一个聊天机器人用其实浪费了大半功能但反过来说就算你只把它当聊天工具它的大模型底座也够用日常问答、写邮件、翻译文档都顺手。1.2 三种核心模式的产品逻辑多数人拿到 WorkBuddy 会先懵一下入口怎么这么多我实测下来其实它把使用场景拆成了三种核心模式分别对应三种不同的人机协作方式。模式本质适合场景上手难度对话模式直接与大模型连续对话可上传文档、网页链接问答、润色、总结、翻译几乎为零Skill 技能包模式加载一个特定领域的技能包AI 按该领域的固定套路工作数学建模、专利辅助、编程、书籍问答低关键在于选对 SkillAgent 模式给定目标后AI 自动规划步骤、调用工具、汇总结果竞品调研、数据分析、周报生成等复杂任务中建议先会前两种这三者不是竞争关系而是递进关系。对话模式是你问它答Skill 模式是你让它用行家的套路做Agent 模式是你把活派给它它自己拆解并交结果。我的建议是先从对话模式用起熟练后再碰 Skill最后再上 Agent一步一个台阶体验会稳很多。在正式开始之前先交代一下我的测试环境我主要用的是 Web 网页版同时测了 Ubuntu 下的 Linux 客户端模型以默认大模型为主偶尔手动切换到其他模型做对比。下面所有结论都基于这个环境不同版本可能有细微差异但大方向是一致的。2. 三周实测三种模式在真实办公场景里的表现2.1 对话模式处理不想动脑但必须产出的活对话模式最容易被低估因为看起来太普通了。但它恰恰是我三周里使用频率最高的模式。每天有两类事情我直接丢给它一类是长文档总结一类是格式性产出。第一类长文档总结。有一次评审会前我手头有一份 20 多页的 PRD自己 skim 一遍至少要半小时我直接把 PDF 传上去用对话模式让它提炼出五个核心决策点和三个风险项。它返回的结果是有结构、有引用的关键段落甚至带了原文页码这比我自己画重点效率高很多。后来我养成一个习惯任何长文档进我手先丢给 WorkBuddy 过一遍再决定哪里值得细读。第二类格式性产出。比如给跨团队的同学发一封沟通邮件、把一个杂乱的会议记录整理成结构化纪要、把技术方案改写成周报语言。这些工作的共性是内容我已经有了只是不想自己花十分钟排格式。对话模式在生成这类内容时只要你在指令里写清楚受众、语气、长度返回质量基本一次到位。我实测过一个场景让它把一段口语化的故障复盘改成面向老板的一页纸它主动压缩了技术细节强化了影响面和恢复时间这个分寸感比我预期得好。不过对话模式也有明显的短板它只对单轮输入敏感不太擅长跨多个文档做关联推理。你把两份 PRD 一起丢进去它偶尔会把两份文档的信息混在一起。所以我的经验是关联性强的资料尽量合成一份后再上传或者在一个会话中分段喂给它不要同时在上下文里塞太多来源。2.2 Skill 技能包模式让 AI 按行家套路工作对话模式解决的是通用问题Skill 模式解决的是专业问题。我最初对 Skill 是持怀疑态度的觉得不就是套了一层提示词吗实测之后我承认这个想法太天真了。套提示词和套一整条方法论结果差距很大。举一个印象最深的例子。我有个同事在准备数学建模竞赛我帮他用数学建模 Skill跑了一个供应链优化的小问题。这个 Skill 不会直接甩给你一段答案而是会按固定的流程走先问清楚问题背景和变量再引导你定义目标函数和约束条件然后建议可选的建模方法最后连灵敏度分析都设计了。整个过程像是一个有经验的建模导师在带你过一遍标准方法论而不是一个急于给答案的搜索引擎。这种过程感是普通对话模式很难做到的。另一个让我觉得值回票价的场景是专利辅助。腾讯内部对专利交底书有固定格式我平时写一份要憋一整天。用专利辅助 Skill后它会先引导我描述创新点然后自动套用技术领域、背景技术、发明内容、有益效果这样的结构来生成初稿。它甚至会反过来问我这个方案和现有技术的区别点是什么——这一步是普通问答很难主动做到的。当然最后的专业判断还是得自己把关但初稿的效率提升是实打实的。信息密度最高的要数 Book to Skill 这种转化型技能。它允许你把一本书的电子版转成一个可对话的知识库之后你问它任何书里相关内容它都会基于这本书来回答。我拿一本系统设计类书籍试了一下提了几个具体问题它都能给出书里的原理解释还会提示这个问题在书中第几章有更详细讨论。这相当于把一本厚书变成了一个随叫随到的专家。2.3 Agent 模式最省心也最容易翻车Agent 模式是我最后才敢放开的因为它自主性最强意味着失控风险也最大。我选了一个相对安全的任务来试水让它做一个项目竞品调研。我给它的指令是调研三款同类产品的功能定位、定价策略和用户评价输出一份 800 字左右的对比报告。它在执行时自己拆了步骤先列出候选产品再逐个搜索公开信息然后对功能点做对比最后汇总成报告。整个流程不需要我干预运行了大约五分钟输出质量可以用初稿可用来形容——框架完整、对比维度合理、结论点也很准确但个别具体数据明显需要复核比如某个产品的定价区间写得不够精确有些用户评价可能带着情绪倾向。这个案例暴露了 Agent 模式的核心问题它在结构化产出上很强但在事实准确性上不可全信。原因不难理解Agent 为了完成目标会去搜索引擎和其他信息源抓取内容而它无法像人一样判断某个论坛帖子的可信度。所以我的建议是用 Agent 做初筛型任务比如收集资料、搭框架、做汇总不要在没有任何复核机制的情况下让它直接产出对外发布的最终内容。另外Agent 模式还有一个容易被忽视的问题它执行任务的步数和调用次数直接影响积分消耗。一次调研任务可能调用几十次模型接口积分烧得比想象中快。我后面会在第五节详细讲积分成本这里先提个醒不要把 Agent 当无限免费劳动力。3. Skill 技能包拆解价值、来源、以及生态现状3.1 Skill 和 Agent 的本质区别先说清楚一个很容易混淆的概念Skill 和 Agent 到底哪里不一样。很多人刚接触 WorkBuddy 时会问Skill 是不是就是 Agent 的简化版其实完全不是一回事它们是两个维度的东西。Skill 是一套知识和方法论的封装。它告诉你在某个特定领域应该按什么步骤思考、用什么格式输出、需要关注哪些关键点。它本身不主动干活而是等着你或别的模块来调用它。你可以把它理解成一本菜谱上面写着每道菜的食材、步骤和火候但菜谱自己不会下厨。Agent 则是一个执行者。它有自主性会自己规划任务、调用工具、判断中间结果最后把成果交给你。虽然 Agent 在干活的时候经常会调用 Skill 来辅助自己但 Skill 不等于 AgentAgent 也不一定非要 Skill 才能干活。用厨师来类比Agent 是那个站在灶台前掌勺的人Skill 是他手里的那一本本菜谱。清楚了这一点很多使用问题就迎刃而解。比如你没必要纠结这个任务该用 Skill 还是 Agent正确思路是确定了任务目标后看有没有对应的 Skill有就让它约束 Agent 的专业性没有就让 Agent 用通用能力完成。它们不是二选一的关系而是组合关系。3.2 实测中最值得装的四个 SkillSkill 数量不少但质量参差不齐。下面这几个是我三周里实际用得比较多、推荐指数也比较高的不需要全装按自己的领域挑就好。Skill 名称定位五星场景我的体验评分仓颉 Skill辅助用仓颉语言写代码程序逻辑设计、代码解释、API 用法问答4.5/5数学建模 Skill引导式完成数学建模全流程竞赛、课程设计、科研问题建模4.5/5专利辅助 Skill辅助产出专利交底书初稿企业专利申请、创新点挖掘4/5Book to Skill把电子书转成可对话知识库技术书籍阅读、专业资料沉淀5/5仓颉 Skill 对我这种后端程序员的价值在于仓颉是一门比较新的语言很多 API 和最佳实践我还不够熟这个 Skill 能提供更贴合语言特性和规范的回答比通用对话查到的要准确。数学建模 Skill 对非专业建模者特别友好它会把问题分析-假设设定-模型建立-求解验证-灵敏度分析这个完整链条跑一遍等于带你把建模方法论实践了一次。专利辅助 Skill 刚刚说过是标准文档产出利器。Book to Skill 则是我个人最喜欢的它把阅读场景从啃书变成了对话信息检索效率提高了数倍。需要提醒的是Skill 生态目前还在快速迭代中有些第三方 Skill 存在两个问题提示词质量不稳定、对模型版本有隐性依赖。我从实践中学到的筛选标准是优先用官方或知名开发者发布的 Skill看一下它的更新时间和用户评价避免装那种只有简介没有实际说明的幽灵 Skill。3.3 手写一个 Skill 的思路以周报为例装别人的 Skill 只是第一步真正理解 Skill最好亲自动手写一个。WorkBuddy 支持用户自定义 Skill入门门槛并不高。我以自己在用的周报生成 Skill为例拆一下思路。最基本的一个 Skill 其实由三部分组成第一部分是角色和目标告诉 AI 它要扮演什么角色、完成什么目标第二部分是执行流程规定了 AI 先做什么再做什么比如先提取本周工作项、再按项目分类、最后按负责人归纳成果第三部分是输出格式比如固定的一页纸周报模板包含本周进展、风险、下周计划三个板块。我写的这个周报 Skill 就遵循了这个结构。使用时我只需要把每天的飞书文档链接和碎片记录丢进去它就会先汇总所有输入识别出哪些是进展、哪些是风险、哪些是待办再按模板生成周报。相比我以前在对话模式里每次手打一段帮我写周报的指令Skill 把整个过程固定成了一个可复用的按钮。这个差异在使用频率越高时越明显——从每次都要写需求变成了一键执行。所以我对 Skill 的最终看法是它本质上是把高手的工作方法论沉淀成了可复用的数字资产。你现在愿意花半小时写一个 Skill未来每天都能省下这半小时。这个投资回报率至少对我这种重度办公文档玩家来说是非常划算的。4. 五分钟上手实操从注册到产出一份可交付结果4.1 环境选择网页版还是 Linux 客户端很多人卡在上手的第一步不是不会用而是不知道该用哪个端。我实测了两个环境Web 网页版和 Linux 客户端先说结论日常办公优先选网页版追求桌面级体验和文件管理再考虑装客户端。网页版的优势是零安装、跨设备同步。我在公司台式机上打开一个页面回家用笔记本登录同一个账号会话记录和 Skill 配置都是同步的这个体验对项目组内多人协作尤其友好。Linux 客户端则是给那些重度依赖桌面环境的用户准备的比如我需要同时开多个工作窗口把 WorkBuddy 客户端固定在独立窗口里比开一堆浏览器标签页要清爽。Ubuntu 下安装客户端的过程不复杂下载对应包安装即可但由于是桌面应用启动速度和内存占用都高于网页版。我个人的建议是如果你是一个月偶尔用几次的轻度用户网页版完全够了没必要多装一个桌面应用如果你和我一样每天要处理大量文档和任务可以考虑客户端配合系统级的快捷键切换窗口会顺手很多。4.2 模型、积分与自定义指令的初始配置注册登录后第一件事建议先别急着聊先把三个配置项过一遍模型选择、积分意识、自定义指令。模型选择是最直观的WorkBuddy 里可以切换不同的大模型。实测下来不同模型在不同任务上的表现确实有差异比如有的模型擅长逻辑推理有的更擅长文本润色。我的经验是日常问答和写作用一个均衡型模型跑 Agent 任务时切换到推理能力更强的模型虽然后者单价更高但出错率低综合算下来反而省积分。积分这件事需要格外关注因为它直接决定了你的使用成本。新用户注册后一般会有一定量的免费积分但每次调用模型都会消耗且消耗量不是线性的上传长文档、Agent 多轮调用、在长上下文里反复追问这几种情况的积分消耗会成倍增加。这里有一个经验法则能在对话模式里一次做完的事就不要主动升级到 Agent 模式能在短上下文里解决的问题就不要把一整本书丢进去。自定义指令值得认真配置。它相当于你的全局人格设定会影响所有模式下的输出风格。比如我在自定义指令里写了回复要分点列出结论、附上必要的数据支撑、不要使用人称化写作之后所有模式生成的文本都默认遵守这个风格。建议每个用户都花十分钟写一版自己的自定义指令这是投入产出比最高的一项配置。4.3 第一个任务的完整跑法理论铺垫够了现在给一份可以直接照做的 5 分钟上手流程。我用把一份会议记录整理成执行计划为例这是每个人都会遇到的场景。第一步打开 WorkBuddy 网页端登录账号确认当前模型和积分余额。第二步把会议记录文件拖拽上传到对话区。第三步在输入框里用自然语言下达指令请把这份会议记录整理成执行计划包含负责人、截止时间、风险点输出成表格形式。这是对话模式的基础用法整个过程不超过一分钟。第四步如果想体验 Skill可以从技能商店找到一个项目管理类或会议纪要类的 Skill加载后再重复上述任务你会发现输出结构从通用表格变成了项目执行看板还自动识别了责任人是否明确、有无待确认事项。第五步保存这次产出可以导出为文档或报告直接作为交付物发出。整套流程走完熟练后基本控制在五分钟以内。这个五分钟不是说五分钟学会所有功能而是从零到产出一份合格工作成果只需要五分钟。我拉过部门两个没用过 WorkBuddy 的同事做测试他们没有看任何教程仅靠界面引导和我的口头提示都在五分钟内完成了上述任务。这说明产品的学习曲线控制得确实不错。5. 这些坑不提前知道你会以为是自己不会用5.1 积分背后的隐藏成本我用第一周时最大的感受是怎么积分掉得这么快。明明觉得自己没干多少事一看消耗记录几百积分没了。复盘后发现问题出在三个地方。第一是长文档反复问答。把一份 50 页的 PDF 喂进去后你每追问一个问题AI 都会重建一次长上下文每次的消耗都比短问答高几倍。正确做法是先让它做一次全文档摘要把摘要保存下来之后的追问基于摘要进行而不是反复回到原文档。第二是Agent 模式的隐性多轮消耗。Agent 看起来只给了你一个指令但内部可能执行了十几个步骤每一步都是一次模型调用。我在实测竞品调研时一个任务就消耗了大约等于二十次普通对话的积分。第三是开着多个会话不关。每个会话的上下文都会保留后台资源也在持续占用虽然不是每个会话都在计费但频繁切换会显著加速积分消耗。我的建议是养成两个习惯一是任务结束后主动关闭不用的会话二是把长文档类任务集中在一个时段批量处理避免反复上传同一个文件。这些都是实测中实打实省下积分的操作不是理论推导。5.2 自定义指令和 Skill 的边界第二个高发困惑是我已经配了自定义指令为什么 Skill 的表现还是和我想的不一样。这其实是把两个机制搞混了。自定义指令是全局风格约束它影响的是 AI 说话的方式和输出的呈现形态比如用词风格、段落结构、是否带数据。Skill 则是领域方法约束它影响的是 AI 做事的专业流程比如数学建模 Skill 会强制按建模方法论走。两者分工不同也会有冲突的时候如果某个 Skill 内部写死了输出格式而你的自定义指令要求另一种格式AI 通常会更听话地遵循 Skill 里的显式要求。所以我不建议把具体要求都塞进自定义指令那样反而会在某些 Skill 场景里失效。正确做法是自定义指令只写通用的风格偏好具体任务的流程要求交给对应 Skill单次对话的特殊需求直接在对话里补充说明。这个认知理顺之后我对 WorkBuddy 的控制感强了很多。5.3 与 CodeBuddy 的分工以及我的最终判断最后一个想聊的坑是怎么处理 WorkBuddy 和我更熟悉的 CodeBuddy 之间的关系。很多同事问我是不是用了 WorkBuddy 就可以不用 CodeBuddy 了我的答案是分工不同两者不冲突。CodeBuddy 嵌入在 IDE 里和编辑器的交互深度是 WorkBuddy 不具备的。写代码、查报错、做重构CodeBuddy 天然更顺手因为它能看到你的工程上下文。WorkBuddy 的强项在 IDE 之外写文档、做调研、处理长文本、管理方法论类任务。我现在的分工是代码相关的问题全部留在 IDE 里问 CodeBuddy办公文档、技术方案的前期调研、专利材料整理等任务交给 WorkBuddy两边各管一段互补性很强。这让我对 AI 办公工具的整体判断也发生了一些变化。以前我觉得这类工具的核心价值在于模型的聪明程度实测 WorkBuddy 之后我开始认为真正决定效率上限的是模型之上那层方法论沉淀——也就是 Skill 体系。底层模型再聪明如果只是对话每个用户还是从零开始摸索而 Skill 把行家经验固化成可复用资产之后普通用户也能直接站在一个成熟方法论的肩膀上干活。这一点是我三周以来最深的体会。最后分享一个实操心法别追求把每个功能都用一遍。挑你最痛的一个办公场景比如周报、会议纪要或长文档总结先把它用 WorkBuddy 跑顺再逐步扩展。一个场景用熟之后你对这个工具的理解会比看十篇教程都深。