DreamWeaver/dreamweaver
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
8b50674d04931284b57c200368f3d8c776f7e65f
dreamweaver/docs/product/voice-co-creation-mode-incremental-prd.md

20 KiB
Raw Blame History

Product Requirements Document: 语音共创模式增量方案

Version: 0.1
Date: 2026-04-19
Author: Codex (based on founder direction)
Status: Discovery Track / 不插队当前主开发线

Executive Summary

DreamWeaver 当前已经具备“输入主题 -> 生成故事/绘本 -> 补全封面/语音 -> 保存回看”的稳定主链路，但它仍然更接近一个“单次提交、单次返回”的生成器。创始人提出的新方向，是把产品进一步升级为一个“孩子能直接用声音参与创作、并在讲述过程中纠正故事走向”的语音共创体验。

这个方向的价值不在于再加一个输入方式，而在于把 DreamWeaver 从“生成结果”推进到“陪伴式创作过程”。孩子不是先写清楚需求再等待结果，而是可以像和讲故事的人对话一样，说出自己想要的角色、情节和变化，系统实时或准实时地接住这些表达，再继续讲下去。

本增量 PRD 的目标不是立刻把语音共创插入当前主开发线，而是先把它定义为一条独立、可评估、可拆阶段落地的产品路线。当前主线仍应继续沿着统一生成工作流、跨环境观测、断点续跑与稳定性治理推进；语音共创作为下一波产品升级方向，先完成需求定义、架构判断和分阶段实施策略。

Roadmap Position

Decision

语音共创模式 现在进入产品发现与方案设计阶段，但 不插队当前主开发线。

Why

  • 当前主线已经明确：统一生成工作流、任务控制、Provider 运营分析、监控与恢复能力。
  • 语音共创会引入新的交互模式、新的数据模型和新的低延迟系统要求，如果直接插入，会同时打断稳定性主线和架构收束节奏。
  • 先写清楚增量 PRD，可以避免后续“想到什么做什么”，也能帮助后面的技术选型、原型验证和资源预估。

Proposed Sequencing

  1. 继续推进当前主线：跨环境 Provider 汇聚、监控告警、断点续跑与更细粒度任务控制。
  2. 并行完成语音共创模式的交互原型、增量 PRD 和技术预研。
  3. 等当前主线进入相对稳定阶段后，再按分阶段方案启动语音共创 MVP。

Problem Statement

Current Product State

DreamWeaver 当前的核心体验仍然是“家长或用户输入文本指令，系统一次性生成结果”。这条链路已经能稳定支持故事、绘本、封面和语音朗读，但它有三个天然限制：

  1. 孩子参与感不够强
    当前孩子更多是内容接收者，而不是创作参与者。

  2. 故事方向难以中途修正
    一旦提交生成请求，用户通常只能等待结果，然后再重来，而不是在讲述过程中自然修正。

  3. 声音只承担播放，不承担创作交互
    现在的语音能力是 TTS 朗读，是结果层资产，不是输入层或互动层能力。

User Problem

对于 3-8 岁孩子来说，“打字描述需求”不是自然交互方式。更符合他们习惯的体验是：

  • 直接说“我想听一个关于恐龙和月亮的故事”
  • 讲到一半再说“不要坏人了，我想让小兔子帮它”
  • 如果系统理解错了，可以马上纠正，而不是整段作废

也就是说，孩子真正需要的不是一个更复杂的表单，而是一个 能听、能接、能改、能继续讲 的声音共创伙伴。

Product Vision

DreamWeaver 的语音共创模式应当成为一种“孩子可以开口参与的故事编织方式”：

  • 孩子用语音说出主题、角色或希望发生的事情
  • 系统用温暖的语音回应，并逐步讲出故事
  • 孩子在关键节点可以插话、纠正或改写走向
  • 系统保留上下文，继续讲述，而不是从头全部重来
  • 最终形成一个可以保存、回放、补全插图和沉淀到故事库的正式作品

这个模式本质上把 DreamWeaver 从“故事生成器”升级为“语音驱动的亲子共创体验”。

