2026山东大学软件学院项目实训（五）

一、阶段背景

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的语音流程；未进行真机联调与性能测试。