开发记录29_故事生成不是拼标签_VLM描述OCR与可视化进度

Memoria 开发记录 29：故事生成不是拼标签——VLM 描述、OCR 与可视化进度

前言

相册故事生成的目标不是把几张照片串起来，也不是把标签列表拼成文案。用户期待的是“这段回忆被理解了”：画面里有什么、照片之间有什么关系、地点和时间如何形成叙事。

早期实现更偏向 tags only：照片标签作为主要输入，生成故事时缺少 OCR、caption、地点和更具体的视觉描述。这会让文案显得泛泛而谈，例如“这是一次美好的旅行”，但说不出照片里真正出现了什么。

因此故事生成链路需要把 VLM 描述、OCR、标签和基础元数据合并成更完整的材料。

Tags 为什么不够

标签适合检索和聚类，但不适合单独承担叙事。因为标签通常是离散概念：

travel
food
beach
group photo
document

它们能说明“属于哪类”，却不一定说明“画面具体是什么”。同样是 travel，可能是海边、古城、夜景、车站、酒店、餐厅。故事生成需要更细粒度的可见事实。

VLM caption 可以补上这一层：

画面描述：几个人站在海边广场前，远处有红色地标雕塑
视觉标签：city square, sea, landmark
OCR文字：青岛 / 五四广场

这些信息比单个标签更适合交给 LLM 组织成文案。

OCR 的价值

OCR 在相册里并不只服务于“搜文档”。很多照片中的文字本身就是回忆线索：

• 餐厅招牌；
• 景区门票；
• 路牌；
• 学校名称；
• 展览标题；
• 活动海报；
• 手写祝福。

如果 OCR 只运行但不入库、不参与检索、不进入故事材料，那它就是纯成本。当前更合理的链路是：

OCR 结果入库
-> 搜索时作为文本特征
-> 故事生成时作为素材摘要
-> VLM 描述中作为补充事实

OCR 不应该盖过视觉内容，但可以显著提高故事的具体性。

等待页面也需要真实预览

故事生成是长任务，等待页不是装饰。它需要告诉用户系统正在处理哪些照片、进度到哪里、结果是否与选择有关。

之前等待页出现过所有图片都是同一张或占位图的问题，根本原因是预览引用不稳定，甚至依赖 path。对于相册应用来说，系统资产 ID 才是稳定句柄。

改造后的等待页使用 asset:<assetId> 作为预览引用，再通过已选照片集合匹配缩略图。这样不需要临时路径，也不依赖缓存文件是否存在。

selected photos
  -> assetId
  -> progress preview refs
  -> MediaThumbnail(assetId)

这符合前面“从 path 转向 assetId”的整体方向。

默认模式应体现最完整能力

如果已经有本地 caption、OCR、tags 和 LLM 组织能力，默认生成模式就不应该停留在 tags only。默认路径应该代表当前系统最好的稳定能力，保留编辑和高级设置，但不要让用户一开始就面对过多选项。

更合适的默认流程是：

选图
-> 本地 VLM/caption 补充描述
-> tags + OCR + caption + 时间地点汇总
-> LLM 生成故事结构
-> 视频生成与导出

编辑能力仍然保留，但不应该喧宾夺主。默认生成效果要先合理。

删除旧路径比兼容更重要

故事链路中曾经存在多种旧实现和 fallback。过多兼容分支会让问题难以定位：同一张图有时走 assetId，有时走 path，有时走缓存，有时走占位图。

这次改造删除了不少旧代码，目标是让数据流更短：

照片实体
-> 资产 ID
-> 缩略图/分析结果
-> 故事材料
-> 进度预览

路径越少，越容易验证每一步是否正确。

总结

故事生成不是把标签交给 LLM，而是把可验证的照片事实组织成叙事。VLM、OCR、tags、时间和地点各自提供不同粒度的信息，缺一层都会影响最终效果。

关键经验包括：

• tags 适合分类，不足以支撑具体叙事；
• OCR 应入库并参与搜索与故事材料；
• VLM 描述能提供比标签更细的画面事实；
• 等待页必须使用 assetId 稳定预览；
• 默认生成模式应使用最完整的稳定链路；
• 删除旧 path/fallback 分支有助于减少不可复现问题。

对应提交：0d3fd19、b58ece8、3830bb7。