feat: polish generation demo workflow

docs/planning/interview-pitch.md

@@ -0,0 +1,83 @@
+# DreamWeaver 3 分钟项目讲解稿
+
+这份讲解稿用于 AI 产品经理面试中的项目介绍。建议先背结构，不要逐字背稿；现场根据面试官背景调整技术深度。
+
+---
+
+## 0:00 - 0:30 一句话定位
+
+DreamWeaver 是一款面向 3-8 岁亲子场景的个性化 AI 绘本与陪伴式讲述产品。它不是简单生成一段故事，而是围绕孩子档案、成长主题和故事宇宙，生成可以保存、回看、补全封面和播放语音的亲子阅读体验。
+
+---
+
+## 0:30 - 1:05 为什么要重启这个项目
+
+这个项目早期功能很多：故事生成、绘本、语音、Provider 管理、孩子档案、记忆系统都做过，但主线不够聚焦。求职版重启时，我把目标从“功能越多越好”改成“能否讲清楚一个 AI 产品闭环”。
+
+我保留的核心闭环是：
+
+`选择孩子档案 -> 输入主题/教育目标 -> 生成故事或绘本 -> 补全封面/插图/语音 -> 保存到故事库 -> 可再次打开`
+
+这样面试官能快速理解用户价值，也能看到我对范围收敛的判断。
+
+---
+
+## 1:05 - 1:55 统一生成工作流
+
+AI 生成产品最大的问题不是“能不能调模型”，而是结果不确定时，用户体验怎么保持稳定。所以我把普通故事、完整故事和绘本生成收敛成统一 Generation Workflow。
+
+现在系统先保存主结果，让故事或绘本文字尽快可读；封面、绘本插图和语音作为可补全资产处理。即使图片或音频失败，主故事不会丢，用户可以继续阅读，也可以稍后重试。
+
+后端通过统一状态字段表达结果：
+
+- `generation_status`
+- `image_status`
+- `audio_status`
+- `last_error`
+
+服务层也抽出了 `AssetCompletionResult`，用来表达资产补全类型、状态、结果值、错误信息和是否阻塞主结果。
+
+---
+
+## 1:55 - 2:35 Provider 分层
+
+另一个重点是 Provider 体系。早期 Provider Router 同时承担默认配置、Key 映射、路由策略、熔断、成本统计和执行入口，解释起来很乱。
+
+我把它拆成四个概念：
+
+- Capability：产品需要的 AI 能力，例如文本、图片、语音、绘本结构
+- Provider：某个能力下的供应商配置，例如 Gemini、OpenAI、CQTAI、MiniMax
+- Adapter：具体 API 调用实现
+- Routing Policy：如何按优先级、成本、延迟或轮询选择 Provider
+
+这样用户看到的是稳定的产品能力，系统内部再决定具体调用哪个模型或供应商。
+
+---
+
+## 2:35 - 3:00 当前成果和下一步
+
+目前本地 Docker 可以跑通完整链路，并且有 smoke 脚本验证健康检查、登录、生成、资产重试、故事列表和 Provider 能力分层。
+
+下一步我会继续打磨前端状态体验，让生成中、部分完成、失败重试这些 AI 产品特有状态更清楚；同时明确旧 API 兼容层和 generation job 是否需要落库。
+
+我希望通过这个项目展示的是：我不只是会接 AI API，而是能把不确定的模型能力收敛成稳定、可解释、可恢复的产品体验。
+
+---
+
+## 面试官追问时的简短回答
+
+### 为什么不是继续加更多功能？
+
+因为求职版的核心目标是展示产品判断和系统设计能力。功能越多不一定越好，闭环稳定、边界清楚、能解释取舍更重要。
+
+### 为什么资产失败不直接让生成失败？
+
+儿童故事的主价值是可阅读内容。封面、插图、语音是增强资产，失败时应该降级而不是摧毁主结果。这是 AI 产品常见的不确定性处理。
+
+### Provider 分层有什么产品价值？
+
+它让用户不需要理解模型供应链，只感知稳定能力；同时让产品拥有者能控制成本、失败降级和供应商切换。
+
+### 这个项目下一步怎么上线？
+
+我会先完成演示级前端状态体验和旧 API 兼容策略，再决定 generation job 是否落库。生产上线前还需要补真实用户鉴权配置、密钥管理、监控告警和部署策略。