Hy4 preview 本地运行全攻略：从环境准备到 WorkBuddy 落地实践

Hy4 preview 登录 WorkBuddy 并且支持本地运行，这个消息最值得关注的点不是“又多个模型入口”，而是“本地运行”这四个字。对于日常要处理文档、代码、接口、工作流的人，本地运行意味着敏感内容不出机器、断网环境还能继续干活、高频重复任务不用每次都按 Token 计费。下面按实际落地顺序展开：环境怎么准备、操作怎么走、卡住时查哪里。

先说明一点，Hy4 preview 目前属于预览版本，具体入口、模型文件大小、支持的功能范围，会随 WorkBuddy 版本更新而变化。下面的内容基于常见的本地 AI 工具接入方式整理，落地时优先以你下载到的版本和官方说明为准。

1. 先弄清楚 Hy4 preview 进 WorkBuddy 到底解决了什么问题

1.1 这不只是多了一个“模型选择框”

WorkBuddy 本身是一个把模型、工具、任务流、知识库放在一起的工作台。以前要用某个本地模型，通常要单独装模型工具、单独配置环境、再手动把结果复制回任务里。Hy4 preview 进入 WorkBuddy 之后，变化在于：你可以在同一个界面里直接切换到这个预览能力，同时选择本地运行模式，让模型权重和运行数据留在本机。

这个“入口统一 + 本地运行”的组合，对三类人最实用：

• 经常处理公司内部文档、客户材料、未公开代码的人，数据不出本机是硬需求。
• 网络环境不稳定，或者偶尔要离线办公的人，本地模式更可控。
• 高频重复跑同一类任务的人，本地跑虽然要承担硬件成本，但长期看少了按次计费的不确定性。

1.2 本地运行解决了什么问题，同时带来了什么代价

本地运行的好处很直接：数据不上传、断网可用、请求次数不再被云平台配额卡住。但它也有明确的代价，这部分最容易被忽略。

第一，模型文件要占磁盘空间。预览版模型通常从几个 GB 到十几个 GB 不等，下载前先确认 C 盘或模型目录所在磁盘剩余空间。

第二，推理速度取决于你的机器。CPU 能跑，但长文本、多轮对话会明显变慢；有 NVIDIA 显卡并且驱动、CUDA 环境正常，速度会好很多。AMD 和 Intel 集显要看对应运行时是否支持。

第三，本地模式不是“点一下就开始”。模型初始化、首次加载、上下文变长后的内存占用，都需要你留出耐心。

这里有个通用判断标准：如果你的机器内存小于 16GB，磁盘剩余空间小于 20GB，建议先不要急着下载完整模型，而是看 Hy4 preview 有没有提供轻量版或量化版。如果没有，就先用云端模式把流程跑通，确认 WorkBuddy 的整体操作符合你的习惯，再考虑本地部署。

2. 运行前先核对环境，这几步能省下一大半排查时间

很多人第一次装本地 AI 工具，失败原因不是工具本身不行，而是环境没对齐。我建议按下面顺序检查，不要跳步。

2.1 操作系统与系统版本

从 WorkBuddy 相关讨论来看，官方客户端的主流支持对象是 Windows 10/11、macOS 和主流 Linux 发行版。Windows 7 这类老系统，即使能安装主程序，也可能因为缺少系统组件、驱动、新版本运行库而无法加载本地模型。如果你还在用 Win7，先不要急着抱怨工具，优先确认能不能升级系统，或者在另一台新系统机器上测试。

macOS 用户要注意芯片类型，Intel 芯片和 Apple Silicon 在模型加速上差别很大。安装前看一下 WorkBuddy 的下载页面是否区分了 CPU 架构版本，选错版本会出现“装上了但启动报错”的典型问题。

2.2 磁盘空间、内存和显卡驱动

判断一台机器适不适合本地跑模型，可以先对照下面这张清单：

这里有一个容易踩的坑：把软件装在 C 盘，但模型文件默认也下载到用户目录。如果 C 盘空间不够，会导致下载到一半失败，或者模型加载后系统盘快速变满。后面第 4 节会专门讲怎么迁移数据目录。

