4.2 KiB
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_statustext_statusimage_statusaudio_statuslast_error
其中 partial_ready 表示主内容已经可读但资产还可以继续补全，degraded_completed 表示主内容可读但某个资产失败，需要用户稍后重试。
服务层也抽出了 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 能力分层。
现在 generation job 已经能查询完整事件流，包括 workflow、资产补全和 provider 调用；用户端和管理端都能展示生成轨迹，也能看到 provider 成功率、耗时和成本视角。
我希望通过这个项目展示的是：我不只是会接 AI API，而是能把不确定的模型能力收敛成稳定、可解释、可恢复的产品体验。
面试官追问时的简短回答
为什么不是继续加更多功能？
因为求职版的核心目标是展示产品判断和系统设计能力。功能越多不一定越好，闭环稳定、边界清楚、能解释取舍更重要。
为什么资产失败不直接让生成失败？
儿童故事的主价值是可阅读内容。封面、插图、语音是增强资产，失败时应该降级而不是摧毁主结果。这是 AI 产品常见的不确定性处理。
Provider 分层有什么产品价值？
它让用户不需要理解模型供应链，只感知稳定能力；同时让产品拥有者能控制成本、失败降级和供应商切换。
这个项目下一步怎么上线？
我已经把当前轻量 job/event 模型迁移到后台 worker，并打通了前端进度轮询、取消/重试队列和管理台当前环境运营视图；下一步会补跨环境 Provider 汇聚、断点续跑和更完整监控。生产上线前还需要补真实用户鉴权配置、密钥管理和部署策略。