WorkBuddy+Hy4预览版：单次生成过山车视频的工作流实践-平芜编程栈

在 AI 视频生成这件事上，很多人的注意力只停留在“哪个模型跑得快”“哪个视频更真实”，却忽略了一个更实际的问题：当你想在项目里真正用起来，模型本身只是底线，能把你从“写提示词、调参数、反复抽卡、剪辑拼接”里解放出来的，是围绕模型搭建的工作流。

Hy4 预览版最近在 AI 视频讨论里被反复提起，而它在 WorkBuddy 里的用法更值得关注。这里释放的信号是：视频生成模型正在从“在线网页填提示词”往“Agent 工作台里可编排、可复用、可编程”的方向迁移。本文不打算堆参数，也不做云评测，而是把一个非常具体的场景拆开讲——在 WorkBuddy 中用 Hy4 预览版单次生成过山车视频。读完你会知道它解决了什么问题、适合谁、有哪些容易踩的坑，以及怎么把这次尝试变成一个能复用的工作流。

1. 为什么要关注“Hy4 + WorkBuddy”这个组合

1.1 视频生成真正让人头疼的不是模型，而是流程

很多人第一次用视频生成模型时，会觉得“输入一段描述就能出片”已经很颠覆了。但放到真实项目里，问题很快暴露：

一次生成的片段往往小于10秒，想做一个完整的过山车镜头，可能需要好几段拼接；
模型对运动速度、镜头轨迹、光影变化的控制并不稳定，需要反复抽卡；
不同素材之间的风格、色调不一致，后期要对齐；
提示词写得再长，模型也有自己的理解和遗忘，上下文一长，生成结果就开始飘。

Hy4 预览版能解决一部分“生成质量”问题，但它解决不了“工作流”问题。真正把流程理顺的，是 WorkBuddy 这类 Agent 工作台。

1.2 WorkBuddy 不是又一个聊天框

从公开资料和社区讨论来看，WorkBuddy 是一个面向个人工作台的 AI Agent 工具。它和纯聊天助手不一样的地方在于：

支持多模型接入，可以把 Hy4、其他生成模型、常规对话模型放在同一个平台里管理；
支持 Skill，允许把一套提示词、参数、执行步骤沉淀成可复用的能力；
支持 API 接入，既能调用外部服务，也能把这个视频生成能力暴露给其他系统；
支持工作流编排，可以把“生成视频片段—检查结果—调整参数—再次生成”串起来；
可以集成 ComfyUI、Obsidian、VSCode 等工具，适合在已有工作环境里使用。

所以在 WorkBuddy 里跑 Hy4，并不只是“从一个网页工具换到另一个网页工具”。它把视频生成从一次性操作，变成了可复用、可维护的工程流程。

1.3 为什么拿“过山车”当测试场景

过山车是视频生成模型比较苛刻的测试场景。因为它同时包含：

主体高速运动，列车在轨道上不断转弯、爬升、俯冲；
镜头需要跟随，前视角、侧视角、外部固定视角都会影响观感；
场景不断切换，轨道穿过山谷、山洞、木质结构、钢铁结构；
光线会在运动过程中快速变化，顺光、逆光、灯光带；
前景和背景的相对运动速度不同，如果模型没有处理好运动逻辑，画面会非常容易穿帮。

一个模型如果在过山车场景下能保持主体一致性、镜头流畅性和光影稳定，那它在常规运镜场景下基本不会出大问题。

2. WorkBuddy 与 Hy4 的核心概念

2.1 先理解 WorkBuddy 中的三个关键概念

很多刚接触 WorkBuddy 的人会被它的术语绕晕，尤其是在社区问答里看到“Skill”“上下文用量”“API 接入”时会感觉很复杂。实际上只需要先抓住三个概念：

第一个是模型。WorkBuddy 本身不是模型，它是承载模型的平台。你可以把 Hy4 预览版当成一个视频生成模型接入进来，也可以接入其他对话模型执行分析、总结、提示词优化等工作。接入之后，WorkBuddy 会统一管理调用密钥、模型参数和调用记录。

