周末晚上，我往本地跑起来的一条AI流水线里丢了一句话：“台风夜，便利店，一只会说话的猫。”接下来四个多小时，我的显卡风扇几乎没停过。等到成片在播放器里走完最后一帧，我确认了一件事：从剧本到分镜、从画面到声音、再到字幕和剪辑，我没有为任何一次API调用掏钱。一部两分多钟的AI短剧，全部在本地零元跑通。

这篇东西就是这次实测的完整记录。我会把“一句剧本怎么长成一部短剧”这条路拆成一条可复现的流水线：本地大模型扩写剧本、分镜表生成、ComfyUI出图、图生视频、本地TTS配音、最后剪辑合成，每一段都会写清选型逻辑、关键参数和踩过的坑。适合手里有NVIDIA显卡、想认真折腾本地AI内容生产，又不想被云API账单绑架的人。

1. 零元方案的底气：先算清本地AI短剧这笔账

1.1 云API的账单有多痛

很多做AI短剧的人一开始走的是云API路线：文本生成用大模型接口，图片生成用绘图接口，视频生成再用视频接口，配音再来一个语音接口。一整条链路走下来，你会发现最烧钱的根本不是文本和图片，而是视频和语音。

市面主流的视频生成API按秒计费或按次计费，一分钟成片烧掉几十上百元是很正常的事。一部两三分钟的短剧，分镜头往往要单独生成，再加上废片重试、角色不一致要重画，实际消耗常常是成片时长的好几倍。也就是说，一部看起来普普通通的2分钟漫剧，API账单可能要吃掉几百块。这只是“一次试错”的成本，不是“做出一部好作品”的成本。

我最初也动过云API的念头，但算了一笔账之后果断转向本地。本地方案的前期成本是一次性硬件投入——显卡、内存、硬盘——之后每次生成消耗的只是电费。而且重试不花钱这件事，对创作节奏的影响远比你想象的大：云API模式下你不敢反复生成对比，本地模式下“同一句剧本跑十个版本然后挑一个”完全是常规操作。

1.2 本地方案的真实边界

本地方案不是没有代价，它把成本从“钱”转移到了“时间和折腾”。同样一条2分钟短片，云API可能两三小时搞定，本地跑通整条链路我第一次用了整整一个周末。显存不够会爆，驱动不对会崩，模型权重从几十GB到上百GB不等，下载、配置、试错都需要耐心。

但边界也很清晰：一旦跑通，后续每一次创作的边际成本几乎为零。你可以凌晨三点想到一个点子，立刻让它变成分镜和样片，不用心疼调用费，不用担心内容审核接口返回的幺蛾子，更不用把剧本和画面素材传到别人服务器上等着排队。

1.3 我实测用的硬件底子

这里先交代我的实测环境，方便你对照：

• GPU：NVIDIA RTX 4090 24GB
• 内存：64GB DDR5
• 系统：Windows 11
• 硬盘：2TB NVMe SSD（模型和中间文件非常占空间）

这不是最低配置，而是让我“少折腾”的配置。如果你用的是RTX 3060 12G或RTX 4060 Ti 16G，文生图完全没问题，图生视频会吃力一些，但也能跑，只是需要接受更长的时间和更低的帧率。纯CPU跑文本生成可以，图像和视频基本不用想。

2. 先让“一句剧本”长成“一集剧本”：本地大模型选型与提示词设计

2.1 三组常见的本地组合

文本生成是整个流水线的起点，也是“一句剧本长出短剧”的第一步。我没用云API，全部走本地推理，目前试下来有三组组合比较顺手：

• Ollama + 量化版中文模型 ：这是最省事的组合。Ollama把模型管理、运行、API调用都封装好了，一条命令就能把模型跑起来，非常适合先跑通流程。
• llama.cpp + GGUF格式模型 ：如果你不想依赖Ollama的封装，想对采样参数和上下文做更精细的控制，llama.cpp更灵活，但配置门槛也更高。
• Dify本地部署 + Ollama后端 ：当你不满足于逐条生成，想做一个“输入一句话，自动输出完整剧本+分镜表”的工作流时，Dify这类编排平台就派上用场了。它把提示词模板、模型调用、结构化输出串成可视化流程，后续维护和复用都方便。

