从珠宝扩到七个品类，改的只有 prompt 层

七品类统一内容生成管线

上一篇讲了识川的起点：一个珠宝专用的 MVP，六个编辑级模板，Gemini 分析加生成的 pipeline，一天部署上线。商家传一张产品照，拿到六张风格图加文案，99 块。

跑是能跑了，但当时最初提出「做云佩戴」的那个朋友看了一圈，问了一句：「为什么有的不做全链路呢，infra 不通用吗？」

我之前的想法大概是这样的：珠宝的 prompt 已经打磨好了，食品的还很粗糙，那就先给食品少开几个功能，等 prompt 成熟了再加上去。她的意思是不用这么搞——pipeline 是一样的，模板是一样的，换个词就行了。我想了一下，确实是她说得对。后来整个产品方向基本就是被这一句话改掉的。

先把模板系统重构成 7 个品类

具体做法是把模板系统重构成 7 个品类：珠宝、美妆、时尚、食品、家居、数码/虚拟产品、通用。每个品类走同一套 6 模板的 pipeline，唯一变的是 prompt 层。

重构的时候把这 6 个模板本身也重新捋了一遍。

珠宝 MVP 里这 6 个模板是用摄影术语命名的——Hero（主图）、Constellation（星图）、Color DNA（色彩基因）、Craft Detail（工艺微距）、Lifestyle（场景）、Size Reference（尺寸参考）。在珠宝语境下完全说得通。但换到食品上就不对了：「宝石星图」是什么意思？「尺寸参考」放个硬币？

捋下来发现，这 6 个槽位跟摄影技法没什么关系，它其实是说服消费者的 6 个角度：

举两个例子。食品的「色彩基因」变成了制作步骤：槽位没变，目的也没变（都是展示产品背后的过程），只是视觉语言整个换掉了。虚拟产品的「尺寸参考」变成了价格对比卡，也是同一个槽位、同一个目的（给买家决策信息），只不过它连实物都没有。

架构上保持得比较干净：一个 TemplateRegistry，把品类加槽位映射到 prompt 函数。加一个新品类就是写 6 个 prompt 函数然后注册一下，pipeline、流式、存储、UI 全都不用动。说白了，变的只有 prompt。

同一套 pipeline 不动，加新品类只换 prompt 层，就能从一份输入产出 6 张图

然后是小红书文字卡

做这块之前研究了一堆卖货效果好的小红书帖子，发现一件事：9 图轮播根本不是 9 张产品图，通常是 3-4 张产品图，中间穿插 5-6 张文字卡——卖点总结、成分指南、尺码规格、FAQ，还有一张带钩子标题的封面。

这块目前基本没人做，竞品的精力全在 AI 生图上。但你去翻卖得好的帖子就会发现，轮播的转化主要是这些文字卡在扛。算是 AI 内容工具最大的一个盲区。

渲染管线是用 Satori 搭的，流程大概是：

1. React JSX 定义卡片布局（标题、要点、图标、品牌色）
2. Satori 把 JSX 转成 SVG，纯服务端，不需要浏览器
3. Sharp 把 SVG 转成精确尺寸的 PNG

一共五种卡片：封面卡（钩子标题 + 产品图）、卖点卡（3-5 个核心优势）、指南卡（成分表或使用方法）、规格卡（尺寸/材质/保养）、FAQ 卡（3 个常见问题和回答）。

比较妙的是这套卡片的 AI 成本是零。分析步骤本来就要调 Gemini，卖点、材质、保养说明、规格这些数据已经提取出来了，卡片只是把这些结构化数据渲染成视觉版式，纯模板化的活，不用再多调一次模型。所以一套完整的小红书 9 图——4 张 AI 产品图加 5 张文字卡——文字卡部分等于是分析步骤的免费副产品，整套的生成成本低到可以忽略。

同一次 Gemini 分析调用的结构化输出同时喂给要花钱的产品图和零成本的文字卡，文字卡是分析步骤的免费副产品

平台裁剪

不同平台要不同的比例：

之前商家生成完图还得自己去裁，现在就是一个下拉框：选平台，Sharp 自动把所有输出——AI 图和文字卡——裁成对应的比例。实现上很简单，Sharp 的 resize 加 extract，按重心裁剪，但体验差别很大。一个同时做小红书和淘宝的商家，一次生成直接拿到两套图。

