一个Python脚本搞定Adobe、Vecteezy和Dreamstime的CSV元数据

批量上传素材到Adobe Stock、Vecteezy和Dreamstime时，最让人头疼的不是图片质量，而是那个永远对不上的CSV文件头。一位开发者分享了他的解决方案：用一套纯标准库Python脚本，从同一个素材文件夹生成三个平台各自要求的CSV，并且彻底解决重复上传的问题。

Building The Exact Adobe, Vecteezy And Dreamstime CSVs With One Python Script

三个平台，三种表头，一个根源问题

Adobe Stock要求五列，Vecteezy要求四列，Dreamstime要求十五列。同样的素材、同样的标题、同样的关键词，却要填写三种完全不同结构的表格。手动维护三份电子表格的结果就是：迟早会把错误的文件传到错误的平台，而平台的拒绝是即时且无声的——文件根本不会出现在你的作品集里。

作者编写的make_metadata.py接受一个输入：素材文件夹，然后输出每个平台要求的精确表头，不多一列不少一列。使用方式是通过--platform标志指定目标平台：

python make_metadata.py ./my-assets --platform adobe --out metadata.csv
python make_metadata.py ./my-assets --platform vecteezy --out vecteezy.csv
python make_metadata.py ./my-assets --platform dreamstime --out dreamstime.csv

脚本只依赖Python标准库，不需要pip install，没有任何第三方依赖。这一点比听起来更重要——当你的流水线运行在1 vCPU、2 GB内存、没有GPU的服务器上时，每一个依赖项都是潜在的故障点。

标题与关键词：诚实的默认值与真正的提交标准

如果没有额外输入，脚本会将文件名转为标题大小写后作为标题。这对第一次跑通流程来说够用，但作者明确强调：这不适合正式提交。三个平台的审核人员都能一眼看出标题只是文件名。

通过传入--titles titles.json参数，脚本会为每个文件读取真实的标题和关键词。作者建议将这个JSON文件放在素材文件夹旁边，在提交前填写完毕。默认值的存在是为了让流水线不会因为缺少数据而阻塞，但替换默认值是使用者的责任，不是脚本的。

图库平台的搜索排序高度依赖标题与关键词的语义匹配度。Adobe Stock 的标题建议控制在 70 个字符以内，关键词上限 49 个，且要求按相关性从高到低排列——平台算法会给予前 10 个关键词更高的权重。Vecteezy 和 Dreamstime 的字段约束各不相同，Dreamstime 的 15 列结构中还包含分类编号和模型授权等元数据。如果标题仅仅是把文件名如 IMG_2043.jpg 转成 Img 2043，审核员和买家都无法从中获取任何语义信息，素材即便通过审核，在搜索结果中也会因关键词缺失而几乎零曝光。因此 titles.json 不是可选项，而是决定素材能否被搜到的关键输入。

最容易被忽视却后果最严重的问题：重复上传

作者分享了一个代价高昂的教训：他重新运行了一个部分完成的批处理任务，导致多个素材被上传了两次。重复提交是引起审核团队注意的最快方式，一旦被标记，之后每一个批次都会受到更慢的审查。

解决方案是一个约四十行代码的台账工具upload_tracker.py，同样只用标准库：

python upload_tracker.py pending items.txt   # 还未完成的项目
python upload_tracker.py done "asset-001.jpg"
python upload_tracker.py status

在任何批处理运行之前，它先检查台账。重新运行时自动跳过已完成项。作者说，自从用了这个台账，再没有出现过一次重复上传。如果你从这篇文章中只带走一个工具，那就应该是这个台账脚本。

图库平台对重复提交的惩罚逻辑值得展开。Adobe Stock、Vecteezy 等平台的审核队列按账号信誉分配优先级，重复上传会被系统判定为「低质量账户行为」，导致该账号后续所有提交进入更慢的人工复核通道，审核周期可能从数小时延长到数天甚至数周。更严重的是，部分平台会对累计重复次数达标的账号直接冻结上传权限。台账工具的核心价值在于把「幂等性」引入了批处理流程：通过在提交前查询本地状态记录、提交后写回结果，让整个流水线可以安全地中断和重跑，而不必依赖人工记忆判断哪些素材已经处理过。这也是所有可靠数据管道的基本设计原则。

在2 GB服务器上跑完整流水线

整个流水线——包括这些脚本——运行在单核vCPU、2 GB内存、无GPU的环境中。让这件事可行的几个习惯：一次只跑一个进程，在单核机器上并行处理图片只会导致资源争抢；每个素材处理完后调用gc.collect()释放内存；用resource.getrusage(RUSAGE_SELF).ru_maxrss测量峰值内存而非平均使用量，因为峰值才是导致进程被杀的原因；对于重量级渲染步骤，每个文件用独立子进程运行，确保内存真正归还给操作系统；按需分辨率渲染，用60 dpi而非300 dpi检查预览可以节省大量内存。

元数据和追踪脚本是纯文本处理，在该环境下运行毫无压力。真正需要关注内存习惯的是涉及图片的脚本，比如pack_product.py中的封面渲染器。

resource.getrusage(RUSAGE_SELF).ru_maxrss 是 Python resource 模块提供的系统调用封装，ru_maxrss 字段返回进程自启动以来驻留集大小（Resident Set Size）的峰值，单位在 Linux 上为 KB、macOS 上为字节。之所以要监控峰值而非平均值，是因为操作系统 OOM Killer 判断是否终止进程时看的是瞬时峰值是否触及内存上限。在 2 GB 内存的机器上，一个平均只用 200 MB 但瞬时峰值冲到 2.1 GB 的脚本照样会被杀掉，而只看均值会完全掩盖这个风险。用法上通常在关键步骤前后各调用一次并取最大值，或封装成装饰器在函数退出时打印，这样能定位到具体是哪一步吃掉了内存。

打包才是销售真正发生的地方

一个带真实封面的压缩包能卖出去，一个裸文件卖不出去。作者通过对比发现：同一个星期、同样价格下，一个带有1280×720封面的产品销量超过了另一个没有封面的相同产品。

pack_product.py接受一个文件夹、标题、副标题和文件数量，输出三样东西：产品压缩包、1280×720封面和600×600缩略图。它使用Pillow处理图片，这是整个工具包中仅有的两个第三方包之一。另一个是reportlab，被md2pdf.py用来将Markdown文件转换为带标题、表格、列表和链接的样式化PDF。每个产品一条命令：

python md2pdf.py content.md product.pdf "My Product Title"
python pack_product.py my-product "My Product" "A short subtitle" 9

输出默认进入_system文件夹，可以通过--dir参数或PACK_ROOT环境变量重定向，无需修改脚本。

防止产品库变成垃圾抽屉的文件夹结构

整套工具假定以下目录结构：

project/
  assets/            原始输出
  output/            可提交文件 + metadata.csv
  packs/             成品压缩包 + 封面
  research/          笔记和来源
  scripts/           工具脚本

作者特别强调：永远保留research/文件夹。笔记和日志是未来产品的原材料。为了“清理”而删除它们是作者犯过一次但不会再犯的错误。

这套工具的实际产出背景

这四个脚本是一个更大流水线的打包层。该流水线共产出了39个成品、856 MB输出，来自约19,000行代码和300多页研究资料，全部运行在同一台1 vCPU、2 GB内存的机器上。作者并非先设计了脚本再期望它们能工作——他先遇到了失败：被拒绝的CSV表头、重复提交、裸文件卖不出去，然后为每一个问题编写了最小的修复工具。