一套素材卖三份：打包脚本让库存上传、产品包与渲染图自动化

手工打包素材的痛点很具体：画完了30个资产，却卡在压缩、截图、填CSV上，一个列数错误就被平台秒拒。本文作者的经历是很多独立创作者的缩影——创作能力不缺，缺的是把同一份作品变成三种可售形态的“打包层”。

为什么一份资产要卖三次

同一批作品可以拆成三种产品形态，每种形态的包装要求完全不同：

1. 图库上传（Stock uploads）：单个文件加平台指定格式的元数据CSV。Adobe Stock要求5列表头，Vecteezy要求4列，Dreamstime要15列。表头错了，审核员连作品都看不到就直接驳回。作者就是因为给Adobe模板写了6列而整批报废。
2. 产品包（Product packs）：把相关文件压成一个zip，在Gumroad或自有站点整包出售。这需要一张一眼能读懂内容的封面图。
3. 列表渲染图（Listing renders）：1280x720的封面和600x600的缩略图。买家实际看到的就是这两张图。作者的第一条商品没有任何预览图，挂零收场。

三种形态共用同一个资产文件夹。把这三件事当成分开的手工活，才是真正的时间黑洞。

元数据CSV是图库平台用于批量上传的表格文件，每一行对应一个资产，列则包含文件名、标题、关键词、类别等字段。不同平台对列的数量、顺序和表头名称有严格规定，因为上传器会直接按列索引解析数据。例如Adobe Stock要求5列（文件名、标题、关键词、类别、释放信息），Vecteezy要求4列，Dreamstime则多达15列。一旦表头不匹配，系统无法定位字段，就会在人工审核前直接拒绝整批文件。因此，元数据生成本质上是格式适配问题，而非文案创作问题，用脚本按平台模板输出是唯一可靠的解法。

元数据是格式问题，不是文案问题

平台对CSV表头没有任何商量余地。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

脚本遍历文件夹，把文件名转成标题大小写后写入行。如果手头有真实的titles.json，可以传入标题和关键词；没有的话，一次通过用文件名凑合，但提交前务必替换掉。这个脚本只用Python标准库，不装任何依赖，一个平台一条命令，表头从此不可能再错。

重复上传是最快的封号方式

作者特别强调这一点：同一批资产对同一平台重复提交，是触发账号审查的已知信号。一旦自动化，重跑不是“如果”，而是“什么时候”——定时任务多跑了一次、忘了某批已经发布，都是常见场景。

upload_tracker.py就是一个极小的账本：

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

它记住已经发过的内容，重跑时自动跳过已完成项。同样只用标准库，大概一百行代码，是整条流水线里最不起眼、但避免损失最多的组件。

账号审查（account review） 是图库平台风控机制的一环。当系统检测到同一资产被多次提交、或上传行为呈现机器化规律（如固定间隔、大批量重复），会自动标记账号并转入人工审查。审查期间，账号的上传和收益功能可能被冻结，严重时会导致封号。重复上传之所以危险，是因为它容易被误判为“恶意刷量”或“规避审核”——即使创作者并无此意。自动化脚本若没有幂等性（即重复执行不会产生额外副作用），定时任务重跑或状态丢失就会直接触发这一机制。因此，记录已上传项的账本不是可选优化，而是避免账号损失的基础设施。

一条命令生成封面和压缩包

pack_product.py负责把产品打包并渲染图片：

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

这条命令会在当前目录的_system文件夹里生成my-product.zip、一张1280x720封面和一张600x600缩略图，用--dir或PACK_ROOT环境变量可以改输出位置。渲染依赖Pillow，是整个工具包里仅有的两个第三方包之一；另一个是reportlab，供md2pdf.py把Markdown文档一键转成带样式的PDF产品。

为什么偏偏是1280x720和600x600？因为这两个尺寸在列表预览区和缩略图网格里看起来正好，又不浪费渲染时间。按实际需要的分辨率渲染，是让整条流水线跑在1 vCPU、2 GB内存、无GPU的小服务器上的关键习惯之一。

让小服务器跑完全流程的几个习惯

完整流水线打包了39个产品、产出总计856 MB，全程跑在那台小机器上。靠的不是硬件，是几个具体习惯：

• 一次只跑一个进程。单核上绝不要把图像任务并行铺开。
• 每个资产处理完后调用gc.collect()，在条目之间释放内存。
• 用resource.getrusage(RUSAGE_SELF).ru_maxrss测峰值内存，而不是平均值——平均值会谎报你的内存上限。
• 重渲染步骤按子进程一个文件来拆，内存才能真正还给操作系统。

这些做法都不聪明，只是让独立创作者能用几乎零成本的硬件跑起一条真实的流水线。

gc.collect() 是Python标准库gc模块提供的强制垃圾回收函数。Python主要依靠引用计数管理内存，但循环引用等场景需要分代垃圾回收器介入。在批量处理图像等大对象时，即使对象已不再使用，内存也可能不会立即归还给操作系统，导致峰值内存持续攀升。逐资产调用gc.collect()可以主动触发回收，及时释放不再引用的图像缓冲区，从而让1 vCPU、2 GB内存的小机器也能稳定跑完整个流水线。与之配合的resource.getrusage(RUSAGE_SELF).ru_maxrss则用于读取进程的峰值常驻内存集（RSS），帮助开发者了解真实的内存上限，而不是被平均值误导。

工具包的定位

上述内容已被整理成四个独立脚本：make_metadata.py、upload_tracker.py、md2pdf.py、pack_product.py。没有框架，不需要云账号，只有两个pip包。它们来自一个更大的项目——约19,000行流水线代码、300多页研究支撑其规则——现在作为“AI贴纸工厂手册”单独提供。作者的原话是：如果你不想在午夜从一个被拒的CSV开始重建整个打包层，这套东西已经在了。

对所有做数字产品的人来说，这里的启示并不限于贴纸：素材的“可售性”很大程度上由打包层决定，而打包层恰恰是最适合脚本化的部分。