视频放在浏览器里做

轮播图有了，下一步自然就是视频。抖音和小红书上产品短视频越来越重要，但大多数商家不会剪辑。

服务端渲染的方案（云端 FFmpeg、Remotion Lambda 这类）都考虑过，全部否掉了——主要是成本，复杂度也是个问题，反正 MVP 阶段撑不起这种架构。最后的做法是全推到客户端：

预览用 Remotion Player 直接在浏览器里渲染视频序列，封面卡 → AI 图片 → 卖点卡，带 Ken Burns 推拉和交叉淡入淡出。说白了就是一个 React 组件在播已经生成好的图片，零服务端成本。

导出用 FFmpeg.wasm 在浏览器里直接编码 MP4。用户点「导出视频」，编码在他自己的浏览器里跑，跑完下载文件。没有渲染农场，没有队列，服务端一分钱成本都没有。

把视频预览和编码全推到用户浏览器里跑，绕开服务端渲染农场，服务端零成本

视频序列按抖音/小红书的惯用结构排：

1. 封面卡 + 钩子标题（1.5 秒）
2. 产品主图（2 秒）
3. 材质/食材拆解（2 秒）
4. 细节特写（1.5 秒）
5. 场景图（2 秒）
6. 卖点卡（2 秒）
7. 结尾卡 + CTA（1.5 秒）

加起来 13 秒左右，短视频平台刚好。FFmpeg.wasm 有个坑，后面讲 audit 的时候再说。

拿一个真包测了一遍

品类引擎好不好使，得拿一个真实的时尚单品跑一遍才知道。选的是 Longchamp Le Pliage：混合材质（尼龙包身、皮革翻盖、金属五金），品牌辨识度强，中端价位。

说实话我之前有点担心 Constellation 这个模板——「宝石标本博物馆陈列」这个概念怎么套到一个包上？结果 Gemini 对时尚品类的「材质星图」给出了自己的解读：把 3 种材质（尼龙面料、牛皮、黄铜五金）分离出来，每种生成一个近距离的质感色块，在深色背景上排成一块材质板，看起来就像设计工作室的面料样卡。

从珠宝那边带过来的编辑美学——那种博物馆画册的感觉——迁移到时尚品类比我想的要自然。同一套 prompt 结构，在珠宝上产出的是宝石星图，在时尚上产出的是材质板。也就是说 AI 泛化的是概念本身（拆解材质、呈现为标本），不是具体品类。

Color DNA 也转得很顺，不再是宝石色系的水彩晕染，而是从包的藏青尼龙、干邑皮革、金色五金里提取出来的色块。概念没换，只是换了个产品，取出来的调色盘就不一样了。

时尚品类算是验证通过了。

没有实物的品类怎么办

其他所有品类都假设你手上有一张产品照。但课程、电子书、软件、模板这些东西没有实物，照片根本不存在。

所以「数码/虚拟」品类走的是另一条路：不分析照片，直接接受文字描述，比如「Python 数据分析课程，40 课时，涵盖 pandas/numpy/matplotlib，目标群体是商业分析师」。纯文字输入，pipeline 照样生成六个槽位：

• Hero： 代表课程主题的抽象概念图（数据流穿过神经网络之类）
• Constellation： 课纲结构可视化思维导图
• Color DNA： 品牌情绪板 + 建议配色
• Craft Detail： 功能亮点 + 图标化展示
• Lifestyle： 理想学习场景（现代工位 + 课程素材）
• Size Reference： 价格对比卡（这门课 vs. 训练营 vs. 学位）

不需要照片输入。分析步骤从文字生成一份详细的产品画像，生成步骤再从画像产出视觉内容。

虚拟品类的视觉风格是故意做得比实物品类更抽象、更有创意的。珠宝的星图是精确的，具体的宝石在具体的排列里；课程的星图是概念性的，主题群组用流线连起来。给 Gemini 更多艺术自由度之后，产出确实更多样，偶尔也更惊艳。

从 demo 到生意

7 个品类上线之后，下一步是把这个东西从 demo 变成能算账的生意。做了几件事。