第二个是 Skill。Skill 是 WorkBuddy 中可复用的能力单元。如果你想稳定生成过山车视频，可以把“过山车提示词模板 + 参数组合 + 后处理要求”打包成一个 Skill。之后每次需要生成时，直接调用这个 Skill，而不是每次重新写一遍提示词。

第三个是上下文。上下文指的是 WorkBuddy 在一次对话或一次任务中能够参考的历史信息量。如果上下文用量满，生成结果会变差，甚至提示无法继续。很多人遇到“上下文用量满了怎么办”，本质上是没有合理拆分任务，把太多中间过程塞进了同一个会话。

2.2 Hy4 预览版解决了视频生成的什么问题

从“预览版”这个限定词可以看出，Hy4 还处于迭代阶段，不是成熟稳定版。预览版的优势是能提前体验新能力和新效果，缺点是参数、接口和生成效果都可能随时调整，不适合直接用于生产环境。

在过山车视频这个场景里，Hy4 最值得关注的点是“单次生成”。所谓单次生成，是指在一个生成任务中，直接输出符合描述的视频片段，而不是拆成一段段手动拼接。这个能力对短视频创作、概念演示、游戏预告片早期原型来说，能明显降低流程成本。

不过需要明确一点：没有公开资料能证明 Hy4 已经公开了全部模型细节，所以本文下面的接入和配置演示，是以 WorkBuddy 这类工作台的通用接入逻辑来写的。字段名和 API 路径很可能在不同版本之间有差异，实践时一定要参考你当前版本的官方文档。

2.3 WorkBuddy、CodeBuddy、Trae 有什么区别

社区里经常出现“CodeBuddy 和 WorkBuddy 区别”“Trae 和 WorkBuddy 区别”这类问题。一句话可以概括：

CodeBuddy 偏向编程场景，核心是代码生成、代码补全、代码解释；
Trae 是 AI IDE，它更像一个编辑器，在 IDE 环境里帮你写代码；
WorkBuddy 更偏向个人工作台，核心是把模型、Skill、API、自动化流程整合在一起，视频生成只是它能承载的场景之一。

所以如果你只是写代码，选 CodeBuddy 或 Trae 更直接；如果你想在一个平台里同时管理模型、生成视频、调用接口、沉淀工作流，WorkBuddy 的定位更匹配。

3. 环境准备与前置条件

3.1 系统与运行环境

WorkBuddy 是桌面级应用，不是纯网页工具。从社区里的常见问题能看出，它在 Windows 7 上无法使用，对 Windows 10/11 的支持更可靠。这一点在使用前就要确认，避免下载安装后才发现系统不兼容。

一个容易被忽略的问题是默认安装位置。社区里有很多人问“WorkBuddy 怎么移到 D 盘”，说明它默认安装后占用空间不小，而且后续模型缓存、生成结果、日志都可能持续增长。如果你习惯把大型软件放在 D 盘，更容易管理的做法是在安装时手动改安装路径，或者在安装完成后把缓存目录迁移到空间更大的盘符。

3.2 需要准备的三样东西

在开始之前，确认自己具备以下条件：

项目	说明
可用的 WorkBuddy 账号	从官方渠道下载并注册，部分功能可能通过活动兑换码解锁
Hy4 预览版访问权限	预览版通常需要开通权限或者在 WorkBuddy 中完成模型接入
可用的 API 密钥	如果 WorkBuddy 以 API 方式调用 Hy4，需要准备一个有额度的密钥

如果你的版本不是以 API 方式接入 Hy4，而是直接在 WorkBuddy 内选择模型，那么 API 密钥这一步可以跳过。重点是：不要把密钥提交到 Git 仓库，也不要写在分享出去的代码里。

3.3 安装完成后的检查清单

安装完成后，先不要急着生成视频，按下面的顺序检查一遍：

