企业官网建设流程全解析

我有个做短视频的朋友，见我最近在搞AI短剧，最常问的一句话是：你是不是每天都蹲在电脑前，一条一条点生成？我跟他说，我现在基本不手工点ComfyUI了，本机ComfyUI负责视频帧生成和批量出图，WorkBuddy则是那个调度台，把从剧本到成片的全流程编排成自动任务，我晚上丢一批分镜进去，第二天直接收片。这篇文章就是把这条流水线的搭建过程、耗时实测数据，以及我踩过的几个坑完整记录下来。对已经装了ComfyUI但还在手动出图的同学，或者想用AI批量做短视频切片的朋友，应该很有参考价值。

先说结论：这套方案的边际成本确实趋近于零，但它的价值不在"省钱"，而在把AI短剧的视频生成从手动一件件加工变成可追踪、可批量、可复用的生产流程。

1. 为什么我决定用 WorkBuddy 调度本机 ComfyUI

1.1 短剧出片的真实痛点：不是生成难，是批量难

单条AI视频生成，现在任何一个会用ComfyUI的人都能做到：拖一个工作流，填一段提示词，点运行，等画面出来，保存。但这个操作放到短剧场景里就完全不够用了。短剧不是一两个镜头，而是几十个分镜、多个主要角色、统一的场景风格、连续的情节推进。每条切片都要重复加载工作流、改提示词、点运行、等结果、找输出文件、手动归档重命名，这一套动作做二三十次，效率极低不说，人还特别容易疲劳，而且一旦有一张图忘了改配置，整批风格就崩了。

我最初也想过直接用Python脚本去调用ComfyUI的API，把工作流批量提交。但做到一半发现，纯脚本方案要处理一堆和生产调度相关的细节：提示词需要按场景结构化维护，任务失败之后怎么筛选重试，中间产物怎么按分镜目录归档，不同模型之间的调用顺序和依赖关系怎么控制。这些问题本质上是"流水线管理"问题，不是"图像生成"问题。用WorkBuddy这类Agent工作台来处理调度，比自己维护一套任务管理系统顺手得多，因为它的skill机制天然适合把"调用ComfyUI出片"封装成一个可复用的动作，再配合其他AI能力做分镜拆解和提示词优化。

1.2 WorkBuddy 和 ComfyUI 的分工边界

很多人一听到"用WorkBuddy调度ComfyUI"就觉得是把ComfyUI替代了，其实完全不是。这两者解决的问题不同，边界也非常清晰：

• ComfyUI是本地执行引擎。它负责模型加载、图像生成、视频帧生成、批量渲染。它不是一个任务编排系统，而是提供了一套完整的HTTP API，允许外部程序把工作流以JSON格式提交进去执行。
• WorkBuddy是编排调度层。它负责理解用户意图、拆解任务、按顺序调用ComfyUI的API、轮询生成状态、失败重试、归档输出。这些事如果都在ComfyUI界面里手动做，就回到了最初的低效循环。

打个比方：ComfyUI像车间里一台功能很强的生产设备，WorkBuddy像车间里的生产管理看板。没有看板也能生产，但一旦进入批量生产，看板的价值立刻体现出来：什么任务在跑、什么任务失败、产出放在哪里，一目了然。

1.3 整条流水线的数据流

我的流水线大致是这样的数据流：

1. 把短剧剧本按场景切分，每个场景包含镜头描述、角色、台词、环境信息。
2. WorkBuddy读取这些场景描述，调用大模型把它转换成结构化的提示词JSON，包含正向提示词、负向提示词、分辨率、运动描述。
3. WorkBuddy把提示词填入预设的ComfyUI工作流模板，通过API提交到本机ComfyUI。
4. ComfyUI执行生成，产出关键帧或视频片段，写入指定输出目录。
5. WorkBuddy轮询任务状态，完成后读取结果，按"剧集/场次/镜头"的目录规则归档。
6. 所有片段通过ffmpeg合成完整的短剧切片，合并字幕和背景音乐。

