最近经常看到一种现象有人让 Codex 帮忙做一条视频第一反应不是先写清楚需求而是先把网上搜到的“视频 Skill”“PPT Skill”“前端 Skill”“数学建模 Skill”全部装进~/.codex/skills总觉得装得越多 Codex 就越智能。结果真正跑起来才发现Codex 启动变慢、上下文被无关 Skill 占满、经常调错指令最后连一条最简单的字幕动画都没生成出来。先说结论Codex 做视频这件事核心不是“装了多少 Skill”而是“有没有把任务拆清楚、有没有给 Codex 正确的执行路径”。Skill 只是把常用经验封装成可复用指令帮助 Agent 减少试错但如果你装了一堆互相干扰的 Skill反而会稀释 Codex 的注意力。这篇文章会从 Codex Skill 的原理讲起带大家完成一个“不装任何视频 Skill 也能用 Codex 生成视频”的完整实战再教大家如何自己写一个真正有用的视频类 Skill最后整理常见报错排查思路。本文适合以下读者刚接触 Codex CLI 的初学者、被“Skill 收藏癖”困扰的开发者、想用 Codex 自动化生成视频素材或演示动画的人。文章中的代码都可以直接复制运行涉及模型接口配置的部分需要结合你本地的实际环境稍作调整。1. 为什么“Skill 装得越多Codex 不一定越强”1.1 Codex 做视频到底靠什么很多人对 Codex 做视频有误解以为它像 Sora 那样输入一句话就能吐出视频。实际上Codex 是一个编程智能体它擅长的是“读写代码、执行命令、操作文件”而不是“生成多模态视频画面”。所以用 Codex 做视频的合理路径通常是这样的你把视频需求描述给 Codex例如“生成 3 个字幕卡片每张卡片 1 秒合成一个 MP4”。Codex 根据需求编写 Python 脚本例如用 Pillow 逐帧绘制 PNG 图片。Codex 调用 FFmpeg 将图片序列合成为视频。人工审查脚本后运行最终得到视频文件。在这个过程中Codex 真正做的是“编排和编码”视频画面的本质是你提供的图像素材或者由代码生成的动画帧。理解了这一点你就会明白与其指望某个 Skill 让 Codex 突然会做视频不如把精力花在“如何把视频拆成代码可执行的步骤”上。1.2 Skill 的真实作用Skill 可以简单理解为一组“预置指令包”。在 Codex 这类 Agent 工具中一个 Skill 通常是一个包含SKILL.md的目录文件里写了这个 Skill 的名字、用途、使用步骤、示例代码。当 Codex 判断当前任务和某个 Skill 匹配时它会读取这个 Skill 的内容从而按照更规范的思路去执行。它的价值在于“复用经验和约束行为”。比如你写了一个“视频分镜 Skill”里面包含了如何把一段文案拆成镜头每个镜头应该输出哪些字段如何生成图片帧如何用 FFmpeg 合成视频。那么以后你再让 Codex 做类似视频时它就不需要从头摸索直接照着 Skill 里的流程执行。这才是 Skill 的正确用法把重复劳动标准化而不是把一堆名字好听的东西堆进目录里。1.3 装太多 Skill 的三个副作用很多同学看到 Skill 就装主要原因是“名字看起来有用”。但在实际项目中无脑安装 Skill 会带来三个很现实的问题第一上下文膨胀。Codex 在处理任务时需要读取可能相关的 Skill 描述。如果 Skills 目录里有几十个无关 SkillAgent 需要花费额外的时间去筛选甚至可能读取了大量不相关的内容导致核心任务可用的上下文减少。第二指令冲突。不同的 Skill 可能对同类任务给出不同的处理方式。比如一个 Skill 说“视频输出用 1920x1080”另一个 Skill 说“视频输出用 1080x1920”Codex 在加载多个 Skill 后可能产生矛盾行为最后生成结果完全不符合预期。第三维护成本上升。Skill 也会过时也会和当前 Codex 版本不兼容。装得越多意味着你需要维护和排查的变量越多。一旦 Codex 出错你很难判断是模型问题、配置问题还是某个 Skill 里的错误指令导致的。所以“装的多≠装的对”更准确的说法是每个 Skill 都应该对应一类高频、稳定、可复用的任务如果一个 Skill 你半年都用不上一次那它就只是在消耗上下文。2. 环境准备先让 Codex 跑起来在开始做视频之前先确保你的 Codex 环境是通的。这里不展开安装细节但会给出最常见的配置项和几个容易踩坑的点。2.1 安装 Codex CLICodex CLI 目前主要通过 npm 安装命令如下npm install -g openai/codex安装完成后检查版本codex --version如果你的电脑没有 Node.js 环境需要先安装 Node.js 18 或更高版本。Windows 用户建议在 WSL2 或 Git Bash 中使用 Codex因为很多 Skill 示例脚本和 FFmpeg 命令在 Linux 环境更顺畅。具体的安装方式以官方文档为准这里重点是确认codex命令可以被正常调用。2.2 配置模型接入以 DeepSeek 为例Codex 默认使用 OpenAI 官方模型但如果你希望接入其他兼容 OpenAI 接口的模型比如 DeepSeek可以通过配置文件指定model_provider和base_url。配置文件通常位于~/.codex/config.toml不同版本可能有差异建议先查看官方文档确认路径。一个常见的 DeepSeek 接入配置示例如下model deepseek-chat model_provider deepseek [model_providers.deepseek] name DeepSeek base_url https://api.deepseek.com/v1 env_key DEEPSEEK_API_KEY配置完成后需要设置环境变量DEEPSEEK_API_KEY或者在 shell 配置中写入export DEEPSEEK_API_KEY你的 API Key需要注意几点不是所有模型都支持 Codex 使用的/responses接口部分模型只能用/chat/completions这会导致model is not supported或 endpoint 相关报错。base_url是否正确、API Key 是否有权限都会直接影响 Codex 能否工作。如果你的模型供应商是兼容接口一般可以直接使用openai协议如果不能确定先用一个最简单的codex 写一个 hello world 脚本测试连通性。2.3 用 cc switch 管理多套配置当你在本机同时使用官方模型、DeepSeek、本地模型等多套配置时手动改config.toml非常容易出错。这时候可以使用社区常见的配置切换工具比如 cc switch。它的本质是帮你管理多份不同 provider 的配置通过界面或命令行一键切换。在使用这类工具时有一个高频报错值得注意cc switch local proxy failed while handling codex endpoint /responses. provi...这个报错通常表示当前配置的base_url指向了本机某个服务但该服务并没有启动或者该服务不支持 Codex 请求的/responses端点。排查思路很简单查看当前 provider 的base_url是否指向本机端口例如http://localhost:8080。确认这个本地服务是否已经启动端口是否被占用。确认该服务是否支持POST /responses接口以及是否需要在请求头中加入鉴权信息。不要一看到“proxy”就想到别的地方这里的local proxy通常只是本地网关或转发服务的约定叫法不是系统级网络代理。出现这个报错时优先检查本地服务状态和配置地址即可。3. Skill 机制拆解目录、SKILL.md 与加载逻辑3.1 Skill 的标准目录结构在 Codex 和许多 Agent 工具中Skill 的组织方式非常相似。一个规范的标准结构通常是~/.codex/skills/ └── video-storyboard/ ├── SKILL.md ├── scripts/ │ └── generate_frames.py └── assets/ └── example_font.ttf其中SKILL.md是这个 Skill 的入口描述文件scripts/存放可复用的脚本assets/存放资源文件。Codex 通过扫描 Skills 目录来发现可用 Skill所以只要目录存在且SKILL.md格式正确Codex 就能识别。3.2 SKILL.md 的核心写法SKILL.md的作用是让 Codex 快速判断“何时使用这个 Skill”以及“使用这个 Skill 后应该怎么做”。它通常包含以下几个部分nameSkill 名称必须唯一。description一句话说明这个 Skill 解决什么问题最好包含具体关键词方便 Codex 做匹配。instructions告诉 Codex 执行这个 Skill 时应该按什么步骤走。examples给出典型输入和输出帮助 Codex 理解预期结果。一个最小可用的SKILL.md示例如下--- name: video-storyboard description: 生成视频分镜脚本和渲染建议适合短视频、演示动画和教程视频。 --- # video-storyboard ## 适用场景 - 用户需要把一段文案变成视频分镜 - 用户需要生成逐镜头的画面、字幕、时长建议 - 用户需要把图片帧合成为 MP4 文件。 ## 处理流程 1. 把用户需求拆成 3 到 5 个镜头。 2. 每个镜头输出四要素画面描述、字幕文案、预计时长、转场方式。 3. 用 Python Pillow 生成逐帧 PNG 图片。 4. 用 FFmpeg 把 PNG 序列合成为 MP4。 5. 检查输出文件提示用户查看结果。这里要提醒一点不同版本的 Codex 对 Skill 元数据的要求可能不同。有的版本要求description必须足够精准否则 Codex 不会自动加载有的版本更倾向于通过AGENTS.md或项目目录中的说明文件来发现 Skill。所以建议你在写 Skill 时既保留标准的name description instructions结构也要在项目目录维护一份AGENTS.md把关键信息再写一遍。3.3 Skill 什么时候会被加载Codex 并不会把所有 Skill 一次性加载进上下文而是根据任务描述去“猜测”哪些 Skill 可能相关。这个匹配过程依赖两个因素一是description的丰富程度。如果你的description只写“视频脚本”Codex 很难判断它和“制作一个 3 秒的演示动画”是否相关。更推荐写成“根据用户主题生成视频分镜包含画面描述、字幕文案、图片帧生成脚本和 FFmpeg 合成命令”。二是当前任务上下文。用户输入的需求越具体Codex 越容易匹配到正确的 Skill。如果你只说“帮我做个视频”Codex 可能连该调用哪个 Skill 都拿不准更不用说后续的规格参数了。这也是为什么“装一堆 Skill”反而无效Codex 需要对大量 Skill 做相关性判断一旦判断错误就会加载错误 Skill输出与你预期完全不同的结果。4. 实战不装任何视频 Skill用 Codex 做一条动态字幕视频下面进入核心实战。这一步我们故意不安装任何第三方视频 Skill只依靠“清晰的任务描述 常规 Python 脚本 FFmpeg”让 Codex 帮我们生成一条简单的动态字幕视频。这样做是为了证明做视频的关键是任务拆解而不是 Skill 数量。4.1 任务描述怎么写在 Codex CLI 中执行codex 请帮我写一个 Python 脚本用 Pillow 生成 3 张 1280x720 的图片帧每张图片背景色使用深蓝色中央显示一行标题文字下方显示一行副标题。标题和副标题分别为Codex 生成视频 / 第一步先拆解任务不装一堆 Skill / 第二步按需安装一个脚本搞定 / 第三步渲染成片。然后将这些图片帧用 FFmpeg 合成为一个 MP4 视频输出到 output.mp4。这段话虽然长但它把关键信息都交代清楚了技术栈Python Pillow FFmpeg图片规格1280x720图片内容每帧的标题和副标题输出格式MP4输出文件output.mp4。Codex 会把这个需求理解为一个“脚本编排任务”然后逐项生成代码。4.2 让 Codex 生成“帧绘制脚本”如果 Codex 没有一次性把脚本写完整或者你希望手动保留脚本下面是一个可以直接使用的帧绘制脚本保存为generate_frames.py# 文件路径./generate_frames.py from PIL import Image, ImageDraw, ImageFont import os os.makedirs(frames, exist_okTrue) width, height 1280, 720 # 中文字体路径需要根据系统实际情况修改 font_path /usr/share/fonts/opentype/noto/NotoSansCJK-Regular.ttc font_title ImageFont.truetype(font_path, 72) font_sub ImageFont.truetype(font_path, 36) frames [ (Codex 生成视频, 第一步先拆解任务), (不装一堆 Skill, 第二步按需安装), (一个脚本搞定, 第三步渲染成片), ] for i, (title, subtitle) in enumerate(frames): img Image.new(RGB, (width, height), #0f172a) draw ImageDraw.Draw(img) # 中央分割线 draw.rectangle([0, height // 2 - 2, width, height // 2 2], fill#38bdf8) # 标题居中 title_width draw.textlength(title, fontfont_title) draw.text( ((width - title_width) / 2, height // 2 - 140), title, fill#ffffff, fontfont_title, ) # 副标题居中 sub_width draw.textlength(subtitle, fontfont_sub) draw.text( ((width - sub_width) / 2, height // 2 60), subtitle, fill#94a3b8, fontfont_sub, ) frame_path fframes/frame_{i 1:04d}.png img.save(frame_path) print(fgenerated {frame_path})脚本里核心是三个步骤创建画布指定分辨率和背景色写入文字使用textlength计算文字宽度保证文字水平居中保存为 PNG 文件文件名按序号排列。如果你本机没有NotoSansCJK-Regular.ttc字体文件可以换成其他中文字体路径例如 Windows 下的C:/Windows/Fonts/msyh.ttc或者 macOS 下的/System/Library/Fonts/PingFang.ttc。如果字体路径不对图片上的中文会变成方框。4.3 用 FFmpeg 合成视频图片帧生成后用 FFmpeg 把 PNG 序列合成 MP4ffmpeg -framerate 1 -i frames/frame_%04d.png -c:v libx264 -pix_fmt yuv420p output.mp4解释一下参数含义-framerate 1每秒显示 1 帧总共 3 帧所以视频时长约为 3 秒-i frames/frame_%04d.png输入文件名的通配规则%04d表示 4 位数字序号-c:v libx264视频编码器使用 H.264兼容性较好-pix_fmt yuv420p使用 YUV 420 像素格式很多播放器对小尺寸视频更友好。如果你想生成更流畅的视频可以先把每个画面重复多帧或者使用更高帧率。一个简单的做法是修改脚本让每张图片保存多次例如frame_0001.png到frame_0002.png内容相同重复 24 次后再切到下一张然后用-framerate 24合成就能得到接近 1 秒一画面的流畅视频。4.4 运行与验证先安装依赖pip install Pillow如果系统没有 FFmpeg需要先安装。Ubuntu/Debian 可以使用sudo apt update sudo apt install ffmpeg然后按顺序执行python generate_frames.py ffmpeg -framerate 1 -i frames/frame_%04d.png -c:v libx264 -pix_fmt yuv420p output.mp4执行成功后你会看到类似下面的输出generated frames/frame_0001.png generated frames/frame_0002.png generated frames/frame_0003.png接着 FFmpeg 会输出编码进度最终在当前目录生成output.mp4。用播放器打开后应该能看到 3 张带有标题和副标题的深蓝色画面依次播放。4.5 如果想让 Codex 生成字幕或配音如果你希望视频里带字幕文件可以继续让 Codex 生成一个.srt字幕文件再用 FFmpeg 合成字幕。最简单的方式是让 Codex 帮你把文案整理成 SRT 格式然后用下面的命令烧录字幕ffmpeg -i output.mp4 -vf subtitlessubtitle.srt output_with_sub.mp4需要注意的是烧录字幕前要保证subtitle.srt的编码是 UTF-8且字体支持中文否则字幕容易出现乱码。如果后续你希望加入配音可以让 Codex 调用本机的 TTS 工具或系统语音引擎先生成音频再通过 FFmpeg 把音频和视频合并。这一步依赖具体系统环境示例思路是先生成音频文件audio.mp3然后执行ffmpeg -i output.mp4 -i audio.mp3 -c:v copy -c:a aac -shortest final.mp4到这里你已经用 Codex 的编程能力完成了一条最简单的视频制作闭环。整个过程没有安装任何第三方“视频 Skill”靠的是清晰任务描述和标准工具链。5. 进阶自己写一个“视频草稿”Skill既然装一堆 Skill 不如少而精那最靠谱的方式是什么答案是针对你真正高频使用的任务自己写一个 Skill。下面以“视频草稿”为例教大家如何写一个可复用的视频类 Skill。5.1 Skill 目录设计先创建目录结构mkdir -p ~/.codex/skills/video-storyboard/scripts然后创建SKILL.md写入前面提到的内容。再将刚才的generate_frames.py放进scripts/目录作为示例脚本。5.2 SKILL.md 示例video-storyboard--- name: video-storyboard description: 根据用户主题生成视频分镜脚本、逐帧图片生成脚本和 FFmpeg 合成命令适合短视频、演示动画和教程视频。 --- # video-storyboard ## 适用场景 - 用户需要把一句主题扩展为 3 到 5 个视频镜头 - 用户需要画面描述、字幕文案、时长建议 - 用户需要把文字诉求转成可执行的 Python 脚本和 FFmpeg 命令。 ## 使用步骤 1. 把用户主题拆成 3 到 5 个镜头。 2. 每个镜头输出四要素画面描述、字幕文案、预计时长、转场方式。 3. 推荐使用 Pillow 生成 1280x720 的 PNG 图片帧。 4. 推荐使用 FFmpeg 合成 MP4。 5. 输出命令时确保包含字体路径、分辨率和编码参数。 ## 示例 - 输入制作一条 3 秒的 Codex 宣传视频 - 输出分镜表 generate_frames.py ffmpeg 合成命令这个 Skill 并不复杂但它的价值在于每次 Codex 遇到“做视频/短视频/演示动画”这类需求时都能按照统一流程走不会再出现“写一堆不相关的代码”的情况。5.3 安装与测试保存好文件后在任意目录启动 Codex输入codex 做一条 3 秒的 Codex 宣传视频主题是Codex 让编码更高效如果 Codex 正确加载了 Skill它会优先按照video-storyboard的流程先给出分镜表再给出生成脚本和 FFmpeg 命令。如果 Codex 没有使用这个 Skill说明description与任务匹配度不够或者当前 Codex 版本对 Skill 自动加载的支持有限。此时可以主动在提示词中补充一句请参考 video-storyboard 这个 Skill 来处理。这样就能手动指定 Skill。5.4 为什么自写 Skill 比“全装”更靠谱自写 Skill 最大的优势是“高度贴合自己的实际需求”。网上的 Skill 很多是通用模板不一定符合你的项目结构、字体环境或输出格式。而你在自写 Skill 的过程中会主动梳理流程、整理示例、修正坑点这些知识本身就是最有价值的沉淀。另外自己维护的 Skill 数量通常不会太多因为你是根据真实高频任务创建的。这种“少而精”的 Skill 集合Codex 加载时匹配更准确出错的概率也更低。6. 常见问题与排查思路在用 Codex 做视频、安装 Skill、配置模型接入的过程中经常会遇到几类问题。下面统一整理成表格方便快速定位。问题现象常见原因解决思路model is not supported当前模型不支持 Codex 使用的接口协议或模型名称错误检查配置文件中的model和model_provider确认模型和接口兼容性cc switch local proxy failed while handling codex endpoint /responsesprovider 的base_url指向的本地服务未启动或服务不支持该端点检查本地服务端口是否启动确认 base_url 和鉴权头配置正确Codex 装入 Skill 后不生效SKILL.md路径错误、元数据格式不正确或 description 与任务不匹配检查 Skills 目录结构、frontmatter格式或手动指定 Skill 名称图片上的中文变成方框字体文件不存在或字体路径错误换成系统中实际存在的中文字体路径FFmpeg 找不到输入文件图片帧命名不规范或路径不对确认文件名是否符合frame_%04d.png规则检查当前工作目录API Key 相关报错环境变量未设置或者 Key 权限不足在 shell 中 export 对应的env_key重启终端后重试Pillow 中textlength报错Pillow 版本过低升级 Pillowpip install --upgrade Pillow如果你遇到“Codex 响应速度变慢”或“任务方向跑偏”优先排查是否因为 Skills 目录下积累了过多无关 Skill。可以先临时把 Skills 目录改名再重试看问题是否解决。mv ~/.codex/skills ~/.codex/skills_backup如果改名后 Codex 恢复正常说明确实是 Skill 数量或内容干扰了任务执行。这时候再逐个恢复 Skill保留真正需要的。7. 最佳实践Skill 的“少而精”管理法则7.1 按任务类型选 Skill建议每个 Skill 只负责“一类任务”不要把多个用途塞进同一个 Skill。比如视频分镜 Skill只处理分镜、字幕和渲染。代码审查 Skill只处理代码评审规范。数据库 SQL Skill只处理 SQL 生成与优化。这样 Codex 在匹配时更容易找到正确目标不会因为描述太宽泛而误加载。7.2 给 Skill 写清晰元信息description不是给你自己看的而是给 Agent 匹配用的。写描述时建议包含任务对象、动作、输出格式、典型场景。例如description: 生成视频分镜脚本、图片帧生成脚本和 FFmpeg 合成命令适合短视频、演示动画、教程视频制作。避免写得太宽泛例如“视频相关”否则 Codex 很难判断具体怎么用。7.3 控制上下文与权限Skill 的脚本里如果涉及执行命令一定要把脚本限制在当前项目目录内不要随意修改系统级文件。Codex 在执行脚本时仍然需要人工确认关键命令尤其是ffmpeg、rm、mv这类可能影响文件系统的操作。建议遵循最小权限原则只给 Codex 访问当前工作目录的必要权限不要把 API Key 写进 Skill 示例文件中。7.4 版本管理与备份随着 Codex 版本迭代Skill 格式和加载逻辑可能变化。建议把 Skills 目录纳入 Git 管理cd ~/.codex/skills git init git add . git commit -m init skills这样每次修改 Skill 都有记录出问题可以随时回滚。同时在升级 Codex CLI 前先确认官方文档中关于 Skill 的变更说明避免旧格式 Skill 失效。7.5 对“热门 Skill”保持谨慎网络上有不少“热门 Skill 合集”但热门不等于适合你。一个 Skill 是否值得安装可以问自己三个问题这个任务我是否每周都会遇到这个 Skill 的指令是否符合我的项目规范和工具链如果 Codex 没有这个 Skill我做这个任务需要多花多少时间如果三个问题的答案都是否定的那这个 Skill 大概率不值得装。真正决定 Codex 生产力的始终是“需求拆解能力 清晰的配置 可复用的高质量脚本”。8. 总结与动手建议这篇文章的核心观点很简单用 Codex 做视频不一定要依赖一堆第三方 Skill。Skill 的本质是经验封装真正让任务跑通的是你能否把需求拆成 Agent 可执行的步骤。我们一起做了这样几件事理解了 Codex 做视频的真实路径用代码生成画面帧再用 FFmpeg 合成视频搭建了 Codex CLI 环境并给出接入 DeepSeek 等 OpenAI 兼容模型的配置示例分析了 Skill 的目录结构和加载逻辑解释了为什么“全装”反而低效完成了一个不装任何视频 Skill 的实战案例用 Pillow FFmpeg 生成动态字幕视频学会自己编写一个video-storyboardSkill把高频任务标准化整理了常见报错和排查清单覆盖模型不支持、本地服务连接失败、中文乱码等问题。接下来你可以继续做两件事一是完善自己项目里的AGENTS.md和 Skills 目录把真实高频的任务沉淀成 Skill二是尝试让 Codex 组合更复杂的工具链比如生成 SRT 字幕、调用本机 TTS 合成语音、用 FFmpeg 完成转场特效。每做一步你都会更清楚什么 Skill 值得装什么任务根本不需要 Skill。环境差异和版本差异是绕不开的安装 Skill 或修改配置后最好先用一个最小示例验证链路是否正常。多动手跑几个脚本比收藏几页“必装 Skill 清单”有用得多。