四个Python脚本，卡住39个产品？

四个Python脚本，卡住39个产品？

周二晚上11点，一封来自Adobe Stock的拒信把他钉在了椅子上。被拒的不是画，是CSV。两周时间，一台1 vCPU、2 GB内存、没有GPU的服务器，30张图全部生成完毕，结果因为元数据文件的列顺序写错，整批上传全军覆没。审核系统不会警告，不会部分接收，它只做一件事：拒掉整批，让你从头再来。

那一夜他停止生成图片，开始写脚本。最后写出来四个。他得出的结论是：真正的瓶颈从来不是图，而是元数据、追踪和打包。

CSV表头是硬门槛，不是建议

他上架的三个平台，表头写错一律秒拒。Adobe要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

它只用Python标准库，不需要pip install。如果传入一个 titles.json，它会用你真实的标题和关键词；不传，就把文件名转成标题格式。这个默认值第一遍够用，但提交前必须替换——一个叫 abstract_gradient_04 的标题，读起来就是它本来的样子。

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

这里有个没人提醒的坑。你跑一批20个上传，第14个时连接断了，你重跑脚本。于是出现重复项，而重复提交是股票素材平台上账号被标记的最快途径之一。

他的解法简单到有点不好意思。upload_tracker.py 就是一本账：

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

每批之前先问它还剩什么没传，每次上传成功就标记完成。重跑时会自动跳过已发布的内容。大约80行标准库代码，此后至少三次帮他躲过了重复灾难。

文档不像产品，就卖不出去

中间两个脚本解决另一个问题：把Markdown变成可售卖的PDF，把素材包变成真正的产品。

md2pdf.py 一条命令搞定：python md2pdf.py content.md product.pdf "My Product Title"。它用reportlab把标题、表格、列表、链接渲染成干净的PDF，这是整套工具里仅有的两个第三方包之一。另一个是Pillow，被 pack_product.py 用来渲染1280x720封面和600x600缩略图，然后打包：python pack_product.py my-product "My Product" "A short subtitle" 9。

这个教训他是硬吃下来的。同一批文件，以带真实封面的zip形式发货后，销量明显更好。买家在打开之前，先判断包装。

2 GB内存逼出来的规矩

以上所有东西都跑在1 vCPU、2 GB内存、无GPU上。这个约束逼出了一些他现在视为不可谈判的习惯：

• 一次只跑一个进程，单核机器上绝不并行展开图像任务
• 每个素材处理完调用 gc.collect() 释放内存
• 用 resource.getrusage(RUSAGE_SELF).ru_maxrss 测峰值内存，而不是平均占用——杀死你的是峰值
• 重渲染步骤一个文件一个子进程，让内存真正还给操作系统
• 按需要的分辨率渲染：用60 dpi而不是300 dpi检查预览，省下大量内存和时间

这条流水线的总产出是39个成品、856 MB，背后是大约19000行流水线代码，以及支撑脚本所执行规则的300多页研究。

一个值得抄走的目录结构

文件夹布局比他预想的更重要。他最终定下的结构是：project/ 下分 assets（原始输出）、output（待提交文件加metadata.csv）、packs（成品zip加封面）、research（笔记和来源）、scripts（工具）。

他做错的一件事：曾经为了"清理"删掉了 research/。那些笔记和抓取日志，是接下来三个产品的原材料。这个文件夹要永远留着。存储比返工便宜。