企业官网建设流程全解析

简介：这份资源面向影视创作爱好者与短剧内容创作者，聚焦小说文本到影视作品的全流程 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[i+1].strip() if i+1 < 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(r'```json|```', '', 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_ascii=False)} 章节摘要：{chapter_summary} 每个分镜输出 JSON 对象，字段包括：{json.dumps(STORYBOARD_SCHEMA, ensure_ascii=False)} 注意：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: "./output"

temperature设 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% 的返工。这个习惯帮我省下的算力成本，比任何优化都实在。希望帮到你。

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