2GB 内存跑完 39 个数字产品：一个人的打包流水线怎么搭

2GB 内存、单核 CPU、不能并行、没配显卡，在这台机器上跑完 39 个数字产品，一开始看着像个不可能完成的任务。海外一位叫 revanzart 的独立开发者把这套流水线跑通了，产出 856 MB、背后约 19000 行代码，靠的不是云服务，就是一台最便宜的服务器加两个第三方库。这套东西做的是给 Adobe Stock、Vecteezy、Dreamstime 三个图库站供货的素材包，卖出去的就是一个压缩文件。他把整套做法开源了出来，核心判断只有一句话，平台格式是契约，其余全是装饰。

往下拆开看，挡在面前的其实是四件很具体的事，元数据、重复上架、把文档变成商品、以及打包。这四件事的共同点在于，每一件都有一个笨办法能解决，而笨办法不需要聪明人，只要求当天就落地。把这四件事按顺序排好，前一件不通过就不用动后一件，因为后面的动作全建立在前面的产物之上。顺序排错，返工量会成倍往上走，一晚上做完和拖三天做完的差别往往就在这里。这四个问题里没有一个是技术难题，全是流程纪律问题。

元数据那道坎最硬。三个上架平台的表格要求完全不一样，Adobe 要 5 列，Vecteezy 要 4 列，Dreamstime 要 15 列。表头写错一行，整批作品直接被拒，一早上的活儿就这么没了。他自己的说法是，平台格式是契约，其余全是装饰，意思就是先把对方要求的形状对齐了，再谈内容本身好不好。一个从文件夹自动生成对应表头的小脚本，把一整批失败原因直接消掉，因为列数和字段名都是固定的，写死一份就能一直用。

重复上架是另一个坑。同样一批文件跑两遍，账号就可能被判定异常，轻则影响后续审核，重则整个账号被限制。解决办法朴素到有点土，一个记录已提交内容的账本文件，第二次运行时直接拒绝把同一件商品再交出去，顺带告诉你还剩多少没交。这个做法的核心是不信任记忆，无论是人的记忆还是程序运行时的记忆，人会记错，文件不会。作者的说法更直接，管线不信任记忆，只信任那份账本。

把文档变成商品和打包，其实是一道连招。内容本来就在，一条命令就能把 Markdown 转成带标题、表格、列表和链接的干净 PDF，用的库是 Reportlab。打包那一步同时渲染 1280x720 的封面和 600x600 的缩略图，用 Pillow 处理，因为光秃秃一个文件几乎没人愿意付钱。两个库都是纯本地运行，不依赖任何外部服务，离线也能跑完。这套流程的设计原则很直白，把已有的东西包装成能卖的样子，而不是从零再去想该卖什么，先有货再谈卖法，比满世界找货省力得多。

内存这块真正要命的不是平均值，是峰值。一次处理一张图的活儿看着人畜无害，偏偏在不该炸的时候冲上去，作者用一个很具体的比喻说那叫垃圾箱时刻。四个习惯能把这套东西摁在 1 vCPU 上，一次只跑一个进程，每处理完一个素材就调用一次内存回收，用系统接口读峰值常驻内存而不是平均值，重活儿丢给单独的子进程跑完就退出，预览图按需要的分辨率渲染而不是一律用最高档。

依赖上的纪律更反直觉。整套流水线只需要两个第三方库，Pillow（处理图片的库）和 Reportlab（生成 PDF 的库），元数据生成器和上传跟踪器用标准库就能写，Python 3.9 加一个虚拟环境就够了。他给的理由很实在，每多一个依赖，就多一个凌晨两点在新服务器上装不上的理由，管线长到一定规模之后，能少装一个包就少装一个包。文件夹结构同样是纪律的一部分，成品和元数据表放一起，研究用的原始资料单独留着，因为那些素材是下一批产品的原料。

这套东西值得抄走的不是代码，是那个把失败原因逐个消灭的顺序。先让格式对，再让流程不重复，然后才是把已有的东西包装成商品。顺序对了，精力才不用花在返工上。国内做模板、做素材包、做知识付费的小团队，其实常常卡在同一条流水线上，只是没人把这条顺序写下来固定下来。这一层的价值，比省下来的那点内存要大得多，因为他验证过的机器是最差的配置，能在这上面跑通，换一台好机器只会更顺。

创业找资源，上乌鸦部落。