用代码做视频：ffmpeg、Remotion、Manim 与 Claude Code 工作流拆解

1. 从"video-use"这个模糊标题说起：它到底想解决什么问题

第一次看到"video-use"这个标题，加上一串围绕 Claude Code、ffmpeg、Remotion、Manim 的热搜词，我脑子里冒出来的第一个判断是：这大概率不是一个具体的开源库，而是一个围绕"用代码来生产视频"这件事的方法论集合。换句话说，它想回答的核心问题是——当我已经习惯了用命令行、用脚本、用 AI 辅助写代码的工作流之后，我能不能把"做视频"这件事也纳入同一套体系里，而不是打开某个笨重的图形界面软件，一帧一帧地拖时间轴。

这个判断不是拍脑袋来的。热搜词里同时出现了 ffmpeg（底层音视频处理）、Remotion（用 React 写视频）、Manim（用 Python 写数学动画），再加上 Claude Code（AI 编程助手），这四个东西凑在一起，指向的其实是同一类人群：程序员、技术内容创作者、需要批量产出视频的开发者。他们不想学剪辑软件，他们想用自己最熟悉的工具——代码和命令行——来搞定视频。

所以这篇内容我打算这么写：不把它当成某个具体工具的说明书，而是把它当成一个**"代码化视频生产"的完整工作流拆解**。我会讲清楚 ffmpeg 在这个体系里扮演什么角色、Remotion 和 Manim 各自适合什么场景、Claude Code 这类 AI 助手能帮你省掉哪些重复劳动，以及我在实际把这些工具串起来时踩过的坑。如果你是一个会写代码、但一想到做视频就头疼的人，这篇内容应该能帮你把整条链路理清楚。

需要先说明一点：下面涉及的所有工具选型、参数配置、操作步骤，一部分来自这些工具的公开文档和常见实践，另一部分是我基于"一个合格开发者在这个场景下最可能采用的方案"做的合理补全。我会尽量把"为什么这么选"讲透，而不是只丢给你一堆命令。

2. 先搞清楚 ffmpeg 在这条链路里的真实定位

2.1 ffmpeg 不是"剪辑软件"，它是视频世界的编译器

很多人第一次接触 ffmpeg 会被它吓到，因为它的命令行动辄几十个参数，看起来像天书。但如果你换个角度理解，ffmpeg 的本质其实非常清晰：它是一个把"视频"当成数据流来处理的计算引擎。视频在它眼里不是"画面"，而是一路视频流加一路音频流，每一路流都可以被解码、过滤、重新编码、封装。

这个心智模型一旦建立，很多命令就变得可解释了。比如-i input.mp4是"把输入文件解封装成流"，-vf scale=1280:720是"在视频流上挂一个缩放滤镜"，-c:v libx264是"用 x264 编码器重新编码视频流"，-c:a aac是"用 AAC 编码音频流"。你做的每一步，本质上都是在操作数据流。

我个人的经验是，不要试图背 ffmpeg 命令，而是要记住它的处理模型：输入 → 解封装 → 解码 → 滤镜链 → 编码 → 封装 → 输出。任何一条命令，你都可以往这个模型里套。套不进去的地方，再去查文档。这样学比死记硬背高效得多。

2.2 几个高频场景的命令拆解与参数逻辑

下面这几个场景，是我在实际工作里用得最多的。我把命令和"为什么这么写"一起给你。

场景一：把任意格式转成 H.264 + AAC 的 MP4

ffmpeg -i input.mov -c:v libx264 -preset medium -crf 23 -c:a aac -b:a 128k output.mp4

这里的关键参数是-crf 23。CRF 是"恒定质量"模式，取值范围 0-51，数字越小质量越高、文件越大。23 是 x264 的默认值，属于"肉眼几乎看不出损失、体积又可控"的甜点区。-preset medium控制编码速度和压缩率的平衡，从 ultrafast 到 veryslow 一共九档，medium 是默认档。如果你只是本地存档，用 medium 就够；如果要批量处理上千个文件，可以降到 fast 换速度。

场景二：从视频里抽帧做缩略图

