简介开源本地AI短剧与漫剧全流程创作工具包面向AI内容创作者、独立开发者和希望本地化生成视频的进阶用户解决从剧本分析、AI分镜、图片资产整理到Seedance视频生成的一站式创作链路问题。工具已接入seedance2数据不离开本机尤其适合对隐私和数据安全要求较高的场景。资源压缩包共包含1175个文件其中1125个webp图片资产占主体配合js、json、css等前端工程文件、Dockerfile/nginx.conf等部署配置以及bff-runtime等运行时支撑文件整体仅19.84MB部署轻量、便于快速体验。压缩包内目录结构清晰既支持通过容器快速启动独立服务也提供了可改写的脚本和配置文件方便用户替换图片素材、调整生成参数或扩展其他视频模型。资源已有50人学习/下载适合想在本地搭建AI真人剧与漫剧生产流程并深入理解工具链细节的创作者。1. AI 漫剧全流程工具到底串起了什么从剧本到成片的链路做 AI 漫剧最磨人的不是生成那一下而是剧本、分镜、底图、视频生成、剪辑这几道工序之间断层。编剧交付的是 Word 文档画师要的是镜头描述ComfyUI 要的是提示词和参考图最后进 Seedance 又得重新写一遍运动指令。来回翻译三次两天出一集都算快。这个标题里的「全流程创作工具」本质上是把这几道工序用统一的数据格式串起来——剧本分析模块产出结构化 JSONAI 分镜基于 JSON 生成镜头序列图片资产模块按照分镜批量出底图最后交给火山方舟上的 Seedance 做视频生成。适合单人做短剧的创作者、小团队做漫剧量产、以及想搭视频生成工作流的从业者。核心收益不是省掉某一个环节而是让改一集剧本时后面所有环节能跟着联动更新。2. 剧本分析与 AI 分镜把一段文字拆成一串能执行的镜头2.1 为什么第一步必须先做结构化而不是直接写分镜拿到剧本就写分镜是这个流程里最容易翻车的起手式。一个大模型直接读五千字小说段落让它输出分镜它大概率会给你一堆「镜头缓缓推进人物表情凝重」这种正确但没法执行的废话。问题不在模型而在输入没有切分单元。分镜需要的最小单位是「一个角色、一个动作、一个情绪、一个场景」但网文段落的天然粒度是「一段情节、多个人物、连续动作」。工具的第一步必须先把剧本切成可操作的片段再在每个片段上做镜头翻译。常见做法是用 LLM 做两级抽取第一级把剧本按场景切分输出分场表第二级在分场表内部按动作和情绪变化切分镜头。两级切分的好处是改动剧本时只需要重跑被影响的场景不用整本重算出问题时也能定位到具体是分场错误还是分镜错误。我一般会把分场表和分镜表用同一套 JSON Schema 约束字段名统一后面接 ComfyUI 和 Seedance 时就不用做字段映射。分场表的核心字段是「场次号、地点、时间、出场角色、故事目标」分镜表的核心字段是「镜头号、景别、运动方式、画面主体、主体动作、情绪、时长」。两级结构最大的隐藏收益是「可追溯」——最终视频里某个镜头崩了你能从镜头号反查到对应的剧本原文知道是剧本理解错了还是生成环节的问题。2.2 剧本结构化模板与 Prompt 实例给 LLM 的 Prompt 里最重要的不是语气词是输出约束和示例。我习惯在 Prompt 里直接给一个两层的 JSON 模板让模型照着填空。模板写得越细解析越稳。你是一个漫剧编剧助理。请把用户提供的剧本段落改写成 JSON。 先按场景切分再在每个场景内按动作/情绪切换切分镜头。 输出格式严格按此结构不要输出其他文字 { script_id: S001, scenes: [ { scene_no: 1, location: 地点名称, time: 白天/夜晚/黄昏/黎明, characters: [角色A, 角色B], summary: 本场一句话概要, shots: [ { shot_no: 1, scale: 全景/中景/近景/特写, camera: 固定/推/拉/摇/移/跟, subject: 画面主体描述含角色名和特征, action: 主体在这一镜头内完成的动作, emotion: 主体情绪, duration: 4, dialogue: 本镜头内台词无台词填空字符串 } ] } ] } 规则 1. 场景以地点时间变化为界不要按段落切。 2. 镜头以动作开始和结束为界一个镜头只描述一个连续动作。 3. 每个镜头时长 3-6 秒对话多的场景镜头可到 8 秒。 4. subject 字段里必须写角色名不能写他/她。 5. 如果原文没有明确地点按剧情合理推断并在 summary 里说明推断依据。这段 Prompt 的关键设计是「镜头以动作开始和结束为界」。不加这条模型经常把一个连续对话拆成十几个静态镜头进了 Seedance 后生成出来的视频全是人物嘴在动、身体不动观感极差。加了这条之后模型会把「拿起杯子—喝水—放下」当一个镜头处理视频生成的连续运动指令才好写。另一个细节是「scene 以地点加时间变化为界」「时间」我限定了四个枚举值而不是让模型自由发挥。因为后面做图片资产时同样角色在不同时间段的底图光影逻辑完全不同自由发挥的「傍晚」「夕阳西下」这类描述在图像生成时反而难以稳定复现。2.3 分镜输出的校验与边界不能全信大模型的 JSON大模型返回的 JSON 看起来规矩实际拿到手里常有三类问题角色名前后不一致、duration 超出范围、shot_no 不连续。直接在 Prompt 里加再多规则也没用输出阶段必须有一个独立脚本做校验。这一步在整个流程里成本最低但能拦住后面图片资产环节一半的返工。import json import sys def validate_script(data: dict) - list[str]: errors [] allowed_scales {全景, 中景, 近景, 特写} allowed_cameras {固定, 推, 拉, 摇, 移, 跟} for scene in data.get(scenes, []): if not scene.get(location): errors.append(f场景 {scene.get(scene_no)} 缺少地点) for shot in scene.get(shots, []): if shot.get(scale) not in allowed_scales: errors.append(f镜头 {shot.get(shot_no)} 景别非法: {shot.get(scale)}) if shot.get(camera) not in allowed_cameras: errors.append(f镜头 {shot.get(shot_no)} 运镜非法: {shot.get(camera)}) if not 3 shot.get(duration, 0) 8: errors.append(f镜头 {shot.get(shot_no)} 时长越界: {shot.get(duration)}) if shot.get(subject) and 角色 in shot.get(subject, ): errors.append(f镜头 {shot.get(shot_no)} subject 中残留占位符) return errors if __name__ __main__: with open(sys.argv[1], r, encodingutf-8) as f: data json.load(f) errs validate_script(data) if errs: print(\n.join(errs)) sys.exit(1) print(校验通过)这段脚本的校验思路是「枚举法」而非「正则匹配」。景别、运镜、时长都用固定枚举值校验因为后面图片资产环节要拿这些枚举值去拼提示词——ComfyUI 里的 ControlNet 对「近景」和「特写」的处理逻辑不一样与其到时候再解析不如在源头就卡死。脚本里我对 subject 做了残留占位符检查因为 LLM 在生成角色描述时偶尔会偷懒写「角色A」而不是实际姓名这类问题不进校验脚本后面生图阶段会变成两个人共用一张脸。跑校验脚本的正确姿势是配合抽检不要只信脚本。我一般脚本全量过一遍再按 20% 比例抽检那些 duration8 的长镜头。长镜头往往包含多个动作模型容易把「说话」和「做动作」压缩进同一个镜头描述导致图片资产阶段很难选一个中间帧作为底图。3. 图片资产用 ComfyUI 为分镜批量生成角色一致的底图3.1 角色一致性靠什么保证LoRA、IP-Adapter 还是参考图重绘AI 漫剧最出戏的就是同一个角色在不同镜头里长得不像。做图片资产时保证角色一致的主流方案有三种训练角色 LoRA、用 IP-Adapter 锁参考图、以及每次生成后手动重绘。三者的取舍直接决定你这条链路的日产量。训练角色 LoRA 效果最好但冷启动成本高。一个角色要准备 15 到 30 张不同角度的干净素材训练一轮少说要跑两三个小时换一套服装又要补素材。适合要做几十集的长期漫剧一个角色从头用到尾。IP-Adapter 是快路子给一张角色设定图就能锁五官结构十几秒出一张底图但有个隐蔽缺陷IP-Adapter 锁不住服装细节。角色上半身还行下半身经常飘换场景换服装时尤其明显。参考图重绘兜底用把上一镜的干净帧作为 inpaint 输入改局部而不重画全局适合修正单张图的崩坏不适合批量。标题里这个工具体系的常规搭配是项目起步用 IP-Adapter 跑通全流程确认角色有大量戏份后再补 LoRA 替换。两条线共用同一套提示词模板LoRA 训练好后只改一个 checkpoint 加载路径其他环节不用动。3.2 ComfyUI 批量出图工作流与命名规范图片资产模块的最小可用工作流是加载 checkpoint接 IP-Adapter 锁定角色特征ControlNet 锁姿态最后正面提示词里写分镜的景别、动作、情绪。在 ComfyUI 里导入的工作流 JSON 长这样{ 3: { class_type: CheckpointLoaderSimple, inputs: { ckpt_name: majicmixRealistic_v7.safetensors } }, 10: { class_type: IPAdapterAdvanced, inputs: { model: [3, 0], image: reference_character.png, weight: 0.7, start_at: 0.0, end_at: 1.0 } }, 22: { class_type: ControlNetLoader, inputs: { control_net_name: control_v11p_sd15_openpose.pth } }, 31: { class_type: CLIPTextEncode, inputs: { text: full body, standing, looking at camera, nervous expression, cinematic lighting } } }这个片段里最关键的两个参数是 IPAdapter 的 weight 和 ControlNet 的模型选择。weight 设 0.7 是多数场景的安全值低于 0.5 时角色特征基本丢了高于 0.9 时面部会像贴了模板一样僵硬。ControlNet 用 OpenPose 是为了锁姿态因为分镜里写的 action 在进文生图模型时经常被忽略有姿态骨架兜底生成的底图至少动作是对的。提示词部分我用的是简单英文短句不用长句因为图片模型对超过 50 个 token 的复杂描述会选择性忽略。批量出图时命名规范比提示词更重要。我常用的规则是「集数_场次_镜头号_角色名_状态」#!/bin/bash # 从分镜 JSON 中提取镜头信息生成标准文件名的目录结构 SCRIPT_DIR./output/scene_01 mkdir -p ${SCRIPT_DIR} # 假设 shot_list.txt 每行格式为: 集数 场次 镜头 角色 动作标签 while read -r ep scene shot char emotion; do cp ./generated/${char}_${emotion}.png \ ${SCRIPT_DIR}/${ep}_${scene}_${shot}_${char}_${emotion}.png done shot_list.txt # 输出检查列出缺失文件 ls ${SCRIPT_DIR} | wc -l这段脚本解决的问题是「底图和分镜的对应关系」。实测中最常见的翻车是图生成了但文件名是 ComfyUI 默认的 timestamp等到了 Seedance 阶段发现不知道哪张图对应哪个镜头只能一张张看缩略图人工匹配一小时起步。用命名规范把集数、场次、镜头号写进文件名后面任何环节需要查图直接按文件名过滤。3.3 底图验收看什么作废率控制在多少才健康底图不是生成完就能直接进视频生成的。批量出图后必须有一道独立的抽检环节检查三件事角色五官是否一致、画面构图是否符合景别要求、以及主体周围有没有明显的残缺或多余元素。在 ComfyUI 的 batch 模式下我习惯每批生成 8 张候选按分镜要求挑一张。健康作废率在 50% 到 70% 之间——如果你 8 张里能挑出 3 张以上可用说明提示词太保守可以加大 IPAdapter weight 或加入更多风格词如果 8 张全军覆没优先查 ControlNet 的姿态骨架是否加载正确而不是调提示词。另一个必须做的是把「选定底图」单独归档到一个 approved 目录作为后续 Seedance 视频生成的唯一输入源。这样当你需要重生成某一镜时不会误用之前标注作废的图。4. Seedance 视频生成在火山方舟上把静态分镜变成动态镜头4.1 为什么选 Seedance 而不是本地视频生成模型标题里写「Seedance 和火山方舟视频生成工作流」这个选型是有原因的。本地视频生成模型比如 AnimateDiff 系列有两个绕不过去的坎一是单镜头时长撑不过 4 秒长了就崩二是运动幅度大的镜头主体变形严重。做漫剧这种一集两三分钟、每镜平均 5 秒的场景本地模型频繁拼接镜头反而效率低。Seedance 通过火山方舟平台以 API 方式提供优势在于单次生成时长可以覆盖常用镜头区间而且对「角色一致性」和「幅度较大的运动」处理得更好。体感上Seedance 对「人物从坐到站」「转头说话」这类漫剧高频动作的生成成功率明显高于本地模型。它不是万能的——复杂场景雨天、多人交互动仍然容易翻车——但在单人漫剧这个细分场景里它是目前成本和效果平衡得比较好的一档。4.2 火山方舟 API 调用最小示例Seedance 在火山方舟上的接入方式沿用平台统一的 HTTP 接口风格。先用 Python 把底图和分镜描述组装成请求import base64 import requests import json # 读取某个镜头的底图编码为 base64 with open(approved/S01_E01_001_阿岚_紧张.png, rb) as f: image_data base64.b64encode(f.read()).decode(utf-8) # 从分镜 JSON 中取该镜头的动作和情绪描述 shot_prompt 阿岚从椅子上站起来双手握紧眼神看向门口背景灯光闪烁 payload { model: seedance-1-pro, prompt: shot_prompt, image: image_data, duration: 6, fps: 24, negative_prompt: 变形, 模糊, 多余的肢体, 背景扭曲, cfg_scale: 3.5 } headers { Authorization: Bearer YOUR_API_KEY, Content-Type: application/json } resp requests.post( https://ark.cn-beijing.volces.com/api/v3/video/generation, headersheaders, jsonpayload, timeout120 ) if resp.status_code 200: result resp.json() print(视频生成任务ID:, result.get(id)) print(预计等待时间:, result.get(estimated_time)) else: print(请求失败:, resp.status_code, resp.text)注意这段代码里我把请求超时设成了 120 秒。视频生成是异步任务第一次提交只返回任务 ID真正的视频文件需要后续轮询任务状态才能拿到。如果你直接同步阻塞等结果大概率会读到连接超时。字段方面「duration」接受 4-12 的整数「cfg_scale」控制提示词遵从度数值越高运动幅度越小、画面越稳数值越低动作越激进但更容易变形。漫剧推荐从 3.5 起步太稳的镜头观感像 PPT。4.3 三个必调参数踩过坑才知道怎么设Seedance 的参数里我用下来最影响出片质量的是 duration、运动幅度描述方式和首尾帧连续关系。时长上「每个镜头按分镜里的 duration 原样提交」是新手最常见的误区。底图的构图是按静态帧设计的视频生成时如果单次时长超过 8 秒物体运动会逐渐偏离底图逻辑后半段经常变成另一张图。我的习惯是把分镜时长超过 8 秒的镜头拆成两段每段各自提交拼接时用转场过渡。运动幅度不要写在 prompt 里用参数表达。Seedance 对「剧烈运动」「快速移动」这类词的响应不稳定同样一句话有时生成高能打斗有时生成慢动作。常见做法是控制 cfg_scale3.0-3.2 适合快速动作3.5 适合日常动作3.8 以上只用于纯对话场景。想要精确控制某个镜头里的具体运动幅度在 prompt 里写「缓慢地」或「急促地」比写「大动作」有效。首尾帧方面我只在需要跨镜头保持连续动作时才提交尾帧。尾帧是从下一个镜头的底图截出来的Seedance 会把视频的运动趋势往尾帧方向引导。但注意尾帧和首帧差异越大生成时间越长失败率也越高。如果两个镜头之间角色位置有大的跳变不要硬接首尾帧直接让每个镜头独立生成用剪辑硬切过渡更省事。5. 避坑全流程最容易翻车的六个环节5.1 剧本分析与分镜阶段的坑现象一大模型输出的 JSON 里镜头号断档。场景内先从 1 排到 4接着直接跳到 9中间缺了 5、6、7。原因通常是剧本段落里有一段旁白模型把旁白当成了镜头但没有编号。解决在 Prompt 里加一条规则「旁白不独立成镜头并入前一镜头的 dialogue 字段」并且在 2.3 节校验脚本里加对 shot_no 连续性的检查。现象二同一角色在分镜里有两个名字。剧本原文用了「阿岚」某几个镜头里模型写成了「岚姐」后面图片资产阶段按角色名建目录直接出现两个文件夹角色形象完全割裂。原因LLM 在长上下文里对角色昵称的归一化不稳定。解决在剧本分析之前先让 LLM 做一次角色表抽取把所有角色别名映射到标准名再把这个映射表作为后续所有 Prompt 的固定前缀。5.2 图片资产生成阶段的翻车现场现象三IP-Adapter 锁了脸但角色换了衣服。分镜里写「阿岚穿黑色外套」生成的图脸还是那张脸衣服变成了红色卫衣。原因是 IP-Adapter 只对中高频特征敏感对大面积颜色区域的约束弱。解决不要在 IP-Adapter 里塞参考图期望它管服装把服装描述写进正面提示词的头部并且用 ControlNet 加一个 Canny 边缘约束把服装轮廓固定下来。现象四ComfyUI 批量出图时内存溢出跑到第 40 张直接中断前面 39 张全部没归档。原因batch 模式下所有候选图都堆在显存里没有边生成边落盘。解决把出图工作流改成每张单独执行完成一张就立刻移动到 approved 目录。代价是速度降一点但不会出现整批颗粒无收的惨案。5.3 Seedance 视频生成阶段的血泪经验现象五Seedance prompt 写太长结果主要动作丢了画面里角色只是站在那里眨眼。原因是视频模型对 prompt 的处理是有压缩的超过一定长度后尾部内容被截断。解决prompt 控制在 20 个词以内核心动作放前 10 个词环境描写全部砍掉。底图里已经有了场景信息prompt 只需要写动态部分。现象六批量提交 20 个视频生成任务后有一半任务查不到状态。原因是对于长时间生成任务平台侧的轮询接口有时间和频次限制。解决在轮询逻辑里加指数退避——第一次查完等 10 秒第二次等 30 秒第三次等 60 秒最多等 10 分钟。同时把任务 ID 落盘记录即使中途进程崩溃重启后还能继续查询已提交的任务。6. 工作流的验证与进阶从单集跑通到批量生产6.1 用什么编排这套链路脚本还是现成的工作流工具单集跑通后下一步是把整条链路自动化。常见的选择有三个纯 Python 脚本串联、n8n 工作流、以及 Coze 这类云端 Agent。我的建议是分阶段升级——先把剧本分析和分镜输出做成一个脚本再把图片资产命名和归档做成第二个脚本最后用 n8n 把这两个脚本和 Seedance API 串起来。理由很直接纯脚本改造成本最低适合跑第一集验证流程n8n 的优势是可视化观察每个节点的输入输出适合在不断调参的阶段Coze 这类云端方案适合已经稳定量产、需要多人远程协作的团队。我自己目前的实践是 n8n 为主。每个镜头一条数据流分镜 JSON 进来经过脚本节点拆出镜头号、角色、动作再并行触发图片生成和视频生成两个分支。这样如果某个镜头生成失败只需要从失败节点重跑不用整个工作流从头再来。6.2 一盘成片的验收清单自动化跑完不等于能发布我每集必做的质检清单包括以下几项按优先级排列验收项具体标准检查办法角色一致性同一角色在所有镜头中五官可辨认抽帧对比重点看正脸和侧脸切换镜头时长每个镜头时长与分镜 JSON 偏差不超过 1 秒视频元数据脚本自动核对运动连贯性相邻镜头之间主体位置无跳变逐镜头播放重点看切点前后两帧字幕同步台词出现时间与口型偏差不超过 2 秒手动抽检对话密集镜头转场自然度无黑帧、无闪白全片快速浏览这套清单里最容易忽略的是「镜头时长自动核对」。人眼对时长偏差极不敏感但整集拼接时单个镜头差 1 秒会积累成整集节奏拖沓。我用 ffprobe 批量读取视频时长和分镜 JSON 里的 duration 逐一对齐超过阈值的镜头直接标记为待重生成。6.3 镜头连续性验证的进阶技巧首尾帧对照单镜头生成质量稳定后真正的瓶颈是「连续镜头之间看起来像不是同一集」。这里有一个实用验证方法把每一镜的最后三帧截出来和下一镜的第一帧做结构相似度对比。结构相似度大于 0.75 的说明镜头衔接基本可用低于 0.5 的检查两镜之间是否需要加转场或者用首尾帧重生成。这个计算脚本放在 n8n 的图片处理节点里每集跑完自动生成一份衔接报告省掉人工逐帧拖进度条的时间。我在做了十几集漫剧之后有个习惯每一集的所有分镜 JSON、底图文件、生成参数全部按集数归档。一个月后回看数据比记忆可靠得多——哪条提示词改过、哪个参数在那个镜头翻过车全都在记录里。这些数据就是你这个工作流的「后悔药」。希望帮到你。本文还有配套的精品资源点击获取