这条链路里，WorkBuddy是整个流程的大脑，ComfyUI是双手。大脑负责任务决策和进度管理，双手负责把每一帧画面真正画出来。两者通过ComfyUI的API接口对接，不依赖任何云端服务，全部在本机完成。

2. 把 ComfyUI 改造成可被调度的本地服务

2.1 启动参数和API验证

ComfyUI默认启动方式适合人工界面操作：双击启动脚本，浏览器打开工作台，手动拖节点。但要让WorkBuddy调度它，第一步就是把ComfyUI变成一个可监听的本地服务。

我的启动命令是这样的：

python main.py --listen 0.0.0.0 --port 8188

这里有两个关键点。--listen 0.0.0.0让ComfyUI监听所有网络接口，而不仅仅是本地回环地址。如果只在本机跑，用127.0.0.1更安全；但如果你跟我一样有多台设备（比如笔记本负责调度、台式机负责渲染），就必须监听局域网地址。--port 8188是默认端口，也可以改成别的，只是后续WorkBuddy里的API地址要同步修改。

启动之后，验证API是否正常工作的最快方式，是直接访问http://127.0.0.1:8188/system_stats，能看到系统内存、显存、设备信息等JSON返回就说明API服务已经起来了。ComfyUI对外暴露的接口并不多，但每个都很好用：

• /system_stats：查看服务运行状态和硬件信息。
• /prompt：POST提交工作流，是核心接口。
• /history：查询历史任务和生成结果信息。
• /view：按文件名访问生成的图片或视频。
• /queue：查看当前队列状态。

2.2 批量任务下ComfyUI稳定性配置

批量出片和单次生成的配置思路差别很大。单次生成时显存不够可以等一下、调低分辨率再来；批量任务一旦跑到第三个任务时崩掉，前面两个就白跑了，所以稳定优先。

如果你的显卡显存小于16G，我建议启动时加上--lowvram，让ComfyUI在显存不足时自动把部分模型卸载到内存，虽然会增加加载时间，但能显著降低OOM概率。显存充足的同学（比如24G）可以不加，保持默认的高显存模式，速度更快。

另一个容易踩的坑是batch size。在ComfyUI里，一个batch size等于一次把多张图同时丢给模型计算。批量流水线里我们总希望一次多跑几张，但本地显卡的显存是硬约束。我实测过，在16G显存下用SDXL级别模型生成1080p图片，batch size设为2已经是上限，设成4大概率爆显存。更稳妥的做法是batch size保持1，通过外部并发队列来控制速度，而不是靠单任务内部去拼显存。

还要注意英伟达显卡驱动里的电源管理模式。默认情况下显卡可能不会主动跑满功耗，导致生成速度波动。在Windows下用nvidia-smi看一眼，跑任务时GPU利用率如果经常掉到80%以下，可以检查电源计划是否开启"高性能模式"，以及驱动设置里电源管理是否设为"最高性能优先"。

2.3 视频生成模型选择与中间产物设计

短剧视频生成目前主流做法是"先图后视频"：先用文本生成图像或关键帧，再做图生视频。ComfyUI里可选的开源方案不少，AnimateDiff、Stable Video Diffusion、以及各类新出的视频生成模型都支持。我的流水线里主要用两类模型组合：

1. 文生图模型负责生成场景主图和角色定妆图。这类模型拼的是首帧质量和风格一致性，短剧需要同一角色在多场戏里长得一样，所以角色图很重要。
2. 图生视频模型负责把主图变成动态片段。输入一张图，输出几秒钟的连续帧，运动幅度可以通过参数控制。

中间产物的设计直接决定流水线是否好维护。我的目录结构是这样的：

output/ series_name/ episode_01/ scene_001/ keyframe.png video.mp4 meta.json scene_002/ ...

meta.json是每个片段的元数据，记录模型、种子、提示词、耗时等关键信息。这段信息特别重要：一旦哪天出片风格不对，翻meta.json就能快速定位是哪一批任务的设置出了问题，不用靠脑子记。

3. WorkBuddy 里写 Skill：把"出视频"变成一个原子操作

3.1 Skill 的输入设计