我这次实测以Ollama为主，原因是它足够简单。安装好之后，拉模型、起服务、通过本地HTTP接口调用，几分钟就能完成。本地模型我用的是7B到14B这个体量的中文模型，包括Qwen系列和DeepSeek的蒸馏版本。7B模型速度更快，但对复杂剧情的理解偶尔会飘；14B模型质量更稳，生成速度慢一些，在4090上属于可接受范围。

2.2 一句话到一集剧本的三段式扩写

直接让模型“把这句话写成一个剧本”不是不行，但输出质量很不稳定。我试过多次之后，养成了三段式扩写的习惯：

1. 先扩梗概 ：用一句话生成300字左右的故事梗概，确定人物、冲突、结尾。
2. 再分场次 ：把梗概拆成分场，每场标明地点、人物、核心事件。
3. 最后写正文 ：逐场生成角色对白和动作描述。

为什么非要分三步？因为大模型在长文本生成上很容易“前后不搭”：开头铺垫了一堆线索，结尾全部忘掉。分段扩写相当于把一次长跑拆成接力赛，每一棒都检查一遍再交棒，出错率明显下降。

我让Ollama跑的实测输入是“台风夜，她在便利店遇到一只会说话的猫”。第一轮扩出的梗概大概三百字：台风夜停电，店员林晚准备关店，一只被淋湿的猫开口说出她失踪哥哥的最后一句话，她决定跟着猫走进风雨里。第二轮分场拆成六场，第三轮逐场生成正文，整个过程大概二十分钟。

2.3 让短剧有“钩子”的提示词技巧

和写小说不同，短剧的剧本对“节奏”的要求极高，尤其是前几秒必须抓住观众。我在提示词里会明确要求模型做到这几件事：

• 每场结尾留钩子 ：不把信息一次给完，让观众想看下一场。
• 台词口语化 ：短剧是靠“听”的，书面语长句在配音阶段很容易出戏。
• 动作描写可视觉化 ：别写“她的内心充满复杂的情感”，要写“她把伞丢在地上，盯着猫的眼睛，退后半步”。

我在系统提示词里固定了一段模板，这段模板是反复迭代出来的：

你是一名短剧编剧。你的任务是把我提供的灵感扩写成适合AI生成画面的短剧剧本。
要求：
1. 故事节奏快，开头要有悬念。
2. 每场结束前设置一个转折或悬念。
3. 台词短而口语化，每句不超过30个字。
4. 动作描述具体且能转为画面，避免心理描写。
5. 输出格式：场次、场景地点、时间、角色、对白、动作。

这里有个很重要的心法：不要指望提示词一次写好。我第一次用这段模板时，模型输出的动作描述还是太抽象，我又加了一句“每个动作都要写清肢体细节，像给演员的指令”，输出才真正变得适合文生图。

3. 把剧本翻译成镜头语言：AI分镜表是怎么生成的

3.1 为什么不能拿剧本直接生图

我踩过这个坑。早期为了省事，直接把剧本正文丢给文生图模型，结果出来的画面和剧情对不上：台词还在聊台风，画面里已经出现晴天；角色情绪是紧张，画面里却是一张面无表情的脸。

原因在于文生图模型根本不理解“剧本”，它只理解“画面”。剧本里写“她犹豫了一下”，这个描述对模型来说有太多解释空间：是皱眉？是低头？是攥紧拳头？所以必须有一个“翻译”步骤，把剧本文字转成一格格具体到可以画的画面，这就是分镜表。

3.2 AI分镜表的字段设计

我让大模型输出的分镜表，每一行包括这些字段：

字段	作用	示例
镜号	排序与后期追踪	场景2-3
景别	决定画面构图	中景
运镜	给后期提示运动方式	从右向左横移
画面描述	文生图的直接素材	便利店货架前，穿雨衣的女孩蹲下，一只猫抬头看她
角色状态	保证表情一致	紧张、瞪大眼睛
环境描述	统一场景风格	暖黄灯光、窗外暴雨、货架上的应急灯
预计时长	给后期剪辑参考	4秒
对白	配音用文本	“你说什么？”

这八个字段不是随便定的。前四个字段影响画面生成，中间两个字段影响角色和场景的一致性，最后两个字段影响配音和剪辑。字段定得越明确，后面每个环节的返工率就越低。

3.3 让大模型输出结构化分镜表

想让大模型稳定输出这个结构，最好让它返回JSON而不是Markdown表格。原因是JSON可以直接被程序读取，之后无论是做批量生图还是导入剪辑工程，都不用手工复制。

我在提示词末尾加了这样一段话：

