自动化500个资产零成交后，我总结了四条铁律

一位创作者在自动化生成并上架500个素材后，遭遇了零上传、零销售的尴尬开局。他复盘了从失败到跑通39个产品的全过程，结论有些反直觉：真正卡住你的，往往不是生成艺术本身，而是那些无聊的工程细节。

元数据表头是契约，不是建议

每个素材平台都会在读取文件之前先校验CSV表头。Adobe Stock要求恰好5列，Vecteezy要求4列，Dreamstime要求15列。只要错一列，整批文件就会被弹回，无论图片质量多好。作者第一次翻车就发生在这里：他提交了6列，系统秒拒500个资产。

他的应对是写一个 make_metadata.py，针对每个平台只输出它要求的表头，绝不画蛇添足。脚本会遍历文件夹，把文件名转成标题作为兜底，再写入CSV；如果传入 titles.json，则使用真实标题和关键词。作者提醒，文件名兜底只是第一版能用，像 asset-001.jpg 这种标题不可能获得任何排名，提交前必须替换。

他由此得出一个成本核算：艺术创作大约只占三分之一的工作量，元数据是准入闸门，也是最便宜的自动化对象。

素材平台对 CSV 元数据的校验通常发生在文件解析的第一道关口：系统先按固定列序读取表头，再逐行匹配数据类型（如标题、关键词、类别、授权类型）。Adobe Stock 的 5 列一般涵盖文件名、标题、关键词、类别和 releases；Vecteezy 的 4 列更精简；Dreamstime 的 15 列则包含更多可选字段和格式约束。列数或列名不符时，平台无法将数据映射到内部数据库字段，因此会在入库前整批拒绝。这种校验是硬性的、不依赖人工审核，因此修复成本极低但失败代价极高——一条表头错误就能让整批数百个资产无法进入任何后续流程。

重复提交比劣质图片更致命

作者差点踩进另一个坑。一次夜间批量脚本重跑时，他忘了上一轮已经部分完成，险些造成重复提交。在素材平台上，重复提交是触发账号标记的最快途径之一，一旦被标记，后续每次上传都会面临更慢的审核或直接拒绝。

解决办法朴素但必要：记账。upload_tracker.py 只用标准库实现，记录哪些条目已标记为完成。每批上传前运行 pending 查看待办，上传后标记 done，重跑时自动跳过台账中已有的条目。没有数据库，没有云服务，就是一个让错误无法发生的文件。

作者的建议很直接：如果管线里只自动化一件事，就自动化这个。它决定了重跑是「无聊但安全」还是「账号风险」。

素材平台的重复检测通常基于文件内容哈希或元数据指纹。同一资产二次提交会被识别为重复入库尝试，触发风控模型。轻则降低审核优先级、延长队列时间，重则直接标记账号，导致后续所有上传都进入人工审核或限制上传频率。对于批量管线而言，夜间重跑、部分失败后重启、断点续传都是常见操作，如果没有幂等设计，重复提交几乎必然发生。本地台账脚本的价值在于把「是否已提交」这一状态从平台侧前移到本地，使重跑具备幂等性——同一批任务执行多次与执行一次的结果一致，从而把操作风险从账号层面降回脚本层面。

服务器比你想的小，而这未必是坏事

整条管线跑在 1 vCPU、2 GB 内存、无 GPU 的机器上。这个约束逼出了一些在强力机器上学不到的习惯：

• 一次只跑一个图片任务，单核上并行渲染只会互相拖累；
• 每个资产处理完后调用 gc.collect()，Python 持有引用的时间比预期更长；
• 用 resource.getrusage(RUSAGE_SELF).ru_maxrss 测量峰值内存，而不是凭感觉——平均值说明不了哪个尖峰杀死了进程；
• 重渲染步骤一个文件一个子进程，让内存真正归还给操作系统；
• 预览检查用 60 dpi，只有最终输出才渲染 300 dpi。

AI 生图按张计费，浪费的渲染就是浪费的钱。一条在 500 个资产中的第 340 个因内存尖峰崩溃的管线，烧掉的是时间和预算两样东西。

gc.collect() 是 Python 的循环垃圾回收器手动触发接口。CPython 使用引用计数为主、循环检测为辅的内存管理策略：引用计数能立即回收大多数对象，但循环引用（如相互引用的容器或异常回溯帧）需要垃圾回收器周期性扫描。在内存紧张的机器上，大图处理会频繁产生临时对象和循环引用，默认的自动回收阈值可能来不及释放，导致峰值内存堆积。显式调用 gc.collect() 是在关键节点强制清理，代价是短暂暂停，收益是避免因内存尖峰被 OOM killer 终止进程。ru_maxrss 则返回进程生命周期内的最大常驻集大小，单位因平台而异（Linux 为 KB），它比平均值更能反映哪个资产或步骤真正撑爆了内存。

一文件夹文件不等于一个产品

作者一度拥有 856 MB 的成品输出，却没有任何可售之物——散落的文件看起来什么都不是。转折点来自固定目录布局和一条打包命令。最终沉淀下来的结构是：assets/ 放原始输出，output/ 放待提交文件与元数据，packs/ 放成品压缩包与封面，research/ 放笔记与来源，scripts/ 放工具脚本。

pack_product.py 负责最后一公里：压缩文件，并渲染 1280x720 的封面和 600x600 的缩略图。带真实封面的压缩包能卖，裸文件不能。封面尺寸也不是随便定的，它们对应各市场上架时的预览位。

他还分享了一个不会重犯的错误：曾为「清理」删掉 research/ 文件夹，而那些笔记和抓取日志正是后续三个产品的原材料。这类资料应当永久保留。

数字素材市场的商品单位是「可下载的压缩包」，而非单个文件。平台在上架时需要预览图、缩略图和打包文件三者对应：压缩包提供交付内容，封面和缩略图决定点击率与搜索结果的展示效果。1280x720 和 600x600 是常见预览位尺寸，前者用于详情页横幅，后者用于列表网格。缺少合规封面的压缩包在上架流程中往往无法通过完整性检查，或者即使上架也缺乏视觉吸引力。因此打包脚本的最后一公里不只是压缩，而是把「文件集合」转换成「具备展示元数据的商品单元」，这一步的自动化程度直接决定从成品到可售的转化效率。

80/20 法则落在了意料之外的地方

项目的粗略数字：约 19,000 行管线代码、支撑规则的三百多页研究、39 个打包完成的产品，而第一笔销售出现在这一切之后。艺术生成是最有趣的部分，也是占比最小的部分。真正卡住他的是元数据表头、防重复、文档转 PDF（通过 md2pdf.py 一条命令完成，基于 reportlab，保留标题、表格和链接）以及打包。

处理这四个环节的工具里，两个只需 Python 标准库，另外两个只需要 Pillow 和 reportlab 两个包。没有框架，没有云账号，没有月账单，全部在 1 vCPU、2 GB 的机器上验证通过。

作者并不宣称这套工具能让销售自动发生——销售仍取决于你做什么、以及是否有人想要。它做的是移除让他卡在零成交数周之久的四个失败点：错误表头、重复提交、丑陋文档、未打包文件。

对于做数字产品的人来说，这个复盘的启发或许在于：把无聊环节当作产品本身来对待，比打磨作品更能决定你能不能走到第一笔订单。