用Codex搭AI短剧自动化流水线：从分镜提示词到字幕生成的实战指南

去年年底我开始折腾AI短剧，就是那种三五分钟一集、竖屏播放、靠AI工具生成画面和配音、最后剪成剧情小短片的玩法。最开始我特别乐观，觉得有AI加持，一个人怎么也能顶一个小团队。结果真上手以后才发现，AI只是解决了“从无到有”的问题，后面几十个小时全耗在改提示词、存素材、对齐时间轴、整理文件这些破事上。直到我把Codex拉进工作流，才真正体会到什么叫“脚本跑起来，人可以在旁边喝咖啡”。这篇就把我三个月摸索出来的完整思路、具体脚本和踩过的坑一次性说清楚，给同样在折腾AI短剧的朋友做个参考。

1. 为什么我会折腾三个月：先说说AI短剧的痛点

1.1 AI短剧看起来简单，做起来全是重复劳动

AI短剧的完整链路并不复杂：写剧本、把剧本拆成分镜、给每个分镜写绘图提示词、批量出图、生成配音、剪成片子、加字幕、调色、发布。任何一个环节单独拿出来都不难，但组合在一起就变成了一个巨大的重复劳动池。我最早做的一部短剧有30集，平均每集40个镜头，也就是说我要处理1200个画面的提示词和素材。光是每张图都要保证人物长相一致、场景风格统一这件事，就足够让人崩溃。

更麻烦的是AI出图本身很吃“抽卡”。同一个提示词往往要抽好几轮才有一张能用的图，抽完还得把满意的画面单独挑出来，记下对应的seed、LoRA、参数，否则后面想微调或者补图，根本无从下手。一开始我就靠手动记，笔记软件里密密麻麻一堆，到了第10集已经分不清哪条记录对应哪张图了。那时候我才意识到，做AI短剧真正的门槛不是创意，而是这些又碎又多的重复事务。

1.2 我试过现成工具，也试过手搓脚本，最后才轮到Codex

我一开始图省事，找了不少号称“AI短剧一键生成”的现成工具。结果也不意外：模板化严重，人物表情僵硬，剧情走向完全不受控制。最要命的是这种工具改起来特别费劲，你没有一个能自由操作中间文件的空间，想换风格几乎等于重新做。

后来又试着自己写Python脚本。我本身不是程序员，是半路出家做内容的，遇到一个报错能卡半天，经常晚上十点开始查问题，抬头已经凌晨两点。直到我接触了Codex，才终于找到那种“用自然语言描述需求，它把代码写出来，我再跑一遍验证”的工作方式。Codex解决的最大问题是：我不需要先成为工程师，才能享受自动化带来的效率。我可以把精力放在流程设计上，而不是跟编译器较劲。

2. 先把边界划清楚：Codex能做和不能做的事

2.1 在AI短剧里，Codex扮演的是“技术员”而不是“创作者”

很多人一听到“用Codex做AI短剧”，第一反应是“它能帮我写剧本吗”。能，但你要注意，它的“剧本”和我想要的“剧本”是两个东西。Codex本质是个AI编程智能体，最擅长的是写代码、跑批处理、操作文件、调用API。你把需求讲清楚，它能把可执行的脚本给到你。所以我在整个AI短剧流程里，更多是把Codex当成一个特别高效的“技术员”。

比如让Codex帮我写一个批量生成分镜提示词的脚本，再帮我写一个把出图结果自动存成结构化JSON的脚本，再让这些脚本配合我原来的出图工具和配音工具跑起来。它做的事情是把你从“手动复制粘贴”里解放出来，让整个制作流程能像流水线一样稳定跑。我把它的角色定为“流程自动化的执行者”，它要保证流程不走样，而不是替我做审美判断。

2.2 这几个环节千万别指望Codex帮你做

虽然Codex很强，但AI短剧里最核心的创意部分，它替代不了。我踩过最大的坑就是一开始把所有东西都交给AI生成，结果做出来一套“看起来都行，但就是不好看”的片子。具体来说，下面这些事我是坚持自己动手的。

第一，剧情节奏和人物动机。AI可以给你生成一个“主角误会、反派捣乱、最后和解”的桥段，但它不知道什么样的情绪转折对你的观众有效。这个东西只有靠你自己对短剧受众的理解去把控。第二，画面审美。AI出的提示词可以很详细，但“这个画面有没有电影感”“这个构图适不适合竖屏沉浸”，这些判断必须你亲自看。第三，配音情绪。脚本可以帮你切分音频、生成字幕，但哪句话该重读、哪句该放慢，靠AI脚本搞不定，得自己听、自己调。

