上传测试数据就该这么造——AI + FFmpeg

先坦白：工具是 AI 选的，FFmpeg 命令是 AI 写的，Skill 是 AI 创建的，这篇文章是 AI 写的，Gitee 仓库也是 AI push 的。

我做的事情只有一件——把做上传测试时反复遇到的痛点，一句一句告诉 AI。然后看它花了不到两天，从噪点雪花屏迭代到 74 条用例全覆盖、Finder 十进制零失误、3.1GB 瘦身到 54MB。

万物皆可 AI。如果你也在被测试数据折磨，这篇文章里的东西直接拿走用。

为什么做这个

我负责的上传功能，支持的格式多、大小限制多、业务场景多。

测试时反复被问："封面图 <1MB 的有没有？""视频超过 200MB 的有没有？""背景音乐 <20MB 的有没有？""App Store 那个 1024×1024 的图标 PNG 给我一个。"

一开始还能翻本地素材库应付。后来要求越来越精细——要"刚好小于 5MB 但逼近边界"、要"Finder 里看起来也是小于 5MB 而不是四舍五入变成 5.0MB"、要"JPG/PNG/WebP 格式各一个的边界配对"。

手算分辨率与文件大小的映射关系，试参数，等生成，看 Finder，不满意再调。一次十几分钟，没法复用。

我把这些需求整理了一下，告诉 AI：帮我把这个流程自动化。

怎么搞出来的

AI 自己选了 FFmpeg 作为底层工具，然后我口述需求，它动手迭代。总共 7 个版本，每次解决一个问题。

v0.1 噪点时代

最早直接用 FFmpeg 的 geq=random(1)*255 生成雪花屏 + 正弦波 440Hz 纯音。

能用，但没法看。 测试文件虽然是真实编码，但全是噪点和蜂鸣声，没法给产品和设计确认。

v0.2 分形替代

改用 mandelbrot 分形图案和 life 生命游戏做内容源。比噪点好看了——但还是一眼就能看出是"算法生成的"，不像真实使用场景。

v0.3 铁律驱动

加入了一条铁律：直接推到编码器极限，不要分步试探。但很快发现了两个硬限制：

16383px 硬墙：mjpeg 编码器有像素上限。比如一张截图内容最多推到 4.14MB，永远到不了 5MB
DCT 噪声跳变：想用 geq 噪声突破极限，但 N=2.0 → 3.41MB，N=2.02 → 8.82MB，中间跳过了 5MB 目标

v0.4 素材觉醒 🎨

放弃生成，改用真实素材。

内置了 42 张真实照片（动物、猫、熊猫、风景 4 个主题）和 1 首 MP3（236 秒，9.9MB）。

音频素材用了蔡徐坤的《Deadman》——来源是网易云音乐下载的 ncm 文件，AI 写了解密脚本转出来的。仅用于生成测试音频数据，非商用。

图片：从素材库随机选一张 → 缩放/转格式/调大小
视频：照片轮播幻灯片 + 音乐音轨
音频：MP3 裁剪/拼接/转格式

视觉直接质变。生成的测试文件终于"看起来像真实用户上传的"。

v0.5 Finder 革命 🔍

这个版本发现了最隐蔽也最要命的 bug。

macOS Finder 使用十进制（1MB = 1,000,000 字节），且四舍五入到小数点后 1 位。而命令行 ls -lh 用的是二进制（1MiB = 1,048,576 字节）。

举个例子：

9,949,999 字节 → Finder 显示 "9.9 MB"  ✅ 小于 10MB
9,950,000 字节 → Finder 显示 "10 MB"   ❌ 看起来等于 10MB

之前一直按二进制思维做边界逼近。这意味着之前生成的所有"小于 N MB"文件，在 Finder 里可能都显示超限！

推导出 Finder 安全公式：

"小于 N MB" 安全值 = N × 1,000,000 − 50,000 字节
"大于 N MB" 安全值 = N × 1,000,000 + 50,000 字节