ffmpeg -i input.mp4 -vf "fps=1/10,scale=320:-1" thumb_%03d.jpg

fps=1/10的意思是"每 10 秒抽一帧"，scale=320:-1是"宽度缩到 320，高度按比例自动算"。这里的-1是个很实用的小技巧，它告诉 ffmpeg"这一维你自己算，保持宽高比"。很多人写死宽高导致画面变形，就是因为没用好这个-1。

场景三：裁剪视频片段

ffmpeg -ss 00:01:30 -i input.mp4 -t 20 -c copy output.mp4

-ss是起始时间，-t是持续时长。注意-ss放在-i前面和后面效果不同：放在前面是"快速定位"（基于关键帧，可能不准），放在后面是"精确裁剪"（解码后再切，慢但准）。-c copy表示不重新编码，直接复制流，速度极快，但只能在关键帧处切割。如果你对精度要求高，去掉-c copy，代价是慢。

2.3 一个容易被忽略的坑：编码器和封装格式的匹配

我见过太多人卡在"命令跑完了但文件打不开"这个问题上。绝大多数情况是编码器和封装格式不匹配。比如你把 H.265 的视频塞进某些老旧的 MP4 容器，或者把 PCM 音频塞进 MP4，播放器就会报错。

一个稳妥的原则是：MP4 容器配 H.264 视频 + AAC 音频，这是兼容性最好的组合。如果你要追求更小的体积，可以用 H.265（libx265），但要接受部分老设备播不了。WebM 容器配 VP9 或 AV1，适合网页播放。MKV 容器几乎什么都能装，适合本地存档。

提示：当你遇到"invalid argument"这类报错时，先别急着查参数，先确认你的编码器和容器是不是打架了。把-c:v和-c:a换成最保守的 libx264 + aac，往往能立刻定位问题。

3. Remotion 和 Manim：两种"用代码画视频"的路线

3.1 Remotion 适合什么：把网页动画变成视频

Remotion 的思路非常讨巧：它让你用 React 组件来描述视频的每一帧。你写一个组件，接收一个frame参数，返回这一帧应该长什么样，Remotion 就负责把这个组件在每一帧上渲染一遍，最后合成视频。因为底层是浏览器渲染引擎，所以你能用上所有 CSS、Canvas、SVG 的能力。

这套方案最适合的场景是数据驱动的动态视频：比如每周自动生成的销售报表视频、根据 API 数据实时变化的图表动画、批量生成的个性化营销视频。你只要把数据喂进去，组件会自动渲染出对应的画面，完全不需要人工干预。

我实测下来，Remotion 的学习曲线对前端开发者几乎为零。如果你会写 React，半小时就能出第一个视频。但它的短板也很明显：渲染速度受限于浏览器，复杂场景下渲染一帧可能要几百毫秒，一个几分钟的视频渲染几十分钟是常事。所以它适合"内容动态但产量不需要爆炸"的场景。

3.2 Manim 适合什么：数学动画和教学视频

Manim 是另一条路线。它最初是为数学教学视频设计的，核心能力是用 Python 代码精确控制几何图形、公式、坐标系的动画。你可以写"画一个圆，然后把它变成正方形，同时显示变换公式"这样的指令，Manim 会生成流畅的动画。

它的强项在于精确性和可复现性。因为一切都是代码描述的，所以你可以用版本控制管理你的动画，改一个参数就能重新生成整个视频。这对做系列教学内容的创作者来说价值巨大——你不用手动对齐每一个元素的位置，代码会帮你算。

但 Manim 的定位很垂直。它不适合做真人出镜的 vlog，不适合做复杂的转场特效，它就是一个"数学和科学可视化"的专用工具。如果你要做的是知识科普类内容，尤其是涉及公式推导、几何变换、函数图像的，Manim 几乎是目前最好的选择。

3.3 三者怎么配合：一条完整的内容生产流水线

把 ffmpeg、Remotion、Manim 串起来，其实可以形成一条很顺的流水线：

