最近“和虚拟角色语音聊天”的AI陪伴软件热度不低标题里提到的“AI伊蕾娜语音对话”就是很典型的一类用户对着手机说话AI以某个角色的口吻回复并且能记住之前的聊天内容。这类产品体验上很炫但技术拆开看并不神秘核心就是 ASR语音转文字 LLM大模型对话 TTS文字转语音 记忆模块 的组合。这篇文章面向想要自己动手实现类似功能的人。我会从架构、模块选型、代码示例、部署测试、性能与合规几个角度展开。看完之后你可以照着搭一个最小可运行的“手机语音陪伴AI”也可以把里面的选型思路套用到自己的项目中。由于这类软件没有统一的公开源码下面给出的实现方案是基于主流开源组件和通用接口的整合方案。实际落地时你可以根据自己的硬件条件和接口成本替换对应模块。1. 核心能力速览能力项实现方案说明语音识别ASRWhisper / FunASR / Vosk / 云端ASR把手机录制的语音转成文本对话生成LLM商业API / 开源本地模型负责角色扮演、多轮对话、回复生成语音合成TTSEdge-TTS / GPT-SoVITS / CosyVoice把回复文本转成语音可控制音色角色人设System Prompt 人设描述让模型以“伊蕾娜”之类角色口吻回复短期记忆上下文窗口拼接同一段对话内保持话题连续长期记忆SQLite / 向量数据库跨天记住用户信息和历史话题手机端WebApp / 小程序 / 原生App采集语音、播放回复、显示对话接口设计HTTP / WebSocket手机与服务端之间的音频和文本传输内容审核关键词过滤 模型输出校验公开运营必须加审核机制2. 适用场景与使用边界先说适用场景。这类系统最直接的使用方式是角色陪伴和闲聊互动用户喜欢某个虚拟角色希望和它语音聊天或者用来做外语口语练习让AI用设定的角色和用户对话再或者作为IP官方互动应用给粉丝提供和角色对话的入口。对开发者来说这个链路也适合做技术验证单独测试ASR的识别率、LLM的人设保持能力、TTS的合成音色或者验证记忆模块在长对话中的效果都可以拿这套架构做实验台。同样要明确不合适的场景。第一不要把这类聊天软件包装成心理咨询、医疗建议或法律咨询工具虚拟角色没有专业资质也没有责任能力用户如果依赖它做决策会出问题。第二不要拿未经授权的真人声音、真人形象、商业角色去做交互尤其涉及真实姓名、照片、声音克隆时必须先获得授权。第三不要把这个能力用于生成或传播任何违法违规内容不要试图绕过平台的审核机制。这里特别说一下合规边界。一个可以公开运营的AI语音陪伴软件至少要包含三层审核输入端的关键词和敏感内容过滤输出端的内容安全校验以及角色设定本身的合规审查。如果你用的是动漫角色“伊蕾娜”这种已有IP形象正式发布前要确认IP授权链条是否完整个人学习开发则不要用于商业宣传。另外用户语音数据和个人信息属于敏感数据采集、存储、传输都要遵循隐私保护要求不能随意把数据交给第三方或用来训练模型。3. 整体技术架构这个系统的完整链路可以拆成下面几步。手机端只负责“声音进来、声音出去”核心计算都在服务端完成所以手机本身不需要很强的AI算力用户说话 → 手机录音 → 音频上传 → ASR识别成文本 → 带上记忆和角色人设交给LLM → LLM生成回复文本 → TTS合成回复音频 → 音频返回手机 → 手机播放如果按模块划分服务端大概会包含这几个组件网关服务接收手机上传的音频返回合成后的MP3/WAV文件同时管理用户会话。ASR服务支持wav/mp3/m4a等常见格式可以做成单独进程也可以和主服务同进程。对话引擎接收ASR文本、用户ID、会话ID拼接人设Prompt和历史记忆调用LLM输出回复文本。记忆服务按用户ID保存对话记录、身份信息、偏好信息在对话前做检索和摘要。TTS服务把回复文本合成语音缓存高频回复音频减少重复计算。审核模块输入/输出文本经过安全过滤音频若需要做内容监听则加在后处理中。这种设计的优势是可以分别替换模块。比如一开始用云端ASRTTS最快跑通后面本地能力够了再切到开源模型或者主服务用FastAPI写ASR单独用Whisper封装一个HTTP服务互不影响。4. 环境准备与前置条件搭建这套系统前先准备好开发环境。以下是一份通用检查清单具体版本以你自己选型为准操作系统Windows / Linux / macOS 都可以。长期跑服务建议用Linux服务器显存和进程管理都更稳。开发语言推荐 Python 3.10ASR、LLM、TTS 这三个生态里Python的集成最省事。音频处理安装 ffmpeg用于格式转换、降采样、音频截断。ASR和TTS很多工具链都依赖它。GPU/CPU如果全部用云端API普通开发机就能完成如果使用本地Whisper或开源TTS/LLM建议准备NVIDIA显卡。显存需求取决于模型体积通常7B参数模型在量化后也需要约8GB左右显存做推理不量化则需要更多。实际占用要以本机测试为准。手机端准备一台能录音、能放音频的Android或iPhone调试阶段用浏览器WebApp最方便。依赖管理用conda或venv创建独立Python环境避免和系统环境冲突。在实际部署时建议分阶段检查先确认录音上传能通再确认ASR能转文字再确认LLM能回复最后接上TTS。每加一个节点就验证一次不要一上来把所有模块都接好再排错。这样出问题时问题范围会被限制在单一节点内。5. 语音识别ASR模块ASR是整个链路里第一个决定用户体验的模块。识别如果太慢或者错误率高后面LLM再强也救不回来。常见的方案分为本地开源和云端API两类。WhisperOpenAI本地部署支持多语言模型分tiny/base/small/medium/large尺寸越大越准资源占用越高。FunASR阿里开源中文场景优化较好支持流式识别适合需要低延迟的场景。Vosk轻量级离线识别可以在低配置设备甚至部分手机上跑但词表覆盖和复杂句式准确率需要实测。云端ASR集成方便延迟通常不高但要按调用量付费且音频数据会经过第三方服务要注意隐私合规。下面是一个通用HTTP请求调用本地ASR服务的示例实际字段名要以你部署的服务为准import requests # 实际URL、字段名要以你部署的ASR服务为准 resp requests.post( http://127.0.0.1:8001/asr, files{audio: open(input.wav, rb)}, data{language: zh, encode: true}, timeout30, ) print(resp.json()) # 预期返回: {text: 你好今天天气怎么样}如果使用OpenAI Whisper本地加载可以写成import whisper model whisper.load_model(small) result model.transcribe(input.wav, languagezh) print(result[text])注意首次运行会下载模型文件耗时取决于网络。建议先拿一段16k单声道、长度在10到30秒的清晰中文语音测试确认识别无误后再做复杂场景。在手机端上音频通常不是16k wav格式所以服务端最好先统一转码。做法是用ffmpeg把上传的m4a/mp3转成16k wav再送给ASRffmpeg -i input.m4a -ar 16000 -ac 1 -y input.wav这一步能显著提高识别稳定性和兼容性。如果用户录音环境嘈杂VAD语音活动检测和降噪处理也最好加在ASR之前避免把静音段或背景音当成有效语音。6. 对话大模型LLM与角色人设LLM是“角色感”的来源。要让模型表现为“伊蕾娜”或者其他虚拟角色不需要重新训练模型核心是写好system prompt。一个比较有效的人设Prompt框架是角色身份 外观性格 说话风格 对话目标 限制条件。示例你是「伊蕾娜」一位灰发灰瞳的魔女旅行者。 性格自信甚至有点自恋但内心善良喜欢帮助别人。 说话风格轻松、俏皮偶尔吐槽使用中文口语化表达。 目标像朋友一样陪用户聊天主动询问用户近况。 限制不提及自己是AI不输出违法、色情、暴力内容不提供医疗和财务建议。调用时把这段system prompt和对话历史一起发给LLMfrom openai import OpenAI client OpenAI( base_urlhttps://api.example.com/v1, api_keyyour-api-key ) messages [ {role: system, content: ROLE_PROMPT}, {role: user, content: 你好呀今天陪我聊聊天吧}, {role: assistant, content: 好啊我正好今天旅行到一个有趣的小镇。}, {role: user, content: 那你给我讲讲这个小镇吧}, ] resp client.chat.completions.create( modelyour-model-name, messagesmessages, temperature0.8, max_tokens200, ) print(resp.choices[0].message.content)多轮对话的关键是管理上下文。短期记忆可以直接把最近N轮对话内容塞进messages但别无限塞否则会超过模型上下文长度。一般做法是只保留最近10到20轮更早的内容提炼成“历史摘要”再放进去。这样角色既不会忘记关键信息也不会让单次请求过长。如果你的环境无法调用云端大模型API也可以部署开源模型。以常见的Llama系或Qwen系为例部署时选择量化版能明显降低显存占用。但量化会一定程度影响生成质量实际用哪个版本要用测试对话来对比。还有一个容易被忽略的点角色人设的稳定性需要反复调不要改一次Prompt就上线最好准备一组固定的测试用例每次改Prompt都跑一遍对比“是否崩角色”。7. 语音合成TTS模块TTS决定用户听到的“声音像不像这个角色”。最简单的方案是使用现成在线TTS服务或者Edge-TTS这类便捷接口如果对音色有更高要求可以训练或使用开源的音色克隆项目例如GPT-SoVITS、CosyVoice。使用开源音色克隆之前必须确认训练数据的来源合法尤其不能未经授权使用真人声音。一个Edge-TTS调用示例轻量且支持多种中文发音人import edge_tts import asyncio async def main(): tts edge_tts.Communicate( 你好我是伊蕾娜今天想聊点什么, zh-CN-XiaoyiNeural ) await tts.save(reply.mp3) asyncio.run(main())在服务端每次生成回复音频后建议做两层优化。第一层是缓存高频问题例如“你好”“你是谁”的回复音频可以落地保存下次直接返回减少TTS调用。第二层是限流和超时TTS合成如果失败要能回退到文本消息让用户先看到文字不至于整个对话流程卡死。需要提醒的是TTS和声音克隆是双刃剑。如果合成的音色近似某个真实人物或商业IP角色发布或传播前必须获得授权。将这类能力用于诈骗、伪造、骚扰等行为是违法的。开发者在工程上也要做好水印、来源标记和使用记录防止被滥用。8. 记忆功能实现“有记忆”是这类陪伴软件和普通聊天机器人的最大差别。记忆分两层短期记忆和长期记忆。短期记忆指当前会话内的上下文。实现最简单就是上一节说的消息列表拼接。但长期记忆需要把跨会话的信息存储下来。落地方式有两类一类是结构化数据库适合保存用户基本信息、偏好、关系状态另一类是向量数据库适合保存“可检索的历史话题内容”通过语义相似度召回相关记忆。先用SQLite实现简单的长期记忆存储import sqlite3 conn sqlite3.connect(memory.db) conn.execute( CREATE TABLE IF NOT EXISTS user_memory ( id INTEGER PRIMARY KEY AUTOINCREMENT, user_id TEXT NOT NULL, memory_type TEXT NOT NULL, content TEXT NOT NULL, created_at DATETIME DEFAULT CURRENT_TIMESTAMP ) ) # 保存一条记忆 conn.execute( INSERT INTO user_memory (user_id, memory_type, content) VALUES (?, ?, ?), (user_001, preference, 用户喜欢旅行主题的聊天内容), ) conn.commit()对话开始时可以先查询当前用户的历史记忆拼接进system prompt或作为上下文参考rows conn.execute( SELECT content FROM user_memory WHERE user_id? ORDER BY created_at DESC LIMIT 10, (user_001,) ).fetchall() memory_text \n.join(row[0] for row in rows)更进阶的做法是加入记忆摘要。当用户对话超过一定轮次用LLM生成一段简短摘要覆盖对话中的关键信息用户的心情、提到的人名、偏好等存入数据库。之后每次对话前把最近摘要和历史热门记忆一起交给LLM。这样既不需要把所有历史消息都塞进上下文又能让角色在多次会话之间表现得更像“记得你”。还要注意记忆不是越多越好。要提供“忘记”和“纠正”机制用户说“这个不要记住”时删除对应记录用户主动提供的新信息可以覆盖旧信息。对敏感信息代码层要做脱敏和权限控制不能让任何用户都能读到别人的记忆。数据库层面的定期清理也很重要长期不活跃用户的隐私数据应设置保留期限。9. 手机端接入与端侧体验手机端最省事的做法是做一个PWA WebApp因为不需要上架应用商店用浏览器就能直接打开支持录音播放非常适合开发调试。正式上架可以再做微信小程序或Android/iOS壳子但业务层API完全复用。手机端要处理的事情并不多采集语音通过浏览器MediaRecorder或移动端录音能力录制用户语音生成mp3/m4a/wav文件。上传和监听上传到后端接口期间可以显示“正在识别”的等待状态。播放音频拿到服务端返回的音频文件后用HTMLAudio或原生播放器播放。文字兜底同时显示回复文本即使音频播放失败用户也不会完全丢失信息。会话ID管理进入页面生成或获取一个userId用于服务端记忆模块区分用户。浏览器录音的基础代码示例async function startRecording() { const stream await navigator.mediaDevices.getUserMedia({ audio: true }); const recorder new MediaRecorder(stream); const chunks []; recorder.ondataavailable (e) chunks.push(e.data); recorder.onstop async () { const blob new Blob(chunks, { type: audio/mp4 }); const formData new FormData(); formData.append(audio, blob, input.m4a); formData.append(user_id, userId); const resp await fetch(/api/chat, { method: POST, body: formData }); const data await resp.json(); document.getElementById(reply-text).innerText data.reply_text; new Audio(data.audio_url).play(); }; recorder.start(); }一个很常见的问题是手机录音格式不统一。建议统一由手机端把录音转成m4a或mp3上传服务端用ffmpeg转码成16k wav做ASR。不要指望所有浏览器都输出wav尤其是在微信内置浏览器里格式兼容性更是要认真测试。延迟是手机端体验的关键。用户说完话后希望1到3秒内听到回复。如果链路每一步都是同步调用很难控制总延迟。优化方法是ASR选流式接口用户说话的同时就开始识别LLM设置合理的max_tokens不要让它生成过长回复TTS优先选延迟低的接口而不是追求极致音色。总的原则是“能用文本结束的地方绝不卡在音频上”。10. 接口 API 与批量任务服务端可以用FastAPI或Flask提供HTTP接口统一接收手机端的语音请求。下面是一个最小接口设计示例from fastapi import FastAPI, UploadFile, File, Form app FastAPI() app.post(/api/chat) async def chat(audio: UploadFile File(...), user_id: str Form(...)): # 1. 保存音频到临时目录 audio_path f./tmp/{user_id}_{timestamp}.m4a with open(audio_path, wb) as f: f.write(await audio.read()) # 2. 转码并调用ASR wav_path ffmpeg_convert(audio_path) text asr_recognize(wav_path) # 3. 查询记忆并调用LLM memory load_memory(user_id) reply_text llm_chat(user_id, text, memory) # 4. TTS合成回复 reply_audio tts_save(reply_text) # 5. 保存本轮对话到记忆库 save_memory(user_id, text, reply_text) return {reply_text: reply_text, audio_url: f/media/{reply_audio}}注意这只是示例框架实际代码里要做异常处理和超时控制。如果是单机小范围使用直接同步调用没问题如果用户量大了语音转写和TTS这种耗时任务应该放入任务队列例如Celery或消息队列让请求先返回“正在处理”前端轮询结果。批量任务方面这类应用中最常见的是三种离线历史对话摘要、记忆归档、音频质检。对话摘要和记忆归档可以在每天低峰期用定时任务跑把前一天的对话记录摘要后压缩入库音频质检则是定期抽取部分合成音频做人工听感校验。这些任务都和生产接口分离避免影响在线延迟。多人同时使用时还要做会话隔离。每个请求都必须带上唯一的userIdASR、LLM、TTS无状态化记忆服务按userId加锁读写避免并发写库造成数据错乱。若使用消息队列消费者要能并发处理不同用户的请求同时防止同一用户的多个请求乱序。11. 资源占用与性能观察资源占用主要看三块ASR、LLM、TTS。ASR方面Whisper的large模型在GPU上推理时显存占用明显高于small/base具体取决于音频长度和模型量化情况。更稳妥的判断是先用small/base模型跑通如果识别率不够再升级。云端ASR则不需要关注本机占用只需要关注并发上限和单次调用的限制。LLM是最大的资源消耗点。显存占用和模型参数量、量化方式、上下文长度、并发数都相关不能笼统说“固定占几个G”。观察方法是部署后启动服务用nvidia-smi -l 1查看或用gpustat定时记录。测试时最好用固定长度的对话请求多测几轮取显存占用的稳定值而不是峰值。TTS中大规模神经TTS通常需要GPU轻量TTS则可以用CPU跑。具体能不能CPU跑要看模型实现建议查看项目文档说明。音频合成是计算密集任务长时间运行时也容易产生显存碎片问题建议定期重启服务或做显存释放。性能优化的通用手段包括模型服务独立部署和业务服务分开避免相互拖慢。接口层加缓存重复音频/重复文本直接命中缓存。LLM请求并发控制防止同一个显卡上多个请求把显存打满后OOM。ASR和LLM采用流式传输减少“说完话等结果”的时间。使用gunicorn/uvicorn多worker或多副本时设置合理的并发数不要盲目调大。音频文件定期清理避免临时目录占满磁盘。12. 常见问题与排查方法问题现象可能原因排查方式解决方案手机录音上传后ASR返回空文本音频格式不支持或静音过多用ffmpeg查看音频格式和时长本地播放确认有声音统一转16k wav提高录音音量增加VAD检测ASR中文识别不准模型太小或存在方言/噪声换更大模型或多测几条干净语音升级模型用FunASR等中文优化模型后端做降噪LLM回复不像角色system prompt太弱或长度不够打开完整请求日志看messages内容重写人设Prompt增加角色示例对话回复声音不像预期TTS音色选错对比不同发音人/音色模型更换TTS音色做声音克隆需授权用户说之前聊过但AI不记得长期记忆没有写入或检索失败查数据库是否有记录查Prompt是否包含记忆修复记忆写入把记忆拼进system prompt页面“正在识别”卡住ASR服务超时看服务端日志和网络状态加超时和重试优化转码流程多人使用时记忆串号userId未正确传递或缓存污染检查请求参数和缓存key统一使用userId做隔离显存不足导致服务崩溃并发过大或模型过大用nvidia-smi观察显存量化模型、降低并发、换小模型TTS合成失败导致整个对话失败音频服务异常或网络超时看TTS日志TTS失败时先返回文本音频异步补手机端没有声音播放器未初始化或格式不支持检查浏览器控制台网络请求换通用mp3格式确认音频CORS配置13. 最佳实践与使用建议先跑通最小链路再逐步加功能。最初版本可以用“文本聊天纯文本回复”的方式验证LLM人设效果确认角色口吻满意后再接入ASR和TTS这样排查范围更小。把人设Prompt版本化管理。角色说话风格、记忆力表现经常需要反复调整用配置文件或Prompt模板管理不要硬编码在业务代码里。建立“话题摘要”机制。超过上下文长度的老对话先让LLM做摘要再丢弃原始消息保证长会话不爆炸。记忆和隐私分开处理。用户明确不想保存的内容必须删除默认只保存必要信息并在隐私政策里说明。加日志和可观测性。每条语音请求记录耗时、识别文本、生成文本、音频大小方便定位问题。日志中要注意避免记录完整敏感语音必要情况下只保留转写后的文本摘要。部署时限制接口访问范围。服务端API不要暴露到公网或用Token鉴权、IP白名单防止被刷接口。公开运营必须上内容审核。输入端过滤违规词输出端校验生成内容音频和文本日志留存出现风险内容能追溯。使用角色IP和真人声音前确认授权。个人学习项目也要避免把角色语音包上传到公开仓库或作为付费资源传播。最后的输出一定要做人工抽查。尤其是TTS合成出来带情绪的长句音色稳定性需要人工听感判断不能只看自动评分指标。14. 总结与下一步这篇文章从架构、选型、代码示例、部署和排错几个层面拆解了“手机端AI语音陪伴聊天软件”的实现方式。核心链路并不复杂关键是把ASR、LLM、TTS、记忆这四个模块各自选好型、接好口再处理好延迟和并发。如果你准备自己动手建议第一优先级验证三件事ASR对中文语音的识别准确率、LLM对角色人设的保持度、TTS合成音频的自然度和延迟。这三个点直接决定用户愿不愿意继续聊下去。最容易踩的坑是记忆模块的“过度嵌入”把大量历史记录硬塞进Prompt导致超长和成本上升正确的做法是摘要向量检索分段读取。下一步可以做的扩展方向包括给记忆模块加入向量检索以支持语义回忆增加多角色切换和人格配置面板在服务端加入流式音频通讯WebSocket来进一步降低延迟以及接入微信或飞书等聊天平台的机器人接口做跨端验证。希望这篇拆解能帮你快速搭建出第一版可用的AI语音陪伴系统。
手机端AI语音陪伴系统：ASR+LLM+TTS全链路实现拆解
最近“和虚拟角色语音聊天”的AI陪伴软件热度不低标题里提到的“AI伊蕾娜语音对话”就是很典型的一类用户对着手机说话AI以某个角色的口吻回复并且能记住之前的聊天内容。这类产品体验上很炫但技术拆开看并不神秘核心就是 ASR语音转文字 LLM大模型对话 TTS文字转语音 记忆模块 的组合。这篇文章面向想要自己动手实现类似功能的人。我会从架构、模块选型、代码示例、部署测试、性能与合规几个角度展开。看完之后你可以照着搭一个最小可运行的“手机语音陪伴AI”也可以把里面的选型思路套用到自己的项目中。由于这类软件没有统一的公开源码下面给出的实现方案是基于主流开源组件和通用接口的整合方案。实际落地时你可以根据自己的硬件条件和接口成本替换对应模块。1. 核心能力速览能力项实现方案说明语音识别ASRWhisper / FunASR / Vosk / 云端ASR把手机录制的语音转成文本对话生成LLM商业API / 开源本地模型负责角色扮演、多轮对话、回复生成语音合成TTSEdge-TTS / GPT-SoVITS / CosyVoice把回复文本转成语音可控制音色角色人设System Prompt 人设描述让模型以“伊蕾娜”之类角色口吻回复短期记忆上下文窗口拼接同一段对话内保持话题连续长期记忆SQLite / 向量数据库跨天记住用户信息和历史话题手机端WebApp / 小程序 / 原生App采集语音、播放回复、显示对话接口设计HTTP / WebSocket手机与服务端之间的音频和文本传输内容审核关键词过滤 模型输出校验公开运营必须加审核机制2. 适用场景与使用边界先说适用场景。这类系统最直接的使用方式是角色陪伴和闲聊互动用户喜欢某个虚拟角色希望和它语音聊天或者用来做外语口语练习让AI用设定的角色和用户对话再或者作为IP官方互动应用给粉丝提供和角色对话的入口。对开发者来说这个链路也适合做技术验证单独测试ASR的识别率、LLM的人设保持能力、TTS的合成音色或者验证记忆模块在长对话中的效果都可以拿这套架构做实验台。同样要明确不合适的场景。第一不要把这类聊天软件包装成心理咨询、医疗建议或法律咨询工具虚拟角色没有专业资质也没有责任能力用户如果依赖它做决策会出问题。第二不要拿未经授权的真人声音、真人形象、商业角色去做交互尤其涉及真实姓名、照片、声音克隆时必须先获得授权。第三不要把这个能力用于生成或传播任何违法违规内容不要试图绕过平台的审核机制。这里特别说一下合规边界。一个可以公开运营的AI语音陪伴软件至少要包含三层审核输入端的关键词和敏感内容过滤输出端的内容安全校验以及角色设定本身的合规审查。如果你用的是动漫角色“伊蕾娜”这种已有IP形象正式发布前要确认IP授权链条是否完整个人学习开发则不要用于商业宣传。另外用户语音数据和个人信息属于敏感数据采集、存储、传输都要遵循隐私保护要求不能随意把数据交给第三方或用来训练模型。3. 整体技术架构这个系统的完整链路可以拆成下面几步。手机端只负责“声音进来、声音出去”核心计算都在服务端完成所以手机本身不需要很强的AI算力用户说话 → 手机录音 → 音频上传 → ASR识别成文本 → 带上记忆和角色人设交给LLM → LLM生成回复文本 → TTS合成回复音频 → 音频返回手机 → 手机播放如果按模块划分服务端大概会包含这几个组件网关服务接收手机上传的音频返回合成后的MP3/WAV文件同时管理用户会话。ASR服务支持wav/mp3/m4a等常见格式可以做成单独进程也可以和主服务同进程。对话引擎接收ASR文本、用户ID、会话ID拼接人设Prompt和历史记忆调用LLM输出回复文本。记忆服务按用户ID保存对话记录、身份信息、偏好信息在对话前做检索和摘要。TTS服务把回复文本合成语音缓存高频回复音频减少重复计算。审核模块输入/输出文本经过安全过滤音频若需要做内容监听则加在后处理中。这种设计的优势是可以分别替换模块。比如一开始用云端ASRTTS最快跑通后面本地能力够了再切到开源模型或者主服务用FastAPI写ASR单独用Whisper封装一个HTTP服务互不影响。4. 环境准备与前置条件搭建这套系统前先准备好开发环境。以下是一份通用检查清单具体版本以你自己选型为准操作系统Windows / Linux / macOS 都可以。长期跑服务建议用Linux服务器显存和进程管理都更稳。开发语言推荐 Python 3.10ASR、LLM、TTS 这三个生态里Python的集成最省事。音频处理安装 ffmpeg用于格式转换、降采样、音频截断。ASR和TTS很多工具链都依赖它。GPU/CPU如果全部用云端API普通开发机就能完成如果使用本地Whisper或开源TTS/LLM建议准备NVIDIA显卡。显存需求取决于模型体积通常7B参数模型在量化后也需要约8GB左右显存做推理不量化则需要更多。实际占用要以本机测试为准。手机端准备一台能录音、能放音频的Android或iPhone调试阶段用浏览器WebApp最方便。依赖管理用conda或venv创建独立Python环境避免和系统环境冲突。在实际部署时建议分阶段检查先确认录音上传能通再确认ASR能转文字再确认LLM能回复最后接上TTS。每加一个节点就验证一次不要一上来把所有模块都接好再排错。这样出问题时问题范围会被限制在单一节点内。5. 语音识别ASR模块ASR是整个链路里第一个决定用户体验的模块。识别如果太慢或者错误率高后面LLM再强也救不回来。常见的方案分为本地开源和云端API两类。WhisperOpenAI本地部署支持多语言模型分tiny/base/small/medium/large尺寸越大越准资源占用越高。FunASR阿里开源中文场景优化较好支持流式识别适合需要低延迟的场景。Vosk轻量级离线识别可以在低配置设备甚至部分手机上跑但词表覆盖和复杂句式准确率需要实测。云端ASR集成方便延迟通常不高但要按调用量付费且音频数据会经过第三方服务要注意隐私合规。下面是一个通用HTTP请求调用本地ASR服务的示例实际字段名要以你部署的服务为准import requests # 实际URL、字段名要以你部署的ASR服务为准 resp requests.post( http://127.0.0.1:8001/asr, files{audio: open(input.wav, rb)}, data{language: zh, encode: true}, timeout30, ) print(resp.json()) # 预期返回: {text: 你好今天天气怎么样}如果使用OpenAI Whisper本地加载可以写成import whisper model whisper.load_model(small) result model.transcribe(input.wav, languagezh) print(result[text])注意首次运行会下载模型文件耗时取决于网络。建议先拿一段16k单声道、长度在10到30秒的清晰中文语音测试确认识别无误后再做复杂场景。在手机端上音频通常不是16k wav格式所以服务端最好先统一转码。做法是用ffmpeg把上传的m4a/mp3转成16k wav再送给ASRffmpeg -i input.m4a -ar 16000 -ac 1 -y input.wav这一步能显著提高识别稳定性和兼容性。如果用户录音环境嘈杂VAD语音活动检测和降噪处理也最好加在ASR之前避免把静音段或背景音当成有效语音。6. 对话大模型LLM与角色人设LLM是“角色感”的来源。要让模型表现为“伊蕾娜”或者其他虚拟角色不需要重新训练模型核心是写好system prompt。一个比较有效的人设Prompt框架是角色身份 外观性格 说话风格 对话目标 限制条件。示例你是「伊蕾娜」一位灰发灰瞳的魔女旅行者。 性格自信甚至有点自恋但内心善良喜欢帮助别人。 说话风格轻松、俏皮偶尔吐槽使用中文口语化表达。 目标像朋友一样陪用户聊天主动询问用户近况。 限制不提及自己是AI不输出违法、色情、暴力内容不提供医疗和财务建议。调用时把这段system prompt和对话历史一起发给LLMfrom openai import OpenAI client OpenAI( base_urlhttps://api.example.com/v1, api_keyyour-api-key ) messages [ {role: system, content: ROLE_PROMPT}, {role: user, content: 你好呀今天陪我聊聊天吧}, {role: assistant, content: 好啊我正好今天旅行到一个有趣的小镇。}, {role: user, content: 那你给我讲讲这个小镇吧}, ] resp client.chat.completions.create( modelyour-model-name, messagesmessages, temperature0.8, max_tokens200, ) print(resp.choices[0].message.content)多轮对话的关键是管理上下文。短期记忆可以直接把最近N轮对话内容塞进messages但别无限塞否则会超过模型上下文长度。一般做法是只保留最近10到20轮更早的内容提炼成“历史摘要”再放进去。这样角色既不会忘记关键信息也不会让单次请求过长。如果你的环境无法调用云端大模型API也可以部署开源模型。以常见的Llama系或Qwen系为例部署时选择量化版能明显降低显存占用。但量化会一定程度影响生成质量实际用哪个版本要用测试对话来对比。还有一个容易被忽略的点角色人设的稳定性需要反复调不要改一次Prompt就上线最好准备一组固定的测试用例每次改Prompt都跑一遍对比“是否崩角色”。7. 语音合成TTS模块TTS决定用户听到的“声音像不像这个角色”。最简单的方案是使用现成在线TTS服务或者Edge-TTS这类便捷接口如果对音色有更高要求可以训练或使用开源的音色克隆项目例如GPT-SoVITS、CosyVoice。使用开源音色克隆之前必须确认训练数据的来源合法尤其不能未经授权使用真人声音。一个Edge-TTS调用示例轻量且支持多种中文发音人import edge_tts import asyncio async def main(): tts edge_tts.Communicate( 你好我是伊蕾娜今天想聊点什么, zh-CN-XiaoyiNeural ) await tts.save(reply.mp3) asyncio.run(main())在服务端每次生成回复音频后建议做两层优化。第一层是缓存高频问题例如“你好”“你是谁”的回复音频可以落地保存下次直接返回减少TTS调用。第二层是限流和超时TTS合成如果失败要能回退到文本消息让用户先看到文字不至于整个对话流程卡死。需要提醒的是TTS和声音克隆是双刃剑。如果合成的音色近似某个真实人物或商业IP角色发布或传播前必须获得授权。将这类能力用于诈骗、伪造、骚扰等行为是违法的。开发者在工程上也要做好水印、来源标记和使用记录防止被滥用。8. 记忆功能实现“有记忆”是这类陪伴软件和普通聊天机器人的最大差别。记忆分两层短期记忆和长期记忆。短期记忆指当前会话内的上下文。实现最简单就是上一节说的消息列表拼接。但长期记忆需要把跨会话的信息存储下来。落地方式有两类一类是结构化数据库适合保存用户基本信息、偏好、关系状态另一类是向量数据库适合保存“可检索的历史话题内容”通过语义相似度召回相关记忆。先用SQLite实现简单的长期记忆存储import sqlite3 conn sqlite3.connect(memory.db) conn.execute( CREATE TABLE IF NOT EXISTS user_memory ( id INTEGER PRIMARY KEY AUTOINCREMENT, user_id TEXT NOT NULL, memory_type TEXT NOT NULL, content TEXT NOT NULL, created_at DATETIME DEFAULT CURRENT_TIMESTAMP ) ) # 保存一条记忆 conn.execute( INSERT INTO user_memory (user_id, memory_type, content) VALUES (?, ?, ?), (user_001, preference, 用户喜欢旅行主题的聊天内容), ) conn.commit()对话开始时可以先查询当前用户的历史记忆拼接进system prompt或作为上下文参考rows conn.execute( SELECT content FROM user_memory WHERE user_id? ORDER BY created_at DESC LIMIT 10, (user_001,) ).fetchall() memory_text \n.join(row[0] for row in rows)更进阶的做法是加入记忆摘要。当用户对话超过一定轮次用LLM生成一段简短摘要覆盖对话中的关键信息用户的心情、提到的人名、偏好等存入数据库。之后每次对话前把最近摘要和历史热门记忆一起交给LLM。这样既不需要把所有历史消息都塞进上下文又能让角色在多次会话之间表现得更像“记得你”。还要注意记忆不是越多越好。要提供“忘记”和“纠正”机制用户说“这个不要记住”时删除对应记录用户主动提供的新信息可以覆盖旧信息。对敏感信息代码层要做脱敏和权限控制不能让任何用户都能读到别人的记忆。数据库层面的定期清理也很重要长期不活跃用户的隐私数据应设置保留期限。9. 手机端接入与端侧体验手机端最省事的做法是做一个PWA WebApp因为不需要上架应用商店用浏览器就能直接打开支持录音播放非常适合开发调试。正式上架可以再做微信小程序或Android/iOS壳子但业务层API完全复用。手机端要处理的事情并不多采集语音通过浏览器MediaRecorder或移动端录音能力录制用户语音生成mp3/m4a/wav文件。上传和监听上传到后端接口期间可以显示“正在识别”的等待状态。播放音频拿到服务端返回的音频文件后用HTMLAudio或原生播放器播放。文字兜底同时显示回复文本即使音频播放失败用户也不会完全丢失信息。会话ID管理进入页面生成或获取一个userId用于服务端记忆模块区分用户。浏览器录音的基础代码示例async function startRecording() { const stream await navigator.mediaDevices.getUserMedia({ audio: true }); const recorder new MediaRecorder(stream); const chunks []; recorder.ondataavailable (e) chunks.push(e.data); recorder.onstop async () { const blob new Blob(chunks, { type: audio/mp4 }); const formData new FormData(); formData.append(audio, blob, input.m4a); formData.append(user_id, userId); const resp await fetch(/api/chat, { method: POST, body: formData }); const data await resp.json(); document.getElementById(reply-text).innerText data.reply_text; new Audio(data.audio_url).play(); }; recorder.start(); }一个很常见的问题是手机录音格式不统一。建议统一由手机端把录音转成m4a或mp3上传服务端用ffmpeg转码成16k wav做ASR。不要指望所有浏览器都输出wav尤其是在微信内置浏览器里格式兼容性更是要认真测试。延迟是手机端体验的关键。用户说完话后希望1到3秒内听到回复。如果链路每一步都是同步调用很难控制总延迟。优化方法是ASR选流式接口用户说话的同时就开始识别LLM设置合理的max_tokens不要让它生成过长回复TTS优先选延迟低的接口而不是追求极致音色。总的原则是“能用文本结束的地方绝不卡在音频上”。10. 接口 API 与批量任务服务端可以用FastAPI或Flask提供HTTP接口统一接收手机端的语音请求。下面是一个最小接口设计示例from fastapi import FastAPI, UploadFile, File, Form app FastAPI() app.post(/api/chat) async def chat(audio: UploadFile File(...), user_id: str Form(...)): # 1. 保存音频到临时目录 audio_path f./tmp/{user_id}_{timestamp}.m4a with open(audio_path, wb) as f: f.write(await audio.read()) # 2. 转码并调用ASR wav_path ffmpeg_convert(audio_path) text asr_recognize(wav_path) # 3. 查询记忆并调用LLM memory load_memory(user_id) reply_text llm_chat(user_id, text, memory) # 4. TTS合成回复 reply_audio tts_save(reply_text) # 5. 保存本轮对话到记忆库 save_memory(user_id, text, reply_text) return {reply_text: reply_text, audio_url: f/media/{reply_audio}}注意这只是示例框架实际代码里要做异常处理和超时控制。如果是单机小范围使用直接同步调用没问题如果用户量大了语音转写和TTS这种耗时任务应该放入任务队列例如Celery或消息队列让请求先返回“正在处理”前端轮询结果。批量任务方面这类应用中最常见的是三种离线历史对话摘要、记忆归档、音频质检。对话摘要和记忆归档可以在每天低峰期用定时任务跑把前一天的对话记录摘要后压缩入库音频质检则是定期抽取部分合成音频做人工听感校验。这些任务都和生产接口分离避免影响在线延迟。多人同时使用时还要做会话隔离。每个请求都必须带上唯一的userIdASR、LLM、TTS无状态化记忆服务按userId加锁读写避免并发写库造成数据错乱。若使用消息队列消费者要能并发处理不同用户的请求同时防止同一用户的多个请求乱序。11. 资源占用与性能观察资源占用主要看三块ASR、LLM、TTS。ASR方面Whisper的large模型在GPU上推理时显存占用明显高于small/base具体取决于音频长度和模型量化情况。更稳妥的判断是先用small/base模型跑通如果识别率不够再升级。云端ASR则不需要关注本机占用只需要关注并发上限和单次调用的限制。LLM是最大的资源消耗点。显存占用和模型参数量、量化方式、上下文长度、并发数都相关不能笼统说“固定占几个G”。观察方法是部署后启动服务用nvidia-smi -l 1查看或用gpustat定时记录。测试时最好用固定长度的对话请求多测几轮取显存占用的稳定值而不是峰值。TTS中大规模神经TTS通常需要GPU轻量TTS则可以用CPU跑。具体能不能CPU跑要看模型实现建议查看项目文档说明。音频合成是计算密集任务长时间运行时也容易产生显存碎片问题建议定期重启服务或做显存释放。性能优化的通用手段包括模型服务独立部署和业务服务分开避免相互拖慢。接口层加缓存重复音频/重复文本直接命中缓存。LLM请求并发控制防止同一个显卡上多个请求把显存打满后OOM。ASR和LLM采用流式传输减少“说完话等结果”的时间。使用gunicorn/uvicorn多worker或多副本时设置合理的并发数不要盲目调大。音频文件定期清理避免临时目录占满磁盘。12. 常见问题与排查方法问题现象可能原因排查方式解决方案手机录音上传后ASR返回空文本音频格式不支持或静音过多用ffmpeg查看音频格式和时长本地播放确认有声音统一转16k wav提高录音音量增加VAD检测ASR中文识别不准模型太小或存在方言/噪声换更大模型或多测几条干净语音升级模型用FunASR等中文优化模型后端做降噪LLM回复不像角色system prompt太弱或长度不够打开完整请求日志看messages内容重写人设Prompt增加角色示例对话回复声音不像预期TTS音色选错对比不同发音人/音色模型更换TTS音色做声音克隆需授权用户说之前聊过但AI不记得长期记忆没有写入或检索失败查数据库是否有记录查Prompt是否包含记忆修复记忆写入把记忆拼进system prompt页面“正在识别”卡住ASR服务超时看服务端日志和网络状态加超时和重试优化转码流程多人使用时记忆串号userId未正确传递或缓存污染检查请求参数和缓存key统一使用userId做隔离显存不足导致服务崩溃并发过大或模型过大用nvidia-smi观察显存量化模型、降低并发、换小模型TTS合成失败导致整个对话失败音频服务异常或网络超时看TTS日志TTS失败时先返回文本音频异步补手机端没有声音播放器未初始化或格式不支持检查浏览器控制台网络请求换通用mp3格式确认音频CORS配置13. 最佳实践与使用建议先跑通最小链路再逐步加功能。最初版本可以用“文本聊天纯文本回复”的方式验证LLM人设效果确认角色口吻满意后再接入ASR和TTS这样排查范围更小。把人设Prompt版本化管理。角色说话风格、记忆力表现经常需要反复调整用配置文件或Prompt模板管理不要硬编码在业务代码里。建立“话题摘要”机制。超过上下文长度的老对话先让LLM做摘要再丢弃原始消息保证长会话不爆炸。记忆和隐私分开处理。用户明确不想保存的内容必须删除默认只保存必要信息并在隐私政策里说明。加日志和可观测性。每条语音请求记录耗时、识别文本、生成文本、音频大小方便定位问题。日志中要注意避免记录完整敏感语音必要情况下只保留转写后的文本摘要。部署时限制接口访问范围。服务端API不要暴露到公网或用Token鉴权、IP白名单防止被刷接口。公开运营必须上内容审核。输入端过滤违规词输出端校验生成内容音频和文本日志留存出现风险内容能追溯。使用角色IP和真人声音前确认授权。个人学习项目也要避免把角色语音包上传到公开仓库或作为付费资源传播。最后的输出一定要做人工抽查。尤其是TTS合成出来带情绪的长句音色稳定性需要人工听感判断不能只看自动评分指标。14. 总结与下一步这篇文章从架构、选型、代码示例、部署和排错几个层面拆解了“手机端AI语音陪伴聊天软件”的实现方式。核心链路并不复杂关键是把ASR、LLM、TTS、记忆这四个模块各自选好型、接好口再处理好延迟和并发。如果你准备自己动手建议第一优先级验证三件事ASR对中文语音的识别准确率、LLM对角色人设的保持度、TTS合成音频的自然度和延迟。这三个点直接决定用户愿不愿意继续聊下去。最容易踩的坑是记忆模块的“过度嵌入”把大量历史记录硬塞进Prompt导致超长和成本上升正确的做法是摘要向量检索分段读取。下一步可以做的扩展方向包括给记忆模块加入向量检索以支持语义回忆增加多角色切换和人格配置面板在服务端加入流式音频通讯WebSocket来进一步降低延迟以及接入微信或飞书等聊天平台的机器人接口做跨端验证。希望这篇拆解能帮你快速搭建出第一版可用的AI语音陪伴系统。