然后回头把所有 BMP/JPG/音频/视频的边界参数全部重算、重跑测。

v0.6 视频登顶 🚀

视频遇到新问题：幻灯片照片轮播内容压缩率太高，实际编码最多只到 ~81MB，到不了 100MB 以上。

解决方案：生成一个 base 段（75MB），然后用 FFmpeg 的 concat 无缝拼接：

base × 1 = 75MB    base × 2 = 150MB   base × 3 = 225MB
base × 4 = 300MB   base × 5 = 375MB   base × 6 = 450MB
base × 7 = 525MB

轻松覆盖 100MB ~ 500MB 全边界。

v0.7 打磨交付 🎯

最后的打磨：

双模式交付：常用文件预烘焙，0 秒复制即用；非常用文件按需生成
自愈验证：生成 → ffprobe 验证编码 → 计算 Finder 值 → 不通过自动微调重试（最多 3 轮）
空间优化：从 3.1GB 精简到 54MB，去掉了所有可即时生成的文件
测试用例：梳理出 74 条业界场景测试用例（App 图标、IAB Banner、闪屏、大小边界、格式兼容、安全测试）

最终成果

技能结构

test-media-factory/            (54 MB)
├── SKILL.md                   (16 KB)
├── picture/                   (28 MB, 42 张素材)
├── prebaked/                  (16 MB, 16 个边界文件)
└── music/deadman.mp3          (9.9 MB, 236s)

支持格式

类型	格式
图片	JPEG, PNG, BMP, WebP, GIF, TIFF
视频	MP4, MOV, MKV, WebM, AVI, FLV, WMV
音频	MP3, WAV, AAC, M4A, OGG

测试用例覆盖

一共梳理了 74 条测试用例，分三大类：

类型	条数	具体覆盖
图片	38	App 图标（iOS 1024×1024、Android 512×512）、Banner（IAB 标准 728×90/300×250/320×50）、闪屏（1080×1920）、大小边界（1/2/3/5/10MB 各一对）、格式兼容（GIF/TIFF）、安全测试（后缀伪装×4）
视频	24	大小边界（5/10/50/100/200/300/400/500MB 各一对）、多格式（MOV/MKV/FLV/WebM）、安全测试（后缀伪装×2 + 损坏 + 空文件）
音频	12	大小边界（3/5/10MB MP3+WAV 各一对）、格式兼容（AAC/M4A/OGG/FLAC）、安全测试（后缀伪装×2 + 空文件）

其中 23 对边界文件全部通过 Finder 十进制验证，确保 macOS 上"看起来正确"。

技术亮点

Finder 十进制安全：所有文件都确保在两者（十进制 Finder + 二进制命令行）下边界正确
真实编码：全部通过 ffprobe 验证，不是改后缀的伪装文件
自愈验证：不通过自动调参重试
大文件拼接：用 base 段 × N 方案突破编码器上限

怎么用

1. 装 FFmpeg

# macOS
brew install ffmpeg

# Windows
winget install Gyan.FFmpeg

2. 下载

git clone https://gitee.com/xpcs/skills-sharing.git

3. 用起来

"生成一张 <1MB 的 JPG"              → jpg_lt_1MB.jpg (540KB)
"生成 iOS App Store 图标 PNG"      → icon_ios_1024.png (1024×1024)
"生成刚好超过 200MB 的 MP4"        → mp4_gt_200MB.mp4 (225MB)
"生成 <5MB 的 MP3 背景音乐"        → mp3_lt_5MB.mp3 (~4.85MB, 110s)
"把这张 PNG 转成 JPG，小于 6MB"    → 自动推编码器极限 + Finder 验证
"生成 5MB 的所有图片格式边界文件"  → BMP/JPG/PNG 各一对，共 6 个文件

踩过的坑，供参考

Finder 那个坑

macOS Finder 是十进制显示（1MB = 1,000,000B），而且四舍五入到小数点后一位。我之前一直按二进制算，吃了大亏——

