WorkBuddy双模型限免怎么用？Hy4与Hy3搭建自动化工作台指南

我这两天在群里看到不少人在转 WorkBuddy 双模型限免的消息：Hy4 preview 直接放开体验两周，Hy3 给到了 9 月底。很多人看到消息第一反应是“能白嫖就嫖一下”，但如果你真把它当成普通抽奖活动，基本会错过这次免费窗口最有价值的用法。

先说清楚这篇内容写给谁：已经听过 WorkBuddy 但还没动手安装的人，想用它搭个人工作台、做业务流程或接口自动化的人，以及一直分不清 Hy4 preview 和 Hy3 到底该用哪个的纠结党。文章里没有厂商通稿那套说辞，更多是我把两个模型分别拉出来跑业务流、写网页、做接口验证之后得到的实操结论，以及一些常规教程不会写的坑。

按现在的节奏，一个模型预览版免费开放两周，属于非常典型的新能力冷启动；而另一个模型把免费期拉到 9 月底，更像是在给存量用户一个平滑切换的过渡期。这两件事叠加起来，说明 WorkBuddy 这次不是简单发福利，而是在借窗口期调整用户习惯。本篇就把这层逻辑拆开，再把下载安装、环境配置、模型选型和自动化接入的完整路径给你走一遍。

1. 双模型限免，看似一张“体验券”这么简单吗

1.1 看清两个时间窗口背后的意思

这次活动最显眼的一个细节是：不是所有模型统一免费到同一个日期，而是 Hy4 preview 放开两周、Hy3 放开到 9 月底。

为什么不干脆统一？我认为这里面有非常明确的产品节奏考虑。Hy4 preview 属于新一代模型预览版，厂商需要的是“短周期、高密度、强反馈”的测试样本。两周时间刚好覆盖一个完整的工作节奏：第一周让用户把日常任务丢给它跑，第二周观察它在真实场景下的失误率、重复请求率和上下文处理瓶颈。如果时间再拉长，用户流失后样本反而分散。

Hy3 免费到月底，本质上是在为存量迁移做缓冲。习惯用 Hy3 处理固定流程的人不用急着立刻换到 preview，可以先把手头依赖 Hy3 稳定性的自动化任务留着，等 Hy4 preview 验证成熟再逐步迁过去。对厂商来说，这也避免了“一刀切切掉旧模型”导致的用户舆情危机。

提示：如果你是主要拿模型做自动化跑批的人，别一上来就把旧流程全部迁到 Hy4 preview。更稳妥的做法是先用两周做并行验证，再决定是否切换。

1.2 为什么是“双模型”而不是一次升级

这个问题我琢磨了一阵。如果 Hy4 preview 真的全面优于 Hy3，厂商完全可以直接把 Hy3 下掉，只留新模型做免费推广。但它没有这么做，说明两个模型并不是简单“下一代替代上一代”的关系。

从实际使用来看，Hy4 preview 的上下文理解能力和对复杂指令的遵循度确实更好，在处理网页生成、长文档重构、复杂业务编排这类任务时表现更聪明。但聪明不等于稳定，预览版在个别场景下会出现响应格式漂移，比如你要求输出 JSON，它偶尔会夹带 Markdown 代码块。Hy3 则走了另一条路线：输出格式稳定、请求速度快、对重复性任务的理解非常可靠。

所以这更像一个“探索型模型 + 生产型模型”的组合。免费期把两者同时打开，就是让用户自己完成一次模型能力的分层认知：哪些任务需要新模型的推理上限，哪些任务只需要旧模型的稳定输出。这种并行模式对我来说其实更有参考价值，因为我能在同一环境里做 AB 对比，而不是靠厂商宣传页里的 benchmark 数字猜。

1.3 两周窗口期，适合谁能干点什么

Hy4 preview 开放两周，对不同的用户价值完全不同。如果你只是把它当聊天机器人，每天问几句“帮我写个文案”，那这两周对你来说基本没什么沉淀；但如果你是做自动化、搭建内部工具、或是做网页原型验证的，这两周就非常值得重点关注。

我自己给这次窗口期排了一张使用优先级清单：

