做短视频的人应该都有这种体验同一个口播稿要套同一个模板剪出几十条甚至上百条片子但每一枪都是手工开字幕一帧一帧对BGM一段一段拖导出前还得反复检查有没有出错。所以当我第一次把Codex和剪映Skill组合起来跑通“从脚本到草稿”的全自动流程时我的第一反应不是“AI真先进”而是“终于不用逐条剪了”。这套方案的核心其实就两件事Codex负责拆解任务、写JSON、操作文件剪映Skill则负责告诉Codex“剪映草稿到底长什么样、字段该怎么填”。两者一接上你只需要准备一份口播稿和素材清单就能批量生成剪映工程文件打开剪映直接预览成片。适合谁适合批量做口播号、带货切片、课程视频、资讯混剪的运营和博主也适合想研究Agent自动化落地的开发者。这篇文章我会把环境安装、Skill设计、草稿JSON结构、批量编排和踩坑过程全部写出来照着做就能跑通。1. 项目到底要做什么一条自动化的视频生产线1.1 手工剪辑的痛点重复劳动吃掉创作时间先说说我在做批量口播视频时的真实状态。以前团队每天要出10到15条短视频内容结构高度一致开头hook、中间口播、结尾引导关注配一条字幕、一段BGM、一个固定的封面风格。看起来没什么难度但真正执行起来特别耗人。每一条视频剪辑同学要做的动作是固定的导入口播录音、对齐波形、切掉气口、加字幕、调字号、拉到统一位置、配背景音乐、压低人声、检查有没有错别字、导出不同比例的版本。一整套下来单条视频大概15到20分钟。如果中间客户改个口播稿或者某个字发音错了要重录那20分钟要重新来一遍。一个月下来团队大头的时间不是花在“想创意”上而是花在“重复执行同一套动作”上。这就是自动化的切入点。因为我发现这种视频的“剪辑规律”完全可以用规则描述口播稿有文本时长可以估算字幕逐句对应BGM固定轨道封面样式固定。一旦规则能描述清楚就可以交给程序执行。1.2 为什么是Codex 剪映Skill而不是别的方案市面上做视频自动化的方案其实不少有直接用FFmpeg命令行拼片的有写Python脚本调MoviePy的也有各种云端剪辑API。但我在实操中遇到一个很现实的问题我的最终交付物是要给客户看的而客户最熟悉的工具就是剪映拿到工程文件还能自己改字幕、改配音、改样式。如果用FFmpeg直接压片客户拿到一个成品MP4发现某个字幕错了只能重新提需求再等一轮效率反而更低。于是我把目标定为“自动生成剪映草稿工程”让客户打开剪映就能继续改。选Codex的原因也很简单它不是一个只能回答问题的聊天机器人而是一个能在本地终端里做事的Agent。它能读文件、写文件、执行命令还能把一个复杂任务拆成多步完成。我要它“读取口播稿、调用TTS生成配音、生成字幕、按模板写出剪映草稿JSON”它能真正一步步执行而不是只给我一份建议方案。剪映Skill则是给Codex装上的“行业知识包”。默认情况下Codex不了解剪映草稿的JSON结构直接让它生成它会编出很多不存在的字段产出草稿根本打不开。而把Skll文件放进Codex的技能目录后Codex就知道什么时候该用哪套模板、字段要填什么、素材路径该怎么写。这跟给新同事写SOP是一个道理人有了SOP才稳定AI有了Skill才不飘。2. 环境准备把Codex和剪映Skill装到能用的状态2.1 Codex CLI安装与登录先说Codex命令行工具的安装。我主力用的是Windows环境另外在macOS上也配过一套两边流程差别不大。Windows上首先确认装了Node.js版本尽量18以上。然后打开终端执行npm install -g openai/codex装完确认一下版本codex --version如果提示“codex不是内部或外部命令”八成是npm的全局bin目录没进系统PATH把Node.js安装目录下的全局路径加到环境变量里再重开终端就行。登录认证有两种方式。一种是用账号登录终端里执行codex login按提示浏览器授权。另一种是直接用API Key设置环境变量export OPENAI_API_KEYsk-xxxxxWindows的命令行窗口里用set OPENAI_API_KEYsk-xxxxxPowerShell用$env:OPENAI_API_KEYsk-xxxxx。这里有一个我踩过的坑Codex的配置文件名是config.toml默认放在用户目录的.codex文件夹下。如果你要自定义模型服务商的地址和模型名必须明确知道这个文件的存在。很多网上教程只告诉你装好了、登录了却不告诉你配置文件怎么改后面接第三方API时会很痛苦。2.2 接入第三方模型服务以DeepSeek为例我的实际情况是需要把Codex接入第三方模型API来跑任务因为不同场景用的模型不一样写口播稿和生成字幕文本用中文能力强的模型写JSON和做路径拼接用指令遵循好的模型。修改config.toml是核心操作。先打开配置文件codex config edit然后在[model_providers]下面添加一个服务商并在[model]里指定模型和提供商。比如model deepseek-chat model_provider deepseek [model_providers.deepseek] name DeepSeek base_url https://api.deepseek.com/v1 env_key DEEPSEEK_API_KEYenv_key的意思是Codex会读取环境变量DEEPSEEK_API_KEY的值作为认证凭据。所以还要提前设置好export DEEPSEEK_API_KEYsk-xxxxx加完provider后执行一句最简单的codex 你好验证能不能通。我遇到过一个问题明明API Key没错却一直收到auth token is unavailable的提示。排查后发现是我把环境变量名写成了OPENAI_API_KEY而配置文件里指定的是env_key DEEPSEEK_API_KEY两边没对上。Codex按env_key去找变量找不到就报认证失败不是Key本身的问题。2.3 剪映Skill的安装与目录结构剪映Skill本质上是一组给Codex看的指令文件不需要额外安装什么复杂程序只需要把文件放到Codex的skills目录里。我的技能目录结构是这样的~/.codex/skills/ └── jianying/ ├── SKILL.md └── templates/ └── draft_example.jsonSKILL.md是核心里面写清楚这个Skill的适用场景和生成草稿的具体步骤。templates目录放一个标准的草稿JSON模板Codex生成新草稿时会先参考这个模板。安装动作其实就是“把文件夹放对位置”。放好之后重启终端Codex就能在任务需要时自动检索到jianying这个Skill。2.4 第一次验证让AI生成一个“最小草稿”安装完不要急着跑大任务先做一个最小验证给Codex一个极简任务让它生成一个只有一段视频和一句字幕的草稿。比如codex 生成一个剪映草稿包含一段10秒视频和一句字幕“测试”输出到 output/test/跑完之后到output/test/目录看是否生成了draft_content.json然后用剪映打开这个草稿看能不能正常识别。我第一次做这个验证时生成的草稿剪映直接提示“工程文件错误”连打开都打不开。原因就是Codex不知道剪映草稿JSON的真实结构编了一套“看起来很像”的字段。从那时起我才真正意识到Skill文件的重要性不管AI多聪明没有准确的行业规范给它它只能在错误的方向上自信地发挥。3. 自动化工作流设计从脚本到草稿的核心引擎3.1 视频生产的五个环节拆解要做自动化第一步是把一条视频的“生产流程”拆成计算机能执行的环节。我拆成五步环节产出物执行方式备注脚本生成口播稿文本Codex调用模型生成按选题和字数要求写配音生成MP3或WAV音频TTS API可指定音色、语速字幕内容每句字幕文本及时间点从口播稿按句切分有稿子就不用识别草稿生成剪映草稿draft_content.jsonCodex调用剪映Skill写入视频、音频、文本轨道导出成片MP4剪映人工点导出或UI自动化目前还不能纯命令行完成可以看到前四步可以完全自动化最后一步导出还需要人工介入。这也是我给团队定的边界机器负责到“剪映工程文件”这一步人负责打开剪映确认效果和点击导出。这样做的好处是如果字幕有问题直接在剪映里改即可不用重新跑全流程。3.2 Skill本质是给AI的SOP怎么写经常有人问我Skill到底是什么、和普通Prompt有什么区别。我的理解是普通Prompt是一次性的说明而Skill是沉淀好的、可复用的操作手册而且Codex能自动识别“什么任务该用哪个Skill”。我最开始写的SKILL.md长这样你可以直接参考--- name: jianying description: 生成剪映草稿工程文件。适用于批量创建口播视频、字幕视频、混剪视频的项目。 --- # 剪映草稿生成准则 1. 拿到任务后先确认输出目录目录不存在则创建。 2. 草稿文件命名为 draft_content.json放在输出目录根下。 3. 所有素材文件统一放入输出目录的 assets/ 子目录并使用相对路径引用。 4. 默认画布尺寸竖屏 1080x1920横屏 1920x1080。 5. 每条字幕默认 4 秒以内按口播稿逐句切分。 6. 字幕样式固定为字体大小 45底部居中白色。 7. 生成前先读取 templates/draft_example.json 作为格式参考。 8. 生成后用 Python 检查 draft_content.json 是否能被 json.load 正确解析。这里最关键的其实是第7条。Codex只有看到具体模板才知道“字段层级长什么样”。如果你只给它一堆文字描述它一定会自由发挥。写SKILL.md的另一个原则是把容易出错的地方写成人必须遵守的规则。比如“使用相对路径”这条我是在碰到素材离线问题后加上去的。不加这条Codex经常会把素材路径写成绝对路径导致草稿换一台电脑就打不开。3.3 剪映草稿JSON只需要搞懂这几个关键块剪映草稿是一个文件夹核心文件是draft_content.json里面记录了画布、轨道、片段、素材路径、特效、字幕样式等全部信息。我不建议你一开始就去研究所有字段只抓住几个关键块就够了。下面是核心骨架的简化示例字段名可能随剪映版本变化但逻辑基本一致{ canvas_config: { width: 1080, height: 1920 }, tracks: [ { type: video, segments: [ { id: segment_video_1, target_timeline_duration: 12000, source_path: assets/main.mp4 } ] }, { type: audio, segments: [ { id: segment_audio_1, source_path: assets/vo_01.mp3, target_timeline_duration: 12000, volume: 1.0 } ] }, { type: text, segments: [ { id: segment_text_1, content: 欢迎来到我的频道, start: 0, duration: 3000, font_size: 45 } ] } ] }canvas_config控制画布尺寸这是横竖屏的关键tracks数组里按video、audio、text分成不同的轨道每个segment就是一个素材片段source_path指向素材文件的位置target_timeline_duration是片段在时间线上的时长单位是毫秒。我学习这个结构的方法很笨但很有效先在剪映里手工创建一个只有一段视频和一行字幕的草稿然后用编辑器打开draft_content.json对照自己的操作逐项看字段变化比如改了字幕字号就看看哪个字段变了。这种方式比看任何教程都直接因为你用的剪映版本和网上教程可能不一样字段也会有差异。3.4 批量任务编排把清单变成几十个草稿单条草稿生成不是难点真正的价值是批量。我的做法是把所有要生成的视频信息整理成一个清单文件让Codex按清单逐条处理。清单用CSV或Markdown都行我习惯用下面的结构video_001.md: 标题夏日咖啡店打卡口播稿...配音音色女声时长30秒 video_002.md: 标题新手跑步入门口播稿...配音音色男声时长45秒然后写一个批处理脚本for i in $(seq 1 30); do codex 根据 scripts/video_$i.md 生成剪映草稿输出到 output/video_$i/ python3 verify_draft.py output/video_$i/draft_content.json doneverify_draft.py是一个简单的校验脚本只检查JSON解析和关键字段存在性import json import sys with open(sys.argv[1], r, encodingutf-8) as f: data json.load(f) assert canvas_config in data, 缺少画布配置 assert tracks in data, 缺少轨道信息 for track in data[tracks]: if track[type] text: for seg in track[segments]: assert content in seg, 字幕缺少content字段 print(草稿校验通过)之所以要做校验是因为Codex偶尔会在生成过程中“偷懒”比如把多个字幕合并成一条或者漏掉视频轨道。校验脚本能提前发现异常不用等到剪映里打开才发现问题。批量生成时一定要先小批量试跑3条人工确认没问题后再一次性跑全量否则30条草稿全错返工量会让你怀疑人生。4. 实操记录第一次跑通完整生成流程4.1 一次真实的任务过程拿我第一次完整跑通的案例来说。任务要求是根据一份口播稿生成一条30秒竖屏口播视频草稿具体要包含配音、字幕和背景音乐。我执行了这么一条命令codex 读取 scripts/day01.md 中的口播稿用女声音色生成配音生成逐句字幕添加 assets/bgm.mp3 作为背景音乐最终输出一个1080x1920的剪映草稿到 output/day01/Codex的做法大致是先读取脚本文件然后调用配置好的TTS接口生成配音接着按口播稿句子数量和时间点切分字幕再读取jianyingSkill里的模板把素材路径、时长、字幕内容填进去最终写出draft_content.json。第一次看到完整生成结果时我很兴奋但打开剪映后被泼了一盆冷水画面正常配音正常但字幕全部没有显示。后来排查发现问题出在文本轨道的字段写错了Codex把字幕内容写进了content字段但剪映当前版本需要的是content加额外的文本样式对象漏了样式对象字幕就静默失败了。这个案例说明Skill模板不是写一次就完事的每换一个剪映版本都要重新对照一次真实草稿结构。4.2 字幕、配音和BGM参数怎么定字幕参数的设置我建议在Skill里固定一套“公司标准”。我目前用的是字号45白色底部居中最长显示4秒。为什么是4秒因为中文口播大约每秒3到4个字一条字幕超过4秒阅读负担会明显增加。配音生成这块关键参数是采样率和声道。我固定输出48kHz、双声道MP3因为在剪映时间线上对轨更稳。如果TTS输出的是单声道也不影响使用但音量响度会偏低需要适当调高音频轨道的volume值。BGM的参数比较容易被忽略。背景音乐的音量不能简单设成和配音一样的1.0否则人声会被盖过去。我的经验是纯口播场景BGM音量设在0.15到0.25之间比较安全如果口播和BGM之间有节奏感要求可以提高到0.3但一定要让人声清楚。这个值在JSON里对应音频片段的volume字段直接填小数即可。4.3 批量生成时参数对照表为了方便团队直接抄作业我整理了一份常用参数对照表参数竖屏口播横屏教程说明画布宽高1080x19201920x1080canvas_config.width/height字幕字号4550横屏观看距离远稍大字幕最长展示3000~4000ms4000~5000ms结合语速调整配音采样率4800048000越高越稳但文件大BGM音量0.15~0.250.2~0.3不要超过人声音频淡入淡出各500ms各500ms避免突兀视频转场不用0.5s交叉溶解教程场景避免花哨时长估算公式也很简单总时长约等于口播稿字数除以3.5单位是秒。比如150字的口播大约43秒。如果你要卡30秒字数控制在105字左右比较稳妥。这个公式我用了很久准确率八九不离十剩下的误差交给“镜头留白”去吸收。5. 踩坑实录与问题排查5.1 Codex连不上、认证失败的几条排查路径用Codex的过程中最常见的报错就那么几个我逐个说下处理思路。auth token is unavailable多半是环境变量没对上。先确认你配置的provider用的是哪个env_key再去环境变量里检查有没有这个变量。我遇到过一次原因是改了config.toml后忘了重开终端新环境变量没生效。request timed out这个报错在任务复杂时出现概率很高。原因通常是请求体太大或者服务响应慢。我的处理方法是把任务拆细一次只让Codex做一个工程不要试图让它“一次生成50条草稿”同时在配置里把超时时间调大一些。如果连着多次超时看看是不是API服务商那边本身在限流换一个时间段再跑。model is not supported when using codex这个报错的意思是你在config.toml里指定的模型名在当前API服务商那里不存在。比如你写了gpt-5.6-sol这种编出来的名字服务商当然不认识。解决方法是去服务商官网查支持列表把模型名改成列表里真实存在的值。5.2 剪映草稿打不开、字幕不显示的排查剪映草稿打不开十次里有八次是JSON结构问题。我的排查顺序是第一步用剪映手工创建一个最简单的草稿导出draft_content.json作为基准文件。第二步把AI生成的草稿和基准文件做结构化对比重点看tracks数组里字段层级是否一致。第三步检查素材路径确认assets/目录里的文件真实存在。素材显示离线基本就是路径问题。我出过一次事故素材文件名带空格Codex在JSON里没有做转义剪映找不到文件。从那以后我要求所有素材文件名统一使用英文小写加下划线例如bgm_lofi_v1.mp3彻底规避这类问题。字幕不显示除了前面提到的字段缺失还有一种情况是内容包含特殊字符。比如字幕里有双引号JSON里的引号必须转义如果不转义整个JSON解析就会失败字幕轨道直接失效。我的做法是在Skill里明确要求所有文本使用Unicode转义后的等价写法提交而不是直接塞原始字符串。说白了就是让AI“老实一点”不要炫技。5.3 我的经验速查表现象可能原因处理办法auth token is unavailableAPI Key环境变量没配对检查config.toml的env_key和系统环境变量是否一致请求超时任务过大或服务限流拆分任务、加大超时时间、换个时间段重跑model not supported模型名不在服务商列表换成服务商支持的真实模型名草稿工程打不开JSON与当前剪映版本字段不匹配用当前版本手工草稿做基准逐字段对比素材离线路径错误或文件名含空格统一素材命名规则全部用相对路径字幕不展示文本轨道字段缺失或特殊字符未转义对照真实草稿补全字段统一转义文本批量生成后全错没有先跑小批量验证先试跑3条人工确认后再跑全量6. 自动化的边界与后续能扩展的方向6.1 目前还做不到的事情别把这个方案想成“全自动印钞机”它有几个边界必须认清。第一剪映目前没有官方命令行导出接口我所说的“自动生产”其实止步于生成工程文件和素材组织最后一步“导出成片”仍然需要有人打开剪映点一下导出按钮。如果你面对的是一条两条视频这没什么但如果你一天要导出50条这一步也是不小的人工成本。想进一步自动化的话可以考虑用UI自动化点击导出但这属于另一个话题稳定性取决于你用的工具。第二复杂特效、转场、蒙版、关键帧动画这类非线性操作用直接写JSON的方式很难做优雅。AI不是不能写而是写出来的效果很难控制而且剪映版本一升级可能就崩。我现在的策略是模板化的口播视频交给自动化创意型的特效视频依旧留给人工精剪。第三版权问题。自动化只能提高效率不能代替你判断素材是否可用。BGM、视频素材、图片素材的授权情况必须自己把关。这个问题没有技术解只有流程解。6.2 后续可以扩展的方向这个方案跑通后很多玩法可以做延伸。我目前在酝酿三个方向第一个方向是接选题自动化。把热点话题、评论区高频问题、搜索建议关键词喂给Codex让它生成一批口播稿再走自动剪辑流程形成“选题到草稿”的完整链路。第二步是接TTS音频库。不同音色、不同语速、不同情绪生成多条配音版本用A/B测试的方式判断哪种音色转化更好。第三步是做一个内部“视频工厂”命令集把“加字幕、换配音、改BGM音量、批量生成”这些常用操作封装成固定命令团队里任何人都会用不依赖某一个人掌握完整技术细节。我个人的体会是这套方案最大的价值不是“省了时间”而是把视频生产变成了一条可以量化、可以复用的流水线。过去团队招剪辑看的是个人熟练度现在只要把流程和Skill沉淀下来哪怕换个新人也能稳定产出标准一致的片子。踩过几次坑之后我最大的心得是不要指望AI凭空理解一个专业工具的格式先把现状复杂却规则化的工作变成一套模板和规范然后让AI在这套规范里干活才是真正靠谱的自动化。最后再分享一个小技巧每次批量生成前先随便挑一条草稿在剪映里打开确认素材、字幕、配音都没问题再跑全量。这个动作多花一分钟却能避免一次50条草稿全部翻车的大事故。素材文件命名也尽量避开中文和空格这是我在这个问题上交过学费之后才改掉的毛病。