我这两天在群里看到不少人在转 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 langzh-CN head meta charsetUTF-8 meta nameviewport contentwidthdevice-width, initial-scale1.0 title团队周报生成器/title /head body div idapp h1团队周报生成器/h1 textarea idraw-input placeholder粘贴项目进展、风险、下周计划.../textarea button idgenerate-btn生成周报/button pre idresult-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 previewHy3上下文理解深度更强能处理长链条复杂指令稳定中短文本表现更好输出格式稳定性偶有漂移需校验非常稳定适合模板化输出网页/前端生成代码结构更合理交互覆盖更全能写但精细度稍弱接口自动化中的语义判断能做复杂判断更适合固定规则判断长文档归纳摘要更准不容易丢点较稳但偶见信息遗漏业务流程编排适合设计新流程适合运行成熟流程对话连贯性强能记住更早的上下文一般超长对话效果递减这张表不能代表所有场景但从我的测试结果来看“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 常见问题速查这里根据我的实操经历和社群里的反馈整理出几个高频问题方便你快速定位问题原因解决办法安装后无法启动安装路径含中文或权限不足重新安装到默认目录或用管理员/非 root 用户重试模型列表里没有 Hy4 preview未开启预览版开关到设置中查看预览版选项并开启刷新模型列表显示已免费但仍提示额度不足限免资格绑定账号切换账号后失效确认登录的是领取限免的账号切换模型后输出格式变了不同模型对相同指令的理解存在差异在 Skill 中补充更明确的输出模板约束定时任务没有执行本地服务未运行确认 WorkBuddy 进程在后台存活API 接口提示认证失败连接器配置过期或密钥错误重新检查连接器授权状态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 的窗口更长更适合用来搭每周固定跑的批处理。等限免结束了这些沉淀下的流程依旧在跑工具换了也不慌。这是我认为“体验模型免费期”最划算的姿态不是拿它聊天而是借它的测试期把自己的工作方法固定下来。