WorkBuddy的skill机制，简单理解就是把一个可重复执行的动作包起来，给一个名字、一套参数、一段执行逻辑，之后就能像调用函数一样去使用它。我做的第一个skill叫generate_short_video_slice，输入参数设计如下：

• scene_id：场景ID，用于归档和命名。
• prompt：结构化提示词，包含主体、环境、光照、运动描述。
• negative_prompt：负向提示词，控制不想出现的内容。
• image_width和image_height：输出分辨率。
• frames：要生成的视频帧数。
• fps：帧率。
• seed：随机种子，控制生成结果的一致性。

这些参数看起来简单，但设计时有一个隐藏要求：提示词一定要结构化，不能是一大段自然语言。因为自然语言在批量任务里不可控，稍微改一个字，出图风格可能就飘了。我在WorkBuddy里配置了一个前置步骤，把剧本场景描述自动转成JSON格式的提示词结构，再传给出片skill。这一步虽然多花十几秒，却让后面的批量任务几乎不需要人工干预。

3.2 核心调用逻辑：提交 /prompt，轮询 /history

WorkBuddy调用ComfyUI的方式，本质上就是HTTP请求加轮询。先POST一个工作流JSON到/prompt接口，ComfyUI会返回prompt_id，之后WorkBuddy定时查/history接口，根据任务ID判断生成是否完成，完成后按输出文件名读取结果。

我写这段逻辑时遇到过不少坑，最后稳定版的核心部分大概是这个样子：

import json import time import requests COMFY_API = "http://127.0.0.1:8188" def submit_workflow(workflow_json, client_id="workbuddy"): payload = { "prompt": workflow_json, "client_id": client_id, } resp = requests.post(f"{COMFY_API}/prompt", json=payload, timeout=30) resp.raise_for_status() return resp.json().get("prompt_id") def wait_for_completion(prompt_id, timeout=1800): start = time.time() while time.time() - start < timeout: history = requests.get(f"{COMFY_API}/history/{prompt_id}", timeout=10).json() if prompt_id in history: item = history[prompt_id] status = item.get("status", {}) if status.get("completed"): return item.get("outputs", {}) if status.get("status_str") == "error": raise RuntimeError(f"任务失败: {status.get('messages')}") time.sleep(3) raise TimeoutError("等待超时")

这段逻辑有几个细节是实践出来的。第一，轮询间隔设在3秒左右，太短会给ComfyUI造成无效请求压力，太长则浪费等待时间。第二，/history/{prompt_id}这个带ID的路径很关键，比拉全量history再过滤要轻得多。第三，判断任务状态时不能只认completed字段，还要检查错误标志，ComfyUI任务失败时也会出现在history里，如果不加错误判断，WorkBuddy会把失败任务当成"还在跑"，一直傻等到超时。

3.3 排队、失败重试与断点续跑

批量任务的核心是控制并发。很多人的第一反应是同时提交10个任务给ComfyUI，让显卡一直满载。但本地ComfyUI的实现是队列机制，同时提交多个任务它们会排队执行，并不会并行，反而可能导致显存混乱。我实践下来的最优策略是：WorkBuddy里维护一个任务队列，同一时刻只提交一个任务到ComfyUI，完成后再提交下一个。并发度设为1，显卡稳定，单任务速度也不会因为显存竞争而下降。

失败重试也要设计。ComfyUI偶尔会在某个模型加载阶段抽风，或者因为显存临时不足报错。WorkBuddy里我给每个任务设了最多3次重试，每次重试前等待30秒，给显存释放留出时间。重试之前会把任务的meta.json更新为"failed"状态并存档，方便事后分析是模型问题还是参数问题。

断点续跑是我后期加的功能。最开始批量生成时，一旦断电或者手滑关掉电脑，前面跑完的任务结果全乱了，得分不清哪个完成了、哪个没有。后来我在WorkBuddy里加了一个简单的job_manifest.json，每次任务完成就往里追加一条记录，包含场景ID、输出文件路径、hash值。下次启动时先读取manifest，跳过已完成的任务，只跑未完成的。就是这个几十行逻辑的东西，让我的批量流水线真正变成了"睡一觉起来收片"的状态。

