1. 缘起为什么我会去折腾 video-use 这套东西做视频内容这几年我最大的感受不是“创意难”而是“重复劳动要命”。一条三分钟的产品演示视频脚本改三遍、字幕对五遍、转场调十遍最后导出还要等半天。更别提批量处理——给二十条素材统一加片头、统一压到 1080p、统一抽封面图纯手工做一遍能把我一下午搭进去。所以当我第一次看到video-use这个标题的时候脑子里蹦出来的不是某个具体工具而是一整套思路用命令行和代码把视频生产流程自动化让机器干重复的活人只负责判断和审美。这套思路落地下来核心就三块拼图。第一块是ffmpeg视频处理领域的老黄牛转码、裁剪、拼接、抽帧、调音量、推流几乎没有它干不了的而且跨平台、免费、脚本友好。第二块是Claude Code一个跑在终端里的 AI 编程助手你可以把它理解成“能读懂你整个项目、还能直接帮你改文件跑命令的结对程序员”它最大的价值是把“我想批量处理视频”这种模糊需求翻译成一条条能跑的 ffmpeg 命令和一段段能维护的脚本。第三块是Remotion 和 Manim前者用 React 写视频适合做数据驱动的动态图形和模板化内容后者是数学动画神器做公式推导、几何演示、算法可视化一绝。这三块拼在一起video-use就不再是一个孤立的工具名而是一套**“AI 辅助 命令行 代码化视频”的工作流**。它解决的问题很具体把视频处理从“点鼠标的体力活”变成“写脚本的脑力活”一次写好反复复用。适合谁来参考我觉着三类人最划算一是做自媒体、需要批量出片的内容创作者二是做技术教程、需要大量录屏剪辑和公式动画的开发者或老师三是任何想把视频处理接进自己自动化流水线的工程师。哪怕你之前没碰过 ffmpeg只要愿意敲几行命令这篇东西都能让你上手。2. 整体设计思路为什么是这套组合拳2.1 先想清楚视频处理到底难在哪很多人以为视频处理难在“软件不会用”其实真正的难点在三个地方。第一是格式和编码的碎片化同样是 mp4H.264 和 H.265 不一样封装格式和编码格式是两码事分辨率、帧率、码率、像素格式随便一个参数不对播放器就给你脸色看。第二是批量操作的重复性单条视频手工调没问题一旦上量人脑记不住那么多参数手也点不过来。第三是创意和执行的耦合你想的是“这里加个淡入”实际要做的是“找到时间点、拖拽、调曲线、预览、导出”中间隔着一堆机械操作。video-use这套工作流的设计出发点就是把这三点逐个拆解。格式碎片化交给 ffmpeg 统一处理它内部有一套非常成熟的编解码体系你只要告诉它“我要 H.264 的 mp4”剩下的它自己搞定。批量重复性交给脚本把参数抽成变量循环一跑就是几十条。创意和执行解耦则交给 Claude Code 和 Remotion/Manim——你用自然语言描述意图AI 帮你生成代码代码再驱动 ffmpeg 或渲染引擎执行。2.2 为什么选 ffmpeg 做底座而不是图形软件我试过不少图形化的剪辑软件做单条精品视频确实顺手但一旦涉及“给一百条视频统一加字幕”这种需求它们就抓瞎了。ffmpeg 的优势恰恰在这里它是为自动化和批处理而生的。一条命令能完成“裁剪 缩放 加水印 转码 抽封面”而且可以写进 shell 脚本、Python 脚本、CI 流水线随时随地复现。更关键的是 ffmpeg 的参数可计算、可版本化。比如码率图形软件里你只能拖个滑块ffmpeg 里你可以写-b:v 2M还能根据源视频动态算。这意味着你的处理逻辑是可以被 review、被 git 管理、被同事复用的。我踩过的一个坑就是早期用图形软件做模板换台电脑、换个版本效果就飘了换成 ffmpeg 脚本之后同样的输入永远得到同样的输出这种确定性对批量生产太重要了。2.3 Claude Code 在中间扮演什么角色Claude Code 不是视频工具它是把“人话”翻译成“命令和代码”的中间层。举个我实际遇到的场景我有一批录屏想把每段开头 3 秒的空白剪掉再统一压到 720p最后抽第一帧当封面。以前我得查半天 ffmpeg 文档现在我可以直接跟 Claude Code 说清楚需求它会给我一条类似这样的命令for f in *.mp4; do ffmpeg -ss 3 -i $f -vf scale-2:720 -c:v libx264 -crf 23 -preset medium \ -c:a aac -b:a 128k out_${f} ffmpeg -i out_${f} -vframes 1 -q:v 2 cover_${f%.mp4}.jpg done它还会顺带解释-ss 3是放在-i前面做快速定位、scale-2:720里的-2是为了保持宽高比且让宽度是偶数H.264 要求宽高能被 2 整除。这种“给命令 讲原理”的方式比我自己翻文档快太多了。而且 Claude Code 能读你项目里的文件你告诉它“参考我上次那个脚本的风格”它就能保持一致不会每次给你换一套写法。2.4 Remotion 和 Manim 补的是哪块短板ffmpeg 强在“处理已有素材”弱在“从零生成画面”。如果你要做的是数据可视化动画、动态图表、公式推导纯靠 ffmpeg 拼是拼不出来的。这时候 Remotion 和 Manim 就派上用场了。Remotion 的思路很讨巧用 React 组件描述视频的每一帧。你写的是普通的 React 代码传入一个frame参数返回这一帧长什么样Remotion 负责把它逐帧渲染成视频。好处是你可以用前端那套生态——CSS 动画、图表库、组件复用——来做视频特别适合“数据变了视频跟着变”的场景比如每周自动生成一份销售数据播报。Manim 则是数学和算法可视化的利器。它用 Python 描述动画Create、Transform、FadeIn这些方法语义清晰做公式推导、几何变换、排序算法演示非常直观。我拿它做过一个快速排序的可视化几十行代码就出来了换成手工做动画得画一整天。这三者不是替代关系而是分层协作Manim/Remotion 负责生成“素材片段”ffmpeg 负责把这些片段和实拍素材拼接、转码、加音轨Claude Code 负责把整个流程串起来并生成可维护的脚本。3. 环境搭建把工具链一个个装到位3.1 ffmpeg 安装别用系统自带的旧版本ffmpeg 安装这件事我的第一条经验是能用官方静态包就别用系统包管理器里的版本。Ubuntu 上apt install ffmpeg装出来的经常是两三年前的版本一些新编码器和滤镜参数不支持跑脚本时报Invalid argument你还以为是命令写错了其实是版本太老。Windows 用户直接去 ffmpeg 官网下载ffmpeg-master-latest-win64-gpl.zip或者 essentials 版本解压到比如C:\ffmpeg然后把C:\ffmpeg\bin加进系统环境变量 PATH。验证方式是开个新的命令行窗口敲ffmpeg -version能打印出版本号和编译配置就成。注意一定要开新窗口老窗口的环境变量不会刷新这是新手最常踩的坑。macOS 用户用brew install ffmpeg就行Homebrew 的版本更新比较及时。Linux 用户如果不想编译可以去官网下静态构建包解压后把ffmpeg、ffprobe、ffplay三个可执行文件丢到/usr/local/bin。想验证编码器支持情况敲ffmpeg -encoders | grep 264能看到libx264就说明 H.264 软编可用。提示如果你要做硬件加速转码比如在 RK3588 这类板子上用需要确认编译时带了对应的硬件编码器如h264_rkmpp。官方静态包通常不带这些得自己交叉编译这块后面单独说。3.2 Claude Code 安装与配置Claude Code 的安装方式取决于你的平台。它本质上是个命令行工具装好之后在终端里输入claude就能进入交互界面。安装前建议先确认 Node.js 环境因为很多 AI 编程工具的 CLI 是基于 Node 的。装完之后第一件事是配置模型接入你可以用官方账号也可以接入兼容的第三方模型服务具体看你的网络和账号情况。配置好之后我建议在项目根目录建一个CLAUDE.md文件把你这个视频项目的约定写进去比如“所有 ffmpeg 命令统一用 libx264、crf 23、preset medium”“输出文件统一放 output 目录”“脚本用 bash 写变量加引号防止空格路径出错”。Claude Code 每次启动会读这个文件相当于给它一份项目规范生成的代码风格就稳定了。这个技巧我是从做前端项目时迁移过来的效果非常好强烈建议你试试。VS Code 用户还可以装对应的扩展在编辑器里直接调用改脚本、看 diff 更方便。不过纯命令行也完全够用看你习惯。3.3 Remotion 和 Manim 的安装要点Remotion 是 npm 包初始化项目用npx create-videolatest它会引导你选模板。装完之后npm start会起一个预览服务你在浏览器里实时看效果改代码自动刷新体验跟做网页一样。渲染用npx remotion render可以指定输出格式和编码参数。Manim 是 Python 包推荐用虚拟环境装python -m venv venv然后pip install manim。它依赖一些系统库Linux 上可能需要装libcairo2-dev、libpango1.0-dev这些官方文档有详细说明。装完跑个manim --version验证。渲染命令是manim -pql scene.py SceneName-pql表示预览、低质量、快速出成品时换成-pqh高质量。注意Manim 渲染很吃 CPU复杂场景一帧要算好几秒。我的做法是先用低质量预览调动画节奏确认没问题再出高质量能省大量时间。4. 核心实操从单条处理到批量流水线4.1 吃透 ffmpeg 命令的基本结构ffmpeg 命令看着吓人其实结构很固定ffmpeg [全局参数] [输入参数] -i 输入文件 [输出参数] 输出文件。全局参数影响整个命令比如-y表示覆盖输出文件不询问输入参数作用于紧跟其后的那个输入输出参数作用于输出文件。理解了这个结构你就能看懂绝大多数命令。举个最常用的转码例子ffmpeg -i input.mov -c:v libx264 -crf 23 -preset medium -c:a aac -b:a 128k output.mp4这里-c:v libx264指定视频编码器-crf 23是质量参数范围 0 到 51数字越小质量越高文件越大23 是公认的甜点值-preset medium是编码速度预设从 ultrafast 到 veryslow越慢压缩率越高-c:a aac -b:a 128k指定音频编码和码率。这条命令几乎能应付 80% 的日常转码需求建议你背下来。4.2 裁剪、缩放、加水印一条龙实际项目里很少只做转码更多是组合操作。比如把一条 4K 视频裁成 1080p、加个角标水印、再压一下ffmpeg -i input.mp4 \ -vf scale1920:1080:force_original_aspect_ratiodecrease,pad1920:1080:(ow-iw)/2:(oh-ih)/2,drawtexttextMyBrand:xw-tw-20:y20:fontsize32:fontcolorwhite0.8 \ -c:v libx264 -crf 23 -preset medium -c:a copy output.mp4这条命令里-vf是视频滤镜链用逗号分隔多个滤镜。scale负责缩放force_original_aspect_ratiodecrease保证不拉伸变形pad负责补黑边到精确的 1920x1080(ow-iw)/2是水平居中的计算drawtext画文字水印w-tw-20表示从右边往左留 20 像素边距。-c:a copy表示音频直接复制不重编码省时间又保质量。这里有个细节值得说滤镜顺序会影响结果。如果你先 pad 再 scale补的黑边会被一起缩放效果就错了。所以顺序一定是先 scale 再 pad。这种坑我踩过不止一次后来养成习惯每写一条复杂滤镜链先用-t 5只处理前 5 秒快速验证确认没问题再跑全片。4.3 用 Claude Code 生成和调试脚本单条命令好写批量脚本才是video-use的精髓。我的做法是先把需求用自然语言写清楚丢给 Claude Code让它生成初版脚本然后我跑一遍把报错信息再丢回去让它修。这个来回通常两三轮就能得到一个能用的脚本。比如我要“把 input 目录下所有 mp4 转成 720p输出到 output 目录文件名保持不变同时抽第一帧当封面”。Claude Code 给我的脚本大概是这样#!/bin/bash set -euo pipefail INPUT_DIR./input OUTPUT_DIR./output COVER_DIR./covers mkdir -p $OUTPUT_DIR $COVER_DIR for f in $INPUT_DIR/*.mp4; do [ -e $f ] || continue base$(basename $f .mp4) echo 处理: $f ffmpeg -y -i $f -vf scale-2:720 -c:v libx264 -crf 23 -preset medium \ -c:a aac -b:a 128k $OUTPUT_DIR/${base}.mp4 ffmpeg -y -i $OUTPUT_DIR/${base}.mp4 -vframes 1 -q:v 2 $COVER_DIR/${base}.jpg done echo 全部完成几个细节值得注意set -euo pipefail让脚本遇到错误就停避免一个文件失败还继续跑[ -e $f ] || continue处理目录为空的情况否则*.mp4不匹配时会把字面量当文件名所有变量都加引号防止路径里有空格。这些都是实战里总结出来的Claude Code 默认生成的脚本不一定带你得知道该加什么。4.4 音频处理响度标准化是个技术活视频做完发现声音忽大忽小这是录屏和混剪的常见问题。ffmpeg 有个loudnorm滤镜专门做响度标准化能按广播标准把音频统一到目标响度。基本用法ffmpeg -i input.mp4 -af loudnormI-16:TP-1.5:LRA11 -c:v copy output.mp4I-16是目标响度单位 LUFS网络视频一般用 -16 到 -14TP-1.5是最大真峰值防止削波LRA11是响度范围。-c:v copy表示视频流直接复制只重编码音频速度快。但loudnorm有个坑它是单遍处理对动态范围大的素材效果一般。更专业的做法是两遍处理第一遍分析得到测量值第二遍用测量值精确归一化。Claude Code 可以帮你把这个两遍流程写成脚本自动解析第一遍的输出再拼第二遍命令。这个需求我提过一次它给的方案是先用-af loudnormprint_formatjson -f null -跑一遍拿到 JSON再用 Python 解析出measured_I等参数填进第二遍命令非常靠谱。4.5 用 Remotion 做数据驱动视频Remotion 适合的场景是“模板固定、数据变化”。比如每周要出一份数据周报视频标题、数字、图表都变但版式不变。用 Remotion 的话你把数据抽成一个 JSON组件读 JSON 渲染换数据就换视频。核心代码结构大概是这样import { AbsoluteFill, useCurrentFrame, interpolate } from remotion; export const DataReport ({ title, value }) { const frame useCurrentFrame(); const opacity interpolate(frame, [0, 30], [0, 1], { extrapolateRight: clamp }); return ( AbsoluteFill style{{ backgroundColor: #0f172a, justifyContent: center, alignItems: center }} h1 style{{ color: #fff, opacity }}{title}/h1 p style{{ color: #38bdf8, fontSize: 80, opacity }}{value}/p /AbsoluteFill ); };useCurrentFrame拿到当前帧号interpolate把帧号映射成透明度就实现了淡入效果。渲染时用--props传入数据 JSON一条命令出一版视频。这种“数据进、视频出”的流水线配合定时任务能做到完全无人值守。4.6 用 Manim 做算法和公式动画Manim 的代码风格是“描述场景”你告诉它要显示什么、怎么变换它负责生成动画。比如演示冒泡排序from manim import * class BubbleSort(Scene): def construct(self): nums [5, 2, 8, 1, 9] bars VGroup(*[ Rectangle(width0.6, heightn/10, fill_opacity0.8, colorBLUE) .shift(RIGHT * i * 0.8) for i, n in enumerate(nums) ]) self.play(Create(bars)) self.wait(0.5) # 这里省略具体排序逻辑核心是每次交换用 Transform 或 animate 移动 self.wait(1)Scene是场景基类construct里描述动画。Create、Transform、FadeOut这些方法语义直观配合self.play和self.wait控制节奏。渲染出来的视频是透明背景的可以直接叠到其他素材上用 ffmpeg 做 overlay 合成。我一般用 Manim 出片段再用 ffmpeg 拼接和加音轨分工明确。5. 常见问题与排查技巧实录5.1 ffmpeg 报错速查表报错信息常见原因解决办法Invalid argument参数位置错、滤镜语法错、编码器不支持检查-ss是否在-i前滤镜用-t 5短测ffmpeg -encoders确认编码器Unknown encoder libx264安装的 ffmpeg 没带该编码器换官方静态包或重新编译带--enable-libx264moov atom not found输入文件损坏或未写完用ffprobe检查文件完整性重新获取源文件Conversion failed输出路径无权限、磁盘满、参数冲突检查目录权限和剩余空间简化参数逐步排查输出视频没声音音频编码不兼容或-an误加确认-c:a设置检查是否误加了-an画面拉伸变形scale 没保持宽高比用scale-2:720或加force_original_aspect_ratio5.2 批量脚本的三个保命习惯第一个习惯是先干跑。在真正执行前把命令里的ffmpeg换成echo看看会执行哪些命令、文件名对不对。这个习惯帮我避免过好几次“把输出覆盖了输入”的惨剧。第二个习惯是输出目录和输入目录分开。我见过太多人图省事直接原地覆盖结果脚本跑一半出错源文件已经没了。永远输出到新目录确认没问题再删旧的。第三个习惯是加日志。脚本里每个文件处理前后都echo一下出错时能快速定位是哪个文件、哪一步挂了。配合set -x还能打印实际执行的命令调试神器。5.3 Claude Code 使用中的经验Claude Code 很强但不能当甩手掌柜。我的经验是需求描述越具体生成结果越靠谱。别说“帮我处理视频”要说“把 input 目录下所有 mp4 转成 720p H.264crf 23音频 aac 128k输出到 output文件名不变抽第一帧存 covers 目录”。参数、路径、命名规则都讲清楚它一次就能给对。另外它生成的命令一定要自己过一遍。我有次让它生成一条推流命令它给的参数里码率和分辨率不匹配跑起来画面糊得不行。AI 懂语法但不一定懂你的业务约束最终把关的还是人。把它的输出当成“一个懂 ffmpeg 的实习生写的初稿”这个心态最合适。5.4 性能与硬件加速的取舍软编码libx264质量好、兼容性强但慢。硬编码如 NVENC、QSV、RKMPP快但同码率下质量略差且不同硬件支持情况不一。我的建议是成片用软编预览和中间产物用硬编。比如批量转码给内部看用硬编几分钟搞定最终发布版用软编慢慢压质量优先。在 RK3588 这类嵌入式板子上做推流硬件编码器能大幅降低 CPU 占用但需要确认 ffmpeg 编译时带了对应模块。交叉编译 x264 和 ffmpeg 是个大工程建议直接找社区现成的编译好的包或者用官方推荐的构建脚本别从零手撸容易卡在依赖上出不来。6. 我踩过的坑和几条实在建议先说一个最坑的路径里有中文或空格。ffmpeg 本身能处理但脚本里如果变量没加引号shell 会把空格当分隔符文件名直接被截断。我早期一个脚本处理“产品 演示.mp4”时输出变成了“产品”后面全乱套。解决办法就一条所有变量引用都加双引号$f而不是$f养成肌肉记忆。第二个坑是滤镜链里的逗号。-vf里多个滤镜用逗号分隔但有些滤镜参数本身也带逗号比如drawtext的text里如果有逗号就得转义或者用引号包起来。我调一个带逗号的标题调了半小时最后发现是转义问题。现在我的习惯是复杂文字水印直接用textfile参数从文件读省得跟转义较劲。第三个坑是帧率不一致导致音画不同步。把 24fps 和 30fps 的素材拼一起如果不统一帧率音频就会飘。解决办法是在拼接前统一转成同一帧率-r 30强制输出帧率或者用fps滤镜。这个在混剪项目里特别常见提前统一能省很多事。最后分享一个提效小技巧把常用的 ffmpeg 命令封装成 shell 函数或者 Makefile 目标比如make to720、make cover比每次敲一长串命令快得多。再配合 Claude Code你甚至可以让它根据你的自然语言描述自动往 Makefile 里加新目标。这套组合用熟了视频处理就从“体力活”彻底变成了“敲几行字的事”。