User Personas

Primary Persona: 孩子（3-8 岁）

  • Role: 直接参与讲故事与改故事的人
  • Goals:
    • 用说话而不是打字表达想法
    • 让故事里出现自己喜欢的角色、动物和发展
    • 在听的过程中随时改变剧情
  • Pain Points:
    • 难以通过文字清楚描述想法
    • 注意力持续时间短，不适合长时间等待
    • 如果系统不理解，缺少自然纠正方式

Secondary Persona: 家长 / 陪伴者

  • Role: 陪伴孩子使用、保证内容安全和完成保存的人
  • Goals:
    • 让孩子更主动参与故事
    • 获得安全、温和、可回放的亲子体验
    • 能把共创结果沉淀为正式故事资产
  • Pain Points:
    • 担心纯开放对话失控或跑偏
    • 担心延迟太高，孩子失去耐心
    • 担心故事很有趣但无法保存和复用

Tertiary Persona: 产品拥有者 / 系统维护者

  • Role: 定义体验边界、控制成本与稳定性的人
  • Goals:
    • 在儿童安全前提下提供有趣的语音共创体验
    • 控制实时语音链路成本和复杂度
    • 让新模式尽量复用现有 generation workflow、memory、profile、universe 能力
  • Pain Points:
    • 语音链路天然更难做低延迟和可控性
    • 需要同时解决识别、推理、朗读和状态同步
    • 容易在“实时体验”与“工程稳定性”之间失衡

Core User Journeys

Journey 1: 孩子发起一个语音故事

  1. 孩子进入“语音共创”模式
  2. 点击说话或自动开始收音
  3. 说出“我想听一个关于小猫去太空的故事”
  4. 系统识别语音、理解意图，并用语音确认
  5. 系统开始讲述第一段故事

Journey 2: 孩子中途修正故事走向

  1. 系统讲到一半
  2. 孩子说“不要让它哭了，我想让它找到一个朋友”
  3. 系统识别到这是“剧情修正”而不是新的故事请求
  4. 系统更新当前故事状态
  5. 后续讲述按照新方向继续

Journey 3: 结束后保存为正式作品

  1. 一轮共创完成后，系统给出标题、摘要和正式文本版本
  2. 家长选择“保存到故事库”
  3. 系统将共创结果写入现有 Story / Storybook 体系
  4. 后续可以补封面、插图、语音缓存和成长记忆

Product Principles

  1. Voice First，不是 Voice Only
    主要交互靠语音，但关键步骤仍要允许家长看到文本摘要、状态提示和保存入口。

  2. 先做可控回合制，再追求完全实时
    第一阶段优先做低风险、可验证的回合式语音共创，而不是一开始就追求复杂的全双工实时对话。

  3. 故事状态必须可追踪
    每一次“孩子说了什么、系统如何理解、故事如何被改写”都需要有清晰的会话状态，而不是只保留最终结果。

  4. 儿童安全高于自由度
    产品目标是温暖陪伴，而不是无限开放对话。需要控制题材、安全边界和表达风格。

  5. 尽量复用现有主干系统
    Profile、Universe、Memory、Generation Job、Story 持久化、TTS Provider 等能力优先复用，不另起一套孤立系统。

Scope Definition

In Scope for This PRD

  • 定义语音共创模式的产品目标、交互边界和分阶段路线
  • 定义与当前系统的关系和复用策略
  • 定义关键功能需求、非功能需求、风险与架构方向
  • 明确什么可以作为未来 MVP，什么应延后

Out of Scope for Immediate Mainline

  • 当前 Sprint 立刻开始实现实时语音共创
  • 为所有页面全面重做 UI
  • 一开始就支持多人同时共创
  • 一开始就支持完全开放世界、无限长对话
  • 一开始就做跨设备实时同步、家庭房间、复杂社交机制

Functional Requirements

FR-001: MUST - 用户可以通过语音发起故事共创会话

系统必须支持孩子使用语音表达故事主题、角色或目标，而不是只依赖文字输入。

