LibTV导演台实战：从零制作1分钟AI真人短剧全流程

在实际 AI 短视频创作里，LibTV 经常被当作一个“导演台”来使用：先确定剧本，再固定角色和场景，然后逐镜头生成图片和视频，最后合成成片。这种工作流很适合 AI 真人短剧，因为真人风格的角色最怕前后不一致，而 LibTV 提供的项目化、角色化、批次化生成方式，恰好可以缓解这个问题。这篇内容不是单一功能介绍，而是从零开始跑通一部“1 分钟、3 个镜头、2 个角色”的 AI 真人短剧，同时把导演台怎么用、分镜脚本怎么写、提示词怎么组织、视频片段怎么校验、后期怎么合成、发布前要检查什么一起讲清楚。哪怕你之前没有任何 AI 视频基础，按这套流程走完，也能得到一条可以上传到平台的完整成片。

这里的“真人”要特别说明一下：指的是 AI 生成角色在画面上接近真人质感，而不是使用真实明星或素人的肖像。角色应该是你自己设定的虚构人物，所有题材也建议使用原创剧本。明白了这个前提，再进入技术流程。

1. 先用一个最短目标理解 LibTV 的创作流程

1.1 “导演台”要解决什么问题

LibTV 这类 AI 创作工作台，核心价值不是“能生成一张好看图片”或者“能生成一段视频”，而是把一次性的 AI 生成动作，变成一条可重复、可管理的生产链路。

普通 AI 绘图工具的用法是：

1. 输入一个提示词。
2. 生成一张图。
3. 不满意就再抽一版。
4. 最后拿到单张素材。

这种用法做一张图没问题，但做短剧就会失控。因为你需要的不是一张图，而是“同一个场景下同一个角色连续多个镜头”的图集和视频片段。如果每次都用独立提示词生成，角色服装、脸型、发型、光线都会被 AI 随机改掉，最终无法剪辑成一部连贯的故事。

LibTV 的导演台，通常会把创作过程拆成几个明确模块：

• 项目：保存整部短剧的角色、场景、分镜和生成记录。
• 角色：维护角色设定图、服装、性格和外观描述。
• 场景：维护地点、时间、光线氛围和背景风格。
• 分镜：把剧本拆成一个个镜头，保留镜头号、景别、运镜、台词和画面提示词。
• 批次生成：按分镜批量产出图片和视频，减少人工反复粘贴提示词。

所以“导演台”这个名字比较准确：你不是在“画图”，而是在“导戏”。你负责编排角色、场景和镜头，AI 负责把这些指令渲染成画面。

1.2 AI 真人短剧和传统短剧的差别

传统短剧的制作链路是：编剧写剧本，导演组织演员，摄影组搭景拍摄，后期剪辑配音。这个流程很成熟，但成本高、周期长、不易试错。

AI 真人短剧把链路压缩成：编剧产出分镜脚本，创作者在 LibTV 中设定角色和场景，AI 批量生成镜头画面，再通过 TTS 配音和剪辑软件合成。

差异集中在几个地方：

这套流程适合做样片、市场验证、低成本试错，但不等于完全替代传统拍摄。真正要长期运营账号，还是需要把 AI 当成前期提案和量产候选工具，而不是省掉所有内容责任的捷径。

1.3 为什么要先做“1 分钟三镜头”的最小项目

很多新手第一天就想要做“20 集短剧”，结果角色不稳定、脚本没拆好、生成视频一直崩，最后连一条完整成片都凑不齐。

更合理的做法是先完成一个极小闭环：

• 一个原创故事，不用复杂世界观。
• 2 个角色，控制在 1 个场景。
• 3 个镜头，每个镜头 3 到 5 秒。
• 合成一条 15 秒左右的样片。

这个目标的意义在于验证整条链路：

1. 角色能不能保持一致。
2. 场景能不能稳定复现。
3. 镜头之间能不能自然组接。
4. 配音和字幕能不能对齐。
5. 导出格式能不能满足平台要求。