请把上面的剧本转换成JSON数组，每个元素包含：scene_id（场景编号）、shot_id（镜头编号）、shot_size（景别）、camera_movement（运镜）、visual_desc（画面描述，含环境、人物动作、表情）、character_state（角色当前状态）、duration_seconds（预计时长）、dialogue（该镜头对白）。

Dify在这时候就派上用场了。我在Dify里拉了一个简单流程：输入剧情梗概 -> 大模型扩写剧本 -> 大模型生成分镜JSON -> 输出。这样每次只需要改第一句话，后面全自动。这种编排一旦跑通，你做第二部、第三部短剧的效率会成倍提升。

3.4 角色视觉锚点：防止人脸漂移的第一道防线

AI短剧最容易被观众吐槽的就是“角色长了一张不断变化的脸”。这个问题的根源在分镜阶段就已经埋下了：如果每个镜头都用自然语言描述人物外貌，“穿雨衣的女孩”在第一个镜头被画成圆脸，第二个镜头被画成瓜子脸，后期根本无法收场。

解决办法是在分镜表里给每个重要角色固定一段“视觉锚点”描述，比如：

林晚：25岁东方女性，圆脸，黑色齐肩发，穿黄色雨衣，深蓝色牛仔裤，白色运动鞋。

这段描述从分镜阶段就固定下来，每次生成画面时都拼进提示词。注意，这段锚点文字要写得“可被模型明确理解”，不要用“气质清冷”这种抽象词，要用“嘴角下垂、眉毛细长”这种具体词。锚点越具体，后续生图的角色一致性越好。

4. ComfyUI文生图：把一格格画面“画”出来

4.1 为什么选ComfyUI而不是WebUI

稳定扩散生态里有两套流行的界面：WebUI和ComfyUI。WebUI上手简单，点几下就能出图，但一旦涉及批量生成、精细控制工作流、人物一致性这些需求，ComfyUI的节点式界面优势非常明显。

我选ComfyUI的核心原因是“可复现”：同一个分镜表要生成几十张图，ComfyUI的工作流文件可以保存下来，换个输入图片或提示词就能复用；WebUI虽然也能做批量，但控制逻辑分散在多个选项卡里，稍不注意就会用错设置。

另一个重要原因是ComfyUI对图生视频、IP-Adapter、LoRA这些扩展的支持更直接，很多新模型的第一时间适配也是ComfyUI优先。

4.2 一条基础文生图工作流的节点骨架

如果你是第一次用ComfyUI，不用被密密麻麻的节点吓到。最基础的工作流只需六个节点：

1. Load Checkpoint ：加载底模，我用的主要是写实风格的SDXL模型。
2. CLIP Text Encode（正面提示词） ：输入画面描述。
3. CLIP Text Encode（负面提示词） ：输入不希望出现的东西。
4. Empty Latent Image ：设置出图尺寸。
5. KSampler ：采样器，控制步数、CFG、种子。
6. VAE Decode + Save Image ：把潜空间数据解码成图片并保存。

第一次跑通这条链路后，我再把LoRA节点、ControlNet节点和IP-Adapter节点逐步加进去。建议你不要一上来就想搭一个“全功能帝王级工作流”，分镜表里几十个镜头，基础工作流先跑通，再加控制逻辑。

4.3 人物一致性：LoRA加IP-Adapter的组合策略

人物一致性是我在这次实测里花时间最多的地方。最终跑通的方案是“LoRA为底，IP-Adapter辅助”。

• LoRA ：用准备固定风格的角色图片训练一个轻量LoRA模型。训练数据不需要很多，20到30张统一风格的正面图就够了。LoRA加载之后，人物的脸型、发型、服装会被“锁”住，这是保证一致性的核心手段。
• IP-Adapter / FaceID ：在生图时把一张参考人物照片作为额外输入，让模型模仿参考图的脸部特征。它和LoRA不冲突，反而能互补：LoRA负责角色整体风格，IP-Adapter负责当前镜头的神态和角度。

这套组合的效果对比很明显：只用文生图提示词，角色的脸部每张图都有微妙差异；加上LoRA后，观众能认出是同一个人；再叠IP-Adapter，连表情都能够对齐分镜要求。

4.4 采样参数：我的常用起点和调整方向

文生图的参数没有标准答案，但在短剧批量出图场景下，我的常用起点是：