Acceptance Criteria

  • 提供独立的“语音共创”入口
  • 用户可以开始录音、结束录音，并获得识别结果反馈
  • 系统能够把一次语音输入解析成结构化创作意图或剧情修正指令
  • 当识别失败时，系统给出可理解的重试提示

FR-002: MUST - 系统可以区分“新建故事”与“修正走向”

语音输入不能一律视为新的生成请求，系统必须识别当前输入是开启新故事、继续讲述还是修改走向。

Acceptance Criteria

  • 会话中至少支持三类意图：开始、继续、修正
  • 修正输入不会默认清空整个已生成故事
  • 系统会在内部保留当前故事状态与修正后的新状态
  • 用户在听感上能感知“故事接住了刚刚的修改”

FR-003: MUST - 系统可以用语音回应并继续讲述

语音共创模式下，系统不只返回文字，也必须以语音形式继续讲述故事。

Acceptance Criteria

  • 每轮系统响应可生成可播放语音
  • 语音风格默认保持儿童友好、温和、清晰
  • 当 TTS 失败时，系统至少保留文本响应，不让会话完全中断
  • 语音播放与文本状态能在界面中同步显示

FR-004: MUST - 共创过程可以保存为正式故事资产

语音共创不应只是一段即时对话，它必须能在某个节点沉淀为正式故事内容。

Acceptance Criteria

  • 会话结束后可生成正式标题、摘要和正文
  • 用户可以选择保存为 Story，后续扩展为 Storybook
  • 保存后的结果能够进入现有故事库
  • 保存后的作品仍可复用现有封面、插图、TTS、Memory 和 Reading Event 流程

FR-005: MUST - 系统必须记录语音会话状态

产品必须有独立于最终 Story 的语音会话状态模型，以支持恢复、调试和后续体验优化。

Acceptance Criteria

  • 每次语音共创会话拥有唯一 ID
  • 至少记录：用户语音转写、系统文本响应、系统语音响应、会话阶段
  • 会话中断后可以恢复最近上下文，而不是完全丢失
  • 关键节点可映射到可观测事件，便于排障

FR-006: SHOULD - 家长可以查看或确认关键改写

考虑儿童表达噪声和误识别，家长应在关键节点拥有轻量确认能力。

Acceptance Criteria

  • 至少提供一个可选的“本轮系统理解为”可视反馈
  • 当系统置信度较低时，可提示家长确认或重说
  • 家长可选择“保存当前版本”作为正式结果

FR-007: SHOULD - 共创过程支持分段生成插图节点

系统应当为未来“边讲边出图”保留能力，但不要求首版立刻做到全量每回合同步出图。

Acceptance Criteria

  • 会话状态模型中为未来插图节点留出扩展点
  • MVP 阶段至少支持结束后统一补图
  • 后续版本可以基于关键段落触发插图生成

FR-008: COULD - 支持故事分叉或“如果这样会怎样”的选择分支

共创模式后续可支持轻量分叉体验，但不作为首版必须项。

Acceptance Criteria

  • 文档中明确分叉能力属于后续增强
  • 当前状态模型设计不阻断未来扩展分支结构

Non-Functional Requirements

NFR-001: MUST - 首版交互应优先保证响应可接受

  • 回合式语音识别结果返回目标：95 分位 <= 2.5 秒
  • 系统语音开始播放目标：95 分位 <= 4 秒
  • 若无法满足实时级别要求，允许先以“说一句、等一句”的回合式体验上线

NFR-002: MUST - 儿童内容安全优先

  • 系统需要有儿童场景安全提示词与内容过滤策略
  • 对明显不适宜内容、暴力或成人化内容进行拦截或柔性改写
  • 需要提供家长可理解的安全降级提示

NFR-003: MUST - 成本必须可观测

  • ASR、对话生成、TTS 调用应能够分能力记录
  • 共创模式需要纳入现有 Provider analytics / cost 体系或其扩展版
  • 必须能评估单次会话成本，而不是只有最终故事成本