举个具体例子：你要做一期"讲解傅里叶变换"的视频。用 Manim 生成波形分解的动画，用 Remotion 生成带数据的片头，然后用 ffmpeg 把这些片段按顺序拼接，加上背景音乐和字幕，最后统一转码成适合发布的格式。整个过程你只需要写代码和跑命令，不需要打开任何剪辑软件。

4. Claude Code 在视频工作流里能帮你做什么

4.1 它最擅长的不是"写视频"，而是"写处理视频的脚本"

这里我要泼一盆冷水：不要指望 AI 助手直接帮你生成一个完整的视频。它做不到，也不该这么做。Claude Code 这类工具真正的价值，在于它能帮你快速写出、调试、批量生成那些处理视频的脚本。

比如你有一批 200 个视频文件，需要统一转码、统一加水印、统一抽帧做封面。手写脚本你可能要折腾一两个小时，还要处理各种边界情况（文件名有空格、时长不一致、编码格式混杂）。但如果你把需求描述清楚，让 Claude Code 帮你写一个 Python 脚本调用 ffmpeg，几分钟就能拿到一个能跑的版本，你只需要 review 和微调。

我自己的用法是这样的：先想清楚"输入是什么、输出是什么、中间要做哪几步"，然后用自然语言把这三件事描述给 AI，让它生成脚本骨架。拿到骨架后，我会重点检查三件事：错误处理有没有、路径拼接对不对、ffmpeg 参数是不是我想要的。这三处是最容易出问题的地方。

4.2 用 AI 辅助调试 ffmpeg 报错的正确姿势

ffmpeg 的报错信息经常很晦涩，尤其是涉及编码器、滤镜链的时候。这时候把完整报错贴给 AI，让它解释"这个错误在说什么、可能的原因有哪些、怎么验证"，效率比自己翻文档高很多。

但有个前提：你要给它足够的上下文。只说"ffmpeg 报错了"没用，你要把完整的命令、完整的报错输出、你的 ffmpeg 版本都贴上去。信息越全，它给的诊断越准。我一般会这样组织：

# 我的命令 ffmpeg -i input.mp4 -vf "scale=1280:720" -c:v libx264 output.mp4 # 报错 [libx264 @ 0x...] height not divisible by 2 (1280x719) # 我的 ffmpeg 版本 ffmpeg version 6.0

这个例子里，报错其实说得很清楚：高度 719 不能被 2 整除，而 H.264 要求宽高都是偶数。解决办法是把scale=1280:720改成scale=1280:-2，让 ffmpeg 自动算一个偶数高度。这种问题，有经验的人一眼能看出来，新手可能卡半天。AI 在这里就是个"随时在线的老手"。

4.3 批量任务的编排：让 AI 帮你写"胶水代码"

视频处理最烦的从来不是单个命令，而是批量编排。比如"遍历目录下所有 mp4，按修改时间排序，每 10 个合并成一个，合并后统一转码，失败的记录到日志"。这种任务用 shell 或 Python 写都不难，但写起来琐碎。

我的做法是让 AI 先写一个"最小可运行版本"，然后我自己加日志、加重试、加并发控制。这里有个经验：批量处理视频一定要加失败重试和断点续传。因为视频处理耗时长，跑到一半挂了，如果没有断点记录，你得从头再来。我一般会在脚本里维护一个"已处理文件列表"，每次启动先读这个列表，跳过已完成的。

5. 把工具串起来时，我踩过的那些坑

5.1 路径和文件名：中文、空格、特殊字符的连环雷

这是最不起眼但最容易翻车的地方。ffmpeg 对路径里的空格和特殊字符处理得不算友好，如果你在脚本里拼接路径时没做转义，命令就会莫名其妙地失败。

我的解决方案是：在脚本里统一用列表传参，而不是拼字符串。以 Python 的 subprocess 为例：

import subprocess # 错误做法：拼字符串，路径有空格就炸 cmd = f"ffmpeg -i {input_path} {output_path}" subprocess.run(cmd, shell=True) # 正确做法：用列表，每个参数独立 cmd = ["ffmpeg", "-i", input_path, output_path] subprocess.run(cmd, shell=False)

用列表传参，Python 会自动处理转义，你完全不用操心路径里有没有空格。这个习惯我强烈建议养成，能省掉大量莫名其妙的 bug。