只要这条链路跑通，再扩展到 12 镜、24 镜、5 集长剧，只是加大规模，不是重新学技术。相反，如果最小项目都做不出来，直接做长剧只会更乱。

2. 制作前准备：账号、素材目录和分镜脚本

2.1 环境与账号准备

在开始用 LibTV 之前，先确认几类基础条件。LibTV 不同版本和团队的部署方式可能不同，不要照搬教程里的具体版本号，要以实际打开的界面为准。

需要准备的内容包括：

• LibTV 使用账号，提前完成实名认证或手机绑定。
• 一个原创剧本，不要直接使用别人有版权的故事。
• 图像生成所需的积分或 Credits，具体计费规则看平台页面。
• 可选：一张角色参考图，用于后续固定角色外观。
• 本地电脑安装 FFmpeg，用于视频合成、抽帧和格式检查。
• 可选：剪辑工具，比如剪映、Premiere Pro、DaVinci Resolve。

这里要区分学习环境和生产环境：

学习阶段可以直接在 LibTV 页面里手动操作，不需要写代码，也不需要高配置电脑。生产环境或者批量成片阶段，建议把分镜脚本保存成结构化文件，比如 JSON 或 CSV，这样后续可以复用、二次修改，也可以被脚本批量调用。

FFmpeg 建议使用命令行，因为后面要批量检查视频参数，图形界面太慢。如果你用的是 Windows，可以下载安装包后把路径加入系统环境变量，再在终端执行：

ffmpeg -version

能输出版本信息，说明环境可用。如果是在 Linux 服务器上，可以安装“ffmpeg”包，也可以直接使用静态编译版本。

2.2 分镜脚本应该写到什么颗粒度

分镜脚本是整条生产链路的核心，它不是作文，而是生产调度表。至少需要包含这些字段：

• 镜号：方便排序和检查。
• 景别：远景、全景、中景、近景、特写。
• 运镜：固定、推镜、拉镜、横移、跟随。
• 角色：这个镜头里出现谁。
• 动作：角色在做什么。
• 情绪：角色语气和表情基调。
• 台词：角色说的话，或者画外音。
• 画面描述：给 LibTV 的画面提示词。
• 参考图：需要引用哪张角色图或场景图。
• 时长：这个镜头预期几秒。

用一个示例剧本模板来演示，故事是“林然回到老宅，发现一封未寄出的信”。

不需要每句台词都写完整，但画面描述和参考图必须能对应上。镜头之间如果发生了时间跳跃，还需要在后面加一栏“时间地点”，方便保持场景一致性。

2.3 用 JSON 管理分镜，避免散落一地

当镜头数量超过 10 个之后，建议用 JSON 保存分镜脚本。原因很简单：表格适合人工阅读，JSON 适合脚本处理和版本管理。

示例分镜文件shots.json：

{ "project": "那封未寄出的信", "characters": { "linran": { "name": "林然", "description": "28岁女性，黑色长发，米色风衣，眼神疲惫", "reference_image": "assets/characters/linran.png" } }, "scenes": { "old_house": { "name": "老宅堂屋", "description": "老旧中式堂屋，木窗，暖黄光线，灰尘可见", "reference_image": "assets/scenes/old_house.png" } }, "shots": [ { "shot_id": "001", "scene": "old_house", "characters": ["linran"], "scale": "全景", "camera": "固定", "action": "林然推门走进老宅", "emotion": "紧张迟疑", "dialogue": "", "prompt": "老旧中式堂屋，阳光从木窗斜射，灰尘在光柱里飘动，一个穿米色风衣的黑色长发年轻女人站在门口，眼神疲惫，电影感，写实风格", "duration": 4 }, { "shot_id": "002", "scene": "old_house", "characters": ["linran"], "scale": "近景", "camera": "缓慢推镜", "action": "林然看到桌上信封，伸手触碰", "emotion": "惊讶", "dialogue": "这是……留给我的？", "prompt": "木桌上一封泛黄信封，穿米色风衣的年轻女人伸手触碰信封，指尖微微颤抖，表情惊讶，近景，暖黄灯光，写实风格", "duration": 5 }, { "shot_id": "003", "scene": "old_house", "characters": [], "scale": "特写", "camera": "固定", "action": "信封特写", "emotion": "悬念", "dialogue": "", "prompt": "信封正面特写，收件人写着林然亲启，背景虚化，暖黄色灯光，电影感", "duration": 4 } ] }

