企业官网建设流程全解析

简介：面向希望借助AI工具快速创作短剧的开发者与内容创作者，这套代码包含用于演示AiPy生成短剧的完整流程，覆盖提示词构建剧本大纲、镜头与风格设计、旁白及分镜头视频生成，直至最终合成音视频，适合无专业编剧背景但想尝试AI影视化制作的用户参考学习。压缩包共3个文件，以HTML教程页为主要内容，附带inscode项目配置文件与gitignore忽略文件，便于在不同环境中快速查看和复用配置，整体仅7KB，非常轻量。当前已有1084人学习浏览，内容被验证为实用。教程内提供具体操作步骤和丰富提示词示例，读者不仅能掌握从剧本到成片的完整制作方法，还能通过源码理解AI短剧背后的内容生成逻辑与算法，包括人物一致性处理、视频编辑和音频合成等关键环节，对入门AI内容创作或二次开发具有实际参考价值。 做AI短剧这件事，我从去年底开始断断续续折腾了大半年。坦白讲，早期用文生视频工具只能产出零星几条“特效片段”，真正能串成一部有剧情、有台词、有节奏的短剧，靠的是把剧本生成、分镜拆解、角色一致性控制、批量视频合成这些环节串成一条工业流水线。这篇教程把我最终跑通的一套完整流程和源码结构拆给你，包含提示词模板、Python脚本、参数配置，以及我踩过的真实坑位。适合已经试过AI视频工具、想认真做系列短剧的创作者，也适合想用AI做批量内容测试的团队参考。

1. 项目概述与整体设计思路

1.1 为什么这个时间点做AI短剧

短剧本身就是快节奏内容，三秒一个钩子、八秒一个反转，单镜头时长普遍在3到8秒。而目前主流的文生视频模型，单次生成时长集中在5秒到10秒，恰好落在短剧镜头的舒适区间内。也就是说，模型能力和内容形态天然匹配，这不是硬凑出来的玩法。

另一个现实是，短剧对画面精细度的要求远低于电影和广告片，观众更在意的是剧情密度、角色辨识度和情绪节奏。AI生成视频常见的细节崩坏、手指异常、透视不稳等问题，在快切镜头下反而容易被忽略。我实测下来，只要分镜切得够快、情绪铺垫到位，AI画面的瑕疵对观看体验的影响会被压到很低。

但这里有一个关键认知：AI短剧的难点根本不在“生成画面”，而在于“组织画面”。一部60集的竖屏短剧，按每集30个镜头算，就是1800个镜头。如果靠网页工具一个个手工生成、手工拼接，效率低到根本不具备可落地性。所以这个项目从一开始就被我定义成一个工程问题，而不是一个创意问题。

1.2 五段式工作流：从剧本到成片的管线设计

我最终跑通的工作流分成五段，每一段都有明确的输入输出边界，方便单独调试和替换模型：

1. 剧本生成：用大模型产出分集梗概、台词、角色关系，并输出结构化字段。
2. 分镜拆解：把每一场戏拆成“镜头级”脚本，包含景别、机位、动作、台词、情绪、时长。
3. 角色一致性：为每个主要角色生成统一设定描述和参考图，并在所有镜头提示词中固定使用。
4. 视频生成：调用文生视频接口，逐镜头生成视频片段。
5. 配音合成：将TTS配音、背景音乐、音效和字幕通过FFmpeg拼合成成片。

这五段里，前两段追求的是“结构清晰”，让机器能读懂剧本；中间两段追求的是“参数统一”，保证角色不漂移；最后一段追求的是“批量可控”，让30集内容能一次性合成，而不是一集集手动剪。

1.3 为什么必须配源码而不是纯靠网页工具

市面上绝大多数讲AI短剧的内容，都停留在“用工具点两下”的层面。那种路子做一个短片可以，做一部完整的剧不行。原因很简单：

• 网页操作无法统一管理几百个镜头的参数，很容易出现同一个角色在不同镜头里描述不一致。
• 文生视频接口有频率限制和超时风险，纯手工操作时一旦失败就要重新点一遍，没有断点续跑能力。
• 后期合成需要按镜头编号精确拼接，纯剪辑软件手工对轨一集还能忍，三十集就完全失控。

所以我把项目落成了一组Python源码，把所有环节串联起来。这不是炫技，而是内容规模到达一定程度后的唯一选择。源码的意义在于：参数可复现、过程可回溯、失败可重试。

2. 核心细节解析与实操要点

2.1 提示词设计：让大模型输出可直接执行的JSON分镜

剧本生成阶段最忌讳让大模型自由发挥成一段散文，那样后期根本没法加工。我用的方法是给模型定义一个强约束的输出格式，让它必须返回JSON数组，每个元素包含固定字段。

我常用的System Prompt是这样设计的：