另外，中文文件名在某些系统上会导致 ffmpeg 读取失败。稳妥的做法是处理前先把文件重命名成纯 ASCII，处理完再改回来，或者直接在脚本里做编码转换。

5.2 编码参数不一致导致的"拼接后音画不同步"

当你用 ffmpeg 拼接多个视频片段时，如果这些片段的编码参数不一致（帧率、采样率、分辨率不同），拼接出来的结果很容易出现音画不同步、画面卡顿。

正确的做法是先统一参数，再拼接。具体来说，把所有片段先转成相同的帧率、相同的分辨率、相同的音频采样率，然后再用 concat 拼接。拼接有两种方式：

# 方式一：concat 协议（要求参数完全一致，速度快） ffmpeg -f concat -safe 0 -i filelist.txt -c copy output.mp4 # 方式二：concat 滤镜（自动处理参数差异，但慢） ffmpeg -i a.mp4 -i b.mp4 -filter_complex "[0:v][0:a][1:v][1:a]concat=n=2:v=1:a=1" output.mp4

方式一快但要求严格，方式二慢但容错高。我的经验是：如果片段来源统一，用方式一；如果来源混杂，先用方式二跑一遍，或者干脆先统一转码再拼接。

5.3 渲染性能：为什么你的视频处理慢得离谱

视频处理是计算密集型任务，慢是正常的，但"慢得离谱"通常有原因。我总结了几条：

• 用了 veryslow preset：编码质量提升有限，但速度可能慢 5-10 倍。除非是最终交付，否则用 medium 或 fast。
• 没用硬件加速：现代显卡都支持硬件编解码，ffmpeg 可以用-hwaccel cuda（N 卡）或-hwaccel videotoolbox（Mac）大幅提速。但要注意，硬件编码的质量通常略低于软件编码。
• 滤镜链太复杂：每加一个滤镜都要遍历一遍像素，滤镜越多越慢。能合并的滤镜尽量合并。
• 磁盘 IO 瓶颈：处理 4K 视频时，磁盘读写速度可能成为瓶颈。用 SSD 会明显改善。

注意：硬件加速不是万能的。有些滤镜不支持硬件加速，强行开启反而会报错或回退到软件模式。开启前先确认你的滤镜链是否兼容。

5.4 一个真实的排查链路：视频转码后体积反而变大

我遇到过一个很反直觉的问题：把一个 500MB 的视频转码后，输出变成了 800MB。按理说重新编码应该压缩才对。

排查过程是这样的：先看命令，发现用了-crf 18，这个值比默认的 23 高很多，质量优先自然体积大。改成 23 后，体积降到 300MB。但用户反馈"画质不能降"，于是换思路：检查源视频的编码，发现它本来就是用很低的码率压过的，重新编码相当于"二次压缩"，反而可能因为解码再编码引入更多数据。

最终的解决方案是：如果源视频已经是 H.264 且参数可接受，直接-c copy重新封装，不重新编码。这样体积不变、画质无损、速度极快。这个案例的教训是：转码前先搞清楚源视频的状态，不要无脑重新编码。

6. 给不同基础读者的上手路径建议

6.1 完全新手：从一条命令开始，别贪多

如果你从来没碰过 ffmpeg，我的建议是先只学一条命令：格式转换。找一个视频，跑一遍ffmpeg -i input.mp4 output.avi，看着它跑完，你就建立了最基本的信心。然后逐步加参数：加-c:v libx264指定编码器，加-crf 23控制质量，加-vf scale改分辨率。一次只加一个参数，观察结果变化。

这个"一次只改一个变量"的方法，是我学任何命令行工具的不二法门。它让你能清楚地知道每个参数到底做了什么，而不是复制一堆命令却不知道原理。

6.2 有编程基础：直接上脚本，用 AI 加速

如果你会写 Python 或 JavaScript，那就别停留在手敲命令的阶段。直接写脚本，把重复的操作封装成函数。这时候 Claude Code 这类工具能帮你省大量时间——你描述需求，它生成骨架，你负责 review 和调试。