确认 WorkBuddy 能启动并正常显示主界面；
在“模型管理”或“设置”页面确认已经能看到 Hy4 预览版；
检查是否有可用的模型配额或兑换码权益；
确认当前版本能否创建 Skill；
如果计划使用 ComfyUI，提前准备一个可运行的 ComfyUI 环境。

这一套检查做完，基本可以确定后续操作中遇到的问题，是出在接入配置还是出在生成流程。

4. Hy4 模型接入与基础配置

4.1 模型接入的通用思路

虽然不同版本的 WorkBuddy 界面可能不同，但模型接入的通用逻辑是一样的：先拿到模型访问凭证，然后在 WorkBuddy 里配置模型参数，最后在 Skill 或工作流中引用该模型。

下面是一个通用配置示例，字段名以演示为主：

{ "model": "hy4-preview", "name": "Hy4 视频生成预览版", "api_key_env": "HY4_API_KEY", "max_retries": 3, "timeout": 300, "params": { "resolution": "1080p", "duration": 8 } }

在这个配置里，api_key_env是指 API 密钥从环境变量HY4_API_KEY读取，避免直接把密钥硬编码在配置文件中。timeout设成了 300 秒，因为视频生成通常不是实时返回结果，需要给模型预留足够的时间。

4.2 配置一个过山车视频 Skill

Skill 是 WorkBuddy 里复用能力的关键。你可以把过山车视频生成做成一个 Skill，以后每次调用都使用同一套提示词和参数，生产效果会稳定得多。

一个 Skill 可以简单理解为一个配置文件夹，里面至少包含提示词模板、模型参数、执行步骤。参考结构如下：

# workbuddy-skill/coaster-video/skill.yaml name: coaster-video description: 用 Hy4 预览版生成过山车视角视频 version: 0.1.0 model: hy4-preview params: duration: 8 resolution: 1080p fps: 24 steps: - build_prompt - call_h_y4 - check_result

这个配置里的steps不是代码，而是描述这个 Skill 的执行步骤：先把用户输入和模板拼成完整提示词，然后调用 Hy4 生成视频，最后检查生成结果是否满足要求。不同版本的 WorkBuddy 对 Skill 的格式要求可能不同，但“模板 + 参数 + 步骤”的思路是通用的。

4.3 上下文管理配置

既然社区里大家都在问“WorkBuddy 上下文用量满了怎么办”，说明上下文管理是实际使用中的高频问题。从工程角度看，核心做法是“一次任务只保留和该任务相关的上下文”：

不要在同一个会话里无限叠加多个视频生成任务；
过长的产品需求文档，建议先做一次摘要，只保留与本次生成相关的关键信息；
每次生成完成后，把成功和失败的结果记录到外部文件，而不是留在会话记录里；
如果 WorkBuddy 支持重置会话，遇到上下文满时可以直接新建一个任务。

5. 单次生成过山车视频的完整流程

5.1 第一步：设计提示词

过山车视频的提示词，不建议写成一长串没有结构的描述。更好的做法是分块描述：

提示词模块	作用	示例
主体	描述过山车列车外观	红色过山车列车，流线型车身，车窗反射阳光
轨道与场景	描述行驶环境和轨道结构	陡峭钢制轨道，穿过山谷、岩洞和木质塔架
镜头	描述摄影机运动	车头前方的跟踪镜头，高速推进，模拟第一视角
光影	描述光线和氛围	下午金色阳光，轨道阴影快速掠过
画幅与风格	描述输出风格	电影感摄影，运动模糊，高对比度，4K质感

对应到实际提示词，可以写成下面这样，直接粘到 WorkBuddy 的对话输入框里：

请使用 Hy4 预览版生成一个过山车视频片段。 主体：一列红色过山车列车，流线型车身，车窗反射下午的阳光。 轨道场景：列车行驶在陡峭的钢制轨道上，轨道穿过山谷、岩洞和木质塔架，远处有山峦和森林。 镜头：车头前方的跟踪镜头，保持高速推进，仿佛坐在第一排座位拍摄。 光影：下午时刻，金色阳光从侧面照射，轨道的阴影快速掠过车身。 风格：电影感摄影，轻微运动模糊，高对比度，画面细腻真实。 输出要求：单次生成一段 8 秒视频，1080p 分辨率，24 帧每秒。

