Files
dreamweaver/docs/product/voice-co-creation-mode-incremental-prd.md

34 KiB
Raw Blame History

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 思路,而不是写死单一供应商
  • 允许首版先只接一套最稳组合,但系统边界要为后续扩展留口

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

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

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 环境仍需验收。能力层仍至少包含:

  • asrspeech_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 Snapshot2026-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 文本后调用 TTSTTS 失败保留文本响应 记录 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_confidenceintent_confidence 会触发确认,支持继续、重说、改文本 打磨确认文案和移动端操作密度
FR-007 分段插图节点 Partial 当前支持结束后统一封面补全,并为 asset job 接回统一 trace 后续评估关键段落插图,不进当前 P0
FR-008 分支剧情 Deferred 当前状态模型不阻断未来扩展,但未实现分叉体验 保持 P2Phase 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 Backlog2026-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 SamplesP2 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 OptionsP2 Seed

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

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

Phase A Alpha Execution Update2026-04-25

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

  • 已完成 #45voice analytics 支持 provider 查询参数,可按转写来源筛选 turn、事件和会话集合。
  • 已完成 #46voice 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 Update2026-05-06

本轮拉取远端 main0ccfd00 chore: update frontend tooling and Chinese copy 后继续收束 Alpha 运营可解释性:

  • 已完成 #47管理端 Provider 运营摘要现在会把 Voice Session 上传转写的 ASR 成功/失败纳入 capability=asr 聚合。
  • 管理端摘要新增 voice_session_countvoice_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.pygeneration_jobs.py、ASR service 和 Voice Studio 的拆分候选、风险信号和建议顺序;并已先把管理端跨用户 Provider/ASR 摘要拆到 admin_provider_analytics.py
  • 已完成 #50演示 checklist、demo package、3 分钟 pitch、PRD 和技术方案已统一口径Voice Studio 是 Phase A AlphaASR 摘要已进入管理端,当前代码 Docker 重建和 voice smoke 已完成。

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

Phase A Alpha ASR Key Validation Prep2026-06-01

  • 已检查 openai_asr 接线:适配器通过 ASR Provider Router 被 Voice Session 上传回合调用Provider 默认配置读取 OPENAI_API_KEY、可选 OPENAI_API_BASEVOICE_TRANSCRIPTION_MODELVOICE_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 环境验收”从后续项里移除。