Python脚本生成图库元数据：标题大小写与关键词排序实战

为一个 CSV 表头丢掉整个周末，是很多做数字产品上架的人都能共鸣的经历。作者把这次失败写成了 make_metadata.py，一个专门为 Adobe Stock、Vecteezy、Dreamstime 生成元数据文件的 Python 脚本。它的核心逻辑不复杂，但踩过的坑值得每个要批量上传图库素材的人看一眼。

表头就是契约，不是你的设计空间

每个图库平台的 CSV 表头列数完全不同：Adobe 要 5 列（Filename、Title、Keywords、Category、Releases），Vecteezy 要 4 列，Dreamstime 要 15 列。作者最初写了一个“万能”CSV，再按平台改造，结果成了 bug 工厂。平台在读第一行数据之前就会校验表头，列数不对，后面所有内容都不会被处理。

现在的做法是脚本为每个平台写死对应的表头，一列不多、顺序不变。验证方法也很朴素：用文本编辑器打开生成的文件，而不是用表格软件。LibreOffice 会把行尾分隔符和引号问题藏起来，而 less 能一眼看出问题——作者那次被拒的 CSV 在表格里看起来完全正常。

CSV 的表头校验本质上依赖各平台的上传接口在解析数据行之前先读取第一行，并将列名与前端表单字段做映射。如果列数不匹配或列名有差异，接口通常会直接拒绝整个文件，而不是给出逐行错误提示——这就是为什么“看起来能打开”的文件仍然会被退回。

文件在 LibreOffice 等表格软件中打开正常，却在实际上传时失败，往往是因为表格软件会自动做容错：它会猜测编码、忽略多余的行尾分隔符、把未闭合的引号补全，甚至把逗号重新定位。而平台后端用的是严格的 CSV 解析器，对行尾是 \n 还是 \r\n、字段是否被引号包裹、引号内的逗号如何处理都有固定预期。用 less 或 cat -A 查看原始字节，能暴露出表格软件隐藏的这些差异。

标题大小写是规则问题，不是审美问题

作者在 Vecteezy 上第二次被拒，原因是标题全大写。他用 Python 的 str.title() 把 boho-rainbow-clipart.png 转成了 Boho-Rainbow-Clipart.Png，扩展名被大写，连字符也没处理掉。

脚本现在强制执行的规则是：去掉扩展名，按分隔符拆分，每个词首字母大写，用空格连接，扩展名保持原样。boho-rainbow-clipart 变成 Boho Rainbow Clipart，仅此而已。代码大概只有 6 行，但之前的版本确实把 .Png 送进了标题字段。

还有一个细节：str.title() 会把 Don't 变成 Don'T。如果素材名里可能有撇号，用 string.capwords() 逐词处理更安全。

Python 的 str.title() 按单词边界切分，把每个单词的首字母大写、其余字母小写。它的判断依据是“前一个字符是否为字母”，而不是是否为单词分隔符，因此 boho-rainbow-clipart 中的连字符会被当作分隔边界，得到 Boho-Rainbow-Clipart；扩展名 .png 的 p 也会被大写，变成 .Png。

string.capwords(s, sep) 的行为不同：它先用指定的分隔符把字符串拆成词，对每个词调用 str.capitalize()，再用同样的分隔符拼回去。它不会跨分隔符错误地识别单词边界，也不处理撇号——don't 得到 Don't，而不是 Don'T。对于素材文件名这种以连字符和下划线为主要分隔符的场景，capwords 结合手动替换分隔符更可控，也更容易写出不超过几行的确定性逻辑。

关键词要排序，不是堆砌

Adobe 最多接受 49 个关键词，前 10 个在搜索中的权重最高。关键词顺序是一个需要主动做的决定。作者早期直接把生成器产出的关键词原样写入 CSV，结果有时候“background”的排名比真正的主体还高。

他现在遵循的优先级是：主体名词优先，其次是风格和技法（flat、watercolor、line art），再次是用途（invitation、sticker、sublimation），剩余位置再看情况填。20 到 30 个高度相关的关键词，比硬凑 49 个更有效。

脚本提供了 --titles titles.json 参数。文件名推导出的标题适合首轮处理，但关键词排序的核心逻辑是：人按主题决定一次顺序，脚本把这个顺序应用到整批文件上。一个主题维护一个 JSON 文件并复用，为 40 个文件手工写 30 个关键词、再让脚本套用，这个效率比才勉强可接受。

Adobe Stock 的关键词权重并不是简单的“前 10 个最重要”。官方搜索排序会综合关键词在标题、关键词列表中的位置以及点击和下载反馈，但普遍的经验是前几个关键词对搜索匹配的贡献更直接，越靠后的关键词影响越弱。关键词数量上限为 49 个，超过会被截断或导致上传失败。

把关键词按主体、风格、用途排序，本质上是把人的主题判断固化成一个可复用的 JSON 模板。因为同一主题下的一批文件往往共享大量关键词，只需要维护一份排好序的列表，脚本就能把它套用到几十个文件上。这既保证了排序的一致性，也避免了每处理一个文件就重新做一次排序决策。

重复上传和资源受限的现实约束

第三个问题是重复提交。作者因为记不清哪些文件已经上传，把同一批 60 个文件跑了两次。重复提交是账号被标记的常见原因之一。upload_tracker.py 用标准库实现了一个三命令的台账：pending、done、status。规则是文件提交的那一刻就调用 done，而不是等整个会话结束再补记——会话结束时才更新的台账，在笔记本没电时会直接撒谎。

整个 pipeline 只依赖标准库，不加 pandas，不用额外的 CSV 库。这不是风格偏好，是硬件限制：整条流水线跑在 1 核 CPU、2 GB 内存、无 GPU 的机器上，同时还要跑图像渲染。pandas 的启动开销在这个环境下不可接受，而 csv 模块处理引号和分隔符足够正确，启动只要毫秒级。

作者的保命习惯是：一次只跑一个进程，每个素材处理后 gc.collect()，用 resource.getrusage(RUSAGE_SELF).ru_maxrss 测峰值内存而不是平均值。平均值告诉他“空间充足”，峰值告诉他真相。

这些脚本被整合进了 Pipeline Starter Kit，包含三个平台的 CSV 写入器、不会产出 .Png 的标题大小写处理、排名关键词的 JSON 工作流和上传台账。同一套脚本在一台 1 vCPU、2 GB 内存的机器上，从大约 19,000 行流水线代码中打包出了 39 个产品（856 MB 输出），总共 4 个独立 Python 脚本、2 个第三方库（Pillow 和 reportlab，且只在使用打包和 PDF 工具时需要）。

resource.getrusage(RUSAGE_SELF).ru_maxrss 返回的是进程自启动以来驻留内存的峰值，单位在 Linux 上是 KB，在 macOS 上是字节。它能反映最高水位，而平均值会把短时间的峰值稀释掉——在一个同时跑图像渲染的 2 GB 内存机器上，峰值才是决定进程是否被 OOM Killer 杀掉的关键指标。

gc.collect() 则用来在每处理完一个素材后主动触发垃圾回收，及时释放不再引用的对象。Python 的引用计数本身会回收大部分对象，但循环引用需要垃圾回收器介入，而且回收时机不可控。在内存紧张、又不能用 pandas 这类启动开销大的库时，手动调用 gc.collect() 是一种用少量 CPU 时间换取可预测内存占用的做法，配合一次只跑一个进程，可以把整条流水线的内存曲线压在一个可控范围内。