• 第一优先级：把日常高频的“复杂指令型”任务丢进去测试，比如生成带交互的网页、整理大段会议纪要到指定表格结构、拆解一份多步骤业务流程。
• 第二优先级：用 Hy4 preview 重跑一遍之前 Hy3 做得不够好的需求，对比差异，记录触发失败或返工的原因。
• 第三优先级：检查你正在用的 Skill 和连接器在新模型下是否还能正常输出，尤其是那些要求模型输出特定格式的模板类任务。
• 第四优先级：沉淀一套适合 Hy4 preview 的提示词模板，不要等活动结束之后再后悔没有留下可复用的结果。

别把时间浪费在漫无目的的聊天上。真正的价值是把一次性的免费算力，转化成能被你反复调用的工作资产。

2. WorkBuddy 真正要解决的事：从“聊天框”到“工作台”

2.1 它和普通 AI 聊天工具的核心差异

要理解这次双模型限免的价值，先要搞清楚 WorkBuddy 到底是一款什么形态的产品。我第一次打开 WorkBuddy 时，第一反应是“这不就是个带模型切换的聊天窗口吗？”但用了一段时间后才发现，它的核心并不在聊天框本身，而在聊天框外那一层“可编排的工作环境”。

WorkBuddy 更像把 AI 能力嵌入了任务流里。普通人用一个 AI，是每次对话时重新描述一遍需求；WorkBuddy 的思路则是让你把固定动作沉淀下来，模型负责在固定框架里执行。举个例子，我给团队写周报这件事，如果用普通聊天工具，我每周都要复制粘贴一遍项目数据，再描述一次格式要求。但在 WorkBuddy 里，我可以把“周报生成”固化成一条指令，绑定好数据来源和输出模板，后面每次只需要更新数据，它就能按之前的规则输出完整内容。

这就是“聊天工具”和“工作台”真正的分界线：前者靠临场提问，后者靠提前搭建。要理解这次双模型限免的意义，就要先理解 WorkBuddy 本身。它的核心不是电一个大模型，而是把模型插进任务流、连接器、定时触发和自定义工具里，让 AI 能在我每天实际工作的上下文里持续运转。这次同时放开两个模型免费，恰好给了用户一个低门槛的 AB 测试环境。

2.2 WorkBuddy 与 CodeBuddy 到底什么关系

CodeBuddy 和 WorkBuddy 这两个名字放在一起，很容易让人混淆。从产品定位上来说，CodeBuddy 偏代码开发场景，更像是给程序员设计的 AI 结对编程工具，强调代码补全、仓库理解、单元测试生成这些能力；WorkBuddy 则偏任务执行和工作流场景，覆盖的不只是写代码，还包括写网页、跑业务流程、搭个人工作台、连接外部系统。

这不是是说 WorkBuddy 不能写代码，它也能写，但它的侧重点在于“把一件完整的事办完”。如果你要的是在 IDE 里盯着代码文件、随时让 AI 帮你改某一个函数，那么 CodeBuddy 会更顺手；如果你要的是布置一个任务给 AI，让它自己去调工具、查数据、生成成果物，那么 WorkBuddy 是更合适的载体。两者在功能上会有重叠，但在使用逻辑上有明显差别。

理解了这层关系，你再看这次限免就不会觉得奇怪：WorkBuddy 想要抢的并不是“下一个代码助手”的市场，而是更上层的“个人工作流入口”。这一类产品形态确实需要更强的新模型来支撑。

2.3 Skill、连接器、业务流程：三个值得记住的概念

WorkBuddy 使用教程里最常出现的三个词是 Skill、连接器、业务流程。很多新手在被这三个词绊住后就放弃了，其实它们并不复杂。

Skill 可以理解成“给 AI 的一份岗位说明书”。它通常由一段背景描述、一组执行步骤、一个输出模板组成。我举个例子：你可以创建一个叫“客户周报整理”的 Skill，里面写明客户名称从哪个字段取、数据源在哪、输出成什么格式，之后每次调用这个 Skill，系统就知道该干什么，不需要你每次重新描述。

连接器则是“让 AI 够到外部系统的管道”。文件系统、在线文档、数据库、协同平台、甚至某个网页后台，只要通过连接器接入，AI 就能读数据、写数据。类似浏览器插件之于浏览器的意义，没有连接器，AI 只能凭空说；有了连接器，AI 才能动手做。

业务流程则是把 Skill、连接器和模型串起来的执行链条。比如“每天早上 9 点，从数据库读取前一天的订单记录，生成摘要，再把摘要推送到指定群”。这种定时触发的自动化，在 WorkBuddy 里就是一条业务流程。理解了这三者的关系，再看 WorkBuddy 的界面就不会觉得功能堆砌。