这个提示词把过山车这个复杂场景拆成了五个维度，让模型知道它需要同时处理“主体、场景、镜头、光影、风格”，而不是只听到“过山车”三个字。

5.2 第二步：在 Skill 中填入参数

如果已经在 WorkBuddy 中创建了coaster-video这个 Skill，可以在调用 Skill 时，把步骤 1 的提示词作为输入参数传进去。WorkBuddy 会读取 Skill 中预设的模型参数，生成时统一使用 Hy4 预览版。

一个值得注意的点是：预览版模型往往会对分辨率、时长、帧率有上限限制。不要一上来就设置 4K、60 帧、30 秒，先按官方默认参数跑通，再逐步增加难度。否则画质够高但生成中断，反而浪费上下文和配额。

5.3 第三步：启动生成并监控状态

在 WorkBuddy 对话界面发起生成后，任务的执行过程通常会分为这样几个阶段：

[1/4] 正在解析提示词 [2/4] 正在调用 Hy4 预览版生成视频 [3/4] 正在检查生成结果 [4/4] 生成完成，输出视频文件

其中第 2 步耗时最长，因为视频生成需要逐帧推理。如果任务卡在“正在调用 Hy4”超过较长时间，先看 WorkBuddy 的日志面板，确认是网络超时、模型负载过高还是配额不足。

5.4 第四步：检查输出

生成完成后，WorkBuddy 会返回一个视频文件路径。在项目里使用这个文件前，最好先做一次基础校验，确认它不是你抽卡抽出来的“意外产物”。

6. 示例配置与代码实现

6.1 通过 Python 调用视频生成 API

如果你的 WorkBuddy 版本支持把模型能力暴露成 API，那么也可以用 Python 写一个脚本，在项目里直接调用。下面是一个演示性质的通用请求结构：

import os import requests # 从环境变量读取密钥，不要硬编码 api_key = os.environ["HY4_API_KEY"] url = "https://api.example.com/v1/generate" payload = { "model": "hy4-preview", "prompt": ( "红色过山车列车行驶在陡峭钢制轨道上，" "穿过山谷和岩洞，车头前方跟随镜头，" "下午金色阳光，电影感摄影，运动模糊。" ), "params": { "duration": 8, "resolution": "1080p", "fps": 24 } } headers = { "Authorization": f"Bearer {api_key}", "Content-Type": "application/json" } resp = requests.post(url, json=payload, headers=headers, timeout=300) if resp.status_code == 200: result = resp.json() video_url = result.get("video_url") or result.get("output") print(f"生成完成，视频地址：{video_url}") else: print(f"生成失败：{resp.status_code} {resp.text}")

这段代码体现了两个工程原则：第一，密钥从环境变量读取，不提交到仓库；第二，对耗时较长的视频生成任务设置足够的超时时间。实际使用中，API 的域名、请求路径、返回字段都会因版本而异，需要以 WorkBuddy 当前版本的接口文档为准。

6.2 用 ffprobe 检查生成视频

拿到视频文件后，可以用 ffprobe 检查它是否满足我们要求的时长、分辨率和帧率。这个工具是 FFmpeg 自带的，在命令行里可以直接使用：

ffprobe -v error \ -show_entries format=duration,size \ -show_entries stream=width,height,r_frame_rate \ -of json output_video.mp4

如果输出结果里duration接近 8 秒，width和height是 1920x1080，r_frame_rate是 24 左右，说明文件本身基本符合预期。

6.3 工作流配置：把视频生成变成自动化任务

如果想把“生成过山车视频”变成团队可复用的自动化流程，可以在 WorkBuddy 中把 Skill 和一个外部任务调度器接起来。例如，可以写一个简单的脚本，从需求文档中提取关键词，自动组装提示词，再调用 WorkBuddy 的接口触发任务：

