简介这份资源面向影视创作爱好者与短剧内容创作者聚焦小说文本到影视作品的全流程 AI 转换适合希望降低制作门槛、快速验证创意的个人创作者与小型团队。压缩包共 197 个文件约 9.63MB以 106 个 ts 与 69 个 tsx 源码文件为主体辅以 png 图标资源、json 配置、js 脚本及 css、html 等前端文件整体呈现为一个结构完整的 AI 影视工具项目工程。已有 39 人学习关注可作为了解 AI 短剧漫剧工具实现思路的参考样本。读者可从中获取小说转剧本、场景与角色生成、图像视频素材匹配等环节的工程组织方式借助 tailwind、postcss、eslint 等配置理解项目构建与代码规范并参考 quality-rules 等规则文件梳理内容质量控制逻辑为二次开发或功能扩展提供可复用的目录结构与实现线索。1. 小说转影视的工程化落地NS AI Animata 到底解决了哪段流水线手里有一部三十万字的小说想把它变成能看的短剧或漫剧传统路径是先拆章节、再写分镜、再画角色、再配音、再剪辑五拨人接力周期以月计。NS AI Animata 这类工具瞄准的正是这条流水线里最耗人力的前四段把小说文本自动拆成剧本结构、生成分镜描述、驱动画面与配音、最后合成可预览的视频片段。它适合两类人一类是手里有文本版权但缺制作资源的内容方另一类是懂一点 Python、想用 AI 工作流批量产出短剧的独立开发者。核心问题从来不是“能不能生成”而是“生成的东西能不能连起来、角色会不会崩、口型对不对得上”。这篇笔记按我实际搭过的一套流程把小说转影视的每个环节拆开讲包括参数怎么设、哪里容易翻车、怎么验证输出是否可用。2. 从小说文本到结构化剧本拆解与角色抽取的工程做法2.1 为什么不能直接把整本小说丢给大模型一本二十万字的小说按中文字符粗算约 40 万 token主流大模型的单次上下文窗口在 32K 到 128K 之间直接整本输入要么被截断要么成本高到不可接受。更麻烦的是长文本里角色关系复杂模型在生成到后半段时容易“忘记”前面的人设导致角色性格漂移。常见做法是先把小说按章节切分再对每章做一次结构化抽取最后把抽取结果汇总成全局角色表和分场大纲。这个思路和 AI 工作流里“分而治之”的原则一致也是目前小说转影视工具普遍采用的预处理策略。切分不是简单按字数切。小说里一章可能只有两千字也可能一万字按固定长度切会把对话和场景拦腰截断。我一般按自然章节切如果单章超过 8000 字再按场景分隔符空行、地点转换句二次切分。切完之后每段控制在 3000 到 5000 字这个长度既能保留完整场景又不会让模型丢失上下文。2.2 用 Python 做章节切分与角色抽取下面这段代码做两件事按章节标题切分小说然后对每章调用大模型抽取角色和场景信息。实际运行时把model_client换成你用的 API 客户端即可。import re import json def split_novel(text): # 按常见章节标题切分第X章、Chapter X、卷X等 pattern r(第[一二三四五六七八九十百千\d]章[^\n]*|Chapter\s\d[^\n]*) parts re.split(pattern, text) chapters [] # re.split 会把分隔符也放进结果需要重组 for i in range(1, len(parts), 2): title parts[i].strip() body parts[i1].strip() if i1 len(parts) else if len(body) 200: # 过滤掉误匹配的短片段 chapters.append({title: title, body: body}) return chapters def extract_characters(chapter_text, model_client): prompt f从以下小说片段中抽取角色和场景信息输出 JSON {{ characters: [{{name: , role: 主角/配角, traits: , appearance: }}], scenes: [{{location: , time: , summary: }}] }} 小说片段 {chapter_text[:4000]} resp model_client.chat(prompt) try: return json.loads(resp) except json.JSONDecodeError: # 模型偶尔会带 markdown 代码块标记做一次清洗 cleaned re.sub(rjson|, , resp).strip() return json.loads(cleaned)split_novel里的正则覆盖了“第X章”和“Chapter X”两种常见格式如果你的小说用“序章”“尾声”这类标题需要把关键词补进正则。extract_characters里把输入截到 4000 字符是因为抽取任务不需要全文取章节开头部分通常已经包含主要角色出场信息。JSON 解析失败时做一次 markdown 清洗这是血泪经验——模型输出 JSON 时经常裹一层代码块标记不清洗直接json.loads会抛异常。2.3 角色表合并与去重每章抽出来的角色是分散的同一个人在不同章节可能叫“林医生”“林晓”“晓姐”。合并时不能只靠名字精确匹配需要做一次相似度聚类。简单做法是用编辑距离加别名表如果两个名字的编辑距离小于阈值或者一个名字是另一个的子串就合并。更稳的做法是把所有角色名和描述丢给模型做一次全局归并让它输出标准角色表。这一步做完你手里就有一份带外貌特征和性格标签的角色清单后面生成分镜和画面时直接引用能大幅降低角色崩坏的概率。3. 分镜生成与画面一致性控制参数怎么设、模型怎么选3.1 分镜描述的结构化模板分镜不是简单地把小说句子翻译成画面描述。一个可用的分镜至少包含镜号、场景地点、时间、角色、动作、景别、镜头运动、对白。我一般让模型按固定 JSON schema 输出这样后面驱动图像生成时可以直接解析字段不用再做自然语言理解。STORYBOARD_SCHEMA { shot_id: int, location: str, time_of_day: str, characters: [str], action: str, shot_size: str, # 远景/全景/中景/近景/特写 camera_move: str, # 固定/推/拉/摇/移 dialogue: str, image_prompt: str # 给图像生成模型的英文提示词 } def generate_storyboard(chapter_summary, character_table, model_client): prompt f根据以下章节摘要和角色表生成分镜列表。 角色表{json.dumps(character_table, ensure_asciiFalse)} 章节摘要{chapter_summary} 每个分镜输出 JSON 对象字段包括{json.dumps(STORYBOARD_SCHEMA, ensure_asciiFalse)} 注意image_prompt 用英文包含角色外貌关键词和场景关键词不要出现具体人名用角色特征代替。 return model_client.chat(prompt)image_prompt字段要求用英文且不出现具体人名是因为图像生成模型对中文人名的理解不稳定用“a young doctor with short black hair”比“林晓”更容易得到一致的形象。角色表里的appearance字段就是给这里用的把外貌特征拼进 prompt同一角色在不同分镜里才能长得像。3.2 画面一致性的三个控制手段角色崩是小说转影视最常见的翻车点。同一个角色第一镜是圆脸第三镜变成方脸观众立刻出戏。控制一致性有三个层次第一层是 prompt 层面把角色外貌特征固定成一段模板文本每个分镜都带上第二层是参考图层面先用角色表生成一张标准角色图后续分镜用图生图或 IP-Adapter 这类方式锁定面部特征第三层是后期层面如果前两层还不够就在剪辑时用换脸工具做统一。我一般用第二层为主、第一层为辅。标准角色图的生成 prompt 要尽量详细包括脸型、发型、发色、眼睛、服装、年龄感。生成之后人工挑一张最符合预期的存成参考图。后续每个分镜生成时把参考图作为条件输入。参数上参考图的权重类似 IP-Adapter 的 scale设在 0.6 到 0.8 之间比较稳太低锁不住脸太高会导致所有画面都像同一张图动作和场景变化被压制。3.3 配音与口型同步的工程取舍配音这块TTS 模型现在成熟度很高按角色分配不同音色即可。难点在口型同步。如果做的是漫剧风格口型同步要求可以放宽观众对漫剧的口型容忍度比真人短剧高得多。如果做真人风格口型同步就需要专门的模型来处理计算成本会上去。我的取舍是先做漫剧风格跑通全流程验证内容质量再决定是否升级到真人口型。漫剧风格下配音和画面分开生成剪辑时对齐时间轴就行。真人风格下需要把每句对白的音频和对应分镜的画面一起送进口型模型输出带口型驱动的视频片段。这一步的算力消耗大概是画面生成的 2 到 3 倍批量做之前先算清楚成本。4. 避坑与排查小说转影视流水线里最容易翻车的五个地方4.1 章节切分把对话截断角色抽取漏人现象生成的角色表里少了某个重要配角后面分镜里这个人突然出现但没有外貌描述画面生成时形象完全随机。原因按固定字数切分时角色出场的对话被切到了下一章而抽取只看了当前章。解决切分时保留前后各 200 字的重叠窗口抽取时把重叠部分也纳入。或者在合并角色表时对每个角色做一次全局扫描确认它在哪些章节出现过漏掉的补抽。4.2 分镜 JSON 解析失败导致整批中断现象批量生成分镜时跑到第 37 章突然报 JSON 解析错误前面 36 章的结果已经写入后面全部停住。原因模型输出偶尔带 markdown 标记、注释或多余逗号json.loads直接抛异常。解决解析函数里加三层兜底——先尝试直接解析失败则清洗 markdown 标记再解析再失败则用正则提取最外层花括号内容。同时把每章结果单独存文件失败时记录章节号支持断点续跑不要整批重来。4.3 图像生成 prompt 里人名导致角色形象漂移现象同一个角色第一镜生成的是黑发第五镜变成棕发第十镜变成短发。原因image_prompt里直接写了角色名图像模型对中文人名的理解每次都不一样相当于每次都在随机抽形象。解决prompt 里禁止出现人名全部用角色外貌模板替换。角色表里的appearance字段写成固定英文描述每次生成时拼进去。如果还漂移上参考图方案。4.4 配音语速和画面时长对不上现象一句对白配音只有 2 秒但对应分镜画面生成了 5 秒剪辑时要么画面定格要么配音被截断。原因画面生成时没有考虑对白时长TTS 输出也没有做时长预估。解决先生成配音拿到每句对白的精确时长再按这个时长去生成或裁剪画面。图像生成模型一般不支持指定视频时长所以实际做法是生成一段视频后按配音时长裁剪或者用支持时长参数的视频生成模型。TTS 这边可以在文本里加停顿标记来控制节奏让语速和画面节奏匹配。4.5 批量生成时 API 限流导致任务卡死现象晚上挂机跑 100 章早上起来发现只跑了 12 章日志里全是 429 错误。原因没有做请求频率控制触发 API 限流后重试策略太激进反而被拉黑更久。解决加一个令牌桶限流器控制每秒请求数。重试用指数退避第一次等 1 秒第二次 2 秒第三次 4 秒最多重试 5 次。同时把任务队列持久化到本地文件进程重启后能从断点继续不用从头跑。5. 批量产出与质量抽检把小说转影视做成可复用的工作流5.1 用配置文件驱动整条流水线跑到第三部小说的时候我意识到每次改参数都要翻代码太蠢了。后来把所有可调项抽到一个 YAML 配置文件里代码只读配置不写死任何模型名和参数。这样换模型、调权重、改并发数都不用动代码。# pipeline_config.yaml novel: input_path: ./novels/book_01.txt chapter_min_length: 200 chapter_max_length: 8000 llm: provider: your_llm_provider model: your_model_name max_tokens: 4096 temperature: 0.3 image: model: your_image_model reference_image_dir: ./refs ip_adapter_scale: 0.7 width: 1024 height: 576 tts: voice_map: 主角: voice_id_01 配角A: voice_id_02 speed: 1.0 pipeline: max_workers: 4 retry_times: 5 output_dir: ./outputtemperature设 0.3 是为了让抽取和分镜生成更稳定创意类任务可以调到 0.7 以上。ip_adapter_scale就是前面说的参考图权重0.7 是漫剧风格的常用值。max_workers控制并发设太高会触发限流设太低跑得慢4 到 8 之间比较平衡。5.2 质量抽检的四个指标批量产出最怕的是“跑完了但没法看”。我一般抽检四个指标角色一致性、分镜连贯性、配音匹配度、画面可用率。角色一致性靠人工看抽 10 个分镜里同一角色出现 3 次以上看形象是否统一。分镜连贯性看相邻分镜的场景和动作是否接得上有没有跳变。配音匹配度看口型和语速漫剧风格下主要看语速。画面可用率是统计生成结果里没有明显畸变的比例低于 70% 就要回头调 prompt 或参考图权重。抽检不用全量看按 10% 比例随机抽如果抽检合格率低于 80%整批回炉。这个比例是我踩过几次坑之后定的低于 80% 意味着后面剪辑要花大量时间修补不如重新生成。5.3 一个具体技巧用“分镜预览图”提前发现问题在正式生成视频之前先生成一套低分辨率的分镜预览图把所有分镜的画面构图和角色位置先确认一遍。这一步成本很低图像生成用低分辨率、少步数几分钟就能跑完一章。预览图确认没问题再跑高分辨率视频生成。这样能把大部分构图和角色问题拦在昂贵的视频生成之前。我现在的习惯是每部小说先跑前三章人工看完预览图和配音确认风格和参数没问题再挂机跑全本。前三章大概占总量的 5% 到 10%但能避免后面 90% 的返工。这个习惯帮我省下的算力成本比任何优化都实在。希望帮到你。本文还有配套的精品资源点击获取
小说转影视AI工作流：从文本拆解到分镜生成的工程化实践
简介这份资源面向影视创作爱好者与短剧内容创作者聚焦小说文本到影视作品的全流程 AI 转换适合希望降低制作门槛、快速验证创意的个人创作者与小型团队。压缩包共 197 个文件约 9.63MB以 106 个 ts 与 69 个 tsx 源码文件为主体辅以 png 图标资源、json 配置、js 脚本及 css、html 等前端文件整体呈现为一个结构完整的 AI 影视工具项目工程。已有 39 人学习关注可作为了解 AI 短剧漫剧工具实现思路的参考样本。读者可从中获取小说转剧本、场景与角色生成、图像视频素材匹配等环节的工程组织方式借助 tailwind、postcss、eslint 等配置理解项目构建与代码规范并参考 quality-rules 等规则文件梳理内容质量控制逻辑为二次开发或功能扩展提供可复用的目录结构与实现线索。1. 小说转影视的工程化落地NS AI Animata 到底解决了哪段流水线手里有一部三十万字的小说想把它变成能看的短剧或漫剧传统路径是先拆章节、再写分镜、再画角色、再配音、再剪辑五拨人接力周期以月计。NS AI Animata 这类工具瞄准的正是这条流水线里最耗人力的前四段把小说文本自动拆成剧本结构、生成分镜描述、驱动画面与配音、最后合成可预览的视频片段。它适合两类人一类是手里有文本版权但缺制作资源的内容方另一类是懂一点 Python、想用 AI 工作流批量产出短剧的独立开发者。核心问题从来不是“能不能生成”而是“生成的东西能不能连起来、角色会不会崩、口型对不对得上”。这篇笔记按我实际搭过的一套流程把小说转影视的每个环节拆开讲包括参数怎么设、哪里容易翻车、怎么验证输出是否可用。2. 从小说文本到结构化剧本拆解与角色抽取的工程做法2.1 为什么不能直接把整本小说丢给大模型一本二十万字的小说按中文字符粗算约 40 万 token主流大模型的单次上下文窗口在 32K 到 128K 之间直接整本输入要么被截断要么成本高到不可接受。更麻烦的是长文本里角色关系复杂模型在生成到后半段时容易“忘记”前面的人设导致角色性格漂移。常见做法是先把小说按章节切分再对每章做一次结构化抽取最后把抽取结果汇总成全局角色表和分场大纲。这个思路和 AI 工作流里“分而治之”的原则一致也是目前小说转影视工具普遍采用的预处理策略。切分不是简单按字数切。小说里一章可能只有两千字也可能一万字按固定长度切会把对话和场景拦腰截断。我一般按自然章节切如果单章超过 8000 字再按场景分隔符空行、地点转换句二次切分。切完之后每段控制在 3000 到 5000 字这个长度既能保留完整场景又不会让模型丢失上下文。2.2 用 Python 做章节切分与角色抽取下面这段代码做两件事按章节标题切分小说然后对每章调用大模型抽取角色和场景信息。实际运行时把model_client换成你用的 API 客户端即可。import re import json def split_novel(text): # 按常见章节标题切分第X章、Chapter X、卷X等 pattern r(第[一二三四五六七八九十百千\d]章[^\n]*|Chapter\s\d[^\n]*) parts re.split(pattern, text) chapters [] # re.split 会把分隔符也放进结果需要重组 for i in range(1, len(parts), 2): title parts[i].strip() body parts[i1].strip() if i1 len(parts) else if len(body) 200: # 过滤掉误匹配的短片段 chapters.append({title: title, body: body}) return chapters def extract_characters(chapter_text, model_client): prompt f从以下小说片段中抽取角色和场景信息输出 JSON {{ characters: [{{name: , role: 主角/配角, traits: , appearance: }}], scenes: [{{location: , time: , summary: }}] }} 小说片段 {chapter_text[:4000]} resp model_client.chat(prompt) try: return json.loads(resp) except json.JSONDecodeError: # 模型偶尔会带 markdown 代码块标记做一次清洗 cleaned re.sub(rjson|, , resp).strip() return json.loads(cleaned)split_novel里的正则覆盖了“第X章”和“Chapter X”两种常见格式如果你的小说用“序章”“尾声”这类标题需要把关键词补进正则。extract_characters里把输入截到 4000 字符是因为抽取任务不需要全文取章节开头部分通常已经包含主要角色出场信息。JSON 解析失败时做一次 markdown 清洗这是血泪经验——模型输出 JSON 时经常裹一层代码块标记不清洗直接json.loads会抛异常。2.3 角色表合并与去重每章抽出来的角色是分散的同一个人在不同章节可能叫“林医生”“林晓”“晓姐”。合并时不能只靠名字精确匹配需要做一次相似度聚类。简单做法是用编辑距离加别名表如果两个名字的编辑距离小于阈值或者一个名字是另一个的子串就合并。更稳的做法是把所有角色名和描述丢给模型做一次全局归并让它输出标准角色表。这一步做完你手里就有一份带外貌特征和性格标签的角色清单后面生成分镜和画面时直接引用能大幅降低角色崩坏的概率。3. 分镜生成与画面一致性控制参数怎么设、模型怎么选3.1 分镜描述的结构化模板分镜不是简单地把小说句子翻译成画面描述。一个可用的分镜至少包含镜号、场景地点、时间、角色、动作、景别、镜头运动、对白。我一般让模型按固定 JSON schema 输出这样后面驱动图像生成时可以直接解析字段不用再做自然语言理解。STORYBOARD_SCHEMA { shot_id: int, location: str, time_of_day: str, characters: [str], action: str, shot_size: str, # 远景/全景/中景/近景/特写 camera_move: str, # 固定/推/拉/摇/移 dialogue: str, image_prompt: str # 给图像生成模型的英文提示词 } def generate_storyboard(chapter_summary, character_table, model_client): prompt f根据以下章节摘要和角色表生成分镜列表。 角色表{json.dumps(character_table, ensure_asciiFalse)} 章节摘要{chapter_summary} 每个分镜输出 JSON 对象字段包括{json.dumps(STORYBOARD_SCHEMA, ensure_asciiFalse)} 注意image_prompt 用英文包含角色外貌关键词和场景关键词不要出现具体人名用角色特征代替。 return model_client.chat(prompt)image_prompt字段要求用英文且不出现具体人名是因为图像生成模型对中文人名的理解不稳定用“a young doctor with short black hair”比“林晓”更容易得到一致的形象。角色表里的appearance字段就是给这里用的把外貌特征拼进 prompt同一角色在不同分镜里才能长得像。3.2 画面一致性的三个控制手段角色崩是小说转影视最常见的翻车点。同一个角色第一镜是圆脸第三镜变成方脸观众立刻出戏。控制一致性有三个层次第一层是 prompt 层面把角色外貌特征固定成一段模板文本每个分镜都带上第二层是参考图层面先用角色表生成一张标准角色图后续分镜用图生图或 IP-Adapter 这类方式锁定面部特征第三层是后期层面如果前两层还不够就在剪辑时用换脸工具做统一。我一般用第二层为主、第一层为辅。标准角色图的生成 prompt 要尽量详细包括脸型、发型、发色、眼睛、服装、年龄感。生成之后人工挑一张最符合预期的存成参考图。后续每个分镜生成时把参考图作为条件输入。参数上参考图的权重类似 IP-Adapter 的 scale设在 0.6 到 0.8 之间比较稳太低锁不住脸太高会导致所有画面都像同一张图动作和场景变化被压制。3.3 配音与口型同步的工程取舍配音这块TTS 模型现在成熟度很高按角色分配不同音色即可。难点在口型同步。如果做的是漫剧风格口型同步要求可以放宽观众对漫剧的口型容忍度比真人短剧高得多。如果做真人风格口型同步就需要专门的模型来处理计算成本会上去。我的取舍是先做漫剧风格跑通全流程验证内容质量再决定是否升级到真人口型。漫剧风格下配音和画面分开生成剪辑时对齐时间轴就行。真人风格下需要把每句对白的音频和对应分镜的画面一起送进口型模型输出带口型驱动的视频片段。这一步的算力消耗大概是画面生成的 2 到 3 倍批量做之前先算清楚成本。4. 避坑与排查小说转影视流水线里最容易翻车的五个地方4.1 章节切分把对话截断角色抽取漏人现象生成的角色表里少了某个重要配角后面分镜里这个人突然出现但没有外貌描述画面生成时形象完全随机。原因按固定字数切分时角色出场的对话被切到了下一章而抽取只看了当前章。解决切分时保留前后各 200 字的重叠窗口抽取时把重叠部分也纳入。或者在合并角色表时对每个角色做一次全局扫描确认它在哪些章节出现过漏掉的补抽。4.2 分镜 JSON 解析失败导致整批中断现象批量生成分镜时跑到第 37 章突然报 JSON 解析错误前面 36 章的结果已经写入后面全部停住。原因模型输出偶尔带 markdown 标记、注释或多余逗号json.loads直接抛异常。解决解析函数里加三层兜底——先尝试直接解析失败则清洗 markdown 标记再解析再失败则用正则提取最外层花括号内容。同时把每章结果单独存文件失败时记录章节号支持断点续跑不要整批重来。4.3 图像生成 prompt 里人名导致角色形象漂移现象同一个角色第一镜生成的是黑发第五镜变成棕发第十镜变成短发。原因image_prompt里直接写了角色名图像模型对中文人名的理解每次都不一样相当于每次都在随机抽形象。解决prompt 里禁止出现人名全部用角色外貌模板替换。角色表里的appearance字段写成固定英文描述每次生成时拼进去。如果还漂移上参考图方案。4.4 配音语速和画面时长对不上现象一句对白配音只有 2 秒但对应分镜画面生成了 5 秒剪辑时要么画面定格要么配音被截断。原因画面生成时没有考虑对白时长TTS 输出也没有做时长预估。解决先生成配音拿到每句对白的精确时长再按这个时长去生成或裁剪画面。图像生成模型一般不支持指定视频时长所以实际做法是生成一段视频后按配音时长裁剪或者用支持时长参数的视频生成模型。TTS 这边可以在文本里加停顿标记来控制节奏让语速和画面节奏匹配。4.5 批量生成时 API 限流导致任务卡死现象晚上挂机跑 100 章早上起来发现只跑了 12 章日志里全是 429 错误。原因没有做请求频率控制触发 API 限流后重试策略太激进反而被拉黑更久。解决加一个令牌桶限流器控制每秒请求数。重试用指数退避第一次等 1 秒第二次 2 秒第三次 4 秒最多重试 5 次。同时把任务队列持久化到本地文件进程重启后能从断点继续不用从头跑。5. 批量产出与质量抽检把小说转影视做成可复用的工作流5.1 用配置文件驱动整条流水线跑到第三部小说的时候我意识到每次改参数都要翻代码太蠢了。后来把所有可调项抽到一个 YAML 配置文件里代码只读配置不写死任何模型名和参数。这样换模型、调权重、改并发数都不用动代码。# pipeline_config.yaml novel: input_path: ./novels/book_01.txt chapter_min_length: 200 chapter_max_length: 8000 llm: provider: your_llm_provider model: your_model_name max_tokens: 4096 temperature: 0.3 image: model: your_image_model reference_image_dir: ./refs ip_adapter_scale: 0.7 width: 1024 height: 576 tts: voice_map: 主角: voice_id_01 配角A: voice_id_02 speed: 1.0 pipeline: max_workers: 4 retry_times: 5 output_dir: ./outputtemperature设 0.3 是为了让抽取和分镜生成更稳定创意类任务可以调到 0.7 以上。ip_adapter_scale就是前面说的参考图权重0.7 是漫剧风格的常用值。max_workers控制并发设太高会触发限流设太低跑得慢4 到 8 之间比较平衡。5.2 质量抽检的四个指标批量产出最怕的是“跑完了但没法看”。我一般抽检四个指标角色一致性、分镜连贯性、配音匹配度、画面可用率。角色一致性靠人工看抽 10 个分镜里同一角色出现 3 次以上看形象是否统一。分镜连贯性看相邻分镜的场景和动作是否接得上有没有跳变。配音匹配度看口型和语速漫剧风格下主要看语速。画面可用率是统计生成结果里没有明显畸变的比例低于 70% 就要回头调 prompt 或参考图权重。抽检不用全量看按 10% 比例随机抽如果抽检合格率低于 80%整批回炉。这个比例是我踩过几次坑之后定的低于 80% 意味着后面剪辑要花大量时间修补不如重新生成。5.3 一个具体技巧用“分镜预览图”提前发现问题在正式生成视频之前先生成一套低分辨率的分镜预览图把所有分镜的画面构图和角色位置先确认一遍。这一步成本很低图像生成用低分辨率、少步数几分钟就能跑完一章。预览图确认没问题再跑高分辨率视频生成。这样能把大部分构图和角色问题拦在昂贵的视频生成之前。我现在的习惯是每部小说先跑前三章人工看完预览图和配音确认风格和参数没问题再挂机跑全本。前三章大概占总量的 5% 到 10%但能避免后面 90% 的返工。这个习惯帮我省下的算力成本比任何优化都实在。希望帮到你。本文还有配套的精品资源点击获取