你是一名短剧编剧。请根据以下故事梗概，生成一集完整的分镜脚本。 要求： 1. 每场戏拆成3-5个镜头，每个镜头输出一个JSON对象。 2. 字段必须包含：scene（场次）、shot（镜头序号）、scale（景别）、camera（机位运动）、action（角色动作）、line（台词）、emotion（情绪）、duration（预估时长秒）。 3. 文本禁止出现解释性文字，只输出JSON数组。

加上输出格式约束之后，大模型返回的内容可以直接被json.loads()解析，省去了大量清洗工作。我这里加了response_format={"type": "json_object"}，如果你用的API不支持这个参数，就在Prompt里反复强调“只输出JSON”。

这里有个非常实用的细节：景别描述一定要用行业黑话，比如“特写”“中景”“过肩”“俯拍”，不要用“画面近一点”这种模糊表达。因为后续这些字段会直接拼进生视频提示词里，模型对“close-up shot”的理解远好于对“画面近一点”的理解。

2.2 角色一致性：AI短剧最大的拦路虎

角色长相漂移是AI短剧最劝退的问题。同一角色上一集还是圆脸，下一集变成方脸，观众立刻出戏。我实测下来，有三套方案可以解决，按成本从低到高排列：

我最常用的组合是“固定描述词+角色参考图”。具体操作是：先用文生图模型生成一张角色正面照，固定住发型、发色、服装颜色、配饰这四个核心特征，然后把这张图的编码ID或URL写进后续每个视频生成请求里，同时在提示词里保持角色描述完全一致。

注意事项：角色描述词一旦定稿就不要频繁改动，每改一次就等于给模型换了一个人物设定。我习惯把每个角色的描述词放在一个characters.json文件里，所有脚本统一读取，从源头避免“一稿一改”的灾难。

2.3 视频生成参数：那些必须抠死的细节

同样是文生视频接口，参数不同，出片效果天差地别。我列一份自己常用的参数表，你可以直接抄：

这里尤其要强调单次时长。目前大多数视频模型的10秒生成效果都不如5秒稳定，而且10秒片段一旦某个部分崩了，整段都要重新生成。我的策略是：所有动作戏、转场戏一律用5秒生成，然后用FFmpeg拼接，宁可多生成两个镜头，也不赌一次生成十秒。

2.4 配音和字幕：容易被低估的体验关键

画面AI化了，但如果配音还是机械TTS，观众一眼就能感觉出“廉价感”。我前期踩过最大的坑是直接用基础款TTS，结果旁白和对话完全分不出层次。后来调整为：旁白用男声低音版本，女主角用甜美女声，反派用略带沙哑的音色，每一条音轨单独渲染后再混音。

字幕方面，我不用剪辑软件手动打字，而是让LLM把台词按时间轴切分好，生成SRT字幕文件，再通过FFmpeg烧录进视频。这一步看似不起眼，实际上能把后期时间压缩掉70%。

3. 源码结构核心实现

3.1 项目目录与职责划分

这组源码我按职责拆成了六个模块，结构很清晰，你可以直接照搬：

ai_short_drama/ ├── config/ │ ├── settings.py # 全局配置：API地址、密钥、默认参数 │ └── characters.json # 角色描述词统一管理 ├── core/ │ ├── script_generator.py # 剧本+分镜JSON生成 │ ├── compile_prompts.py # 分镜JSON转视频提示词 │ ├── video_generator.py # 批量调用文生视频接口 │ └── audio_mixer.py # TTS配音与混音 ├── pipeline/ │ ├── batch_generate.py # 批量执行入口，支持断点续跑 │ └── render_final.py # FFmpeg合成剪辑 ├── output/ │ ├── scripts/ # 生成的剧本JSON落盘 │ ├── videos/ # 原始视频片段 │ └── final/ # 合成后的成片 └── requirements.txt

这个目录不是拍脑袋设计的。config层解决角色一致性和参数统一，core层解决各个AI接口的调用细节，pipeline层解决流程编排和失败重试，output层解决产物管理。每层之间通过文件路径传递数据，不用数据库，原因是文件日志足够直观，出问题一眼能看出是哪一步断了。

3.2 剧本生成模块：从LLM接口拿到结构化分镜

script_generator.py的核心逻辑就是调用大模型接口，并对返回结果做健壮性处理。我贴一段简化版：

import json from openai import OpenAI client = OpenAI( api_key=settings.API_KEY, base_url=settings.API_BASE_URL, ) def generate_script(synopsis: str) -> list[dict]: prompt = f""" 你是一名短剧编剧。请根据故事梗概生成一集分镜脚本。 故事梗概：{synopsis} 要求：只输出JSON数组，每项包含 scene, shot, scale, camera, action, line, emotion, duration 字段。 """ resp = client.chat.completions.create( model=settings.LLM_MODEL, messages=[{"role": "user", "content": prompt}], temperature=0.7, response_format={"type": "json_object"}, ) raw_text = resp.choices[0].message.content.strip() # 从返回文本中提取第一个 [ 到最后一个 ] 之间的内容 start = raw_text.find("[") end = raw_text.rfind("]") + 1 shots = json.loads(raw_text[start:end]) return shots