2.4 本地部署最被高估，也最被误解

热搜里出现“WorkBuddy 本地部署”这个词时，我发现不少人第一反应是“要把大模型权重下载到自己电脑上跑”。这是一个比较普遍的误解，尤其是对接触 AI 没那么深的用户来说。

实际上这类产品的“本地部署”通常包含两种可能：一是把 WorkBuddy 客户端本体装在自己的机器上，通过本地服务进程与云端模型 API 通信；二是把整套调度环境部署到自己的服务器里，由部署方统一管理账号、数据流以及连接器，但模型推理本身仍然走服务端。把几十 GB 甚至几百 GB 的模型权重完全塞进个人电脑，对绝大多数用户没有必要，也没有性价比。

那为什么还有人执着于本地部署？核心诉求通常不是“我要拥有模型”，而是“我要掌控数据流程”。当你想让业务数据不经过第三方公共客户端、希望所有配置统一由团队管理、或者需要把 WorkBuddy 接到内部系统时，本地部署或私有化部署就成了更合理的选择。理解这一点，才能避免在安装阶段给自己加戏。

3. 安装、切换与本地接入：把 WorkBuddy 跑起来的那一刻

3.1 常规安装流程，三分钟完成

先说大多数人最常用的安装方式。WorkBuddy 的桌面端安装包一般可以直接从官方渠道获取，支持 Windows 和 macOS 两个主流平台。下载完成后，常规安装包安装流程都比较直接，双击安装包、按提示继续、等待安装完成即可。安装过程中需要注意的一点是，尽量安装到默认路径，不要为了省空间改到中文目录或权限受限的路径，否则后续启动本地服务时可能出现奇怪的权限问题。

安装完第一次启动，一般会要求登录账号。登录后进入主界面，你会看到模型选择区域、对话窗口和功能侧边栏。如果此时发现界面是空的或者模型列表加载不出来，先检查网络环境和账号状态，再检查是否需要在设置里手动刷新模型列表。整个过程如果顺利，三分钟内就能进入正式的对话界面。

注意：限免资格一般会绑定账号，不是“安装即送”。你需要在登录状态下打开模型列表，确认 Hy4 preview 和 Hy3 的标识已变为可用状态。如果界面上只看到 Hy3，别急着卸载重装，先找找设置里有没有“体验预览版”之类的开关。

3.2 Linux 环境下的安装与启动方式

目前社区对 Linux 版本的关注度不低，WorkBuddy 官方也在逐步覆盖 Linux 使用场景。如果你用的是 Linux 服务器，大概率需要拿到的是一份压缩包或命令行安装脚本，而不是像 Windows 那样双击 next。

通用的命令行安装路径大概是这样的：把压缩包解压到你希望安装的目录，给主程序添加可执行权限，然后在终端直接运行启动命令。第一次启动时，有些版本会在终端输出一个本地面板地址，比如 http://127.0.0.1:8080 这样的形式，你用浏览器打开这个地址就能进入和桌面端相似的操作界面。

初跑 Linux 版本时需要注意三点。第一，服务器时间和时区要正确，否则登录取证会有偏差；第二，尽量用非 root 用户运行，避免后续创建配置文件和连接器时出现目录权限不足；第三，如果用的是远程服务器，需要确认防火墙规则放行本地面板的端口。国内不少使用者会把 WorkBuddy 跑在便宜的云服务器或者本地 NAS 上，这种部署方式的好处是模型调度任务可以 7×24 小时执行，不必依赖某台个人电脑是否关机。

3.3 本地接入和 API 的合理姿势

把 WorkBuddy 跑成本地服务后，最直接的收益就是你可以通过 API 方式把它集成到自己的脚本或现有系统里。很多教程喜欢直接甩一段 Python 代码，但我更建议你先理解接入逻辑再动手：WorkBuddy 本地服务启动后，会暴露一组接口，用来接收任务请求、返回模型输出；你的业务系统只需要把文本任务或结构化任务发送到这个接口，就能拿到结果。

这个方案非常适合“把模型能力嵌入现有系统”的场景。我举个例子：团队内部有一台服务器每天处理若干条工单，现在你希望 WorkBuddy 每天晚上自动分析当天工单的共性问题并生成报告。传统做法是人工复制粘贴给模型；接入 API 后，你只需要在工单处理流程的末尾加一段脚本，把当天的工单文本拼接好，发给 WorkBuddy 的本地接口，再把返回的报告写入对应目录。