# 从需求文档中提取关键词并触发 WorkBuddy 任务 # 这里用 workbuddy-cli 演示，具体命令以当前版本为准 workbuddy-cli skill run coaster-video \ --input "从 doc/shot-list.md 中读取过山车镜头需求" \ --model hy4-preview \ --output ./outputs/

类似这样的命令可以把视频生成接入到已有的内容生产线中，而不是每次打开图形界面手动点操作。

7. 运行结果与效果验证

7.1 判断生成成功的标准

判断一次生成是否成功，不能只看“有没有出片”。建议按以下四个层次检查：

第一层，文件层。视频文件存在，时长、分辨率、帧率符合设置。这里用 ffprobe 校验最稳妥。

第二层，视觉层。画面里过山车列车是否保持同一造型，没有在运动过程中突然变形；轨道和列车的位置关系是否稳定；远近景的相对运动是否符合透视。

第三层，镜头层。镜头是跟随列车的，还是固定在轨道旁。如果提示词要求“车头前方跟踪镜头”，但输出变成了侧方固定机位，说明模型没有正确理解镜头意图。

第四层，光影层。下午金色阳光这个条件，如果生成出来变成阴天或夜景，说明光影描述没有生效，需要在后续提示词里强化光线关键词，比如“阳光高角度照射，轨道影子清晰”。

7.2 预期输出参考

以过山车场景为例，一次比较理想的 Hy4 预览版输出应该是这样的：

- 文件格式：MP4 - 时长：约 8 秒 - 分辨率：1920 x 1080 - 帧率：24 fps - 内容：红色过山车列车从轨道高点向下俯冲，镜头在前方跟随， 列车穿过山谷和岩洞，阳光在车身表面留下流动的反光

如果在实际运行中某个维度不达标，优先调整提示词对应模块，而不是盲目修改整个提示词。

7.3 如果失败，先看哪里

按下面的顺序排查，能省不少时间：

看 WorkBuddy 执行日志，确定失败发生在哪一步；
如果日志显示超时，检查模型调用超时时间是否足够；
如果提示上下文用量满，清理会话历史后重试；
如果提示无权限或额度不足，检查 Hy4 预览版权限和兑换码状态；
如果提示词问题，先跑一个更简单的视频生成任务，验证模型通路是否正常。

8. 常见问题与排查方法

结合社区里讨论较多的问题，整理成下面这个排查表：

问题现象	可能原因	排查方式	解决方案
提示上下文用量已满	会话历史过长，占满上下文窗口	查看 WorkBuddy 的上下文占用面板	清理历史记录、重置会话，或把任务拆成多个短会话
WorkBuddy 无法启动	操作系统版本过低，如 Windows 7	检查系统要求和启动日志	升级到受支持的操作系统版本
兑换码输入无效	活动限制、已过期或大小写错误	核对活动规则和输入内容	复制兑换码原文，确认未过期，必要时联系客服
生成的视频总是中断	超时时间过短、配额不足	查看日志和配额页面	增大 timeout 参数，检查模型调用额度
ComfyUI 工作流导入失败	WorkBuddy 与 ComfyUI 版本不兼容	对比两个工具的版本号	升级 WorkBuddy 或 ComfyUI，重新导出工作流
API 接入后无法调用	密钥错误、密钥未写入环境变量	检查环境变量和请求日志	重新配置环境变量，确认密钥有对应模型的调用权限
生成结果没有运动效果	提示词中缺少镜头运动描述	检查提示词中镜头模块	明确写“车头前方跟踪镜头”“高速推进”等关键词
过山车车身变形	模型对高速运动下的主体一致性控制不足	观察具体哪一帧开始形变	降低运动速度，或改用更稳定的运镜方式

这些问题是工作中台类工具的通病。很多问题不是模型能力不足，而是上下文管理、环境兼容性或工程配置出了问题。

9. 从“单次生成”到工程化使用的最佳实践

