一个文件夹生成三个平台CSV：Adobe、Vecteezy、Dreamstime元数据自动化

卖图库素材最磨人的环节不是创作，是提交。同一批文件要变成三套表头完全不同的 CSV，而平台校验的第一关就是表头——错一列，整批打回。作者分享了自己从手动做表到脚本化管线的完整方案，核心逻辑是：把元数据当成代码的构建产物，而不是手工编辑的文档。

表头即关卡，必须当成代码来管

Adobe Stock 要 5 列，Vecteezy 要 4 列，Dreamstime 要 15 列。三家都会在任何人工或模型审阅之前直接拒绝错误表头，没有“部分得分”这回事。作者去年三月就吃过亏：120 行素材的表格多了第六列，粘贴进 Adobe 后直接解析报错，一条都没进审核。

问题根源在于用电子表格手工拼装。表格不是构建产物，而是静默错误滋生的地方。修复方式是写一个 make_metadata.py，把各平台的正确表头硬编码在脚本里，只输出这一种格式：

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

一个文件夹，三份 CSV，表头永远不会漂移，因为它不是打出来的，是代码里定死的。没有标题文件时脚本会回退到首字母大写的文件名，第一轮能用，但提交前应当替换——文件名不等于关键词。

CSV 表头校验：素材平台在接收批量上传（多为 CSV 或平台专用表格模板）时，会先做一次结构化解析，把文件当成数据表读入。这一步只检查列名、列数和顺序是否与模板完全匹配，不理解内容语义。因为它是整批文件进入审核队列的前置闸门，任何一列偏差都会让解析器整表失败——平台通常不会逐行容错，也不会给出“第几列错了”的友好提示，只会报一个解析错误。这也是为什么手工在 Excel 里拼表特别危险：合并单元格、隐藏列、尾随逗号、BOM 编码都可能让导出结果悄悄多出一列或改变列序。把表头写死在脚本里，本质上是让表结构成为版本可控的单一事实来源，而不是依赖人工复制的模板。

重复上架是最快的被标记方式

作者早期踩过一次坑：连夜重跑了一批任务，忘了其中一半已经上传过，结果重复文件堆进了审核队列。重复提交会让审核员对整个目录失去信任，而信任是小卖家账号唯一的资产。

解法很笨但有效：一个账本。upload_tracker.py 用纯文本文件记住哪些已经发布，只用标准库，不装依赖、不建数据库：

python upload_tracker.py pending items.txt
python upload_tracker.py done "asset-001.jpg"
python upload_tracker.py status

每次上传前查 pending，标记完成前查 status，重跑时已完成的自动跳过。作者的评价是：无聊的方案才是你真正会一直用下去的方案。

一套目录结构，别做成杂物抽屉

产品到四五十个之后，拖垮你的不是生成速度，而是找不到东西。整套管线假定这样的布局：

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

有一条规则是作者删过文件才学会的：research/ 永久保留。他曾经为了“清理”删掉笔记，结果花了一周重建已经做过的决策。抓取日志和笔记是下一季度产品的原材料。

小服务器上的生存习惯

整条管线跑在 1 vCPU、2 GB 内存、无 GPU 的机器上——这个约束对设计的影响比任何平台规则都大。几条实际管用的习惯：

• 一次只跑一个进程。单核上并行图片任务没有收益，只会 OOM。
• 每处理完一个素材调用 gc.collect()。这是稳定循环和跑到第 90 个崩溃之间的区别。
• 看峰值 RSS，不看平均值，用 resource.getrusage(RUSAGE_SELF).ru_maxrss 测量。平均值会掩盖天花板。
• 重的渲染步骤每个子进程只处理一个文件，内存才真正还给操作系统。
• 按需要的分辨率渲染。预览用 60 dpi 而不是 300 dpi，能省下大量那 2 GB 内存。

依赖方面只保留 Pillow（做封面）和 reportlab（做 PDF），其余全部标准库。在 2 GB 的机器上每多一个依赖，就是未来一次凌晨三点的排障。

峰值 RSS 与 ru_maxrss：RSS（Resident Set Size）指进程当前实际占用、驻留在物理内存中的页大小，不含被换出到磁盘的部分。Linux 上 resource.getrusage(RUSAGE_SELF).ru_maxrss 返回的是从进程启动至今的峰值 RSS，单位是 KB（macOS 上则是字节，跨平台时要注意换算）。之所以看峰值而不是平均值，是因为 OOM killer 触发依据的是瞬时高水位：一个任务平均只占 300 MB、但渲染某一步骤时飙到 1.9 GB，平均值完全看不出来，进程却会在那一刻被杀。记录峰值 RSS 能帮助定位具体是哪个阶段吃掉了内存，从而决定是否拆分步骤、降低渲染分辨率或改成每文件一个子进程。

为什么子进程能真正归还内存：Python 的引用计数和分代垃圾回收只能释放 Python 对象自身占用的堆内存，但图像处理、PDF 生成等操作常常在 C 扩展层（如 Pillow、reportlab 背后的库）申请大块缓冲区，这些内存在对象释放后未必立刻归还给操作系统，而可能留在进程的分配器里备用。因此长期运行的循环进程，RSS 会呈现只升不降的台阶状。把每个重任务放进独立子进程、处理完一个文件就退出，进程结束时操作系统会一次性回收其全部地址空间，这是唯一能保证内存真正回到系统的做法；主进程只负责调度和汇总，自身保持轻量。

包装本身就是一半的销量

带 1280x720 封面和 600x600 缩略图的压缩包卖得动，裸文件卖不动——作者说自己目录的销售数据能证明这一点。pack_product.py 一条命令完成打包和两张图渲染：

python pack_product.py my-product "My Product" "A short subtitle" 9

zip、封面、缩略图都写进 _system 文件夹，可用 --dir 或 PACK_ROOT 环境变量重定向，不需要改脚本，也没有按产品区分的配置。

这套东西的实际产出

这不是纸上谈兵。这些脚本产出了 39 个成品、856 MB 输出，来自一条约 19,000 行的父管线，背后是 300 多页关于平台规则的研究——脚本执行的就是这些规则，全部在同一台 1 vCPU / 2 GB 的机器上验证过。作者把完整方法（包括提示词引擎和贴纸细分市场部分）整理成了 ai sticker factory playbook。

对多平台卖家来说，可迁移的经验只有一条：提交环节的可靠性来自工程化，而不是自律。表头交给代码，重复交给账本，内存交给子进程，剩下的精力才轮得到创作。