参数	实测常用值	说明
分辨率	832x1216（竖屏）	短剧基本是手机竖屏
采样步数	25-30	步数太低画面脏，太高收益递减
CFG	5-7	写实模型我常用6左右
采样器	DPM++ 2M Karras	速度与质量比较均衡

这里想特别提醒：同一部短剧的所有镜头，底模、LoRA、采样器、分辨率这些全局参数一定要固定。很多人前面镜头用SD1.5模型，后面换成SDXL模型，结果同一个角色变成了两种画风。不要觉得这是小事，我实测中后期画风统一工作比前期生成还麻烦。

4.5 批量生成与筛选

分镜表里有几十个镜头，我不可能一个个手工调。ComfyUI支持批量处理：把每个镜头单独当作一次工作流输入，写个小脚本批量调用API，每个镜头生成四到六张备选图，然后人工快速挑出最顺眼的一张。

这一步千万不要让它全自动挑选。至少在目前，AI生成画面里经常出现手指畸形、文字乱码、多余物体这些肉眼能一眼识别但程序很难判断的问题。人工筛选的代价是时间，但换来的是成片不用在剪辑阶段返工。

5. 让静态画面动起来：本地图生视频的“能”与“不能”

5.1 本地可跑的图生视频模型怎么选

画面生成之后，下一步是让静态分镜动起来。这一步是本地零元方案里“肉眼可见”最吃配置的环节。

目前能在本地跑起来的方案有三类：

• AnimateDiff系列 ：基于稳定扩散的动画扩展，显存压力相对小，RTX 3060 12G就能跑，适合做幅度不大的动作和氛围变化。
• CogVideoX系列（如CogVideoX-5B） ：专门做视频生成的开源模型，效果比AnimateDiff更像“实拍视频”，但显存占用更高，24G显卡比较从容。
• Wan系列（如Wan2.1） ：近两年口碑不错的视频生成模型，支持图生视频，生成运动幅度可控，ComfyUI已经支持。

我实测用的是CogVideoX家族的轻量版本和Wan系列交替测试。AnimateDiff的优势在于和现有SD工作流无缝衔接，劣势是动作幅度一大就容易崩；Wan和CogVideoX生成的自然运动更流畅，但对显存和推理时间的要求高不少。

5.2 图生视频的关键参数

图生视频的核心参数和文生图不太一样，我常用的几个维度：

参数	实测常用值	作用
总帧数	24-72帧	决定视频时长，24帧约为1秒
帧率（输出）	8-12 FPS	低帧率配合后期补帧更稳
步数	20-30	步数越高越精细，时间成本也越高
运动强度	0.5-0.8	太高画面变形，太低看起来像PPT
种子	固定或微调	抽卡式试错时很有用

这里有个反直觉的经验：不要一上来就生成72帧长视频。视频模型生成的时间越长，前后一致性越难保持，越到后面越容易出现角色五官漂移、物体扭曲。我更推荐每个镜头只生成长度2到3秒的短视频，后期剪辑时用多个镜头衔接来撑起总时长。

5.3 实测里最常见的两类失败

这次实测里，图生视频阶段翻车最多，两类失败占了八成：

第一类是“画面不动” 。明明参数里写的是“猫站起来看向门口”，生成出来的视频里猫基本没动，只有背景的雨在动。这种情况通常是运动强度参数太低，或者输入提示词没有强调运动。我的解法是提示词里写得更具体，不写“猫动了”，而是写“猫从柜台上站起来，前爪落地，头转向门口”。

第二类是“变形” 。开头几帧还是那只猫，到了第30帧，猫的脸已经扭曲得不像话了。这种情况通常是大动作幅度加长视频时长导致的。我的解法是把时长短一些，动作幅度调低一些，然后用多个镜头替代一个大动作。

5.4 静态空镜用“图片加运镜”代替生成

处理完全没必要让所有镜头都有大幅度动作。短剧里很多空镜、定场镜头，画面本身不用变，只需要有镜头运动感。

对这种镜头，我偷了个懒：直接用FFmpeg给静态图加缓慢的缩放或平移，模拟“推镜头”和“摇镜头”的效果。比如一张便利店门口的全景图，加一个从上到下的缓慢下摇，配合雨声音效，观众根本不会注意到这是静态图。

别小看这个偷懒方案，它帮我省下了将近一半的视频生成时间。AI视频生成本身不稳定，能少生成就少生成，这是效率的关键。

6. 配音、字幕与最终剪辑：本地也能完成

6.1 本地TTS方案横向对比

