1. 从video-use这个模糊标题说起它到底想解决什么问题第一次看到video-use这个标题加上一串围绕 Claude Code、ffmpeg、Remotion、Manim 的热搜词我脑子里冒出来的第一个判断是这大概率不是一个具体的开源项目名而是一个方向性的命题——怎么让 AI 编程助手真正用起来视频这件事。换句话说它关心的不是视频怎么剪而是视频这种媒介怎么被代码化、被工具链化、被 AI 代理化。这个判断不是拍脑袋。你把热搜词摊开看会发现它们天然分成三堆一堆是 Claude Code 相关的安装、配置、接入 DeepSeek、skill、SDK一堆是 ffmpeg 相关的安装、命令、推流、m3u8 转 mp4、交叉编译还有一堆是 Remotion 和 Manim 这种用代码生成视频的框架。这三堆东西凑在一起指向一个非常具体的场景用 AI 编程代理去驱动一条视频处理与生成的流水线。所以这篇东西我不打算写成某个库的 API 手册那种文章网上一抓一大把。我更想聊的是当你真的想搭一条AI 能操作视频的工作流时ffmpeg、Remotion、Manim 这三类工具各自站在什么位置Claude Code 这类代理又在中间扮演什么角色以及我在实际折腾过程中踩过的那些坑。适合谁看适合已经会写点代码、想把手里的视频活儿自动化、又不想被 GUI 剪辑软件绑死的人。哪怕你只是想知道ffmpeg 到底能干嘛Manim 和 Remotion 有啥区别这篇也能给你一个能落地的坐标系。先说一个反直觉的结论在这条链路里最难的从来不是生成视频而是让 AI 稳定地调用正确的工具、传对参数、拿到可验证的结果。视频这东西不像文本它没有一眼看出对错的即时反馈一个参数写错可能渲染十分钟才发现画面全黑。这个特性决定了整条工作流的设计思路后面会反复回到这一点。2. 三类视频工具的分工ffmpeg、Remotion、Manim 各管哪一段2.1 ffmpeg 是视频界的瑞士军刀但它不是创作工具ffmpeg 的定位必须说清楚否则新手特别容易走弯路。它是一个转码、封装、滤镜、流处理的底层工具强项是把已有的视频/音频/图片按你的意志重新组合和转换弱项是从零创造视觉内容。你想把 m3u8 切片合成 mp4、想把一段视频裁掉前 3 秒、想批量压缩、想抽帧、想加水印、想推流ffmpeg 都是首选一条命令搞定。但你要是想画一个会动的数学公式ffmpeg 帮不了你它没有场景描述能力。这就是为什么热搜里同时出现了 Manim 和 Remotion——它们负责从代码生成画面ffmpeg 负责把生成出来的东西再加工和分发。我常用的几个 ffmpeg 命令直接抄# m3u8 转 mp4不重新编码速度快 ffmpeg -i input.m3u8 -c copy output.mp4 # 裁剪从第 5 秒开始取 10 秒 ffmpeg -ss 5 -i input.mp4 -t 10 -c copy cut.mp4 # 抽帧每秒 1 帧 ffmpeg -i input.mp4 -vf fps1 frame_%04d.png # 压缩CRF 越大越糊23 是常用平衡点 ffmpeg -i input.mp4 -c:v libx264 -crf 23 -preset medium output.mp4注意-c copy是流复制不重新编码所以极快但前提是容器格式兼容。m3u8 转 mp4 用-c copy经常出问题时间戳错乱、音画不同步这时候老老实实去掉-c copy重新编码慢是慢但稳。2.2 Remotion 是用 React 写视频适合数据驱动和模板化Remotion 的核心卖点一句话讲完你写 React 组件它把每一帧渲染成画面最后合成视频。这意味着什么意味着你所有的前端技能——CSS 动画、SVG、Canvas、第三方图表库——全都能直接用在视频里。你要做一个每周自动生成的销售数据播报视频数据从接口拉图表用 ECharts 画动画用 CSS 写Remotion 负责按帧渲染这套组合拳打下来非常顺。它适合的场景很明确批量、模板化、数据驱动。比如给 1000 个用户各生成一条带名字的个性化视频Remotion 的inputProps机制就是为这个设计的。但它的代价是你得有 Node 环境、得懂 React、渲染时对内存和 CPU 有一定要求而且它本质上是逐帧截图再合成渲染速度不算快。2.3 Manim 是数学动画的专用引擎别拿它做通用视频Manim 是那个做数学科普视频的引擎社区版叫 Manim Community。它的强项是精确的几何变换、公式排版、坐标系动画。你要画一个函数图像怎么随参数变化、要演示矩阵乘法、要做一个 3Blue1Brown 风格的动画Manim 是天花板级别的选择。但它的边界也很硬它不是通用视频编辑器。你拿 Manim 去做一个产品宣传片会非常痛苦因为它的场景抽象是为数学和几何服务的做文字排版、做图片合成、做转场都比 Remotion 或传统剪辑软件麻烦得多。所以选型上我的经验是需求首选理由转码/裁剪/压缩/推流ffmpeg底层、快、命令即用数据驱动、模板化、Web 技术栈RemotionReact 生态直接复用数学/几何/公式动画Manim专为精确动画设计复杂剪辑、调色、多轨传统 NLE代码化收益低别硬上这张表是我踩了不少坑之后总结的。早期我试图用 Manim 做一个带大量文字排版的产品视频结果光调文字位置就花了两天后来换成 Remotion半天搞定。工具没有好坏只有匹配不匹配。3. Claude Code 在这条链路里的真实角色不是帮你写代码是帮你调度工具3.1 为什么视频场景特别需要 AI 代理前面说过视频工作流最大的痛点是反馈慢、验证难。你写一段 ffmpeg 命令参数错了可能跑完才发现输出是坏的。这时候一个能读文档、试命令、看报错、改参数的代理就非常有价值。Claude Code 这类工具的核心能力不是生成代码而是在一个有文件系统、有终端、能执行命令的环境里自主地完成多步任务。举个我实际用过的场景我有一批 m3u8 文件要转 mp4但每个文件的分片时长不一样有的还带加密。我懒得一个个看就直接把任务描述给代理把这个目录下所有 m3u8 转成 mp4遇到加密的先告诉我转换失败的记录到 failed.log。它会自己去ls、去试ffmpeg、去看报错、去判断哪些是加密的最后给我一个结果。这个过程里它其实是在替我执行一套探索性的调试流程。3.2 安装和配置里最容易卡住的几个点热搜里claude code 安装claude code 安装教程windows 安装 claude codeubuntu 安装 claude code这些词高频出现说明安装本身就是一道坎。我把常见的坑列一下Node 版本这类工具通常依赖较新的 NodeNode 16 以下基本别想建议直接上 LTS 的 20 或 22。装之前先node -v看一眼。权限问题Linux/macOS 下全局安装经常遇到EACCES别急着sudo正确做法是配一个用户级的 npm 全局目录或者用 nvm 管理 Node从根上避开权限问题。网络与环境安装过程中如果卡在下载先确认基础网络和包管理器的镜像配置是否正常这是环境问题不是工具问题。Windows 的终端Windows 上建议用 WSL 或者新版 PowerShell老版本 cmd 对某些交互支持不好容易出现奇怪的字符编码问题。提示安装类问题 90% 是环境问题Node 版本、权限、镜像不是工具本身的问题。遇到报错先看报错信息里的关键词别急着重装。3.3 接入不同模型和 skill 机制的意义热搜里还有claude code 接入 deepseekclaude code skillclaude code 怎么手动装 github 上的 skills这些。这背后反映的是一个趋势代理工具正在变成可插拔的平台。你可以换底层模型可以装社区写的 skill 来扩展它的能力。这对视频工作流意味着什么意味着你可以写一个ffmpeg 常用命令的 skill把你们团队常用的转码参数、目录规范、命名规则固化进去之后代理处理视频任务时就会自动遵循这套规范。这比每次都在 prompt 里重复一遍要靠谱得多。我自己的做法是把输出目录结构命名前缀默认 CRF 值这些写进一个 skill 文件团队里谁用都一致。4. 把三者串起来一条能跑通的AI 驱动视频流水线4.1 整体架构长什么样我实际搭过的一条链路是这样的你可以参考素材层原始视频、图片、数据文件放在input/目录。生成层需要数学动画的用 Manim 脚本生成需要数据可视化的用 Remotion 渲染输出到generated/。加工层ffmpeg 负责统一分辨率、统一编码、加片头片尾、压缩输出到output/。调度层Claude Code 这类代理负责读任务描述、调用上面各层的脚本、检查产物、记录日志。关键设计原则是每一层都产出可验证的中间文件。Manim 渲染完先出一段 mp4你能直接播Remotion 渲染完先出一段 mp4你能直接看ffmpeg 加工完再出一段你能对比。这样代理在每一步都有证据可以检查而不是等到最后才发现全错。4.2 一个具体的任务拆解示例假设任务是这样把 data.csv 里的月度数据做成一个 30 秒的动画视频配上背景音乐输出 1080p。代理的合理执行路径应该是先读data.csv确认字段和行数判断用 Remotion 还是 Manim数据可视化 文字选 Remotion 更合适生成 Remotion 组件代码用inputProps把数据传进去渲染出无声视频用 ffmpeg 把背景音乐混进去统一到 1080p输出最终文件并报告时长、分辨率、文件大小。这里面每一步都有明确的输入输出代理可以逐步验证。最忌讳的是让代理一口气生成一个巨大的脚本然后直接跑那样一旦出错你根本不知道错在哪一步。4.3 参数计算为什么这些数字不是随便定的拿视频编码来说几个关键参数背后都有逻辑分辨率1080p 是 1920x1080。如果你源素材是 4K降到 1080p 能显著减小体积但要注意宽高比别把 16:9 的素材硬塞进 9:16 的框里会变形。帧率24/25/30/60 是常见值。动画类内容 30 帧足够60 帧适合快速运动。帧率不统一会导致音画不同步混流前务必统一。码率与 CRFCRF 是恒定质量模式18 接近无损23 是默认平衡点28 以上明显糊。文件大小大致和 CRF 成反比关系但具体数值取决于画面复杂度没法精确预测只能试。音频AAC 128kbps 对大多数场景够用192kbps 更保险。采样率统一到 44100 或 48000别混。这些数字我建议你写进配置里别每次手敲。代理调用时读配置既快又不容易错。5. 踩坑实录那些让我熬夜的报错和它们的根因5.1 ffmpeg invalid argument八成是参数顺序或引号问题这个报错太常见了。ffmpeg 的参数是位置敏感的-ss放在-i前面和后面行为完全不同前者快速定位后者精确但慢。还有路径里有空格没加引号、Windows 下反斜杠被转义都会报 invalid argument。我的排查顺序是先把命令简化到最小可运行版本比如只保留-i input -c copy output跑通了再一点点加参数。别一上来就写一条巨长的命令然后对着报错发呆。5.2 推流延迟不是 ffmpeg 的锅是缓冲策略热搜里ffmpeg 推流到 srs 存在延迟这个很典型。推流延迟通常来自几个地方编码器的缓冲、-tune zerolatency没加、GOP 太大、播放端的缓冲。解决思路是编码加-tune zerolatency减小 GOP-g设小一点必要时用-fflags nobuffer。但要注意低延迟和画质/稳定性是有取舍的一味追求低延迟可能导致卡顿。5.3 交叉编译Android 上编 x264 和 ffmpeg 的经典难题跨平台交叉编译 android 编译 x264 ffmpeg这个热搜词说明很多人卡在这。核心难点是要先编 x264再编 ffmpeg 并链接它顺序错了就找不到库。而且 NDK 版本、ABIarm64-v8a、armeabi-v7a、API level 都要匹配。我的经验是把编译脚本参数化把 NDK 路径、ABI、API level 抽成变量一次配好之后换目标平台只改变量。别每次手敲一长串 configure 参数。5.4 环境重装后的如何恢复把环境当代码管理热搜里有个很真实的词ffmpeg 安装后重装了系统 如何回复恢复。这问题的本质是环境没有版本化。我的做法是把所有安装步骤、版本号、配置写成一个脚本或者一份文档放在仓库里。重装系统后跑一遍脚本就恢复了。ffmpeg 这种工具建议记录清楚是哪个版本、从哪装的、编了哪些 codec。别依赖记忆。6. 给不同基础读者的上手建议如果你是完全的新手我的建议是先别碰代理先把 ffmpeg 用熟。找几个真实的小任务把手机拍的视频压缩、把一段视频转成 GIF、把几个片段拼起来。跑通这些你对视频处理是怎么回事就有感觉了。然后再去看 Remotion 或 Manim选一个跟你技术栈接近的。如果你已经会写代码想上代理那我的建议是从小任务开始让代理做可验证的事。比如把这个目录的视频都转成 720p而不是帮我做个宣传片。前者代理能自己验证结果后者它没法判断好坏。随着你信任度提高再逐步放权。如果你在团队里推这套东西最重要的是把规范固化下来目录结构、命名规则、默认参数、日志格式。这些写进 skill 或配置文件比写进文档有用得多因为代理会真的去读它。最后分享一个我自己的小习惯每次让代理处理视频任务我都会要求它输出一份处理报告包含输入文件、执行的命令、输出文件、耗时、文件大小。这份报告既是验证依据也是下次复现的参考。视频这东西没有报告过两天你自己都忘了当时是怎么处理的。