Implement unified story generation flow

docs/planning/interview-pitch.md

@@ -48,20 +48,22 @@ AI 生成产品最大的问题不是“能不能调模型”，而是结果不
 
 我把它拆成四个概念：
 
-- Capability：产品需要的 AI 能力，例如文本、图片、语音、绘本结构
+- Capability：产品需要的 AI 能力，例如文本、图片、语音合成、语音识别、绘本结构
 - Provider：某个能力下的供应商配置，例如 Gemini、OpenAI、CQTAI、MiniMax
 - Adapter：具体 API 调用实现
 - Routing Policy：如何按优先级、成本、延迟或轮询选择 Provider
 
 这样用户看到的是稳定的产品能力，系统内部再决定具体调用哪个模型或供应商。
 
+语音共创 Alpha 也沿用这套分层：孩子可以通过 Voice Studio 用文本降级或上传语音参与故事，系统把 ASR、对话生成和 TTS 都当成可观测能力，而不是写死在页面里。
+
 ---
 
 ## 2:35 - 3:00 当前成果和下一步
 
-目前本地 Docker 可以跑通完整链路，并且有 smoke 脚本验证健康检查、登录、生成、资产重试、故事列表和 Provider 能力分层。
+目前本地 Docker 运行栈可以跑通完整链路，并且有 smoke 脚本验证健康检查、登录、生成、资产重试、故事列表、Provider 能力分层和 Voice Studio Alpha。之前镜像重建被 Docker Hub / npm registry 链路卡住，我把基础镜像和 npm registry 做成可配置后，当前代码已经完成 `docker compose up -d --build` 和重建后 voice smoke。
 
-现在 generation job 已经能查询完整事件流，包括 workflow、资产补全和 provider 调用；用户端和管理端都能展示生成轨迹，也能看到 provider 成功率、耗时和成本视角。
+现在 generation job 已经能查询完整事件流，包括 workflow、资产补全和 provider 调用；用户端和管理端都能展示生成轨迹，也能看到 provider 成功率、耗时和成本视角。Voice Studio 仍定位为 Phase A Alpha：它验证回合式语音共创、文本 fallback、低置信度确认、TTS 回复和保存为正式 Story，不把它包装成实时语音最终形态。
 
 我希望通过这个项目展示的是：我不只是会接 AI API，而是能把不确定的模型能力收敛成稳定、可解释、可恢复的产品体验。
 
@@ -81,6 +83,10 @@ AI 生成产品最大的问题不是“能不能调模型”，而是结果不
 
 它让用户不需要理解模型供应链，只感知稳定能力；同时让产品拥有者能控制成本、失败降级和供应商切换。
 
+### 语音共创现在做到什么程度？
+
+它是 Phase A Alpha，已经能演示创建会话、文本 fallback、上传语音转写、系统接着讲、低置信度确认、TTS 回复、会话恢复和 finalize 保存到故事库。当前不做实时打断和全双工对话，下一步先补真实 ASR Key 环境验收。
+
 ### 这个项目下一步怎么上线？
 
-我已经把当前轻量 job/event 模型迁移到后台 worker，并打通了前端进度轮询、取消/重试队列和管理台当前环境运营视图；下一步会补跨环境 Provider 汇聚、断点续跑和更完整监控。生产上线前还需要补真实用户鉴权配置、密钥管理和部署策略。
+我已经把当前轻量 job/event 模型迁移到后台 worker，并打通了前端进度轮询、取消/重试队列、管理台当前环境运营视图和 ASR 摘要；下一步会补真实 ASR 环境验收、跨环境 Provider 汇聚、断点续跑和更完整监控。生产上线前还需要补真实用户鉴权配置、密钥管理和部署策略。