企业官网建设流程全解析

简介：开源本地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 又得重新写一遍运动指令。来回翻译三次，两天出一集都算快。这个标题里的「全流程创作工具」本质上是把这几道工序用统一的数据格式串起来——剧本分析模块产出结构化 JSON，AI 分镜基于 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", encoding="utf-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% 比例抽检那些 duration=8 的长镜头。长镜头往往包含多个动作，模型容易把「说话」和「做动作」压缩进同一个镜头描述，导致图片资产阶段很难选一个中间帧作为底图。

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", headers=headers, json=payload, timeout=120 ) 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_scale：3.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 一盘成片的验收清单

自动化跑完不等于能发布，我每集必做的质检清单包括以下几项，按优先级排列：

这套清单里最容易忽略的是「镜头时长自动核对」。人眼对时长偏差极不敏感，但整集拼接时，单个镜头差 1 秒会积累成整集节奏拖沓。我用 ffprobe 批量读取视频时长，和分镜 JSON 里的 duration 逐一对齐，超过阈值的镜头直接标记为待重生成。

6.3 镜头连续性验证的进阶技巧：首尾帧对照

单镜头生成质量稳定后，真正的瓶颈是「连续镜头之间看起来像不是同一集」。这里有一个实用验证方法：把每一镜的最后三帧截出来，和下一镜的第一帧做结构相似度对比。结构相似度大于 0.75 的，说明镜头衔接基本可用；低于 0.5 的，检查两镜之间是否需要加转场或者用首尾帧重生成。这个计算脚本放在 n8n 的图片处理节点里，每集跑完自动生成一份衔接报告，省掉人工逐帧拖进度条的时间。

我在做了十几集漫剧之后有个习惯：每一集的所有分镜 JSON、底图文件、生成参数全部按集数归档。一个月后回看，数据比记忆可靠得多——哪条提示词改过、哪个参数在那个镜头翻过车，全都在记录里。这些数据就是你这个工作流的「后悔药」。希望帮到你。

本文还有配套的精品资源，点击获取