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

**Version**: 0.2
**Date**: 2026-04-24
**Author**: Codex (based on founder direction)
**Status**: Phase A Alpha / 已进入可演示收束

---

## Executive Summary

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

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

本增量 PRD 最初用于把语音共创定义为一条独立、可评估、可拆阶段落地的产品路线。2026-05-06 更新后，远端 `main` 已经跑通 Phase A Alpha：独立 Voice Studio、语音/文本回合、低置信度确认、安全改写、TTS 回复、会话恢复、finalize 保存为 Story，以及接回统一 generation job 的资产补全与 trace。ASR 已纳入 Provider 能力与管理端运营摘要，当前代码镜像重建后的 Docker voice smoke 已通过；真实 Key 环境仍需补验。下一步不应继续扩大到 Phase B 实时化，而应先完成真实 ASR 环境验收，再回到原主线的跨环境 Provider 汇聚、监控告警和断点续跑。

---

## Roadmap Position

### Decision

语音共创模式已经从 **产品发现与方案设计阶段** 进入 **Phase A Alpha 可演示收束阶段**。

### Why

- 当前主线已经完成统一生成工作流、任务控制、Provider 运营分析、资产补全 trace 和基本恢复能力。
- Phase A 的数据模型、API、Voice Studio 和 finalize 链路已经落地，但仍处于 Alpha；它需要验收、真实 ASR 接入和观测补齐，而不是继续扩大范围。
- Phase B/Phase C 会引入流式 ASR、WebSocket、barge-in 和更高实时性要求，应等 Phase A 的产品价值和稳定性被验证后再启动。

### Proposed Sequencing

1. 先完成 Phase A Alpha 收束：回归验证、演示清单、验收矩阵、服务复杂度自审和已知限制记录。
2. 补齐真实 ASR Key 环境验收，以及 turn 级对话/TTS 成本归因。
3. 回到生产化主线：跨环境 Provider 汇聚、监控告警、断点续跑与更细粒度任务控制。
4. Phase A 稳定并验证产品价值后，再评估 Phase B 准实时共创。

---

## 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，但当时 **没有输入侧语音识别能力**。Phase A Alpha 已新增 `asr` capability、demo fallback 和 `openai_asr` 适配器；真实 Key 环境仍需验收。能力层仍至少包含：

