从一句Prompt到39件成品：自动化流水线踩过的坑

一次性批量上传40个素材到Adobe Stock，第二天醒来却是一屏拒绝通知——图片本身没问题，问题出在CSV上。一个表头列写错，Adobe的上传器连图片都不看就直接拒掉整个文件。这位开发者由此总结出一个朴素的道理：Prompt生成内容是最简单的部分，真正把产品做出来的，是生成之后的那一堆活儿。

下面是他记录下来的：哪些环节崩了，怎么修的，以及背后的数字。

元数据表头是闸门，不是建议

不同平台对上传CSV的要求天差地别。Adobe固定5列表头，Vecteezy要4列，Dreamstime要15列。给任何一个平台递交结构错误的文件，审核校验会立刻失败——没有部分通过，没有「差不多就行」。作者就因为表头少了一列，整批素材被废。

修复方案很无聊但有效：平台要什么表头就写什么，一个字段都不多写。他的 make_metadata.py 脚本现在能从同一个文件夹，通过 --platform adobe、--platform vecteezy 或 --platform dreamstime 参数生成三种格式。脚本会用文件名首字母大写作为标题的兜底方案，但提交前他总会传入一个带真实标题和关键词的 titles.json。像 asset-017.jpg 这样的文件名，根本过不了人工审核那一关。

如果你要自己搭这套东西，别想着做一个「通用CSV」。给每个平台做一份，严格按规范来，上传前校验列数。三种格式，三个表头，零即兴发挥。

重复提交是被封号最快的方式

第二个失误完全是人为的。网络抖了一下之后他重跑了一次上传批次，结果有12个素材被发了两遍。重复提交正是那种会导致账号被标记的操作，而他当时根本没有记录哪些东西已经发出去了。

现在每一批都要过一个台账脚本 upload_tracker.py。这是一个纯文本台账，只有三个命令：pending 显示未完成项，done 标记某项已完成，status 给出总览。它只用Python标准库，无需安装任何依赖。因为提交前都会先查台账，重跑永远不可能导致重复提交。

这条教训可以推广到任何场景：任何会触碰外部账号的自动化流水线，都需要有自己的「记忆」。别指望凌晨一点的你能靠脑子记住发了什么。

「幂等性」是这里的核心概念：同一操作无论执行多少次，结果都与执行一次相同。对上传流水线来说，幂等性意味着即便网络中断后重跑整个脚本，系统也能识别出已成功提交的条目并跳过它们，而不是盲目重发。台账脚本本质上是在本地维护一份「已提交集合」，每次上传前做一次集合差运算，只处理不在集合里的条目。这个思路在分布式系统里被称为「at-least-once delivery + 幂等消费者」模式，但即便在单机脚本场景下同样适用——外部平台的审核系统通常不会主动去重，重复内容的代价由提交方承担。

1核2G的服务器逼你养成纪律

整条流水线跑在一台单核、2GB内存、没有GPU的机器上。这个约束塑造了一切。让它跑得起来的几个习惯：

• 一次只跑一个进程。 单核上并行分发图像任务只会相互争抢，拖垮性能。
• 每处理完一个素材就 gc.collect()， 避免内存在39项的长流程里一路爬升。
• 测量峰值RSS而非平均值， 用 resource.getrusage(RUSAGE_SELF).ru_maxrss。平均值什么都看不出来，峰值能精确告诉你某次渲染会在哪里OOM。
• 重型渲染步骤每个文件开一个子进程， 这样内存才能真正还给操作系统。
• 预览用60 dpi检查，成品用300 dpi渲染。 他曾经花了一整晚debug一个内存飙升问题，最后发现是自己把检查用的副本也按全分辨率渲染了。

这些都算不上什么高明技巧，只是小服务器硬逼出来的做法。说实话，这个约束让流水线变得更简单，而不是更差。

RSS（Resident Set Size，驻留集大小）指进程当前实际占用的物理内存量，与虚拟内存不同，它反映的是真实的RAM消耗。resource.getrusage(RUSAGE_SELF).ru_maxrss 返回的是进程生命周期内的峰值RSS，单位在Linux上是KB，在macOS上是字节。OOM（Out Of Memory）指操作系统内存耗尽后强制杀死进程的机制——Linux内核的OOM Killer会在物理内存和swap均告罄时选择一个进程终止，被杀进程不会留下任何有意义的报错，只是静默消失，这使得OOM问题在日志里极难溯源。子进程的作用恰在于此：子进程退出后，操作系统会回收其占用的全部内存页，而在单一长进程内即便调用gc.collect()，某些C扩展（如图像处理库）申请的底层内存也未必会真正归还给操作系统。

把内容变成产品，是独立的一步

作者手里有一堆装满真实内容的Markdown文档，却没办法让它们看起来像产品。「一个文档」和「一份可售卖的PDF」之间的鸿沟，就是排版：标题、表格、列表、链接。md2pdf.py 用reportlab一条命令就能填平：python md2pdf.py content.md product.pdf "My Product Title"。

打包也是同样的道理。一个没有封面的裸zip是卖不出去的。pack_product.py 把文件打包，并用Pillow渲染一张1280×720的封面和一张600×600的缩略图，把zip、封面、缩略图写进一个可以用 --dir 或 PACK_ROOT 迁移的 _system 文件夹。整套工具只用了两个第三方包：Pillow和reportlab，其余全是标准库。

文件夹结构才是真正的产品

作者最低估的一件事：没有固定结构的素材库，会变成一个杂物抽屉。最终稳定下来的布局是五个文件夹：assets/ 放原始输出，output/ 放可提交文件和元数据CSV，packs/ 放成品zip和封面，research/ 放笔记和抓取日志，scripts/ 放工具。

还有一条用惨痛代价换来的规则：research/ 永远别删。他曾经为了「清理」删掉了这个文件夹，结果弄丢了三个未来产品的原始素材。抓取日志和笔记是库存，不是垃圾。

最终的成果

这套流水线最终打包出了39件成品、856 MB输出，背后是约19,000行母项目代码，以及支撑脚本规则的300多页研究资料。全部在那台1核2G、无GPU的机器上验证通过。上文提到的四个脚本是打包层，运行在一个免费的编排栈之下——由Hermes Agent负责调度任务，9Router在本地以$0成本处理LLM访问。

作者坦言自己并不是一开始就想写什么工具包，他只是想别再丢批次。直到第三个朋友向他要「那些CSV脚本」，他才把真正干活的四个脚本整理到一起。没有框架，没有云账号，Python 3.9+即可运行；如果你只需要元数据和追踪功能，甚至连pip install都不用。

这个案例对任何想做自动化内容流水线的人都有参考价值：真正决定成败的，往往不是最光鲜的生成环节，而是那些枯燥的工程细节——表头规范、幂等台账、内存纪律、目录结构。生成一万张图容易，让这一万张图可靠地变成可售卖产品，才是难的部分。

文中提到的「Hermes Agent」与「9Router」属于本地化LLM编排栈的组件：编排层负责将高层任务拆解为子任务并调度脚本执行，路由层则在多个本地运行的语言模型之间做请求分发，从而在不产生API调用费用的前提下完成提示词处理。这类本地栈的典型替代方案包括Ollama加LangChain，或直接调用llama.cpp的HTTP接口，核心价值都是将LLM访问成本降至接近零，使得每张图片的元数据生成可以不计调用次数地反复重试，而不必担心账单累积。