本地 API 接入听上去有点门槛，但对于做过爬虫或写过运维脚本的人来说并不难。核心只有一个：模型调度与业务逻辑解耦。让业务系统始终面向一串任务接口，而不是面向某个具体模型，这样即使 Hy4 preview 限免结束、未来换了新模型，你的业务系统代码也不需要大改。

3.4 正确领取限免资格与模型切换

这一步看似简单，但我发现很多人在模型切换上栽过跟头。进入 WorkBuddy 后，在模型列表里应该能看到 Hy4 preview 和 Hy3 的存在。限免生效时，对应模型会显示“限免”或“0 额度消耗”之类的提示，你可以直接点击切换。

切换模型不需要重启应用。你可以在同一个会话内切换，也可以在每条业务规则里分别指定模型。这里要特别提醒：有些定时业务流程在创建时就绑定了模型，即使全局切换了模型，旧流程可能仍然按原模型运行。如果你想趁 Hy4 preview 免费期间把某个固定流程切到新模型上，要回到业务流程设置里检查模型字段：

• 全局默认：所有未单独指定模型的任务都使用默认模型。
• 单条规则指定：只对当前业务流程生效，不干扰其他任务。
• 会话语境：类似聊天时手动切换，主要影响当前对话窗口。

建议做一次“设置模型 → 发送测试任务 → 检查返回结果 → 查看用量记录”的四步验证，确保模型切换真的生效了，不要等到月底看账单再后悔。

4. 核心玩法拆解：从写网页到接口自动化

4.1 网页原型怎么写：把 Hy4 preview 的能力拉满

很多人用 AI 写网页还停留在“帮我写个登录页”的层面，这远没有发挥 Hy4 preview 在水生模型里的优势。拿一次实战来说，我让 Hy4 preview 完成一个“团队周报生成器”的网页，要求包含一个输入区、一个结果展示区和一个复制按钮。用普通聊天式提问也能做，但页面样式会比较单薄，交互也相对基础。

但在 WorkBuddy 里，我换了一种做法：先创建一个项目目录，把需求拆成页面结构、样式、脚本、接口对接四部分，然后让 Hy4 preview 基于这个目录生成完整的页面。它给出的基础代码骨架大概是这样的：

<!DOCTYPE html> <html lang="zh-CN"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>团队周报生成器</title> </head> <body> <div id="app"> <h1>团队周报生成器</h1> <textarea id="raw-input" placeholder="粘贴项目进展、风险、下周计划..."></textarea> <button id="generate-btn">生成周报</button> <pre id="result-area"></pre> </div> </body> </html>

拿到基础版本后，我继续让它把结果按“本周进展 / 风险与阻塞 / 下周计划”三段式渲染，并加上一键复制功能。整个迭代过程中，Hy4 preview 对“保留已有结构、只改局部逻辑”的指令理解得比较到位，基本没有出现整体推倒重写的状况。这里也反映出一个使用技巧：让它写网页时，不要一上来就要求“做一个完美的大网站”，而要先把页面结构和功能点描述清楚，再按模块迭代。

4.2 接口自动化怎么做：用好 Hy3 的稳态能力

接口自动化是我日常使用频率最高的场景之一，也是我建议大家在免费期内重点测试的方向。之所以推荐用 Hy3 跑这类任务，是因为接口自动化讲究的不是发散能力，而是对接口文档的解析、对参数的记忆、以及对固定脚本模板的复用。这些需求恰恰是稳定型模型的强项。

我在 WorkBuddy 里配置接口自动化任务的基本思路是这样的：先把目标 API 的请求参数、鉴权方式、预期返回结构写清楚，然后让模型基于这些信息生成一段数据校验或接口冒烟脚本。模型不一定需要真的去发送 HTTP 请求，它可以做的是“根据返回文本判断必填字段是否缺失”这类逻辑工作。举个例子，它会输出类似下面的判断逻辑：

import json def validate_response(raw_text: str): data = json.loads(raw_text) required_fields = ["code", "message", "data"] missing = [field for field in required_fields if field not in data] if missing: return {"status": "failed", "missing": missing} if data.get("code") != 200: return {"status": "failed", "error": data.get("message")} return {"status": "success"}