token 追踪

MVP 阶段是用每次调用的平均值粗略估 Gemini 成本的，不够精确。Gemini 的 usageMetadata 会返回每次请求实际的输入/输出 token 数，所以切到了真实追踪：每次 API 调用记录实际的 token 消耗，关联到触发它的用户和套图上。

这件事挺重要的，因为不同品类的 prompt 长度差距很大——珠宝的分析 prompt 带材质灯光指令，大概 2,000 tokens，食品的大概 1,200。用平均值会高估食品、低估珠宝。

额度系统

用户买额度，每次生成按实际成本扣（向上取整到最近的额度单位）。余额存在 Upstash Redis 里，用原子递减操作，保证不会出现双重扣费。

管理后台

成本看板看四个东西：每日 API 花费（总量 + 分品类）、每用户累计成本、分品类的平均每套成本、利润分析（每套营收减 API 成本）。

数字跑出来验证了上一篇的定价假设：99 元一套，API 成本只占很小一部分，毛利非常健康。文字卡零成本这件事还把混合成本拉得比纯 AI 图套装更低。

单位经济模型

替代方案要 1,100 到 3,100 元，识川是它的十分之一到三十分之一，而 API 成本只占营收的零头。定价足够便宜，商家不用犹豫；毛利足够高，能撑住增长。

上线前跑了一遍 audit

宣布 v2 完成之前，把系统整个 audit 了一遍，扫出来 22 个问题，8 个严重的。

安全这边修了三个：

• 邀请码生成从 Math.random() 换成 crypto.randomInt()。Math.random() 不是密码学安全的，邀请码可预测就等于可以免费用。
• 所有 API 路由加上鉴权校验。之前好几个生成端点没有 auth 检查，任何人拿到 URL 就能烧 Gemini key。
• 关掉图片上传流程的 SSRF 漏洞。原来的代码接受任意 URL 做「链接上传」，不校验目标地址，攻击者可以拿识川当代理去扫内网。

可靠性这边也是三个：

• 生成失败退额度。之前 Gemini 中途报错，用户额度已经扣掉了，加了自动退回的逻辑。
• FFmpeg.wasm 的竞态条件，就是前面说的那个坑。视频导出的流程是启动 FFmpeg、开始写帧、调 ffmpeg.run()——但写帧是异步的，run() 没等它们写完就开跑了，慢一点的机器上会偶发产出损坏的视频。修法是所有帧写入 await 完再跑编码。
• Zustand store 的闭包过期 bug。几个 React 回调捕获了渲染时的 store 值，没有在回调内部用 useStore.getState() 拿最新值。很经典的 React 陷阱，而且造成了真实 bug：生成进度条卡在 33%，实际生成在后台继续跑。

代码质量也修了一批：几个 Zustand store 的 action 直接 mutate 了 state，重构成展开-替换的模式；珠宝专用时代遗留的死代码，写死的 prompt 字符串没走品类注册表，清掉了；Remotion Player 补上了 error boundary，视频预览崩溃不应该带崩整个页面。

22 个问题，全部修掉。代码库从「正常使用没问题」变成了「想搞坏都难」。

回头看

整个过程里最关键的就是那句「为什么不是全品类全链路」。它暴露了我的一个思维陷阱：把每个品类当成需要定制功能的特例，没意识到结构是通用的，变的只有文字。后来我做 AI 产品基本都照这个思路来：pipeline 不动，要适配新品类就去改 prompt。反正 infra 层面各品类没什么区别，区别都在 prompt 里。

文字卡是另一个收获：最有价值的功能可以是零 AI 成本的。这套卡说到底就是服务端的 React 渲染，一次模型都不用调，边际成本是零，偏偏在小红书上最能带转化。视频也是同一个思路，能推到客户端的计算就推到客户端，浏览器里跑 FFmpeg.wasm，零边际成本、零基础设施。

v2 之后识川从「珠宝内容工具」变成了「电商内容平台」。底下还是同一套 Gemini pipeline，同一套 ÉLAN 基因，表面积从一个品类扩到七个，从纯图片到图片加卡片加视频，从一个平台到四个。上一篇那个一天上线的珠宝 MVP，就这么长成了现在这个样子。

---

This post is also available in English.