上周四下午同事在工作群里转发了一条 WorkBuddy 的消息平台开始双模型限免Hy4 preview 开放两周免费体验Hy3 期限更长直接免到 9 月底。说实话我第一反应是“又来营销噱头”毕竟类似的限免消息每个月都能看到好几条点进去不是要拉新就是要填一堆问卷。结果这次进入之后发现确实不一样登录账号在模型列表里切一下就能用不需要额外付费也没有强制分享之类的操作属于实打实的窗口期。过去大半年我已经把 WorkBuddy 当成主要的生产力工具之一日常写代码、做接口自动化、处理重复性文档都会在它的会话里完成。这次的限免价值在于普通用户终于有机会长时间、低成本地体验两代模型尤其是 Hy4 preview 这种平时可能藏在付费选项背后的新能力。我对这套工具熟悉又踩过不少坑所以就趁这个机会整理一篇实操向的内容把 WorkBuddy 是什么、双模型怎么选、限免期适合做什么、实际使用中会遇到哪些问题一次讲清楚。无论你是刚开始了解 workbuddy 怎么用还是已经在本地部署了 WorkBuddy 想试试新模型这篇文章都能给你一些可以直接落地的参考。1. 双模型限免的完整解读先搞清楚免的是什么1.1 WorkBuddy 不是又一个 AI 聊天框而是“能动手干活的智能体”先说一个很多人容易混淆的地方WorkBuddy 并不等同于你在网页里打开的那种 AI 对话框。它的定位更接近“AI 工作台 智能体运行环境”你可以把它理解成一个能真正碰你本地文件的 AI 助手。拆开来看它具备这么几层能力。第一它可以直接读取本地目录和项目代码理解你正在做的事情而不只是靠你复制粘贴一段内容进去。第二它可以执行终端命令然后自己读取命令输出根据结果决定下一步动作。第三它可以创建、修改、删除文件适合完成那种需要多个操作步骤串联的任务。第四它支持 skill 和连接器机制外部系统可以通过 API 接入让它把能力延伸到聊天、填表、创建工单这类业务场景里。这和传统 ChatBot 最大的区别是它具备“行动能力”。举个例子我让它“在这个目录下建一个静态站点并把首页里所有外链改成相对路径”它会先扫描目录结构看看有没有冲突文件然后分步生成页面再调用命令做本地预览最后告诉你哪里需要人工确认。这已经不是一问一答而是一个能闭环跑通的小任务。最近网上不少人拿 CodeBuddy 和 WorkBuddy 做对比。我自己的使用感受是CodeBuddy 更偏“贴身写代码的结对程序员”重点放在代码补全、单文件级别修改和代码库问答。而 WorkBuddy 更想成为你整个日常事务的总控台它不只是改代码更偏向按业务流程来调度。两者确实有交集但如果你需要的不只是写代码而是把一连串动作自动化掉WorkBuddy 的模型会更有发挥空间。1.2 Hy4 preview 和 Hy3 的定位差异以及怎么选这次限免的两个模型从命名看像是同一模型系列的迭代版本但实际体验差异挺明显可以当成两个不同性格的搭档来对待。Hy3 在我这边的表现属于“稳定型选手”。日常代码生成、小步重构、脚本编写、逻辑讲解它都完成得很扎实很少出现答非所问或者中途“跑飞”的情况。它更像那种在公司干了很久、做事稳妥但不太会给你惊喜的同事大部分日活任务交给它问题不大。Hy4 preview 则明显更“激进”一些。连续几轮长会话里它对复杂任务的规划能力更强面对多文件改动、从零搭一套项目骨架、接口自动化批量生成这类需求时它更容易一次给出相对完整的方案而不是挤牙膏式地一步步问。在处理长上下文时它的理解也更连贯不容易忘掉前面已经定好的约束条件。不过既然是 preview 版本就必然有 Preview 的脾气。我在测试中发现任务描述过于开放时Hy4 容易“自嗨”自己设计出一套庞大的目录结构实际上你可能只需要一个最简单的版本。它也偶尔会出现执行到一半停下来、需要你反复催“继续执行”的情况。所以这两个模型的适用范围不太一样我建议按任务类型来选而不是无脑追新。任务类型推荐模型选择原因个人工作台搭建、多文件项目初始化Hy4 preview规划完整长会话里不容易丢上下文接口自动化用例生成、测试脚本批量产出Hy4 preview生成的代码一次成型率高反复修改成本低日常问答、代码讲解、小范围重构Hy3响应稳定行为可预期不容易“加戏”批量文档整理、Excel/CSV 清洗脚本Hy3任务逻辑固定不太需要超强推理长时间运行的自动化流程Hy3稳定性优先减少中途失联的风险如何判断自己的任务该用哪个我有一个很朴素的标准先问自己这个任务如果交给一个只会照章办事的老员工他能完成吗如果能用 Hy3 就够如果任务需要大量推断和取舍需要在不同文件之间来回对比才值得切换 Hy4 preview。1.3 限免“窗口期”决定了任务优先级两个模型免的时间不一样这一点很重要。Hy4 preview 只有大约两周Hy3 却能一直用到9月底所以限免策略不能只是“谁强用谁”得有节奏感。我建议把 Hy4 preview 的窗口优先安排给那些“重活”和“一次性高强度任务”。比如你一直想重构但没空动手的老项目、准备从零写的接口测试工程、困扰已久的脚本框架重构、个人工作台的原型搭建这些任务利用两周时间集中完成价值最高。因为这些任务通常需要更强的规划和长上下文理解能力趁着 Hy4 preview 免费把硬骨头啃下来之后切回其他模型也不心疼。Hy3 的长窗口更适合用来“培养习惯和沉淀流程”。它到9月底都免费你可以把每周重复的固定动作交给它来做比如周五导出的数据报表清洗、会议纪要整理、固定格式的周报生成、日常代码库问答。这样做的好处是在窗口期里你已经把整套工作流跑熟了等免费期结束你留下的不是聊天记录而是一套可以持续复用的脚本、skill 和提示词模板。如果你之前没深入研究过 WorkBuddy这段时间正好可以完成从了解到深入的全过程第一周用 Hy4 preview 做几个大项目练手熟悉高级任务怎么拆后几周把日常高频任务全部切到 Hy3测试稳定性和长期表现。这样两不耽误。2. 从安装到切换到新模型一套流程走下来也就10分钟2.1 下载、安装、登录三件事很多人在热词里搜“workbuddy 安装教程”“workbuddy linux 版本”说明大家遇到的第一个门槛其实是环境安装。WorkBuddy 的客户端形态在不同平台上有差异但总体的思路是下载对应系统版本完成安装登录账号然后就能进入工作台界面。Windows 上比较简单下载安装包后一路下一步即可。需要注意的是WorkBuddy 这类工具需要在本地执行命令某些安全软件可能会拦截它读取终端或访问文件目录第一次启动如果遇到权限提示要先确认是不是安装包来源可信。如果来源没问题可以放行否则后续所有自动化操作都会卡在权限上。macOS 用户如果是通过网盘或官网下载的 dmg 文件要在“系统设置-隐私与安全性”里允许来自 App Store 和被认可开发者的应用。如果你习惯用 Homebrew 这类包管理器也可以关注一下官方是否提供了对应的安装源用命令行安装以后升级会更方便。Linux 场景下用户通常面临两种选择如果有图形界面版本直接下载 AppImage、deb 或 rpm 包安装如果跑在没有桌面的服务器上就要用命令行版本。命令行版本首次执行时会引导你完成初始化本质上就是生成本地配置文件写入账号信息和模型偏好。遇到command not found的提示时先确认安装包是否已经加入 PATH或者需要给可执行文件加执行权限chmod x workbuddy ./workbuddy --init这一步很多人会忽略明明文件下载了就是执行不了其实只是权限问题。登录方式一般支持手机号或第三方账号按界面提示操作即可。登录完成后工具会同步你的账号配置这一步没什么坑。倒是登录之后不要急着开干我习惯先单独建一个目录比如~/workbuddy-sandbox专门用来做测试实验避免模型在真实项目目录里执行一些你没预料的命令把文件搞乱。2.2 把模型切换到 Hy4 preview 或 Hy3安装完成接下来就是关键动作把模型切换过去。不同版本的 WorkBuddy 菜单位置可能有差异但思路是一样的打开设置或模型管理面板找到当前模型的下拉列表在列表里选择 Hy3 或 Hy4 preview。有一点要注意如果切换后没有生效最常见的原因是你还在用旧的会话。模型列表的切换通常只对新会话生效已经打开的会话会保持创建时的模型配置。所以正确操作是先切换模型再新建会话开始对话不要在同一个长会话里反复横跳否则模型记忆很容易“串味”。如果用的是命令行版本可以在启动时通过参数或环境变量指定模型。具体环境变量名以官方workbuddy --help的输出为准不同版本命名可能不一样。大致逻辑是这样# 终端环境变量示例具体以官方 CLI 的 --help 为准 export WORKBUDDY_MODELhy4-preview workbuddy另外有些用户希望把自己的 API 接入 WorkBuddy这在热词里也有不少人搜索。WorkBuddy 通常支持“自带 Key”的接入方式原理就是你自己有模型服务商的 API在连接器配置里填入对应的服务地址和密钥WorkBuddy 就会通过这个 API 来调用模型。好处是可以按自己的用量控制成本坏处是如果服务商限流整个工作流都会卡住。对新手来说我建议在限免期先用官方内置的模型入口跑通全流程之后再研究自定义 API 接入不要一上来就叠加太多变量。2.3 开工前给 WorkBuddy 建立合适的“工作边界”很多人抱怨 AI 工具不好用其实问题往往出在自己没交代清楚边界。WorkBuddy 本质上是一个能操作文件、执行命令的智能体如果目录里什么文件都让它读几十万行的 node_modules 或者其他依赖目录会瞬间撑爆上下文窗口。所以开工前的第一件事是给它“划地盘”。具体做法有两个。第一在项目根目录设置忽略规则类似.gitignore的思路把node_modules、.git、dist、build、临时目录等不需要关注的内容排除掉确保模型只看到真正需要分析的代码。第二在对话开始前明确指定任务范围不要直接说“帮我看一下这个项目”而是说“请先读取src/pages和docs目录不要读取其他路径”。这个习惯能极大提高任务成功率还能省下不少上下文空间。如果你有长期固定规范可以把它们写进项目里的说明文档也可以利用 WorkBuddy 的 skill 机制沉淀成可复用的指令。比如我自己会写一份文档规定前端组件命名规范、接口请求必须统一走某个封装函数、所有命令执行前必须先打印将要执行的内容。只要这些说明放在项目根目录WorkBuddy 每次读取后都会优先遵循。这比每次在对话框里重复解释要省事得多。3. 限免期间最值得做的三个实操方向3.1 方向一让 WorkBuddy 帮你搭个人工作台个人工作台这个概念听起来有点玄其实就是把自己每天高频使用的入口和零散信息集中在一个页面里省去来回开标签页的麻烦。我平时会在浏览器里开一堆后台系统、待办工具、常用软件链接每次要找某个入口得翻半天书签很烦。后来我直接让 WorkBuddy 帮我搭了一个纯本地的静态工作台放在固定目录里作为默认主页。当时的任务描述大概是这样的“在当前目录下创建一个 portal 文件夹用原生 HTML、CSS 和少量 JavaScript 做一个静态后台首页。左侧导航列出常用工具、今日待办、项目日志右侧展示三列卡片分别放常用链接、最近修改文件和快捷命令。不要使用构建工具所有文件都放在 portal 下最后启动一个本地 HTTP 服务并告诉我访问地址。”在这个任务里Hy4 preview 的表现比 Hy3 更突出一些因为它能自主规划文件拆分而不是把所有内容堆在一个 HTML 里。它会先扫描当前目录确认没有同名文件夹冲突再按照文件结构逐个生成 index.html、style.css、app.js最后主动建议用 Python 自带的http.server做本地预览避免引入额外的 Node 依赖。这类任务的关键不是生成结果有多惊艳而是你能从中学会如何向 AI 描述需求。我建议在提示词里加入验收标准比如“不要用构建工具”“按钮点击后不需要后端也能展示数据”“所有资源相对路径引用”。验收标准越明确模型越不容易自由发挥。个人工作台建好以后后续可以不断往里加功能比如让 WorkBuddy 解析你的书签导出文件自动生成链接卡片或者加一个本地 markdown 文件搜索框把零散笔记集中起来。Hy4 preview 的两周窗口期足够你把一个像样的工作台原型跑起来剩下细节慢慢调。3.2 方向二把接口自动化测试从零跑到能出报告如果你在热词里搜过“workbuddy 怎么用来做接口自动化”说明你大概率有真实的接口测试需求。这恰好是 WorkBuddy 这种工具最适合承担的活因为接口自动化不是单纯写代码还涉及读接口文档、建测试工程、跑用例、看失败日志、修改断言整个链路刚好是智能体的强项。我的建议流程是这样先把你手上的接口文档放到项目目录里最好是 OpenAPI/Swagger 格式的 yaml 或 json。然后在 WorkBuddy 里发起类似这样的指令“阅读docs/openapi.yaml在tests/api目录下生成 pytest 测试用例。需要覆盖登录接口、鉴权失败场景、订单列表、订单详情的正常返回和常见错误码。接口地址不要写死从环境变量 BASE_URL 读取。先生成文件不要执行。”这里有个很重要的细节点我特意说明“先生成文件不要执行”。因为在接口自动化场景里如果模型按自己的理解立刻发起真实请求可能直接打到生产环境或者把测试环境的数据搞乱。更安全的做法是让它先生成代码你来 review 确认逻辑没问题再加上执行指令让它在本地跑通。跑通之后你还可以进入 WorkBuddy 更擅长的“自动修复循环”先让它执行pytest -m smoke把失败用例的报错堆栈交回给它让它阅读日志并定位是接口字段变了还是断言写错然后直接修改对应测试代码再重跑一遍。这种“写测试—跑测试—看失败—修代码—再跑”的循环如果靠人肉来做很耗时间让模型接手就舒服很多。我自己在这类任务上会优先切到 Hy4 preview。原因是接口自动化的上下文往往不短需要理解接口文档、测试框架、既有代码结构还要记住之前定下的用例规范。Hy4 在两三轮迭代之间的记忆保持比 Hy3 更好修复代码时不太会“好心办坏事”把原本正确的断言一起改掉。3.3 方向三把重复的业务文档处理交给 AI 编排除了写代码WorkBuddy 在日常办公方面的价值被很多人低估了。它可以通过生成一次性脚本并且自动执行帮你完成批量文件处理本质上就是“AI 编排一个脚本任务”。举一个我每周都会跑的案例。公司系统每周会导出一份包含大量明细的 Excel我希望从中提取关键指标按不同城市分类汇总再生成一份带图表的总结报告。以前我要么手动整理要么花半小时写个 Python 脚本即便写好下个月字段一变又要重新改。现在我只把原始文件放进一个固定目录然后给 WorkBuddy 一句话“读取data/raw下最新的 Excel输出每个城市的订单量、销售额、退款率并按周生成 markdown 报告放到reports目录。”它会先生成处理脚本执行后如果发现某些列名对不上会读取文件头部信息进行调整最后输出一份可读的汇总报告。整个流程不需要我理解 Excel 的具体结构也不需要反复复制数据只要导出的文件格式没有翻天覆地的变化这套流程就能长期复用。这一类固定流程非常适合用 Hy3因为它的执行稳定性好不需要太多临场发挥。更重要的是你可以借着 9 月底的长窗口期把这类流程沉淀成 skill把“每周数据清洗”“月末汇总”做成固定的技能模块以后每次调用只需触发对应 skill不用重新描述需求。这才是 WorkBuddy 工作流的真正复利。4. 限免实测遇到的坑与排查方向4.1 任务拆得太大Hy4 preview 会开始“自嗨”限免期间我用 Hy4 preview 做的最大的一个错误是让它“把整个项目管理系统自动化”。这个任务听起来很高大上但实际执行起来它给出的方案越来越庞大甚至自己创建了 models、services、controllers、tests 全套目录但我原本只是想让它梳理清楚几个入口文件的调用关系。这其实是 preview 模型的常见问题任务开放程度越高越容易“自嗨”。解决办法也很简单把任务拆到足够小。不要让它一次性完成“整个系统自动化”而是先做“梳理所有路由入口并生成接口清单”等这一步确认没问题再规划下一步。每次只给它一个明确目标等它完成后继续下一个目标看起来效率低了但总比它天马行空创造一整套文件强。如果发现它已经开始偏离方向不要顺着它的计划走下去及时打断并纠正“我刚才只要求你完成 xxx请删除所有为 yyy 创建的文件重新检查目录结构。”这个纠正动作要果断不然它会在错误的方向上越走越远。4.2 长会话中途变慢或者“失忆”的排查思路限免窗口期用户量增大以后有朋友反馈响应速度时快时慢也有遇到长会话执行到一半卡住的情况。这里需要区分是模型本身能力问题还是上下文太长导致处理变慢或者是网络链路问题。先说上下文。有些人习惯把整个项目文件复制粘贴给模型让大模型一口吃成胖子这对任何工具都是一个考验。WorkBuddy 虽然本身有读取本地文件的方式但如果你的项目文件非常多且没有设置忽略规则它会花大量时间扫描无关目录任务效率自然下降。建议优先让它按需读取特定文件而不是一次性列出整个目录树的所有内容。再说会话管理。如果你在一个会话里持续工作了很久任务上下文越来越长中途可能会感觉模型的回复质量明显下降甚至忘记前面约定好的输入输出格式。这时候最好的办法不是硬聊继续而是开一个新会话把之前的关键背景信息压缩成一段摘要重新交给模型。这个习惯在长任务里能省很多时间。最后是网络问题。如果所有请求都卡住先看看是不是客户端版本过旧。我发现不少工具类软件的诡异问题更新到最新版之后自动消失。遇到莫名其妙的行为异常先重启客户端再开新会话最后考虑是否要切换模型不要一上来就怀疑模型能力。4.3 给执行类任务加上“预览确认”的安全带WorkBuddy 能执行命令这是它高效的原因也是你需要注意的地方。它本身是按照你给的目标去行动但它并不能保证每一步都对业务无副作用。所以我的原则是凡是有副作用的操作先让它预览人工确认后再执行。比如我会要求它在执行删除文件前先列出将删除的文件清单在批量重命名前先打印新旧文件名对照表在修改依赖版本前先展示 diff。这些操作可以在对话里用一句话加进去“请在执行删除前先展示变更列表等我同意后再继续。”如果是修改代码的场景我会让它先展示改动再写入或者直接利用代码托管工具查看 diff批准后再提交。这不是对工具不信任而是对生产环境的敬畏。这套“预览确认”的思路哪怕 Hy4 preview 的 intelligence 再高也应该保留。模型是概率系统它的决策大多数时候是对的但你不能拿“大多数”去赌重要文件的安全。最后再分享一个我从限免期里总结出来的小技巧。不要把这波限免单纯当成薅模型羊毛而是要想办法把每周固定走的流程沉淀下来。我自己的习惯是每周把高频任务整理成一份需求文档放到项目根目录或 skill 目录里然后让 WorkBuddy 按文档执行。Hy4 preview 的两周窗口我会专门拿来开发难度较高的任务等它的窗口结束后面的时间就交给 Hy3 接管日常。等到限免期过完你留下的不是一堆可有可无的聊天记录而是一套已经跑通的工作流这才是双模型限免里真正值得抓住的东西。