用四个Python脚本统一数字产品目录：从杂货抽屉到品牌化商店

一个独立开发者打开自己的Gumroad后台，旁边是40个已完成的产品文件夹，却感到一阵尴尬。产品本身没问题，但整个目录看起来像是四十个陌生人做出来的。封面有深蓝衬线体、荧光绿剪贴画，甚至还有压缩包直接截图当封面的。有买家发邮件问：这些真的是同一家店的吗？这件事成了一个转折点——把包装当成事后想到的事，转为把整个产品目录当成一个产品来运营。

这篇文章记录的方法有一个硬性约束：整套流程跑在一台1 vCPU、2 GB内存、没有GPU的服务器上。工具是四个独立的Python脚本，没有框架，没有云账号，第三方依赖只有Pillow和reportlab。最终产出是39个产品、856 MB打包输出，背后约19000行流水线代码。对独立开发者和小团队来说，这个体量的工具链反而比SaaS更可控。

核心心智转变：目录是一个产品，多个SKU

买家不会逐个评估你的压缩包，他们评估的是你的店铺。封面、文件名、文件夹结构不一致时，每上一个新品，店铺的可信度不是增加而是稀释。

作者的做法是选定一个封面模板然后永远不再改。pack_product.py 用同一条Pillow代码路径渲染所有封面（1280x720）和缩略图（600x600），字体、布局完全相同，只换标题和副标题。一个命令同时写出压缩包、封面和缩略图：

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

做到第九个产品时，所有封面已经可以互换。这正是目标——喜欢过你一个产品的买家，能一眼认出下一个是你的。

命名与目录结构：在写代码之前先定死

目录变成杂货抽屉，往往是因为结构每次都在即兴发挥。文章给出的固定结构是：assets/存原始输出，output/放待提交文件和metadata.csv，packs/放成品压缩包和封面，research/存笔记和来源，scripts/放工具。

两条听起来无聊但很重要的规则。第一，文件名会变成标题。元数据脚本在没有标题文件时会把文件名转成标题格式，所以 botanical-border-04.jpg 第一遍就能生成可用标题；如果你的文件名是 final_final_v3.jpg，CSV里继承的就是这个。第二，research/ 永远不要删。作者曾为「清理」删掉抓取日志，结果三个后续产品的原始素材没了，再也没找回来。

元数据：图库平台先用CSV格式筛掉你

如果你同时在图库平台卖货，目录问题会翻倍——每个平台要求的CSV形状不同，表头错了直接秒拒。Adobe Stock要5列表头，Vecteezy要4列，Dreamstime要15列。错一列，整批上传在人工看到你的作品之前就被弹回。

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

和封面逻辑一样，所有资产在所有平台的标题与关键词来自同一个真实来源。买家在Adobe还是在你自己店铺找到你，品牌读起来是一样的。

图库平台的CSV上传机制：Adobe Stock、Vecteezy、Dreamstime 等微图库平台，除了网页逐张上传，都提供批量上传通道——通常是一个包含图片文件与一份元数据 CSV 的 ZIP。CSV 的每一行对应一张图，列里填写标题、关键词、类别等字段。平台在校验时会先解析表头：列名、列数、顺序必须与官方模板完全匹配，否则整批文件在进入人工审核之前就会被系统拒绝，报错信息往往只提示"格式错误"而不指明具体列。这就是为什么表头错一列等于整批报废。由于各家模板互不兼容，同一批素材要上多个平台就得生成多份 CSV，而关键词和标题又必须保持一致，否则同一作品在不同平台呈现的品牌信息会分裂。用脚本从同一数据源按平台模板生成 CSV，正是为了解决这个矛盾。

最容易被封号的操作：重复上传

这一条跟美观无关，跟生存有关。让图库账号被标记的最快方式，是把上传批次跑两遍。作者早期重跑了一个部分失败的脚本，一次性发了30个重复项，清理花了一整晚，而且算运气好。

upload_tracker.py 是一个纯账本，记住什么已经发过：

python upload_tracker.py pending items.txt   # 显示还没做的
python upload_tracker.py done "asset-001.jpg"
python upload_tracker.py status

入队前先查账本，重跑永远不会重复发布。只用Python标准库，零安装。

文档类产品：Markdown不是产品，PDF才是

作者目录里有一半不是图片素材，而是指南、清单、提示词手册这类文档。原始Markdown文件不是产品。md2pdf.py 把一个Markdown文件渲染成带样式标题、表格、列表和链接的干净PDF：

python md2pdf.py content.md product.pdf "My Product Title"

依赖只有reportlab，每次排版一致，所以目录里的PDF和旁边的封面视觉上是一套的。

小服务器上的生存习惯

这套流程不需要更大的机器，但需要纪律。单核上永远一次只跑一个进程，不并行展开图片任务；每个资产处理完后调用 gc.collect() 释放内存；用 resource.getrusage(RUSAGE_SELF).ru_maxrss 测峰值RSS而不是平均使用量，因为杀死2 GB机器的是峰值；重渲染放子进程里一个文件一个进程，让内存归还操作系统；只需要检查布局时按60 dpi看预览，而不是渲染300 dpi。

峰值 RSS 与 gc.collect() 的意义：RSS（Resident Set Size）指进程当前实际占用的物理内存。Python 使用引用计数加循环垃圾回收，对象释放后内存往往不会立刻归还操作系统，而是留在解释器的内存池里备用，所以平均内存看起来很低，峰值却可能瞬间撑爆 2 GB 的机器。gc.collect() 强制触发一次完整回收，能及时释放循环引用占用的内存。而 resource.getrusage(RUSAGE_SELF).ru_maxrss 返回的是进程生命周期内的峰值常驻内存，这才是判断"会不会 OOM"的真实指标。把重渲染放进子进程，是因为子进程退出时操作系统会一次性回收其全部内存，比在长驻进程里手动清理更彻底。

多源视角与适用边界

需要说明的是，本文的方法论主要来自单一开发者的实践总结，缺少多来源交叉验证。其中「封面模板统一、文件名即标题、上传账本防重」这些做法，与独立开发者社区长期流传的经验一致，属于共识性较强的部分；而具体的CSV列数、脚本实现细节则依赖作者自己的图库渠道，换平台需要重新核对。

另外这套流程的定位很明确：它是包装层，不是分发层。它解决的是「看起来像不像一个品牌」和「会不会因为格式错误被封号」，不解决定价、选品和流量。对SKU数量超过二十、同时在多个渠道上架的独立卖家，收益最明显；只有三五个产品的阶段，手工维护可能比搭流水线更快。

四个脚本——make_metadata.py、upload_tracker.py、md2pdf.py、pack_product.py——是这篇文章真正的落点。它们没有框架和云账号，只有两个第三方包，其中一半脚本只需要Python本身。工具不复杂，难的是把「目录当成一个产品」这个决定坚持下去。