9.1 把提示词当成代码管理

过山车视频提示词一旦调通，就应该把它保存到版本库里，而不是留在 WorkBuddy 的对话记录中。提示词的命名也很重要，不建议叫good_prompt.txt或最终版.txt，而是要有明确的版本语义：

prompts/ coaster_video/ v0.1_baseline.md v0.2_add_lighting.md v0.3_first_person_camera.md

这样回头能看出版本演化过程，也方便在团队里讨论。

9.2 用 Skill 沉淀可复用流程

一次生成成功，不代表这个能力属于你。真正有工程价值的是，把这次经验沉淀成 Skill，让团队里的其他人都能调用。

Skill 包含三个核心：提示词模板、模型参数、执行步骤。当这次过山车视频的提示词被验证稳定后，可以把它从“对话里的文本”升级为“Skill 里的模板”，模型参数也固定下来。这样后续做“过山车二段”“过山车夜景版”“木质过山车版”时，只需要改场景模块，其他部分保持不变。

9.3 合理管理上下文和缓存

上下文满的问题，本质上是“把工作台当记事本用”。更高效的做法是：

每个生成任务独立成会话，任务结束就关闭；
成功的视频路径、失败的参数组合，记录到外部文件；
大段参考文档只保留摘要，不要全文塞进上下文；
有条件的话，把中间产物放到磁盘缓存，而不是全部留在会话里。

9.4 安全边界与团队协作

使用 WorkBuddy 接入 Hy4 时，需要把安全边界想清楚：

API 密钥只保存在环境变量或密钥管理服务中，不进入代码仓库；
团队共享 WorkBuddy 时，划分好不同成员的操作权限；
涉及公司素材或未公开项目时，不要使用外部模型做生成，避免数据流出；
生成视频如果不满意，可以直接丢弃，但不要反复用同一段错误消息覆盖日志，否则会干扰排查。

9.5 不要把预览版直接用于生产

Hy4 是预览版，所以它的接口、生成效果、配额政策都可能调整。对于一次实验无所谓，但如果你打算把视频生成接入生产流程，建议做一层适配：

class VideoGenerator: def __init__(self, model="hy4-preview"): self.model = model def generate(self, prompt: str, duration: int = 8) -> str: # 这里的实现需要对接实际的生成接口 # 假设返回视频文件路径 video_path = self._call_generate_api(prompt, duration) return video_path

这层封装的意义在于：未来如果 Hy4 预览版升级，或者需要替换成其他模型，只需要修改这一个类，不需要改动所有调用方。

10. 总结与后续学习方向

通过“Hy4 预览版经 WorkBuddy 单次生成过山车视频”这个案例，本文真正讲清楚了四件事：

第一，视频生成的难点不只是模型，还需要工作流。WorkBuddy 通过模型接入、Skill 和上下文管理，把视频生成从一次性操作变成了可复用流程。

第二，过山车场景是很有价值的测试用例。它能暴露模型在运动一致性、镜头控制、光影变化上的真实水平，适合用来评估 Hy4 预览版。

第三，工程化使用时，要把提示词模板、模型参数、上下文管理、密钥安全这些环节都管起来，而不是只盯着“出片效果”。

第四，预览版意味着不确定性。本文里的接入方式、参数字段都是通用演示，不是固定的生产配置。真正上手时，以你当前版本的官方文档和实际界面为准。

接下来，如果你想继续深入，可以把这些方向作为下一步：

跑通一次过山车视频生成，记录成功和失败的边界条件；
把这个提示词和参数沉淀成自己的第一个 WorkBuddy Skill；
尝试把 WorkBuddy 接入 ComfyUI，组合出更复杂的视频处理流程；
把视频生成接口封装成团队内部服务，让后端系统也能调用。

这篇文章适合先收藏，等你要尝试 WorkBuddy 和 Hy4 预览版时，再拿出来对照执行。你在跑这个过山车场景时遇到最奇怪的问题是什么？欢迎在评论区一起排查。