这个 JSON 文件后续可以配合 Python 脚本生成生成任务、生成 CSV、或者做批量重命名。实际项目中，图片资源文件建议统一放在assets/characters/和assets/scenes/下，不要和最终视频混在一起。

2.4 角色设定卡和场景卡

分镜脚本是“每一条镜头怎么拍”，角色设定卡和场景卡则是“整个项目里角色和场景长什么样”。这两类信息是给 LibTV 导演台用的，也是保证角色一致性的基础。

角色设定卡建议固定这些字段：

• 姓名、年龄、性别。
• 发型、发色、脸型、眼睛颜色。
• 体型、身高。
• 常用服装和备用服装。
• 表情和情绪特征。
• 参考图。

场景设定卡建议固定：

• 场景名称。
• 地理位置。
• 时间段：白天、黄昏、夜晚。
• 光线方向。
• 主色调。
• 核心陈设。
• 参考图。

不要把角色描述写成“一个漂亮女生”，而要写成“黑色中长发女性和米色风衣，年龄约 28 岁，五官立体但不过度精致，眼神疲惫”。AI 对“漂亮”的诠释太多样，但对“米色风衣”和“黑色长发”这类具体特征更容易保持一致。

2.5 制作前检查清单

在正式打开 LibTV 前，按下面清单检查一遍：

• 原创剧本是否写完，有没有明确的冲突、目标和结局。
• 短剧标题、主演角色名、场景名是否统一。
• 分镜脚本是否包含镜头号、景别、运镜、提示词和时长。
• 角色设定卡是否写到发色、服装、年龄这些可量化字段。
• 场景设定卡是否包含时间、光线、主色和核心陈设。
• 是否有参考图，参考图是否清晰、无多余文字遮挡。
• 是否理解 Credits 计费方式，能否承受多次重抽。
• FFmpeg 是否能正常执行版本命令。
• 对外发布时是否计划在视频中标注“AI 生成”。

很多项目做一半失败，不是 AI 能力不够，而是输入信息太模糊。准备阶段多花 30 分钟，后面可以少抽十几张废图。

3. LibTV 导演台怎么用：创建项目、角色和场景

3.1 先新建项目，再导入分镜脚本

进入 LibTV 后，第一步不是直接写提示词，而是新建项目。项目是整部短剧的容器，里面通常会包含角色、场景、分镜、生成记录和输出素材。

新建项目时要确定的几个字段：

• 项目名称：建议用短剧名加日期，例如nafengxin-20250501。
• 分辨率：根据发布平台确定，常用 1920x1080 或 1080x1920。
• 帧率和时长：如果生成视频片段，通常需要设置时长和运动幅度。
• 风格：写实、电影感、古风、都市等。

在这里要注意一个常见误区：项目分辨率影响最终画幅，但不是越高越好。如果你最终发布到短视频平台，竖屏 1080x1920 是主流，做电影感短片则用横屏。生成时先把画幅定好，后面避免裁剪导致角色脸部被切掉。

导入分镜脚本时，如果 LibTV 支持外部文件导入，就把上一步的 JSON 整理成平台要求的格式；如果不支持，就按分镜表手动录入。手动录入虽然慢，但能让你逐条检查提示词。

3.2 创建角色：参考图比文字描述更稳定

在导演台里创建角色时，优先上传参考图，而不是只用文字描述。参考图的作用是给 AI 一个可对齐的“锚点”。

如果你还没有角色参考图，可以先用角色设定卡生成一张“肖像测试图”。建议让 AI 生成统一模板下的正面半身图，比如：

An original fictional character, a 28-year-old Chinese woman, black straight shoulder-length hair, beige trench coat, clear facial features, calm but tired expression, frontal view, neutral pose, soft studio lighting, photorealistic, plain background, character sheet style.

