前面在弄一批视频素材加起来二十多G平台上传限制卡得死得在不翻车的前提下把体积压下来。以前这种活我都是临时翻命令、复制粘贴改参数这次换了个思路把需求直接丢给 Claude Code for web 里的 Claude Fable 5.1让它帮我构建一个 FFMPEG 视频压缩工具。整个过程比预想顺一些但坑也没少踩。这篇把我从需求拆解、FFMPEG 参数选型到工具落地、实测排错的全过程都写下来给正在折腾视频压缩、或者想试试让 AI 写命令行工具的朋友做个参考。1. 先说清楚为什么要让 AI 来写 FFMPEG 工具1.1 视频压缩真正的痛点不是命令记不住而是参数组合太乱很多人以为视频压缩难在记不住命令其实不是。FFMPEG 这玩意儿的官方文档你查一下就知道了命令结构本身并不复杂真正让人头大的是参数组合的排列混乱。同一个输入文件你要考虑编码器选 H.264 还是 H.265、画质用 CRF 还是固定码率、编码速度选哪个 preset、音频是保留原样还是重编码、字幕要不要带走、封装格式是 mp4 还是 mkv……每一个选项单拿出来都有人写过文章但放到一起的时候几乎没有哪篇教程能告诉你你现在这个场景到底该用哪套组合。更难受的是FFMPEG 出错方式非常安静。很多时候命令跑完了、文件也生成了肉眼一看画面还行但细节早就丢了或者字幕没了、旋转信息被忽略了等到交付阶段客户反馈出来才知道出事。这也是为什么我一直觉得视频压缩的本质不是跑一条命令而是在一堆互相制约的参数里做一个合理的折中。1.2 Claude Fable 5.1 在 Claude Code for web 里适合干什么活这次我用的组合是 Claude Code for web 网页环境里跑 Claude Fable 5.1。它的工作方式跟我以前用的拿 ChatGPT 问一句然后复制代码不太一样它不是只甩给你一段代码就完事而是可以在项目上下文里持续对话、改文件、跑命令、读报错然后基于结果继续调整。放在构建 FFMPEG 工具这个场景里这个循环特别值钱。因为我需要的不只是一条 ffmpeg 命令而是一个能反复使用、能处理批量文件、能对异常做处理的小工具。这类工具的特点是需求细节多、边界条件多、测试反馈多。恰好是 AI 辅助编程比较擅长的领域。当然我并没有天真到把所有事都丢给它。FFMPEG 的底层参数、编码器特性这些AI 容易一本正经地给出一套看起来没问题的命令但实际跑出来好不好还得靠自己心里有数。所以我在开工前先自己补了一遍 FFMPEG 的基础知识这个咱们放到下一节说。2. 开工前的 FFMPEG 知识清单压缩的本质是折中2.1 编码器怎么选H.264 保守、H.265 均衡、AV1 激进这一步直接决定压缩效率和兼容性也是 AI 最容易给错建议的地方。我这次整理了一张对照表按实际使用场景排序编码器典型 FFMPEG 实现压缩率编码速度兼容性适合场景H.264libx264基准快极好几乎所有设备和平台都认识交付给客户、平台上传、日常使用H.265 / HEVClibx265比 H.264 高约 40%-50%较慢近几年设备基本支持老设备可能黑屏个人存档、可控播放环境的批量压缩AV1libsvtav1 / libaom-av1比 H.264 高约 50% 以上很慢软件编码尤其明显浏览器基本支持但剪辑软件和旧播放器不一定长期归档、对文件体积极度敏感我这次压缩的是要上传平台的视频平台那边 H.264 兼容性最稳所以主体视频走 libx264。生成一部分高清但体积尽量小的版本给朋友看时试了 H.265压缩率确实香但对方设备如果旧一点就容易出问题。AV1 我也在测试机上试过画质/体积比确实是最猛的那个但编码耗时实在太长不适合批量赶工。2.2 CRF、preset、分辨率、码率四个参数的联动关系选完编码器接下来是四个绕不开的参数。AI 生成的命令里一定会有它们如果你自己不懂出问题的时候根本没法判断该动哪个。CRFConstant Rate Factor恒定质量因子范围 0-51数字越小画质越好、文件越大。H.264 的默认值是 23日常压缩我习惯用 20-23追求小体积可以拉到 26-28超过 30 就要小心了后面我会讲踩坑经历。CRF 的好处是它面向质量而不是体积画面复杂的地方自动用更多码率静态场景自动省码率。preset控制编码器的速度和效率权衡从 ultrafast 到 veryslow。用同一个 CRF 的情况下preset 越慢同画质下文件越小但编码耗时成倍增加。我一般用 medium 或 slow 就够不要一上来就 veryslow文件压到一半才发现太慢很尴尬。分辨率所有提升压缩率的手段里降分辨率是最立竿见影的但代价是损失细节。如果是 4K 素材要压缩后放在手机上看缩到 1080p 完全没问题如果要保留在大屏剪辑的余地就别动分辨率。码率当你明确目标文件必须小于某个大小时就得用固定码率或二压估算。日常单次压缩我更推荐 CRF preset 的组合省心且质量可控。这四者的关系说白了就是一句话CRF 把住质量下线preset 决定压缩效率分辨率和码率决定最终文件的体量天花板。我在让 AI 写脚本之前先把这几个参数的取值区间定死后面它生成的命令基本不会跑偏。3. 在 Claude Code for web 中从零搭建压缩工具3.1 第一轮对话把需求描述清楚比会写代码更重要刚开始在 Claude Code for web 里打交道我犯了一个很多人的通病直接上来一句帮我写一个视频压缩脚本。它确实会给一个脚本但那是通用得不能再通用的版本跟我的文件命名规则、目录结构、平台限制完全不搭。第二次我学乖了把需求当成一份需求文档来写包含这么几个要素使用场景本地素材往平台上传平台单文件限制 4G需要把体积压到 3G 以内。输入输出源文件在E:/source/下可能是 mp4、mov、mkv 混合输出统一放E:/compressed/文件名加_compressed后缀。硬性约束编码器用 libx264分辨率不改音频重编码为 AAC 128k去掉原始字幕轨道。异常要求碰到损坏文件或编码失败脚本不能中断要跳过去并记录日志。把这些写进提示词之后Claude Fable 5.1 第一次给出来的脚本就已经能用了。这也是我想提醒的给 AI 的信息颗粒度决定了它产出物的可用度。你描述的场景越接近真实它写出来的东西越能落地。3.2 生成压缩脚本从单文件到批量逐步收敛第一版脚本是 Python 的逐行执行 ffmpeg 命令逻辑很朴素import subprocess import sys input_file sys.argv[1] output_file input_file.rsplit(., 1)[0] _compressed.mp4 cmd [ ffmpeg, -y, -i, input_file, -c:v, libx264, -preset, slow, -crf, 23, -c:a, aac, -b:a, 128k, -map, 0:v:0, -map, 0:a:0?, output_file ] result subprocess.run(cmd, capture_outputTrue, textTrue) if result.returncode ! 0: print(编码失败:, result.stderr[-500:]) else: print(完成:, output_file)注意这里几个细节是它根据我的约束自己加上去的-map 0:v:0指定只保留第一条视频流-map 0:a:0?表示如果存在音频流就保留下一条、没有也不报错。这个?是可选的标记处理音轨缺失的素材时特别好用。不过单文件版本只是热身。我真正需要的是批量直接遍历目录里所有视频文件。这一轮迭代也很快我把目录结构和失败不中断的要求再强调一遍它就把主流程改成了os.scandir()循环。3.3 加上进度显示、输出目录和参数白名单批量版本跑通之后我又提了几个加分项输出目录自动创建不要跟源文件混在一起避免重复压缩。跳过已存在的文件中断之后重跑不会把已经压过的再压一遍。编码失败的记录收集失败的源文件名和错误摘要统一输出到error.log。这部分 Claude Fable 5.1 处理得不错但我拿到代码之后还是自己加了一层参数白名单校验。原因是我吃过亏如果脚本里不小心混入一个错误参数FFMPEG 可能不报错、只是悄悄忽略某些选项导致输出格式不对。所以我在脚本里维护了一份允许出现的参数集合凡是不在名单里的参数一律拦截。这个习惯是我后来强烈建议大家保留下来的尤其是让 AI 写代码的时候。补完这些工具已经具备能给我干活的状态了但真正让它成熟起来的是接下来那段实测排错的过程。4. 实测踩坑全记录这些问题不实际跑根本发现不了4.1 ffmpeg 不是内部或外部命令环境变量坑了我半小时第一轮测试直接在 Windows 上跑Python 脚本一执行就报了个眼熟的错误ffmpeg 不是内部或外部命令。这个错大多数人都遇到过本质是系统在环境变量 PATH 里找不到 ffmpeg 可执行文件。但这里有个隐藏细节很多 FFMPEG 教程只说了下载解压和配置 PATH却没告诉你配置完之后必须关掉当前终端重新开一个。我当时改了 PATH 后继续用原来的命令窗口跑自然还是报错白白浪费了十几分钟。验证是否配好了就一条命令ffmpeg -version能打印出版本号就是成功。另外如果不想动系统全局 PATH也可以直接在脚本里写死 ffmpeg 的完整路径或者放到项目目录下用相对路径引用这样换机器也不受影响。顺带说一句如果你用的系统本身没有 ffmpeg那就得先装。Windows 上可以下载官方编译的静态包解压使用Linux 上apt install ffmpegmacOS 上brew install ffmpeg装完同样先跑ffmpeg -version确认。4.2 字幕流和旋转信息被静默丢弃一条 -map 参数救回来第一版脚本我特意要求去掉字幕轨道但压完第一批文件后我拿ffprobe检查输出发现不止字幕没了连原始文件里的旋转元数据也没了。原因是 FFMPEG 默认行为在作祟当你只指定-map 0:v:0 -map 0:a:0?时电影容器里除视频和音频之外的其他轨道会被忽略。mkv 里常见的字幕流、封面图mxf 里的时间码全是这种情况。如果确实不需要丢掉没问题但有些视频在手机上加过旋转信息FFMPEG 压完后默认可能不会保留这个元数据变化导致输出画面方向不对。解决办法分两种情况想保留元数据在命令里加-map_metadata 0把源文件的全局元数据带过去。想保留字幕轨道把-map 0:s?加进去但要注意 mp4 容器对字幕格式支持有限遇到 ass 特效字幕要么转成 mov/text要么干脆烧录进画面。这轮给我的教训是压缩不只是压画面和声音流选择是一个独立的决策维度。我第一次从家里拿出这套心得来用是在一次集合多语言音轨的视频里差点把配音轨丢掉还好检测得早。4.3 CRF 拉太高之后静态画面出现块状噪点批量压缩到一半我发现有个视频体积特别小比同类的都小。直觉告诉我不对劲。拉出来一看果然暗部场景出现了明显的色块和带状噪点尤其是渐变天空和会议室深色背景的部分。原因是我为了压体积把这个文件的 CRF 调到了 30同时 preset 用了 fast。CRF 30 本身在 H.264 里就已经偏高遇到高噪点或暗部渐变素材编码器会为了省码率把细节一刀切于是出现 banding带状断层。这件事让我重新理解了 CRF 的质量恒定含义CRF 恒定的是感知质量的主观目标不是客观的画质保证。同一个 CRF 值高码率素材和低码率素材的结果差异巨大。解决方案是三层CRF 设回 23preset 用 slow能明显改善暗部色块。对确有大量暗部场景的素材可以用滤镜做轻量降噪比如-vf hqdn3d但要注意过度降噪会让画面发肉。永远先用一小段测试再跑全量。用-ss 00:05:00 -t 30截取 30 秒片段试压检查画质和体积觉得没问题再放开跑整批。这个习惯帮我省下无数次返工。4.4 另一个隐藏坑压完的文件播放器打不开还有一个问题差点漏掉。某个 mov 源文件里视频用了 ProRes 编码音频是 PCM压缩时我指定了 libx264 加 aac看着没问题但生成的 mp4 在某个老版本播放器里打不开报无法解码。排查下来发现问题出在音频上FFMPEG 默认会用-c:a aac但只要你的 FFMPEG 编译版本里没有原生 AAC 编码器它可能会退回别的实现或者在某些封装组合下签名不标准。解决方式是在命令里显式写明音频编码器名称常用的几个-c:a aac主流 mp4/mov兼容性最好。-c:a libmp3lame输出 mp3 音频老设备兼容性好。-c:a libopus网页播放首选Opus 压缩效率高但封装别用 mp4。同样视频编码器也建议显式写libx264而不是只写h264避免不同 FFMPEG 构建版本解析不一致。5. 把工具变成多面手转格式、裁片尾、压缩音频、录屏5.1 m3u8 转 mp4 和时间精准裁剪工具跑顺之后我开始往里加些高频场景。第一个是 m3u8 转 mp4。现在很多平台给到的下载链接其实是 HLS 流一堆.ts分片配一个playlist.m3u8索引。直接对单个 ts 文件操作没意义要对整个列表操作ffmpeg -i https://example.com/path/playlist.m3u8 -c copy -bsf:a aac_adtstoasc output.mp4-c copy是流复制不做重编码速度极快。但有个前提如果源分片的编码格式跟 mp4 容器不兼容还得走重编码。另外如果流内容是加密的需要确保 FFMPEG 能拿到密钥否则会报 403 或者解密失败。另一个高频需求是精准裁掉片尾。很多人习惯把-ss放在-i后面这在精确裁剪场景有两个毛病-ss在-i之后是解码到指定时间点再输出操作慢。对关键帧间隔大的视频位置不精确。正确做法是把-ss放到-i之前实现快速定位ffmpeg -ss 00:57:30 -i input.mp4 -t 00:02:30 -c copy output.mp4这里-t 00:02:30表示从定位点开始取 2 分半钟。如果只想去掉片尾而不知道片长先拿 ffprobe 查时长ffprobe -v error -show_entries formatduration -of defaultnoprint_wrappers1:nokey1 input.mp4拿到总时长后用脚本算好-ss的时间点就能自动批量裁掉固定长度的片尾了。这个逻辑看起来简单但里面藏着关键帧对齐的问题稍微说明一下就明白了。5.2 音频压缩与录屏场景的参数补充音频压缩其实是视频工具的自然延伸。我有时候只是想把一个几百 MB 的音频文件压小一点FFMPEG 一条命令就能搞定ffmpeg -i input.wav -c:a libmp3lame -q:a 2 output.mp3-q:a 2是 LAME 的质量等级范围 0-9数字越小质量越好文件越大。日常分享用-q:a 2或-q:a 3够用文件体积和音质相对均衡。如果走 AAC码率给 128k 到 192k 都比较稳妥。录屏这块不同系统的采集方式不一样我之前在这个问题上卡过Linux 桌面-f x11grab -i :0.0抓整个屏幕或者-f x11grab -video_size 1920x1080 -i :0.00,0抓指定区域。Windows-f gdigrab -i desktop抓桌面-f gdigrab -i window_title 窗口名抓特定窗口。macOS-f avfoundation -i 1:0之类设备索引用ffmpeg -f avfoundation -list_devices true -i 查。录屏之后接压缩正好就是前面工具的主场先把 raw 录屏压成 H.264 AAC 的 mp4体积能缩到十分之一以下。说到提高视频清晰度我得说句公道话FFMPEG 能把不清晰的视频做到看起来更锐利但没法无中生有地恢复丢失的细节。常见的操作是结合scale放大后用锐化滤镜稍微找补比如ffmpeg -i input.mp4 -vf scale1920:1080:flagslanczos,unsharp5:5:0.6:5:5:0.0 -c:v libx264 -crf 20 output.mp4但这类操作只是让边缘观感更清晰本质上没有新增信息。真想小而清楚还是在录制和初次编码时就用高一点的质量后面压缩才有空间可挤。6. 收尾心得AI 写工具的正确姿势6.1 我给 Claude Fable 5.1 提需求的固定套路经过这一轮完整实践我慢慢总结出一套跟 AI 协作写工具类脚本的固定流程分享出来供参考先描述场景再描述命令。不要上来就说给我写个 ffmpeg 脚本而是说明你在什么场景下用、输入是什么、输出希望是什么、有什么限制。一次性说清边界条件。比如文件名可能含空格、目录里可能有非视频文件、有的素材没有音轨。这些边界条件你不在第一轮说它生成的脚本大概率不考虑后面改来改去反而更花时间。让它自己解释关键参数。我会要求它把每个关键参数的作用和推荐范围写进注释一方面是帮我核对另一方面以后自己修改也方便。要求它给出测试方案。直接问我怎么快速验证这个脚本输出质量对不对它通常会给出用-ss截片段测试的建议这个建议很实用。迭代而非一次成型。第一版能跑通就行后面通过贴报错、贴 ffprobe 检测结果来逐步修正。把测试输出喂回去比你自己白话描述画面有问题有效得多。这套流程的本质是把 AI 当成一个上手很快、但容易想当然的初级工程师。你有责任把验收标准说清楚也有责任在它给方案时做技术兜底。6.2 哪些参数必须自己确认不能全信 AI最后说点掏心窝的话。AI 生成的 FFMPEG 命令里有几个点我从来不敢直接信一定会自己核对编码器可用性你本机的 FFMPEG 编译版本里有没有libx265、libsvtav1、libopusAI 并不清楚最好用ffmpeg -encoders自己查一遍。目标播放环境AI 不知道你的视频要发到哪个平台、哪些人用什么设备看。兼容性判断只能由你做。音频质量下限AI 默认给的 128k AAC 在一般场景够用但如果原始素材是高质量音轨压完会有明显差距。对音频敏感的素材我会手动提一档到 192k 甚至 256k。原片保留任何压缩都是有损的压缩前一定要保留原始文件等所有输出验证完毕再决定是否删除。这个习惯救过我太多次了。整套工具跑下来现在压缩一个小时的 1080p 视频大概能比原来少一半体积画质在正常观看距离下几乎看不出差别。最大的收获倒不是省了多少硬盘而是我建立了一套让 AI 干活、自己把关的路子后面再遇到格式转换、片头片尾裁剪、音频处理这些杂活都能很快把工具扩展出来用。如果你也想折腾类似的东西我的建议是从最小的场景开始挑一个真实文件先手动跑通单条命令再让 AI 帮你打包成批量工具最后一定要拿真实素材测试一遍。视频处理这个领域所有参数变化最终都得落到你用眼睛看的画面上AI 可以帮你把路铺平但方向盘还是得你自己握。