8.0
热点
AI SCORE
编程提效2026-08-04 14:29
用AI生成FFmpeg命令的可靠方法
dev.to · AI#FFmpeg#AI编程#视频处理
Editor brief · 编辑速览
文章说明如何向AI明确视频处理目标与约束、检查生成命令的结果，并区分适合FFmpeg自动化和适合浏览器工具的一次性任务。重点覆盖批处理、服务端转码、CI资产生成等可重复场景。
AI 改变了许多开发者初次接触 FFmpeg 的方式。
过去，人们会先阅读文档、搜索 Stack Overflow，再逐个尝试各种参数。如今，工作流通常从这样一句话开始：
帮我写一条 FFmpeg 命令，把这个视频变小。
这并不是一个糟糕的起点。很多时候，它的效果出乎意料地好。
问题在于，FFmpeg 并不是一个“压缩视频”按钮，而是一套完整的视频处理工具箱。AI 可以快速给你一条命令，但你仍然需要弄清楚，自己究竟想让这条命令完成什么任务。
本文将从实践角度，介绍在 AI 辅助编程时代应该如何理解和使用 FFmpeg：什么时候可以让 AI 生成命令、需要为它提供哪些约束、如何检查处理结果，以及什么时候直接使用 VideoCompress 这样的浏览器工具反而更快。
当工作流需要重复执行时，使用 FFmpeg：
自动化视频处理
服务端转码
下周还要再次运行的脚本
当任务主要是为了交付时，使用基于浏览器的视频压缩工具：
需要发送的会议录像
体积稍微超标的产品演示视频
必须控制在上传大小限制以内的视频
需要快速交付给客户、同事或朋友的 MP4
当 AI 能够把你的意图转换成可测试的 FFmpeg 参数时，它最有用。如果只是让它猜测“把视频变小”究竟意味着什么，它的价值就没那么大了。
大多数糟糕的 FFmpeg 命令，都源于一个模糊的目标。
“把这个视频变小”至少可能代表四种不同的需求：
文件必须小于 25MB，才能通过电子邮件发送。
画质看起来应该几乎没有变化。
视频只用于移动端预览，因此 720p 就足够了。
视频只是用来发送聊天消息，音质并不重要。
这些是完全不同的压缩任务。
在让 AI 生成命令之前，先明确约束：
输入格式是什么？
输出文件将上传到哪里？
目标文件大小是多少？
什么最重要：画质、分辨率、音频，还是兼容性？
一个更好的 prompt 应该像这样：
Write an FFmpeg command to convert input.mov to output.mp4.
The goal is to upload it to a chat app.
The file should be around 25MB or smaller.
It is a screen recording, so small text must remain readable.
It can be scaled down to 1280px wide.
The output should play in common browsers and phones.
Explain each parameter and give me one conservative version and one smaller-file version.
重点并不是为了 prompt engineering 而做 prompt engineering，而是把压缩需求转化成明确的约束。一旦约束足够清晰，AI 就很难再生成那种虽然技术上能够运行、却解决了错误问题的命令。
如果你只是想得到一个兼容性良好的 MP4，可以先尝试下面这条命令：
ffmpeg -i input.mov -c:v libx264 -crf 23 -preset medium -c:a aac -b:a 128k -movflags +faststart output.mp4
几个关键选项的含义如下：
-c:v libx264 使用 H.264 视频编码，兼容性非常广泛。
-crf 23 控制视觉质量。数值越高，文件越小，画质也越低。
-preset medium 控制编码速度与压缩效率之间的平衡。
-c:a aac -b:a 128k 使用 AAC 编码音频，码率为 128 kbps。
-movflags +faststart 让 MP4 更适合在网页中播放。
这并不是一条完美的命令，但它是一个稳定的基准，因此非常适合用来进行 AI 辅助迭代。
例如，第一次运行之后，可以把结果反馈给 AI：
The output file is 82MB. I need it closer to 40MB.
The video is a screen recording, and text readability matters more than motion smoothness.
Suggest two versions: one that keeps more quality and one that prioritizes size.
这比反复说“再小一点”有效得多。
如果输出文件必须控制在特定大小以内，CRF 可能会让人觉得难以预测。此时，基于码率的方法更容易理解和控制。
target total bitrate in kbps = target size in MB * 8192 / duration in seconds
video bitrate in kbps = target total bitrate - audio bitrate
例如，一个时长 120 秒的视频，目标大小为 25MB，音频码率为 96 kbps：
target total bitrate = 25 * 8192 / 120 ≈ 1707 kbps
video bitrate ≈ 1707 - 96 = 1611 kbps
ffmpeg -i input.mov -c:v libx264 -b:v 1600k -c:a aac -b:a 96k -movflags +faststart output.mp4
如果希望文件大小更可预测，可以使用两遍编码：
ffmpeg -y -i input.mov -c:v libx264 -b:v 1600k -pass 1 -an -f null NUL
ffmpeg -i input.mov -c:v libx264 -b:v 1600k -pass 2 -c:a aac -b:a 96k -movflags +faststart output.mp4
在 Windows 上，NUL 是空输出目标；在 macOS 和 Linux 上，请使用 /dev/null。
会议录像、教程、代码演示和产品操作讲解，与相机拍摄的视频并不相同。
对于相机拍摄的视频，稍微柔和、模糊一点也许可以接受。但对于屏幕录像，如果小字号文字、菜单、代码或表格变得模糊，整段视频可能就失去了使用价值。
处理屏幕录像时，我通常会按以下顺序考虑压缩：
剪掉开头和结尾不必要的等待时间。
如果画面运动并不重要，把帧率从 60fps 降到 30fps。
保持足以清晰显示文字的分辨率。
谨慎提高 CRF。
在保持宽高比的同时缩放视频：
ffmpeg -i input.mov -vf scale=1280:-2 -c:v libx264 -crf 24 -preset medium -c:a aac -b:a 96k -movflags +faststart output.mp4
对于画面大部分时间都静止不动的 UI 操作演示，30fps 通常已经足够：
ffmpeg -i input.mov -r 30 -vf scale=1280:-2 -c:v libx264 -crf 24 -preset medium -c:a aac -b:a 96k -movflags +faststart output.mp4
只要明确告诉 AI，文字的可读性非常重要，它就能在这里帮上忙。
我推荐养成一个习惯：不要只让 AI 生成转换命令，也让它提供相应的检查命令。
ffprobe -hide_banner input.mov
ffprobe -hide_banner output.mp4
你不需要理解输出中的每一行。先检查几个基本问题：
视频 codec 是否符合预期？
音频 codec 是否符合预期？
分辨率是否发生了正确的变化？
视频时长是否正确？
文件大小是否接近目标？
这一步非常重要，因为视频命令可能会“悄无声息”地失败。命令也许顺利运行了，但音频不见了；文件也许变小了，但文字已经无法辨认；输出文件也许能在本地播放，却无法在浏览器中打开。
AI 能让命令生成得更快，而验证能确保它给出的结果值得信任。
FFmpeg 非常强大，但这并不意味着我愿意为了每个视频都打开终端。
我只有一两个文件需要处理。
我只是需要把视频发送到某个地方。
我不想向其他人解释一条命令。
我正在使用一台没有安装 FFmpeg 的机器。
目标仅仅是“让这个文件可以上传”。
我希望设置目标大小，然后直接下载结果。
在这些场景中，我会把 VideoCompress 当作一个实用的快捷方案。
它的工作流很简单：上传视频，选择压缩目标或参数，等待处理完成，然后下载压缩后的文件。对于一次性的交付任务，这可能比安装 FFmpeg、让 AI 生成命令、测试参数，再不断重复这一过程更快。
它尤其适合处理会议录像、课程片段、产品演示、社交媒体草稿和用于快速评审的视频。在这些场景中，真正的目标通常不是“构建一套完美的编码流水线”，而是“发送一个能够正常打开，并且效果足够好的视频”。
当然，如果文件包含客户数据、内部会议内容、尚未发布的产品界面或任何敏感信息，那么在把文件上传到在线工具之前，必须遵守团队的安全规范。如果任务要求完全在本地处理、保留审计日志或实现后端自动化，就应该使用 FFmpeg。
这并不是在比较哪一种工具更加“专业”，而是要看任务本身属于什么类型。
AI vibe coding 让 FFmpeg 变得更容易使用，但也让人更容易跳过必要的思考。真正节省时间的关键，是判断这个任务是否值得投入工程化成本。
如果你只是需要交付一个方便分享的视频，浏览器工具可能就足够了。
如果同一套工作流需要重复执行 50 次，就让 AI 帮你把 FFmpeg 命令封装成脚本。
下面是我通常采用的工作流：
描述目标：谁会观看视频、视频将上传到哪里、目标文件大小是多少，以及文字是否必须保持清晰可读。
让 AI 提供 2～3 条候选命令，而不是只给一条。
使用 ffprobe 检查输入和输出文件。
先用一段 10～30 秒的样本进行测试。
只有在样本效果符合预期后，才处理完整视频。
创建一段 30 秒的样本：
ffmpeg -ss 00:01:00 -i input.mov -t 30 -c copy sample.mov
然后在样本上测试压缩参数。这比每次都重新编码完整视频快得多。
FFmpeg 并不会因为 AI coding 的出现而过时，它只会变得更容易使用。
但该做的工作仍然少不了：理解约束、选择正确的取舍，并验证输出结果。
工程问题使用 FFmpeg。
交付问题则使用最快、最可靠的工具。
对我来说，VideoCompress 正好属于第二类。当我不需要一套长期使用的视频处理流水线，只想把视频压缩到便于分享的大小时，它通常是更轻量的选择。
如需采取进一步措施，可以考虑屏蔽此人和/或举报滥用行为。