- `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

初始架构 **可以支撑语音共创方向**，但不能直接无痛实现；以下差距中，Phase A Alpha 已补齐主链路，剩余重点是生产化验收：

1. **语音输入能力层**
   已新增 `asr` Provider capability、demo fallback 和 `openai_asr`；仍需真实 Key 环境、延迟样本和更多失败原因验收。

2. **会话态故事模型**
   已新增 Voice Session/Turn/Event；后续要继续拆分服务边界，降低 turn 编排复杂度。

3. **剧情修正语义**
   已支持基础 start / continue / correct；后续要用更多真实儿童表达样本提高覆盖。
   当前重试和取消针对 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

## Phase A Alpha Acceptance Snapshot（2026-04-24）

| Requirement | Status | Evidence | Next Action |
| --- | --- | --- | --- |
| FR-001 语音发起故事共创会话 | Alpha Done | `VoiceStudio` 已提供独立入口，支持录音上传回合和文本 fallback；后端有 `POST /api/voice-sessions/{id}/turns` | 用真实儿童表达样本补演示 smoke |
| FR-002 区分开始、继续、修正 | Alpha Done | turn service 已按 `start/continue/correct` 更新会话状态，修正不会清空整段故事 | 增加更多真实儿童表达样本验收 |
| FR-003 系统语音回应并继续讲述 | Alpha Done | 每轮生成 assistant 文本后调用 TTS，TTS 失败保留文本响应 | 记录 TTS 延迟与失败率到更细指标 |
| FR-004 保存为正式故事资产 | Alpha Done | `finalize` 已持久化 Story，并返回 `generation_job_id` 接回封面资产补全 trace | 补 finalize 后故事库/详情页端到端 smoke |
| FR-005 记录语音会话状态 | Alpha Done | 已有 `voice_sessions / voice_turns / voice_session_events`，前端展示最近 turn 与事件 | 补 turn 级成本与 Provider 归因 |
| FR-006 家长确认关键改写 | Alpha Done | 低 `transcript_confidence` 或 `intent_confidence` 会触发确认，支持继续、重说、改文本 | 打磨确认文案和移动端操作密度 |
| FR-007 分段插图节点 | Partial | 当前支持结束后统一封面补全，并为 asset job 接回统一 trace | 后续评估关键段落插图，不进当前 P0 |
| FR-008 分支剧情 | Deferred | 当前状态模型不阻断未来扩展，但未实现分叉体验 | 保持 P2，Phase A 不做 |
| NFR-001 响应可接受 | Needs Measurement | 回合式体验已实现，但尚无 p95 指标采集 | 加入 ASR/TTS/turn 编排耗时埋点 |
| NFR-002 儿童内容安全 | Alpha Done | 已新增用户转写安全检查、assistant 柔性改写和 `safety_flags` 事件 | 扩充安全样本和误伤回归 |
| NFR-003 成本可观测 | Partial | generation job/provider analytics 已覆盖资产补全；ASR 已进入管理端 Provider 摘要；voice turn 级 Dialogue/TTS 成本仍需细化 | 把 Dialogue/TTS 成本写入 turn/event metadata |
| NFR-004 会话可恢复 | Alpha Done | Voice Studio 支持最近会话恢复和 active session 查询 | 补刷新/切页手动验收记录 |
| NFR-005 架构可插拔 | Alpha Done | ASR 已纳入 `asr` Provider capability，默认 demo fallback，可配置 `openai_asr` | 后续补更多 ASR provider 与管理端体验 |

### Alpha Exit Criteria

- 后端测试、前端构建、管理端构建和 Docker smoke 在当前环境可重复通过。
- Voice Studio 手动路径覆盖：创建会话、文本 fallback、录音回合、低置信度确认、重说/改文本、finalize、故事库回看、资产 trace。
- 真实 ASR Provider 至少完成一个可配置适配器，并保留 demo fallback。（已接入 `openai_asr`，待真实 Key 环境验收）
- turn 级事件至少能区分 ASR、Dialogue、TTS、Safety、Confirmation、Finalize 和 Asset Generation。
- PRD、技术方案、演示 checklist 与当前实现保持一致。

### Must Have

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

### Should Have

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

### Could Have

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

### Won't Have in MVP

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

---



## Phase A Alpha 50-Task Execution Backlog（2026-04-24）

> 目标：先把语音共创 Alpha 做到“可演示、可解释、可复验”，再进入 Phase B 实时化。以下 50 项按今天可连续推进的优先级排列；实现时优先选择无需新迁移、风险低、能用测试和 smoke 验证的任务。

| # | Priority | Area | Task | Acceptance |
| --- | --- | --- | --- | --- |
| 01 | P0 | PRD | 固化 50 项 Alpha 执行池 | PRD 中能看到任务、优先级、验收口径 |
| 02 | P0 | Analytics | turn summary 返回用户录音时长 | `GET /turns/{id}` 有 `user_audio_duration_ms` |
| 03 | P0 | Analytics | turn summary 返回助手音频时长 | `GET /turns/{id}` 有 `assistant_audio_duration_ms` |
| 04 | P0 | Analytics | voice analytics 返回用户语音总时长 | analytics 有 `total_user_audio_duration_ms` |
| 05 | P0 | Analytics | voice analytics 返回用户平均语音时长 | analytics 有 `avg_user_audio_duration_ms` |
| 06 | P0 | Analytics | voice analytics 返回转写 Provider 分布 | analytics 有 `transcription_provider_counts` |
| 07 | P0 | Analytics | voice analytics 返回低置信度确认率 | analytics 有 `confirmation_request_rate` |
| 08 | P0 | Frontend | Voice Studio 展示平均用户语音时长 | 观测卡片可见平均秒数 |
| 09 | P0 | Frontend | Voice Studio 展示转写来源分布 | 观测卡片可见 fallback/demo/openai 次数 |
| 10 | P0 | Frontend | Voice Studio 展示确认率 | 低置信度卡片显示确认率 |
| 11 | P0 | Smoke | `SMOKE_VOICE=1` 断言上传回合时长 | smoke 检查 `user_audio_duration_ms` |
| 12 | P0 | Smoke | `SMOKE_VOICE=1` 断言 Provider 分布 | smoke 检查 demo/fallback 次数 |
| 13 | P0 | Tests | 增加 analytics 时长测试 | `test_voice_sessions.py` 覆盖新增字段 |
| 14 | P0 | Tests | 增加 Provider 分布测试 | 测试覆盖 fallback/openai 分布 |
| 15 | P0 | Tests | 增加确认率测试 | 测试覆盖 `confirmation_request_rate` |
| 16 | P1 | Analytics | 统计文本 fallback turn 数 | analytics 有 `text_fallback_turns` |
| 17 | P1 | Analytics | 统计上传音频 turn 数 | analytics 有 `uploaded_audio_turns` |
| 18 | P1 | Analytics | 统计用户语音 turn 占比 | analytics 有 `user_audio_turn_rate` |
| 19 | P1 | Analytics | 统计助手音频 ready turn 数 | analytics 有 `assistant_audio_ready_turns` |
| 20 | P1 | Analytics | 统计助手音频 ready 率 | analytics 有 `assistant_audio_ready_rate` |
| 21 | P1 | Analytics | 统计 ASR 成功率 | analytics 有 `asr_success_rate` |
| 22 | P1 | Analytics | 统计 TTS 成功率 | analytics 有 `tts_success_rate` |
| 23 | P1 | Analytics | 统计平均转写置信度 | analytics 有 `avg_transcript_confidence` |
| 24 | P1 | Analytics | 统计平均意图置信度 | analytics 有 `avg_intent_confidence` |
| 25 | P1 | Analytics | 统计安全介入率 | analytics 有 `safety_intervention_rate` |
| 26 | P1 | Analytics | 统计语音失败事件分布 | analytics 有 `failure_event_counts` |
| 27 | P1 | Frontend | Voice Studio 展示 fallback/upload turn 数 | 观测卡片可见输入构成 |
| 28 | P1 | Frontend | Voice Studio 展示助手音频 ready 率 | 观测卡片可见 TTS 产物覆盖 |
| 29 | P1 | Frontend | Voice Studio 展示 ASR/TTS 成功率 | 观测卡片文案可见成功率 |
| 30 | P1 | Frontend | Voice Studio 展示平均置信度 | 观测卡片文案可见转写/意图均值 |
| 31 | P1 | Frontend | Turn 卡片展示用户录音时长 | 单轮卡片可解释录音长度 |
| 32 | P1 | Frontend | Turn 卡片展示助手音频时长 | 单轮卡片可解释 TTS 产物长度 |
| 33 | P1 | Smoke | `SMOKE_VOICE=1` 断言输入构成 | smoke 检查 fallback/upload 计数 |
| 34 | P1 | Smoke | `SMOKE_VOICE=1` 断言成功率字段 | smoke 检查 ASR/TTS/assistant audio 率 |
| 35 | P1 | Tests | 增加输入构成测试 | 后端测试覆盖 fallback/upload 计数 |
| 36 | P1 | Tests | 增加音频 ready 率测试 | 后端测试覆盖 assistant audio ready |
| 37 | P1 | Tests | 增加平均置信度测试 | 后端测试覆盖 confidence 均值 |
| 38 | P1 | Docs | 更新技术方案 analytics 字段 | tech spec 与接口一致 |
| 39 | P1 | Docs | 更新 demo checklist 观测项 | checklist 包含语音观测字段 |
| 40 | P1 | Docs | 更新 validation log | 日志记录命令与结果 |
| 41 | P2 | Product | 真实儿童表达样本集 | 至少 10 条样本进入验收文档 |
| 42 | P2 | Product | 低置信度文案 A/B 草案 | 输出两版确认文案 |
| 43 | P2 | Frontend | 移动端确认卡密度优化 | 小屏按钮不拥挤 |
| 44 | P2 | Frontend | 会话列表显示观测摘要 | 列表可见需处理原因和输入模式 |
| 45 | P2 | Backend | 支持 analytics 按 provider 过滤 | query 可筛选 provider |
| 46 | P2 | Backend | 支持 analytics 按 status 过滤 | query 可筛选会话状态 |
| 47 | P2 | Ops | ASR Provider 管理端摘要 | admin 侧可见 ASR 调用情况 |
| 48 | P2 | QA | Docker voice smoke 回归 | Docker 栈下 `SMOKE_VOICE=1` 通过 |
| 49 | P2 | Review | 自审语音服务复杂度 | 列出可拆分函数和风险点 |
| 50 | P2 | Review | 自审演示口径一致性 | PRD、tech spec、checklist 口径一致 |

### 今日执行策略

- 先完成 #01-#40 中无需数据库迁移的观测与验收项。
- #41-#50 作为后续产品化和演示质量任务，不阻塞今天的 Alpha 收束。
- 每批完成后必须跑后端语音测试、前端 build、ruff，并追加验证日志。

## 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 主线不被打断，也能确保后续做语音共创时，我们是在按计划推进，而不是临时起意。

## Phase A Alpha Child Expression Samples（P2 Seed）

这些样本用于后续补齐真实儿童表达验收，不作为模型提示词硬编码。

| # | Sample | Expected Intent | Review Focus |
| --- | --- | --- | --- |
| 01 | 我想听小熊和星星找家的故事 | start_story | 能否抓住主角与目标 |
| 02 | 不要让小熊害怕，让月亮姐姐帮它 | correct_story | 修正是否接上上一轮 |
| 03 | 然后小狐狸也来了，它带了饼干 | continue_story | 新角色是否自然进入 |
| 04 | 我不喜欢黑黑的森林，换成彩虹森林 | correct_story | 负面场景是否温和替换 |
| 05 | 让恐龙变小一点，不要踩坏花 | correct_story | 安全和教育主题是否保留 |
| 06 | 再讲一段，它们坐上云朵船 | continue_story | 奇幻想象是否延续 |
| 07 | 结束吧，我想保存这个故事 | save_story | 是否引导 finalize |
| 08 | 先停一下，我等会再讲 | end_story | 是否保持会话可恢复 |
| 09 | 它们可以一起道歉吗 | continue_story | 是否融入教育主题 |
| 10 | 我刚才说错了，不是兔子，是小猫 | correct_story | 指代修正是否准确 |

## Phase A Alpha Confirmation Copy Options（P2 Seed）

- 版本 A（更温柔）：`我刚才听到的是「{summary}」。如果听对了，我们就按这个继续；如果不对，可以重说一遍或改成文字。`
- 版本 B（更高效）：`本轮系统理解为「{summary}」。请家长确认：继续、重说，或改成文本输入。`

默认建议继续使用版本 B，因为 Alpha 演示时更短、更容易解释系统状态。

## Phase A Alpha Execution Update（2026-04-25）

本轮继续推进真实开发任务，而不是只维护任务池：

- 已完成 #45：voice analytics 支持 `provider` 查询参数，可按转写来源筛选 turn、事件和会话集合。
- 已完成 #46：voice analytics 支持 `session_status` 查询参数，可按会话状态筛选统计窗口。
- 已扩展 Voice Studio 观测卡：支持转写来源和会话状态筛选，便于演示时解释 demo/fallback/真实 ASR 差异。
- 已扩展 `SMOKE_VOICE=1`：增加 provider/status 过滤断言，避免 analytics 只验证全量路径。

当时后续仍未完成：#47 ASR Provider 管理端摘要、#48 Docker voice smoke 回归、#49 服务复杂度拆分、#50 演示口径最终复核。2026-05-06 已补 #47/#48/#49/#50。

## Phase A Alpha Execution Update（2026-05-06）

本轮拉取远端 `main` 到 `0ccfd00 chore: update frontend tooling and Chinese copy` 后继续收束 Alpha 运营可解释性：

- 已完成 #47：管理端 Provider 运营摘要现在会把 Voice Session 上传转写的 ASR 成功/失败纳入 `capability=asr` 聚合。
- 管理端摘要新增 `voice_session_count` 与 `voice_turn_count`，语音识别筛选下可直接看到语音会话数和上传回合数。
- ASR 摘要会按转写来源聚合成功调用，按失败事件聚合错误原因，并把 ASR 成本记录计入供应商和用户维度。
- 已补后端测试覆盖 ASR 成功、失败、成本、跨用户聚合和管理端接口响应。
- 已完成 #48：外部 Registry 阻塞已通过可配置基础镜像与 npm registry 修复；当前代码 `docker compose up -d --build` 通过，重建后 `SMOKE_VOICE=1 ./scripts/demo_smoke.sh` 也通过。
- 已完成 #49：技术方案新增服务复杂度自审，列出 `voice_session_service.py`、`generation_jobs.py`、ASR service 和 Voice Studio 的拆分候选、风险信号和建议顺序；并已先把管理端跨用户 Provider/ASR 摘要拆到 `admin_provider_analytics.py`。
- 已完成 #50：演示 checklist、demo package、3 分钟 pitch、PRD 和技术方案已统一口径：Voice Studio 是 Phase A Alpha，ASR 摘要已进入管理端，当前代码 Docker 重建和 voice smoke 已完成。

后续仍未完成：真实 ASR Key 环境验收、turn 级 Dialogue/TTS 成本归因、跨环境 Provider 汇聚、断点续跑和更完整监控。

## Phase A Alpha ASR Key Validation Prep（2026-06-01）

- 已检查 `openai_asr` 接线：适配器通过 ASR Provider Router 被 Voice Session 上传回合调用，Provider 默认配置读取 `OPENAI_API_KEY`、可选 `OPENAI_API_BASE`、`VOICE_TRANSCRIPTION_MODEL` 和 `VOICE_TRANSCRIPTION_LANGUAGE`。
- 已补 `SMOKE_REAL_ASR=1 ./scripts/demo_smoke.sh`，该路径会自动包含 Voice Studio smoke，上传真实音频并断言 `transcription_provider=openai_asr`、转写文本非空、用户侧 analytics 可按 `provider=openai_asr` 筛选、Admin ASR analytics 能看到 `openai_asr`。
- 默认演示路径仍保留 demo fallback；真实 ASR 路径必须显式打开，避免没有 key 时影响普通 smoke。
- 文档已补真实 ASR `.env`、运行命令和失败排查口径。

真实 Key 环境验收仍需在有可用 key 的机器执行；执行通过后再把“真实 ASR Key 环境验收”从后续项里移除。