CSV表头错了，素材上传秒拒：三大图库平台的列数规则与自动化修复

一个周末的教训：表头行比审核更早杀死你的批次

作者在去年三月准备了60张JPG，打算提交到Adobe Stock。他用手工构建的CSV，点击提交后不到一分钟就收到了拒信。不是内容审核拒稿，不是质量问题——文件根本没走到那一步。解析器直接卡在表头行，整批被退回。他改了表头再交，又因为另一个列的问题被拒。直到这时他才停止猜测，用代码把表头固定下来。

这件事揭示了一个被严重低估的事实：在人类审核员打开你的文件之前，机器早已完成了第一轮筛选。这一轮筛选的成本极高——你几乎得不到有用的反馈，只能对着电子表格反复调试。

解析器先于人类：三大平台的列数硬规则

Adobe Stock、Vecteezy和Dreamstime都会在人工审核前跑一道机器检查。检查内容很机械：先验证列数和列顺序，再验证单个素材。一旦列数不对，返回的是元数据错误（metadata error），而不是内容审核结果。

三个平台的列数各不相同，而且没有兼容余地：

• Adobe Stock：5列。文件名、标题、关键词、分类、授权声明。
• Vecteezy：4列。文件名、标题、关键词、分类。
• Dreamstime：15列。三者中最宽，也是手工CSV最容易崩的地方——少一个空列，后面所有列都会移位。

原文作者表示三种组合他都试过：Adobe的5列表头在Vecteezy上不能用，Dreamstime的15列也容不下5列的行。

陷阱在于这些表头看起来足够相似，大脑会自动补全缺失的部分。你以为在改一个字段，实际上整行结构已经错位。

元数据错误（metadata error） 是素材平台在上传阶段返回的一类技术性拒稿，与内容质量无关。它的触发条件通常是CSV结构不符合平台规范，如列数不符、列名拼写错误、列顺序错位或字段格式非法（例如日期格式、分隔符不一致）。与人工审核拒稿不同，元数据错误往往只返回笼统的错误码或提示，不指出具体哪一行哪一列有问题，因此调试成本很高。更关键的是，部分平台会将反复触发元数据错误的上传计为失败记录，可能影响账户的贡献者评级。理解这一点后，正确的策略是：在提交前用脚本生成并校验CSV结构，而不是在提交后根据模糊错误反复试错。

为什么手工编辑CSV注定失败

用电子表格做几次感觉很安全，做到第四十次就开始出问题。失败模式都很无聊：一个尾随逗号造出幽灵般的第16列；关键词字段里粘贴了逗号而不是平台要求的分隔符；文件名扩展名写错，指向一个不存在的文件。每一个都会让整批退回，而且部分平台会把反复失败的上传计入你的账户记录——在人类看到你的作品之前。

作者因此写了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标准库，无需安装任何东西。标题默认取文件名并转为标题格式，适合第一遍草稿，但提交前应替换为真实标题和关键词，可用--titles titles.json参数传入。

CSV的隐式结构脆弱性 是手工编辑容易失败的根源。CSV本身没有类型系统，列与列之间仅靠逗号分隔，而逗号又可能出现在字段内容中（如关键词列表）。当字段包含逗号时，标准做法是用双引号包裹整个字段，但电子表格软件在导出时可能自动改变引号策略，或者用户手工粘贴时引入未转义的逗号，导致解析器将一行拆成多列。尾随逗号则会在行末制造一个空列，使列数多出一列。这些错误在电子表格里肉眼难以察觉，因为单元格看起来正常，但导出为纯文本后结构已经错位。因此，任何用于机器解析的CSV都应由代码生成，并在提交前用解析器做一次回读校验。

第二个自动化陷阱：重复上传

CSV修好之后，下一个机器拒稿风险来自你自己——把同一批文件跑了两遍。作者早期就干过这事：上传脚本重跑，相同文件名再次上传。重复提交是最快让账户被标记的方式之一，没有平台希望同一个贡献者提交两次相同素材。

解法很笨但有效：一个台账。upload_tracker.py用纯文本记录已经发布的内容：

python upload_tracker.py pending items.txt   # 显示尚未完成的部分
python upload_tracker.py done "asset-001.jpg"
python upload_tracker.py status

每批上传前先查pending。不在台账里的文件才上传，在台账里的跳过。同样只用标准库，两个脚本、零依赖，消除了最耗时间的两类故障。

上传台账（upload tracker） 是一种轻量级的状态管理方法，用于记录哪些文件已经提交、哪些尚未处理。它的核心价值在于幂等性：无论上传脚本重跑多少次，台账都会阻止同一文件被重复提交。实现上，台账可以是一个纯文本文件，每行一个已发布文件名，配合简单的子命令（pending/done/status）即可完成查询与更新。与数据库相比，纯文本台账无需额外依赖、易于版本控制、可直接用文本编辑器查看，适合个人贡献者和小型流水线。关键习惯是：每次上传前先运行pending查询，只上传不在台账中的文件；上传成功后立即写入done记录，避免中途失败导致状态不一致。

被低估的工程比例：创意只占三分之一

在产生39个成品、约856MB输出的父项目中，处理元数据、追踪和打包的流水线代码大约有19000行。这个比例不是巧合。创意部分离一个提示词只有一步之遥，而让你被拒的部分是一个表头行——它在任何审核员打开文件之前就静默地拒绝了你。

另一件值得说的事：这一切不需要大机器。整条流水线，包括图像生成和打包，跑在1 vCPU、2GB内存、无GPU的环境上。让它跑通的习惯很朴素：一次只跑一个进程，每个素材之后调用gc.collect()，用resource.getrusage测量峰值RSS而不是平均值。如果元数据这一步需要超过2GB内存，说明你过度设计了——生成一个5列的CSV几乎不占资源。

给过去的自己的建议

表头只写一次，写在代码里，按平台区分。永远不要手工编辑提交用的CSV。用台账追踪每一次上传，让重跑无法造成重复发布。研究笔记永远留着——作者曾为“清理”删掉一个研究文件夹，一个月后就需要里面的来源做新产品线，追悔莫及。

这些经验现在被打包成脚本：元数据构建器、上传追踪器、Markdown转PDF工具，以及一个把产品打包成zip并渲染1280×720封面和600×600缩略图的打包脚本。如果你正要提交第一批素材，先修表头，其他都可以等一天。

核心思路可以迁移到任何平台化上传场景：凡是先机器校验再人工审核的流程，元数据格式的优先级高于内容质量。把格式规则固化进代码，用台账管理状态，是比提高创意产出更快的提效路径。