2.3 网络、账号和依赖

第一次下载模型、安装依赖、登录 WorkBuddy 账号，都需要正常网络。启动本地模式之后，模型推理本身通常不再依赖网络，但如果你要用到 WorkBuddy 的在线插件、技能商店或接口服务，网络还是要保持畅通。

依赖方面，WorkBuddy 作为桌面应用一般会自带运行环境，不太需要你手动装 Python 或 Node。但如果你打算用 API 方式对接自己的脚本，就要单独检查脚本里的依赖版本。常见报错顺序是：先看是不是路径问题，再看是不是权限问题，最后看依赖版本。

注意：安装路径和用户目录不要包含中文或特殊字符。很多本地工具在路径含中文、空格、符号时会出现“明明装好了却无法启动”的问题。

3. 安装、启动与第一次验证：用最小任务跑通全流程

本地 AI 工具最容易在第一次启动时劝退人。我的建议是：先跑通一条最小任务，不要一上来就做批量处理。

3.1 安装 WorkBuddy 并找到 Hy4 preview 入口

第一步，从 WorkBuddy 官网或官方渠道下载对应系统的安装包。安装时选择默认路径即可，如果 C 盘确实紧张，可以自定义安装到 D 盘或其他数据盘。安装完成后先登录账号，接着在模型列表或功能面板里找到 Hy4 preview。这个入口在预览阶段可能放在“模型市场”“实验室功能”或“预览通道”之类的位置，不同版本的具体名称会有差异，找不到时优先查官方更新日志，而不是到处找来路不明的补丁。

第二步，查看 Hy4 preview 的说明页，确认它的支持范围。有的预览功能只支持文本对话，有的能处理文档上传、代码生成、网页内容提取。确认清楚再决定要不要用它替代你现有的日常流程，避免第一步就期待过高。

3.2 下载模型并完成本地初始化

如果你选择本地运行，点击启用后通常会进入模型下载流程。这一步要关注三点：

• 下载进度是否正常。模型文件大，中途断网可能导致文件不完整，这时候删除残留文件重新下载，比“续传”更省心。
• 下载目录在哪里。记住这个路径，后面清理、迁移、备份都用得上。
• 首次启动是否提示额外依赖。比如提示需要安装某个运行库或加速组件，按提示装完再重启 WorkBuddy。

初始化完成后，WorkBuddy 一般会在模型列表里把 Hy4 preview 标记为“本地可用”或“本地模型”。如果一直显示“下载中”，先看网络和磁盘空间，再考虑重启应用。

3.3 用一条最小任务验证是否跑通

不要直接给它一个几千字的文档让它总结，也不要第一次就跑几十条批量任务。先发一句简单的指令，比如让它写一段 Python 代码、总结一句话、列出三个要点。验证目标只有一个：确认输入能发出去、模型能返回结果、结果能正常显示在对话窗口。

跑通之后，再逐步增加难度：

• 让它处理一个本地文件，确认文件读取正常。
• 让它连续回答多轮问题，确认上下文切换是否流畅。
• 让它输出 JSON 或代码，确认格式是否保留完整。

这三项都正常，才说明基本链路没问题。任何一个环节失败，都先检查输入内容、文件路径、编码格式，再考虑是不是模型参数问题。

4. 核心参数和配置取舍：哪些设置必须知道

本地模型跑通之后，真正决定体验的是参数和配置。下面这几个点，基本覆盖了大多数用户会遇到的设置问题。

4.1 上下文长度与“上下文用量满了”的处理

本地模型通常有上下文长度上限，比如 8K、16K、32K 或者更长，以实际版本为准。上下文越长，能记住的对话越多，但内存占用和推理耗时也越高。“上下文用量满了”是 WorkBuddy 用户里很常见的问题，现象是：前几轮对话正常，后面模型开始“遗忘”前面的内容，或直接把新增输入忽略。

处理办法按优先级排列：

