企业官网建设流程全解析

简介：Toonflow 是一套面向短剧与漫剧创作者的 AI 一站式生成工具，核心能力是把小说文本自动转化为剧本，并借助 AI 生成的图片与视频素材完成从剧本到成片的自动化流程，适合个人创作者、小团队以及预算有限的短剧漫剧项目使用，能显著降低制作门槛与人力成本。资源包共 190 个文件，整体约 9.93MB，以 155 个 ts 源码文件为主体，辅以 png、jpg 图片素材、yml 与 json 配置、md 与 txt 说明文档，以及 Dockerfile、dockerignore、gitignore、license 等工程化文件，目录结构完整，便于直接部署与二次开发。目前已有 338 人学习下载。借助该资源，读者可快速理解 AI 短剧漫剧的自动化生产链路，掌握剧本转换、视觉素材生成与工程配置的衔接方式，并基于现有代码结构进行功能扩展与本地调试，对希望切入 AI 内容创作领域的开发者具有较高参考价值。

1. Toonflow 到底在解决什么：从小说文本到短剧成片的那条断链

手里有一本几十万字的小说，想把它变成能发出去的短剧漫剧，最卡人的从来不是「有没有 AI」，而是中间那条断链：小说是纯文本叙事，剧本要分场分镜，画面要角色一致，视频要镜头连贯。四个环节各用各的工具，格式对不上，角色对不上，风格对不上，最后拼出来的东西自己都不想看第二遍。Toonflow 这类 AI 短剧漫剧工具瞄准的就是这条链——把小说自动转成剧本，再用 AI 生成的图片和视频把剧本落地成片。它适合两类人：一类是手里有小说版权或授权、想低成本试水短剧的内容方；另一类是懂点技术、想搭一套自动化流水线自己跑量的独立开发者。这篇不吹概念，按「小说进、成片出」的顺序，把每个环节的选型理由、可复现步骤、参数怎么设、哪里会翻车讲清楚，新手能照着搭，熟手能直接看到边界在哪。

2. 小说转剧本：分场、对白、镜头提示词怎么自动拆出来

2.1 为什么不能直接把整本小说丢给大模型

很多人第一反应是写个 prompt，把小说全文塞进去让模型输出剧本。这条路在短篇上能跑通，一上长篇就崩。原因有三个：上下文窗口装不下，几十万字必然要截断，截断处剧情就断了；模型对「第几章第几节」这种结构没有稳定记忆，输出到后面人物关系会漂；最要命的是成本，整本反复喂，token 消耗和输出稳定性完全不成正比。

常见做法是分层处理：先做章节切分，再对每一章做「场景抽取」，最后把场景合并成带镜头提示的剧本。Toonflow 这类工具的核心逻辑也是这个路子——不是一次性转换，而是流水线式逐段处理，每段处理完做一次结构化校验。我一般会把流程拆成四步：章节切分 → 场景识别 → 对白与旁白分离 → 镜头提示词生成。每一步的输出都是结构化 JSON，方便下一步消费，也方便出问题时定位是哪一步烂了。

2.2 章节切分与场景识别的可复现脚本

先解决切分。中文小说的章节标记不统一，有的用「第一章」，有的用「第1章」，有的干脆只有数字。用正则做一轮粗切，再按长度做二次合并，能覆盖九成以上的情况。

import re # 常见中文章节标记：第一章 / 第1章 / 第 1 章 / Chapter 1 CHAPTER_PATTERN = re.compile( r'^\s*(?:第\s*[0-9一二三四五六七八九十百千]+\s*[章节回]|Chapter\s+\d+)\s*.*$', re.MULTILINE ) def split_chapters(raw_text: str, min_len: int = 800): """按章节标记切分，过短的章节与上一章合并""" matches = list(CHAPTER_PATTERN.finditer(raw_text)) if not matches: # 没有章节标记，按固定长度硬切，避免整本进模型 return [raw_text[i:i+3000] for i in range(0, len(raw_text), 3000)] chapters = [] for idx, m in enumerate(matches): start = m.start() end = matches[idx + 1].start() if idx + 1 < len(matches) else len(raw_text) chapters.append(raw_text[start:end].strip()) # 合并过短章节，防止模型对碎片化输入产生幻觉 merged = [] for ch in chapters: if merged and len(ch) < min_len: merged[-1] += "\n" + ch else: merged.append(ch) return merged

