1. 从video-use这个标题能读出什么第一次看到video-use这个标题配合着Claude Code、ffmpeg、Remotion、Manim这几个关键词我脑子里第一反应是这大概率是一个把AI编程助手和视频生产工具链缝合起来的项目。为什么这么判断因为这几个词放在一起指向性其实非常明确——Claude Code负责写代码/调工具ffmpeg负责底层音视频处理Remotion负责用React写视频Manim负责数学动画与程序化可视化。这四样东西凑一块本质上就是在回答一个问题能不能让AI帮我把视频这件事自动化地做出来我做了十多年技术内容见过太多视频自动化的项目最后烂尾原因往往不是技术不行而是没想清楚video-use到底要解决哪一段的痛点。视频生产这条链路特别长素材采集、剪辑、转码、合成、加字幕、加特效、导出、分发。每一段都有成熟工具但把它们串起来、并且让一个AI助手能理解并调用这才是真正难的地方。所以这篇我想聊的不是某个工具怎么用而是把video-use这个方向拆开讲清楚它背后的技术选型逻辑、每一环的坑、以及我自己实操下来觉得靠谱的组合方式。如果你是想用AI辅助做视频的开发者、想批量生产内容的自媒体、或者单纯对程序化视频好奇的技术人这篇应该都能给你一些能直接抄的东西。我会尽量把每个选择的为什么讲透而不是甩一堆命令让你自己猜。2. 为什么是ffmpeg打底而不是别的2.1 ffmpeg在视频链路里到底扮演什么角色很多人对ffmpeg的理解停留在格式转换工具这其实大大低估了它。ffmpeg更像是一个音视频领域的瑞士军刀操作系统解码、编码、滤镜、封装、推流、抽帧、拼接、字幕烧录几乎你能想到的对视频的底层操作它都能干。在video-use这类项目里ffmpeg通常承担的是最后一公里的执行层——上层无论是Remotion渲染出来的帧序列还是Manim导出的动画片段最终都要经过ffmpeg做封装、转码、音画同步。我个人的经验是任何视频自动化项目ffmpeg都是绕不开的地基。原因很简单它是目前生态最完整、跨平台支持最好、命令行可编程性最强的方案。你可以在Ubuntu、Windows、macOS上跑同一套命令也可以把它编译进Android热词里就有ffmpeg for android已编译这种需求这种普适性没有第二个工具能比。2.2 安装这件事坑比你想的多热词里ffmpeg安装ffmpeg下载官网ffmpeg master latest win64 essentials.zip这些词高频出现说明安装本身就是很多人的第一道坎。我踩过的坑总结一下Windows上官方推荐的是gyan.dev或者BtbN的构建版本。ffmpeg-master-latest-win64-gpl.zip这种包解压后要把bin目录加进PATH否则命令行里敲ffmpeg会提示找不到。很多人下载了essentials版本发现某些编码器没有比如libx264、libx265可能不在里面这时候就得换full版本或者gpl版本。Ubuntu上相对简单apt install ffmpeg就行但要注意系统源里的版本可能偏老某些新滤镜或者新编码参数不支持。如果你要用到比较新的特性建议自己编译或者用静态构建。提示装完之后一定要用ffmpeg -version和ffmpeg -encoders确认版本和可用编码器别等到跑任务时报Unknown encoder才回头查。还有一个高频问题是ffmpeg 安装后重装了系统 如何回复——这其实是问重装系统后怎么恢复环境。答案很朴素ffmpeg本身是绿色软件把之前的整个文件夹备份好重装后重新加PATH即可不需要重新下载。养成把ffmpeg放在固定路径比如D:\tools\ffmpeg的习惯能省很多事。2.3 几个video-use场景里最常用的ffmpeg命令既然是实操向我直接给几个在视频自动化里出场率最高的命令都是我自己反复用过的抽帧把视频拆成图片序列方便后续处理或喂给其他工具ffmpeg -i input.mp4 -vf fps30 frames/%06d.png拼接把多个片段按顺序合成注意要先用concat协议生成列表文件ffmpeg -f concat -safe 0 -i list.txt -c copy output.mp4m3u8转mp4热词里ffmpeg m3u8转换mp4格式就是这个需求ffmpeg -i index.m3u8 -c copy -bsf:a aac_adtstoasc output.mp4加字幕并烧录进画面ffmpeg -i input.mp4 -vf subtitlessub.srt output.mp4这几个命令覆盖了video-use项目里80%的底层操作。关键点在于-c copy能避免重新编码、极大提速但前提是源和目标封装格式兼容否则还是得老老实实转码。3. Remotion和Manim两条完全不同的程序化视频路线3.1 Remotion适合什么不适合什么Remotion的核心思路是用React组件描述视频。你写的是JSX它把每一帧当成一次React渲染然后逐帧截图合成视频。这个思路对前端开发者极其友好——你会的CSS动画、Flex布局、组件复用全都能直接搬到视频里。它适合的场景很明确数据驱动的、模板化的、需要批量生成的视频。比如每周自动生成的数据报告视频、电商商品展示视频、带动态字幕的讲解视频。因为视频内容本质上是数据模板Remotion能让你用写网页的方式批量产出。但它不适合什么不适合需要复杂视频剪辑逻辑的场景比如多轨道时间线、精细的音频波形对齐、复杂的转场特效。这些还是得靠传统剪辑软件或者ffmpeg滤镜。我见过有人硬要用Remotion做vlog剪辑最后痛苦不堪这就是选错了工具。3.2 Manim的定位数学动画的专属利器Manim是3Blue1Brown那套数学动画背后的引擎热词里manim官网高频出现说明关注度一直不低。它的强项是精确的几何变换、公式推导动画、坐标系绘制。如果你要做的是讲清楚一个数学/物理概念的视频Manim几乎是唯一优雅解。但Manim的学习曲线比Remotion陡。它基于Python你需要理解它的Scene、Mobject、Animation这套抽象。而且它的渲染速度不快复杂场景渲染几分钟视频可能要跑很久。所以在video-use项目里Manim通常不是主力而是特定片段的生产者——比如整个视频里有一段需要展示公式推导就用Manim单独渲染出来再用ffmpeg拼进主视频。3.3 三者怎么协作一个我实际用过的分工把ffmpeg、Remotion、Manim放在一个项目里我的分工是这样的环节工具理由模板化主体内容RemotionReact生态数据驱动批量生成强数学/公式动画片段Manim几何精确学术表达清晰封装、转码、拼接、字幕ffmpeg底层全能跨平台稳定调度与代码生成Claude Code自然语言转脚本降低门槛这个分工的核心逻辑是让每个工具干它最擅长的事用ffmpeg做粘合剂。不要试图用一个工具解决所有问题那是烂尾的开始。4. Claude Code在video-use里到底能帮上什么忙4.1 它解决的是门槛而不是能力Claude Code这类AI编程助手的价值不在于它能做出你做不到的视频而在于它能把你知道该怎么做但懒得写的代码快速写出来。视频自动化最大的痛点是每个环节都要写胶水代码。抽帧要写脚本、调ffmpeg要拼命令、Remotion要写组件、Manim要写场景这些代码单看都不难但加起来工作量巨大。Claude Code能干的事很具体你说帮我把这个目录下所有mp4抽成30fps的帧序列它直接给你ffmpeg命令你说用Remotion写一个带淡入效果的标题组件它给你JSX你说这段Manim动画的公式位置不对它能帮你调坐标。它把查文档、拼参数、试错这个过程压缩了。4.2 安装与配置的现实问题热词里claude code安装claude code使用教程vscode配置claude codeubuntu安装claude code这些词密集出现说明大家卡在环境配置上。我梳理一下常见路径在VS Code里通常是装对应的扩展然后在设置里配置好认证信息。Ubuntu上一般是通过npm全局安装对应的CLI工具装完用claude命令启动。Windows上现在也有桌面客户端热词里claude code桌面版claude code 客户端就是这类需求。注意热词里出现了note: claude code might not be available in your country这类提示这属于服务可用性范畴具体以官方说明为准我这里只聊技术集成不涉及任何网络访问方式。配置过程中最容易出问题的是认证和权限。很多人装完了发现命令跑不起来八成是认证没配好或者PATH没生效。我的建议是装完后先在终端里跑一个最简单的命令验证别急着上复杂项目。4.3 让Claude Code真正好用的几个技巧用了这么久我总结几条让它在video-use场景里真正提效的经验第一给它明确的上下文。别只说帮我处理视频要说我有一个1080p、30fps的mp4想抽帧后喂给图像识别请给我ffmpeg命令并解释每个参数。上下文越具体输出越可用。第二让它解释而不是只给结果。视频处理参数很容易写错让它解释-vf、-crf、-preset这些参数的含义你能顺便学到东西下次自己就能改。第三善用它的技能机制。热词里claude code skillclaude code怎么手动装github上的skills说明很多人已经在用扩展能力。你可以把常用的ffmpeg命令模板、Remotion组件模板做成技能让它随取随用避免每次重复描述。第四接入其他模型做补充。热词里claude code接入deepseekclaude code接deepseek反映了一种常见做法不同模型擅长的东西不一样有的擅长写代码有的擅长理解中文需求组合使用往往效果更好。5. 一条完整的video-use流水线该怎么搭5.1 从需求到成片的五个阶段我把video-use的完整链路拆成五段每段说清楚输入输出和工具阶段一需求解析。输入是一句自然语言需求比如做一个介绍我们产品的30秒视频。输出是结构化的脚本分几个镜头、每个镜头多长、配什么文字。这一段Claude Code能帮上大忙把模糊需求转成可执行的规格。阶段二素材与模板准备。根据脚本确定哪些用Remotion模板生成、哪些用Manim渲染、哪些是现成素材。这一段是纯工程活考验的是模板库的积累。阶段三分段渲染。Remotion渲染出webm或帧序列Manim渲染出mp4各自独立。关键点所有片段统一分辨率和帧率否则后面拼接会出问题。我一般统一到1080p、30fps。阶段四ffmpeg合成。把各段拼接、加背景音乐、烧字幕、统一转码。这一步命令最长也最容易出错。阶段五质检与导出。检查音画同步、时长、文件大小导出目标格式。5.2 拼接阶段最容易翻车的三个点第一帧率不一致导致音画不同步。Remotion默认可能是30fpsManim可能是60fps直接concat会出问题。解决方法是拼接前统一转码ffmpeg -i segment.mp4 -r 30 -c:v libx264 -crf 18 -preset medium normalized.mp4第二分辨率不一致导致画面拉伸或黑边。用scale滤镜统一ffmpeg -i input.mp4 -vf scale1920:1080:force_original_aspect_ratiodecrease,pad1920:1080:(ow-iw)/2:(oh-ih)/2 output.mp4第三音频采样率不一致导致爆音或静音。统一到44100Hz或48000Hz。这三个点我在项目里都踩过每次都是视频能播但就是哪里不对排查半天才发现是参数不统一。养成拼接前先归一化的习惯能省掉大量返工。5.3 一个可复用的合成脚本骨架#!/bin/bash # 1. 归一化所有片段 for f in segments/*.mp4; do ffmpeg -i $f -r 30 -vf scale1920:1080:force_original_aspect_ratiodecrease,pad1920:1080:(ow-iw)/2:(oh-ih)/2 \ -c:v libx264 -crf 18 -preset medium -c:a aac -ar 48000 normalized/$(basename $f) done # 2. 生成拼接列表 for f in normalized/*.mp4; do echo file $PWD/$f list.txt done # 3. 拼接 ffmpeg -f concat -safe 0 -i list.txt -c copy merged.mp4 # 4. 加背景音乐 ffmpeg -i merged.mp4 -i bgm.mp3 -c:v copy -c:a aac -shortest final.mp4这个骨架我用了很多次改改路径就能跑。核心思想是先归一化再拼接别偷懒。6. 那些没人告诉你但一定会遇到的坑6.1 编码器选择libx264还是硬件编码很多人纠结用CPU编码还是GPU编码。我的经验是质量优先用libx264/libx265速度优先用硬件编码。libx264的-crf 18在画质和体积之间平衡得很好但慢。如果你有NVIDIA显卡h264_nvenc能快好几倍但同码率下画质略差。批量生产内容时我通常用硬件编码跑初稿最终成片用libx264重编一遍。6.2 中文字幕的字体问题烧录中文字幕时如果系统没装对应字体ffmpeg会渲染成方块。解决方法是显式指定字体文件ffmpeg -i input.mp4 -vf subtitlessub.srt:force_styleFontNameMicrosoft YaHei output.mp4或者用fontsdir参数指定字体目录。这个坑我踩过不止一次尤其是把脚本从Windows搬到Linux跑的时候。6.3 长视频的内存与磁盘处理长视频时ffmpeg默认会占用大量内存做缓冲。如果机器内存小可以加-threads限制线程数或者分段处理再拼接。磁盘方面抽帧是最占空间的一个10分钟1080p视频抽成PNG序列可能几十GB。抽帧前先算一下空间别把磁盘跑满导致任务中断。6.4 推流场景的延迟问题热词里ffmpeg推流到srs存在延迟rk3588 ffmpeg推流这类需求说明有人在做实时推流。推流延迟通常来自几个地方编码缓冲、网络传输、服务端缓冲。降低延迟的关键参数是-tune zerolatency和减小GOPffmpeg -i input -c:v libx264 -tune zerolatency -g 30 -c:a aac -f flv rtmp://...但要注意延迟和画质是矛盾的zerolatency会牺牲压缩效率。这个取舍得根据实际场景定。7. 我对video-use这个方向的一些真实判断做了这么多视频自动化我最大的体会是工具链的成熟度已经足够了真正的瓶颈在编排。ffmpeg、Remotion、Manim各自都很强Claude Code又能帮你写胶水代码理论上你可以在几分钟内搭出一条流水线。但实际做起来你会发现80%的时间花在处理各种不一致上——分辨率不一致、帧率不一致、编码不一致、字体不一致。所以我的建议是先建立一套自己的归一化标准再谈自动化。比如规定所有素材统一1080p/30fps/H.264/AAC所有字幕统一用某个字体所有片段统一命名规则。标准定好了后面的自动化才有意义。否则你只是在用更快的速度制造混乱。另一个判断是不要追求全自动。视频这东西最后10%的打磨节奏、情绪、细节目前还是得靠人。AI和工具能帮你把前90%的重复劳动干掉这已经价值巨大了。把省下来的时间花在创意和打磨上才是video-use这类项目真正的意义。最后分享一个我自己的小习惯每做完一个视频项目我都会把这次用到的ffmpeg命令、Remotion组件、Manim场景整理成一个模板库。下次遇到类似需求直接改参数就能用。这个习惯坚持下来我的视频生产速度提升了不止一倍。工具会过时但积累可复用资产这件事永远不会错。