生成后如果满意，就把它作为该角色的默认参考图。接下来所有镜头都建议带这张参考图，而不是每次都重新描述外观。

创建角色时，描述字段建议写成“角色名 + 关键外观 + 服装 + 情绪基调”，例如：

林然：28岁女性，黑色中长发，米色风衣，眼神疲惫，动作克制，整体气质安静但带一点点警惕。

不要写“本片女主角”“温柔善良”这类主观判断。AI 不理解“善良”的视觉表现，但能理解“嘴角微微向下”“眉头轻皱”这类具体细节。

3.3 创建场景：先固定环境，再谈氛围

短剧场景不需要很多，但每一个场景都要单独建卡。同一个场景在不同镜头里会因为光线、时间段、镜头焦段不同而有变化，但它们必须共用一个“场景锚点”。

建议场景描述采用这种格式：

地点：老旧中式堂屋。 时间：下午三点。 光线：阳光从西侧木窗斜射进来，能看到空气中的灰尘。 主色：暖黄色、深棕色、米白色。 核心陈设：木质方桌，桌上有一封泛黄信封，两把旧木椅，墙上有老照片。 氛围：怀旧、安静、略带悬疑。

这种描述比“一个老房子”清晰得多。场景参考图也要一起绑定到项目中，生成镜头时用“场景参考图 + 角色参考图 + 动作描述”，一致性会明显提高。

3.4 提示词结构：把“形容词”改成“可视元素”

在 LibTV 里写画面提示词，不要像写作文。更多时候需要用“主体 + 动作 + 环境 + 光线 + 镜头 + 风格 + 负面词”的结构。

一个适合短剧镜头的提示词模板：

[角色名]，[动作描述]，在[场景描述]中，[景别]，[运镜]，[光线条件]，[氛围词]，[风格词]

比如 002 号镜头可以写成：

林然，站在木桌前，伸手触碰泛黄信封，指尖微微颤抖，表情惊讶，在老宅堂屋中，近景，缓慢推镜，暖黄色灯光，光线从木窗射入，灰尘在光柱中浮动，写实风格，电影感，浅景深。

负面词也是提示词的一部分。常见需要规避的内容包括：

多手指，畸形手，脸部扭曲，模糊，低分辨率，水印，文字乱码，重复人物，多余肢体

不同平台对负面词的支持方式不一样，有的模型不支持独立负面词，要写在提示词末尾。使用时先确认 LibTV 当前页面的填写位置，不要直接照抄。

3.5 General Image Pro 是什么，Credits 又是什么

热搜里经常出现一个问题：“libtv 的 general image pro 是 gpt-image 吗？”

从一般产品逻辑来看，General Image Pro 应该算 LibTV 平台里的一个图像生成模型档位或“模型能力档位”，它不等于 OpenAI 的 GPT-Image。平台可能在后台接入不同模型供应商，但对外展示的名字是平台自己的档位名。具体底层是什么模型，要以 LibTV 官方页面或接口文档标注为准。不同版本、不同区域、不同账号权限都可能不一样，不要只看一个教程就当成确定结论。

另一个高频词是 Credits。在 AI 工具里，Credits 通常指“算力点数”或“配额积分”，不是可以提现的货币。每次调用图像生成、视频生成、高清修复、视频延长等功能，会按照不同单价扣除相应点数。

使用 Credits 的建议：

1. 先用小图、低分辨率、低时长测试工作流。
2. 不要一上来就把整套分镜全部批量生成。
3. 角色参考图和场景参考图确认满意后，再开批量。
4. 记录每个任务大概消耗多少 Credits，避免中途余额不足。
5. 如果任务失败，优先检查是否扣费成功，再决定是否重试。

Credits 在 AI 工具里是“资源”，不是“保证成功”的按钮。创作前把预算当成生产成本，而不是用完再充值。

4. 从静态分镜到视频片段：批量生成、校验和重抽

4.1 动态视频怎么从静态图里来

LibTV 这类平台通常有两种生成方式：