4. 耗时实测：每条短剧切片到底多久，成本到底多高

4.1 测试环境

先交代硬性条件，否则耗时数据没有参考意义。我的测试环境如下：

如果你的显卡比我弱或者强，耗时会有明显变化，但数据背后的规律是通用的：瓶颈始终在GPU推理，CPU和内存的影响相对小。

4.2 各环节耗时实测表

我选取了流水线上三个最核心的耗时环节做记录，每组任务跑10次取中位数：

实际跑下来，最耗时的是视频片段生成。以8秒240帧的输出规格来看，单段6到10分钟已经是比较理想的状态。这意味着一条剧情上有30个镜头的短剧切片，光是视频生成环节就需要3到5小时。如果只是出图没有问题，20张主图半小时以内就能搞定。

这里要提醒一点：耗时波动很大是正常的。我遇到过同一套参数，第一段视频8分钟，第二段突然变成12分钟的情况。排查下来不是参数问题，而是Windows后台服务和显卡温度导致的降频。跑批量任务时把无关的后台应用关掉，尤其是浏览器里的视频播放和动画渲染，性能会稳定很多。

4.3 跟云端API算一笔账

这套流水线最打动人的宣传点是"零成本"，这个词得拆开看。硬件成本是实打实的沉没成本，一次性投入在那里。但单条视频的边际成本确实趋近于零：只有电费。RTX 4080满载功耗大约320W，加上整机其他配件，跑一小时大概0.5度电，一天跑8小时就是4度电，按一般居民电价算，一天电费两块钱左右。这个成本和云端视频API按秒收费比起来，几乎可以忽略。

我算过一笔对比账：如果使用云端视频生成API，生成一段8秒视频的价格通常在几分到几毛钱不等，取决于模型和分辨率，批量生成100条切片，API费用就是几十到上百元。同样的量在本地跑，电费不到十块钱，而且显卡是一次性投入，用两年不回本也回本了。

不过"零成本"还有个隐性前提：开源模型的画质和可控性得能满足你的项目要求。如果非要商用级画质和复杂角色一致性，本地开源模型可能需要反复调优，这部分人工时间才是真正的成本。所以标题里的"零成本"我更愿意理解为"零边际成本"，硬件和调优精力不算在内。

5. 从搭建到量产，我踩过的坑和完整排查链路

5.1 显存OOM：批量任务跑到第三个就崩

第一次跑批量流水线，我信心满满地提交了10个视频任务，结果跑到第三个，ComfyUI直接报CUDA out of memory，整个服务进程崩溃，前两个已经生成完的片子还在，但第三个任务被卡在半路，WorkBuddy这边一直等不到完成信号。

排查过程是这样的：先看ComfyUI的控制台日志，发现有torch.OutOfMemoryError，说明任务崩溃发生在模型推理阶段，而不是参数配置错误。然后我用nvidia-smi观察显存变化，发现前两个任务结束后显存并没有完全释放，第三个任务提交时模型重新加载，瞬间显存峰值把16G打满了。

解决思路分两层。第一层是降低单任务显存占用，把视频生成的batch size从2降到1，同时开启--lowvram；第二层是延长任务间的间隔，WorkBuddy里每个任务完成后等待10秒再提交下一个，给显存温降和释放留缓冲。改完之后，连续跑20个任务再也没崩过。这个坑让我意识到，批量任务稳定性不是靠单点优化，而是调度节奏和硬件资源的整体配合。

5.2 WorkBuddy超时误报：轮询逻辑没写好

有一次批量任务跑到一半，WorkBuddy突然报超时，但我打开ComfyUI界面看，任务明明还在正常运行。排查后发现是我的轮询逻辑有问题：我最初用的是全量history接口获取任务状态，每次请求都返回整个执行历史，数据量越来越大，请求延迟从几十毫秒涨到几秒，最终超过了WorkBuddy内部设置的请求超时阈值。