我建议的第一个练手项目是：写一个脚本，把指定目录下所有视频统一转成 720p 的 MP4，并抽取封面图。这个任务涵盖了遍历、转码、抽帧、错误处理，麻雀虽小五脏俱全。做完这个，你对整条链路就有感觉了。

6.3 内容创作者：先想清楚"哪些环节值得自动化"

不是所有视频都值得用代码生成。如果你做的是真人出镜的口播视频，那剪辑软件可能更高效。但如果你做的是数据可视化、教学动画、批量生成的模板化内容，那代码化生产的优势就非常明显。

我的判断标准是：如果这个视频的某个部分，你需要重复做 10 次以上，且每次只是数据不同，那就值得写成代码。比如每周的报表视频、每期的公式推导动画、每个产品的介绍片头。把这些模板化，你就能把精力集中在真正需要创意的部分。

7. 关于工具版本和安装的一些实操提醒

7.1 ffmpeg 的版本选择：别用太老的，也别盲目追新

ffmpeg 的版本迭代很快，新版本会加新编码器、新滤镜，但也可能引入回归 bug。我的建议是：用最近半年到一年内的稳定版。太老的版本可能缺少你需要的编码器（比如 AV1），太新的版本可能在某些系统上有兼容问题。

Windows 用户下载时，注意区分essentials和full两个构建版本。essentials只包含常用编码器，体积小；full包含几乎所有编码器，体积大但功能全。如果你不确定，下full更保险。

安装后记得把 ffmpeg 的 bin 目录加到系统 PATH 里，否则每次都要敲完整路径。验证安装是否成功，跑一句ffmpeg -version，能看到版本信息就说明配置好了。

7.2 跨平台编译：除非必要，别自己编译

热搜词里出现了"Android 编译 x264 & ffmpeg"这类内容，说明有人需要在移动端集成 ffmpeg。我的建议是：除非你有非常明确的定制需求，否则直接用预编译好的库。自己编译 ffmpeg 涉及交叉编译工具链、依赖库版本匹配、NDK 配置等一大堆问题，新手很容易卡在环境配置上几天出不来。

如果确实需要编译，记住一个原则：先编译依赖库（如 x264、fdk-aac），再编译 ffmpeg，并且配置参数要和依赖库的安装路径对应。顺序错了或者路径不对，编译必然失败。

7.3 关于 AI 编程工具的安装与配置

Claude Code 这类工具的安装，核心就两步：装运行时环境（通常是 Node.js）、装工具本身、配置认证。不同操作系统的步骤略有差异，但逻辑一致。安装完成后，建议先在空目录里跑一个"hello world"级别的任务，确认工具能正常工作，再去处理真实项目。

配置过程中最容易出问题的是网络和认证。如果工具提示"可能在你所在地区不可用"，那通常是网络环境的问题，需要按照官方文档的指引处理。这一步我不展开，你按官方说明操作即可。

8. 我个人的几条经验总结

做视频这件事，用代码做和用剪辑软件做，本质上是两种思维。剪辑软件的思维是"所见即所得"，你看到什么就拖什么；代码的思维是"描述即所得"，你用参数和逻辑描述你想要什么，工具帮你实现。前者适合创意探索，后者适合批量生产和精确控制。

我这些年最大的体会是：不要试图用代码替代所有剪辑工作。代码化生产的优势在于"可复现、可批量、可版本控制"，但它在"快速试错、直觉调整"上远不如图形界面。最聪明的做法是混合使用：用代码生成素材和模板，用剪辑软件做最终的创意微调。

另一个体会是：把视频处理当成数据处理来对待。视频就是一堆字节，转码就是格式转换，拼接就是数据合并。当你用这个视角看问题，很多看似复杂的操作都会变得清晰。ffmpeg 之所以强大，正是因为它把视频彻底"数据化"了。

最后分享一个小技巧：给你的每一条 ffmpeg 命令写注释。不管是放在脚本里还是放在笔记里，写清楚"这条命令在做什么、关键参数为什么这么设"。三个月后你回头看，会感谢当时的自己。视频处理的参数太多了，靠脑子记是靠不住的，文档化才是长久之计。