一段用手机拍的地图动画短片，要发到博客上，总得先压缩一下。独立开发者Simon Willison没有去翻FFmpeg的参数手册，而是让Claude Fable 5.1在Claude Code for web里直接给他写了一个网页工具：拖进原视频，勾选几个选项，浏览器自己跑完压缩，五个不同尺寸的版本11.8秒后全部生成完毕，最小的一份只有145KB，是原文件体积的48%。
这事有意思的地方，不是又出现了什么新的视频编码技术——压缩这一步从头到尾都是FFmpeg在干活，Claude只是把它裹进了WebAssembly，塞进了一个按钮里。
一次性需求，被一次性满足了
这个工具本身没打算长期维护，也没打算给别人用。Willison要做的事很具体：给一段动画短片同时生成大、中、小几个版本，方便挑一个塞进博客文章。他没去装命令行工具、没去记CRF参数该填多少，而是把这个需求原样讲给Claude，换回一个能用的网页界面：分辨率854×370或640×276可选，CRF画质从22到28分五档，音频码率128到64kbps，外加编码速度、H.264 profile、限制30帧、去元数据、去音轨、只截前10秒这些开关。
这套参数配置本来就是FFmpeg的标准菜单，会用的人早就烂熟于心。变化在于，不会用命令行的人，现在也能在几分钟内得到一个专属的可视化面板，而且用完就扔，不留一点历史包袱。
便捷的是壳，压缩能力还是那套老底子
习惯用命令行处理视频的人，通常有两条路：本地敲一遍ffmpeg -i input.mp4 -crf 23 ...，或者把文件传到某个在线压缩服务，等对方处理完再下载回来。前者门槛高，后者要上传原始文件，隐不隐私、传多久，都得看对方服务器。
Claude生成的这个工具，走的是第三条路：用WebAssembly把FFmpeg整个搬进浏览器里跑，界面上直接摆出可视化的参数表格，改完点一下按钮就出结果。这种模式确实省了敲命令和依赖外部服务两道手续，但具体是否完全在本地处理、有没有联网行为，取决于这个特定实现怎么写，不能因为用了WebAssembly就默认等于“绝不上传”。
- 结论.真正被压缩的不是视频码率，是把FFmpeg一套工作流封装成一次性工具的时间成本。
也不该把演示里的数字当成普遍性能基准。原视频本身是手机拍的短片，体积不大，11.8秒出五个版本、最小压到48%，说明的是这一类短视频在这套参数下的表现，换成几分钟长的素材或者手机端浏览器跑，速度和内存占用会不会撑住，目前看不到验证。
- 风险.演示样本小而短，不能直接推到大文件、长视频或移动端浏览器的普遍表现。
对经常要发短视频的独立开发者和内容作者来说，这类"临时工具"可能比装一整套本地压缩软件更划算——用一次就够，改天需求变了，再让AI重新写一个也不费事。这多少改变了"要不要学命令行"这个老问题的答案：现在也许不用学了，但底层的FFmpeg知识，仍然是那个让工具真正可控的东西。