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会和照片一起进入后续流程。finaladdedCountStoryQueueService().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采用带占位符的 Markdown连同标题、副标题、图片 ID、画幅方向和发布平台一起入库供后面的结果页、视频回忆和数字相册继续使用。6. 结果展示、编辑与二次产出结果页会先把StoryEntity里的 Markdown 重新解析成StorySection列表再结合PhotoEntity里的最新图片信息补齐展示数据形成图文并茂的故事。之后用户可以逐段编辑文字、保存修改、进入“播放回忆”或者继续生成数字相册。界面展示如下7. 视频与后续扩展故事页不是终点。当前代码在故事生成完成后还会立即调用StoryVideoPreparationService生成配乐如果启用了 AI 配乐就先让 LLM 写音乐 prompt再尝试生成音乐失败时回退到预置音乐。生成字幕如果开启自动字幕就根据故事正文和图片描述生成逐图字幕失败时回退到故事 section 文本或aiCaption。“故事生成”是后面视频回忆和数字相册的素材中台。8. 总结当前项目里的故事生成已经形成了一条完整创作链路先选图和排顺序再配置主题、模式与模板然后由编排器分步骤提取线索、生成结构化故事、落库保存最后进入结果编辑、视频回忆和数字相册。从代码实现看这条链路最重要的特点有三个用户可以明确控制素材和顺序生成不是单次调用而是完整编排流程故事结果也不是终态而是后续视频和数字相册的上游内容资产。