这段代码的关键参数是min_len。设太小，模型会收到大量几百字的碎片，场景识别容易把一段对话拆成两个场景；设太大，单章超出模型舒适区，对白和旁白会混。我的经验值是 800 到 1500 字之间，具体看小说本身的段落密度。切分完之后不要急着进模型，先打印每章的前 50 个字人工扫一眼，确认没有把「第一章」这种正文里的词误判成标题——这是最常见的翻车点。

场景识别这一步，我一般用「地点变化 + 时间跳跃 + 主要人物进出」三个信号做判断。让模型对每一章输出场景列表，每个场景带地点、时间、在场人物、剧情摘要。这里有个参数必须调：要求模型只输出 JSON，不要输出解释性文字。很多模型默认会加一句「好的，以下是分析结果」，这行字会直接污染下游解析。

import json SCENE_PROMPT = """你是剧本拆解助手。请把下面这章小说拆成场景列表。 只输出 JSON 数组，不要任何解释文字。每个场景包含字段： location(地点), time(时间), characters(在场人物数组), summary(剧情摘要，50字内), dialogues(对白数组，每项含 speaker 和 line) 小说正文： {chapter_text} """ def extract_scenes(chapter_text: str, llm_client) -> list: resp = llm_client.chat(SCENE_PROMPT.format(chapter_text=chapter_text)) text = resp.strip() # 容错：模型偶尔会包 ```json ``` 代码块 if text.startswith("```"): text = text.split("```")[1] text = text.replace("json", "", 1).strip() try: return json.loads(text) except json.JSONDecodeError: # 解析失败时退回空列表，记录原始输出供排查 print("[WARN] 场景解析失败，原始输出：", text[:200]) return []

dialogues字段是后面做配音和口型的基础，必须在这一步就分离干净。旁白和对白混在一起，到了视频生成阶段你会发现根本没法给角色分配声音。如果模型输出的对白里还夹着「他说道」这种叙述，要在 prompt 里明确要求剥离，或者加一轮后处理正则清洗。

2.3 镜头提示词生成：把场景翻译成图片和视频能懂的描述

场景有了，下一步是把它翻译成图片生成模型和视频生成模型能消费的提示词。这一步的难点在于「一致性」——同一个角色在不同镜头里，外貌描述必须稳定，否则生成出来的图每张脸都不一样，剪在一起就是灾难。

我的做法是维护一份角色档案表，在生成镜头提示词之前先让模型从全书中抽取主要角色的固定描述：性别、年龄段、发型、发色、服装风格、体型特征。这份档案一旦确定就冻结，后续所有镜头提示词都从这里引用，不允许模型自由发挥。

镜头提示词按「景别 + 角色 + 动作 + 环境 + 风格」五段式组织。景别用远景、中景、近景、特写四档，不要用「唯美」「大气」这种模型无法稳定响应的词。风格锚点直接复用角色档案里的style_tag，保证全片色调统一。每个镜头生成完后，把提示词和对应的场景 ID 一起存下来，后面视频生成阶段直接按 ID 取用，不要重新生成，否则又引入一次随机性。

3. 图片与视频生成：角色一致性和镜头连贯怎么保住

3.1 图片生成阶段的三个必调参数

图片生成是整条链里最吃算力也最容易翻车的一环。同一个角色，提示词里描述完全一样，换一次随机种子就换一张脸，这是扩散模型的固有特性，不是工具的问题。要压住这个随机性，有三个参数必须固定。

第一个是种子。角色定妆照生成时选定一个种子，后续该角色的所有镜头都复用这个种子。种子固定后，即使提示词有细微变化，面部特征也会保持相对稳定。第二个是参考图权重。如果工具支持图生图或角色参考，把定妆照作为参考图传入，权重设在 0.6 到 0.75 之间。太低不起作用，太高会导致所有镜头姿势雷同，人物像贴图。第三个是负面提示词。把「多手多脚、面部扭曲、文字水印、多余人物」这些常见崩坏项写进负面提示词，能过滤掉相当一部分废图。

