AIGC长剧制作全链路拆解：从剧本到发布的工程实践

前段时间国内首部 AIGC 长剧《后西游记》正式开播的消息在技术圈和影视圈都引起了不小的关注。和以往“AI 生成几分钟短片”的玩法不同这次是一部完整的剧集并且采用了“边审边播”的模式。很多读者在后台问我AIGC 生成一部长剧到底是怎么做到的“边审边播”在技术上意味着什么作为开发者如果自己想做一个 AIGC 内容生产工具应该从哪些环节入手这篇文章不打算讨论八卦而是站在技术角度把 AIGC 长剧制作背后的工程链路拆开来看。围绕“剧本生成、分镜设计、角色一致性、视频生成、配音合成、审核发布”这条主线讲清楚每一步涉及的核心技术、常见工具、可落地的代码/配置思路以及最容易被忽视的工程坑点。如果你以后想从事 AIGC 内容生产、AIGC 工程化落地或者只是想搞懂这类剧集是怎么批量生产出来的这篇文章可以给你一个比较完整的参考框架。1. AIGC 长剧到底是什么和普通 AI 短视频有什么区别1.1 从“AI 生成视频”到“AIGC 剧集”我们经常在抖音、B 站看到一些“AI 绘画 动态效果”生成的短视频时长通常在几十秒到两三分钟内容大多是概念动画、图片故事或 MV 风格片段。这类内容可以统称为“AI 生成视频”但“AIGC 剧集”要复杂得多。《后西游记》作为一部“AIGC 长剧”意味着它在内容生产链路中大量使用了生成式 AI 技术包括但不限于剧本的辅助生成或改写分镜头脚本的生成角色形象、场景画面的生成基于图片生成动态视频角色配音、音效、背景音乐的生成剪辑、字幕、色彩调整等后期处理。换句话说AIGC 长剧不是“一个人用 Midjourney 生成 100 张图然后拼成视频”而是一个由多个 AI 工具和人工审核节点组成的内容生产流水线。1.2 “边审边播”模式在技术上的含义“边审边播”在传统影视行业里并不算特别新的概念意思是剧集不用等到全部制作完成再一次性送审而是制作一部分、审核一部分、播出/上线一部分。但在 AIGC 剧集里“边审边播”带来的工程挑战是很大的内容生产速度快审核的速度必须跟上生成内容具有不确定性需要建立质量门禁审核不能只靠人工需要 AI 辅助内容审核系统每一集上线后后续剧集还在生产中生产版本和审核版本必须保持一致。从软件工程的角度看“边审边播”本质上是一条“持续生成 持续审核 持续发布”的流水线和现代软件行业的 CI/CD持续集成/持续交付思想非常相似。这也是为什么 AIGC 剧集值得做技术拆解的原因它已经把“内容生产”变成了一种类似软件工程的过程。1.3 适合谁关注内容平台的后端开发者要理解 AIGC 内容的生产、审核、发布链路AI 应用开发工程师想了解生成式 AI 在真实业务中的落地方式产品经理和项目经理需要理解 AIGC 内容生产的成本结构、质量控制和交付节奏影视/动画从业者想了解 AI 工具在编剧、分镜、美术、后期中的实际边界。2. AIGC 长剧制作的整体技术架构在做任何技术拆解之前我建议先建立一个全局视角。AIGC 长剧的技术栈并不是某一个模型而是一套组合系统。2.1 核心环节我把 AIGC 长剧的制作流程简化为下面几个环节剧本与文本生成 - 分镜与画面脚本 - 视觉素材生成 - 动态视频生成 - 音频配音与音效 - 剪辑合成 - 内容审核与发布以上每个环节都可能用到不同的 AI 模型和工具。为了让整条链路可复用、可追踪工程上还需要配套的资产管理系统、版本管理机制和审核日志系统。2.2 各环节涉及的技术工具下面用表格给出一份常见参考注意版本更新很快重点是理解对应环节需要什么能力而不是死记工具名。环节核心技术/工具类型常见工具示例输出产物剧本生成大语言模型 LLMGPT 系列、Claude、文心一言、通义千问剧本文字、对白分镜脚本LLM 结构化输出自研程序 LLM分镜表格、运镜描述画面生成文生图模型Midjourney、Stable Diffusion、FLUX角色设定图、场景图视频生成图生视频、文生视频Runway、Pika、即梦、可灵、AnimateDiff视频片段配音生成TTS 语音合成ElevenLabs、Azure TTS、火山引擎 TTS、GPT-SoVITS对白音频剪辑合成脚本化剪辑FFmpeg、Premiere、剪映、达芬奇成片素材内容审核大模型 规则引擎自研敏感词系统 视觉审核 API审核结果、风险标签这里要特别强调目前大多数 AIGC 长剧并不会让所有环节都“无人化”。更常见的工程模式是“AI 辅助生成 人工审核修正”也就是说 AI 负责批量生产初稿内容人类负责质量把关和方向调整。2.3 为什么需要进行资产化管理AIGC 内容生产有一个很大的问题生成结果是不稳定的。同样的提示词不同时间生成的角色脸可能不一样不同模型版本生成的颜色风格也可能不同。如果是单张图片差异可以接受但长剧有几十集角色形象、服装、场景风格必须保持一致否则观众根本无法入戏。所以工程上必须引入“资产化管理”每个角色有唯一标识符比如 character_id每个场景有标准参考图每集生成的素材都要保存在统一目录结构中后期素材重生成时要绑定参考图和种子参数。这其实和我们做前端组件库、微服务管理是同一个思路控制输入规范过程才能保证输出的稳定性。3. 环境准备最小可用的 AIGC 内容生产环境接下来我们进入实操层面。这里不会讲特别复杂的影视级流程而是搭建一个“最小可用的 AIGC 长剧内容生产实验环境”你可以把它理解成一个简化版。用这个环境你可以体验从文本到画面从画面到视频片段的基础链路。3.1 硬件与系统操作系统Windows 10/11、Ubuntu 20.04 或 macOS 12显卡NVIDIA GPU建议显存 8G 以上纯 CPU 环境可以做部分文本和音频环节但视频生成会很吃力内存16G 起步32G 更稳妥如果你的电脑配置不够也可以使用云服务器或在线平台完成部分环节。本文的示例主要是“思路演示”不一定要求你本地把所有模型跑起来。3.2 软件环境Python 3.9 或 3.10FFmpegGitNode.js部分工具链需要Docker可选用于部署审核服务3.3 创建一个项目目录建议把项目目录设计成这样aigc-drama-lab/ ├── scripts/ # 脚本与工具代码 │ ├── generate_script.py # 剧本生成 │ ├── generate_prompt.py # 提示词生成 │ └── check_content.py # 内容审核 ├── assets/ │ ├── characters/ # 角色资产 │ ├── scenes/ # 场景资产 │ ├── clips/ # 视频片段 │ └── audio/ # 音频配音 ├── output/ │ ├── episode_01/ # 第一集输出 │ └── episode_02/ └── config/ └── prompts/ ├── character_prompts.json └── scene_prompts.json这种结构的核心是把角色、场景、脚本、输出分开管理方便后期对某一集进行单独重做而不影响其他内容。4. 从剧本到分镜在代码里管理“提示词”长剧制作的第一步是文本内容。虽然你可以直接用聊天窗口让大模型写剧本但在工程化流水线里我们把“写剧本”拆成三个步骤生成剧情概要根据概要生成分场剧本根据分场剧本生成画面提示词。下面用 Python 代码演示一个简化的剧本生成思路。# 文件路径scripts/generate_script.py import json import os # 这里仅演示结构化提示词模板实际调用请对接大模型 API def build_story_prompt(theme: str, character_count: int) - str: return f 你是一位专业的编剧。请根据下面的主题创作一部短剧的第 1 集剧情概要。 主题{theme} 主要角色数量{character_count} 要求 1. 剧情结构包括开端、冲突、转折、结尾。 2. 每个角色必须有明确的目标和行动。 3. 输出格式为 JSON包含字段title, summary, characters, scenes。 请注意只输出 JSON不要输出其他解释性文字。 def call_llm(prompt: str, model: str gpt-4o-mini) - str: # 示例代码中不直接调用真实 API # 实际项目中可替换为 openai / 通义 / 文心 等 SDK print(调用大模型模型:, model) print(提示词内容:, prompt) # 返回模拟结果 return json.dumps({ title: 后西游记之石猴重生, summary: 一块受天地灵气孕育的仙石在毁灭后重新凝聚新的石猴即将踏上取经之路。, characters: [ {id: monkey_01, name: 小石猴, goal: 寻找身世真相}, {id: master_01, name: 老师傅, goal: 守护经书} ], scenes: [ {scene_id: 1, location: 花果山废墟, time: 黄昏}, {scene_id: 2, location: 山间小径, time: 夜晚} ] }, ensure_asciiFalse) def main(): theme 后西游记石猴在现代都市苏醒寻找消失的经书 prompt build_story_prompt(theme, character_count2) result call_llm(prompt) data json.loads(result) os.makedirs(output/episode_01, exist_okTrue) with open(output/episode_01/script.json, w, encodingutf-8) as f: json.dump(data, f, ensure_asciiFalse, indent2) print(剧本生成完成输出目录output/episode_01/script.json) if __name__ __main__: main()这段代码的核心价值不是实现大模型调用而是演示“结构化管理文本生成任务”的思路提示词模板、结构化 JSON 输出、按集保存到独立目录。在实际项目中你应该把call_llm替换成真实的大模型 SDK同时把script.json作为后续分镜和画面生成的输入。5. 分镜脚本与画面提示词管理5.1 分镜脚本的结构分镜脚本是连接剧本和画面的桥梁。简单来说每一场戏都要拆成若干个“镜头”每个镜头包含镜号shot_id景别远景/全景/中景/近景/特写运镜方式固定/推近/拉远/跟随/环绕画面内容描述角色与动作对白或旁白时长预期在 AIGC 长剧里分镜脚本不一定要手写可以由语言模型根据剧本自动生成。关键是要定义好输出的 JSON 结构方便下游工具读取。5.2 生成画面提示词同一个角色在不同镜头中必须保持一致这要求我们在提示词里固定“角色描述符”。首先维护一套角色提示词库例如{ characters: { monkey_01: { name: 小石猴, appearance: a young heroic monkey warrior, glowing golden fur, red armor with ancient patterns, negative_prompt: blurry, low quality, distorted face, extra fingers, wrong anatomy }, master_01: { name: 老师傅, appearance: an old wise monk, white beard, brown kasaya robe, wooden staff, kind eyes, negative_prompt: blurry, low quality, distorted face, extra fingers, wrong anatomy } } }然后写一个函数来组装当前镜头的提示词# 文件路径scripts/generate_prompt.py import json def load_character_prompts(path: str config/prompts/character_prompts.json) - dict: with open(path, r, encodingutf-8) as f: return json.load(f) def build_shot_prompt( character_prompts: dict, shot: dict ) - str: char_id shot.get(character_id) char_info character_prompts[characters].get(char_id, {}) appearance char_info.get(appearance, a person) negative char_info.get(negative_prompt, ) prompt ( f{appearance}, f{shot.get(scene_description, )}, f{shot.get(camera_style, cinematic shot)}, f{shot.get(lighting, natural lighting)}, fhigh quality, 8k, detailed background ) negative_prompt negative , watermark, text, logo return prompt, negative_prompt def main(): character_prompts load_character_prompts() shot { shot_id: ep01_shot_001, character_id: monkey_01, scene_description: standing on a mountain cliff at sunset, looking at the distant city, camera_style: wide shot, slow push in, lighting: golden hour lighting } prompt, negative_prompt build_shot_prompt(character_prompts, shot) print(画面提示词:) print(prompt) print(\n反向提示词:) print(negative_prompt) if __name__ __main__: main()在实际项目中这个函数产出的提示词会给到文生图模型。随着模型版本迭代提示词写法也会变化所以不要认为这套模板是标准。重点在于把提示词作为一种“配置”来管理而不是散落在聊天记录里。6. 画面生成与视频生成从静态图到动态片段6.1 静态画面生成在 AIGC 长剧流程中静态画面的生成通常用文生图模型。这类模型包括 Stable Diffusion、Midjourney、FLUX 等。如果你使用 Stable Diffusion通常会涉及以下配置文件简化版# 文件路径config/sd_config.yaml model: name: sd_xl_base_1.0 steps: 30 cfg_scale: 7.0 sampler: euler_a width: 1280 height: 720 output: format: png save_metadata: true这里的cfg_scale决定图像与提示词的贴合程度数值太高画面会过饱和太低又可能跑题。建议根据场景类型做实验不是所有镜头都适用同一组参数。6.2 图生视频生成有了静态画面之后下一步是让画面动起来。常见思路有两种文生视频直接用文字描述生成视频片段优点是方便缺点是可控性较差。图生视频先生成首帧关键图再让模型根据首帧生成短片段优点是角色和场景一致性较高。在 AIGC 长剧中图生视频方式更常见。你可以使用 Runway、Pika、可灵等平台也可以使用开源模型如 AnimateDiff。由于不同产品的 API 差异较大这里不写死某个调用代码。给出一个通用的请求结构化思路# 文件路径scripts/generate_video.py # 示例代码演示图生视频任务的请求结构 import requests # 以某个支持图生视频的平台为例仅展示请求体结构请按实际 API 调整 def submit_video_generation(api_url: str, api_key: str, image_path: str, prompt: str): headers { Authorization: fBearer {api_key} } data { prompt: prompt, image_path: image_path, duration: 5, # 生成视频时长单位秒 resolution: 1280x720, motion_scale: 0.8, # 运动幅度数值越大动作越明显 } # 实际请求可能是 multipart/form-data这里仅示意 response requests.post( f{api_url}/video/generations, headersheaders, jsondata ) return response.json()需要注意的是不同平台对“运动幅度”“首帧图”“参考图”的参数支持不一样。这里的关键是在请求体中体现出“角色参考图 动作描述 时长 分辨率”这些核心字段。6.3 为什么需要角色参考图很多 AIGC 初学者会问为什么我生成同一个角色每张图长得都不一样这是因为大部分文生图模型不具备跨生成的长期记忆。模型只知道“这次生成一个金色毛发的猴子”但不知道“上次那只猴子长什么样”。解决办法就是引入“角色参考图”Reference Image机制在做图生视频时把该角色的标准形象图一起传入在做文生图时使用 IP-Adapter、LoRA 等模型微调技术固定角色特征在后期剪辑时使用统一素材库避免混用不同版本的角色图。对于一部长剧来说建议在制作初期就完成所有主要角色的“定妆照”然后每一集的生成都围绕定妆照进行而不是每集都把角色描述凭空重写一遍。7. 配音与音频生成7.1 TTS 语音合成配音环节在 AIGC 长剧中通常有两种做法使用 TTS文本转语音直接生成角色对白在 TTS 基础上进行声音克隆让配音音色稳定统一。TTS 工具非常多比如 Azure TTS、火山引擎 TTS、ElevenLabs 等。对于长剧项目选择 TTS 时重点看三点音色自然度、多情感表达、并发能力。7.2 一个简单的音频文件管理示例音频资产也需要按集管理。下面是用 Python 整理音频文件的示例# 文件路径scripts/manage_audio.py import os import shutil def organize_audio(episode: str, source_dir: str, target_dir: str): 把某集的音频文件按角色归类到目标目录 os.makedirs(target_dir, exist_okTrue) for filename in os.listdir(source_dir): if not filename.endswith(.mp3): continue # 文件名命名规则ep01_角色ID_场景号_音频编号.mp3 parts filename.split(_) if len(parts) 2: char_id parts[1] char_dir os.path.join(target_dir, char_id) os.makedirs(char_dir, exist_okTrue) shutil.copy2( os.path.join(source_dir, filename), os.path.join(char_dir, filename) ) print(音频资产整理完成) if __name__ __main__: organize_audio( episodeep01, source_dirassets/audio/raw, target_dirassets/audio/processed )这里的目录规划思路和前端静态资源管理的逻辑是相通的。音频文件按角色和场景拆分后后期剪辑时查找成本就会大大降低。8. 内容审核体系AIGC 批量生产的安全底线《后西游记》采用“边审边播”意味着内容审核不是制作完成后的“最后一步”而是贯穿整个生产链路的“质量门禁”。对于开发者来说这恰好是可以工程化实现的部分。8.1 审核分为哪些层次内容审核不只是查敏感词。在 AIGC 长剧里审核体系至少包括文本审核剧本、对白是否存在违规内容图像审核画面是否存在违规或侵权元素音视频审核语音内容、字幕是否同步版权审核角色形象、背景素材是否涉及版权风险一致性审核角色前后形象是否一致、场景是否穿帮。8.2 基于规则引擎的敏感词检查下面给出一个简单的 Python 敏感词检查示例。这不是完整的审核系统但可以帮你理解审核模块如何嵌入流水线。# 文件路径scripts/check_content.py import re class ContentFilter: def __init__(self, sensitive_words: list): # 将敏感词列表编译为正则表达式 self.patterns [re.compile(re.escape(word), re.IGNORECASE) for word in sensitive_words] def check(self, text: str) - dict: hit_words [] for pattern in self.patterns: if pattern.search(text): hit_words.append(pattern.pattern) return { pass: len(hit_words) 0, hit_words: hit_words, text_length: len(text) } def main(): # 实际项目中应从配置文件或审核服务拉取敏感词列表 sensitive_words [违禁词A, 违禁词B, 高风险词C] text 这是一段正常的对白不包含任何违规内容。 filter_ ContentFilter(sensitive_words) result filter_.check(text) print(result) if __name__ __main__: main()在实际生产环境中文本审核往往交给大模型或专门的审核 API 来做因为敏感词库很难覆盖所有变体比如谐音、拆字、表情符号绕过。但规则引擎依然有存在价值响应快、可解释、可离线部署适合做第一道快速拦截。8.3 审核结果如何进入发布流程如果整个项目按“边审边播”来设计发布流程可以像这样每一集生成初稿素材自动跑文本、图片、音频基础审核审核不通过的内容自动打回并记录失败原因审核通过的内容进入人工抽检队列抽检通过后执行剪辑合成合成产物再次过审核门禁通过后进入发布队列发布后继续监测观众反馈和舆情风险。在下发判断中如果 AIGC 内容涉及数字人形象或真人肖像克隆还需要取得相应授权避免侵犯肖像权和声音权。这些合规问题在工程设计中也要留出审核字段。9. 常见问题与排查思路下面整理了 AIGC 长剧制作过程中常见的工程问题方便你以后遇到类似报错时快速定位。问题现象常见原因解决思路同一个角色每张图都不一样没有使用角色参考图或提示词中未固定外观描述建立角色定妆照库生成时绑定参考图或 LoRA生成视频画面抖动严重图生视频时运动幅度设置过高或参考图尺寸不稳定降低 motion 参数保持输入图像比例一致生成速度太慢本地显卡显存不足批量任务没有做并发控制使用云端 GPU或对任务做队列和批量调度语音与画面不同步音频生成和视频生成的时长没有统一在分镜脚本中提前标注对白时长剪辑时以音频轨为基准审核误杀正常内容敏感词规则过于严格或大模型判断标准不稳定建立白名单机制对高风险判定做人工复核剪辑素材太多找不到没有按集、场景、角色统一命名制定命名规范用脚本定期整理资产目录提示词明明是同样内容生成风格却不一致模型版本、采样参数或随机种子不同固定 sampler、steps、cfg_scale、seed 等关键参数长剧集数太多人工审核跟不上审核流程没有自动化或者自动化覆盖率太低分层审核先用规则和大模型自动初筛再人工抽检从排查思路来看AIGC 长剧项目里最常出问题的不是某一个模型效果不好而是“多个工具之间的衔接规范”没做好。比如角色图没有统一、命名没有规范、审核状态没有记录很容易在几十集生产之后彻底乱掉。10. 最佳实践与工程建议10.1 提示词管理要“资产化”提示词是 AIGC 生产中最重要的资产之一。不要在聊天框里写完就丢建议用 Git 管理提示词文件保留每个版本的变更记录。推荐把提示词拆成三个层级基础描述角色外观、场景风格、画风工艺参数模型版本、采样步数、分辨率、seed项目限定当前剧集的时间线、情节限定、美术方向。这样做的好处是当某一集生成效果不理想时你可以快速定位是“描述问题”还是“参数问题”并且可以回滚到上一个可用版本。10.2 建立素材版本管理机制长剧生产周期长素材会被反复重做。强烈建议在素材文件名中加入版本号例如ep01_scene01_monkey_01_v1.png ep01_scene01_monkey_01_v2.png不要用最终版.png、最终版2.png这种命名。工程上可以使用 Git LFS 管理大文件也可以用轻量级素材管理系统但核心是“可追溯、可回滚”。10.3 自动化质量门禁“边审边播”要想真正跑起来必须把质量门禁嵌入流水线。你可以设计一个简单的检查状态字段{ episode_id: ep01, script_status: approved, character_art_status: checking, video_status: pending, audio_status: pending, review_status: pending, version: v1.2 }每一集都用一个状态文档来跟踪任何环节更新后都要同步状态。这个思路和 CI/CD 流水线里的流水线状态非常相似。10.4 保留人工审核环节AIGC 内容即使技术上能全自动生成也不建议在发布链路中完全去人。原因有三个模型对长剧的情节连贯性理解有限内容审核标准存在主观性需要人来兜底版权和合规问题需要法律专业判断。比较好的实践是AI 负责生成、初筛、提示风险人负责确认、修改、最终放行。10.5 关注版权和安全边界在 AIGC 长剧制作中需要特别注意几点使用第三方素材时确认授权对知名 IP 形象做商业化使用前确认版权风险数字人形象需要用户明确授权涉及隐私信息的内容严禁在提示词中出现生产内容时要保留生成记录方便追溯。安全不是技术单点问题而是流程和系统共同保证的。建议从项目第一天就把审核和版权检查纳入工程计划而不是等项目上线前再补救。11. 总结与下一步学习路线《后西游记》开播这件事真正值得技术人关注的不是某一家平台或某部剧本身而是它证明了 AIGC 长剧的工程链路已经初步跑通。从文本生成到画面生成从配音到审核发布每一个环节都出现了可用的工具和方案同时也暴露出大量工程化挑战一致性、可控性、审核效率、资产管理和版权合规。如果你对这个方向感兴趣可以按下面这条路线继续深入先体验主流文生图/图生视频工具建立对生成效果的直观感知学习大模型 API 的基本调用方式习惯用 JSON 管理结构化输出动手搭建一个“文本到分镜”的小工具理解提示词工程尝试用开源模型本地跑图像生成理解参数和显存之间的关系了解视频剪辑的脚本化操作比如用 Python 调用 FFmpeg 做批量剪辑设计一个简单的内容审核流程把文本审核和图片审核串起来。AIGC 技术更新非常快今天的主流模型可能半年后就会被新方案替代但“生产链路拆解、资产化管理、流程化审核”这些工程思路会长期有效。哪怕是做到一半想转方向这套流程化的思维方式也能帮你在其他技术领域走得更稳。最后建议大家动手时先从 3 到 5 分钟的短片开始不要一上来就挑战长剧。先把角色一致性、音画同步、素材命名和审核流程跑顺了再逐步拉长内容和集数。把过程拆细把版本管好AI 生成内容才能真正成为可交付的产品。