上传测试数据就该这么造——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 个维度试试给自己的东西打个分。测试人天然适合干这个——本质上就是"测试思维 × 产品敏感度"。