Memoria-智能影记创新实训博客（三）：故事生成功能接口实现与界面展示

Memoria-智能影记创新实训博客（三）：故事生成功能接口实现与界面展示

博客主题：主线功能的实现
功能时间跨度：2026.04.13 - 2026.04.21（第7-8周）
进度总结：我已经完成并完善了图片打标，语义搜索，故事生成三大主线逻辑与界面实现，外加队友实现的时空聚类、人脸聚类以及整套视频生成流程，该app已经具备了任务书中的约60%的主线需求，后续会继续补齐推荐、数字相册模拟等功能。

1. 目标

和前两篇一样，这套功能仍然不把用户相册原图直接上传给云端大模型。当前实现里，DeepSeek 接收的是时间、地点、标签、OCR、caption 等结构化线索；如果需要直接看图，则优先走本地 VLM。

故事生成要解决的不是给一组图配一段文案，而是把用户挑出的照片整理成一条完整创作链路：

• 先把照片从相册、语义搜索或聚类结果里选出来，组成一个可调整顺序的故事队列。
• 再让用户配置主题、文案风格、故事模式、音乐和字幕等生成条件。
• 按固定编排流程提取时间、地点、标签、OCR、caption 等线索，生成结构化故事并落库。
• 最后进入结果页，让用户继续编辑文字、预览视频、生成数字相册。

2. 前期工作

故事生成建立在前面的打标与语义搜索能力之上。真正进入故事编排阶段的，是每张图已经沉淀下来的信息：

• aiTags：提供画面主体和场景线索。
• aiCaption：提供已有的图片描述。
• ocrTags / ocrSummary：补充文字型画面内容。
• 时间与地点：用于组织时间线和空间线索。
• 语义搜索词：如果用户是从语义搜索结果里选图，原始查询会一起带入故事主题。

3. 选图与故事队列

故事链路的第一步不是写故事，而是先确定“哪些图进入故事”以及“这些图按什么顺序讲”。

当前代码里，照片主要从相册聚类/事件页、语义搜索结果页、创作页手动勾选这三类入口进入故事流程。

故事队列由StoryQueueService统一管理。它做了三件事：

• 去重：同一张照片不会重复进入队列。
• 保序：队列顺序默认是后续故事的顺序，用户可以手动拖拽调整。
• 传上下文：如果照片来自语义搜索，semanticSearchQuery会和照片一起进入后续流程。

finaladdedCount=StoryQueueService().addPhotos(selectedEntities.map(StoryQueueService.mapPhotoEntityToQueuePhoto).toList(growable:false),semanticSearchQuery:_controller.text.trim(),);

队列页里，用户还能查看大图、移除照片、拖动排序、手动改写每张图的描述。这里的“手动描述”会覆盖默认 caption，直接参与后面的故事生成。实际界面展示如下：

4. 配置页：把选图变成生成请求

选图完成后，系统会进入ConfigPage，把用户输入整理成一个StoryGenerationRequest。

界面展示如下，从上到下看，配置页实际上有 8 组信息。

这一页虽然选项很多，但逻辑很清楚：上半部分的“核心主题”和“副标题/切入点”决定故事要讲什么、从什么角度讲；中间的“画面比例”“发布平台”“配乐方案”决定结果更适合竖屏还是横屏、偏向哪类平台风格，以及后续视频使用 AI 配乐还是本地音乐；下半部分的“生成故事方式”和“文案模板”决定故事正文是直接基于标签生成，还是先用本地 VLM 补 caption 再交给 DeepSeek，同时控制最终文案更像热门表达、诗歌感、电影旁白还是治愈回忆；最下面的“自动生成视频台词”则继续补齐后续视频字幕。也就是说，这张配置页把“讲什么、怎么讲、讲完怎么展示”三件事都交代完整。

5. 生成主流程

真正的生成工作由StoryGenerationOrchestrator完成。它拆成 8 个步骤推进，界面展示如下：

它会先取出选中的PhotoEntity，如果用户来自故事队列就保留拖拽顺序，否则按时间排序；接着为每张图整理时间、地点、清洗后的aiTags、ocrTags / ocrSummary、已有aiCaption和用户手动改写 caption，统一收束成可写作的素材对象。之后进入语义增强阶段：deepseekTags直接基于标签、OCR 和元数据写故事，localCaptionThenDeepseek会先均匀采样最多12张图片，用本地 VLM 补一轮 caption，再交给 DeepSeek 串成完整叙事。真正调用 DeepSeek 时，系统上传的不是原图，而是每张图片对应的结构化 JSON 线索，并要求模型只输出一个 JSON 对象，严格基于事实写作，保证sections数量与图片数量一致、每段只对应一张图，同时生成整篇story和highlights。如果返回为空、不是合法 JSON，或者正文和分段都无效，系统就回退到本地保底逻辑，利用时间、地点、标签、caption 和亮点摘要拼出一段可用故事，再按图片数均分成多个 section。最后，标准化结果会被写成StoryEntity，其中content采用带![img](index)占位符的 Markdown，连同标题、副标题、图片 ID、画幅方向和发布平台一起入库，供后面的结果页、视频回忆和数字相册继续使用。

6. 结果展示、编辑与二次产出

结果页会先把StoryEntity里的 Markdown 重新解析成StorySection列表，再结合PhotoEntity里的最新图片信息补齐展示数据，形成图文并茂的故事。之后用户可以逐段编辑文字、保存修改、进入“播放回忆”，或者继续生成数字相册。界面展示如下：

7. 视频与后续扩展

故事页不是终点。当前代码在故事生成完成后，还会立即调用StoryVideoPreparationService：

• 生成配乐：如果启用了 AI 配乐，就先让 LLM 写音乐 prompt，再尝试生成音乐；失败时回退到预置音乐。
• 生成字幕：如果开启自动字幕，就根据故事正文和图片描述生成逐图字幕；失败时回退到故事 section 文本或aiCaption。

“故事生成”是后面视频回忆和数字相册的素材中台。

8. 总结

当前项目里的故事生成，已经形成了一条完整创作链路：先选图和排顺序，再配置主题、模式与模板，然后由编排器分步骤提取线索、生成结构化故事、落库保存，最后进入结果编辑、视频回忆和数字相册。

从代码实现看，这条链路最重要的特点有三个：用户可以明确控制素材和顺序；生成不是单次调用，而是完整编排流程；故事结果也不是终态，而是后续视频和数字相册的上游内容资产。