其实“WorkBuddy 做接口自动化”这个说法很误导人，它并不是一个像 Postman 那样可视化点选的接口测试工具。更准确的定位是“让模型理解接口语义、辅助生成校验逻辑、并对返回结果做分析判断”。你需要把网络请求的部分交给脚本或连接器去处理，WorkBuddy 更擅长的是拿到返回结果后做解析、判断和报告生成。

我建议你把接口自动化的任务拆成两层：外层用 Python 或现成的调度工具负责发起请求，内层把返回结果交给 WorkBuddy 分析，形成一个“请求在外、判断在里”的协作结构。这样既不会因为模型不稳定影响整个测试链路，也能把模型的长文本理解能力用在最值得用的地方。

4.3 搭一个 7×24 小时的个人工作台

WorkBuddy 最让我觉得值的地方，不是聊天有多聪明，而是它能真正搭出一个“不睡觉的工作台”。方法很简单：本地服务保持运行，把需要反复执行的任务挂上定时触发，任务结果自动落到指定位置，你只需要每天早上打开结果文档看更新就行。

我从实际使用中总结出来的个人工作台搭建路径是：先明确高频重复的事情，比如日报整理、基金净值摘要生成、项目进展情况汇总、外部网页信息监控；然后逐个为这些任务绑定数据来源，常见的数据来源包括本地文件、网页地址、数据库；接着配置对应的输出模板；最后设置触发时间，可以选择每天、每周或自定义周期。

在你把它作为一个“7×24 小时工作台”部署之前，需要考虑一个关键问题：一旦这些任务开始依赖模型自动执行，你需要检查每一条任务是否会被“限免结束”所影响。比如 Hy3 免费到 9 月底，如果你把大量周报任务都绑定到 Hy3 上，就必须考虑届时是迁移到 Hy4，还是切换成正式付费方式。搭建自动化工作台时，建议把耗性能和稳定性要求高的任务放 Hy3，把探索型、临时型任务留给 Hy4 preview，形成一张高低搭配的任务矩阵。

4.4 沉淀 Skill 的模板写法

免费期最容易被忽略的收获，不是模型本身，而是你在试错过程中沉淀出的 Skill。Skill 写得好不好，直接影响模型输出质量。我提供一个比较通用的 Skill 模板结构：角色背景、任务目标、执行步骤、输出格式、约束条件。把这五个部分写清楚，一个 Skill 基本上就能稳定工作了。

拿“每日行业新闻摘要”这个 Skill 举例，我会在里面写：你是一名行业分析助理；任务是读取最新的资讯列表，从中筛选出与指定领域相关的条目；每一条摘要不超过 80 字；输出格式为 Markdown 列表，保留原文链接；如果有重复内容，只保留来源信息和时间戳最早的一条。这样模型每次执行时都能有明确边界，不会自由发挥得太远。

另外，写 Skill 时要尽量把模糊词换成可执行指令。比如不要写“简洁一点”，要写“正文控制在三到五行，总字数不超过 150 字”；不要写“分析一下”，要写“从市场风险、成本变化、替代方案三个角度分别给出观点”。在实际过程中我发现，把 Skill 里的要求写得越具体，Hy3 这类稳定型模型的输出就越可靠。

5. Hy4 preview 和 Hy3：别被免费迷惑，学会选型

5.1 从实际场景看两个模型的硬差别

很多用户关注的是“哪个模型更强”，但在我连续一周的对照测试里，更准确的判断是“哪个模型更适合哪类任务”。把两者的能力倾向整理成一张表，你就能看得更清楚：

这张表不能代表所有场景，但从我的测试结果来看，“Hy4 preview 全面优于 Hy3”是不准确的。更合适的表述是：Hy4 preview 的上限更高，但 Hy3 的下限更稳。

5.2 选型的最佳策略：按任务类型分流

如果你同时拥有两个模型的免费使用权，最佳策略一定不是“只挑一个用到死”。我认为值得参考的分流方式如下：

网页生成、原型设计、数据分析报告这类“一次性、高复杂性”的任务，优先选择 Hy4 preview，因为它的理解力更强。日常运营、批量信息提取、定时报告这类“重复性、模板化”的任务，优先选择 Hy3，稳定就是最大的优势。当任务发生在 Hy3 处理不了的高复杂度场景时，再切换到 Hy4 preview 来力挽狂澜。

