1. 从“video-use”这个标题说起它到底想解决什么问题第一次看到video-use这个标题我脑子里蹦出来的第一个念头是这大概率不是一个单纯的播放器也不是一个简单的视频剪辑脚本而是一套“让程序化视频生成这件事变得可复用、可组合”的工具集或者方法论。为什么这么判断因为标题本身太克制了video-use直译过来就是“视频使用”它没有限定是剪辑、转码、合成还是渲染这种命名方式通常出现在两类项目里一类是底层能力封装库另一类是面向特定工作流的脚手架。结合热搜词里高频出现的Claude Code、ffmpeg、Remotion、Manim我基本可以确定这个项目想做的事情是把“用代码生成和处理视频”这条链路打通让开发者或者内容创作者能够像调用函数一样去操作视频。先把这个项目的定位说清楚。video-use面向的核心场景我理解是三个层次。第一个层次是视频处理也就是转码、裁剪、拼接、抽帧、加字幕、改分辨率这些传统 ffmpeg 擅长的活儿。第二个层次是视频合成也就是把图片、文字、音频、动画按照时间轴组合成一个完整的视频这块 Remotion 和 Manim 是典型代表前者偏向 React 生态的声明式视频后者偏向数学动画和教学演示。第三个层次是智能化编排也就是借助 Claude Code 这类 AI 编程助手把自然语言需求翻译成可执行的视频生成脚本降低“我想做个视频”到“视频真的出来了”之间的门槛。为什么这个组合值得单独拿出来讲因为过去做视频自动化痛点非常分散。你要处理素材得会 ffmpeg 命令行你要做动画得学 Manim 的 Python API 或者 Remotion 的 React 组件你要把整个流程串起来还得自己写调度逻辑。video-use这类项目的价值就是把这些碎片化的能力收敛到一个统一的“使用范式”里。它不一定是一个庞大的框架更可能是一组约定、一套目录结构、一批可复用的脚本模板让你在遇到“批量给视频加水印”“把 Markdown 转成讲解视频”“用代码生成数据可视化动画”这些需求时不用每次从零开始。适合谁来参考我觉得有三类人。第一类是独立开发者和小团队他们没有专门的视频后期但需要批量产出演示视频、教程视频、产品介绍视频。第二类是技术内容创作者比如做编程教学、数学科普、数据新闻的博主他们需要把代码、公式、图表变成动态视频。第三类是想入门 AI 辅助编程的工程师他们听说 Claude Code 能写代码但不知道拿它做什么真实项目video-use这种有明确输入输出的场景正好是练手的好靶子。下面我就按照“设计思路—核心细节—实操过程—问题排查”这条线把这个项目拆开讲透。2. 整体设计与思路拆解为什么是 ffmpeg Remotion Manim Claude Code2.1 四件套的分工逻辑各管一段不互相替代很多人一上来就想找一个“全能工具”最好一个命令就能把视频做出来。我踩过这个坑结论是视频领域不存在真正的全能工具只存在分工明确的工具链。video-use的思路之所以合理是因为它承认了这一点并且把四个核心组件放在了正确的位置上。ffmpeg负责的是像素级和流级别的操作。它是整个链路的底座处理的是已经存在的视频和音频。你让它把 MP4 转成 WebM它干得又快又好你让它从第 10 秒切到第 30 秒它一条命令搞定你让它把一批图片按 24 帧合成视频它也能做。但 ffmpeg 不擅长“从无到有”地创造画面它的滤镜系统虽然强大但写复杂动画非常痛苦。所以它的定位是素材加工厂。Remotion负责的是基于 Web 技术的声明式视频合成。它的核心思想是视频就是一系列帧每一帧就是一个 React 组件在特定时间点的渲染结果。这意味着你可以用 CSS、HTML、Canvas、SVG 这些前端技术来做视频复用整个 npm 生态。对于做产品演示、数据看板动画、动态文字排版这类需求Remotion 的效率远高于 ffmpeg 滤镜。它的定位是画面编排器。Manim负责的是数学和科学可视化动画。它最初是为数学教学视频设计的擅长处理坐标系、函数曲线、几何变换、公式推导这些内容。Manim 的动画模型是“场景 对象 变换”你描述的是“这个圆变成那个方”而不是“第 30 帧这个像素是什么颜色”。它的定位是知识可视化引擎。Claude Code负责的是自然语言到代码的翻译和工程编排。它不直接处理视频但它能帮你写 ffmpeg 命令、生成 Remotion 组件、调试 Manim 报错、组织项目目录。它的定位是智能副驾驶。这四者组合起来形成了一条从“想法”到“脚本”到“渲染”到“成品”的完整链路。2.2 为什么不用剪映、PR 这类图形化工具这个问题我被问过很多次。图形化工具当然好上手快、所见即所得但它们有一个致命短板不可编程、不可批量、不可版本控制。你做一个视频用剪映拖拖拽拽半小时搞定但你要做一百个结构相同、只是数据不同的视频剪映就废了。而video-use这套思路的核心优势恰恰在于可复用。举个例子假设你要给公司每周生成一份数据周报视频。用图形化工具你每周都要手动导入数据、调整图表、对齐时间轴一周花两小时。用代码化方案你写一次模板之后每周只需要把新数据喂进去一条命令渲染出来全程五分钟。这个投入产出比在长期来看是碾压性的。另外代码化方案天然适合版本控制你的视频项目可以像代码一样提交到 Git每次修改都有记录团队协作也方便。还有一个容易被忽略的点AI 辅助编程让代码化视频的门槛大幅降低了。以前你要学 ffmpeg 的几百个参数、学 Remotion 的 API、学 Manim 的坐标系学习曲线很陡。现在你可以用 Claude Code 这类工具用中文描述需求它帮你生成初版代码你再微调。video-use这个标题背后其实暗含了“AI 时代视频工作流”这层意思。2.3 项目目录结构的常见设计基于我做过类似项目的经验video-use这类项目通常会采用一种“按功能分层”的目录结构。下面这个结构是我在实际操作中总结出来的比较适合中小型视频自动化项目video-use/ ├── assets/ # 原始素材图片、音频、字体、logo ├── scripts/ # 各类处理脚本 │ ├── ffmpeg/ # ffmpeg 命令封装和批处理 │ ├── remotion/ # Remotion 组件和入口 │ └── manim/ # Manim 场景定义 ├── templates/ # 可复用的视频模板 ├── output/ # 渲染产物按日期或版本分目录 ├── config/ # 配置文件分辨率、帧率、码率等 └── docs/ # 项目说明和操作记录这个结构的好处是职责清晰。素材归素材脚本归脚本产物归产物。你找东西的时候不会翻半天。config目录单独抽出来也很关键因为视频参数经常要调集中管理比散落在各个脚本里强得多。我见过有人把分辨率写死在十几个脚本里后来要改 1080p 到 4K改到崩溃。提示目录名尽量用英文避免中文路径。ffmpeg 和部分渲染工具对中文路径的支持时好时坏尤其是在 Windows 上踩过坑的都懂。3. 核心细节解析与实操要点每个组件到底怎么用3.1 ffmpeg 的安装与核心命令拆解ffmpeg 的安装是第一步也是最容易卡住新手的一步。Windows 用户最常见的做法是去官网下载ffmpeg-master-latest-win64-gpl.zip这类压缩包解压后把bin目录加到系统环境变量PATH里。这里有个细节不要只把 exe 文件复制到某个目录要保留完整的目录结构因为 ffmpeg 依赖同目录下的 dll。我见过有人只复制了ffmpeg.exe结果运行时报缺 dll查了半天。macOS 用户用 Homebrew 最省事brew install ffmpeg一条命令。Ubuntu 用户用apt install ffmpeg但要注意系统源里的版本可能偏旧如果你需要新特性比如某些硬件加速编码器可能需要自己编译或者找第三方源。验证安装是否成功运行ffmpeg -version能看到版本号和编译配置就说明 OK 了。ffmpeg 的命令结构是ffmpeg [全局参数] [输入参数] -i 输入文件 [输出参数] 输出文件。这个结构刚开始容易晕我教你一个记忆方法输入相关的参数写在-i前面输出相关的参数写在-i后面。比如你要指定输入文件的帧率-r 30写在-i前你要指定输出文件的帧率-r 30写在-i后。这个规则能解决 80% 的“参数放错位置”问题。几个高频命令我列一下都是实操中反复用到的# 视频转码MP4 转 WebM指定码率和编码器 ffmpeg -i input.mp4 -c:v libvpx-vp9 -b:v 1M -c:a libopus output.webm # 裁剪时间段从第 10 秒开始取 20 秒 ffmpeg -ss 00:00:10 -i input.mp4 -t 20 -c copy output.mp4 # 提取音频 ffmpeg -i input.mp4 -vn -c:a copy output.aac # 图片序列合成视频按 24 帧输入是 img001.png 到 img100.png ffmpeg -framerate 24 -i img%03d.png -c:v libx264 -pix_fmt yuv420p output.mp4 # 给视频加水印位置在右下角距离边缘 20 像素 ffmpeg -i input.mp4 -i logo.png -filter_complex [1:v]scale100:-1[logo];[0:v][logo]overlayW-w-20:H-h-20 output.mp4这里重点说两个坑。第一个是-c copy的使用。很多人以为-c copy就是“无损快速”但它要求输入输出的容器格式和编码格式兼容。你把 MP4 的 H.264 流直接 copy 到 WebM 容器里大概率失败。-c copy适合做“不重新编码的切割和封装转换”比如 MP4 转 MOV或者从一个大文件里切一段。第二个是-ss的位置。-ss放在-i前面是“快速定位”解码器会跳到关键帧附近速度快但可能不准放在-i后面是“精确切割”会逐帧解码慢但准。做精确剪辑时把-ss放后面。3.2 Remotion 的定位与上手路径Remotion 的核心概念是“用 React 写视频”。你创建一个 React 项目然后定义一个组件这个组件接收一个frame参数返回该帧应该显示的内容。Remotion 会遍历所有帧把每一帧渲染成图片最后用 ffmpeg 合成视频。所以 Remotion 底层其实也依赖 ffmpeg只是它帮你封装好了。上手 Remotion 的路径我建议是这样先用npx create-videolatest创建一个模板项目跑起来看看默认效果。然后重点理解三个 APIuseCurrentFrame()获取当前帧号interpolate()做数值插值spring()做弹性动画。这三个是 Remotion 动画的基石。比如你想让一个方块从左边滑到右边用interpolate(frame, [0, 30], [0, 500])就能实现意思是第 0 帧在位置 0第 30 帧在位置 500中间自动插值。Remotion 最大的优势是前端生态的复用。你可以用 Tailwind 写样式用 D3 画图表用 Three.js 做 3D用 Lottie 播动画。这些在传统视频工具里都要重新学但在 Remotion 里都是现成的。对于做数据可视化视频、产品演示视频的人来说这个优势是决定性的。但 Remotion 也有短板。它的渲染速度受限于浏览器渲染引擎复杂场景下比纯 ffmpeg 慢不少。另外它需要 Node.js 环境对非前端开发者有一定门槛。我的经验是画面元素多、需要复杂排版和交互逻辑的用 Remotion纯素材加工和简单拼接的用 ffmpeg 就够了。不要为了用而用。3.3 Manim 的适用场景与学习曲线Manim 是 3Blue1Brown 那个频道背后的动画引擎后来开源了。它的定位非常明确数学和科学可视化。如果你要做的是“一个圆沿着抛物线运动”“矩阵乘法的逐步演示”“傅里叶变换的波形分解”这类内容Manim 是最佳选择。它的 API 设计就是围绕“对象”和“变换”来的你描述的是数学关系而不是像素操作。Manim 的安装稍微麻烦一点因为它依赖 Python、FFmpeg、LaTeX用于渲染公式等。标准做法是pip install manim然后确保系统里有 ffmpeg 和 LaTeX 发行版。Windows 用户装 LaTeX 推荐 MiKTeXmacOS 推荐 MacTeXLinux 用 TeX Live。如果只是做简单动画不需要公式可以不装 LaTeX但很多教程默认你会用到。Manim 的核心类是Scene你在里面定义construct()方法然后往场景里添加对象和动画。比如from manim import * class SquareToCircle(Scene): def construct(self): circle Circle() square Square() self.play(Create(square)) self.play(Transform(square, circle)) self.play(FadeOut(square))这段代码的意思是创建一个正方形然后把它变成圆形最后淡出。Manim 会自动处理中间帧。这种“描述变换”的思维方式和 Remotion 的“描述每一帧”完全不同各有各的适用场景。Manim 的学习曲线比 Remotion 陡因为它的文档相对学术化很多用法要靠读源码和社区示例。但一旦掌握做数学动画的效率极高。我的建议是先跟着官方 Gallery 里的示例抄一遍改参数看效果再尝试自己组合。不要一上来就啃文档会劝退。3.4 Claude Code 在视频工作流中的实际用法Claude Code 这类 AI 编程助手在video-use项目里的价值不是“帮你写完整项目”而是“帮你跨越具体的技术障碍”。我实际用下来的感受是它在以下几个场景特别有用第一生成 ffmpeg 命令。ffmpeg 的参数太多记不住很正常。你可以直接描述需求“把 input.mp4 转成 720p码率 2M音频 AAC 128k输出 output.mp4”它会给你一条完整的命令。你复制到终端跑一下不对再让它调。第二调试报错。ffmpeg 和 Manim 的报错信息经常很晦涩。你把报错贴给 Claude Code它能帮你翻译成人话并给出修改建议。这个功能省了我大量搜索时间。第三生成 Remotion 组件骨架。你说“帮我写一个 Remotion 组件显示一个标题从下方滑入停留 2 秒后淡出”它能生成可用的代码框架你在此基础上改样式和内容。第四组织项目结构。你可以让它帮你规划目录、写 README、生成配置文件模板。这些琐事交给它你专注在创意和逻辑上。但要注意Claude Code 生成的代码必须验证。它有时候会编造不存在的 API或者参数写错。我的习惯是生成的命令先在小文件上测试生成的组件先在模板项目里跑通再集成。不要盲目信任也不要因为一次错误就否定它。把它当成一个反应很快但偶尔会犯错的实习生。4. 实操过程与核心环节实现从零跑通一个视频生成流程4.1 环境准备一次装好长期省心我以 Ubuntu 为例把整套环境装一遍。Windows 和 macOS 的差异我会标注出来。第一步装基础工具。Ubuntu 下sudo apt update sudo apt install -y ffmpeg python3 python3-pip nodejs npm gitWindows 下ffmpeg 手动下载解压加 PATHPython 和 Node.js 去官网下安装包。macOS 下用 Homebrew 一把梭brew install ffmpeg python node git。第二步装 Manim。推荐用虚拟环境避免污染系统 Pythonpython3 -m venv venv source venv/bin/activate # Windows 是 venv\Scripts\activate pip install manim第三步准备 Remotion。不需要全局安装用npx按需创建项目即可npx create-videolatest my-video-project cd my-video-project npm install第四步验证 ffmpeg 和 Manim 能跑通。ffmpeg 用ffmpeg -versionManim 用manim --version。Remotion 用npm run dev启动预览。注意如果你在 Windows 上遇到 Manim 报 LaTeX 相关错误先确认 MiKTeX 是否在 PATH 里。MiKTeX 安装后需要手动把它的 bin 目录加到 PATH或者用它的控制台工具配置。4.2 一个完整案例把 Markdown 文稿转成讲解视频我拿一个真实需求来演示你有一篇 Markdown 格式的技术文章想把它转成一个带配音、带字幕、带简单动画的讲解视频。这个需求在video-use的框架下可以拆成四步。第一步解析 Markdown提取分段和标题。用 Python 写个脚本把 Markdown 按标题层级拆成“章节”每个章节有标题和正文。这一步的输出是一个 JSON 结构类似[ {type: h1, text: 第一章 概述, content: ...}, {type: h2, text: 1.1 背景, content: ...} ]第二步生成配音。这块可以用 TTS 工具把每段文字转成音频文件。注意要记录每段音频的时长后面做时间轴对齐要用。TTS 的选择很多系统自带的、云服务的都行按你的预算和隐私要求选。生成后用 ffmpeg 统一转成 48kHz 采样率、单声道方便后续合成。第三步用 Remotion 做画面。每个章节对应一个 Remotion 组件显示标题和正文配合简单的入场动画。时间轴根据音频时长来定。这里的关键是把音频时长作为参数传给 Remotion让画面和声音对齐。Remotion 支持读取音频文件的时长你可以在calculateMetadata里做这件事。第四步用 ffmpeg 合成最终视频。Remotion 渲染出来的是无声视频你需要把 TTS 生成的音频和它合并。命令大致是ffmpeg -i video.mp4 -i audio.aac -c:v copy -c:a aac -shortest final.mp4-shortest的作用是让输出以较短的流为准避免音频比视频长导致黑屏。这个流程跑通一次之后你就有了一个“Markdown 转视频”的模板。以后换一篇文章只需要替换输入文件其他步骤自动完成。这就是代码化视频的威力。4.3 参数选择分辨率、帧率、码率怎么定视频参数的选择经常让人纠结。我给出我的经验值你可以直接抄。用途分辨率帧率视频码率音频码率网络分享B站、YouTube1920x1080308-12 Mbps192 kbps移动端预览1280x720304-6 Mbps128 kbps高质量存档3840x21606040-60 Mbps320 kbps快速草稿854x480241-2 Mbps96 kbps帧率的选择有个原则内容决定帧率。纯静态画面加文字动画24 或 30 帧足够有快速运动、游戏画面、体育内容用 60 帧。不要盲目上 60 帧文件体积会翻倍渲染时间也会增加。码率的选择和分辨率挂钩。一个粗略的公式是码率Mbps≈ 分辨率像素数 × 帧率 × 0.07 / 1000000。比如 1080p 30 帧1920×1080×30×0.07/1000000 ≈ 4.35 Mbps这是基准值实际可以往上浮动 50% 到 100% 来保证画质。这个公式不是绝对的但能给你一个起点。编码器的选择也值得说一句。H.264 兼容性最好什么设备都能播H.265 压缩率更高但兼容性稍差VP9 和 AV1 是 Web 端的趋势但编码速度慢。我的建议是不确定就用 H.264确定只在现代浏览器播放就用 VP9 或 AV1。5. 常见问题与排查技巧实录5.1 ffmpeg 报错速查表ffmpeg 的报错信息经常让人摸不着头脑。我整理了一份高频错误对照表都是实际踩过的报错关键词常见原因解决方法Invalid argument参数位置放错或滤镜语法错误检查-i前后参数滤镜用引号包裹No such file or directory路径错误或中文路径用绝对路径路径改英文Unknown encoder编码器未编译进当前版本换编码器或下载完整版 ffmpegmoov atom not found文件损坏或未完整下载重新获取源文件Conversion failed输出参数与输入不兼容检查容器格式和编码格式是否匹配Permission denied输出目录无写权限换目录或改权限Invalid argument是最常见的90% 的情况是参数位置问题。记住那个规则输入参数在-i前输出参数在-i后。滤镜链里的逗号和分号也要注意filter_complex里用分号分隔不同滤镜链用逗号分隔同一链内的滤镜。5.2 Remotion 渲染慢怎么办Remotion 渲染慢是普遍问题因为它走的是浏览器渲染。几个优化方向第一降低分辨率做预览。开发阶段用 480p 预览确认效果后再用 1080p 正式渲染。Remotion 支持通过--scale参数缩放。第二减少 DOM 复杂度。每一帧都要重新渲染整个组件树DOM 节点越多越慢。能用 CSS 动画的不用 JS 动画能合并的图层合并。第三用--concurrency提高并发。Remotion 支持多进程渲染默认会用满 CPU 核心。如果你的机器核心多渲染速度会明显提升。第四把静态部分预渲染成图片。如果视频里有大量不变的背景可以先渲染成图片再用 ffmpeg 叠加动态部分。这个思路在复杂项目里很有效。5.3 Manim 的坐标系和动画时长控制Manim 新手最容易懵的是坐标系。默认场景的坐标范围是 x 从 -7 到 7y 从 -4 到 4这是为 16:9 画面设计的。你可以用Axes类自定义坐标系指定 x_range 和 y_range。画函数图像时用axes.plot(lambda x: x**2)这样的写法。动画时长用run_time参数控制默认是 1 秒。self.play(Create(circle), run_time2)就是 2 秒。多个动画可以用self.play(a, b)并行或者用self.play(a); self.play(b)串行。这里有个技巧用self.wait()控制停顿self.wait(0.5)停半秒self.wait()默认停 1 秒。节奏感对教学视频很重要不要让动画一个接一个没有喘息。5.4 Claude Code 生成代码的验证习惯用 Claude Code 生成视频相关代码我有几个固定的验证习惯。第一命令先 dry run。ffmpeg 没有 dry run 模式但你可以先用一个几秒的小文件测试确认命令正确再处理大文件。第二组件先独立跑。Remotion 组件先在模板项目里单独渲染一帧看看没问题再集成到主项目。第三参数先查文档。Claude Code 给的参数如果没见过去官方文档确认一下避免用了废弃参数。还有一个经验把 Claude Code 当成“第二意见”而不是“唯一答案”。同一个需求你可以让它给两种方案对比之后选更合适的。比如加水印它可能给你 overlay 滤镜方案也可能给你 drawtext 方案你根据实际情况选。6. 我在这类项目里踩过的坑和总结的技巧做视频自动化这几年有几个坑我印象特别深分享出来帮你省时间。第一个坑是音频视频时长不一致。TTS 生成的音频和 Remotion 渲染的视频时长经常差个零点几秒。如果不处理合成出来要么音频被截断要么视频最后黑屏。解决办法是用-shortest参数或者在生成阶段就把时间轴对齐。我现在习惯在 Remotion 里读取音频时长动态设置视频长度从源头解决。第二个坑是字体缺失导致渲染异常。Remotion 和 Manim 都依赖系统字体如果你在开发机上有某个字体在服务器上没有渲染出来就是方块或者默认字体。解决办法是把字体文件打包进项目用font-face或 Manim 的TextFont指定字体路径。这个坑在跨平台部署时特别常见。第三个坑是ffmpeg 版本差异。不同版本的 ffmpeg同一个命令的行为可能不同。比如某些滤镜参数在新版本里改了名字旧脚本就跑不了。我的做法是在项目 README 里记录 ffmpeg 版本并在 CI 里固定版本。生产环境不要用“最新版”用“验证过的版本”。第四个坑是渲染产物的管理。视频文件很大几次渲染下来磁盘就满了。我现在习惯在output目录下按日期和版本号建子目录并写一个清理脚本定期删除超过一定天数的草稿。正式产物单独归档不要和草稿混在一起。最后一个技巧把常用命令封装成脚本或 Makefile。不要每次都手敲 ffmpeg 命令容易出错。写一个Makefile把make preview、make render、make clean这些目标定义好团队里谁都能用也方便交接。这个习惯看起来小但长期收益很大。这套video-use的思路核心不是某个具体工具而是“把视频当作代码来管理”的意识。工具会变ffmpeg 会更新Remotion 会迭代Manim 会重构但“可复用、可版本控制、可自动化”这个方向不会变。你先从一个最小的流程跑通比如“图片序列转视频”然后再逐步加入音频、字幕、动画。不要一上来就搞大项目容易半途而废。跑通一个再扩展一个积累下来就是一套属于自己的视频生产管线。
