Files
dreamweaver/docs/planning/interview-pitch.md

84 lines
3.9 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# 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 是否落库。生产上线前还需要补真实用户鉴权配置、密钥管理、监控告警和部署策略。