画面有了，还差声音。短剧没有配音，观感会大打折扣。本地TTS我试过三个方案：

方案	优势	劣势	适合场景
ChatTTS	对话自然、口语化强，支持情绪标签	长文本偶尔吞字	短剧对白
Piper	轻量、速度快、延迟极低	声音表现力一般	旁白与说明
GPT-SoVITS	可以用原声克隆音色	配置复杂、算力要求高	固定主播音的连载剧

我这次主要用ChatTTS。它对中文口语的处理比Piper自然得多，而且可以在文本里插入情绪标签来控制语气，比如插入停顿、笑声、叹气。

6.2 台词的节奏感怎么用提示词控制

很多人用TTS生成的配音听起来“像机器念课文”，问题往往出在台词文本本身，而不是TTS模型。

ChatTTS支持在文本中嵌入特殊标记来调节生成结果。我在测试中常用的几个：

• [laugh] ：插入笑声，适合人物轻松对话。
• [break] ：插入停顿，比标点符号控制的停顿更长。
• [sigh] ：叹气，表达无奈或紧张。

比如这段台词：

“你说什么？[break]不，这不可能……”

比我直接给“你说什么？不，这不可能……”生成的语气情绪丰富得多。

另一个经验是：台词文本里尽量用口语写法，不要用书面缩略语。TTS对“你怎么了”和“汝何以如此”的处理完全不是一个量级。

6.3 字幕与合成：用FFmpeg就能完成

配音生成后，我用FFmpeg把视频画面、配音、字幕一次性合成。FFmpeg的命令没有想象中复杂，核心一条就能做完：

ffmpeg -i video.mp4 -i audio.wav -vf subtitles=sub.srt -c:v libx264 -c:a aac output.mp4

-vf subtitles=sub.srt 会把字幕烧进画面。如果你希望字幕字体更好看，可以给subtitle滤镜加字体参数，例如：

-vf "subtitles=sub.srt:force_style='FontName=Microsoft YaHei,FontSize=12,PrimaryColour=&H00FFFFFF,OutlineColour=&H00101010'"

这里面的 PrimaryColour 是字幕颜色， OutlineColour 是描边颜色，值采用BGR格式的十六进制。短剧字幕通常需要白字加黑边，这样在亮背景和暗背景上都能看清。

我这次全程只是把分镜对应的配音按顺序拼接、再交给FFmpeg合成。对一个2分钟短片，手工排序几十段素材完全可接受。等到你打算做长剧集、每集时长拉长到5分钟以上，再去研究自动导入剪辑工程也不迟。

7. 一次实操复盘：从“一句剧本”到2分钟成片的完整时间线

7.1 原始输入与最终成片

我这套流程的实测输入就是开头那句话：“台风夜，她在便利店遇到一只会说话的猫。”经过一个晚上调试，最终成片时长2分37秒，共38个镜头，包含完整的配音、背景音乐和字幕。

这里把实际走查结果列一个时间成本，方便你有心理预期：

环节	耗时	说明
本地大模型扩写剧本与分镜	约45分钟	含多次提示词调整
ComfyUI批量出图（38镜头，每组4张）	约80分钟	382分辨率，未开加速
图生视频（24个动态镜头）	约100分钟	视频生成最耗时
本地TTS配音	约20分钟	15句对白，含重试
剪辑合成与字幕	约40分钟	含手工筛选素材

总计约四到五个小时。如果显卡是24G以上、且各模型都已经跑顺，时间会更短。如果用12G显存跑，图像阶段问题不大，视频阶段可能要翻倍。

7.2 显存占用记录

生成过程中的显存占用是很多人关心的。实测数据大概是这样：

• 文生图阶段：80%的时间显存占用10-14GB。
• 图生视频阶段：峰值逼近22GB，4090几乎被吃满。
• 本地TTS阶段：显存占用不高，5GB以内。

这也意味着，如果你只有12G显存，文生图完全够用，图生视频则需要选AnimateDiff这类更轻量的方案，或者将视频生成长度进一步缩短。千万别用24G显卡的标准去规划12G显卡的流程。

7.3 成片质量与明显短板

先说能看的部分：角色一致性基本稳住了，观众能认出“林晚”从头到尾是同一个人；配音情绪比预期好，尤其是那句停顿后的“不，这不可能”，确实带出了惊愕感；节奏也符合短剧特点，每场结尾都有钩子。

