# 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.*