一、阶段背景StarMate 已具备与通义千问后端的文字对话能力支持默认、老师、朋友、导师等多种人设并允许用户自定义人设。在孤独症干预与家庭陪伴场景中团队通过试用与教师反馈发现部分使用者阅读困难对语音输入、语音反馈的接受度明显高于纯文字同时家长希望切换「老师 / 朋友」时不仅文字语气变化听到的声音也应随之变化以增强沉浸感与角色认同。本次确定要做哪些能力、验收标准是什么、技术路线选哪条。二、本阶段分步工作第一步场景调研与目标确认梳理现有对话页能力文字发送、人设菜单、会话重置、自定义人设等。在此基础上明确增量目标——语音输入STT 与 语音输出TTS且 TTS 需与当前选中的人设绑定。第二步需求拆解与验收标准将目标拆为五项可验证需求。其一AI 回复应支持自动朗读并允许用户一键关闭避免干扰课堂环境。其二不同人设听感应可区分至少满足「男声 / 女声 / 沉稳 / 活泼 / 童声 / 大叔」等差异不能出现菜单标注与播放效果严重不符。其三用户可通过麦克风完成提问说话结束后得到识别文本并进入既有聊天流程。其四无麦克风权限、后端未启动、识别失败、合成失败等情况需有简短中文提示不能长时间无反馈。其五原有文字聊天、人设切换、自定义人设、重置对话等功能不得回退。本步仅形成需求清单与验收描述尚未进入开发。第三步技术路线对比方案 A纯本机语音。 使用 Android 系统TextToSpeech与SpeechRecognizer优点是不改 Flask 后端、接入快适合两周内出原型缺点是各厂商中文音色命名混乱难以保证「导师 女声」稳定成立同性别人设之间 pitch、rate 调节后差别仍有限。本阶段结论可作为流程验证不宜作为最终音色方案。方案 B云端语音 本机兜底。 在 StarMate_Backend 增加识别与合成接口复用项目已有 DashScope 密钥聊天仍走POST /api/chat/send。识别拟用 Paraformer合成拟用 CosyVoice按人设固定声线与语气指令云端失败时回退系统 TTS。第四步人设与合规边界产品曾希望支持「动画角色」风格音色。本阶段调研结论公开 API 无法提供版权角色原声风格模仿也不稳定易引发「名不副实」投诉。故在需求文档中明确对外菜单改为 豪爽大叔、星星童伴 等原创称呼内部 persona key如guangtouqiang可暂保留避免数据库迁移。具体 CosyVoice 声线映射留待第二阶段实现。第六步风险识别与应对预案识别到四类风险并写对策方向依赖 PC 运行后端文档化启动步骤与真机 IP 配置云端合成耗时与失败预案为超时控制、文本截断、本机兜底动画版权与预期管理原创人设 风格化语气不承诺原声模拟器无麦克风语音识别以真机为准模拟器可测文字 TTS。这些预案在后续本阶段只记录。三、本阶段产出与边界产出物包括语音能力目标说明、五项需求与验收标准、技术选型报告本机 vs 云端、架构草图、人设命名策略、风险清单。明确未做未新增transcribe/synthesize路由未编写persona_tts.py未修改ChatPage与ChatViewModel的语音流程未进行真机联调与性能测试。