再说短板。最明显的是动作幅度受限：很多镜头里的“动作”其实很微小，近景对话可以，但中远景的肢体动作一多就容易崩。其次是背景音乐：我用的是本地生成的一段合成音乐，和画面的情感贴合度一般，暂时只能靠配音和音效撑住。

7.4 中途翻车：一次显卡驱动崩溃的排查记录

这次实测中间还发生过一次诡异问题：跑了大概一个小时，突然弹出一个事件日志错误，提示“无法找到来自源 nvlddmkm 的事件 ID 153 的描述”，紧接着显卡驱动重置，ComfyUI进程直接卡死。

第一次遇到时我以为是驱动版本问题，直接重装了驱动，结果跑没多久又崩。后来仔细排查才发现根因：图生视频阶段显存占用太高，刚好打到我系统里其他程序的显存占用，叠加之后触发了驱动保护机制。解决办法也很朴素：关掉所有浏览器标签页，关闭其他占显存的程序，并且把视频生成的批量大小调低，让峰值显存降下来。

这个坑想特别记一笔，因为它的表象很有迷惑性：事件日志里只提示“找不到事件描述”，看起来像是系统日志损坏或驱动故障，实际上只是显存压力过大触发了显卡重置。以后你看到类似日志，先查显存峰值，再查驱动版本。

8. 想复刻这套流程？最后的配置清单与避坑建议

8.1 最低配置与推荐配置

如果你确定要复刻这套流程，我先给两份配置参考：

配置级别	GPU	规格	适合做什么
最低能跑	RTX 3060 12G	32G内存，512G SSD	文本生成、文生图、短镜头视频
推荐顺跑	RTX 4070 Ti Super 16G	64G内存，1T SSD	全部流程，视频生成有等待但可用
从容丝滑	RTX 4090 24G	64G内存，2T SSD	全流程高效，可同时训练LoRA

注意，这里说的“最低能跑”是能跑通，不是跑得舒服。图生视频阶段你需要接受单镜头可能等待十分钟以上、并且频繁重试的现实。

8.2 七个高频坑，一次性说清

我在这次实测里踩过不少坑，挑七个高频的列出来，你遇到时能少走弯路：

1. 路径不能有中文 。ComfyUI和很多AI工具对中文路径兼容性极差，模型加载失败时十有八九是路径问题。工作目录全部用英文。
2. 模型格式别混用 。SD1.5、SDXL、FLUX的底模不能跨工作流混用。你用的是SDXL工作流，就别直接把SD1.5的LoRA挂上去。
3. 上下文长度不要塞太满 。本地大模型处理超长剧本时经常丢后文信息，分镜表太长就拆成几段生成。
4. 负面提示词里有常见关键词要写上 。“畸形的手、多余的手指、文字水印、模糊、低质量”这几条在短剧场景里属于保命词。
5. 采样种子不要全场统一 。同一分镜下的多张备选图最好用不同种子，否则所有备选图构图几乎一样，筛选意义全失。
6. 别迷信单次长视频生成 。能拆成2秒短镜头就拆，后期剪辑拼接完全看不出来，还能大幅降低翻车率。
7. 配音文本千万别直接复制剧本台词 。剧本台词是给人读的，TTS需要额外加入标点符号和停顿标记，否则语速和重音完全不对。

8.3 这套流程下一步还能怎么玩

这套链路跑通之后，可扩展空间其实很大。你可以在文本层接入Dify，做成“一句话自动生成完整分镜JSON”的免配置工具；可以在图像层训练自己角色的LoRA，建一个角色库；可以在视频层尝试更新更强的开源视频模型；可以在语音层用GPT-SoVITS克隆固定声线，让连载短剧有稳定的“主演音色”；甚至可以把所有环节封装成脚本，让一部短剧的生成从四小时缩短到一小时以内。

我个人下一步准备把“数字人”加进流程：生成一个固定形象的虚拟主播，让它朗读剧本开场白，再切入正片。这个扩展依赖的技术基本还是当前这套本地方案里的，只是再多跑一个本地数字人模型而已。

这次实测让我最深的体会是：AI短剧生产的门槛已经从“会不会用云API”变成了“愿不愿意把本地环境折腾明白”。零元成本不是梦，但它换来的不是躺赢，而是一整套需要自己维护和调优的生产管线。如果你也想试，先别急着追求高画质、长时长，把“一句话到成片”的最小闭环跑通，后面所有优化都是在这个闭环上做加法。