# 图片生成请求的典型参数结构（以常见文生图接口为例） payload = { "prompt": "中景，林晚，黑色长直发，白色衬衫，站在雨夜街头，冷色调，写实风格", "negative_prompt": "多手多脚，面部扭曲，文字，水印，多余人物，模糊", "seed": 20240517, # 角色定妆时确定的种子，全片复用 "width": 768, "height": 1344, # 竖屏短剧常用比例 9:16 "steps": 28, # 步数 20-30 之间，再高收益递减 "cfg_scale": 7, # 提示词遵循度，7 左右比较稳 "reference_image": "linwan_ref.png", "reference_weight": 0.7 # 参考图权重，0.6-0.75 是安全区 }

steps和cfg_scale这两个参数很多人喜欢往高调，觉得越高越精细。实际测下来，步数超过 30 之后画面提升肉眼几乎不可见，但耗时线性增长；cfg 超过 9 画面会变硬，颜色发闷，人物表情僵硬。竖屏短剧的宽高比按发布平台来，9:16 是通用安全值，横屏平台再另说。

3.2 视频生成：首尾帧控制和运动幅度

图片到视频这一步，主流做法有两种：一种是图生视频，给一张起始帧让模型推演运动；另一种是首尾帧控制，给起始帧和结束帧，让模型补中间。短剧漫剧里对话镜头多，人物动作幅度小，首尾帧控制更可控，但准备成本高。我一般对关键剧情镜头用首尾帧，过渡镜头用图生视频。

运动幅度是这里最玄学的参数。设小了，画面几乎静止，像 PPT；设大了，人物五官会扭曲，背景会融化。经验值是把运动幅度控制在 0.3 到 0.5 之间，对话镜头取低值，动作镜头取高值。另外，视频生成对提示词的敏感度比图片低，写太多细节反而干扰，一般只写「镜头缓慢推进」「人物轻微转头」这种运动描述就够了，画面内容交给起始帧。

镜头连贯性还有一个容易被忽略的点：相邻镜头的色调和光线方向要一致。如果上一个镜头是暖光从左打，下一个镜头变成冷光从右打，剪在一起观众会觉得跳。解决办法是在场景级别定义光照方案，同一场景内所有镜头共用一套光照描述，跨场景才换。

3.3 一条最小可跑的生成流水线

把前面几步串起来，一条最小流水线大概长这样：读小说 → 切章 → 抽场景 → 生成角色档案 → 逐场景生成镜头提示词 → 逐镜头生成图片 → 图片转视频 → 按场景拼接。每一步的中间产物都落盘成 JSON 或图片文件，不要只在内存里传递。原因很简单：图片和视频生成又慢又贵，跑到一半失败是常态，中间产物落盘后可以从断点续跑，不用从头再来。

# 目录结构建议，按阶段分目录，方便断点续跑和排查 project/ raw/ # 原始小说文本 chapters/ # 切分后的章节 json scenes/ # 场景抽取结果 json characters/ # 角色档案 json + 定妆照 shots/ # 镜头提示词 json images/ # 生成的图片，按 shot_id 命名 videos/ # 生成的视频片段 output/ # 拼接后的成片

跑批的时候加一层重试和限速。图片和视频接口都有并发限制，闷头并发容易被限流，反而更慢。我一般设 2 到 3 个并发，每个请求失败后指数退避重试三次，三次都失败就记进失败清单，最后统一人工处理。失败清单这个习惯救过我很多次——批量跑几百个镜头，总有那么几个因为提示词触发审核或者网络抖动挂掉，没有清单就得靠肉眼一张张翻。

4. 避坑与排查：这条流水线上最容易翻车的五个地方

4.1 角色脸崩：同一角色不同镜头长得不一样

