一周一晚搞定素材上传：元数据、封面与防重复投稿自动化

数字素材卖家最怕的不是没灵感，而是重复劳动和重复投稿。一位开发者分享了他的亲身经历：上周二，他因为记不清哪些文件已经上传，差点把同一批40个文件再次推送到Adobe。Adobe不会警告重复，而是直接记入审核不良记录——重复提交已发布素材是账户被标记的明确原因之一。他及时发现了，但靠的是手动翻上传历史。那天晚上他决定：追踪必须靠脚本，不能靠记忆。

元数据CSV：表头是硬性门槛，不是建议

三大素材平台对元数据文件的表头要求极为严格。Adobe要求5列，Vecteezy要求4列，Dreamstime要求15列。格式错误不会得到温和提示，而是直接在上传时被拒。手工在表格里拼凑，迟早会列顺序错乱或分隔符不对，整批文件被退回。

作者的解法是 make_metadata.py：指向一个文件夹，选择平台，生成符合该平台表头要求的CSV。如果没提供标题文件，它会自动将文件名转为标题格式——但作者提醒，提交前仍需替换这些自动标题，因为审核员真的会看。

时间账很直观：以前手动为40个素材构建三个平台的CSV要花掉大半个晚上，现在只需三条命令和约一分钟的计算。

重复投稿是账户被标记的最快路径

自动化上传最常见的错误，就是对同一渠道重复运行同一批任务。素材网站将重复提交视为质量问题，累积多了就会触发账户审核或限制。作者的修复方案简单到不会出错：upload_tracker.py 是一个纯文本账本。批次开始前运行 pending 查看未完成项，每次成功上传后标记 done。重新运行批次脚本时先检查账本，重复投稿从“不太可能”变成“结构上不可能”。

他的建议很直接：不要建数据库，建一个你不可能误读的列表。整个上传历史就是一个记事本文件，可读、可备份、可grep。

为什么素材平台把重复提交当作质量问题

素材库的搜索排序高度依赖“新素材质量信号”：审核通过率、被拒原因分布、同一账户的重复率都会进入风控模型。同一文件二次提交不仅浪费审核人力，还会被判定为“刷库”行为——账户的通过率被拉低，后续所有上传进入更慢的人工审核队列，严重时触发上传权限限制或账户冻结。

更隐蔽的风险是近似重复：同一素材的不同分辨率、轻微调色版本在感知哈希层面高度相似，也会被归入重复族。因此账本除了记录“已上传”，还应记录素材的标识（文件名 + 内容哈希），才能在改名前重跑批次时依然拦住重复投稿。纯文本账本之所以够用，正是因为一行 hash filename platform date 就足以完成这个判断。

2GB小内存机器的纪律：串行、及时回收、按需渲染

整条流水线运行在1核CPU、2GB内存、无GPU的服务器上。这个约束塑造了所有操作习惯。

• 永远不要并行展开图像任务：单核上并行不会更快，反而更慢并压垮机器。
• 每个素材后调用 gc.collect()：在项目之间释放内存。
• 重渲染步骤使用子进程：每个文件一个子进程，让内存真正归还给操作系统，而不是在Python内部池化。
• 测量峰值RSS而非平均值：用 resource.getrusage(RUSAGE_SELF).ru_maxrss，因为平均值无法告诉你任务崩溃那一刻发生了什么。
• 按需分辨率渲染：预览检查用60dpi而非300dpi，检查成本几乎为零；只有最终输出才支付全分辨率成本。对于按图计费的AI图像生成，因为高分辨率检查失败而重渲整批，是真实成本而不仅是理论上的。

峰值 RSS 与 ru_maxrss

RSS（Resident Set Size）指进程当前实际占用物理内存的字节数，而 ru_maxrss 记录的是进程自启动以来的峰值常驻内存。之所以测峰值而非平均值，是因为 OOM（内存不足）杀死进程只看瞬时峰值：一个平均占用 300 MB、却在某一帧解码 3000x3000 图像时冲到 1.9 GB 的任务，平均值看起来完全安全，却恰好会在那一刻被内核终止。

需要注意单位陷阱：Linux 上 resource.getrusage(RUSAGE_SELF).ru_maxrss 返回的是千字节（KB），macOS 上则是字节，跨平台脚本若直接除以 1024² 会得到差 1024 倍的结果。在 2GB 机器上，把这条数字打进日志、每个素材一行，就能在崩溃前看到内存爬升趋势，而不是事后对着一段 traceback 猜测。

gc.collect() 与子进程为何能真正还内存

Python 的引用计数会在对象失引用时立即释放，但循环引用只能靠分代垃圾回收器处理，因此长时间运行的批处理进程会出现 RSS 只涨不降的“高水位”现象。每处理完一个素材显式调用 gc.collect() 可以回收这批循环引用，把内存压回基线。

但更彻底的手段是子进程：CPython 释放的内存往往不归还操作系统，而是留在 pymalloc 的内部池中供后续复用。子进程退出时，内核会一次性收回其全部地址空间，这是唯一能让 RSS 真正下降的方式。代价是进程启动开销和无法共享缓存，因此只在重渲染这类“单次占用巨大、调用次数有限”的步骤上使用，批量轻量任务仍留在主进程内。

包装是命令，不是手工活

光秃秃的文件卖不出去。一个带1280x720封面和600x600缩略图的zip才是产品。作者以前每个产品花30到45分钟在图像编辑器里做封面，39个产品就是整整一周的业余时间。

pack_product.py 接收文件夹、标题、副标题和项目数，直接输出zip、封面和缩略图，唯一第三方依赖是Pillow。他的观点很实在：封面不是艺术，是一致性框架，而一致性正是脚本擅长的事。

文档同理。md2pdf.py 用reportlab把Markdown转成带标题、表格、列表和链接的样式化PDF。一条命令。文档看起来像产品，是因为样式固定，而不是因为晚上11点还有审美。

文件夹结构比工具更重要

没有固定结构，目录会变成垃圾抽屉。他的五层结构是：assets 放原始输出，output 放可提交文件和元数据，packs 放完成的zip和封面，research 放笔记和抓取日志，scripts 放工具。

他早期犯过一个错误：清理时删掉了 research 文件夹。那些笔记和日志是未来产品的原材料。他重建了能恢复的部分，现在该文件夹里的东西永不删除。

一周一晚的真实节奏

一个晚上，约三小时。生成本周素材并审核，运行三条元数据命令，用 pending 检查账本，打包两到三个产品，全部标记完成。脚本至今已打包39个产品，约856 MB输出，全部跑在那台2GB服务器上。整个父流水线约19000行代码，但日常需要的打包层只有四个脚本和两次pip安装。

作者不假装这是全自动生意：审核员仍会拒绝，标题仍需重写，有些周他完全跳过这个晚上。但上周二那个因为忘记而重复跑批次的失败模式，现在在结构上已经不可能了。

四个脚本、文件夹布局和内存笔记被打包成入门套件，理由是：打包层是拖住所有人的无聊部分，不该花一年才搞对。