换句话说，Codex是提高你执行效率的放大器，而不是替你构思内容的“编剧”。你先有自己的创意和判断力，再用它来放大你生产内容的速度，这个组合才是合理的。

3. 我现在这套AI短剧流水线，从剧本到素材全流程拆解

3.1 先看单集执行的完整流程清单

折腾了三个月之后，我现在制作一集3到5分钟的AI短剧，固定走下面这几步。这套流程前前后后改了很多版，现在基本稳定。

第一步，剧本阶段。我先把分集大纲、角色卡、台词表写在一个文本文件里，然后让Codex按这个大纲生成单个镜头的描述，输出JSON。角色卡非常关键，里面必须有角色外貌、穿衣风格、画风限定、常用镜头景别。第二步，分镜提示词生成。Codex根据角色卡和镜头描述，批量生成每条分镜的绘图提示词，正反向一起生成。第三步，出图。我写一个Python脚本批量调用绘图接口，每个镜头抽4到6张候选图，自动把seed、提示词、图片路径保存到JSON。第四步，配音和字幕。我用TTS接口生成每句台词音频，然后让另一段脚本用ffprobe自动检测每条音频的时长，生成带时间轴的srt字幕。第五步，素材整理。脚本把所有图片和音频统一改成“集数-镜头号-序号”的命名格式，再导出一份剪辑软件能读的素材清单。第六步，归档。每做完一集，脚本自动生成一个项目报告，记录角色卡版本、seed、耗时和出图成功率。

3.2 分镜提示词生成脚本是怎么写的

分镜提示词是我整个流程里最核心的一步，因为后面所有出图质量都跟它有关。我以前是一句一句用手敲，特别慢，后来让Codex给我写了下面这类脚本。先看一个简化版。

from pathlib import Path import json character = { "name": "小北", "appearance": "20岁女生，齐肩短发，穿墨绿色卫衣，牛仔外套", "style": "国漫平涂，干净背景，柔和光影，竖屏9:16" } storyboard = [ {"id": 101, "shot_type": "中景", "content": "小北在便利店门口犹豫，最后推门进去"}, {"id": 102, "shot_type": "特写", "content": "小北看到货架上最后一盒草莓牛奶，伸手去拿"}, {"id": 103, "shot_type": "全景", "content": "便利店灯光下，小北抱着牛奶笑起来"}, ] def build_prompt(shot): return ( f"{character['style']}，" f"角色：{character['name']}，{character['appearance']}，" f"景别：{shot['shot_type']}，" f"动作/情境：{shot['content']}" ) for shot in storyboard: shot["prompt"] = build_prompt(shot) with open("prompts.json", "w", encoding="utf-8") as f: json.dump(storyboard, f, ensure_ascii=False, indent=2) for shot in storyboard: print(shot["id"], shot["prompt"])

这段代码的运行逻辑很直白：角色卡写死在前，保证人物外形不漂移；镜头描述接在后面，保证动作有信息量；最后统一追加画风和画幅。我后来在每个提示词里还会加上负向提示词，用来排除“多手指、模糊脸、文字水印”这类常见问题。

这个脚本对我来说最大的价值不是省了打字时间，而是让提示词格式完全统一。以前我手动写提示词的时候，同一个场景可能今天加“柔光”，明天忘记加，导致前后画面风格对不上。脚本一跑，所有镜头的风格限定都来自同一个角色卡，后面再想抽卡补图，也不会出现“两张图看起来像两个剧”的尴尬。

3.3 字幕时间轴脚本：用ffprobe读出真实时长

做字幕是我最早崩溃的环节。刚开始我用“估算时长”去写字幕时间轴，结果每次不是字幕早了就是晚了，反复调来调去，一集能浪费一个小时。后来让Codex写了一个脚本，直接调ffprobe读每段音频的真实时长，再自动累加得到每句台词开始和结束的时间点。

import json import subprocess def get_duration(audio_path): result = subprocess.run( [ "ffprobe", "-v", "quiet", "-print_format", "json", "-show_format", audio_path ], capture_output=True, text=True ) data = json.loads(result.stdout) return float(data["format"]["duration"]) lines = [ {"audio": "audio/001.mp3", "text": "小北站在门口，深吸了一口气。"}, {"audio": "audio/002.mp3", "text": "便利店里的灯还亮着。"}, ] start_time = 0.0 subtitle_entries = [] for line in lines: duration = get_duration(line["audio"]) subtitle_entries.append({ "start": start_time, "end": start_time + duration, "text": line["text"] }) start_time = start_time + duration + 0.3 with open("subtitle.srt", "w", encoding="utf-8") as f: for i, entry in enumerate(subtitle_entries, 1): f.write(f"{i}\n") f.write( f"{format_time(entry['start'])} --> " f"{format_time(entry['end'])}\n" ) f.write(f"{entry['text']}\n\n")