1. 开启新会话。最简单，把当前讨论结论粘贴到新会话开头，继续工作。
2. 压缩当前内容。让它把中间过程总结成几条要点，再继续。
3. 减少单次粘贴量。不要一次性把整份文档塞进对话，先分段提取关键信息。
4. 检查是否有自动清理开关。有的版本支持自动截断或摘要，开启后可以缓解，但要注意它的摘要可能丢失细节。

不要一遇到“满了”就调大上下文参数。调大写死之后，内存占用会明显上升，低配机器容易直接卡死。

4.2 模型目录、缓存与“把 WorkBuddy 移到 D 盘”

很多用户下载模型后，发现系统盘空间告急。解决思路有两条。

第一条，在 WorkBuddy 设置里修改模型下载目录和数据目录。大多数桌面应用都提供“存储位置”或“资源目录”选项，改成 D 盘或其他数据盘即可。注意，修改后要把已经下载的旧文件也迁移过去，否则会重复下载。

第二条，如果设置里没有迁移选项，可以在系统层面把用户目录下的对应文件夹做移动或符号链接。这个操作不算难，但要注意先关闭 WorkBuddy，迁移完成后再启动，否则容易产生文件冲突。对新手来说，更稳妥的做法是安装时就把程序装到数据盘，并从一开始把模型目录指向非系统盘。

缓存文件也是空间大户。对话记录、附件、临时文件会慢慢积累，建议每隔一段时间清理一次缓存目录。清理前确认没有正在运行的任务。

4.3 并发、批量和 API 接入的取舍

本地模型和云端模型在并发能力上差别很大。云端可以同时处理很多请求，本地模型受限于 CPU、GPU、内存，并发开太高会导致任务排队、显存溢出、甚至整个应用无响应。

如果你只是自己用，保持默认并发即可，不要开最大。如果你想通过 API 把 Hy4 preview 接到自己的脚本或自动化工具里，建议按下面顺序做：

1. 先用界面模式跑通一条任务，确认模型本身没问题。
2. 再查 WorkBuddy 是否有本地 API 服务开关，开启后记下端口地址和鉴权方式。
3. 用一条最简单的请求测试返回格式，确认 JSON 结构、错误码、超时设置。
4. 最后再做批量调用，并加上失败重试和日志记录。

接口自动化场景容易出的问题不是“模型不会写代码”，而是请求格式、超时设置、返回解析不一致。接口文档没写清楚时，先抓一次真实请求看返回内容，比反复改参数高效得多。

5. 常见问题与排查链路：按顺序查，不要乱改

这里整理几条高频问题，排查顺序尽量从“最便宜”的检查开始。

5.1 启动失败、连不上本地服务

现象：点开 Hy4 preview 后一直转圈，或提示“连接失败”“本地服务未启动”。

排查链路：

1. 先看任务管理器或活动监视器，确认 WorkBuddy 进程有没有在运行。
2. 再看日志。桌面应用一般会在用户目录下生成日志文件夹，找到最近的错误记录。
3. 确认端口没有冲突。如果本地服务占用了固定端口，另一个程序占用了同一个端口，就会出现连不上。
4. 确认路径没有中文和特殊字符。
5. 最后考虑重装对应组件或整个应用。

不要一开始就卸载重装。八成问题出在路径、权限、端口和残留文件上。

5.2 输出为空、格式不对、内容截断

现象：任务执行成功但没有输出，或输出的 Markdown、JSON 乱掉。

先检查输入：

• 文件格式是否受支持。比如 PDF 预览报错，往往不是模型问题，而是系统缺少对应预览组件。
• 文件路径是否正确，有没有把“文件名里带空格”当成路径错误。
• 文本编码是否为 UTF-8，某些旧版文档会有编码兼容问题。

再检查输出：

• 是不是上下文超长导致尾部被截断。
• 是不是输出内容本身超过接口限制。
• 是不是后处理脚本解析逻辑写错了。

5.3 速度慢、内存占用过高、电脑卡死

现象：多轮对话后风扇狂转，应用无响应。

排查顺序：

