三个月前我朋友群里都在刷Codex我当时第一反应是又一个写代码的AI跟我做短剧能有什么关系我那时候正卡在一部36集AI短剧的筹备期每天敲分镜提示词敲到凌晨嘴上不说心里早就在骂街这玩意怎么比剪片子还累人。直到有一次我实在不想手搓了把一张乱糟糟的分镜表丢给Codex让它按我规定的格式重新整理又顺手让它写了一个批量保存图片的小脚本。那天晚上十点半我居然收工了。这篇文章不是讲怎么用AI写剧本也不聊剪映还是PR而是分享我折腾三个月后跑通的一套做法用Codex把AI短剧制作里最磨人的“程序员工序”接过去——也就是分镜表拆解、提示词批量生成、素材文件整理、API调用批处理这些环节。如果你是一个人做短剧或者带两三个人但完全没有代码基础这篇文章里所有步骤都能直接抄。说句实在话按我现在的流程一部36集动态漫从剧本定稿到分镜提示词齐活时间至少省一半。1. 先搞清楚AI短剧的工序里哪一步最浪费时间1.1 AI短剧的完整生产链路很多人以为AI短剧就是拿文生视频工具敲一句话出个片段然后剪一起就行。真正动手做一个月就会发现完整链路比这长得多而且大部分时间根本不在“生成画面”那一步。我跑的项目可以拆成八个环节剧本、分镜脚本、视觉素材生产、对白配音、音效背景乐、剪辑合成、字幕包装、上传发布。这里面剧本和剪辑是大家比较熟的部分但真正让我这种单人小团队崩溃的是第二到第四个环节——它们看起来不起眼却像一个隐形流水线每天吞噬大量时间。所谓视觉素材生产又分两种路线。一种是我说的“直接文生视频”用一个模型生成几秒钟的动态片段另一种是“动态漫/漫剧”路线先生成一批高精度的分镜静态图再靠镜头平移、缩放、局部动效、配音字幕组成整集内容。对于个人和小团队来说第二种路线更可控成本也更低但它天然要求你先有一张非常规范的分镜表。这张分镜表就是全流程的核心中间产物。1.2 手工时代的三个隐形时间黑洞我刚开始做项目时整个流程全靠手工当时不觉得有什么问题回头一算账才发现时间都漏在三个地方。第一个黑洞是提示词重复劳动。每个镜头都要生成一段中英混杂的提示词主体是谁、什么动作、什么环境、什么光线、什么镜头语言再加上负面提示词和风格参数。我一集25个镜头36集就是900个镜头每个镜头起码两三轮修改。人不是机器写到100个镜头的时候脑子已经糊了后面全是复制粘贴改动词这种活儿不出错才怪。第二个黑洞是素材管理混乱。生成的图片文件名经常是时间戳或者乱序编号我得靠肉眼在文件夹里认出“这是第几集第几个镜头”。改一版提示词重新生成一次又覆盖一遍。最后电脑里全是“未命名_001”“副本_最终版”“到底哪个是终版”这种文件我一度怀疑自己在做行为艺术。第三个黑洞是手工校验和补件。900个镜头漏一个、图裂一个、尺寸不对一个都很难及时发现。往往等到剪辑阶段才发现某段分镜对应的图片根本不存在或者分辨率跟前后的镜头对不上只能回去翻素材库。这一来一回浪费的时间比生成图片本身还多。这几个黑洞的本质其实是“批量文本处理”和“文件工程管理”。Codex最擅长的恰恰就是这两件事。想通这一点之后我的整个工作思路都换了。2. Codex在短剧项目里到底扮演什么角色2.1 一句话定位它是驻场开发不是编剧我先给还不知道Codex是什么的朋友补个背景。Codex是OpenAI出的编程智能体官方提供命令行工具和IDE插件你可以用自然语言在终端里指挥它读文件、写代码、执行命令、改文件、调接口。它本质上不是一个聊天的窗口而是一个能直接对你的项目目录动手的“驻场开发”。我踩过的最大误区就是一开始以为它只能帮我写网站或者做数据分析。后来我发现在AI短剧这种项目里它真正有价值的角色是“生产流程的程序员”。它能帮我把剧本拆成分镜表把分镜表批量转成提示词写脚本去调绘图和配音的API再自动整理所有生成的文件。它不会替我决定故事走向也没办法替我把女主角的脸设计得更讨喜那些还得自己来。我现在的分工很明确我当制片人和编导负责定调子、审查内容和审美把关Codex当执行开发负责把重复、规则明确、容易出错的工作自动化。这个分工一旦确立整个项目的推进速度就不一样了。2.2 为什么选Codex CLI而不是只盯着IDE插件Codex目前有几种用法最常见的是IDE插件和在终端里跑的CLI。我做短剧项目几乎全程用CLI原因有三个。第一CLI能真正进入项目目录工作。短剧项目本质上是一堆脚本、CSV、图像文件、音频文件组成的文件夹我需要的是有一个助手能在这个文件夹里统一处理文件而不是只在我打开某个代码文件的时候帮忙补全函数。第二CLI适合跑整条流水线。我可以把分镜表CSV丢到data目录然后在终端里说“读取分镜表按规则生成全量提示词”它就会乖乖干活。IDE插件更适合修改单点代码但对我来说不够整体。第三CLI配合Git使用体验非常好。我新建每个短剧项目都会初始化Git仓库提示词版本、脚本版本、中间产物结构全都被记录。哪怕某次Codex把脚本改坏了我也可以一键回退不用从头再来。当然IDE插件也不是没用。比如你想微调一个已经写好的生成脚本打开VS Code框选几行让它改确实比在终端里说一堆话要直观。我的习惯是搭建工作流用CLI日常微调用插件两条路都通互不冲突。2.3 用AGENTS.md给Codex立规矩CLI用得越久我越发现一个项目目录里最重要的是“约定”。Codex每次进入项目都会尽量读取项目信息你可以专门放一个AGENTS.md文件把项目约定写清楚它干活的时候就有章可循。我项目里的AGENTS.md长这样# AI短剧项目约定 - 所有代码和脚本放在 scripts/ 目录 - 中间数据分镜表、提示词、配置放在 data/ 目录 - 生成的图片统一放在 shots/ 目录音频放在 audio/ 目录 - 文件名一律使用英文短横线风格例如 shot-0101.png - API密钥只允许从环境变量读取禁止硬编码到任何文件中 - 任何可能删除文件的命令执行前必须输出计划并确认别看这个文件只有五行作用非常大。它相当于一个“老板”站在Codex旁边随时提醒它项目的规矩。以前我让它写脚本它经常往项目根目录丢一堆临时文件把目录搞得乱七八糟自从有了AGENTS.md它每次生成代码前都会默认遵守这些规则。这个习惯我真的建议所有用Codex的人养成不管你是不是做短剧。3. 从剧本到分镜让Codex帮你把脚本拆成镜头表3.1 先定标准格式分镜表是最重要的中间产物前面反复强调分镜表到底什么是标准的分镜表它不能是一段描述性文字而是要能落到表格里的结构化数据。我现在用的字段是这样的镜头号、场次、景别、画面描述、角色对白、英文绘图提示词、预计时长、备注。其中最重要的就是镜头号和英文绘图提示词。镜头号是用来管理文件的关键索引绘图提示词是后续生成素材的输入参数。这两个字段一旦确定后面所有环节都能挂在这张表上走。为什么一定要强调“结构化”因为AI生成内容时自由发挥空间越大错误率越高。如果你让Codex输出一大段带着自然语言解说的分镜文本你得再花时间二次解析如果直接要求它按固定字段输出CSV结果就能直接喂给脚本用。每个镜头一行字段用逗号或竖线分隔字段名固定这才能算是合格的分镜表。3.2 给Codex的提示词怎么写才能稳定输出这个步骤是整个工作流的胜负手。我给Codex下指令时模板大体是这样我给了你一段短剧剧本放在 data/script.txt。 请把剧本按要求拆分成分镜表输出到 data/split_ok.csv。 字段顺序固定为 shot_no|scene_no|shot_type|visual_desc|dialogue|image_prompt|duration 规则 1. 每个镜头一行CSV只保留数据不输出任何解释文字。 2. shot_no格式集数镜头号例如第一集第3个镜头写成0103。 3. shot_type写景别远景、全景、中景、近景、特写、过肩择一即可。 4. visual_desc用中文描述画面内容限30字以内。 5. image_prompt用英文120个词以内必须包含主体动作、环境、光线、镜头语言。 6. 有对白的镜头duration按台词长度估算无对白镜头默认3秒。 7. 如果剧本中有角色名不一致按主要角色名统一修改时不要额外说明。这段提示词有三个关键地方值得展开说。一是“只输出数据不输出解释文字”。Codex这类模型特别容易在任务完成后补一句“已完成拆分”之类的废话放在CSV里就是脏数据。直接禁止它输出数据之外的东西能省很多清洗时间。二是把格式约束具体化。用“0103”这种编号规则后面脚本做文件名映射就非常方便。景别直接限定几个选项后续美术风格统一、镜头节奏处理都有依据。三是给它一个“角色替换”的自由度。剧本里可能有同一个角色被写成“女主”“她”“晓芸”多种叫法要求它统一能提前消灭大量低级错误。3.3 落地示例36集短剧的批量分镜我拿自己项目举个例子。我这部短剧一共36集每集大约60秒按平均3秒一个镜头一集约20到25个镜头全片接近900个镜头。以前靠人手写这张分镜表一集至少40分钟写完全部三十多集脑力早就透支了。现在流程是这样的剧本定稿后我把它丢到data/script.txt然后对Codex说一句“按data/split_ok.csv模板和AGENTS.md约定处理这个剧本一集拆20到25个镜头”。Codex会自动把一集拆出来生成一集一张CSV。第一次拿到CSV时我会抽三个地方检查人物称呼是否统一、台词是否跟原剧本一致、景别分配是否有“全是特写”或“全是全景”的情况。这种审查不是逐行看而是抽样加排序检查十分钟内能完成一集。确认规则没问题后剩下几十集就可以放心批量跑。实际跑出来的结果里Codex生成的表格大概率不是完美的。比如某些镜头的画面描述重复度过高或者英文提示词把“a young woman”写成了“a young man”这种错误确实会偶尔出现。但更重要的是它把“从零开始写”变成“改错题”效率和心态完全不一样。4. 批量生成提示词与素材脚本省时间的大头4.1 把分镜表转成各服务商的提示词分镜表落定之后下一个大工程是把CSV里的image_prompt字段转成每个绘图服务商能用的最终提示词。这里有一个关键认知不同绘图服务对提示词的要求不一样但工作内容本质上是批量字符串处理。比如某家服务需要你把画面比例写进参数另一家需要你追加风格后缀还有一家希望负面提示词单独用英文逗号连接。如果手工操作每一行都要重新拼一遍容易出错也容易漏后缀。我把这些“拼接规则”告诉Codex让它写一个转换脚本一次性处理整张CSV。这一步还衍生出一个好习惯给每个服务商建一个独立的提示词配置模板放在data目录下。下次换服务商或者某个服务商改了参数规范我只需要更新模板再让Codex重新跑一遍转换脚本而不是手动改900条提示词。这个灵活性在AI工具更新频繁的当下特别值钱。4.2 用Codex写一个批处理脚本批处理脚本是整个工作流里最像“软件工程”的部分。流程图我不画了直接看代码。下面这个Python脚本是Codex给我的标准脚手架我加上注释后放在scripts/batch_generate.py里import csv import json import time from pathlib import Path PROMPTS_CSV Path(data/split_ok.csv) OUTPUT_DIR Path(shots) def load_shot_rows(): rows [] with PROMPTS_CSV.open(r, encodingutf-8-sig) as f: for row in csv.DictReader(f): rows.append(row) return rows def generate_image_for_shot(row): shot_no row[shot_no] out_file OUTPUT_DIR / fshot-{shot_no}.png if out_file.exists(): print(f跳过已存在{out_file.name}) return skipped # 这里替换成你实际绘图服务的请求 # 示例把row[image_prompt]发送到绘图API保存返回的图片字节 # resp post(api_url, headersheaders, json{ # prompt: row[image_prompt], # negative_prompt: lowres, watermark, text, extra fingers, # size: 768x1344, # }) # resp.raise_for_status() # out_file.write_bytes(resp.content) time.sleep(1) # 模拟调用耗时 print(f生成{out_file.name}) return generated def main(): OUTPUT_DIR.mkdir(parentsTrue, exist_okTrue) result [] for row in load_shot_rows(): status generate_image_for_shot(row) result.append({shot_no: row[shot_no], status: status}) Path(data/generate_manifest.json).write_text( json.dumps(result, ensure_asciiFalse, indent2), encodingutf-8 ) if __name__ __main__: main()这段代码有几处被我用注释占掉了因为每个绘图服务商的鉴权和请求体都不一样实际使用时你让Codex按官方文档补上就行。但核心设计有三个第一是“幂等”。文件如果已经存在就直接跳过不会重复生成覆盖这样哪怕中途网络中断、脚本报错修好之后重新跑一遍已经生成的素材不会白费。这个设计在长周期批量任务里极其重要。第二是“清单对账”。脚本跑完后会生成一个data/generate_manifest.json文件记录每个镜头是生成还是跳过。等全量跑完拿这个文件跟分镜表对比一下就知道哪些镜头漏了不用再人工数文件夹。第三是“小步验证”。main函数里对每个镜头串行处理一次只跑一张图稳定以后再考虑并发。很多人一上来就开多线程并发请求结果要么把API限流打爆要么一堆失败最后返工。做AI内容生产稳定排队真的比野蛮并发靠谱。4.3 跑批前一定要做的三件事脚本写完之后我建议不要立刻对全量900个镜头下手先做三件准备。第一件抽2到3个镜头做小样。把分镜表里前几行单独存成一个小CSV跑一遍脚本重点确认图片比例是否正确、画风是否统一、脸部有没有变形、文字是否乱入。这一步相当于电影开拍前的试妆照有问题早发现早改。第二件确认密钥和路径都干净。所有API密钥必须从环境变量读取不要写死在脚本里。路径不要用带空格和中文的目录Windows上老老实实全英文路径能避免九成奇怪问题。第三件给脚本设置合理的重试和超时。真实世界里的接口永远会有偶发失败200个请求全部一次成功的概率并不高。让Codex在调用API的位置加上重试三次和指数退避的逻辑整个批处理会稳很多。我早期没加重试一口跑下来损失了十几张图补起来非常麻烦。跑批的体验也值得一提。以前我坐在电脑前一张一张手点生成像流水线工人一样盯到凌晨现在脚本跑起来机器自动排队我只需要偶尔看一眼进度该睡觉睡觉。第二天醒来素材躺在文件夹里manifest把缺的镜头也列得清清楚楚。5. 实操中的坑与排查方法5.1 登录、模型、网络这三类高频问题用Codex三个月真正让我卡住的问题基本都是环境问题。我整理成一张表遇到类似情况可以直接按表排查。现象可能原因解决方向Codex登录后转圈或提示auth token is unavailable登录令牌失效、订阅状态异常、浏览器操作中途断掉在终端重新执行codex login确认账号权限正常升级到新版客户端后重试报错model is not supported配置文件里填了当前账号/客户端不支持的模型名删除自定义模型名回到官方默认模型别照抄教程里的过期模型名报错local proxy failed while handling codex endpoint /responses本地代理配了但没监听、端口不对、证书不受信任检查终端里的HTTP_PROXY和HTTPS_PROXY环境变量确认代理进程在运行、端口填写正确不需要代理就清空变量并重启终端请求全部超时或大量失败网络抖动、目标服务限流在脚本里加入超时参数和指数退避重试别一次性开高并发图片生成出来全是1:1方形绘图服务默认尺寸是1:1调用参数里直接指定宽高9:16可用768x1344或832x1472宁可参数写死不要事后裁剪这里面最让我折腾的其实是“local proxy failed”那条。有一段时间我电脑上装过抓包调试工具它顺手改了我的环境变量Codex每次发起请求都被引导到一个根本不存在监听端口的本地代理上报错提示又不太明显我一度以为是我的服务商出了问题。后来把环境变量清空再重开终端问题直接消失。所以遇到连接类报错先检查环境变量准没错。5.2 编码、文件名与“找不到文件”细节Windows用户遇到Codex最容易踩的第二个坑是编码问题。分镜表里有中文对话Python脚本读CSV时不指定编码很容易出现UnicodeDecodeError或者输出乱码。我的统一做法是CSV读取用utf-8-sig编码写入文件全部指定encodingutf-8终端环境变量加PYTHONIOENCODINGutf-8。这三件事让Codex在脚本生成阶段直接帮我写好后面就不会反复踩。文件名方面我吃过中文文件名的亏。素材文件如果叫“女主角吃饭特写.png”不仅会有奇怪的全角字符问题很多API服务对中文文件名的处理也不透明。我现在统一用shot-0101.png这种编号命名中文描述全部放在manifest和分镜表里维护。文件名只承担“索引”职责描述交给数据库。5.3 素材完整性校验漏镜头这件事比想象中常见做批处理最怕的不是某张图生成很慢而是生成完没人发现漏了一个镜头。我前三部项目都出现过这种尴尬剪到第三集发现女主角一个关键表情找不到回头一看是分镜表里镜头号重复后一个文件把前一个覆盖了。现在的解决方案非常简单第4.2节里的manifest文件。脚本跑完用镜头号列表和实际文件列表做一次差集有多少个文件、多少个镜头、哪些缺一眼就能算清楚。Codex还能帮我把这个差集核对逻辑直接写成一个check.py脚本每次跑完自动执行缺文件就打印清单。素材校验从原来的半小时人工翻文件夹变成了十秒钟的命令行输出。6. 三个月实测到底省了多少还有哪些事必须自己做6.1 拿一部36集动态漫算一笔时间账我这三个月实际跑了三个项目最完整的一部是36集动态漫约900个镜头。我拿它算了笔账。手工时代分镜表拆解加提示词编写一集大概40到50分钟36集起码24小时以上。实际上人没法连续高效工作那么久真正做完差不多花了一两个星期晚上。跑批期间隔三差五要人工检查、补图、改错反反复复。现在这套流程跑下来一集分镜表初稿大约5到8分钟由Codex完成人工审查和修正一集控制在15到20分钟36集总共大约10到15小时。素材批处理几乎全自动人只需要负责小样审查和后期抽查。这样算下来时间确实省了一半以上而且省下来的都是白天精力最好的时段。还要算一笔隐性收益。以前我熬夜手搓提示词编到第600个镜头时已经麻木经常把“女二”写成“女主”。现在这个环节交给机器一致性检查也由脚本来做错误率明显下降剪辑阶段的痛苦少了一大半。6.2 Codex管不了的事审美、版权和人设一致性不过我必须泼一点凉水Codex不是万能的指望它包办一切会撞墙。第一它管不了审美。分镜表可以由它拆但“这个镜头光线要不要再柔一点”“女主角的眼神能不能更有攻击性”这些判断必须人来做。AI短剧到最后拼的仍然是审美工具只是把执行成本降低了。第二人设一致性需要人自己下功夫。Codex无法保证同一个角色在900张图里长得一样。你仍然要用参考图、LoRA或者角色提示词库来控制画风这是美术工程不是文本自动化能替代的。第三版权和合规必须自己把控。素材不要用未经授权的图片、音乐、配音素材AI生成内容的平台标识规则也在变化。码农交给Codex担责任的人永远是你自己。6.3 现在我的日常AI短剧SOP最后分享一下现在这套稳定的流程供参考。我的SOP是剧本定稿后放进data/script.txt第一件大事是让Codex拆分成集和分镜CSV第二件大事是人工审查分镜表确认人物关系、台词、镜头节奏第三件大事是让Codex生成转换脚本和批处理脚本第四件大事是小样试跑检查画风和人设确认后再全量跑图、跑配音跑完后用manifest对账缺件补跑最后才进剪辑软件做合成和字幕包装。每一步之间都有明确的检查点不会等到最后一刻才发现问题。我个人在实际操作里的一个建议是每次新开项目都从Git仓库开始而不是从“随便建个文件夹”开始。哪怕你是几个人合作、哪怕你完全不懂Git只要让Codex帮你初始化仓库把代码、数据、脚本都纳进来版本管理的收益会随着项目变长越来越明显。AI工具更新很快但工作流和项目纪律不会过时。还有个小技巧我越用越顺手每次让Codex跑批量任务前都给它单独立一条“只读检查”的任务让它先读一遍数据文件、统计一下镜头数和字段完整性然后再执行生成。这相当于代码正式构建前先跑一遍静态检查能挡掉大量低级错误。这个方法不复杂但非常实用。
