40个文件重复提交，我用一个Python脚本堵住了这个坑

周二晚上11点，我打开Adobe Stock的贡献者后台，发现同一批矢量素材在审核队列里躺了两遍。四十个文件，一周之内提交了两次。

原因不复杂：上传脚本跑到一半失败，我修好之后直接重跑，而脚本没有记录哪些文件已经发出去过。账号没出事，纯属运气。批量重复提交是贡献者账号被标记的最快路径，而我恰好在最大的销售平台上干了一次。

修复花了一个下午。这个文件现在是我整条流水线里最不起眼、也最值钱的一个。

重复提交为什么这么容易发生

批量上传的流程通常是三步：生成素材文件夹、构建元数据CSV、通过贡献者门户提交。问题出在第二步和第三步不是原子操作。

Adobe Stock的CSV模板是严格的五列表头，Vecteezy要四列，Dreamstime要十五列。任何一个表头写错，渠道会立刻拒收文件。我最初几次的本能反应是改完CSV，把整批重跑一遍。重复文件就是这么来的。

脚本没有记忆。它会老老实实为已经提交过的文件重新生成条目，因为“已提交”这个事实只存在于贡献者后台，不在我的硬盘上。

部分失败会让情况更糟。如果跑到四十个文件中的第三十个挂掉，你不想重发前三十个。但没有台账，你根本不知道它停在哪，于是要么全部重发，要么手动去后台一个个核对——而这正是流水线本该替你消灭的枯燥活。

追踪器只有一个文件，零依赖

解决方案小得有点不好意思。upload_tracker.py是一个单文件Python脚本，只用标准库，不需要pip install。它维护一份纯文本台账，回答三个问题：

• python upload_tracker.py pending items.txt —— 哪些还没做
• python upload_tracker.py done "asset-001.jpg" —— 标记某个文件已完成
• python upload_tracker.py status —— 查看当前状态

替代那个周二夜晚灾难的工作流是这样的：任何提交动作之前，先从文件夹生成items.txt，先跑pending，只提交pending显示出来的文件，每发一个就标记done。如果跑到第三十个挂了，重跑pending，它只显示最后十个，也只提交这十个。重跑不可能再重复提交，因为决定发什么的是台账，不是我的记忆。

零依赖这一点值得多说一句。我整条流水线跑在一台1 vCPU、2 GB内存、没有GPU的服务器上。工具箱里只有两个脚本需要第三方包（Pillow做封面，reportlab做PDF）。元数据构建器和追踪器只需要Python 3.9以上，意味着它们在哪都能跑，包括这么小的机器，不用为虚拟环境争论。

元数据是同一个问题的另一半

追踪器只有在CSV一次写对的前提下才有用。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

如果你提供titles.json，它能从中读取真实的标题和关键词。没有的话，文件名会被转成标题格式当作标题用，第一遍凑合可以，提交前应该替换掉。

CSV阶段被拒，正是触发重跑冲动的源头。所以修表头问题和修重复问题本质上是同一个修复：让流水线变得确定，你就不会再有“再跑一遍试试”的念头。

让这套东西安全的三个习惯

现在每批我都会做三件事：

1. 一次只跑一个进程。在单核机器上绝不要并行分发图片任务。串行单件更慢，但整体更快，因为不会有东西挂掉。
2. 用gc.collect()在条目之间释放内存，并且用resource.getrusage(RUSAGE_SELF).ru_maxrss测峰值内存，不是平均值。平均内存对上限一无所知。
3. 重渲染步骤一个子进程只处理一个文件，这样内存才能真正还给操作系统。

这些习惯来自跑完整条流水线的经验：大约19000行代码，打包39个产品，产出约856 MB成品。如果其他东西全丢了，追踪器是我第一个要重建的部件。

我把追踪器、元数据构建器和另外两个脚本（一个Markdown转PDF工具，一个负责压缩文件并渲染1280x720封面加600x600缩略图的产品打包器）打进了Pipeline Starter Kit。就是这套工具产出了我的矢量提示词包和其余目录，跑在每月几美元成本的硬件上。