前几天技术群里突然被一个名字刷屏Hy4 preview。点进去一看信息量确实够大——770B 参数的 MoE 模型开源同时 WorkBuddy 宣布限时两周免费。这两件事放一起表面看是“又一个大模型开源了 一个工具搞促销了”但如果你做过模型选型或者正打算把手头重复的工作交给 AI 去跑就会明白这组合并不简单底座开源解决的是“能不能自己掌控模型”的问题工具限免解决的是“要不要先花钱试错”的问题。这篇文章我打算聊三件事一是 Hy4 preview 这个 770B MoE 到底值不值得关注背后是什么技术逻辑二是 WorkBuddy 这类工具和模型之间是什么关系适合谁用三是限时两周免费这个窗口期怎么领取、怎么安装、怎么真正用出价值。适合对开源大模型有兴趣的开发者、想用 AI 工具提升效率的产品和运营同学以及正在犹豫要不要本地部署一套模型服务的团队参考。1. 先搞清楚 Hy4 preview 的“770B MoE”到底厉害在哪1.1 MoE 不是“7700 亿个参数全都在跑”总参数和激活参数是两码事“770B”这个数字很容易让人以为模型每一次推理都要把 7700 亿个参数全部过一遍。实际上 MoEMixture of Experts混合专家的核心设计恰恰就是“不全部激活”。你可以把 MoE 想象成一家大型咨询公司770B 是公司名册上所有专家的总数但接到一个具体项目时路由器只会挑选其中一小部分专家进场干活其它专家继续待命。这个路由器就是 MoE 里的 Router 机制它负责根据输入内容把 token 分发给最合适的几个专家模块最后再把各专家的输出结果合并起来。专家之间各干各的细分领域比如有的擅长代码、有的擅长数学、有的偏向长文本理解路由器来决定“这个问题应该找谁”。这种设计带来的直接好处有两个。第一训练阶段可以把总参数做得很大模型的知识容量上去了第二推理阶段只激活一小部分参数单次请求的计算成本被压了下来。这也是最近两年超大模型普遍转向 MoE 架构的根本原因。稠密模型Dense所有参数每次都必须参与计算想加大规模就得线性增加推理成本到了一定的量级之后绝大多数团队根本跑不起。MoE 相当于把“规模大”和“跑得起”这两个本来互相矛盾的需求解耦了。至于 Hy4 preview 的激活参数具体是多少标题里只写了 770B 总量这种把细节留给技术报告的做法在业界很常见。按照 MoE 的常规设计区间来推测推理时实际激活的参数通常在总量的十分之一到二十分之一之间也就是大几十 B 的量级。这背后的意义很直接如果你手头有 80GB 左右的显存再配合适当的量化方案就存在本地跑起来的可能性而不是像稠密 770B 那样必须依赖多机集群。当然了这里只是基于 MoE 通用经验的推断具体部署门槛要看官方后续发布的 model card 和推理框架支持情况。1.2 770B 总参数放在今天开源模型里是什么档位光说“770B”不好直观理解我把当前开源模型里的几个代表性选手放一起横向对比一下模型总参数规模类型激活参数参考开源情况DeepSeek-V3671BMoE约 37B开源Qwen3-235B-A22B235BMoE约 22B开源Llama 3.1 405B405B稠密405B全量激活开源Mixtral 8x22B141BMoE约 39B开源Hy4 preview约 770BMoE未公布待官方确认开源从这张表能看出一个趋势今天的开源模型正在往“总参数越来越大激活参数控制在几十 B”这个方向走。Hy4 preview 如果把 770B 总参数坐实就是目前开源 MoE 阵营里第一梯队的存在明显高于 DeepSeek-V3 的 671B 总量但比当年纯稠密的 Llama 405B 对推理资源友好得多。更重要的是“preview”这个后缀。用过开源模型的人都懂preview 意味着功能和能力已经成型但还在接受社区反馈、暴露边界问题的阶段。也就是说谁先用起来谁就能更早发现它在自己业务场景下的真实表现——是骡子是马拉出来跑一遍才知道而不是只看榜单分数。这也是我通常建议团队优先关注 preview 版开源模型的原因等到正式版发布社区已经踩过一轮坑经验积累已经完成了。1.3 这个模型开源最大的受益者是谁每次有超大参数模型开源都有人说“反正我也跑不动和我没关系”。这话只对了一半。跑不动满血版确实正常但你至少有三条路可以走。第一条路是接 API 或者用云厂商的托管推理服务把 770B 当成一个远程大脑来调用完全不需要关心本地显存。第二条路是等社区的蒸馏版本模型开源之后很快会有人用小参数架构去蒸馏它的能力得到十几 B 甚至几 B 的版本这些才是大多数个人开发者真正能本地部署的东西。第三条路是拿它做数据标注和合成数据利用大模型生成高质量的训练集再去微调你自己的小模型。所以真正受益的实际上有三类人一是做学术研究的人有了 770B 级别的开源权重可以做模型内部机制分析、知识编辑、对齐研究这些以前只有大厂才玩得起的方向二是垂直行业团队哪怕不直接用 770B用它在自己领域数据上蒸馏一个领域小模型效果通常也远超直接训练小模型三是云服务商和推理框架开发者超大 MoE 开源后量化、投机采样、专家并行这些技术就有了新的试炼场。2. 从 CodeBuddy 到 WorkBuddy这次限时免费的主角到底是什么2.1 WorkBuddy 和 CodeBuddy定位完全不一样坦白说看到“WorkBuddy 限时两周免费”这个信息时我的第一反应是先搞清楚它和 CodeBuddy 的关系。从社区讨论和产品形态来看两者确实同属一个生态但解决的不是同一个问题。CodeBuddy 的侧重点在代码链路主要面向写代码的场景比如代码生成、仓库理解、自动补全和 Code Review。而 WorkBuddy 明显更偏向通用工作流覆盖的是更宽泛的办公和业务场景。我这样理解两者的分工CodeBuddy 像一个专门帮工程师干活的同事你让它改 bug 就改 bug让它写测试就写测试WorkBuddy 更像一个可以承接一整条业务流程的助理它不只回答你“这句话怎么翻译”而是能把“收集信息 → 整理格式 → 生成报告 → 按模板输出”这一连串动作编排起来跑完。这也是为什么在热搜词里会看到那么多和 WorkBuddy 相关的“教程”“使用”“本地部署”“插件”“安装”之类的搜索词。一个工具被大量搜索教程说明它有一定的配置门槛但也说明它确实提供了某个通用痛点对应的解决方案。大家都在找怎么把它跑起来、怎么把它接到自己的业务里。2.2 Skill 体系和自定义指令为什么说它是“可拼装”的助手WorkBuddy 最值得聊的设计是它的 Skill 体系。如果你用过 ChatGPT 的 GPTs 或者 Claude 的 Skills就很容易理解这个概念Skill 相当于给模型预装了一个“岗位说明书”加一套“操作工具包”里面既包含针对特定任务的指令模板也可以挂载外部工具调用和知识库。举个例子你可以在 WorkBuddy 里创建一个“周报生成”Skill告诉它你的团队有哪些成员、项目进度追踪习惯、周报模板长什么样以后你只需要把这一周的聊天记录、邮件、会议纪要往里面一丢它就能自动整理成结构完整的周报。这个过程中模型本身不需要重新训练变的只是挂在模型外面的“工作上下文”。自定义指令则是更轻量的一种定制方式。你可以把常用的偏好写成基础指令比如“所有输出用中文”“涉及数据必须给出计算过程”“不要给模棱两可的结论”这样每次调用都会带上这些约束。Skill 和自定义指令的区别一句话总结自定义指令是给助手立规矩Skill 是给助手配置完整的岗位能力。两者叠加起来工具才真正从“聊天框”变成“业务流程里的一环”。2.3 适合谁来用不适合谁把话说清楚WorkBuddy 这类工具并不是适合所有人的。如果你日常工作是由大量零散的、一次性的提问组成比如偶尔翻译一段话、偶尔让 AI 编个文案那免费期你可以随便体验但没必要投入太多精力去搭 Skill。可是如果你的工作里存在“每周都要做同样的事”“每次格式都一样只是内容在换”“需要把多个工具串起来处理数据”这类固化流程那就非常适合把 WorkBuddy 用起来。反过来如果你期望的是一个完全开箱即用、双击安装、永远不出错的“全自动数字员工”那目前这类工具多半会让你失望。它真正擅长的是把你定义清楚的流程跑顺而不是替代你去思考“这个流程到底应该怎么设计”。从这个角度说最好的使用姿势是你当项目负责人它当执行助理你把任务拆解清楚、边界划明白剩下的重复劳动交给它。3. 限时两周免费WorkBuddy 的获取、安装与首次使用全流程3.1 动手之前先把前提条件搞清楚既然是限时两周免费第一步肯定不是急着下载而是先搞清楚三件事免费的到底是什么、你所在的平台能不能跑、试用期从哪一天开始算。从目前公开的产品形态看WorkBuddy 主要有两种使用方式一种是官方托管的版本打开即用适合快速体验和验证业务场景另一种是本地部署适合对数据安全有要求或者想把 Skill 深度定制到内部系统的用户。热搜词里出现了“workbuddy 本地部署”和“workbuddy linux”说明本地跑通这件事很多人都在关注。先给一个偏保守但稳妥的操作建议如果目标是“两周内看它能不能解决我的问题”优先用托管版本不要去碰本地部署。这不是说本地部署不好而是因为本地部署的变量太多——依赖环境、模型服务的连接配置、显存占用、外部工具调用权限任何一个环节出问题都会消耗掉你本来就很宝贵的试用时间。先把业务跑通再考虑把整套东西搬回本地。另外要确认你的网络和设备环境多数情况下托管版本只需要一个浏览器本地部署则对操作系统有要求。建议先去官网把 WorkBuddy 的文档翻一遍重点看两个部分一是支持的系统平台列表二是免费试用的授权方式是自动发放还是需要注册申请。这两个信息决定了你后面所有步骤怎么做。3.2 安装的推荐顺序与标准操作这里以本地部署为例给你一个我实践下来比较顺畅的操作顺序全程不用管理员权限也能完成大部分步骤第一步准备基础环境。如果你用的是 Linux 服务器先确认 Python 版本满足要求官方文档如果没有特别说明通常 Python 3.10 以上比较稳妥。如果你用的是 Windows记得提前装好 Git Bash 或 WSL很多开源项目的脚本在原生 CMD 环境下会出现编码问题。第二步获取 WorkBuddy 本体。从官方公告给出的仓库地址克隆代码git clone workbuddy 官方仓库地址 cd workbuddy第三步创建独立的虚拟环境并安装依赖。这一步强烈建议单独建环境避免和系统里的其它 Python 包冲突python -m venv .venv source .venv/bin/activate # Windows 下为 .venv\Scripts\activate pip install -r requirements.txt第四步配置模型服务。WorkBuddy 本身是一个调度和编排层真正的“大脑”是背后的大模型。它通常支持两种模型来源一个是接入官方云服务或第三方 API另一个是连接本地模型服务比如通过 vLLM 或 Ollama 起一个推理服务。如果你只是想体验先用默认配置接云端模型如果你已经通过开源渠道获取了 Hy4 preview 这类模型的访问方式也可以把 API 地址填进去让它变成 WorkBuddy 的推理后端。第五步初始化配置并启动./workbuddy init ./workbuddy start启动成功后它会提供一个本地 Web 管理界面通常默认地址是http://localhost:xxxx在浏览器里打开就能进入工作台。到这里你已经完成了最核心的安装闭环。3.3 首次启动最容易踩的三个配置坑我自己在配置同类工具时踩过不少坑这里挑三个最常见的提醒你。第一个坑是把模型 API 地址填错。很多工具默认会去连http://localhost:8000但如果你本地模型服务起在了别的端口或者用了远程服务器必须把base_url改掉否则日志里只会反复出现“connection refused”而你不会第一时间反应到是地址问题。建议启动之前先手动用curl或者 Python 脚本测一下模型接口通不通通了你再启动 WorkBuddy。第二个坑是外部工具调用权限没配好。WorkBuddy 这类工具经常需要读写文件、执行脚本、调用浏览器不同系统下的权限管理方式不一样。如果你在 Linux 下发现 Skill 读取不了某个目录八成是目录权限问题而不是 Skill 写错了。提前把打算让 WorkBuddy 访问的目录权限开放好能少很多排查时间。第三个坑是依赖版本冲突。很多人拿到项目就pip install结果装到一半发现某个底层库和系统已有的版本冲突整个环境废掉。我的经验是创建虚拟环境之后先看requirements.txt里有没有指定版本号有就老实按版本装不要随意升级。这些看起来是小问题但在时间紧张的免费体验期里每一个都会浪费你半天。提示如果只是为了快速验证业务场景跳过本地部署直接用托管版本。托管版本通常已经把环境问题都处理好了你把精力省下来测试业务流程才是最划算的。4. 两周免费期内怎么把 WorkBuddy 用出价值4.1 先建自己的 Skill 库而不是到处逛模板拿到一个功能强大的工具之后最容易犯的错就是到处看模板、收藏别人的配置结果两周过去收藏夹满了自己的业务一个也没跑起来。我的建议是第一天不要碰模板先花半天时间梳理你自己的高频重复任务。你可以拿一张纸列一下过去一个月里你每周都做、每次格式都一样、只是内容在变的事情有几个。对多数人来说这种任务少则两三个多则六七个。把这些任务写下来它就是你的 Skill 库清单。然后按优先级挑一个最痛的任务亲手做一个 Skill。比如你是运营那就做“竞品周报”Skill你是财务那就做“费用汇总”Skill你是研发那就做“迭代报告”Skill。做第一个 Skill 的过程就是最好的学习过程你会理解指令怎么写模型才不跑偏、字段怎么定义输出才稳定。第一个跑通以后后面的 Skill 就是复制粘贴改改参数的事。4.2 三个可以直接上手的场景示例场景一结构化周报自动生成。把本周的聊天记录、邮件、项目文档放进一个目录写一个“周报生成”Skill定义好输出格式本周进展、风险项、下周计划。执行时 WorkBuddy 自动读取目录下的内容生成一份格式统一的周报。这个场景对大多数岗位都适用也是最能直观感受“流程自动化”价值的一个。场景二批量文档初筛。假设你手头有几十份简历或者方案需要先做一轮粗筛。在 WorkBuddy 里建一个“简历初筛”Skill设定筛选标准比如必须满足哪些硬性条件、优先关注哪些关键词然后一次性把文件丢给它让它输出一个“通过/待定/不通过”的汇总表。它不一定比资深 HR 判断得准但把第一轮机械筛选的活接走你只需要看通过的那一小部分效率提升立竿见影。场景三内部知识库问答机器人。把团队的操作手册、常见问题文档整理进一个知识库目录在 WorkBuddy 里挂一个“知识库问答”Skill。以后新同学入职不用再天天私聊老同事直接问它就行。这个场景需要的基础设施就是把文档放对位置、把 Skill 的检索范围写清楚技术门槛并不高但省下来的答疑时间非常可观。这三个场景的共同点是任务边界清晰、输出格式固定、重复频率高。它们恰好是 WorkBuddy 这类工具最擅长的事。4.3 免费期最容易犯的几个错我见过太多人在类似工具的免费期里浪费机会最常见的几个错基本是固定的。第一个错是接敏感数据不设防。有些业务数据不适合传到云端托管服务里但很多人图方便直接把客户名单、财务数据丢进去。建议在试用第一天就先做一轮“哪些数据可以传哪些只能本地跑”的梳理把所有敏感数据相关的任务留到本地部署方案确认之后再执行。数据安全这个事工具免费是好事但别拿隐私数据做赌注。第二个错是同时启用太多个 Skill互相干扰。免费期容易冲动看见什么功能都想开最后 Skill 之间产生指令冲突输出质量反而下降。正确做法是一次只激活一个 Skill验证稳定了再启用下一个。第三个错是只测试理想场景不测异常输入。比如你建了一个“周报生成”Skill只拿格式规范的会议记录去测一切正常可一旦遇到乱码文档、空文件、格式错乱的内容它可能就直接卡住或者输出垃圾。免费的这两周恰恰是你把“脏数据”喂给它、看看它崩溃边界在哪里的最好机会。提前知道它什么情况下会出错比只知道它什么情况下能用更有价值。5. 开源底座 限免工具背后我看到的三层机会5.1 底座开源降低的不是成本是掌控权门槛很多人会把“开源”单纯理解成“免费”这是误会。开源真正的意义在于可控和可持续你不用依赖某个平台的心情来决定明天模型还能不能调用不需要担心服务下架、接口涨价、数据被拿去训练这些不可控因素。Hy4 preview 把 770B 的权重放出来哪怕你短期用不上至少给了你一个“随时可以私有化部署”的选项。这和 WorkBuddy 限时免费放在一起看思路就更清晰了。模型负责能力工具负责业务流程模型开源把底座成本打到最低工具限免把试错成本降到零。如果你本来就在考虑搭一套内部的 AI 自动化流程现在正是成本最低的入场窗口。5.2 个人开发者如何把两个东西组合成可用方案对个人开发者来说一个务实的落地路径是“小模型 大模型 工作流工具”三层组合而不是什么都往本地搬。具体来说日常高频率、低复杂度的任务用本地小模型跑响应快且不花钱需要深度推理、知识密度高的任务通过 API 调用 Hy4 preview 这类大参数模型WorkBuddy 作为编排层负责调度任务到底层模型同时管理你的 Skill 和业务逻辑。这套组合的好处是成本和能力可以灵活调节——预算紧的时候多用本地小模型遇到真正棘手的问题再放大招。你甚至可以把 WorkBuddy 当成一个实验场在它的 Skill 体系里测试不同模型在同一任务上的表现差异哪个模型做哪些任务更稳记录下来。这个测试结论本身就是你接下来半年选型的参考依据。5.3 也需要冷静看待的地方最后也要泼一盆冷水。preview 后缀意味着模型还处于快速迭代期可能有已知或未知的能力缺陷770B 级别的模型就算开源完整部署的硬件成本依然不是个人开发者能轻松承担的开源协议也需要仔细看有些开源协议对商用场景有限制不是所有“开源”都允许你随意拿去包装成商业产品赚钱。所以我的建议是热情可以有但别把所有生产依赖押在一个刚发布的 preview 模型上。你可以拿它做验证、做对比、做数据生产但是关键的生产链路务必保留一个成熟模型的备份方案。工具免费期也一样免费期结束之后是否续费、价格能不能承受需要在试用期间就提前评估别等流程跑顺了才发现停不下来结果被动接受一个不合适的定价。6. 最后给同行的一点建议前面写了很多方法最后分享一点更个人化的体会。因为我平时要处理大量的工具选型和部署验证我给自己定过一个原则任何新工具、新模型拿到手之后第一周只做“最小闭环验证”不扩充、不优化、不加戏。所谓最小闭环就是把它最核心的能力在一个真实的小任务上跑通然后验证结果是否可靠。这个原则在 Hy4 preview 和 WorkBuddy 这个组合上同样适用——先用一个真实的小任务验证模型能力和工具的可控性确认过它确实能稳定干活再讨论怎么放大使用范围。两周免费期说长不长说短也不短足够你完成一轮很有信息量的验证了。但前提是你得有个清晰的验证目标哪怕目标只是“我到底要不要为这个工具掏钱”也比漫无目的地到处点一点、看什么都新鲜强得多。希望这篇内容能帮你少走点弯路。