87 lines
4.1 KiB
Markdown
87 lines
4.1 KiB
Markdown
# 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`
|
||
- `text_status`
|
||
- `image_status`
|
||
- `audio_status`
|
||
- `last_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 运营分析。生产上线前还需要补真实用户鉴权配置、密钥管理、监控告警和部署策略。
|