实际使用中，大模型偶尔会在JSON前后夹带注释文字，所以我用find/rfind做了截断。另外temperature不能拉太高，0.7已经足够，太高容易产出不合理的分镜。

3.3 分镜转视频提示词：从中文脚本到英文视频Prompt

不同视频模型对提示词语言的理解能力差异很大，我统一用英文拼装，因为英文提示词在大部分模型上的表现更稳定。compile_prompts.py负责把中文分镜JSON转换成符合目标模型的英文提示词：

def compile_video_prompt(character_desc: str, shot: dict) -> str: scale_map = { "特写": "close-up shot", "中景": "medium shot", "全景": "wide shot", "过肩": "over-the-shoulder shot", "俯拍": "high-angle shot", } camera_map = { "固定": "static camera", "推": "dolly in", "拉": "dolly out", "摇": "panning shot", "跟": "tracking shot", } scale = scale_map.get(shot["scale"], "medium shot") camera = camera_map.get(shot["camera"], "static camera") action = shot["action"] emotion = shot["emotion"] template = ( f"{character_desc}, {action}, {emotion}, " f"{scale}, {camera}, cinematic lighting, " f"9:16 vertical frame, film grain, photorealistic" ) return template

这个模块是整条流水线里最容易出效果差异的地方。提示词里描述角色时必须放最前面，模型会优先关注前置信息；镜头语言和光线统一收尾，避免干扰主体。

3.4 批量生成与断点续跑：多镜头生成的稳定性保障

批量调用视频接口时最常见的问题就是中途断掉。要么是网络超时，要么是API频率限制，总之跑两分钟断了就得全部重来。所以我把批量生成做成了“先记录进度、后生成”的模式：

import json import time from pathlib import Path def run_batch(shots, output_dir="output/videos"): manifest_path = Path(output_dir) / "manifest.json" manifest = {} if manifest_path.exists(): manifest = json.loads(manifest_path.read_text(encoding="utf-8")) for index, shot in enumerate(shots): shot_id = f"{shot['scene']}_{shot['shot']}" if shot_id in manifest: continue video_path = generate_single_video(shot) manifest[shot_id] = { "path": str(video_path), "status": "done", } manifest_path.write_text( json.dumps(manifest, ensure_ascii=False, indent=2), encoding="utf-8", ) time.sleep(2) # 控制请求频率，避免触发限流

这样即使跑到第200个镜头时崩了，重启后也会从第201个继续，前面生成好的素材不会被浪费。manifest.json文件就是你的工程保险单。

3.5 FFmpeg合成：批量拼接、加字幕、混音

所有镜头生成完毕后，用FFmpeg一次性完成拼接、字幕烧录和配音混合。我分享两条用得最多的命令：

# 1. 按镜头顺序拼接所有视频片段 ffmpeg -f concat -safe 0 -i filelist.txt -c copy merged.mp4 # 2. 烧录ASS字幕并混入配音音轨 ffmpeg -i merged.mp4 -i final_mix.m4a \ -vf "ass=subtitle.ass" -c:v libx264 -preset veryfast \ -c:a aac -shortest final_episode.mp4

我习惯先生成一份filelist.txt，按第几集第几镜头的顺序排列，再执行第一条命令拼接。字幕我不用简单的SRT，而是转成ASS后用ass=subtitle.ass烧录，因为ASS可以统一设置字体、描边和位置，竖屏字幕如果不加描边，白色字很容易被高光背景吃掉。

4. 常见问题与排查技巧实录

我把实际跑项目中遇到最高频的问题整理成了一张速查表：

这里我要特别强调一个容易忽略的坑：AI生成内容的版权和素材合规问题。批量生产时必须确认你用的视频模型API允许商用，角色形象尽量不要模仿真实艺人或未授权IP，背景音乐要使用可商用曲库。别等成片要上架了才发现素材来源有问题，那是整个项目里最麻烦、也最没必要踩的坑。

关于角色一致性的排查，再补充一个经验：如果你用的是文生视频接口，但没有显式传入参考图的能力，那就退而求其次，把角色描述词固定成一段“角色身份证”，每次都在提示词最开头完整粘贴，不改一个字。实测下来的效果比不写强很多，至少发型和服装能稳定住，五官漂移概率会大幅下降。

5. 最后再分享一个实操习惯

最后分享一个我个人的实操习惯：每跑完一批镜头，我会把提示词、参考图路径、生成结果文件名和参数设置整理成一个HTML报告，一集一个页面。这样后续哪条视频出问题，我能直接对着报告回溯，而不是在一堆文件名里猜。这个习惯帮我省掉了大量重复生成的时间，建议你也试试。AI短剧创作的核心竞争力其实并不在于某个模型有多强，而是你能不能把模型稳定地组织成一条生产线，让每一集都能按同样的标准交付。

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