这段代码里的核心是加了一个0.3秒的间隔，也就是每句台词之间留一点气口，避免字幕粘在一起。这里要特别提醒一句：不同TTS模型生成的同一句台词，时长可能有细微差别，所以永远不要复用上一集的字幕时间轴，必须重新用ffprobe读一遍。这是我在做第7集的时候踩到的坑，当时偷懒复制了第6集的时间轴，结果整体延迟了快半秒，平台上一堆人吐槽字幕对不上嘴型。

3.4 批量任务必须加断点续跑，不然太容易白干

批量出图或者批量生成音频这种活，最怕跑到一半报错。网络波动、接口限流、某个文件路径写错，都可能让整个批次中断。我发现如果脚本没写“断点续跑”，每次失败之后都要从头开始，前面的结果虽然已经生成了，却没有记录下来，特别浪费。

后来我让Codex给所有批量任务都加了一个进度标记，跑完一个镜头就把ID写进一个JSON文件，下次启动时先读这个文件，跳过一个已经完成的任务。

import json from pathlib import Path PROGRESS_FILE = Path("progress.json") done = set() if PROGRESS_FILE.exists(): data = json.loads(PROGRESS_FILE.read_text(encoding="utf-8")) done = set(data.get("done", [])) shots = [ {"id": 101, "prompt": "...", "save_path": "img/s01e03_101.png"}, {"id": 102, "prompt": "...", "save_path": "img/s01e03_102.png"}, ] for shot in shots: if shot["id"] in done: print(f"跳过已完成镜头 {shot['id']}") continue try: # 这里填入你真正的出图/生成函数 generate(shot) done.add(shot["id"]) PROGRESS_FILE.write_text( json.dumps({"done": list(done)}, ensure_ascii=False), encoding="utf-8" ) except Exception as exc: print(f"镜头 {shot['id']} 失败：{exc}") break

这个改动的意义非常大。有了断点续跑，我再也不怕夜里睡觉前启动一个大批次任务，因为就算半夜断了，第二天起来接着跑就行。省下的不仅是重跑的时间，还有那种“白忙活一场”的挫败感。

4. 实操中遇到的坑和排查思路：都是拿时间换来的

4.1 Codex会话太长会“失忆”，任务一定要拆小

我一开始用Codex很不克制，恨不得开一个对话就把整部30集的流程全部生成。结果它越改越乱，前半小时还能正常理解我的需求，后半小时经常改A脚本的时候把B脚本的逻辑也改了，我甚至出现过用新脚本跑数据把旧脚本产生的文件给覆盖掉的低级事故。

后面我学乖了，把任务拆成一个个独立的小目标。比如今天只做“分镜提示词生成脚本”，明天只做“断点续跑功能”，后天只做“字幕时间轴生成”。每个脚本单独验证，验证通过之后再组合。Codex虽然上下文很强，但它不是无限记忆的，保持每个会话聚焦一个主题，出错概率会大幅下降。

4.2 素材命名规范是整个流程的地基，千万别偷懒

这是我这三个月最痛的一条领悟。第一次批量做完第1集到第3集素材时，我用的文件名是“1-1”“2-3”“新图片5”这种风格。结果到了配音脚本那里，整个程序直接找不到文件，因为命名完全没规律。我花了一个下午手动重命名，改到第2集的时候就已经开始怀疑人生。

现在我所有素材统一用这个规则：s01e03_shot012_img04.png、s01e03_shot012_audio01.mp3。集数、镜头号、候选序号都在文件名里体现，脚本解析起来毫无压力。我建议你在项目最开始就定好命名规范，哪怕多花10分钟，都能帮你在后期省下几小时。命名这件事，怎么严格要求都不过分。

4.3 第三方接口说变就变，必须留一个兼容层

做AI短剧的人基本都会用到绘图接口、TTS接口、视频生成接口。问题在于这些第三方接口的返回结构特别不稳定，今天返回的是JSON里的“url”，明天可能就变成“data.image”，你辛辛苦苦写的解析逻辑莫名其妙失效。我开始是每次报错就改代码，改来改去越来越乱，后来让Codex帮我统一封装了一个函数，所有接口解析都走这一个入口。

def extract_image_url(resp): for key in ["url", "image_url", "data.image", "data[0].url"]: try: # 简单演示，真实环境建议用更严谨的取值方式 if key == "url": return resp["url"] elif key == "image_url": return resp["image_url"] elif key == "data.image": return resp["data"]["image"] except (KeyError, TypeError): continue raise ValueError("未知的返回格式")

