企业官网建设流程全解析

1. 缘起：为什么我会去折腾 video-use 这套东西

做视频内容这几年，我最大的感受不是“创意难”，而是“重复劳动要命”。一条三分钟的产品演示视频，脚本改三遍、字幕对五遍、转场调十遍，最后导出还要等半天。更别提批量处理——给二十条素材统一加片头、统一压到 1080p、统一抽封面图，纯手工做一遍能把我一下午搭进去。所以当我第一次看到video-use这个标题的时候，脑子里蹦出来的不是某个具体工具，而是一整套思路：用命令行和代码把视频生产流程自动化，让机器干重复的活，人只负责判断和审美。

这套思路落地下来，核心就三块拼图。第一块是ffmpeg，视频处理领域的老黄牛，转码、裁剪、拼接、抽帧、调音量、推流，几乎没有它干不了的，而且跨平台、免费、脚本友好。第二块是Claude Code，一个跑在终端里的 AI 编程助手，你可以把它理解成“能读懂你整个项目、还能直接帮你改文件跑命令的结对程序员”，它最大的价值是把“我想批量处理视频”这种模糊需求，翻译成一条条能跑的 ffmpeg 命令和一段段能维护的脚本。第三块是Remotion 和 Manim，前者用 React 写视频，适合做数据驱动的动态图形和模板化内容；后者是数学动画神器，做公式推导、几何演示、算法可视化一绝。

这三块拼在一起，video-use就不再是一个孤立的工具名，而是一套**“AI 辅助 + 命令行 + 代码化视频”的工作流**。它解决的问题很具体：把视频处理从“点鼠标的体力活”变成“写脚本的脑力活”，一次写好，反复复用。适合谁来参考？我觉着三类人最划算：一是做自媒体、需要批量出片的内容创作者；二是做技术教程、需要大量录屏剪辑和公式动画的开发者或老师；三是任何想把视频处理接进自己自动化流水线的工程师。哪怕你之前没碰过 ffmpeg，只要愿意敲几行命令，这篇东西都能让你上手。

2. 整体设计思路：为什么是这套组合拳

2.1 先想清楚：视频处理到底难在哪

很多人以为视频处理难在“软件不会用”，其实真正的难点在三个地方。第一是格式和编码的碎片化，同样是 mp4，H.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-video@latest，它会引导你选模板。装完之后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 "scale=1920:1080:force_original_aspect_ratio=decrease,pad=1920:1080:(ow-iw)/2:(oh-ih)/2,drawtext=text='MyBrand':x=w-tw-20:y=20:fontsize=32:fontcolor=white@0.8" \ -c:v libx264 -crf 23 -preset medium -c:a copy output.mp4

这条命令里-vf是视频滤镜链，用逗号分隔多个滤镜。scale负责缩放，force_original_aspect_ratio=decrease保证不拉伸变形；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 "loudnorm=I=-16:TP=-1.5:LRA=11" -c:v copy output.mp4

I=-16是目标响度，单位 LUFS，网络视频一般用 -16 到 -14；TP=-1.5是最大真峰值，防止削波；LRA=11是响度范围。-c:v copy表示视频流直接复制，只重编码音频，速度快。

但loudnorm有个坑：它是单遍处理，对动态范围大的素材效果一般。更专业的做法是两遍处理，第一遍分析得到测量值，第二遍用测量值精确归一化。Claude Code 可以帮你把这个两遍流程写成脚本，自动解析第一遍的输出再拼第二遍命令。这个需求我提过一次，它给的方案是先用-af loudnorm=print_format=json -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(width=0.6, height=n/10, fill_opacity=0.8, color=BLUE) .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 报错速查表

5.2 批量脚本的三个保命习惯

第一个习惯是先干跑。在真正执行前，把命令里的ffmpeg换成echo，看看会执行哪些命令、文件名对不对。这个习惯帮我避免过好几次“把输出覆盖了输入”的惨剧。

第二个习惯是输出目录和输入目录分开。我见过太多人图省事直接原地覆盖，结果脚本跑一半出错，源文件已经没了。永远输出到新目录，确认没问题再删旧的。

第三个习惯是加日志。脚本里每个文件处理前后都echo一下，出错时能快速定位是哪个文件、哪一步挂了。配合set -x还能打印实际执行的命令，调试神器。

5.3 Claude Code 使用中的经验

Claude Code 很强，但不能当甩手掌柜。我的经验是：需求描述越具体，生成结果越靠谱。别说“帮我处理视频”，要说“把 input 目录下所有 mp4 转成 720p H.264，crf 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 里加新目标。这套组合用熟了，视频处理就从“体力活”彻底变成了“敲几行字的事”。