LibTV + ComfyUI：从零搭建AI漫剧工作流的完整教程

如果你最近刷短视频一定见过那种画面统一、剧情连贯、配音自然的 AI 漫剧。角色不飘脸、转场有逻辑、台词能对上口型看起来像一个小型动画工作室的产出。但当你自己去搜索怎么做的时候会发现信息极度碎片这边教你怎么用大模型写剧本那边教你用另一个工具生图再下一个视频教你剪辑配音中间没有任何串联。最后你手上攒了一堆软件却始终做不出一条完整成片。LibTV 的出现在很大程度上解决了这个断层。它不是某个单一功能的“出图工具”而是一套跑在 ComfyUI 生态里的 AI 影视工作流方案目标是把“剧本—分镜—画面—配音—剪辑”这条生产链路整合起来。这篇教程会从零开始把 LibTV 工作流的环境搭建、节点安装、模块拆解、完整运行、常见报错一次讲透。我会尽量把“为什么这么做”也讲清楚而不是只给你一串按钮位置。这篇文章适合三类人想入局 AI 漫剧但被 ComfyUI 各种概念吓住的新手已经在用 ComfyUI 出图画但不知道怎么把流程串成影视级产出的进阶玩家以及做 AI 短视频代运营、想批量做内容的团队。读完你应该能自己跑通一条“从文本到成片”的 LibTV 漫剧生产流程。1. 这篇文章真正要解决的问题先泼一盆冷水。很多人对“一键出 AI 漫剧”的理解是输入一个剧本电脑自己把视频吐出来。这个预期需要修正。至少在现阶段LibTV 工作流解决的不是“全自动生成”而是“把原本散落在十几个工具里的工序统一收编到一条可复用的可视化流程里”。没有这套工作流时你做一条 AI 漫剧大概要走这些步骤用大模型聊天窗口写剧本复制到 Word 里。根据剧本段落逐条去绘图工具里抽卡生图手动调整提示词保证角色一致。把几十张图下载下来再用图生视频工具逐张生成动态片段。用 TTS 工具为每句台词配音手动对齐时间轴。最后进剪辑软件把视频、音频、字幕、背景音乐拼起来。每一步单独看都不难但串联起来非常痛苦。尤其是角色一致性、画面比例统一、分镜数量和台词长度对应关系这三个问题靠手工操作几乎不可能高效解决而这恰恰是 LibTV 这类工作流最擅长处理的。LibTV 真正降低的是流程管理成本。它让你把剧本结构、画面描述、配音文本、分镜数量、输出路径全部结构化然后由工作流引擎按照固定逻辑去执行。改剧本时不需要重新生图换配音时不需要重新剪辑因为每个环节的输入输出都是独立的节点你可以单独替换、单独重跑。这篇文章后续会按下面的路径展开先解释 LibTV 和 ComfyUI 工作流的核心概念再讲环境准备和依赖安装然后逐模块拆解剧本、画面、配音、剪辑的配置方法最后给出一个完整可运行的示例流程和常见的报错排查清单。2. LibTV 是什么先搞清楚它和 ComfyUI 的关系LibTV 并不是独立软件。它建立在 ComfyUI 生态之上本质是一组自定义节点和工作流配置的集合。ComfyUI 是当前 AI 绘画领域非常流行的节点式界面工具它把图像生成过程拆成一个个可连接的节点加载模型是一个节点输入提示词是一个节点采样器是一个节点保存图片是另一个节点。用户把节点拖到画布上连线组成一个流程。LibTV 做的事情是把“影视漫剧生产”中需要的更高层能力封装成节点。比如把“一段剧本文字拆成多个分镜描述”把“一段分镜描述自动补全成绘图正向提示词”甚至把“一个故事角色描述在多张图中保持一致”这类逻辑封装成工作流内部的处理单元。这里有一个非常重要、新手最容易误会的点ComfyUI 工作流不等于代码脚本它是一张可视化的流程图。你保存一个 workflow 文件本质上保存的是节点信息和节点之间的连接关系。别人分享一个 LibTV 工作流给你你下载后拖进 ComfyUI 就能看到整条流水线但前提是你本地的环境里已经装好了工作流用到的所有自定义节点和依赖包。所以我会反复强调一个排查原则当工作流界面出现红色节点或提示“请安装缺失的包以使用此工作流”时首先要做的不是删掉节点重画而是去检查当前 Python 环境缺少哪些依赖。这是所有 ComfyUI 系工作流的通用坑LibTV 当然也不例外。如果只看表面很容易误以为 LibTV 是一个“AI 视频生成器”。实际上它更接近一个“AI 影视流程框架”。它真正让你获得的能力是把编剧、美术、配音、剪辑的规则固化成流程然后通过替换输入文本批量产出不同剧本的漫剧成片。这是普通绘图工具完全不具备的。3. 适用场景LibTV 适合做什么不适合做什么判断一个工具值不值得学不能只看它能做什么还要看它不适合做什么。我用这张表概括 LibTV 工作流的边界。维度适合场景不适合场景内容形式动漫风格短剧、漫剧、剧情解说、动态漫画实拍风格、高写实 CG、复杂 3D 动画生产模式批量产出、系列化内容、固定角色多集剧情单张高质量插画、精细人工修图制作周期短平快的短视频每集 1-3 分钟院线级电影、高精度商业广告用户基础已接触过 ComfyUI 或 Stable Diffusion懂基础提示词完全不懂节点、不懂模型、零基础电脑用户硬件要求本地 8GB 以上显存或使用云端 ComfyUI只有普通办公笔记本且无云资源这里要额外说明一点。LibTV 这类工作流的核心优势是一致性也就是让同一个角色在多个分镜里长得像同一个人。它在做短剧、漫剧时价值很大因为这类内容角色出场频次高观众对面孔连续性的要求也高。但如果你是做单张商业插画或者只需要一张精品主视觉用 LibTV 反而是杀鸡用牛刀因为工作流的固定逻辑会限制你对单张画面的自由控制。从成本角度判断LibTV 工作流更适合那种“内容量大、单条质量要求中等偏上、交付节奏快”的项目。比如 AI 漫剧解说、小说推文视频、儿童故事动画、连续漫画翻拍。做这类内容时人工介入的重点不再是每张图的构图而是剧本节奏、角色设定和最终审核。还要提醒一点用 LibTV 或其他 AI 工具生成内容用于公开传播时要关注素材授权、模型使用条款和各平台对 AI 生成内容的规定不要直接拿未确认权属的剧本、声音或美术素材投入商业项目。更稳妥的做法是使用自己创作的剧本、自己训练或明确允许商用的模型并保留完整制作记录。4. 环境准备先把 ComfyUI 和 LibTV 的底座搭好开始动手之前先把环境准备当成一个正式项目来做。我见过非常多新手在工作流跑到一半时出问题回头排查发现是最开始的 Python 环境装乱了。4.1 基础环境清单以当前主流实践为例建议准备以下环境操作系统Windows 10/11 或 LinuxUbuntu 22.04 以上。macOS 也能跑但显存和兼容性限制更大。GPUNVIDIA 显卡显存建议 8GB 起步12GB 以上更舒服。Python3.10 或 3.11。不要用 3.12 作为首选部分自定义节点和依赖可能还没有完全适配。Git用于拉取 ComfyUI 仓库和 LibTV 相关仓库。ComfyUI通过 Git 拉取官方仓库然后安装依赖。虚拟环境这一步不要省。很多报错都源于不同项目依赖冲突。下面的命令演示了创建 ComfyUI 专用虚拟环境并安装依赖的完整过程# 以 Linux / macOS 为例Windows 可用 conda 或 venv 替代 conda create -n comfyui python3.11 -y conda activate comfyui # 拉取 ComfyUI 官方仓库 git clone https://github.com/comfyanonymous/ComfyUI.git cd ComfyUI # 安装 PyTorch 及 ComfyUI 依赖 pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121 pip install -r requirements.txtWindows 用户如果没有 conda可以用 Python 自带的 venvpython -m venv comfyui_env comfyui_env\Scripts\activate pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121 pip install -r requirements.txt这段命令里真正值得注意的是 PyTorch 的安装源。--index-url指向 CUDA 12.1 版本这是当前兼容性比较稳妥的选择。如果你的显卡驱动较老可能需要换用 cu118 的版本但优先尝试 cu121。安装完成后启动 ComfyUIpython main.py看到类似Starting server的日志后浏览器访问http://127.0.0.1:8188能打开 ComfyUI 界面就算成功。4.2 安装 LibTV 节点LibTV 通常以 ComfyUI 自定义节点的形式安装。标准做法是把节点仓库放到ComfyUI/custom_nodes/目录下。假设你找到了 LibTV 的官方仓库地址安装命令是cd custom_nodes git clone https://github.com/example/libtv-comfyui.git cd libtv-comfyui pip install -r requirements.txt然后重启 ComfyUI。重启后在节点列表里搜索 “LibTV” 或相关关键词如果能找到说明安装成功。这里必须强调一点LibTV 项目和 ComfyUI 生态一样推进速度很快仓库地址、安装方式、依赖列表都会变。上面命令里的仓库地址是占位示例你自己操作时要以项目官方 README 为准。这不算偷懒而是高效利用信息的方式——长期维护的教程一定赶不上仓库本身的更新速度。4.3 依赖缺失问题的初步处理安装完节点后如果你拖入一个别人分享的 LibTV 工作流文件界面仍然可能弹出一批红色节点提示“请安装缺失的包以使用此工作流。要安装缺失的节点请先在你的 Python 环境中运行……”。这是 ComfyUI 生态最常见的信息同时也是最有用的报错。出现这个提示说明工作流依赖的某个 Python 包不在当前环境里。处理思路分两步查看红色节点提示里具体提到了哪个包名比如imageio-ffmpeg、moviepy、openai。激活 ComfyUI 所在的环境手动安装对应包然后重启 ComfyUI。命令示例conda activate comfyui pip install imageio-ffmpeg moviepy openai装完之后刷新浏览器页面红色节点一般就会恢复正常。如果还报错优先看 ComfyUI 启动时终端里打印的 import error 堆栈那才是真正的原因。5. LibTV 工作流核心模块拆解从剧本到成片四步走把环境准备好之后我们直接进入 LibTV 工作流的内部结构。一条完整的 LibTV 漫剧工作流无论界面多复杂核心逻辑可以拆成四段剧本生成与解析、分镜画面生成、配音合成、视频组装与输出。下面逐个拆解。5.1 剧本生成与解析模块这个模块解决的是“从一个故事想法变成结构化分镜文本”的问题。它通常接收一个故事梗概或剧本草稿然后输出结构化数据场次列表、每个分镜的画面描述、对应台词、画面时长建议。如果工作流内置了剧本生成能力配置时通常需要接入大模型 API填 Key、选模型、写提示词模板。如果 LibTV 当前版本没有内置大模型接入一个更通用、稳定性更好的做法是先用任意大模型工具把剧本写好整理成工作流要求的格式再作为一个文本节点输入到流程中。这里有一个判断在工作流里接入大模型直接生成剧本体验很酷但可控性差不适合生产。因为大模型输出的格式不稳定容易断在 JSON 解析那一步。更稳妥的工程实践是分离“创意生成”和“解析执行”创意阶段用大模型随意发挥人工审一遍执行阶段让工作流严格读取结构化文本减少解析报错。一条典型的结构化剧本输入大概长这样{ title: 深夜便利店, story: 一个加班的年轻人在深夜便利店遇到神秘店员得知自己重复过着同一天。, scenes: [ { scene_id: 1, location: 便利店门口, characters: [年轻人, 店员], description: 夜晚便利店招牌亮着冷光年轻人在门口犹豫片刻后推门进入。, dialogue: 又是加班到十二点买瓶咖啡吧。, duration: 5 }, { scene_id: 2, location: 便利店内部, characters: [年轻人, 店员], description: 镜头跟随年轻人走到冷藏柜前店员在不远处注视着他。, dialogue: 您又来了。, duration: 4 } ] }得到这类 JSON 后工作流里的解析节点会把description送去生图把dialogue送去配音把duration作为视频片段长度三个环节共用同一份剧本数据不会出现台词和画面对不上的情况。这就是 LibTV 工作流比手工拼接高效的根本原因一份数据多处消费。5.2 分镜画面生成模块这是整个工作流里最重、最吃显卡的部分。它要做两件事一是把剧本里的description转成适合绘图模型的正向提示词二是保证同一个角色在不同分镜中长相一致。提示词转换方面LibTV 节点通常内部已经做了增强你不需要自己写很长的 tag。但如果你发现生成画面和剧本描述差距很大可以手动在提示词模板里追加风格词比如anime style, cinematic lighting, high detail。角色一致性是漫剧制作的分水岭。目前主流方案是引入角色参考图也就是先为每个主要角色生成一张定妆图然后在后续所有分镜生成时把定妆图作为参考条件传入。从材料看LibTV 的节点设计也遵循了这一思路。实际使用中你的工作流里大概率会有类似这样的输入项character_reference_young_man: 角色参考图 1 character_reference_store_clerk: 角色参考图 2 style_reference: 整体画风参考图如果你拿到的工作流没有暴露这些输入而是把所有参考图都写死在节点内部建议你改成外部输入。这样以后换角色只需要替换参考图不需要动工作流结构。这个模块的输出是一批静态图比如每个分镜输出 1 到 4 张候选帧供你挑选或直接进入视频生成。5.3 配音合成模块配音模块没有那么神秘。它本质上是一个文本转语音TTS节点把剧本里的dialogue字段逐条转成音频文件。可选的方案非常多有的工作流支持本地 TTS 模型有的接云端 API。具体用哪种建议以 LibTV 工作流当前支持的节点为准。在这个环节真正影响成片质量的因素有三个语气和断句TTS 生成的音频如果太平观众听两句就想划走。选择支持情感参数或角色音色的模型会比单一音色效果好很多。音频对齐每句台词的音频时长最好和分镜时长匹配。如果音频太长画面已经结束声音还在说话会很奇怪。多角色区分如果漫剧里有多个角色尽量给不同角色分配不同音色这是提升“像真剧”观感最明显的一步。另外配音合成后不要直接拿去剪辑。建议先做一遍响度归一化也就是让所有音频片段的音量保持相对一致避免上一段轻声细语、下一段振聋发聩。5.4 视频组装与输出模块拿到分镜图片和配音音频之后工作流会把它们合成为最终视频。这个过程通常包括把静态分镜图按顺序拼接或者通过图生视频节点让画面产生轻微动态效果。把配音音频放到对应时间轴。按剧本为每个片段设置时长。可选择性地添加字幕、背景音乐、转场效果。最终导出为 MP4 文件。如果你的 LibTV 工作流只是把图片直接拼接成视频成品会接近“动态漫画”的观感画面静止但配合配音和转场叙事也是成立的。如果接入了图生视频模型成品会更接近动画但耗时和算力消耗也会明显增加。一个非常实用的建议是先让静态图拼接版本的流程跑通再去追求图生视频动画效果。不要在第一天就开最高画质、最大分辨率、最强动态模型。媒体制作行业有一个原则先做出粗剪再打磨细节。AI 漫剧流程也一样先跑通 10 秒的测试片段确认工作流每一条链路都正常再扩大产量。6. 完整示例一个人人可复制的 LibTV 工作流骨架下面我给出一个 LibTV 工作流的最小结构示意用来展示节点之间的数据流关系。注意这不是某个版本的完整可运行 JSON而是一个帮助你理解工作流结构的骨架模板。你真正使用的工作流文件应该从官方社区导出。{ workflow_name: libtv_mini_demo, nodes: [ { id: 1, type: LoadStoryJSON, inputs: {}, outputs: [story_data] }, { id: 2, type: LibTVStoryParser, inputs: { story_data: node_1.output.story_data }, outputs: [scene_list, dialogue_list, duration_list] }, { id: 3, type: LibTVScenePromptBuilder, inputs: { scene_list: node_2.output.scene_list }, outputs: [prompts] }, { id: 4, type: LibTVCharacterRefLoader, inputs: { young_man_ref: workflow_input.character_ref_1, store_clerk_ref: workflow_input.character_ref_2 }, outputs: [ref_images] }, { id: 5, type: KSampler, inputs: { prompts: node_3.output.prompts, ref_images: node_4.output.ref_images }, outputs: [scene_images] }, { id: 6, type: LibTVTTSNode, inputs: { dialogue_list: node_2.output.dialogue_list }, outputs: [audio_files] }, { id: 7, type: LibTVVideoAssembler, inputs: { scene_images: node_5.output.scene_images, audio_files: node_6.output.audio_files, durations: node_2.output.duration_list }, outputs: [final_video] } ] }看这个结构你就能理解工作流的本质每个节点做一件事节点之间通过输入输出连接。你修改LoadStoryJSON里的剧本内容后面所有节点会自动按照新数据重新生成。这也是为什么工作流一旦调整好批量做漫剧的效率会非常高。实际运行时给你的建议是拆成三段跑先只跑LoadStoryJSON到LibTVStoryParser确认剧本解析成功。再跑LibTVScenePromptBuilder和KSampler生成几张测试图确认画面符合预期。最后接上LibTVTTSNode和LibTVVideoAssembler合成完整视频。不要一上来就把整条链路全跑一遍否则出了问题你很难定位是剧本解析失败、模型显存溢出还是音频节点缺包。7. 运行验证与效果检查工作流跑完怎么判断结果是好的很多新手看到视频文件生成就以为成功了但实际内容可能根本不能用。我建议按下面四个维度检查。7.1 图片质量检查第一轮看静态图。检查每个分镜的画面是否和剧本描述一致场景对不对、角色在不在、动作方向对不对。AI 生图经常出现“画面很美但内容跑偏”的情况比如剧本里写“便利店门口”画出来却变成室内货架这种必须返工。7.2 角色一致性检查把同一个角色的所有分镜图放在一起看五官、发型、服装是否保持稳定。一致性出现问题优先检查角色参考图的设置是否正确以及提示词里是否写入了互相冲突的风格词。这是漫剧生产中最耗时的一步没有捷径。7.3 音画同步检查播放成片重点看台词是否在对应画面上出现。如果配音模块输出的音频时长和分镜时长对不上画面会显示“声音已经结束了角色还在开口说话”或反过来。这类问题通常要回到duration_list或 TTS 节点参数里调整。7.4 导出格式检查确认输出文件的分辨率、帧率、编码格式是否符合发布平台要求。平台不支持某个编码格式时视频会出现上传后无法播放的情况。必要时可以使用 FFmpeg 做格式转换命令示例ffmpeg -i input.mp4 -c:v libx264 -pix_fmt yuv420p -c:a aac -b:a 192k output_h264.mp4这条命令把输入视频统一转成 H.264 编码、AAC 音频的 MP4 文件这是当前短视频平台兼容性最好的组合之一。8. 常见问题与排查思路下面这个清单基本覆盖了 LibTV 工作流最常见的坑建议截图保存。问题现象可能原因排查方式解决方案节点显示红色提示“请安装缺失的包”Python 环境缺少工作流依赖查看终端 import error 堆栈确认包名用 pip 安装对应包后重启 ComfyUI运行到一半显存不足OOM分辨率过高或批量过大查看 GPU 显存占用降低分辨率、减小 batch size或使用显存优化参数生成的角色每张图长得都不一样角色参考图没有正确传入节点检查参考图节点是否接线、是否加载成功重新加载角色参考图确认节点输出类型匹配画面风格和剧本描述完全不符提示词转换节点未生效或风格词冲突查看最终送入采样器的 prompt重置提示词模板删除冲突风格词视频没有声音TTS 节点没有输出音频或组装节点没接音频输入检查 TTS 节点输出路径和组装节点输入单独运行 TTS 节点测试音频能否生成音频和画面时长对不上剧本 duration 字段设置不合理检查剧本 JSON 中每段的 duration根据台词字数估算时长留出呼吸和转场余量导出 MP4 在播放器里无法播放编码格式不兼容查看导出视频编码信息使用 FFmpeg 转为 H.264 AAC当多个问题同时出现时优先排依赖再排内存最后排逻辑。依赖缺失会导致节点无法初始化显存不足会导致采样中断而音画不同步只在前面都正常时才会暴露出来。9. 最佳实践与工程建议9.1 工作流文件用 Git 管理LibTV 工作流的本质是配置代码。只要你开始修改工作流结构就建议放进 Git 仓库管理。每次跑出一个满意的配置提交一次。这样当你后来改坏的时候一条命令就能找回之前的可用版本。9.2 配置和资源分离角色参考图、风格参考图、剧本 JSON、音频输出、视频输出这些资源不要全部堆在一个目录里。推荐用下面的结构组织libtv_project/ workflows/ libtv_main.json libtv_test.json inputs/ stories/ character_refs/ style_refs/ outputs/ scene_images/ audio/ videos/这个结构的好处是换项目时复制整个文件夹不会污染其他项目的输出。9.3 每一环节都单独验收我见过太多团队在完整流程跑通后才检查画面质量结果几十集内容全是角色崩坏的废稿。正确做法是在生成前期就建立验收点剧本解析完检查分镜数量图片生成完检查角色一致性配音合成完试听几条最后再合成完整成片。宁可每个环节多花十分钟也不要到最后推倒重来。9.4 控制内容合规边界用 AI 工具做漫剧底线问题必须提前想清楚。首先是素材来源剧本最好是自己创作的或有合法授权不要直接拿他人的小说、漫画直接改编其次是模型使用条款确认你用的绘图模型、TTS 模型是否允许生成内容商用最后是平台规则发布 AI 生成内容前后留意平台对合成内容标识的要求。保留制作过程素材和笔记遇到争议时能快速说明来源。9.5 先引擎后内容先短后长如果你是在团队里推广 LibTV 工作流建议不要一上来就要求成员做三分钟完整剧情。可以先定一个“十五秒测试片段”的验收标准一个场景、两个镜头、一句台词、一段配音。十五秒跑通之后再扩展到一分钟再到三分钟。这样团队积累的不是单个视频而是可复用的生产方法。10. 总结与后续学习方向LibTV 这类工作流真正改变的是 AI 漫剧生产从“手工作坊”走向“流程化流水线”的方式。它并不神奇也不神秘本质是把剧本、画面、配音、剪辑这些环节用节点串联起来让数据在固定的管道里流动。你学会的不只是一个工具的按钮位置更是一条可以复用的内容生产思路。对于刚上手的读者我建议下一步只做一件事找一个别人分享的 LibTV 工作流按本文的步骤把环境装好然后用一个十句话以内的小故事跑通一遍。不要贪多不要一开始就做长篇先在流程里感受数据如何流动出错时如何排查。等你跑通第一个成片真正值得深入的方向有三个一是角色一致性控制尝试用更多角色参考方式减少崩脸二是动态效果增强研究图生视频模型的接入方式和参数调优三是批量生产能力学习如何用外部脚本批量替换剧本输入实现多个剧本批量出片。最后送各位一句话工作流解决的是“能不能稳定做出来”的问题而“内容好不好看”最终仍然取决于你的剧本、审美和节奏感。工具给你的是效率内容给你的是观众。把 LibTV 当成你的创作底座但别让它替你思考。