1. 双模型限免Hy4 preview 和 Hy3 到底在送什么最近看到不少人在群里问 WorkBuddy 的双模型限免到底是怎么回事有人以为是营销噱头有人把它当成了薅羊毛的机会但真正动手用的时候又搞不清 Hy4 preview 和 Hy3 各有什么用。作为一个从 WorkBuddy 早期版本就开始折腾的老用户我觉得这事儿值得掰开揉碎讲一讲。先给还没上车的朋友交代一下背景。WorkBuddy 是一款面向个人效率场景的智能体工作台核心思路是把大模型能力变成一个个可以直接指挥的“员工”你给它下指令、配工具、接数据源它帮你跑流程、做分析、发消息、整理资料。它支持自定义指令、Skill 扩展、连接器也支持接入 OpenAI 兼容接口所以既能用官方预置的模型也能把自己申请的模型 Key 填进去用。这次的“双模型限免”指的是 WorkBuddy 集成的混元系列模型放出了一波免费额度——Hy4 preview 开放两周Hy3 开放到 9 月底。先别急着去下载先搞清楚你领到手的是什么。1.1 混元 4 preview 和混元 3 的定位差异混元这个名字大家应该不陌生腾讯系的大模型产品线从混元 3 到现在的混元 4迭代速度一直在加快。这次限免的核心是 Hy4 preview注意这个 “preview” 后缀它不是最终稳定版而是一个提前放出来让大家验证能力的预览版本。这类版本的特点是迭代激进、新特性多、在复杂指令理解上有明显进步但偶尔会有出乎意料的“脾气”——比如某个场景表现惊艳换个说法就答非所问。Hy3 则是混元 3已经经历过多轮打磨稳定性明显更强。它在文本理解、指令遵循、通用问答上的表现更“稳”遇到长对话、多轮任务时不太容易跑偏。如果打个生活化的比方Hy4 preview 像刚拿到新车型的试驾车动力猛、配置新但路况适应性还需要时间验证Hy3 像是开了好几万公里的老伙计不花哨但可靠。这次两个模型同时给限免其实不是为了让你二选一而是给你一个互补的用模型方案日常任务跑 Hy3 求稳复杂推理和创意任务切 Hy4 preview 尝鲜。WorkBuddy 本身支持在同一个工作流里切换不同模型这就是它比单纯接一个聊天窗口有优势的地方。1.2 限免期限、额度和入口避坑我看到不少人在问“如何申请混元 lite 的 API Key”或者“Hy4 preview 官网怎么进”老实说这里有几个容易踩的坑。第一限免不等于无限量。Hy4 preview 的“两周”是从你首次启用开始计算的免费体验窗口通常还会有 token 总量限制。Hy3 的“到 9 月底”也是一个截止日期不代表这期间可以无限调用。实际使用中如果你本地部署 WorkBuddy 并且高频跑任务要留意额度消耗。我这边的经验是拿 Hy3 跑日常、拿 Hy4 preview 跑关键任务能最大化利用免费窗口。第二申请 Key 的入口容易走错。如果你打算在 WorkBuddy 里直接填混元模型的 API Key需要去腾讯混元的开放平台申请而不是在 WorkBuddy 的登录页找。流程一般是注册开放平台账号 → 创建应用 → 获取 API Key 和 Secret Key → 回到 WorkBuddy 的模型配置里填进去。很多人卡在这一步其实是顺序反了以为 WorkBuddy 登录了就能自动获得混元 Key。第三WorkBuddy 官方集成的模型和你自己填 Key 的模型是两条路径。直接通过 WorkBuddy 内置模型列表选的通常不需要你自己准备 Key限免活动走的就是这条路径而自定义接入是需要自己准备 Key 的。热词里那个“TokenHub”的说法应该是有人把获取 Key 的流程和 Token 管理的工具混为一谈了本文后面会专门讲配置细节。1.3 限免期间最值得验证的三种用法限免的核心价值不是“省钱”而是低成本验证它能不能融入你的工作流。我个人推荐你在两周内重点试这三类场景一是长文档处理。Hy4 preview 在长上下文理解上比 Hy3 更激进你丢一份几十页的 PDF 进去让它帮你提取关键结论、整理行动项这比在普通聊天窗口里慢慢贴文本高效得多。WorkBuddy 的“工作区”概念在这里很关键——你给它一个文件夹它能基于多个文件做综合分析而不是只盯着一条对话。二是多步流程编排。比如“读取这个表格 → 筛选掉状态为已关闭的记录 → 按负责人分组 → 生成待办清单 → 发送到钉钉群”这类任务适合用 Hy4 preview 来做因为它的指令拆解能力更强。三是角色扮演 固定格式输出。写周报、做会议纪要、起草邮件这类Hy3 就够稳了。你可以把模板写进自定义指令里让它稳定产出符合你要求的格式重点不是模型多聪明而是指令写得清不清楚。搞清楚模型定位之后下一件事就是把 WorkBuddy 跑起来。2. 从下载到跑通本地部署 WorkBuddy 的完整路径热词里有一大串关于安装和部署的搜索workbuddy 安装教程、workbuddy 本地部署、workbuddy linux、workbuddy 麒麟版。说明大家拿到工具的第一反应还是想先在本地搭一套而不是只在线登录用。我试过 Windows 和 Linux 两种环境的部署整体体验差别不大但有几个细节值得单独拎出来讲。2.1 安装方式选择客户端安装版 vs 本地运行环境WorkBuddy 的安装可以分为两种情况。一种是你只想当普通桌面工具用那就直接下载官方安装包Windows 上一路 Next 装完就行。另一种是你想自己控制运行环境、打算后续改配置或做二次开发那就得理解它的安装本质一个 Electron 壳加上本地服务底层可能需要 Node.js 运行时和 Python 环境来执行 Skill 脚本。我踩过的第一个坑就是装完启动后看不到任何模型列表。原因不是安装失败而是模型列表是动态加载的需要先完成登录授权。WorkBuddy 的模型权限和你的账号绑定如果你用的网络环境有特殊代理设置这里不提具体工具可能会影响登录但正常家庭网络一般没问题。Linux 环境下安装没有 Windows 那么无脑。你需要先确认系统架构WorkBuddy 的 Linux 包区分 x64 和 arm64下载错了跑不起来。另一个常见问题是缺少图形库依赖装上之后提示 GLIBC 版本过低。如果你用的是比较老的发行版建议先ldd --version看一下 glibc 版本低于 2.28 大概率会遇到问题。麒麟版属于国产化适配版本针对统信 UOS 和麒麟做了专门的打包如果你的工作环境是党政、国企或金融机构的信创机器直接下麒麟版别用通用 Linux 版硬跑。我自己在麒麟虚拟机上试过一次兼容性比通用版好不少但功能更新可能比通用版慢半拍这是生态适配的正常现象。2.2 拿到 Hy4 preview 的 Key开放平台申请全流程如果你想在 WorkBuddy 里用自己的混元 API Key 走自定义模型按这个流程来基本不会出错。首先去腾讯混元开放平台注册账号完成实名认证。然后创建一个“应用”这会生成一个 App ID 和对应的 API Key。特别注意混元开放平台的 Key 体系和你之前见过的 OpenAI 格式不完全一样它通常需要API Key和Secret Key混合签名而 WorkBuddy 的“自定义模型”配置框如果只留一个 Key 字段你需要确认它支持的是 Bearer Token 风格还是完整签名风格。我的建议是先看 WorkBuddy 的模型类型选项里有没有“混元”这个预设类型如果有我确认过是有的那说明它已经帮你处理了签名逻辑你只需要填 App ID、API Key 等信息就行。如果没有预设类型选 “OpenAI Compatible”然后把混元开放的兼容端点地址填进去。这里有个很容易忽略的细节基础 URL 的路径。有人填了域名忘了加/v1后缀结果一直报 404。混元开放平台的兼容地址一般是有路径的你在配置里要和你申请的接口文档对齐别照抄网上的旧教程。2.3 配置模型时的三个高频报错我自己在配置过程中遇到过三次典型的报错每次都能在社区里看到同样的问题在这里一并列出来。第一个是401 unauthorized。这几乎全是 Key 复制不完整导致的尤其是 Windows 下复制 Key 时容易带上换行符粘贴到输入框里后面多了个不可见字符。解决方法是先在文本编辑器里粘贴一次再重新复制或者手动删掉末尾的空格和换行。第二个是model not found。这个报错是模型名称不匹配。WorkBuddy 里预置的模型名称可能是hunyuan-4-preview但你申请的接口那边对应的模型 ID 却不是这个名字你需要进模型管理后台查一下实际返回的模型列表把 WorkBuddy 里的模型名改成和后台一致的。顺便说一句“workbuddy 目录 前面 有个 .”这个搜索词我看到的时候特别有共鸣那是指工作区目录默认带隐藏文件夹后面我专门讲。第三个是context length exceeded。这个不完全算报错但它经常被误会成模型坏了。当你把一堆文档拖进工作区让它总结时上下文长度超限了就会报这个。解决思路不是换模型而是先做一轮切片让 WorkBuddy 先读每个文件的前面部分再汇总而不是一次全塞进去。配置跑通之后下一步是让它真正干活。这里就不得不提 WorkBuddy 的灵魂功能——自定义指令和 Skill。3. 自定义指令与 Skill 扩展WorkBuddy 真正的灵魂表格里填了模型 Key 只是第一步真正决定 WorkBuddy 好不好用的是你怎么定义它的“行为准则”。WorkBuddy 的自定义指令相当于给模型设定一套工作 SOP标准作业程序而 Skill 则是一段段可复用的“技能脚本”让模型在特定场景下自动调用工具。这两个东西玩明白WorkBuddy 就不再是聊天窗口而是一个能按你的思路运转的虚拟助理。3.1 人手一份的自定义指令推荐清单我在工作台里维护了一套自己的指令集你可以直接抄作业然后根据自己的工作场景改。第一套是“会议纪要模板”。核心指令是从对话记录中提取时间、地点、参会人、讨论主题、结论、待办事项待办事项要标明负责人和截止时间输出格式为 Markdown 表格。这套指令配 Hy3 跑非常稳每次开会前把录音转写的文字丢进去一分钟不到就出来一份像模像样的纪要。第二套是“日报生成器”。指令要点是根据工作区中的项目进度文件提取今日完成事项、阻碍问题、明日计划不要润色、不要编造保留原始信息的颗粒度。这里最需要注意的是“不要润色”这个负面约束否则模型会自作主张给你改写事实。第三套是“代码评审助理”。指令是审阅指定代码文件按严重程度列出问题阻断性问题、性能隐患、可读性问题、风格问题每个问题给出所在行号和修改建议。这个场景建议切 Hy4 preview因为它的代码理解能力明显更强能揪出的问题更细。第四套是“文章改写器”。因为我是博主经常需要把一段录音或者草稿改写成正式博文我的指令是保留核心信息和观点改写为自然的中文表达加入必要的过渡句避免模板化开头控制每段在150字以上不要用列表总结。这套指令配合 Hy3 表现良好改写后的内容读起来不僵。自定义指令的存放位置在 WorkBuddy 的设置里注意它支持“项目级指令”和“全局指令”两种。全局指令是所有工作区共用的项目级指令只在指定工作区生效。我建议把通用行为约束比如“输出格式统一为 Markdown”放全局把业务相关指令放项目避免互相污染。3.2 Skill 的目录结构与写法逻辑Skill 是更高级的自定义。它本质上是一组“技能包”包含一个描述文件、若干运行脚本和依赖声明。WorkBuddy 在工作区里识别 Skill 的逻辑是扫描特定的目录结构这就是为什么热词里有人问“WorkBuddy 里目录前面有个 .”——那其实是隐藏的技能目录WorkBuddy 用它来存放和管理 Skill 文件名字带点前缀是为了避免和用户业务文件混在一起。Skill 的基本结构是这样的一个文件夹里包含SKILL.md描述技能用途和触发条件、script.py具体执行逻辑、可能还有requirements.txtPython 依赖。SKILL.md的撰写很关键它要让模型知道“什么时候该调用这个 Skill、传入什么参数、期望什么输出”。举个例子。我写了一个“网页标题批量抓取”的 SkillSKILL.md里写明“当用户需要批量获取一组 URL 的网页标题时调用此技能”script.py用 requests 抓每个网页的 title 标签把结果输出成 CSV。WorkBuddy 的智能体看到相关请求时会先读 SKILL.md 判断是否适用然后调用脚本执行。这里有个新手不容易理清的逻辑Skill 不是模型直接执行 Python而是模型“决定调用”一个脚本脚本的运行结果再回到模型手里做后续处理。所以你在 Skill 的脚本输出里最好做结构化处理别只打印一堆无关日志否则模型拿到的信息太杂影响下一步判断。3.3 一个完整的实战定时同步钉钉多维表与 Obsidian这个案例来自热词里的“workbuddy 钉钉多维表定期同步”和“workbuddy obsidian”这也是我认为 WorkBuddy 最出彩的场景——把不同系统串起来。需求很简单每天上午 9 点把钉钉多维表里的项目进度同步到本地 Obsidian 笔记库生成每日项目看板。拆解一下一共四步连接器读取钉钉多维表 → 数据清洗和格式化 → 写入 Obsidian 的指定笔记 → 由定时触发器每天启动。WorkBuddy 的连接器在这里起了大作用。它内置了钉钉、企微、飞书、Slack 等常见办公软件的连接能力不需要你写复杂的 API 对接代码。在连接器管理界面里授权钉钉账号选择需要读取的多维表WorkBuddy 生成的读取路径会自动放到对应的 Skill 环境变量里。真正的难点在于 Obsidian 的写入方式。Obsidian 的本质是本地 Markdown 文件所以写入并不需要什么特殊 API只需要一个“文件写入技能”把 WorkBuddy 生成的 Markdown 内容写到指定 vault 路径下。关键在于路径别写错建议先手动创建好 Obsidian 库里的文件夹然后在技能脚本里引用相对路径避免因为盘符或目录层级问题导致写入失败。这个场景用到的是“定时任务 连接器 文件写入技能”的组合如果每一步都配置好整个流程是全自动的。我实际用下来最满意的不是自动化本身而是数据并没有经过第三方的云服务中转——钉钉数据直接进了本地 Obsidian隐私性和可控性好很多。4. WorkBuddy 与 CodeBuddy 的定位差异以及“连接器”适配制胜点很多人会把 WorkBuddy 和 CodeBuddy 混为一谈因为它们确实是同一家公司推出的产品界面上也有不少相似之处。但在实际的工程实践里我建议你把它们当作两个不同工种来理解选错了工具会非常别扭。4.1 不是竞品而是分工什么时候用哪个CodeBuddy 的核心场景是“软件研发提效”它面向的是写代码的人。它做代码补全、代码生成、测试用例生成、仓库级问答本质是一个更聪明的 IDE 插件或开发助手。它的优势是深度理解代码库——你可以基于整个 GitHub 仓库提问它知道函数之间的调用关系。WorkBuddy 的核心场景则是“业务执行自动化”面向的是要处理流程、文档、数据、消息的人。它不要求你懂编程只要你用中文描述清楚“做什么、按什么顺序、用什么工具”它就能编排一个流程去执行。它的连接器、定时任务、Skill 系统都是为了非编码场景设计的。我用一个例子区分如果我要检查一个 Python 项目里有没有内存泄漏的隐患用 CodeBuddy它懂代码如果我要每天早上把销售表格里的低库存商品汇总成一条提醒发进群用 WorkBuddy它懂流程和连接。当然两者有重叠比如 WorkBuddy 也提供了不错的代码解释和脚本执行能力CodeBuddy 也有一定的自动化能力。但边界感很重要在 IDE 里写代码我切 CodeBuddy在桌面端做工作流我开 WorkBuddy。两个都装、各干各的是效率最高的组合。4.2 连接器能做什么钉钉、企业微信、飞书一个不少WorkBuddy 的连接器是它区别于“纯 prompt 工具”的核心资产。连接器的本质是预建的 API 桥梁——它帮你处理好了鉴权、重试、分页、数据结构映射你不需要关心接口文档长什么样只需要在界面上选“连接哪个应用、读哪个资源”。我实际搭过钉钉连接的流程。打开连接器管理页点“添加连接”选钉钉然后会弹出一个授权二维码用钉钉扫码确认授权。授权之后WorkBuddy 可以读取你有权限访问的钉钉应用资源比如多维表、审批、通讯录。这里注意一个权限粒度问题授权的账号只能看到它本人权限范围内的数据如果连接器的账号不对数据列表是空的这不是产品 bug是账号权限边界。连接器的价值在面对“老系统”时格外明显。比如某些企业还在用钉钉多维表管理项目没有现成的 API 给外部调调度WorkBuddy 的连接器刚好补上了这个缺口。不需要研发团队额外开发接口业务人员自己就能把数据接进来。这种“平民化集成”是传统接口对接方式做不到的。4.3 定时任务和触发器的组合玩法连接器只是“接水管”真正让流程转起来的是 WorkBuddy 的定时任务和触发器机制。你可以创建一个这样的自动化规则每周一早上 9 点 → 连接器读取钉钉多维表 → 用 Hy3 生成上周项目进度小结 → 通过企业微信发给指定群。配置的关键点有两个。一个是定时表达式。WorkBuddy 支持类 Cron 表达式也有可视化配置。新手别手写 Cron可视化里选“每周一 09:00”更不容易出错。另一个是失败重试机制当连接器拉取数据超时自动化流程怎么处理我建议在配置里开启“失败后重试 2 次”和“失败消息通知”否则流程静默失败会让你误以为跑成功了。还有一个非常容易被忽略的点触发器不是越多越好。每个自动任务都有对应的数据读取和模型调用免费额度虽然不花钱但额度是有限的。我会给自动化任务加一个“执行日志”输出定期查看哪些任务在低频循环、哪些任务总是失败及时关停无效任务把额度留给真正有价值的流程。5. 社区高频问题排查从 CLAW 不显示到 UI 自动化的边界看了一圈热词好几条都是关于“为什么看不到某个功能”“怎么用 WorkBuddy 做哪些事”这类问题。我做一次集中排查记录把几个典型案例的根因和解决办法说一下。5.1 “没有看到 CLAW怎么让它显示”这个搜索词应该是指某个功能模块或视图没出现在面板里。社区里问这类问题的用户绝大多数不是功能本身缺失而是视图布局或版本差异导致入口没被展示。排查路径是这样先确认你的 WorkBuddy 版本是不是最新。这类工具的迭代节奏很快有的版本默认不展示某模块升级之后就出现了。第二步是查看视图布局设置WorkBuddy 的侧边栏模块有些是可以折叠和排列的检查侧边栏设置里是否勾选了对应入口。第三步是看你是不是在“项目工作区”里而模块只在“个人工作区”展示。如果以上三步都排查完还是看不到那就不是配置问题可能你期望的功能名和产品里的实际名称不完全一致。比如你想找的可能是“自动化”模块但它叫“流程”你想找“连接器”但它叫“集成”。建议先翻一遍官方文档的功能目录把名字对齐再回来找入口。5.2 定时发送微信消息与 UI 自动化的实现思路“WorkBuddy 定时发送微信消息”这个需求在技术的可行性上要分两层看。如果你要发的是企业微信里的群消息恭喜你这个做起来很顺WorkBuddy 连接器原生支持企业微信定时任务触发后用连接器发消息到指定群。我的建议是至少预留 30 秒的缓冲时间避免因为网络延迟导致任务判定失败。但如果你要发的是个人微信消息事情就没那么简单了。个人微信的自动化发消息本质上是 UI 自动化也就是模拟鼠标键盘操作去点击界面按钮、输入文字。WorkBuddy 不是专门的 UI 自动化工具除非你特定安装了对应能力的 Skill 并在脚本里封装好了坐标定位和窗口操作逻辑否则不推荐把它当键盘精灵用。这也是热词里“使用 WorkBuddy 做 UI 自动化”的正确理解方式WorkBuddy 适合编排“调用 API 执行脚本”的自动化流程而不适合纯模拟人工点击的界面操作。如果非要坚持做你可以用 Python 的 pyautogui 编写脚本通过 WorkBuddy 的 Skill 机制调用但你要为此投入不少时间和踩坑成本。一句话能用 API 和连接器解决的不要走 UI 自动化。5.3 “weknora”是什么以及轻量模型本地部署的替代思路热词里有个“workbuddy 里边 weknora 怎么用”我猜测这里指的是一类本地知识库或检索增强生成工具的名称类似语义检索插件。如果你在 WorkBuddy 里装了这类扩展它能做的是把本地方档做向量检索让模型回答问题时先检索本地知识再生成回复而不是全凭模型内部知识瞎编。这类工具的实际使用门槛主要在文本切块和向量化的参数配置。文本切块太大会导致检索不精准切块太小会让上下文拆得稀碎。我的经验是中文文档每块 500 字左右、重叠 50 字向量化模型用默认的中文 embedding 模型即可。配置好后在 Skill 描述里注明“当回答涉及本地文档时优先检索知识库”模型就知道该调用了。另外热词里有人问“千问 3.8 本地部署到 WorkBuddy 效果怎样”这说明大家的确有本地化、隐私化的模型需求。千问系列开源模型近年来在中文任务上的表现确实不错如果你机器配置够至少 64G 内存做推理扛得住通过 Ollama 这类工具起一个本地 OpenAI 兼容接口然后在 WorkBuddy 里用“OpenAI Compatible”的模型配置指过去就能实现完全离线的工作流。不过要提醒一句本地小模型7B/14B 级别处理复杂指令的能力远不如 Hy4 preview在 WorkBuddy 跑“多步流程编排”会力不从心只适合做固定模板化的任务。6. 限免期间我最看重的三件事以及给你的一点实操建议限免活动的时间窗口其实不算长Hy4 preview 只有两周Hy3 到 9 月底我不建议你把这段时间用来“研究”工具而是建议你直接把它用起来盯住三件事跑通一个完整流程、积累一套自己的指令集、归档一组踩坑笔记。第一跑通一个完整流程。不管你是做文员、做开发还是做运营先选一个每周都要重复的固定任务比如写周报、整理报销单、同步项目表。把它拆成指令和步骤用 WorkBuddy 的定时任务跑一遍试试。中途大概率会翻车但翻车的过程是最有价值的学习材料——你会在报错里理解 WorkBuddy 的连接器、触发器和模型之间的协作逻辑。第二积累一套自己的指令集。我会建一个专门的文案指令库把场景、指令原文、预期输出、实测效果记在一个文档里。这就像老程序员沉淀代码段时间越长价值越大。等免费窗口过了以后你留下的指令库才是真正属于自己的资产。第三归档一组踩坑笔记。限免期间遇到的所有问题Key 填错了、模型名不一致、连接器权限不对、定时任务没触发都记下来附上截图和解决过程。这不只是帮你自己发到社区里也是很好的经验输出能帮助后面的人少走弯路。我自己很多关于 WorkBuddy 的理解就是在整理踩坑笔记时突然想通的。最后分享一个个人经验双模型限免的价值不在于省了多少钱而在于它可以让你在“零成本”的状态下试错。你会更敢按复杂任务、开多步流程、接多个连接器——因为这些尝试不需要花钱。等到活动结束只留下一个默认模型的时候你会更清楚什么样的配置是最适合你的而不是一上来就追求全功能大而全。工具永远是手段把工作流程理顺才是目的。限免窗口期正好是理清流程的最佳时机。