现象是生成出来的图片里，同一个角色在不同镜头中脸型、发色、五官比例明显不同，剪在一起像换了演员。原因通常是种子没有固定，或者参考图权重设得太低，模型每次都在自由发挥。解决办法是把角色定妆照作为强参考传入，种子全片锁定，参考图权重提到 0.7 左右。如果工具支持角色 LoRA 或身份嵌入，优先用那个，比单纯靠参考图稳得多。还有一个隐蔽原因是提示词里角色描述每次措辞不同，比如这次写「黑色长直发」，下次写「黑长发」，模型理解成两个特征。角色档案冻结后，所有镜头提示词必须从档案里字符串拼接，不允许手写。

4.2 场景解析返回非 JSON：下游全挂

现象是场景抽取那一步偶尔返回一段带解释文字的输出，json.loads直接抛异常，整章场景为空，后面全断。原因是模型没有严格遵守「只输出 JSON」的指令，尤其是换了模型版本或者调了温度参数之后。解决办法有三层：prompt 里把「只输出 JSON」放在最后一句加强；解析前先做代码块剥离和首尾大括号截取；解析失败时记录原始输出并重试一次，重试时把温度调到 0。温度这个参数对结构化输出影响很大，抽取类任务一律用 0 或接近 0 的值，不要用默认的 0.7。

4.3 视频片段首尾不接：拼接处跳帧

现象是相邻两个视频片段拼在一起时，画面明显跳一下，人物位置或背景对不上。原因是每个片段独立生成，起始帧和上一个片段的结束帧没有关联。解决办法是在镜头设计阶段就规划好衔接：下一个镜头的起始帧尽量复用上一个镜头的结束帧，或者至少保持机位和光照一致。如果工具支持，把上一个片段的最后一帧导出作为下一个片段的起始帧输入，能大幅减少跳变。这个操作会增加准备步骤，但对成片质量提升很明显，值得做。

4.4 对白和口型对不上：配音阶段才发现

现象是视频生成完了，配音贴上去发现口型完全对不上，人物嘴在动但节奏是乱的。根本原因是对白在场景抽取阶段没有精确到时间轴，只有一个文本列表。解决办法是在剧本阶段就给每句对白标注预估时长，按字数除以语速估算，中文一般每秒 4 到 5 个字。有了时长，视频生成时才能按对白节奏设计口型镜头，配音时也能按时间轴对齐。这一步前置做，比后期硬对口型省事得多。

4.5 批量跑批中途限流：任务卡死没有反馈

现象是批量生成跑到一半突然全部失败，日志里只有超时，没有明确错误码。原因是并发数设太高触发了接口限流，或者单次请求体太大被拒。解决办法是把并发降到 2 到 3，请求之间加固定间隔，失败重试用指数退避。同时给每个任务加唯一 ID 和状态记录，跑批结束后统计成功数和失败数，失败的任务输出 ID 清单。没有这层记录，几百个任务里挂掉几个根本发现不了，等成片出来才发现缺镜头，返工成本极高。

5. 把成片质量再抬一档：镜头节奏和批量产出的取舍

流水线跑通之后，真正拉开差距的不是模型多强，而是镜头节奏。短剧漫剧的观众耐心极低，前几秒抓不住就划走了。我一般会把每个场景的第一个镜头设成信息量最大的画面，景别用中景或近景，不要用远景慢慢推。对话镜头之间穿插空镜和特写，避免连续三个以上同景别镜头，否则画面会平。单集时长控制在 60 到 90 秒，超过这个长度完播率断崖式下跌。

批量产出和质量之间有个取舍点必须想清楚：全自动跑量适合做测试和铺量，但真正要推的片子，关键镜头还是得人工挑图、人工调提示词。我的习惯是让流水线跑出三倍于成片需要的素材，然后人工从中挑，挑中的镜头再单独精修。这样既保留了自动化的效率，又在关键处保住了质量。全自动一把出片听起来很美，实际跑下来废片率会让你怀疑人生。

验证一套流水线是否稳定，有个简单办法：拿同一章小说跑三遍，对比三次输出的场景数和镜头数。如果三次差异超过 20%，说明某个环节的随机性没压住，优先去查温度参数和种子。稳定之后再上量，不然量越大返工越狠。

这套东西我从最开始整本丢模型，到后来拆成流水线加人工挑图，前后翻车无数次才跑顺。最大的教训是别指望一步到位，先把最小链路跑通，再逐个环节加约束。希望帮到你。

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