我换成/history/{prompt_id}定向查询接口后，每次请求只返回一个任务的状态，延迟回落到几十毫秒，超时问题彻底消失。这个坑不算难，但它提醒我一个问题：当你想用工具调度另一个工具时，先把你依赖的API的细节吃透，不要想当然地用一个能跑的接口就完事。

5.3 角色一致性失控：种子和LoRA顺序

批量生成的另一个大坑是同一角色在不同镜头里长相不稳定。同一个提示词、同一个模型，两次生成的同一角色可能完全不像，这是因为每次生成的随机种子不同。流水线里如果不固定种子，角色一致性无从谈起。

我在WorkBuddy的skill参数里增加了seed字段，并设置默认值为固定数值（比如12345）。但固定种子只是第一步，更复杂的情况是使用LoRA模型时加载顺序会影响最终效果。ComfyUI工作流里如果同时加载多个LoRA，它们的权重生效顺序不同，画风会有微妙差异。我踩坑之后的做法是：把角色LoRA放在工作流固定位置，所有场景共用同一套LoRA排列顺序，不再手动调整。效果稳定之后，出片质量明显上了一个台阶。

5.4 断电断跑之后任务全丢：存档机制

这个坑几乎发生在所有做批量任务的人身上。某个晚上我挂机跑了30个镜头的生成，第二天早上起来发现夜里两点停电了，ComfyUI进程退出，WorkBuddy的任务队列也清空了。当时我没有任何记录判断哪些任务已完成，只能从头开始重新跑，白白浪费了半宿电。

后来我加了job_manifest.json存档机制，每次任务完成就写入一条完成记录，任务启动时先加载存档，自动跳过已完成场景。断电恢复后，只需要重新启动WorkBuddy，它会自动从断点开始继续跑，不需要人盯。这个机制可以说是整个流水线里性价比最高的一段代码：不到50行，却解决了批量任务最大的人为痛点。

6. 进阶方向与个人体会

6.1 多AI协作：把提示词优化也纳入流水线

流水线跑通之后，我开始把更多环节交给WorkBuddy自动处理。比如剧本分镜解析、提示词优化、负面提示词扩充，这些事情原本是我手动做的：先在别的地方写好提示词，再粘到任务参数里。现在WorkBuddy里配置了一个提示词优化skill，输入一段"夕阳下的两人对峙"这类口语化描述，输出完整的结构化提示词，并自动补充光线、镜头语言、风格修饰等细节。

这样一来，整条流水线变成了真正的多AI协作：WorkBuddy负责调度和任务管理，大模型负责文本理解和提示词生成，ComfyUI负责图像与视频生成。我只需要在开头丢进一个剧本，在中途偶尔查看产出质量，其余环节全部自动。这个体验和之前手动一条条生成相比，完全是两个时代的东西。

6.2 这套流水线的真实价值和个人体会

跑了一段时间后，我对这套方案有了几个比较深的体会。

首先，WorkBuddy调度ComfyUI这套组合，最核心的价值不是"省电费"，而是让AI短剧的视频生成从手工作坊变成了可追踪的流水线。每一条产出都有日志、有元数据、有归档路径，出问题能快速定位，迭代效果好，这才是生产级方案和玩具级方案的根本区别。

其次，本地批量生成的门槛并不低，硬件、模型调优、工作流编写、调度逻辑都要有基础。如果你只是想偶尔生成一段AI视频，完全没必要上这套流水线，直接ComfyUI手动操作就够了。当你开始频繁生成内容、一天要出几十条素材时，才值得投入时间把调度层搭起来。

最后想说的是，这套流水线目前还在持续迭代。我把视频片段合成、字幕生成、背景音乐匹配都纳入到WorkBuddy的后续编排里，下一步是让它能根据一个完整的短剧剧本，一次性输出一整集的视频素材。到那时候，AI短剧的生产效率还能再上一个台阶。

就我个人的实际体验来说，花一天时间把WorkBuddy和本机ComfyUI的调度链路跑通，是今年做AI视频内容最值得的一笔投入。别嫌配置麻烦，这套流水线一旦立起来，你手里就真正有了一台可以随时出片的本地工厂。