1. 文生视频：直接输入提示词生成视频，适合空镜头、氛围镜头。
2. 图生视频：基于一张静态参考图生成动态片段，适合角色保持一致的动作镜头。

做 AI 真人短剧时，强烈建议优先用“图生视频”链路。因为你已经在上一步得到了角色参考图和分镜静态图，基于这些图生成视频，角色外观不会突然漂移。

动态视频生成时，需要设置几个核心参数：

如果你的目标镜头是“人物伸手拿信封”，建议先输出一张静态图，确认人物手部形状正常，再把静态图丢进图生视频。如果直接输入一大段话生成视频，很容易人物变脸、手部崩溃。

4.2 批量生成时要怎么组织任务

镜头数量少时，可以手动逐条生成。镜头数量达到 20 个以上后，手动操作会非常痛苦，而且容易漏镜头。

批量生成前，至少要做这些准备：

• 每个镜头都已经有独立的提示词。
• 每个镜头都绑定了正确的角色参考图和场景参考图。
• 每个镜头都标注了时长和景别。
• 确认项目里的输出目录按镜头号组织。

推荐目录结构：

project/ assets/ characters/ linran.png scenes/ old_house.png shots/ 001.png 002.png 003.png videos/ 001.mp4 002.mp4 003.mp4 audio/ voiceover.wav subtitles/ output.srt final/ final_v1.mp4

在 LibTV 里批量生成时，建议先只跑“每镜头 1 张静态图”，不要直接跑视频。把静态图全部检查完，确认构图、角色、场景都没问题，再将这些图统一转为视频。这样能避免 Credits 浪费在错误构图上。

4.3 校验视频片段，不能只看第一帧

很多新手拿到视频后只看第一帧，觉得画面不错就开始合成，结果后面几帧里角色脸变形、手变成六根手指。这不是工具坏了，而是 AI 视频生成常见的不稳定现象。

校验视频片段时要重点检查：

• 第一帧和最后一帧：角色是否自然过渡。
• 脸部细节：五官是否持续稳定。
• 手部动作：手指数量和弯曲方式是否合理。
• 文字：画面里的文字是否乱码。
• 运动幅度：是否存在突然跳变。
• 音频：如果平台生成带声音的视频，检查底噪和口型是否对得上。

如果只是 1 秒到 2 秒的小崩坏，可以调整运动幅度、固定种子、更换参考图后重抽。如果连续多次重抽都崩，建议退回去检查：是不是参考图本身太模糊，是不是动作提示词太复杂，是不是场景里干扰元素太多。

4.4 用 FFmpeg 批量检查生成视频

如果你生成的视频文件在本地，可以用 FFmpeg 批量读取分辨率、时长和帧率。这对排查“导入剪辑软件后画幅不对”“平台只允许 60 秒以内”这类问题很有用。

单文件检查命令：

ffmpeg -i videos/001.mp4

输出中会包含类似Duration: 00:00:05.00、Stream #0:0: Video: h264的信息。想批量检查多个文件，可以写一个简单的 Shell 脚本：