这样一来，以后接口返回格式变了，我只需要改这一个函数，整条流水线上依赖它的脚本不用跟着动。这就是我理解的“兼容层”思路，听起来挺简单，但真遇到接口变动的时候，能帮你少掉很多头发。

4.4 字幕对不齐不全是脚本问题，TTS缓存也要管

字幕时间轴对不齐的最常见原因有两个：一是手动估算时长，二是重复生成同一句台词。前者我已经用ffprobe解决了，后者是另一个隐藏的大坑。有些TTS接口有缓存机制，同样一句话在相同发音人配置下，第二次生成可能直接返回缓存音频，而缓存音频的时长和原音频有细微不同。但这个差异在后期拼接时会放大。

所以我现在会在脚本里对每句台词做一个hash，生成音频前先检查hash对应的文件是否已经存在。如果存在就直接复用，不存在才调用TTS接口。这个做法既省钱又避免重复生成带来的时长漂移。

4.5 遇到endpoint一类的报错，我现在的处理顺序

用Codex的过程中，偶尔会遇到和endpoint相关的报错。这是我实际过程中碰到过的情况，但说句实在话，大部分时候根本不是你的脚本写错了，而是网络链路不稳定，或者临时服务波动。我自己摸索出来的处理顺序是：先确认网络环境本身是稳定可用的，再重启一次Codex，让连接重置。重试的时候建议隔几分钟再试，不要在同一时间内疯狂点击。

这里我也多说一句，网上有些来路不明的“加速方法”我劝你别乱用，尤其是涉及第三方插件、非官方的配置修改，很容易引入安全风险。老老实实保持一个稳定、正常的网络环境，然后按官方渠道来使用工具，反而是最快最省事的。

4.6 登录状态失效别慌，多半是token过期

有一次我连续跑了两个批次任务之后，突然所有请求报错，提示“auth token is unavailable”。一开始还以为是脚本崩了，查了半天才发现是登录状态过期。Codex和很多在线服务一样，认证令牌是有时间限制的，长时间运行的应用偶尔会遇到这种问题。

解决方案很简单：重新登录官方账号，让工具重新获取认证信息就行。千万不要去改配置文件里自己看不懂的参数。我后来习惯在每天开工前先确认登录状态是正常的，避免跑批跑到一半才发现所有请求都失效了。

5. 三个月前后效率对比：省一半时间是怎么算出来的

5.1 单集AI短剧素材生产环节的耗时实测表

我把最近一集完整做下来，记录了一组自己实测的时间数据。这里强调一下，下面这些数据统计的是从剧本拆镜到最后素材归档的“素材生产环节”，不含我自己的创意决策时间，也不含剪辑软件里的精细调色和卡点包装。

加起来差不多是13小时对4小时不到。当然这只是素材生产环节，后面剪辑、包装、调色这些还是要自己动手的。但素材生产的效率翻倍之后，一集短剧的总制作周期大概从两天压到一天以内，整体算下来就是大家常说的“省了一半时间”。这个数据是我自己真实记录的，不是拍脑袋。

5.2 时间到底省在哪，以及哪里反而变慢了

省下来的时间主要来自三块：提示词不用一条条手敲了，出图不用一张张手动保存了，字幕不用一次次用肉眼去对齐了。这几件事都特别适合用脚本来干，它们重复、有规律、可验证，完全是Codex的舒适区。

但也有变慢的地方。第一次搭建脚本的时候要花掉大量时间调通，角色卡和风格库也要日常维护，还有检查成品图和字幕的校对环节，这些并没有变快。这就是边际成本的问题：如果你只做一集，那手工反而更快；但如果你要做30集、60集的连载，脚本和角色卡带来的复利会非常可观。我的建议是，先确定你是一个长期项目，再投入精力去搭这套流水线。

6. 最后分享一点我的个人体会

折腾了三个月，我最深的感受是：AI短剧这件事，真正拉开效率差距的不是你用的绘图模型有多强，而是你有没有把重复流程沉淀成可复用的脚本。Codex对我来说最大的价值不是“自动写剧本”，而是让我这种非程序员也能轻松维护一套自动化流水线。

如果你也想试，我给一个最实际的建议：不要一上来就想着搭建完整系统，先找自己最烦的重复环节，比如批量出图命名、分镜提示词生成，让Codex写一个小脚本解决它。跑通一个，再扩展下一个。等你把小脚本拼成一条完整链路，回头再看，省下的时间会远超你最初的预期。