Hy4 预览版加 WorkBuddy单次生成过山车视频。这个组合最值得关注的地方不是“AI 能生成视频”这个结果而是从一句提示词到一段完整动态影像整个链路可以被一个工作台完整接住。试过之后我更在意另一件事WorkBuddy 在这个过程中到底做了什么。如果只是把 prompt 发给模型那随便一个对话窗口都能完成。真正有差异的是任务记录、参数管理、输出位置和后续批量扩展这些看起来不起眼的部分。这篇内容适合两类人看。一类是刚拿到 Hy4 预览版、想用 WorkBuddy 做完整视频任务的人另一类是想把 AI 视频生成从“偶尔玩一次”变成“可复用工作流”的人。如果你只是想要一段过山车视频那直接用一句简单的 prompt 就够了。如果你想每次都知道为什么成功、为什么失败WorkBuddy 这类工作台的重点就在后面那些容易被忽视的细节里。1. 先确认 Hy4 预览版和 WorkBuddy 各自负责什么1.1 Hy4 预览版真正要解决的是哪种生成需求从项目标题看Hy4 是一个预览版的视频生成能力。它要解决的核心动作是“输入描述输出视频”。过山车这个测试主题选得不算随意。它包含高速运动、镜头跟随、轨道翻转、场景透视、速度感传递这些对视频生成模型来说都是压力项。能在一个片段里稳定处理这些动态元素说明模型对镜头运动和物理变化的控制力不错。“预览版”三个字要尤其注意。预览版意味着功能基本成型可以拿出来试但不代表已经达到正式版的质量和稳定性。我在跑这类版本时不会默认它一定会一次成功。我会把它当成一个“可以验证思路但不能直接当生产工具”的阶段。如果你的使用场景是给客户交付视频或者做固定风格的连续内容那就必须在小批量测试里记录成功率和输出一致性再用结果决定能不能扛住正式需求。基于标题和搜索材料来看Hy4 预览版的具体版本号、发布时间、支持参数在原始材料里没有给出。所以我不会去猜某个固定参数一定有效。我更建议你拿到的第一时间先把默认设置跑一遍再用自己的 prompt 做对照。1.2 WorkBuddy 更像任务编排层不是模型本身WorkBuddy 在这条链路里不是生成模型也不是滤镜工具。它更像一个编排层。模型是引擎WorkBuddy 是驾驶舱。你在 WorkBuddy 里组织 prompt、选择要调用的模型版本、提交任务、观察执行状态、查看日志、管理输出文件。为什么需要这一层因为生成一段视频往往不是一次对话就结束。你需要记录这次用的是哪一版模型、seed 是多少、分辨率多少、prompt 原文是什么、输出文件放到了哪里。如果这些信息散落在不同地方后面想复现会非常痛苦。工作台的价值是把一次“生成动作”变成一条“可追踪的任务记录”。从搜索热词里可以看到很多人关心 WorkBuddy 怎么使用、怎么安装、和 CodeBuddy 有什么区别。这说明大多数使用者和我一样一开始并不清楚它归属于哪类工具。我的判断是CodeBuddy 更偏向代码场景WorkBuddy 的任务范围更宽可以容纳办公、内容生成、接口调用、脚本辅助等任务。但具体功能差异还是要以官方文档和实际安装后的能力清单为准不能靠名字猜。1.3 搜 WorkBuddy 时最常出现的三个疑问搜索材料里反复出现几类问题我把它们归成三类这也是新手最容易卡住的地方。第一类是安装。安装的问题通用做法是先确认操作系统版本、系统位数、磁盘空间和网络条件。不要跳过环境检查直接解压否则后面报错时你会分不清是安装问题还是生成问题。第二类是上下文用量满了怎么办。这是高频问题。上下文满了不是模型坏了而是工作台在一个会话里堆积了太多历史信息。处理思路很简单新开一个会话清理历史记录精简 prompt把长文档从对话输入变成模板引用。后面我会专门说这部分。第三类是 WorkBuddy 和 CodeBuddy 的区别。这类问题不需要在安装前纠结。如果你主要用来做视频生成、内容编排、日常任务管理先以 WorkBuddy 为主线。如果你主要是写代码、调接口再看 CodeBuddy 是否更贴合。工具可以切换但你自己的任务清单和模板才是核心资产。注意如果你看到搜索词里有“基金”“比赛”“变现”这类内容那和工作台本身的生成能力没有直接关系更接近运营活动或营销说法不建议作为判断工具好坏的依据。2. 跑一次生成之前把环境、模型和目录先理清楚2.1 运行环境客户端、系统版本和网络条件视频生成对资源的敏感程度比纯文本生成高很多。如果你是用本地模型跑显存、内存、磁盘都会直接影响结果。显存不够时不一定会直接报错可能是速度极慢、任务卡住、输出黑帧、甚至中途退出。如果你通过 API 调用本地资源压力会小很多但要关注配额、延迟和费用。我一般开始前会先顺手确认三件事一是操作系统和客户端版本是否匹配二是模型目录或 API 配置是否就位三是输出目录有没有建立。不要等生成到一半才去补这些中途操作很容易让任务失联。搜索材料里也有人问 Windows 7 能不能用 WorkBuddy。这个问题我不给绝对结论因为是否支持取决于官方客户端的兼容策略。旧系统确实可能因为运行库、浏览器内核或安全协议无法加载新版客户端。最稳妥的办法是在一个可运行的环境里先做验证不要因为安装不上就认为模型本身有问题。2.2 模型接入在线 API 和本地模型怎么选Hy4 预览版如果走在线 API好处是配置简单不需要本地高配显卡适合快速验证 prompt 和流程。需要留意的是请求是否带重试机制、超时时间设置多长。如果一次生成要几十秒甚至几分钟前端一定要有耐心等待的预期不要反复点击提交。如果本地跑模型就需要认真算资源账。低配置环境不是不能跑而是要把分辨率、时长、帧数降下来。先跑一个短片段确认链路通了再慢慢加码。不要一上来就按最高画质跑那是把单次验收变成资源压力测试。在 WorkBuddy 里接入模型时有一条原则先确认当前任务到底用的是哪个模型版本。因为工作台可能同时管理多个模型如果直接沿用上一次的选择可能出现“我以为在跑 Hy4 预览版实际还是旧模型”的情况。2.3 上下文用量和输出目录先处理再跑任务上下文用量是工作台类工具最容易被小看的问题。对话式界面会让人误以为这是一个无限聊天窗口。实际上模型和编排层能承载的历史信息是有上限的。如果你在同一个会话里堆积了很多轮讨论、贴了大量文档、反复修改 prompt上下文很快会满。满了之后的现象很典型任务提交后没有反应或者开始回答但内容偏题或者直接提示上下文超限。处理顺序是新开一个会话把当前任务独立出来。精简 prompt只放生成所需的必要描述。把长文档从对话输入改成模板引用让工作台从外部读取。让轻量模型承担计划、整理类任务把生成动作留给 Hy4 预览版。输出目录也要在任务开始前确定。我习惯建一个带日期和任务名的目录例如output/hy4_20250120/roller_coaster/。文件名建议带上任务名、模型版本、seed 和日期比如coaster_v1_hy4pre_seed1001_20250120.mp4。这样就算跑几十个任务也不会出现“一堆视频文件不知道谁是谁”的情况。3. 单次生成过山车视频的完整操作流程3.1 prompt 怎么写过山车视频不能只写“过山车”很多人第一次生成失败不是模型能力问题是 prompt 太笼统。“生成一段过山车视频”这句话信息量太低了。模型不知道你要的是第一视角还是第三视角不知道轨道是钢管还是木头不知道场景是山景、海边还是城市不知道光线是白天还是黄昏更不知道镜头是先加速还是先俯冲。我把过山车视频的 prompt 拆成五块视角、轨道动作、场景、光源和风格、时长。每个部分都写清楚模型才有一个可执行的描述。下面是一段示例 prompt不是标准答案只是给一个拆解思路第一视角过山车视频镜头沿钢制轨道高速前进。 先缓慢爬坡在顶点短暂停顿后急速俯冲再经过一段螺旋翻转最后穿过木质缓冲段。 场景为山谷间远处有雪山近处轨道两侧是松林和岩石。 光线明亮晴天画面清晰运动流畅。 时长 4 秒。这段 prompt 的好处是动作顺序明确爬坡、停顿、俯冲、翻转、穿过。这样后续检查视频时你可以针对每一步判断模型有没有忠实执行。如果只看“过山车”三个字输出千奇百怪也说不清是哪里错了。3.2 在 WorkBuddy 里提交任务打开 WorkBuddy 后新建一个任务或会话先确认模型选择。如果你能看到模型下拉列表就选择 Hy4 预览版如果支持多个版本还要确认是不是预览版对应的服务地址。第一次测试不追求完美只验证链路通不通。把 prompt 粘贴进去后提交任务然后观察执行状态。我建议盯两个地方一个是任务是否进入排队或执行中另一个是日志里有没有出现错误信息。不要急着看视频好不好看先确认成功生成这个动作本身。如果 WorkBuddy 支持 skill 或自定义流程可以把“过山车视频生成”封装成固定操作。封装以后你只需要填场景、轨道类型、时长等几个变量工作台会自动拼好完整 prompt 并提交。这一步是后面做批量任务的基础第一次手动跑通之后再封装。3.3 单次生成的默认参数建议生成视频时不同模型对参数的支持情况不一样。下面这张表给的是通用参考具体数值以你的实际环境和模型版本为准。参数作用建议分辨率影响画面清晰度和资源占用先用默认显存或网络压力大时降低时长/帧数决定视频长度和生成耗时先跑 4 秒以内验证链路和效果步数影响生成质量和耗时默认起步卡顿或模糊再调整seed控制随机性固定 seed便于复现同一段结果CFG/提示词强度控制 prompt 的跟随程度过高可能画面过度扭曲过低可能跑题我习惯先固定 seed然后再调 prompt。这样每次改动都能看出是 prompt 变了还是纯随机变了。如果第一次生成效果不错记录下这组参数它就是一个可以复用的起点。3.4 输出检查先看文件再看画面最后看一致性生成结束后不要只看预览播放器。我先去输出目录看文件是否存在、大小是否异常。一个 4 秒视频如果只有几 KB大概率是失败或者内容损坏。文件正常之后再播放看画面。重点看运动是否流畅镜头是否沿轨道前进俯冲段有没有速度感螺旋翻转有没有明显的闪变或变形。最后回到 prompt 逐项对照prompt 说先爬坡再俯冲视频里是不是这个顺序prompt 说晴天画面是不是真的明亮。如果视频生成失败先看日志不要重复提交同一条任务。如果视频生成了但效果不好改 prompt 和参数不要盲目堆高分辨率。运行环境不够时高分辨率只会放大问题不会提升效果。4. 单次跑通之后再决定要不要往批量方向走4.1 单次成功不等于批量稳定这是我在实测中体会最深的一点。单次成功只能说明链路是通的不能说明 10 个任务都能稳定成功。批量任务会遇到单条任务完全没有的麻烦连续提交把上下文撑满、输出文件命名重复、某个中间任务失败导致后续混乱、资源被连续占用后速度越来越慢。我建议按这个节奏来先跑 1 条确认输入、输出、日志都正常。再跑 3 条检查并发或连续执行的稳定性。最后才考虑扩大到 10 条以上。不要一开始就跑最大批量那样一旦出问题你很难判断是哪一环坏了。4.2 批量任务的三种前置准备做批量前至少准备三样东西。第一是模板。把 prompt 里会变化的部分抽出来。比如轨道类型、场景、视角、时长。固定部分像“镜头流畅”“画面清晰”可以保持不变。第二是命名规范。建议按“任务名_序号_模型版本_seed”来命名。这样即使生成顺序乱了你还能通过文件名把结果对应回 prompt。第三是失败重试策略。想清楚某个任务失败后是跳过继续下一个还是原地重试三次。如果跳过失败的任务必须有单独记录避免最后漏掉一批没生成。下面是一个可复制的模板思路[视角]第一人称 / 第三人称跟拍 [轨道结构]钢制轨道 / 木质轨道 / 螺旋段 / 俯冲段 [场景]山景 / 海边 / 城市 / 森林 [运动节奏]缓爬坡 - 顶点停顿 - 急速俯冲 - 螺旋翻转 [光源与风格]白天 / 黄昏 / 霓虹风格 [时长]4 秒批量时只需要替换方括号里的内容避免每次都从头组织一段完整自然语言。4.3 重试、日志和资源占用怎么盯批量任务跑起来之后真正需要盯的是三类信号任务状态、日志文本、资源占用。任务状态决定整体进度日志文本告诉你失败原因资源占用帮你判断是继续加任务还是先停下来。比如连续跑多个视频生成任务后如果发现速度明显变慢不要急着优化 prompt先看是不是显存或内存不够。工具无法在物理资源不足的情况下靠参数提高稳定性。如果 WorkBuddy 的上下文用量开始涨高那就主动断掉这个会话新建一个再继续。把已经成功的 prompt 模板、参数和 seed 记录到外部不要全部堆在会话里。这样清理上下文时你不会丢失关键信息。注意批量任务里看到一次报错先想“这是单条输入问题还是整个链路问题”。处理方式完全不同。单条问题改输入链路问题改配置或资源。5. 容易踩的坑和一套可复用的排查顺序5.1 现象一任务提交后没有反应这是最常见的坑。任务提交后转了一圈没有输出也没明显报错。很多人第一反应是重新点一次提交实际上这样做只会制造更多重复任务。优先检查顺序如下任务是不是真的提交成功了看执行状态。网络请求是否正常API 配额是否用尽。模型版本是否可用是不是选了不存在的模型名。输出目录有没有写入权限。日志面板里有没有被忽略的错误。报错不一定是模型问题。路径不对、权限不够、API Key 失效、模型名写错都会造成“看似没反应”。先看日志再改参数。5.2 现象二视频模糊、闪烁或运镜不对如果任务成功生成但画面质量不行先不要急着怀疑模型。先做四步对照把分辨率、时长调低跑一个短片段排除资源不足导致的花屏和丢帧。修改 prompt 里的动作描述不要用“快速飞驰”这种太虚的词改用“先爬坡再俯冲再螺旋翻转”这种有阶段的描述。清理上下文重新生成。有时候是上下文太杂模型被前面的历史影响。固定 seed把当前版本和之前效果较好的版本做对比。如果还是不行再考虑提高步数或调整 CFG 强度。但要注意调高 CFG 不等于一定更好。提示词强度过高画面可能出现过度扭曲、边缘发虚、色彩饱和过重的问题。5.3 现象三上下文用量满导致任务中断上下文用量满是工作台类工具最容易遇到的问题。判断标准很简单如果同一个会话里已经聊了很多轮或者贴了大量文本提交新任务时可能直接提示超限。处理方式新开一个会话把当前任务独立出来。把 prompt 精简到只保留当前生成所需的信息。把长文档从对话输入改为模板引用不要全文粘贴进对话。如果工作台支持子任务或轻量模型把计划、总结类的工作分离出去让生成模型只负责生成。这个方法能解决大部分“上下文满了怎么办”的问题。真正需要注意的是在上下文快满的时候不要反复重试同一条任务。那样只会让已满的会话压力更大。5.4 统一排查顺序把上面的经验汇总成一张表适合贴在你自己的工作台旁边。现象优先检查处理方式任务无反应任务状态、网络、API 配额看日志不要重复提交视频模糊/闪烁分辨率、时长、seed调低参数做对照运镜不符合 promptprompt 动作顺序拆成阶段性描述上下文用量满历史消息、会话轮次新开会话精简 prompt找不到输出文件输出目录路径、权限检查目录和命名规则速度越来越慢显存、内存、存储占用降低批量并发释放资源排查时永远遵循一个顺序现象 → 输入 → 环境 → 参数 → 工具版本。不要跳过输入和环境的检查直接去改参数。很多问题看起来像模型能力不够实际是输入格式不对或者资源不够。6. 把这次实测沉淀成可以反复使用的工作流6.1 把提示词变成可替换参数的模板一次成功的生成不值得高兴太久。真正值得保留的是这次迭代里沉淀出的参数组合。我把过山车视频的 prompt 存成模板之后换主题只需要改几个变量。模板要包含三部分固定描述、变量字段、参数快照。固定描述保证基本风格稳定变量字段让不同任务可以切换场景参数快照记录分辨率、时长、seed、模型版本。这样下次任何一个环节出问题你都能回到一个已知的成功点。6.2 工作台里值得沉淀的周边任务生成视频本身只是第一步。后续还可能有内容整理、视频转 GIF、素材归档、效果对比。这些工作如果每次手动做会非常零散。像 WorkBuddy 这类工作台可以承担一部分周边整理工作比如把生成记录归档成文本、把优秀 prompt 存入模板库、把失败案例单独记录。我会建议把“失败案例”也保留下来。失败案例比成功案例更有参考价值。你记录“分辨率太高导致任务中断”和“CFG 调太高导致画面扭曲”下次遇到类似现象就能快速定位。6.3 和 ComfyUI、VS Code、Obsidian 的常见组合思路搜索热词里出现了 workbuddy comfyui、workbuddy vscode、workbuddy obsidian 这些组合说明很多人已经在尝试把工作台接到其他工具里。从组合思路上看分工通常是这样ComfyUI 负责复杂节点流程。如果你有固定的视频后处理工作流可以让 WorkBuddy 管任务入口和记录ComfyUI 管具体节点执行。关键是两边的输入输出目录要一致否则任务状态和文件路径容易对不上。VS Code 适合代码和脚本场景。如果你想生成多个 prompt 文件或者批量整理日志可以借助脚本完成。WorkBuddy 负责整体任务调度VS Code 处理文本和脚本。Obsidian 适合做知识沉淀。把 prompt 模板、参数笔记、成功案例、失败案例放进笔记库形成你自己的生成手册。后续写方案或调优时不需要重新摸索。这些组合方式取决于官方集成程度不要默认某个功能一定能用。实际操作前先确认工作台是否支持对应扩展、插件或外部调用能力。6.4 什么时候用预览版什么时候等正式版预览版适合学习和测试。用来验证 prompt 思路、测试模型风格、跑通工作台流程都没有问题。但如果你要交付给客户或者做一批需要在内容风格上严格一致的视频就要先做小批量稳定性测试。测试时记录下来每组任务的成功率、平均耗时、失败原因、最终效果。如果连续几次测试稳定再考虑用它承载正式任务如果失败率偏高就要等模型更新或换用正式版本。单次生成过山车视频只算是把链路打通的第一步。真正值得留下来的是你在这个过程里整理出的 prompt 模板、参数记录和排查顺序。下次你想换个场景把山景改成海边把木制轨道改成钢制轨道只需要改几处变量而不是从头再试一遍。预览版可以玩但要把它用进正式任务还是先把默认配置跑稳再考虑放大规模。