9,949,999 字节 → Finder "9.9 MB"  ✅ 小于 10MB
9,950,000 字节 → Finder "10 MB"   ❌ 看起来刚好等于 10MB

后来我定了条死规矩：

"小于 N MB" 安全上限 = N×1,000,000 − 50,000  字节
"大于 N MB" 安全下限 = N×1,000,000 + 50,000  字节

BMP 不用每次生成

BMP 是 W×H×3+54 字节，公式精确到字节。所以预烘焙直接砍掉了 BMP，需要时秒级算出来：

限制	方向	分辨率	文件大小	Finder
1MB	<	562×562	949 KB	"0.9 MB"
1MB	>	592×592	1.05 MB	"1.1 MB"
2MB	<	805×805	1.94 MB	"1.9 MB"
2MB	>	827×827	2.05 MB	"2.1 MB"
3MB	<	991×991	2.95 MB	"2.9 MB"
3MB	>	1009×1009	3.06 MB	"3.1 MB"
5MB	<	1284×1284	4.95 MB	"4.9 MB"
5MB	>	1298×1298	5.06 MB	"5.1 MB"

几个坑

MP3 别用 -fs，libmp3lame 的 VBR 不听话。用 -t + -c copy
WAV 别设 -b:a，这个参数对它没用。直接用 -t 算时长
AVI/WMV 编码器吃不了照片这种内容源，一用码率就飞
OGG 必须用 libopus，内置 vorbis 有 bug
别只信 ls -lh，它用的是二进制，跟 Finder 差 4.9%

代码

https://gitee.com/xpcs/skills-sharing

补充一些使用截图

我给技能装到马维斯

附：如何让 AI 帮你设计技能

整个过程中有一个交互思路对我帮助巨大，分享出来。

我当时的原话：

"如果是你，你针对我的诉求，会如何设计这个技能？开放思维，天马星空，头脑风暴，来上一波，然后再审视和评价一下当前的实现。"

AI 从三个维度给出了 8 个点子：

架构层：预烘焙 + 按需生成双模式、一键全量矩阵、自愈式验证闭环
体验层：视觉反馈、测试报告自动导出、渐进式交付
生态层：对接测试管理平台、CI/CD 集成

我挑中了其中三个觉得最实用的（预烘焙、自愈验证、视觉反馈），跟它说"执行"，它就落地了。

如果你也在做类似的工具或技能，试试这句提示词。比你自己闷头想要高效得多。

附：这个技能的评分

技能完成后，我让 AI 按 Agent-as-Judge 框架做了次评测：

维度	权重	评测内容	结果
功能正确性	30%	"生成<5MB JPG"，是否拿到正确文件	查表命中→0 秒交付 ✅
边界鲁棒	25%	极限请求：编码器上限、恶意输入	遇到极限告知用户 + 给出替代方案 ✅
指令遵循	20%	是否严格遵循 SKILL.md 工作流	预烘焙优先→查表→生成→自愈验证 ✅
输出质量	15%	Finder 双制验证、ffprobe 编码验证、视觉反馈	三项全部覆盖 ✅
Token 效率	5%	查表命中时是否过度推理	直接复制 + 输出对比 ✅
幻觉控制	5%	参数值、格式列表、边界值是否编造	全部来自实测对照表 ✅

总分 94/100

扣分项：

查表命中后输出模板偏长（-3）
缺少对"生成 0 字节"等恶意输入的防御描述（-2）
超过 50MB 的视频无视觉反馈（-1）

技能评测的思路不复杂：6 个维度，拆开就是"做的事对不对"、"极端情况崩不崩"、"有没有按规矩来"、"给的东西好不好用"、"花钱多不多"、"有没有瞎编"。

如果你也在做技能或者写 prompt，可以拿这 6 个维度试试给自己的东西打个分。测试人天然适合干这个——本质上就是"测试思维 × 产品敏感度"。

↙↙↙阅读原文可查看相关链接，并与作者交流