北京
花了一个周末把店铺页面做到完美：新横幅、重写描述、统一价格。一周后看数据，14次浏览，零成交。同一批素材，用丑陋的自动化列表挂在股票素材市场上，那一周反而出了单。问题不在货架，在通往客户的那条路。
这件事的核心可以拆成三层：渠道自带流量、分发是状态问题、包装决定它是文件还是产品。下面逐层说。
渠道的流量是现成的，但它用表头卡你
Adobe Stock、Vecteezy、Dreamstime 都支持通过元数据 CSV 批量上传。麻烦在于每家要求的列数不同，而且表头错了是在上传时就被拒，不是等人工审核才告诉你。
- Adobe 要 5 列
- Vecteezy 要 4 列
- Dreamstime 要 15 列
不是“大约”。表头差一列，整批在任何人看到你的作品之前就失败了。
这就是漂亮店铺页没用处的原因：店铺页在争夺你并不拥有的注意力。格式正确的 CSV 把你的作品放到一个每月有数百万访客的平台上，摆到已经在搜索的人面前。店铺一周 14 次浏览；市场上的列表不用碰，平台的搜索就在替你分发。
不性感但有效的做法是写一个脚本，从同一个文件夹输出每家平台要求的那套表头。同一批素材，三份输出，三个渠道。分发本身就是产品决策。
重复上传丢的是账号，不只是一批文件
早期他不确定第一次跑完没有，把批量脚本又跑了一遍。第二次上传了一批已经在审核中的文件。这是素材平台上被标记的最快方式——跨提交的重复内容，看起来要么是垃圾信息，要么是版权问题。
解法不是“小心点”，是一本账。他用一个纯文本追踪器，三个命令：pending、done、status。上传前，流水线先问账本哪些还没发过。重跑现在不会重复发任何东西，因为追踪器记得。只用了 Python 标准库，没有东西要装，也没有东西会坏。
这条经验可以推广：分发是一个状态问题。你需要确定地知道什么去了哪里。完美的店铺页什么都不知道。
包装是文件和产品的分界线
一个光秃秃的矢量图压缩包在 Gumroad 或自己的收银台上卖得很差。同样的文件配上一张真正的封面图，卖得明显更好——是封面，不是压缩包里的第一个文件。他的打包器给每个产品渲染一张 1280x720 的封面和一张 600x600 的缩略图。这两个尺寸覆盖了产品会被展示的地方，渲染只是一次 Pillow 调用，不用设计工具，不用手动导出。
文档同理。一堆躺在研究文件夹里有用的 Markdown 笔记什么也没干。把其中一篇转成带标题、表格、链接的样式化 PDF，它就从“笔记”变成了“产品”。一条命令，底层是 reportlab。这一次转换，就是一个研究文件夹变成可售产出的方式。
整个项目里，这层包装把一个提示词引擎变成了 39 个成品，856 MB 输出。这些产品没有一个比最早的尝试画得更好，它们只是分发得更好。
不需要大服务器，需要对内存有纪律
整条流水线跑在 1 vCPU、2 GB 内存、无 GPU 上。靠的是习惯，不是硬件：
- 一次只跑一个图像任务，单核上绝不并行渲染
- 每个素材之后调用 gc.collect()
- 用 resource.getrusage 测峰值内存，不是平均占用——平均值会骗人，峰值才是真实天花板
- 重渲染按一个文件一个子进程跑，让内存还给操作系统
- 预览用 60 dpi 检查，而不是按 300 渲染，全分辨率只留给最终文件
全部东西是四个 Python 脚本加两个第三方包：Pillow 和 reportlab。元数据和追踪脚本只需要 Python。如果一条流水线跑不动 2 GB 的机器，问题通常在流水线，不在机器。
研究文件夹永远别删
他犯过的一个结构性错误，是“清理”时删掉了一个研究文件夹。那些笔记和抓取日志，是后来三个产品的原材料。现在目录结构固定下来：assets、output、packs、research、scripts。研究永不删除。分发会放大你已有的东西，但前提是那些东西还在。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