NFR-004: MUST - 会话必须可恢复

  • 浏览器刷新、页面切换或短暂断线后，最近会话上下文不能完全丢失
  • 至少支持恢复最近一轮会话状态和最后一次系统响应

NFR-005: SHOULD - 架构保持可插拔

  • ASR、对话模型、TTS 都应沿用 Provider/Capability 思路，而不是写死单一供应商
  • 允许首版先只接一套最稳组合，但系统边界要为后续扩展留口

Recommended Rollout Strategy

Phase A: 回合式语音共创 MVP

Goal
验证“孩子用语音发起故事 + 中途修正剧情 + 保存正式故事”是否真的有产品价值。

Characteristics

  • Push-to-talk 或显式录音按钮
  • 一次说完一句，系统识别后再回应
  • 先输出文本 + TTS，不做复杂打断
  • 故事会话结束后保存为正式 Story

Why This First

  • 技术风险最低
  • 最容易复用当前 generation workflow
  • 能最快验证孩子是否真的愿意参与“改故事”

Phase B: 低延迟准实时共创

Goal
让对话更像自然讲故事，而不是轮流发消息。

Characteristics

  • 引入流式 ASR
  • 允许系统分段说、用户分段打断
  • 引入更细粒度的会话状态和中间故事状态

Phase C: 实时沉浸式语音陪伴

Goal
把 DreamWeaver 升级为更连续的声音陪伴系统。

Characteristics

  • 更自然的 barge-in
  • 多轮上下文记忆更稳定
  • 关键段落插图联动
  • 更丰富的角色语气、音色和故事节奏控制

Architecture Direction

Recommended Architecture

首版推荐采用 “语音会话层 + 现有生成主干复用” 的增量架构，而不是重写整套系统。

1. 新增 Voice Session 层

新增独立的语音会话概念，用于管理：

  • 当前会话 ID
  • 当前轮次 turn
  • 每轮用户语音转写
  • 每轮系统文本回应
  • 每轮系统语音回应
  • 当前故事状态摘要
  • 当前修正意图

建议未来新增的数据对象包括：

  • voice_sessions
  • voice_turns
  • voice_story_snapshots 或等价状态字段

2. 复用现有主干能力

以下能力应优先复用：

  • profiles / universes
  • memory context 构建
  • 统一 generation workflow
  • Story / Storybook 持久化
  • TTS Provider Router
  • generation job / generation event 可观测机制

3. 新增 ASR / Dialogue Orchestrator 能力

当前系统已有 text / image / tts / storybook capability，但 没有输入侧语音识别能力。未来至少需要新增：

  • asr 或 speech_input capability
  • 会话级 story planner / dialogue orchestrator

这里的核心不是单纯“把语音转文字”，而是让系统理解：

  • 这是新故事还是修正
  • 修正的是角色、风格还是情节
  • 该在当前故事哪一层生效

4. 首版通信建议

首版不要一开始就强依赖 WebRTC 或复杂全双工实时架构，建议先使用：

  • 前端录音上传
  • 后端异步识别与生成
  • 前端轮询或 SSE 获取本轮结果

等 MVP 价值被验证后，再考虑：

  • WebSocket
  • Realtime API
  • WebRTC

Model Capability Guidance

本 PRD 不锁死具体供应商，但建议能力分层如下：

Capability Role 首版建议
speech_input 语音转写 选择低延迟、儿童普通话识别稳定的 ASR 方案
dialogue_orchestrator 判断用户意图、维护故事状态、决定下一段叙事 选择低延迟、指令遵循稳定的对话模型
story_generation 生成正式叙事段落与收束文本 优先复用现有稳定文本模型
tts 讲述输出 优先复用当前已接通的 TTS Provider 体系

Practical Recommendation

  • 首版优先稳定组合，不追求最先进组合
  • 优先验证体验价值，再做多 Provider 优化
  • 如果需要低延迟实时感，可在第二阶段单独引入 realtime 类模型

Key Gaps vs Current Architecture