for f in videos/*.mp4; do echo "== $f ==" ffprobe -v error -show_entries format=duration,size -show_entries stream=width,height,r_frame_rate -of default=noprint_wrappers=1 "$f" done

如果没有 ffprobe，也可以用 FFmpeg 的统计输出代替，但 ffprobe 更适合解析参数。生产环境建议把这种检查写成脚本，保证每次批量生成后都有统一质检记录。

4.5 用 Python 脚本统一检查分镜 JSON 和视频文件

当镜头数量变大后，手工检查 JSON 容易漏项。可以写一个简单 Python 脚本，读取分镜文件，检查每个镜头是否都有提示词、时长和角色，再检查磁盘上的视频文件是否存在。

一个简化示例：

import json import os from pathlib import Path def check_shots(shot_file, video_dir): with open(shot_file, "r", encoding="utf-8") as f: data = json.load(f) errors = [] for shot in data["shots"]: sid = shot["shot_id"] if not shot["prompt"]: errors.append(f"{sid}: 缺少 prompt") if not shot.get("duration"): errors.append(f"{sid}: 缺少 duration") video_path = Path(video_dir) / f"{sid}.mp4" if not video_path.exists(): errors.append(f"{sid}: 视频不存在") return errors if __name__ == "__main__": result = check_shots("shots.json", "videos") if result: for item in result: print("ERROR:", item) else: print("OK: all shots pass check.")

这个脚本只是示例，实际项目要结合自己的目录结构和文件命名规则调整。它的价值在于把人工检查变成程序检查，让“漏镜头”这类问题在一开始就被发现。

5. 配音、字幕和剪辑合成：把镜头缝合起来

5.1 先做配音，再对字幕，最后合成画面

在 LibTV 里生成的视频片段，可能自带原始画面但缺少声音，或者声音只是环境底噪。短剧需要清晰对白，所以配音环节通常使用 TTS 文本转语音工具，也可以自己录制真人配音。

台词文件建议按镜头维护。先用文本文件保存：

镜头001：无台词 镜头002：这是……留给我的？ 镜头003：无台词

然后选择一个 TTS 工具生成音频。生成时要注意：

• 选择中文音色，语速不能太快。
• 根据角色年龄和性格选择声音气质。
• 台词前后留 0.3 秒静音，方便后期对齐。
• 如果角色是 AI 生成人物，配音音色不要太机械。

生成后，可以把所有音频按镜头号命名，例如audio/002.wav。后面导入剪辑软件时，直接按镜头号对位。

5.2 字幕文件用 SRT 格式

如果平台要求硬字幕，建议先制作 SRT 字幕文件。SRT 格式简单，能手动编辑，也能被 FFmpeg 直接烧录。

示例output.srt：

1 00:00:00,000 --> 00:00:04,000 2 00:00:04,500 --> 00:00:09,000 这是……留给我的？

字幕时间轴要与视频片段时长对齐。如果你的某个镜头是 5 秒，但字幕只显示 3 秒，观众会看不清台词。最好在剪辑软件里对着音频波形逐条调整。

5.3 用 FFmpeg 拼接视频片段

如果你的镜头全部生成完毕后不需要复杂转场，可以使用 FFmpeg 直接拼接。先创建list.txt：

file 'videos/001.mp4' file 'videos/002.mp4' file 'videos/003.mp4'

然后执行：

ffmpeg -f concat -safe 0 -i list.txt -c copy concat_play.mp4

-c copy会直接复制视频流，速度很快，但前提是所有片段编码参数一致。如果片段分辨率、帧率不同，这个命令可能报错，这时需要先统一转码，或者改用剪辑软件处理。

如果只是把三个镜头拼在一起，-c copy通常可行。如果中间要加转场、滤镜、字幕、配音，建议用剪映或 Premiere Pro 这类非线性剪辑工具，手动控制会更好。

5.4 最后的导出命令和验收标准

合成完画面和配音后，需要把字幕烧录进视频。使用 FFmpeg 烧录字幕命令：

ffmpeg -i concat_play.mp4 -vf subtitles=output.srt -c:v libx264 -preset slow -crf 18 -c:a aac -b:a 192k final_ai_short_drama.mp4

这里的-crf 18是高质量编码参数，数值越小画质越高、文件越大。短视频平台通常不会要求太高码率，但要求导出后不能出现明显压缩块。

导出完成后，建议从以下几个维度验收：

这个验收清单可以放在每次发布前的最后一步，避免某个镜头崩坏但已经导出成片。

6. 常见问题排查：从现象倒推原因

AI 短剧制作过程中会遇到很多重复性问题，下面按“现象 - 可能原因 - 检查方式 - 处理建议”整理成一条排查链路。

6.1 角色每集长得不一样

这是 AI 真人短剧最容易遇到的问题。

可能原因：

• 参考图没有绑定到每个镜头。
• 提示词里的外观描述不统一。
• 角色描述字段里写了太多抽象词。
• 中途更换了模型档位。

检查方式：打开两个镜头的生成记录，对比参考图 ID、提示词、种子参数。确认是否真的一起提交。

处理建议：

• 把角色外观描述复制到每个相关镜头。
• 让参考图成为每个镜头的第一优先级输入。
• 固定使用同一个模型档位。
• 有条件就固定种子，提高可复现性。

6.2 提示词写得很详细，但生成结果南辕北辙

可能原因：

• 提示词里包含矛盾信息，比如“白墙”和“深色木质背景”同时出现。
• 中文对某些模型来说不如英文稳定。
• 提示词太长，模型丢失早期指令。
• 负面词里没有排除干扰元素。

处理建议：把提示词压缩到“角色 + 动作 + 场景 + 光线 + 景别”五个板块，最多再补一个风格词。如果平台对英文更友好，可以准备一份中英文对照提示词表。

6.3 视频卡顿、人物扭曲、手指异常

可能原因：

• 运动幅度设置过大。
• 视频时长超过当前模型稳定范围。
• 角色动作包含多个连续复杂动作。
• 参考图本身细节不足。

处理建议：

• 先缩短视频时长，测试 3 秒片段。
• 把动作拆成更短的单动作，例如“伸手”和“拿起”分开生成。
• 打开固定种子，重抽前先做小改动。
• 如果连续多次崩坏，换一张更高清、手部完整的参考图。

6.4 Credits 扣了但任务失败或输出质量差

可能原因：

• 页面提示“任务失败”但扣费延迟显示。
• 请求参数超出模型限制，比如时长太长。
• 网络连接中断，任务状态未同步。

检查方式：查看任务历史、订单记录、输出日志。截图保存失败状态。

处理建议：

• 联系平台客服前，先保存任务 ID 和失败截图。
• 不要立刻反复重试，避免重复扣费。
• 后续测试先用低参数档位，不要拿复杂镜头做稳定性测试。

6.5 合成后音画不同步

可能原因：

• 配音文件时长与视频片段时长不一致。
• 剪辑时只看画面，没有看音频波形。
• 字幕时间轴按估计值填写。

处理建议：

• 在剪辑软件中把台词放到画面关键词出现的位置。
• 生成 TTS 后检查音频时长，如果台词最后有太多静音，可以裁剪。
• 字幕时间轴要以音频波形边缘为准，不按画面长度平分。

6.6 常见问题速查表

这些排查路径不是一次性解决的，建议每次生成都记录日志：提示词、模型档位、种子、参考图、消耗点数、结果状态。整理成一张 CSV 表后，你会发现哪些参数最稳定，哪些镜头最容易崩。

7. 发布合规、内容标识与可持续的变现路径

7.1 AI 生成内容需要自我标识

用 LibTV 做 AI 真人短剧，不等于生成完就能直接发布。多个内容和短视频平台对“AI 生成内容”都有标识要求，一般需要在发布时勾选“内容由 AI 生成”，或者在视频画面和简介中明确提示。

这不是可有可无的操作，而是关于观众知情权和平台规则的底线。发布前要检查：

• 视频是否被平台自动标记为“AI 生成”。
• 标题或简介里是否说明使用了 AI 工具。
• 评论区是否可能误导用户这是真实拍摄。
• 素材里是否包含无法确认版权的音乐、图片、字体。

一旦被平台判定为“欺骗性内容”，轻则限流，重则封号。与其冒险，不如一开始就建立“AI 内容标识”的固定检查项。

7.2 真人肖像与公众人物是红线

AI 真人短剧用“真人质感”没有问题，但有两个边界必须守住：

1. 不能使用真实素人的肖像生成可识别身份的内容。
2. 不能使用明星、名人、政要、运动员等真实公众人物的形象，即使只是“脸替”也不行。

有人会觉得“AI 生成的角色长得像某个明星但我不说是谁”，这仍然是高风险操作。因为平台和权利人可以通过技术手段识别相似度，一旦涉及丑化、虚假陈述或商业用途，会涉及肖像权、名誉权等法律问题。

安全的做法是：角色全部是原创虚构人物，长相不要以真实人物为模板。参考图也是自己生成的原创角色图，而不是从网络抓取的真实照片。

7.3 短剧变现的真实路径

标题里提到“商业变现”，这里需要把路径说清楚。LibTV 本身是生产工具，它不保证“做出视频就有收入”。变现主要取决于内容质量、账号运营和平台政策。

可参考的路径：

• 短剧平台分账：有些平台会购买或分账短剧，但一般要求字数集数、剧情节奏、完播率达标。
• 广告分成：你的内容在广告分成计划内，按播放和互动获得收益。
• 品牌定制：用 LibTV 快速产出样片，为品牌提供 AI 短剧或口播宣传片。
• 知识付费：把整套“从分镜到成片”的经验整理成课程或服务，需要你有足够案例证明。
• 教程和模板销售：把稳定的提示词模板、分镜脚本模板做成产品。

不管哪条路，核心都不是“AI 自动赚钱”，而是“你能稳定产出可复用的内容资产”。短剧的集数越多，角色一致性和生产稳定性的价值越大。所以建议先跑通 3 集，再考虑商业化。

7.4 用数据复盘代替盲目追热点

发布后，不要只看播放量。短剧类内容需要关注：

如果完播率低，优先检查开头 3 秒有没有钩子。如果评论区有人问“这是真人吗”，说明 AI 内容的辨识度已经需要调整，要么在简介里说清楚，要么优化画面以降低误导质疑。

复盘时要同时盯两组数据：一是内容数据，二是生产成本。每集花了多少 Credits、废了几张图、用了多久，都要记下来。如果一集成本太高，说明工作流还不够稳定，要先降成本再扩量。

7.5 从 LibTV 工作台走向自建生产链路

当个人创作者或小团队需要更高一致性、更细粒度的版权控制时，可以考虑往自建方向扩展。

常见演进路径：

1. 先用 LibTV 跑通全流程。
2. 整理出标准分镜 JSON 和提示词模板。
3. 对高频角色训练角色 LoRA 或人物控制模型。
4. 把图像生成、图生视频、配音、字幕拆成独立服务。
5. Java 或 Python 团队可以基于现有模型接口自建后台，Java 方向可以关注 Spring AI 这类模型接入框架，Python 方向可以关注 diffusers 和 ComfyUI。

但自建不等于必然更好。自建需要 GPU、模型运维、数据标注、成本控制和技术人员，初期不一定比平台工作台便宜。比较合理的策略是：学习阶段和中小型项目继续用 LibTV 这类成熟工作台，当产能和复购需求稳定后，再把最关键的环节私有化。

8. 七天从小白到稳定出片的学习路线

8.1 第 1 天到第 7 天怎么安排

下面是一份适合零基础入门的学习路线，每天都有明确产出和验收标准。不需要一天学完所有功能，重点是形成“做完一部再学下一部”的正循环。

第 7 天的核心不是“必须破播放量”，而是把整个流程走完一遍。你只有完整走完一次，才知道卡点在哪里。绝大多数新手都卡在第 5 天和第 6 天：前四天做图很开心，到了视频生成发现所有镜头都崩，于是放弃。其实只要把运动幅度调低、时长缩短、参考图绑定好，问题会明显减少。

8.2 长期创作时需要养成的习惯

• 素材库按“项目/角色/场景/镜头”分类，不要把所有图片放在一个文件夹。
• 每次生成记录保存提示词、参数、种子、结果截图。
• 后一个项目优先复用前一个项目的角色设定和场景描述。
• 不要在一个镜头里让角色做三件以上连续动作。
• 批量生成前先做 1 到 2 张测试，确认参数稳定后再扩量。
• 每次发布前走一遍合规检查：原创、AI 标识、音乐版权、字体版权。
• 每部短剧生成后记录 Credits 消耗，方便后续估算单集成本。

这些习惯可以让你从“偶尔生成一张好看图”升级到“稳定生产一条内容”。

学习 LibTV 也好，学习 AI 短剧制作也好，真正重要的不是某个按钮在哪里，而是你能否把一件事切成可管理的小步骤。先完成一个 3 镜头的样片，再复制这个流程到一集、一季、一个账号。只要这条链路是稳定的，后续不管平台规则怎么变，你都能快速调整，而不是每次都从零开始。