475 lines
19 KiB
Markdown
475 lines
19 KiB
Markdown
# Product Requirements Document: DreamWeaver 求职版产品重启与重构
|
||
|
||
**Version**: 1.0
|
||
**Date**: 2026-04-17
|
||
**Author**: Sarah (Product Owner)
|
||
**Quality Score**: 91/100
|
||
|
||
---
|
||
|
||
## Executive Summary
|
||
|
||
DreamWeaver 当前已经具备一个 AI 儿童故事产品的基础能力，包括故事生成、绘本生成、封面图生成、语音合成、孩子档案、故事宇宙、记忆系统与供应商路由能力。从“功能数量”上看，这个项目并不空，但从“产品完成度”上看，当前版本的核心问题是价值主线分散、工作流不统一、供应商体系复杂度过高，导致产品体验不够聚焦，项目故事也不够适合面试场景快速讲清楚。
|
||
|
||
本次重启不以“继续堆功能”为目标，而以“构建一个求职可展示、逻辑可讲述、体验可闭环的 AI 产品版本”为目标。求职版 DreamWeaver 将聚焦为一个“面向 3-8 岁亲子场景的个性化 AI 绘本与陪伴式讲述产品”，突出三个核心价值：个性化连续性、稳定的生成工作流、可感知的声音体验。
|
||
|
||
本 PRD 旨在为后续 2 周至 4 周的产品重构提供明确的目标、范围、优先级与阶段计划。文档同时兼具两个用途：一是作为当前项目的重启执行依据；二是作为转型 AI 产品经理时可模仿的标准化产品文档样本。
|
||
|
||
---
|
||
|
||
## Problem Statement
|
||
|
||
**Current Situation**
|
||
DreamWeaver 目前存在以下产品层与系统层问题：
|
||
|
||
1. 产品主线不清晰。系统同时在讲“儿童故事产品”“成长记忆产品”“多供应商 AI 编排平台”三个故事，但没有一个故事被打磨到足够完整。
|
||
2. 关键工作流分裂。普通故事生成、完整生成、绘本生成分别走不同实现，验证、上下文、保存、资产生成与后处理逻辑重复，难以稳定演进。
|
||
3. 供应商体系职责混杂。Provider 路由层同时承担默认配置、Key 映射、路由策略、熔断、成本统计、执行入口等多项职责，维护成本高，后续扩展风险大。
|
||
4. 演示链路不够稳。Storybook 阅读器依赖内存状态，刷新后无法恢复；音频未做缓存；管理端构建失败会阻碍全量部署。
|
||
5. 工程观感不统一。后端测试可通过，但 lint 历史债务较多，前后端重复代码较多，项目成熟度展示受影响。
|
||
|
||
**Proposed Solution**
|
||
将项目收敛为“求职版 DreamWeaver MVP”，围绕一个可讲清楚的核心闭环进行重构：
|
||
|
||
`选择孩子档案 -> 输入主题/教育目标 -> 生成故事或绘本 -> 生成封面/语音 -> 保存进入故事库与成长时间线`
|
||
|
||
系统层同步推进两项重构：
|
||
|
||
1. 将故事/绘本/资产生成统一到一套 Generation Workflow 中。
|
||
2. 将供应商体系重构为清晰的 Capability / Provider / Routing Policy 分层结构。
|
||
|
||
**Business Impact**
|
||
本轮重构完成后，项目在求职场景中的价值将从“会调用多个模型的功能集合”提升为“有明确价值主张、闭环体验和系统设计取舍的 AI 产品案例”，更适合作为 AI 产品经理岗位的核心项目展示。
|
||
|
||
---
|
||
|
||
## Current Product Diagnosis
|
||
|
||
| 诊断项 | 当前表现 | 对产品的影响 | 判断 |
|
||
|------|------|------|------|
|
||
| 核心价值主张 | 功能较多，但主线分散 | 面试官难以快速理解产品价值 | P0 问题 |
|
||
| 生成工作流 | 故事、完整生成、绘本三套路径并存 | 需求扩展成本高，失败处理不一致 | P0 问题 |
|
||
| Provider 架构 | 路由、配置、凭证、监控耦合 | 后续优化与说明成本过高 | P0 问题 |
|
||
| Storybook 体验 | 依赖前端内存状态，无法按 ID 恢复 | 阅读体验中断，演示不稳 | P0 问题 |
|
||
| 音频体验 | 支持实时生成，但无缓存与复用 | 性能与成本不可控 | P1 问题 |
|
||
| Admin 前端 | 构建失败，影响完整部署链路 | 一键启动和展示受阻 | P0 问题 |
|
||
| 代码质量信号 | 后端测试通过，但 lint 债务明显 | 降低项目成熟度感知 | P1 问题 |
|
||
| 前端表现力 | 可用但较轻，缺少状态设计与产品表达 | 难以承载“生成中/失败/降级成功”等体验 | P1 问题 |
|
||
|
||
---
|
||
|
||
## Product Positioning
|
||
|
||
### 产品定位
|
||
|
||
DreamWeaver 是一款面向 3-8 岁亲子场景的个性化 AI 绘本与陪伴式讲述产品，通过孩子档案、成长主题和故事宇宙上下文，为家庭生成连续、可回看、可聆听的儿童故事体验。
|
||
|
||
### 求职版定位
|
||
|
||
求职版 DreamWeaver 不是“最全功能版本”，而是“最能体现产品思考与系统设计能力的版本”。
|
||
该版本重点体现以下能力：
|
||
|
||
- 能围绕明确用户价值做产品收敛，而不是单纯堆功能。
|
||
- 能把多模型、多供应商能力整理成稳定、可解释的 AI 工作流。
|
||
- 能把声音体验、个性化连续性和失败降级机制变成真正的产品能力。
|
||
|
||
### 核心价值主张
|
||
|
||
1. **个性化连续性**：故事不是一次性生成，而是围绕孩子档案与世界观不断积累。
|
||
2. **陪伴式体验**：文本、绘本和语音不是孤立能力，而是一套完整的亲子阅读体验。
|
||
3. **生成稳定性**：用户不需要理解底层模型，只需要感受到“能稳定出结果，失败也可恢复”。
|
||
|
||
---
|
||
|
||
## Success Metrics
|
||
|
||
**Primary KPIs**
|
||
|
||
- **故事生成成功率**：核心生成链路成功完成率 >= 90%
|
||
测量方式：生成请求中完成文本输出并成功保存主记录的比例。
|
||
- **首个结果可见时长**：用户发起生成后，首个可见结果出现时间 <= 15 秒
|
||
测量方式：文本结果或“部分完成”状态首次返回时间。
|
||
- **完整体验完成率**：文本、封面、语音至少完成其二的比例 >= 80%
|
||
测量方式：故事生成后资产完成状态统计。
|
||
- **个性化命中率**：在内部评审样本中，>= 80% 的故事能明显体现孩子档案/宇宙上下文
|
||
测量方式：人工评估打分表。
|
||
- **演示可用率**：求职演示关键链路 10 次连续演示成功率 = 100%
|
||
测量方式：内部演示脚本回归。
|
||
|
||
**Validation**
|
||
|
||
- 第 1 阶段验证：以“是否能完成端到端故事闭环”为准。
|
||
- 第 2 阶段验证：以“是否能稳定支持绘本与语音回放体验”为准。
|
||
- 对外验证：以面试演示反馈和项目讲解清晰度为准。
|
||
|
||
---
|
||
|
||
## User Personas
|
||
|
||
### Primary Persona: 家长 / 监护人
|
||
|
||
- **Role**: 3-8 岁儿童的家长或监护人
|
||
- **Goals**:
|
||
- 为孩子快速生成有趣、温暖、可教育的故事
|
||
- 让孩子成为故事主角，形成陪伴感
|
||
- 在睡前、亲子共读等场景中使用语音或绘本
|
||
- **Pain Points**:
|
||
- 一次性生成内容容易同质化
|
||
- 缺少与孩子长期成长相关的连续性
|
||
- 语音与插图往往不是同一套体验的一部分
|
||
- **Technical Level**: 初中级
|
||
|
||
### Secondary Persona: 产品拥有者 / 运营管理员
|
||
|
||
- **Role**: 产品负责人、创作者或系统维护者
|
||
- **Goals**:
|
||
- 稳定控制模型调用效果、成本和失败降级
|
||
- 保持产品演示链路稳定
|
||
- 对系统结构有解释力，便于招聘场景展示
|
||
- **Pain Points**:
|
||
- Provider 配置复杂，难以讲清楚
|
||
- 多条工作流重复演化，维护成本高
|
||
- 工程质量与展示价值不匹配
|
||
- **Technical Level**: 中高级
|
||
|
||
---
|
||
|
||
## User Stories & Acceptance Criteria
|
||
|
||
### Story 1: 快速生成个性化故事
|
||
|
||
**As a** 家长
|
||
**I want to** 基于孩子档案和教育主题生成一个故事
|
||
**So that** 我能快速得到适合孩子的阅读内容
|
||
|
||
**Acceptance Criteria**
|
||
|
||
- [ ] 用户可以选择孩子档案并输入主题或教育目标
|
||
- [ ] 系统能结合档案与宇宙上下文生成故事文本
|
||
- [ ] 故事保存后可在故事库中查看
|
||
- [ ] 当图片或语音生成失败时，故事文本仍可正常保留并查看
|
||
|
||
### Story 2: 生成并阅读绘本
|
||
|
||
**As a** 家长
|
||
**I want to** 生成一个多页绘本并在前端顺畅阅读
|
||
**So that** 我能获得更强的陪伴和共读体验
|
||
|
||
**Acceptance Criteria**
|
||
|
||
- [ ] 系统支持多页绘本生成
|
||
- [ ] 绘本可通过唯一 ID 被再次打开，而不是只依赖前端内存状态
|
||
- [ ] 页面刷新或重新进入时，绘本内容仍能恢复
|
||
- [ ] 若部分页面插图失败，文本页仍可正常展示
|
||
|
||
### Story 3: 听故事
|
||
|
||
**As a** 家长
|
||
**I want to** 播放故事语音
|
||
**So that** 我可以在睡前或陪伴场景下使用
|
||
|
||
**Acceptance Criteria**
|
||
|
||
- [ ] 故事详情页支持加载和播放语音
|
||
- [ ] 同一故事音频应支持缓存或复用，避免重复生成
|
||
- [ ] 音频生成失败时，页面应给出明确状态与重试方式
|
||
|
||
### Story 4: 管理模型供应与成本风险
|
||
|
||
**As a** 产品拥有者
|
||
**I want to** 以清晰的方式管理不同能力对应的供应商
|
||
**So that** 我能解释系统架构，并稳定控制成本与故障
|
||
|
||
**Acceptance Criteria**
|
||
|
||
- [ ] Provider 配置以能力、供应商、模型配置的方式组织
|
||
- [ ] 路由策略与凭证管理职责分离
|
||
- [ ] 系统能清楚展示失败降级逻辑
|
||
- [ ] 管理端或配置文档能说明当前有效供应链路
|
||
|
||
---
|
||
|
||
## Functional Requirements
|
||
|
||
### Core Feature 1: 统一的生成工作流
|
||
|
||
- **Description**: 将普通故事、完整故事、绘本生成统一到一套生成任务模型中。
|
||
- **User Flow**:
|
||
1. 用户发起生成
|
||
2. 系统校验档案与宇宙关系
|
||
3. 系统构建 memory/context
|
||
4. 系统生成文本或绘本结构
|
||
5. 系统保存主记录
|
||
6. 系统异步生成封面与语音
|
||
7. 系统回写状态
|
||
- **Edge Cases**:
|
||
- 用户未选择孩子档案
|
||
- 故事宇宙与孩子档案不匹配
|
||
- 部分资产生成失败
|
||
- **Error Handling**:
|
||
- 文本失败：返回明确错误，不保存空故事
|
||
- 图片失败：标记为部分完成，可后续重试
|
||
- 音频失败：不阻塞文本阅读
|
||
|
||
### Core Feature 2: 个性化上下文注入
|
||
|
||
- **Description**: 将孩子档案、成长主题、故事宇宙和记忆系统统一视为内容上下文，而不是附属配置。
|
||
- **User Flow**:
|
||
1. 用户选择档案
|
||
2. 系统聚合角色、兴趣、成长主题、宇宙设定、记忆
|
||
3. 生成结果体现上下文
|
||
- **Edge Cases**:
|
||
- 没有档案时，允许通用生成
|
||
- 没有宇宙时，允许使用基础档案
|
||
- **Error Handling**:
|
||
- 某类上下文缺失不应阻塞生成，只进行降级
|
||
|
||
### Core Feature 3: 绘本与语音的可恢复体验
|
||
|
||
- **Description**: 阅读器和音频播放应支持重新进入、状态恢复与降级处理。
|
||
- **User Flow**:
|
||
1. 用户打开故事详情或绘本详情
|
||
2. 系统按 ID 拉取内容
|
||
3. 页面展示当前已完成资产
|
||
4. 用户按需触发图片或音频补全
|
||
- **Edge Cases**:
|
||
- 页面刷新
|
||
- 资产未生成完成
|
||
- 资产生成失败
|
||
- **Error Handling**:
|
||
- 以状态展示替代“空白失败”
|
||
- 保留重试入口
|
||
|
||
### Core Feature 4: 简化后的 Provider Orchestration
|
||
|
||
- **Description**: 供应商系统应服务于“稳定生成”，而不是暴露为产品主角。
|
||
- **User Flow**:
|
||
1. 系统根据能力类型加载 provider 列表
|
||
2. 根据 routing policy 选择执行顺序
|
||
3. 调用成功即返回结果，失败则自动切换
|
||
4. 记录成本、耗时与错误
|
||
- **Edge Cases**:
|
||
- 没有可用 provider
|
||
- provider 凭证缺失
|
||
- 同类 provider 全部失败
|
||
- **Error Handling**:
|
||
- 返回聚合错误
|
||
- 支持 degraded completion
|
||
|
||
### Core Feature 5: 演示级前端关键体验
|
||
|
||
- **Description**: 前端优先完成关键状态设计，而不是先追求大规模视觉升级。
|
||
- **Required States**:
|
||
- 初始化
|
||
- 生成中
|
||
- 文本已完成、资产处理中
|
||
- 部分完成
|
||
- 全部完成
|
||
- 失败与重试
|
||
- **UI Principles**:
|
||
- 用户始终知道系统当前在做什么
|
||
- 用户始终知道下一步能做什么
|
||
- 页面刷新后体验不中断
|
||
|
||
### Out of Scope
|
||
|
||
- 新增大量供应商类型或复杂负载均衡策略
|
||
- 多租户 Provider 管理
|
||
- 复杂高可用部署优化作为本轮核心目标
|
||
- 高保真商业化支付、会员与订阅系统
|
||
- 花大量时间做纯视觉层重做
|
||
|
||
---
|
||
|
||
## Technical Constraints
|
||
|
||
### Performance
|
||
|
||
- 文本生成应在 15 秒内给出首个可用结果或明确状态
|
||
- 图片/语音资产生成可异步完成，但前端必须有可见状态
|
||
- 绘本详情和故事详情需支持按 ID 快速恢复
|
||
|
||
### Security
|
||
|
||
- 继续使用现有 JWT + httpOnly Cookie 认证方案
|
||
- Provider 密钥应保持加密管理，不在前端暴露
|
||
- 管理端仅保留必要入口，默认不作为求职版核心展示对象
|
||
|
||
### Integration
|
||
|
||
- **Text Providers**: Gemini / OpenAI 作为文本能力候选
|
||
- **Image Providers**: CQTAI / Antigravity 作为图片能力候选
|
||
- **TTS Providers**: MiniMax / ElevenLabs / Edge TTS 作为语音能力候选
|
||
- **Background Jobs**: Celery + Redis 负责后处理与异步任务
|
||
|
||
### Technology Stack
|
||
|
||
- **Backend**: FastAPI + SQLAlchemy Async + PostgreSQL + Celery/Redis
|
||
- **Frontend**: Vue 3 + TypeScript + Pinia + Tailwind CSS
|
||
- **Design Principle**: 先完成状态与流程设计，再做界面强化
|
||
|
||
---
|
||
|
||
## MVP Scope & Phasing
|
||
|
||
### Phase 1: MVP (2 周)
|
||
|
||
**目标**: 做出一个求职可演示、逻辑清晰、体验闭环的 AI 故事产品版本
|
||
|
||
**MVP Scope**
|
||
|
||
- 统一故事 / 完整生成 / 绘本生成的工作流抽象
|
||
- 将 Storybook 页面改为支持按 ID 恢复
|
||
- 修复管理端构建问题，或明确降级为非核心链路
|
||
- 清理 Provider 概念层，去掉历史别名与混杂职责
|
||
- 为图片/音频生成增加明确状态与重试入口
|
||
- 清理关键 lint 与工程观感问题
|
||
|
||
**MVP Definition**
|
||
|
||
用户可以稳定完成一次“选择孩子档案 -> 生成故事/绘本 -> 获取封面/语音 -> 回看或继续阅读”的完整体验，且系统结构可以被清晰讲述。
|
||
|
||
### Phase 2: Enhancements (4 周)
|
||
|
||
- 音频缓存与复用
|
||
- 记忆系统与时间线联动优化
|
||
- Provider 健康状态与成本摘要
|
||
- 演示级前端优化，包括结果页、状态页和阅读页体验
|
||
- 补齐缺失测试，提升工程可信度
|
||
|
||
### Future Considerations
|
||
|
||
- 更细粒度的叙事风格与音色策略
|
||
- 睡前模式 / 陪伴模式
|
||
- 教师场景或课程场景扩展
|
||
- 更复杂的成本路由与多租户配置
|
||
|
||
---
|
||
|
||
## Prioritization Matrix
|
||
|
||
| Priority | 事项 | 目标 | 原因 |
|
||
|------|------|------|------|
|
||
| P0 | 收敛产品主线 | 明确“个性化 AI 绘本与陪伴讲述”定位 | 决定后续所有范围 |
|
||
| P0 | 统一生成工作流 | 消除故事/绘本/资产生成的分裂实现 | 是系统稳定性的核心 |
|
||
| P0 | Provider 概念重构 | 拆清 Capability / Provider / Routing Policy | 是系统可解释性的核心 |
|
||
| P0 | Storybook 可恢复体验 | 支持按 ID 加载与刷新恢复 | 是演示稳定性的核心 |
|
||
| P0 | 修复 admin-frontend 构建或明确降级 | 保证一键启动或明确非核心范围 | 避免部署阻塞 |
|
||
| P1 | 音频缓存与重试 | 强化声音体验和成本控制 | 与你的背景强相关 |
|
||
| P1 | 前端状态设计 | 让生成中、失败、部分完成可感知 | 提升产品成熟度 |
|
||
| P1 | 补测试与 lint 清理 | 提升工程可信度 | 有助于面试展示 |
|
||
| P2 | 增加更多 Provider | 扩展覆盖面 | 当前不是关键短板 |
|
||
| P2 | 管理后台复杂可视化 | 增强运维能力 | 不是求职版核心 |
|
||
| P2 | 大规模视觉升级 | 提升表层观感 | 应晚于闭环与稳定性 |
|
||
|
||
---
|
||
|
||
## Delivery Plan
|
||
|
||
### 第 1 阶段：2 周执行清单
|
||
|
||
#### Week 1
|
||
|
||
- 完成产品主线和展示口径收敛
|
||
- 定义统一的 Generation Job 状态模型
|
||
- 拆分 Provider 层职责，输出新概念模型
|
||
- 决定 admin 端保留范围
|
||
- 修复 Storybook 依赖内存状态的问题
|
||
|
||
#### Week 2
|
||
|
||
- 将前端关键页面补齐状态与重试
|
||
- 打通故事生成与绘本生成的统一流程
|
||
- 输出一版稳定演示脚本
|
||
- 清理关键 lint 问题
|
||
- 完成一轮端到端回归测试
|
||
|
||
### 第 2 阶段：4 周执行清单
|
||
|
||
#### Week 3
|
||
|
||
- 上线音频缓存与复用
|
||
- 让时间线、记忆、故事结果之间形成更清晰关联
|
||
- 增加失败降级与资产补全机制
|
||
|
||
#### Week 4
|
||
|
||
- 完善前端结果体验与语音体验
|
||
- 补齐缺失测试
|
||
- 输出项目说明文档、架构图和演示话术
|
||
- 完成求职版 Demo 包装
|
||
|
||
---
|
||
|
||
## Risk Assessment
|
||
|
||
| Risk | Probability | Impact | Mitigation Strategy |
|
||
|------|------------|--------|---------------------|
|
||
| 重构范围失控 | High | High | 严格限制本轮只服务一个核心闭环，不新增大功能 |
|
||
| Provider 重构导致兼容性问题 | Medium | High | 先保留兼容层，再逐步迁移配置 |
|
||
| Storybook/音频链路改动引入回归 | Medium | High | 补关键回归测试与演示脚本 |
|
||
| 前端优化挤占后端重构时间 | High | Medium | 前端只做状态和关键体验，不做全量视觉翻新 |
|
||
| 求职展示与真实产品目标冲突 | Medium | Medium | 将“求职版”定义为独立阶段目标，不追求商业化全量能力 |
|
||
|
||
---
|
||
|
||
## Dependencies & Blockers
|
||
|
||
**Dependencies**
|
||
|
||
- 现有后端数据库模型和迁移能力
|
||
- 现有 Provider Adapter 体系
|
||
- Vue 前端页面与 Pinia 状态管理
|
||
- 可用的测试与构建环境
|
||
|
||
**Known Blockers**
|
||
|
||
- 管理端前端当前构建失败
|
||
- Storybook 阅读器缺少按 ID 恢复能力
|
||
- 音频未缓存，体验和成本不可控
|
||
- Provider Router 耦合度高，任何修改都容易牵动多处逻辑
|
||
|
||
---
|
||
|
||
## Appendix
|
||
|
||
### Assumptions
|
||
|
||
- 本轮目标以求职展示为第一优先级，而非商业化上线。
|
||
- 目标用户仍然是 3-8 岁儿童家庭场景。
|
||
- 当前技术栈保持不变，不进行大规模框架迁移。
|
||
- 管理后台是辅助能力，不作为本轮展示主角。
|
||
|
||
### Glossary
|
||
|
||
- **Generation Workflow**: 从用户输入到文本、图片、语音完成的一整套生成流程。
|
||
- **Capability**: 底层 AI 能力分类，如文本、图片、语音。
|
||
- **Provider**: 具体供应商，如 Gemini、OpenAI、MiniMax。
|
||
- **Routing Policy**: 供应商选择与降级策略。
|
||
- **Degraded Completion**: 资产部分失败但主结果可用的完成状态。
|
||
|
||
### 如何模仿本类文档
|
||
|
||
当你以后写自己的 PRD 或产品方案时，可以复用这套骨架：
|
||
|
||
1. 先写 Executive Summary，说明产品现在为什么要做这件事。
|
||
2. 再写 Problem Statement，拆清当前问题、方案与业务影响。
|
||
3. 给出 Success Metrics，避免文档只有想法没有验证标准。
|
||
4. 用 Persona 和 User Story 把“用户价值”写实，而不是只写功能点。
|
||
5. 在 Functional Requirements 里同时写 happy path、edge case 和 error handling。
|
||
6. 用明确的 Out of Scope 防止范围不断膨胀。
|
||
7. 用 P0/P1/P2 或阶段计划体现产品判断，而不是罗列任务。
|
||
8. 最后补风险、依赖和假设，让文档更像真正可执行的产品方案。
|
||
|
||
### References
|
||
|
||
- `backend/app/services/provider_router.py`
|
||
- `backend/app/services/story_service.py`
|
||
- `frontend/src/views/StorybookViewer.vue`
|
||
- `frontend/src/stores/storybook.ts`
|
||
- `backend/tests/`
|
||
|
||
---
|
||
|
||
*This PRD was created as a job-search-oriented product reboot plan, with emphasis on product focus, AI workflow clarity, and portfolio-ready execution quality.*
|