1. 先看内存占用。如果接近满，先关掉浏览器其他标签页，再重启 WorkBuddy。
2. 把上下文长度调回默认值。
3. 减少同时打开的工作区、插件和技能数量。
4. 如果开了多个本地模型，只保留当前要用的一个。

低配机器的正确用法是：小任务、短上下文、低并发。不要幻想在 8GB 内存的笔记本上流畅跑大型本地模型，这不现实。

5.4 系统兼容与权限问题

现象：Windows 7 安装不上、安全软件拦截、应用无法写入目录。

处理思路：

• 老系统优先换新系统，预览版工具对新系统的适配最及时。
• 安全软件误报时，先确认安装包来源是官方渠道，再在安全设置里加入信任区，不要盲目关闭防护。
• 应用无法写入目录时，给程序数据目录赋予当前用户的可写权限。

提醒：预览版功能本来就不稳定。正式使用重要工作流之前，把关键数据备份好，并保留一个稳定版本的安装包。

6. 进阶用法：把 Hy4 preview 用成真正的工作流工具

跑通、调顺之后，才算开始真正使用它。这个阶段重点想清楚三件事。

6.1 用 WorkBuddy 的 Skill 和插件扩展场景

WorkBuddy 支持技能（Skill）和插件机制，这也是它和普通聊天工具的主要区别。Hy4 preview 作为模型能力，可以配合技能完成更具体的事：比如让模型按固定模板生成日报、解析网页内容、整理 Obsidian 笔记、辅助生成 ComfyUI 工作流、在 VSCode 里辅助写代码。

注意，技能和插件会改变输入给模型的内容结构。如果某一次结果突然变差，先禁用新增插件再试，很多问题是插件改写了提示词导致的。这也解释了为什么有人会说“模型没变但效果差很多”。

6.2 和 CodeBuddy、Trae 等其他工具怎么分工

很多人会拿 WorkBuddy 和 CodeBuddy、Trae、千问办公做对比。这里不给出谁好谁坏的结论，只给你一个判断框架：

• 如果主要做代码仓库级任务，比如理解整个工程、多文件重构，要重点看工具对项目的索引能力和编辑器集成程度。
• 如果主要做日常办公、文档、流程、接口调试，要看工具的任务面板、技能扩展和数据管理好不好用。
• 如果核心诉求是数据不出本机，就要看本地模型加载能力、离线可用程度和 API 开放程度。

同一个模型在不同的入口里，体验差异往往来自界面、上下文管理和插件质量，而不是模型本身。所以先确定你的主要场景，再选工具，比反复换工具更有效。

6.3 从入门到熟练，再到稳定产出

网上有“WorkBuddy 从上手到变现”的说法，我的观点是：先把工具用熟，再把效率转化为可交付的结果，最后才考虑收益问题。具体路径可以这样走：

1. 第一周：只用默认配置，每天处理 2 到 3 个真实小任务。
2. 第二周：整理自己的常用提示词和技能组合，把重复操作模板化。
3. 第三周：接 API、写脚本、做批量任务，同时把日志和失败重试机制补上。
4. 第四周：回顾哪些任务确实比原来快，哪些仍然需要人工检查，把边界记下来。

判断一个工具是否值得长期用，不是看功能列表多长，而是看你能不能稳定地复现同一个结果。预览版功能尤其如此。

6.4 始终盯住预览版的边界

Hy4 目前是 preview，意味着功能可能变化、接口可能调整、模型行为可能和正式版不同。落地建议只有三条：

• 重要数据定期备份，不要只存在 WorkBuddy 的配置目录里。
• 升级前先看更新日志，确认新版本是否改了入口、参数或本地模型格式。
• 如果当前版本工作正常，不要为了追新急着升级，等社区反馈稳定后再动。

本地运行的最大优势是可控。硬件是你的、数据是你的、参数也是你的，出现问题也有完整的日志可以查。把这一套摸熟之后，不管以后 Hy4 正式版叫什么名字，也不管 WorkBuddy 怎么更新，你都能快速迁移到新版本上。