比如我可以让 Hy3 负责每天定时抓取行情、生成净值摘要；而把“根据净值数据，分析资产配置变化并给出建议”这类开放性问题丢给 Hy4 preview。这样既能保证每天日报的格式不出错，又能让深度分析获得更好的模型支撑。

还有一个值得注意的点：API 接入时，同一账号下不同模型可能是独立计费或独立配额状态。免费期结束之后，两个模型的成本结构大概率不同。趁现在测试时，最好记录每个模型在典型任务上的消耗量，方便后续估算正式使用时的成本。这套“按任务复杂度和稳定要求分流”的思路，比单纯追求“新版更强”要实用得多。

5.3 版本切换时最容易踩的坑

我在切换模型过程中遇到过几个很典型的问题，这里提前告诉你，可以省去不少排查时间。

第一个坑是对话上下文不通用。某个会话如果用 Hy4 preview 聊了很长一段，切换到 Hy3 时，Hy3 往往不能完整继承之前的全部上下文信息。所以如果有重要任务，最好在一个模型下完整跑完再切换，不要做到一半突然切模型。

第二个坑是 Skill 兼容性。一个为 Hy3 设计的 Skill，格式模板可能比较固定，在 Hy4 preview 下不一定输出同样风格的结果。切换模型后一定要重新检查 Skill 输出是否符合预期，尤其是那些要求输出 JSON、XML 等结构化内容的 Skill。

第三个坑是业务流程模型锁定。创建流程时如果指定了模型，之后即使全局默认模型变了，该流程也不会自动切换。如果你打算在 Hy3 免费期结束后把所有流程迁到新的模型上，一定要提前在流程设置中修改模型字段，而不是只改全局配置。

这三个问题看似轻微，但在自动化场景里会直接导致任务失败或输出格式错乱。建议现在就把你的关键流程过一遍，看看有没有存在上述隐患的配置。

6. 高频问题与避免“白嫖翻车”的实用指南

6.1 常见问题速查

这里根据我的实操经历和社群里的反馈，整理出几个高频问题，方便你快速定位：

6.2 最容易忽略的几个隐藏细节

第一，“限免”通常不等于“API 免费”。WorkBuddy 客户端内的模型对话可能显示为 0 额度消耗，但如果你通过 API 方式接入自己的系统，可能走的是另外一套计费逻辑。我的建议是接入前看官方文档或咨询客服，不要默认 API 调用也免费。

第二，Skill 比模型更值得积累。模型限免结束后，你在免费期调出来的提示词模板、Skill 配置、业务流程并不会过期，它们会持续发挥作用。不要只停留在“用完即走”的聊天模式，把有价值的指令模板沉淀到 Skill 里，才是稳定收益。

第三，限免到期之前，你要提前检查自动流程。Hy4 preview 免费两周结束后，如果某个定时任务绑定了 Hy4 preview，而该模型恢复收费且账号未预留额度，任务可能会直接失败。建议在到期前一天把所有自动流程重新检查一遍，把不希望中断的任务切到 Hy3 或配置好正式额度。

6.3 免费期即将结束时我建议做的事

如果 Hy4 preview 的两周免费期只剩一两天，我会建议你做三件事。一是把近期跑得好的任务提示词保存下来，建立自己的“有效模板库”，为后续模型应用打好基础；二是把已经稳定运行的业务流程从 Hy4 preview 切回 Hy3 或者确认新的模型策略，避免定时任务突然中断；三是记录下 Hy4 preview 在各个场景下的表现，方便以后模型版本更新时做对比。

对 Hy3 的免费期到 9 月底这件事，我觉得也不能掉以轻心。如果你的流程重度依赖 Hy3，九月中旬就需要开始做迁移测试，看看它在新的模型组合下表现如何。别等到月底最后一天才去调整，模型一旦恢复收费或下线，影响的是你整个自动化业务流。

我个人的习惯是：在限免期内把那些反复出现、频率很高的工作流都重跑一遍，把结果存成 Skill。Hy4 preview 免费到期的前一天，我会用一天集中测试那些对上下文理解要求高的长任务；Hy3 的窗口更长，更适合用来搭每周固定跑的批处理。等限免结束了，这些沉淀下的流程依旧在跑，工具换了也不慌。这是我认为“体验模型免费期”最划算的姿态：不是拿它聊天，而是借它的测试期把自己的工作方法固定下来。