最近在效率工具和 AI 工作流相关的几个社区里WorkBuddy 双模型限免的消息讨论度确实高。简单概括就是Hy4 preview 限免开放两周Hy3 直接免到 9 月底。很多人第一反应是“又是个营销噱头”但我把客户端完整装了一遍、两个模型都实际跑过之后发现这次值得关注的不是“免费”两个字而是它背后那套模型切换和工作流搭建的完整链路。这篇文章我会把这个活动讲透包括 WorkBuddy 到底是什么、和 CodeBuddy 的区别在哪里、从下载安装到本地部署和接入模型的完整操作、拿到限免模型后建议先做的几件事以及我实测中踩过的坑。无论你是正在搭个人工作台还是想把钉钉同步、消息推送这些重复劳动交给工具都建议花几分钟把这篇文章看完。1. 这次的限免信息先帮你把账算清楚1.1 Hy4 preview 和 Hy3 到底是什么定位这里的“双模型”不是同一代产品换了个名字。根据我这两周的实际使用体感Hy4 preview 和 Hy3 在任务特性和可用性上有非常明显的分工。Hy4 preview 更像是一个“探索型”模型。它在长上下文理解、指令跟随和复杂任务拆解上表现更积极尤其是当你在一条消息里同时丢给它多个子任务、需要它自己规划先后顺序的时候Hy4 preview 给出的步骤明显比 Hy3 灵活。我拿一批真实的工作流需求做了对比比如“把整周的聊天记录整理成待办并按优先级排序”Hy4 preview 会先识别出哪些是需要行动的、哪些只是信息同步然后自己设计一套分类规则而 Hy3 会更倾向于保守地逐条罗列把判断留给我做。所以需要模型“多动脑子”的场景Hy4 preview 的优势更明显。Hy3 则是一个“生产型”模型。它的输出风格更收敛行为更可预测不太会因为提示词里多写了一段背景就开始自由发挥。这一点对跑定时任务和重复性流程非常关键因为自动化场景最怕的就是模型“脑补”出不存在的需求。我自己的体验是同样一条“每天上午 9 点生成昨日工作总结”的指令Hy3 连续跑一周的输出结构都很稳定很少出现格式漂移。所以要给这两个模型定个位的话我的结论是Hy4 preview 是拿来“试”的Hy3 是拿来“用”的两者不是替代关系而是互补关系。这个认知会直接影响下面使用节奏的安排先记着。1.2 时间窗口怎么安排更划算两周和到9月底这两个时间窗其实已经暗示了模型的不同用途。两周的限免含义很明确官方希望你集中测试、快速反馈趁这个窗口把 Hy4 preview 的能力边界摸清楚。我建议把接下来一个月想试但一直没动手的个人项目、自动化流程和复杂提示词实验全部趁这个窗口丢进去跑一遍。之前见过不少朋友把限免窗口浪费在闲聊和简单问答上等窗口过了才想起来有正事没试回头看基本等于白拿这次机会。Hy3 到9月底就从容得多。这个时间足够把一套完整的工作台搭起来并且把它固化成一个每天都会打开使用的习惯。我个人现在的节奏是每周日晚上用 Hy3 批量整理下一周的待办模板日常工作里的文本整理、周报初稿、数据汇总这类重复性任务都挂在 Hy3 上跑。临时冒出来的新需求、拿不准的复杂问题才切到 Hy4 preview 去试。另外可以做个简单的安排表第一周用 Hy4 preview 测你最高频的5个场景记录下来哪些表现超出预期、哪些还需要人工兜底第二周根据测试结果把其中2到3个场景沉淀成固定的 skill 或自定义指令切回 Hy3 跑。这样两周结束后你得到的不是一次“用过就忘”的体验而是一套已经跑起来的工作流。1.3 “限免”两个字背后要注意什么限免不等于无限制。从我了解到的情况看这类模型限免一般都会配合一定的使用额度或者频率限制具体以客户端里的提示为准。所以在 Hy4 preview 限免期内我建议把它当成“测试资源”而不是“默认模型”。如果把所有请求都指向它很可能提前触发额度上限反而影响你验证新想法。还有一点容易被忽略限免结束后的切换。Hy3 免到9月底意味着9月底之后模型策略可能调整如果你把核心业务完全绑死在某个模型上到时候会比较被动。比较好的做法是从现在开始就把提示词写得尽量模型无关让同一套指令在 Hy4 preview 和 Hy3 上都能跑出可接受的结果。这样不管后面模型策略怎么变你的工作台都不会塌。2. WorkBuddy 是个什么工具为什么这次值得装2.1 智能体工作台的核心构成skill、连接器、自定义指令WorkBuddy 的定位不是“又一个聊天机器人”而是一个围绕个人工作台搭建的效率智能体。把它拆开看有三个核心概念skill、连接器和自定义指令有的版本里也叫 instructions。skill 是能力封装相当于给智能体装了一个“专项技能”。比如“把聊天记录整理成待办清单”“从网页或文档里抽取结构化数据”“生成符合特定格式的周报”这些都可以封装成 skill。用的时候不用每次都把规则说一遍直接调用 skill 名就行这一点在重复性任务里非常省事。我自己第一次用 skill 跑通一个从网页抽取表格并生成 Markdown 文档的流程时最大的感受是以前要写脚本做的事现在用自然语言定义一遍规则就能反复调用。连接器connector负责打通外部服务。经常有人问 WorkBuddy 的连接器到底是什么其实就是一组现成的集成能力钉钉多维表、企业微信、文档平台、消息推送服务、数据库等都能通过连接器接进来。一个典型的场景是每周一早上自动从钉钉多维表里拉取项目状态经过模型总结后推送到消息渠道。没有连接器的话这一步需要自己写脚本调接口而现在只要配置好授权和触发规则即可。自定义指令则是行为规则层。它决定了智能体在什么场景下用什么语气、按什么格式输出、遇到边界情况怎么处理。比如你可以规定“输出报告时先给结论再给数据”也可以规定“默认使用中文专业术语保留英文原词”。三个概念合在一起才构成 WorkBuddy 和普通对话助手的本质区别普通助手是一问一答WorkBuddy 是你自己搭的一个“数字员工”。2.2 和 CodeBuddy 到底有什么区别这个问题在社区里的热度一直很高我在不同群里也被问过很多次。CodeBuddy 的侧重点在代码场景核心是代码生成、补全、仓库级上下文理解和开发流程辅助应用场景基本集中在开发工具链里。WorkBuddy 的覆盖面要宽得多它更关注工作流本身定时任务、消息推送、多表同步、业务数据处理、跨平台连接器等等。举个实际分工的例子我有个项目需要每天拉取业务数据、清洗后生成图表描述再定时推送到工作群。代码部分我会在 CodeBuddy 里写数据处理和定时推送的流程编排则放在 WorkBuddy 里。两者配合使用的体验是CodeBuddy 负责“写”WorkBuddy 负责“跑”。如果你只做纯开发、不碰业务流转那 CodeBuddy 可能已经够用但一旦你的工作里涉及大量跨平台的信息同步、定时任务和重复文案处理WorkBuddy 的价值就会体现出来。它不是一个替代 CodeBuddy 的升级版而是一个不同维度的工具两者互补。2.3 企业落地的配套从业者认证与团队复用除了个人使用WorkBuddy 在企业方向上也有一些配套我注意到官方在这块已经有成体系的布局比如效率智能体的从业者认证。它的意义在于当你想把工作台方案从个人使用扩展到团队或者作为服务交付给客户时认证体系能提供一个相对标准的能力基线。不过我的建议是如果你是个人用户前期不用太在意认证这件事先把 skill、连接器、自定义指令这三个核心概念玩明白。等你的工作台方案真的稳定跑了一阵子再考虑要不要往团队复用和认证方向走。工具的价值在于先把流程跑通剩下的都是加分项。3. 从零把 WorkBuddy 跑起来含 Linux / 麒麟版注意事项3.1 下载安装与基础配置安装这块不复杂但有几个细节值得注意。常规做法是去官方渠道下载对应系统的安装包Windows 和 macOS 的直接装即可。这里要单独说的是 Linux 环境尤其是国产麒麟系统的适配这两个版本社区里问的人不少。如果你用的是 x86 架构的 Linux 发行版直接下官方 Linux 包一般没问题但运行时依赖需要自己确认一下。常见的缺库问题大多集中在图形界面组件上报错的话补装对应依赖就行。麒麟版主要是兼容性适配建议优先选择官方针对该平台发布的安装包不要用通用包硬装否则可能出现界面显示异常或者部分功能不可用的情况。首次启动后先别急着用把三件事做掉登录或注册账号、检查客户端版本是否为最新、确认一个专门的工作目录。工作目录这个概念很容易被新用户忽略默认配置里会有一个以点号开头的隐藏目录很多人找不到自己的配置和技能文件其实就是被“目录前面有个点”这种命名方式带偏了。建议从第一天就把工作目录建到显眼位置后面排查问题会省很多力气。3.2 在客户端里启用限免模型登录之后在模型选择区域应该能看到当前可用的模型列表。限免期间Hy4 preview 和 Hy3 都会有明确标识直接选中即可。这里要提醒的是模型列表的显示依赖客户端版本如果你看不到对应的限免模型优先检查是不是版本过旧升级到最新版再刷新。限免是否生效最直接的判断方式是用一条带明确结构要求的指令测试比如让它生成一份特定格式的周报然后观察输出质量和响应速度。另外我建议在启用模型前先看清客户端里关于额度的提示文字把限免模型当生产模型全量跑很可能提前触发限额。我在实际测试中遇到过一个问题切换模型后之前的会话上下文不会自动带过去。如果你想让 Hy4 preview 基于之前 Hy3 的对话继续工作需要手动确认上下文继承的方式。不同版本的交互入口不太一样但逻辑是一样的先确认上下文再继续对话。这个细节官方文档里写得不明显属于实操中很容易忽略的点。3.3 本地模型与第三方模型的接入思路除了官方模型WorkBuddy 也支持接入 OpenAI 兼容接口这对喜欢自己折腾模型的人来说很实用。基本思路是在设置里找到模型服务配置填入 base URL 和 API Key然后新建一个自定义模型条目。这样可以把 WorkBuddy 的 skill 和连接器能力与你自己选的模型结合起来用。关于本地模型很多人问千问这类开源模型本地部署后能不能接入 WorkBuddy答案是可以的官方也留了兼容接口。效果方面如果本地跑的是 8B 级别的量化模型日常文本整理、摘要生成、定时任务脚本这些场景表现够用但复杂推理和长文档理解跟官方大模型还有明显差距。所以我的建议是本地模型适合处理隐私敏感或离线场景的简单任务涉及到复杂理解和高质量生成还是优先用官方限免模型。接入步骤上先确认本地模型的推理服务已经启动并暴露了兼容接口然后在 WorkBuddy 自定义模型里填地址、密钥和模型名称即可。这里最容易踩的坑是 base URL 末尾的路径写不对不同推理框架要求的路径不一样一般以框架提供的文档为准填错了会一直报连接失败。4. 拿到限免模型后我建议你先试这几件事4.1 定时发送微信消息把工作流搬到手机外很多人设置好模型后的第一件事是问“能怎么玩”我的建议是先做定时消息推送因为这是最快能感受到“工作台”价值的功能。用连接器或定时任务配置能让 WorkBuddy 在每天早上固定时间把日报、待办、提醒消息推送到微信或类似的消息渠道。具体操作上先建一个定时任务指定要执行的动作比如“总结昨天的进展并生成今日待办”再绑定消息推送渠道。我第一次跑通这个功能的时候最大的感受不是“智能”而是“省心”——每天早上不用自己回忆昨天干了什么消息自己就来了。不过有一点要提醒定时任务依赖客户端或服务端的持续运行如果你用的是本地客户端记得保持它在后台运行否则定时任务不会触发。这个功能特别适合两类人一类是每天要写日报的同学一类是经常漏掉待办事项的朋友。把一个固定提示变成自动推送之后整个工作节奏会明显不一样。我自己现在每天早上的第一条待办消息就是它推过来的已经变成习惯了。4.2 钉钉多维表定期同步这类重复劳动交给skill钉钉多维表定期同步这个需求我在社区里看到过不少人在问说明它是一个真实且高频的场景。我自己的测试场景是项目进度表放在多维表里每周有成员更新我需要每周一把变动同步到另一个汇总表里再做简单分析。手动做的话每次大概10分钟频率一高就会觉得很烦。用 WorkBuddy 之后这套流程被拆成了两步第一步通过连接器授权多维表的读写权限第二步建一个 skill 描述同步规则包括源表字段、目标字段、去重逻辑、冲突处理方式。之后每次只要触发这个 skill模型会按规则完成字段映射、内容比对和增量同步。我实测下来简单场景的同步准确率是很高的但如果表结构经常变skill 里的映射规则可能需要跟着维护这是没法完全避免的。这个场景其实是 WorkBuddy 最有代表性的用法它不是帮你“写代码实现同步”而是让你用自然语言定义一条业务规则然后由智能体去执行。对于不会写脚本的同事来说门槛低很多这也是它能进入业务流程领域的核心原因。4.3 UI自动化和业务流程的简单落地再往深一点走WorkBuddy 还能做 UI 自动化和业务流程编排。不少人在社区里问过怎么用 WorkBuddy 做 UI 自动化我理解主要指的是用它的自动化能力代替人去做重复的界面操作比如批量填写表单、点击按钮、数据抓取。我的建议是从小处入手先选一个每天重复的界面操作把过程录下来或写成指令让它稳定跑一周再说。不要一上来就搭一个横跨十几个步骤的大流程因为中间任何一步出问题排查成本都会很夸张。业务流程也是类似的逻辑我见过有人用 WorkBuddy 搭了一套从数据收集、清洗、汇总到生成报告的完整流程非常漂亮但那是建立在前期把每个小环节都验证过的基础上的。从行业角度看WorkBuddy 在建筑、基金这类垂直场景里也有实际案例。建筑行业可以用它做材料清单整理和进度信息汇总基金相关场景可以做净值数据和公告的结构化整理。这些本质上都是“数据获取 结构化输出 定期执行”的组合恰好是 WorkBuddy 擅长的区域。如果你所在的行业也有这种固定流程完全可以参照这个思路来搭。5. 我实际测试后的一些提醒和参数建议5.1 限免到期判断与切换策略限免到期这件事客户端一般会有提示但提示不一定显眼。我建议不要等系统提示自己在日历上设个提醒Hy4 preview 两周窗口到期前三天做一次集中测试的收尾9月底前一周再检查一次 Hy3 相关的定时任务是否正常。等到活动结束才想起来很有可能被打个措手不及。切换策略上我坚持一个原则工作流不绑死单一模型。具体做法是在 skill 和定时任务的配置里尽量用模型无关的描述比如“把这段文字按优先级整理成清单”而不是依赖某个模型的特殊格式指令。这样即使限免结束后模型策略调整最多只影响输出风格不会让整个工作台瘫痪。5.2 skill/连接器使用中的常见坑第一个坑是权限范围。连接器授权时默认拿到的权限可能比你预想的大也可能比预想的小。大权限意味着安全性风险小权限则可能导致同步任务执行到一半报错。我建议每个连接器在配置完成后先用一条最小指令测试读写边界确认它只能访问该访问的内容再放开正式任务。第二个坑是版本匹配。客户端升级后个别第三方 skill 或插件可能因为接口变化而失效现象是调用时报错或者静默失败。遇到这种情况别急着怀疑模型的错先看 skill 或插件的版本是否兼容当前客户端版本大部分问题都是这里出来的。第三个坑是上下文污染。同一个工作区里如果配置了多个自定义指令指令之间可能互相影响。比如一条指令规定“回答尽量简短”另一条规定“输出必须包含完整说明”同时生效时模型行为会变得不可控。我的建议是全局指令只放通用规则场景化规则放到 skill 内部缩小生效范围。5.3 自定义指令的几条推荐写法最后分享几条我自用的自定义指令写法都属于“直接抄就能用”的级别。第一条是角色前置比如“你是一名项目经理助理负责把零散信息整理成结构化任务清单”角色确定后模型后续输出会稳定很多。第二条是格式约束比如“所有输出必须以 Markdown 列表呈现每项不超过一行”这类约束能有效防止模型自由发挥。第三条是兜底指令比如“如果信息不足请明确列出缺失项不要猜测”这条对自动化任务尤其重要能显著减少“一本正经编数据”的情况。参数方面如果客户端暴露了温度、最大输出长度等选项我的经验值是事实整理类任务温度调低到 0.3 左右创意生成类任务可以调到 0.7 到 0.8。最大输出长度要看具体场景周报建议给足 2000 字消息推送类指令给 500 字以内就够了避免模型为了凑字数输出一堆废话。这些参数不一定要照搬但可以作为你调试时的起点。