如果你也烦透了每次剪视频都要逐条拖素材、对字幕、调导出参数那这篇记录应该能帮你省下不少时间。我最近把 Codex 和剪映 Skill 搭在一起把“选题—素材—成片”里最重复的那段流程做成了自动化流水线目前已经稳定跑完了好几批批量视频项目。这里说的“全自动”不是让你彻底不碰剪映而是那些机械的替换素材、改字幕、统一画幅和码率的工作全部交给 Codex 读取工程文件后自动完成。整个过程踩了不少坑下面从思路拆解到具体步骤尽量完整写出来。1. 这个自动化方案到底在自动化什么1.1 先看清楚剪映草稿的本质剪映的工程项目不是某种神秘的私有格式它本质上就是一个本地文件夹。你每次在剪映里新建的草稿在磁盘上会有一个对应目录核心文件叫draft_content.json。时间线上所有视频片段、音频、字幕、转场、特效的参数全部都被写在这个 JSON 里。也就是说只要你能够读写这个 JSON你就有机会批量生成剪映工程而不是靠鼠标在界面里一段一段拖。举个例子你在时间线里放了一段视频剪映并不是直接把这个视频文件“嵌入”草稿而是在draft_content.json的某个segment里记录它的本地路径、起止时间、缩放位置等参数。字幕同理一个字幕条对应一个text对象连字体、字号、描边、位置都在里面。你要做的所有重复劳动比如把第 3 条视频换成另一个素材、把第 2 条字幕改一行字本质上都只是改这个 JSON 里的字段。所以方案的第一步不是学剪映的插件开发而是先搞清楚草稿文件的目录结构和字段规律。这事听起来简单实际坑很多后面我会专门讲。1.2 自动化视频生产的三层拆解我把“视频生产全自动化”拆成了三层三层之间用 Codex 去串联。素材整理层把原始视频、图片、音频、文案统一放到固定目录并生成一张 CSV 清单CSV 里每一行代表一条待生产的成片。工程生成层根据 CSV 里的内容复制一个事先做好的剪映模板草稿批量替换掉时间线里的素材引用和字幕文本。渲染交付层让剪映打开对应草稿并导出成片再用 FFmpeg 统一转码、压缩画幅、生成封面最后归档到交付目录。如果哪一层出了问题可以单独排查。比如素材路径错了问题多半在素材整理层所有成片画幅不对问题就在渲染交付层的 FFmpeg 参数。把流程拆开比一个人坐在剪映里从头剪到尾更容易控制质量也更容易让别人接手。1.3 为什么选 Codex Skill而不是纯脚本你可能会问直接写个 Python 脚本改 JSON 不就行了吗确实可以但问题是剪映草稿的结构不是给二次开发准备的字段嵌套很深而且不同版本会有变化。如果让我把“把第一条字幕往后顺延 0.5 秒同时保证和配音对齐”这样的需求固化成一段脚本脚本会非常脆换个草稿就不工作了。Codex 的价值在于它能理解自然语言描述的任务然后自己决定改哪些字段。比如你告诉它“把这条字幕时长改成 3 秒”它会去定位到 text segment 的 duration 字段而不是你手动告诉它改第几行。但让 Codex 自由发挥很危险它可能给你新增一堆莫名其妙的字段。所以必须配一个 Skill用来把剪映草稿的操作规则固化下来。可以把 Skill 理解为一份机器可读的 SOPCodex 每次执行剪映相关任务时都会先读这份 SOP然后按照里面的字段表、操作规范去改。这相当于既给了 Codex 一双能干活的手又给它画了一条明确的边界线。2. 环境准备把 Codex 和剪映 Skill 接通2.1 安装 Codex 并完成基础认证我这边主力环境是 macOS直接用 Homebrew 装的 Codex。如果你在 Windows 上用 npm 全局安装也是一样的。装好之后最关键的一步是登录授权终端里执行codex login按提示完成授权后Codex 会在用户目录下保存本地凭证。装完先别急着跑大任务先验证一下 CLI 是否可用codex exec hello能正常返回就说明网络和认证都没问题。如果你是命令行苦手也可以用桌面版窗口界面会更友好一点但后面要接脚本批量执行的话我建议还是把 CLI 装好因为 CLI 更方便被程序调用。这里有一个很容易踩的坑Codex 需要联网调用模型接口如果公司网络或校园网限制比较多经常会出现请求超时报错往往是request failed或者endpoint /responses相关的提示。这不是你本地配置出错了换一个稳定的网络环境再试一次往往就好了。2.2 剪映 Skill 到底放在哪、长什么样Codex 的 Skill 机制很好理解在指定目录里放一个文件夹里面写一个SKILL.md告诉 Codex“当用户要处理剪映草稿的时候请先读这份文件”。我习惯把 Skill 放在~/.codex/skills/jianying_draft/SKILL.mdSKILL.md看起来是这个样子核心是 frontmatter 里的name和description--- name: jianying_draft description: 当用户要求操作剪映草稿、批量生成剪映工程、修改字幕或素材引用时使用 --- # 剪映草稿操作指引 ## 草稿位置 - macOS: ~/Movies/JianyingPro/User Data/Projects/com.lveditor.draft/ - Windows: %USERPROFILE%\AppData\Local\JianyingPro\User Data\Projects\com.lveditor.draft\ ## 关键字段 - segments: 时间线片段列表 - material_id: 素材引用 ID - duration: 片段时长单位微秒 - text_content: 字幕文本内容这份文件是整套自动化的地基。Codex 对剪映的理解完全来自你写的这些说明。你写得越细它后续操作越稳。我一开始偷懒只写了两行描述结果 Codex 每次改出来的 JSON 都缺字段后来老老实实把字段表补全准确率立刻上来了。2.3 Skill 里的关键配置和边界控制我在SKILL.md里固定了几个小节缺一不可草稿定位给出不同操作系统的路径模板并且告诉 Codex 如果路径不符合就用搜索命令找。字段速查用表格列出关键字段比如segments、material_id、duration、text_content、volume、source_timerange等。操作规范要求修改前必须先备份原文件修改后必须做 JSON 格式校验。禁止事项明确告诉 Codex除非用户主动要求否则不要新增字段也不要删除原有配置。返回格式要求每次操作完成后输出一份改动摘要让别人一眼看出它改了哪几个文件、改了哪些字段。这些边界非常重要。Codex 本质上是生成式模型你不给它边界它就敢给你自由发挥。比如它可能会把素材路径里的反斜杠全部转义或者给某个回调节点补一个不存在的默认值。出现这些问题后我在 Skill 里加了一条“只修改模板中已有的值不要新增任何字段”问题就少多了。3. 完整实操从一张表格到一批成片3.1 第一步准备好素材清单和模板草稿自动化不是从零开始而是需要一条“母版草稿”。我会先用剪映手动创建一条 20 秒左右的母版里面包含两段视频、一段配音、两条字幕和一个转场。这条母版负责把所有样式确定下来比如字幕字体、颜色、位置、视频转场效果后续所有成片都会基于它复制。然后建立素材目录结构大致是project/ templates/ # 母版草稿目录 videos/ # 原始视频素材 audios/ # 配音文件 batch.csv # 待生产成片的清单batch.csv我一般这样设计id,title,video_path,audio_path,subtitle1,subtitle2 001,产品介绍,./videos/001.mp4,./audios/001.mp3,这是第一句,这是第二句 002,使用教程,./videos/002.mp4,./audios/002.mp3,先打开设置,再点击保存之所以要把信息放进 CSV是因为 CSV 方便编辑也方便 Codex 逐行读取。你只需要维护这个表格不需要打开剪映逐条改字幕。3.2 第二步让 Codex 按 Skill 批量改写草稿准备好之后就开始真正执行。我在终端里下的指令类似这样codex exec 读取 project/batch.csv根据 jianying_draft skill 批量生成草稿到 project/generated 目录。每个草稿使用 project/templates 作为基础替换视频素材、配音和字幕字段并校验 JSON 格式。Codex 会先读取 SKILL.md再定位模板草稿目录里的文件然后用 Python 脚本逐条处理 CSV。整个过程中它会自己创建临时脚本去解析 JSON、修改字段、写入新文件。我们不需要手动去改某个草稿所有批量操作它都会完成。强烈建议第一次跑的时候加一句“先做 dry run只输出改动计划不实际写文件”。这样你能在写坏之前看到它打算改哪些字段。确认无误后再让它真正写入。执行完之后先别急着批量导出打开剪映随便选一个生成出来的草稿检查一下。第一次大概率会提示“部分素材缺失”这个非常正常。原因可能是剪映版本不同或者素材路径没有保持相对路径这个问题我放到踩坑部分详细说。3.3 第三步渲染导出与统一转码剪映官方没有提供命令行导出接口所以“全自动”的最后一公里我需要用一点取巧的方式。如果导出量不大可以让 Codex 通过系统自动化脚本打开剪映、激活目标草稿然后模拟点击一次导出按钮。macOS 上可以用 AppleScriptWindows 上可以用 AutoHotkey。核心思路是“让剪映打开一个草稿然后触发导出快捷键”。这个方案依赖剪映具体的界面布局和窗口位置所以比较脆弱。我一般只在导出几十条成片时用量大或者换电脑后我还是会让剪映批量导出再用 FFmpeg 统一加工。FFmpeg 这层是重点统一做三件事分辨率统一为 1080x1920帧率统一为 30视频码率统一压到 7.5 Mbps。码率怎么算根据目标文件大小反推目标文件大小 码率 × 时长 / 8假如一段 60 秒的视频希望最终不超过 60 MB那总码率就是 60×8/60 8 Mbps。音频占掉 128 kbps 后视频码率就给 7.5 Mbps这样最后文件大小刚好在预算内。转码命令我一般这样写ffmpeg -i input.mp4 -vf scale1080:1920:force_original_aspect_ratiodecrease,pad1080:1920:(ow-iw)/2:(oh-ih)/2 -r 30 -b:v 7500k -b:a 128k -c:v h264 -c:a aac output.mp4解释一下参数scale1080:1920:force_original_aspect_ratiodecrease是让视频等比缩放到 1080 宽以内pad再把多余部分补成黑色这样横屏素材放进竖屏画幅也不会拉伸变形。这是竖屏短视频最稳妥的适配方式。3.4 第四步自动生成标题封面和交付目录成片转码之后还需要封面。封面这件事其实很机械不需要让 Codex 去“理解设计”我直接用 Python 脚本从 CSV 里读标题生成 1080x1920 的封面图。PIL 的写法也很简单from PIL import Image, ImageDraw, ImageFont img Image.new(RGB, (1080, 1920), #0F0F0F) draw ImageDraw.Draw(img) font ImageFont.truetype(PingFang.ttc, 80) title 产品介绍 bbox draw.textbbox((0, 0), title, fontfont) x (1080 - (bbox[2] - bbox[0])) / 2 y 800 draw.text((x, y), title, fontfont, fill#FFFFFF) img.save(cover.jpg)实际做封面时我会加一些装饰元素但核心思路就是“数据驱动”。CSV 里写了什么标题封面上就自动出现什么标题。最后把所有文件按交付目录归档deliverable/ 001/ final.mp4 cover.jpg export_report.json 002/ final.mp4 cover.jpg export_report.jsonexport_report.json里记录源文件、输出时长、输出路径、码率等信息方便回溯。到这一步整套流水线就算跑通了。4. 踩坑实录我把所有能踩的坑都踩了一遍4.1 连接与认证相关Codex 安装之后遇到最多的问题就是登录授权失败。报错大概长这样auth token is unavailable。我一开始以为是安装问题后来发现是浏览器授权回调没有成功写入本地文件或者本地凭证权限不对。解决办法很直接删掉旧配置文件重新执行codex login。但有个细节需要注意如果你在用网络限制比较严格的办公网络授权回调很容易被切断切回个人网络再试一次基本就好了。还有一个问题是请求一直超时。我先检查了网络是不是稳定然后看 Codex 的日志。日志里如果只是偶发超时多半是模型服务端波动稍等重试就好。不要一上来就怀疑是自己配置错了反而浪费时间。4.2 剪映草稿结构相关最大的坑不是 Codex而是剪映版本更新。只要剪映升级draft_content.json里的字段就可能变化。比如老版本里素材路径字段叫source_path新版本可能改成嵌套在material里的path。如果你的 Skill 是按旧版写的升级后 Codex 会照着旧字段去改导致剪映打不开草稿。我的做法是跑批量任务期间绝对不升级剪映等这批任务全部交付后再统一升级并更新 Skill。最好把剪映安装包也留存一份这样团队里其他人复现环境时才不会踩版本差异的坑。第二个常见问题是修改完 JSON 后剪映提示“草稿不完整”或“无法打开”。我排查下来绝大多数情况是material_id引用了一个不存在的素材。剪映的草稿里每个素材都会有一个对应 ID时间线片段通过这个 ID 去引用素材。如果你只改了路径但忘了改 ID剪映就找不到这个素材。这种问题怎么排查打开草稿目录确认所有素材文件都还在原位置再看 JSON 里ids字段的前缀是否跟模板一致。这个前缀有点像版本指纹如果被 Codex 动了剪映就会认定草稿损坏。还有一个非常容易忽略的编码问题Windows 下用 PowerShell 重定向写文件时很容易把 UTF-8 文件写成 GBK导致剪映里中文字幕全部乱码。我的解决办法是让 Codex 用 Python 显式指定 UTF-8 编码写文件并且在 Skill 里写了这一条强制要求。4.3 Skill 编写与 Codex 行为相关关于 Skill 本身我踩过两次坑。第一次是 SKILL.md 内容太短。我一开始只写了一句“剪映草稿是 JSON 文件”结果 Codex 每次生成的东西都非常“想当然”缺字段、错字段频繁出现。后来我把字段速查表补全并且加入了一个最小可用草稿片段示例问题立刻减少。Codex 需要参考点你不能让它凭空理解一个复杂格式。第二次是 Codex 过度发挥。它有时会好心地给 JSON 补一个“看起来合理”的默认值比如给音频片段补一个volume: 1.0字段。虽然这在大多数情况下没问题但剪映对某些字段非常敏感新增字段会导致草稿被判定为高版本文件旧版剪映直接打不开。所以我在 SKILL.md 里增加了一条强硬规定“除非用户明确要求否则只修改模板中已有的字段不新增任何字段。”有了这一条Codex 就老实多了。4.4 渲染环节相关剪映导出的时候会占用草稿目录。如果你一边让剪映导出一边让 Codex 往同一个目录写新文件大概率出现文件锁冲突结果是导出失败或者写入了半个草稿。我的解决办法也是从坑里学来的脚本只操作工作目录里的草稿副本原模板永远不动。具体流程是先把母版目录复制到generated/id再由 Codex 修改这个副本最后让剪映打开副本导出。这样即使中途出问题也不会毁掉母版。FFmpeg 转码阶段也有一个坑CPU 软件编码太慢。遇到 4K 甚至 8K 素材转 1080P我用 CPU 跑一个片子要半小时后来加了硬件加速参数ffmpeg -hwaccel auto -i input.mp4 ...速度快了很多。但注意硬件编码器生成的文件在某些老播放器上可能不兼容交付前一定要抽几段出来实际播放验证不能光看文件大小和时长对了就发出去。4.5 常见问题速查表这里整理了一份我在实操中反复遇到问题的速查表方便你快速定位问题可能原因解决办法Codex 登录失败授权回调被网络中断切换稳定网络后重新codex login请求一直超时模型服务端波动查看日志稍后重试不一定是本地配置问题剪映提示草稿损坏material_id引用错误检查 JSON 里 ID 前缀确认素材原件没被移动字幕全部乱码文件被写成 GBK强制用 Python UTF-8 写文件剪映升级后打不开草稿草稿 JSON 字段结构变化批量任务期间不升级剪映升级后同步更新 SkillCodex 乱加字段SKILL.md 边界不够明确在 Skill 中写明“不新增字段只改已有值”导出时文件写入冲突剪映占用草稿目录脚本只改副本剪映导出用副本FFmpeg 编码太慢CPU 软件编码加-hwaccel auto启用硬件加速这张表我打印出来贴在显示器旁边遇到问题先扫一眼能省不少排查时间。5. 最后说点真心话我踩过几次坑之后的体会是全自动化的瓶颈从来不是工具而是流程想得不够清晰。Codex 负责动手Skill 负责让 Codex 不乱来CSV 负责把需求变成数据。三者理顺之后批量生产视频这件事并没有想象中那么玄。最后再分享一个小技巧每次让 Codex 批量执行前先让它输出一份 Dry Run 改动清单同时把整个 projects 目录备份一次。这个习惯看起来很保守但真的帮我省了大量时间因为批量生成最容易出的问题就是“某一条生成错了但你没发现”等发现的时候已经覆盖了原来的文件。有个备份随时能回滚心里就不慌。