从珠宝到万物
七品类统一内容生成管线
上一篇讲了识川的起点——一个珠宝专用 MVP。六个编辑级模板，Gemini 分析+生成管线，一天部署上线。商家传一张产品照，拿到六张风格图加文案，99 块。
能跑了。但还不够。
那个最初提出"做云佩戴"的朋友看了一圈，问了一句话，直接改变了整个产品方向：
"为什么有的不做全链路呢，infra 不通用吗？"
我之前的思路是：珠宝的 prompt 打磨好了，食品的还粗糙，先给食品少几个功能，等 prompt 成熟了再加。
她的思路是：管线一样，模板一样，换个词就行了。
她说得对。
7 个品类，一套管线
我把模板系统重构成 7 个品类：珠宝、美妆、时尚、食品、家居、数码/虚拟产品、通用。每个品类都走同一套 6 模板管线。唯一变的是 prompt 层。
但这逼着我重新想：这 6 个模板到底是什么？
在珠宝 MVP 里，我用摄影术语命名——Hero（主图）、Constellation（星图）、Color DNA（色彩基因）、Craft Detail（工艺微距）、Lifestyle（场景）、Size Reference（尺寸参考）。珠宝语境下完全说得通。
换成食品呢？"宝石星图"是什么意思？"尺寸参考放个硬币"？
想通了：这 6 个槽位不是 6 种摄影技法。它们是说服消费者的 6 个角度。
| 槽位 | 说服角度 | 珠宝 | 食品 | 虚拟产品 |
|---|---|---|---|---|
| 1 | 第一印象 | 棚拍主图 | 摆盘美照 | 课程封面 |
| 2 | 专业拆解 | 宝石星图 | 食材解构 | 课纲结构 |
| 3 | 视觉识别 | 色彩基因 | 制作步骤 | 品牌情绪板 |
| 4 | 品质证明 | 工艺微距 | 质感特写 | 学员成果展示 |
| 5 | 生活场景 | 佩戴场景 | 餐桌/分享 | 学习场景 |
| 6 | 决策信息 | 硬币比尺寸 | 营养/份量 | 价格对比 |
食品的"色彩基因"变成了制作步骤——同一个槽位，同一个目的（展示产品背后的过程），完全不同的视觉语言。
虚拟产品的"尺寸参考"变成了价格对比卡——同一个槽位，同一个目的（给买家决策信息），根本没有实物。
架构保持干净：一个 TemplateRegistry 映射品类+槽位到 prompt 函数。加一个新品类 = 写 6 个 prompt 函数 + 注册。管线、流式、存储、UI 都不动。
小红书文字卡——所有人都在卷 AI 生图，没人管这个
我研究了一堆卖货效果好的小红书帖子，发现一件事：9 图轮播不是 9 张产品图。通常是 3-4 张产品图穿插 5-6 张文字卡——卖点总结、成分指南、尺码规格、FAQ、还有一张带钩子标题的封面。
这些文字卡是 AI 内容工具最大的盲区。
所有竞品都在卷 AI 生图。没人管文字卡。但文字卡才是小红书轮播转化的关键。
我用 Satori 搭了一条渲染管线：
- React JSX 定义卡片布局（标题、要点、图标、品牌色）
- Satori 把 JSX 转成 SVG（服务端，不需要浏览器）
- Sharp 把 SVG 转成精确尺寸的 PNG
五种卡片：封面卡（钩子标题 + 产品图）、卖点卡（3-5 个核心优势）、指南卡（成分表或使用方法）、规格卡（尺寸/材质/保养）、FAQ 卡（3 个常见问题和回答）。
分析步骤已经提取了这些卡片需要的所有数据——卖点、材质、保养说明、规格。卡片只是把结构化数据渲染成视觉版式。
AI 成本：零。
纯服务端渲染。Gemini API 调用（本来就在做分析）提供数据。卡片生成就是模板化。
一套完整的小红书 9 图现在是：4 张 AI 产品图 + 5 张文字卡，文字卡零成本——分析步骤的免费副产品。整套生成成本低到可以忽略。
一键裁剪，别让商家自己动手
不同平台要不同的比例：
| 平台 | 比例 | 尺寸 |
|---|---|---|
| 小红书 | 3:4 | 1080 x 1440 |
| 抖音 | 9:16 | 1080 x 1920 |
| 淘宝 | 1:1 | 1080 x 1080 |
| 通用 | 4:3 | 1440 x 1080 |
之前商家生成完图还得自己裁剪。现在是一个下拉框。选平台，Sharp 自动把所有输出——AI 图和文字卡——裁成对应比例。
实现很简单（Sharp 的 resize + extract，重心裁剪），但体验差别很大。一个同时做小红书和淘宝的商家，一次生成就拿到两套图。
视频？让用户的浏览器自己剪
轮播图有了，下一步自然是视频。抖音和小红书上产品短视频越来越重要，但大多数商家不会剪辑。
我考虑过服务端渲染（云端 FFmpeg、Remotion Lambda 之类的），全部否掉了。成本和复杂度不适合 MVP。
方案：
预览： Remotion Player 在浏览器里渲染视频序列。封面卡 → AI 图片 → 卖点卡，带 Ken Burns 推拉效果和交叉淡入淡出。零服务端成本——就是一个 React 组件在播放已经生成好的图片。
导出： FFmpeg.wasm 在浏览器里直接编码 MP4。用户点"导出视频"，浏览器做编码，下载文件。没有渲染农场。没有队列。没有服务端成本。
视频序列按抖音/小红书的惯用结构排：
- 封面卡 + 钩子标题（1.5 秒）
- 产品主图（2 秒）
- 材质/食材拆解（2 秒）
- 细节特写（1.5 秒）
- 场景图（2 秒）
- 卖点卡（2 秒）
- 结尾卡 + CTA（1.5 秒）
总共约 13 秒。短视频平台刚好。
FFmpeg.wasm 有个坑，后面代码审计部分再说。
拿一个真包跑一遍
品类引擎的关键测试是拿一个真实时尚单品跑一遍。我选了 Longchamp Le Pliage——混合材质（尼龙包身、皮革翻盖、金属五金），品牌辨识度强，中端价位。
Constellation 模板给了我一个惊喜。
说实话我担心过——"宝石标本博物馆陈列"这个概念怎么用到包上？
但 Gemini 对时尚品类的"材质星图"做了自己的解读：把 3 种材质（尼龙面料、牛皮、黄铜五金）分离出来，每种生成一个近距离质感色块，在深色背景上排列成材质板。
看起来像设计工作室的面料样卡。
从珠宝传过来的编辑美学——那种博物馆画册感——迁移到时尚比我想的要自然。同一套 prompt 结构，在珠宝上产出宝石星图，在时尚上产出材质板。
AI 泛化的是概念（拆解材质，呈现为标本），不是具体品类。
Color DNA 也转得很顺——不是宝石色系的水彩晕染，而是从包的藏青尼龙、干邑皮革、金色五金里提取的色块。同一个概念，不同的调色盘。
时尚品类验证通过。接下来是更难的。
没有实物怎么办——虚拟产品
其他所有品类都假设你有一张产品照。但课程、电子书、软件、模板呢？没有实物的东西。
"数码/虚拟"品类走不同的路。不分析照片，而是接受文字描述："Python 数据分析课程，40 课时，涵盖 pandas/numpy/matplotlib，目标群体是商业分析师。"纯文字输入，管线生成：
- 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 tokens。用平均值会高估食品成本、低估珠宝成本。
额度系统
用户买额度。每次生成根据实际成本扣额度（向上取整到最近的额度单位）。余额存在 Upstash Redis 里，用原子递减操作——不会出现双重扣费。
管理后台
成本看板：
- 每日 API 花费（总量 + 分品类）
- 每用户累计成本
- 分品类平均每套成本
- 利润分析（每套营收 - API 成本）
数字验证了上一篇的定价假设：99 元一套，API 成本只占很小一部分——毛利非常健康。文字卡零成本还让混合成本比纯 AI 图套装更低。
单位经济模型
| 项目 | 说明 |
|---|---|
| 每套营收 | 99 元 |
| AI 图片生成成本 | 营收的很小一部分 |
| 文字卡生成成本 | 无额外 AI 开销（纯服务端渲染） |
| 平台裁剪成本 | 无额外 AI 开销（服务端图片处理） |
| 视频生成成本 | 无额外 AI 开销（客户端编码） |
| 毛利率 | 非常健康 |
| 替代方案价值 | 1,100-3,100 元 |
| 价格比 | 1/10 到 1/30 |
替代方案的十分之一到三十分之一的价格，API 成本只占营收的零头。足够便宜让商家不犹豫，足够高让利润支撑增长。
上线前，先把自己审一遍
在宣布 v2 完成之前，我跑了一遍系统审计。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 产品开发的通用原则：不要按品类改管线，按品类改 prompt。 基础设施应该品类无关。智能在 prompt 层。
文字卡教了第二课：最有价值的功能可以零 AI 成本。 所有 AI 内容赛道的人都在卷生图质量。但真正驱动小红书转化的文字卡就是服务端 React 渲染。不用 GPU，不调 API，零边际成本。
有时候市场最大的空白不在技术所在之处——在技术不需要的地方。
客户端视频教了第三课：能推到客户端的计算就推到客户端。 服务端视频渲染需要基础设施、队列、存储和持续成本。浏览器端 FFmpeg.wasm 零边际成本、零基础设施，还是用户自己控制的功能。
代价是编码速度（低端设备慢一点），但 13 秒的产品视频，手机也不到一分钟就编完了。
v2 把识川从"珠宝内容工具"推到了"电商内容平台"。底下还是同一套 Gemini 管线，同一套 ÉLAN 基因。但表面积从一个品类扩展到七个，从纯图片到图片+卡片+视频，从一个平台到四个。
上一篇讲的是做对的东西。这一篇讲的是给所有人做。
This post is also available in English.