当前架构 可以支撑语音共创方向，但还不能直接无痛实现，主要差距有：

  1. 没有语音输入能力层
    现在只有 TTS，没有 ASR / STT。

  2. 没有会话态故事模型
    现在更像“提交任务 -> 等结果”，缺少持续共创 session。

  3. 没有剧情修正语义
    当前重试和取消针对 job，不针对“故事中途被改写”。

  4. 没有低延迟链路设计
    当前 worker 化设计适合生成任务，不适合直接承载高频实时会话。

  5. 没有儿童语音场景安全机制
    需要额外的识别置信度、内容边界和家长确认机制。

Risks and Blockers

Risk 1: 延迟过高，孩子失去耐心

如果每次说完都等待太久，产品体验会从“共创”退化成“多轮卡顿提交”。

Mitigation

  • MVP 先做短回合
  • 优先压低首响应延迟
  • 必要时让系统先做简短确认，再继续讲长段内容

Risk 2: 语音识别错误导致故事跑偏

儿童语音、环境噪音和吐字不清会显著增加误识别。

Mitigation

  • 低置信度时进行轻量确认
  • UI 中显示“系统理解为”
  • 允许家长快速纠正

Risk 3: 开放对话导致内容不可控

孩子的表达可能跳跃，系统也可能走向不适合儿童的内容。

Mitigation

  • 强化儿童安全 prompt
  • 限定世界观和风格边界
  • 对危险输入进行柔性改写或拒绝

Risk 4: 实时架构过早引入，打乱当前主线

如果还没验证价值就上 WebRTC / 全双工，会显著增加工程复杂度。

Mitigation

  • 先做回合式 MVP
  • 先验证留存和参与感
  • 价值成立后再升级实时架构

MoSCoW Prioritization

Must Have

  • 语音发起故事
  • 语音修正剧情走向
  • 系统语音回应
  • 会话状态落库或可恢复
  • 保存为正式故事
  • 儿童安全边界

Should Have

  • 家长低置信度确认
  • 分阶段插图补全
  • 会话成本统计
  • 与现有 analytics 打通

Could Have

  • 分支剧情
  • 角色多音色切换
  • 更自然的打断式实时对话

Won't Have in MVP

  • 多人实时共创
  • 完整开放世界长时对话
  • 复杂社交分享房间
  • 首版就做跨端同步协作

Success Metrics

Product Metrics

  • 语音共创发起成功率 >= 90%
  • 首轮系统语音响应开始时间中位数 <= 3 秒
  • 至少一次剧情修正被成功接住的会话占比 >= 60%
  • 会话后保存为正式故事的比例 >= 40%

Experience Metrics

  • 内部评审中，80% 以上样本能明显感受到“孩子参与改变了故事”
  • 家长主观反馈中，“比纯文字生成更适合孩子参与”的比例 >= 70%

Technical Metrics

  • 单会话成本可拆解到 ASR / 对话 / TTS
  • 最近会话恢复成功率 >= 95%
  • 关键失败都能映射到可观测事件

Open Questions

  1. 首版是否只支持普通故事，不支持绘本共创？
  2. 首版是否允许孩子自由说，还是需要半结构化引导句式？
  3. 家长确认机制默认开启还是仅在低置信度时触发？
  4. 正式保存时，是只保存最终版本，还是同时保留关键修正轨迹？
  5. 是否需要单独的“语音共创故事”内容类型，还是复用现有 Story 即可？

Final Recommendation

语音共创模式是一个值得做、也确实能把 DreamWeaver 从“工作流完整”再往上推一层的方向，但它不应该现在就直接插队主开发线。

最合理的做法是：

  1. 把它作为独立增量 PRD 固化下来
  2. 将其定位为下一波产品升级方向，而不是当前 Sprint 任务
  3. 未来先从“回合式语音共创 MVP”开始
  4. 复用现有生成主干，新增 voice session 层，而不是另起一套平行系统

这样既能保持当前 PRD 主线不被打断，也能确保后续做语音共创时，我们是在按计划推进，而不是临时起意。

Reference in New Issue View Git Blame Copy Permalink