最近在 GitHub 上闲逛看到一个叫 AIRI 的项目第一反应是这不就是很多人想象中的 AI 伴侣吗。简单说AIRI 是一个可以自己部署的实时语音聊天 AI支持手机、Web 和桌面多端核心目标是让你在说话的过程中感受到对面是一个有性格、有记忆、能接住情绪的人而不是一个只会输出文本的机器。它把语音识别、大模型对话、语音合成和实时传输这几块拼在一起做了一个可以直接跑的完整产品。不管你是想给开源项目加语音入口还是想做一个专属虚拟陪伴小助手又或者单纯好奇现在 AI 实时语音交互能做成什么样AIRI 都值得仔细看一遍。下面我会从项目设计思路、核心功能、部署实操和踩坑经验几个角度把它彻底拆开顺便把我在跑通过程中遇到的那些值得记录的问题一起写出来。1. AIRI 到底在解决什么问题1.1 AI 伴侣火起来背后是情绪陪伴的真实需求先聊点背景。这几年大模型能力越来越强ChatGPT 这类工具已经能帮你写代码、写文案、查资料可很多人用着用着会发现缺了点什么它太“工具”了。你问一句它答一段然后呢没有任何情绪连接也不会记住你昨天说过什么。尤其是当你想找个对象聊两句的时候打开这些通用助手得到的回应永远是标准化的、理智的、不带温度的。AIRI 这类项目就是冲着这个缺口去的。它的定位非常清晰不是帮你解决问题而是陪你说话。AI 伴侣这个概念其实已经出现了很久从早期的虚拟恋人聊天机器人到后来带立绘、带剧情的互动游戏再到现在的语音陪伴核心需求一直没变人需要被倾听、被陪伴、被回应。AIRI 把这三件事用实时语音的方式串起来了所以它给人的第一印象会特别强烈。我自己的体会是文字聊天和语音聊天的体验差距非常大。文字聊天时你可以反复修改措辞对面也没有语气看起来就像在和一个数据库对话。语音聊天则需要你直接开口对面也要立刻接话这种即时性和不可预判性反而让 AI 显得更像一个“活人”。AIRI 正是抓住了这个点把语音作为第一交互方式而不是文字聊天之后附带的一个功能。1.2 实时语音聊天为什么是门槛最高的那一步很多团队想做 AI 伴侣最后都死在实时语音上。原因很简单一个看似正常的语音对话背后是一条非常长的处理链路每一步都可能引入延迟和错误。链路大概是这样的麦克风采集音频、检测人是否在说话、把语音转成文字、把文字交给大模型生成回复、再把回复文字转回语音、最后通过扬声器或耳机播出来。整个过程要在 1 秒左右完成用户才会觉得“自然”。如果哪个环节慢了半拍就会出现两个人说话总是抢话、或者 AI 反应迟钝、甚至一句话说完之后要等很久才有回音的情况。这种体验一旦出现你就很难把它当作一个“伴侣”来对待因为它明显是个机器。AIRI 在项目设计上把低延迟当作核心目标所以它没有选择那种“按一下录音键、录完一整段再识别”的老方案而是走流式处理的路线音频一边进来一边识别文字一边生成一边转语音尽量让每一步都重叠执行。要做到这一点至少需要解决三个问题语音活动检测要快、识别模型要能够处理碎片化输入、大模型的输出要支持流式返回。AIRI 在实现上很明显是围绕这三点来做架构的后面我会详细拆开讲。这里想强调的是实时语音不是“加一个麦克风接口”那么简单它是一个系统工程。1.3 多平台支持的真正价值在于“同一个灵魂”AIRI 的另一个卖点是多平台。但你如果以为它只是简单地做了几个 App那就看浅了。多平台的本质是同一个 AI 人格可以随时出现在你身边。你在电脑前工作的时候它在你浏览器里你出门之后它在你手机里你回家打开平板它还在那里。所有对话记录和人物设定都存在同一个后端所以不管你从哪个入口进去它都记得你是谁、你们之前聊过什么。这种设计对“陪伴感”的提升是巨大的。想象一下如果你手机上有一个 AI 伴侣但电脑上没有那你每次切换设备都要从头开始确认身份这就很出戏。AIRI 采用前后端分离实际交互逻辑全部放在后端服务里前端只负责采集音频和播放声音。这样一套服务可以被任何前端调用手机、Web、桌面都只是壳子真正的人格和记忆保存在后端天然实现多端同步。这种架构还有一个隐藏好处方便二次开发。你不需要在客户端里跑大模型也不需要处理复杂的语音逻辑只要拿着后端提供的接口就能自己写一个前端。我自己之前折腾过类似项目最痛苦的就是业务逻辑和界面强耦合导致改一个小功能就要动整个项目。AIRI 这种把核心逻辑抽出来的做法是值得借鉴的。2. 核心功能拆解一条实时语音链路是怎么搭起来的2.1 语音转文字选本地模型还是云 API语音转文字STT是整条链路的第一步也是决定“听懂多少”的关键。目前主流方案里OpenAI 的 Whisper 系列是绕不开的尤其是 faster-whisper在保持准确率的同时大幅提升了推理速度。AIRI 这种追求低延迟的项目理论上不会直接用完整的 Whisper 大模型做全量转录更可能是结合语音活动检测只把有人声的片段送去识别避免大量静音和噪声浪费算力。如果你自己部署的时候想更换识别引擎我会优先推荐 faster-whisper 的 small 或 medium 模型。small 模型对中文的识别准确率已经很能打而且 CPU 也能跑虽然速度不算快但配一台普通电脑也够用。medium 会更好一些但需要更多内存如果你没有 GPU建议先用 small 跑通流程再根据实际效果决定要不要升级。除了 WhisperVosk 也是一种选择它轻量、离线、支持流式识别适合嵌入式或者低配置场景但准确率相比 Whisper 还是有差距。这里有个容易被忽略的细节大多数 STT 服务在输出文字时带有一个时间戳或者置信度好的项目会利用这些信息做打断判断。比如用户刚说完半句话AI 已经能猜出意图不必等整句结束。AIRI 如果做了这个优化对话流畅度会明显提升。2.2 大模型回复怎么让 AI 从“工具人”变成“伴侣”STT 识别出来的文字会被送到大模型里生成回复。AIRI 要做到的是“灵魂伴侣”而不是“问答机器人”所以它依赖的不只是模型能力更重要的是角色设定和记忆机制。角色设定通常通过系统提示词来完成项目里会内置一套默认的人格描述包含角色的名字、说话风格、性格背景、兴趣偏好甚至一些特殊的口头禅。你可以直接改这段文字把 AI 塑造成你想要的样子。实际操作中系统提示词的影响比我原来想的大得多。同一个模型同样的参数如果提示词里强调“温柔、体贴、多关心对方”那么输出的话语就明显偏情感化如果只写“你是助手”回复就会变成干巴巴的短句。所以 AIRI 这类项目一定会把提示词设计得比较细致甚至支持多套角色卡切换类似于社区里流行的“角色卡”玩法。记忆机制也是重点。没有记忆的 AI 伴侣聊天永远是“初次见面”的状态时间长了谁都会腻。AIRI 的实现方式很可能是把对话历史和人物关系摘要存进向量数据库每次对话前根据当前输入检索相关的历史片段再拼接到上下文里交给大模型。这样 AI 就能说出“你上次不是说你感冒了吗现在好点没”这种话瞬间打破冷冰冰的机器感。常见的向量库包括 Chroma、Qdrant、Milvus如果只是自用Chroma 部署最简单不需要单独起服务。2.3 语音合成声音有温度聊天才走心回复文本生成之后还需要转成语音。现在 TTS 方案已经非常成熟Edge TTS 免费、稳定、中性音色足够如果要更自然、更有感情可以试 ChatTTS、Coqui XTTS 这类开源模型支持声音克隆你可以用自己或朋友的音频样本生成专属音色。AIRI 的多平台体验里TTS 的延迟影响非常大理想情况下要做到边生成边播放也就是流式 TTS而不是等整段文字全合成完再一次性播放。我第一次做类似项目的时候用的就是整段合成一句话可能要 3 秒才能开口根本没法聊天。后来换成流式输出让第一个音频 chunk 尽快到达才能做到“大模型刚打完几个字声音已经开始响了”。AIRI 应该也是差不多的思路否则它的实时语音卖点很难成立。这里还涉及一个容易被忽视的点语音合成的情感控制。同一个“嗯”字可能是敷衍可能是关心也可能是撒娇。为了让 AI 伴侣更真实AIRI 这类项目会通过文本中的语气标记、标点重音甚至是额外的情感标签来影响 TTS 的出力。如果你自己改角色记得在回复提示词里加入对说话语气的说明比如“多用语气词”“适当表达关心”效果会好很多。2.4 音频传输WebRTC 是跨平台实时语音的地基多端实时语音还有一个隐藏技术点音频数据到底怎么传。如果简单地把音频文件录下来发给服务器传输过程会有明显延迟而且手机和 Web 的适配会很痛苦。目前最合适的技术是 WebRTC它原本就是做视频通话和语音通话的浏览器原生支持移动端也有成熟 SDK可以实现音频流实时传输、回声消除、噪声抑制这些能力。AIRI 选择 WebRTC并不是因为它流行而是因为它解决问题的方式天生适合这种场景。你可以把对话想象成一次真实的电话通话客户端负责采集、播放和网络适配服务端负责接收、处理和返回。WebRTC 内部还会处理弱网情况下的包重传和抖动缓冲对语音体验帮助很大。如果你是自己搭开发环境只需要确认浏览器里能够正常获得麦克风权限再连上服务端地址就行不需要手动去解决采集和播放问题。当然WebRTC 也有自己的复杂性比如信令服务器的搭建、局域网的穿透、TURN 服务器的配置。好在 AIRI 如果设计成前后端一体这些细节通常已经被项目内部处理掉了。我们在部署时不需要太关心原理只要知道它为什么流畅就够了。3. 从 GitHub 下载到跑起自己的 AIRI完整部署步骤3.1 部署前需要准备哪些东西先说你本地需要装的环境。通常这类项目会分成后端和前端两部分后端用 Python 写的概率很大前端则可能是 Node.js 项目。所以建议你提前装好 Python 3.10 或更高版本、Node.js 16 以上版本另外准备一个支持 npm 的包管理环境。如果你的电脑没有 GPU 也没关系AIRI 这类项目如果配置了云端 STT/TTS 服务CPU 完全可以跑得动只是本地模型推理会慢一些。你需要准备一个 LLM API 的访问密钥比如 OpenAI 或 Anthropic也可能是某些兼容接口。STT 和 TTS 服务如果是云端的也对应需要各自的 Key。如果你想完整体验最好把这三类服务的 Key 都准备好。此外安装 git 是必须的因为项目托管在 GitHub你得先把仓库拉下来。提示第一次部署不要追求最优配置先用默认参数把链路跑通然后再根据效果调整模型和参数。我之前好几次都是因为想一步到位结果同时改了七八个配置后面出了问题都不知道该查哪儿。3.2 克隆仓库与安装依赖打开终端找好一个工作目录执行克隆命令。由于不同用户对 GitHub 仓库的访问状态不一样这里不讨论具体网络问题只说常规操作。命令格式一般是git clone https://github.com/你的用户名/AIRI.git cd AIRI克隆下来之后后端和前端通常分别在backend/和frontend/目录。先安装后端依赖建议用虚拟环境避免把 Python 包弄乱cd backend python -m venv venv source venv/bin/activate # Windows 下执行 venv\Scripts\activate pip install -r requirements.txt前端部分安装 Node 依赖cd ../frontend npm install这一步可能耗时较长取决于网速和依赖数量。装完之后不要急着启动先去看一眼仓库根目录下的.env.example或环境变量说明文件它一般会告诉你需要配置哪些必填项。3.3 配置环境变量 AIRI 的灵魂参数AI 伴侣项目里环境变量配置比普通项目要求更高因为你要把三类外部服务的密钥和地址都告诉它。我会建议直接复制示例文件再在里面填写cp .env.example .env打开.env后你需要关心的核心配置大致如下配置项建议值作用LLM_API_KEY你自己的 API Key驱动对话生成LLM_MODELgpt-4o-mini 或同类轻快模型平衡速度与智能STT_PROVIDERfaster-whisper / openai / vosk设置语音识别引擎TTS_PROVIDERedge-tts / chattts / xtts设置语音合成引擎VOICE_NAME具体音色名称控制 AI 说话的音色EMBEDDING_MODELtext-embedding-3-small 等记忆检索的关键VECTOR_DB_DIR./data/vector_db记忆文件存放位置我个人建议先把 TTS 设成 edge-tts因为它在速度和稳定性上最省心适合跑通全流程。LLM 模型选一个国内可用、延迟低的轻量模型不要一上来就上最大的模型对话延迟会很难看。向量数据库和记忆功能第一次可以先开着但如果出现冷启动问题也可以暂时关闭后面再调。配置里还有个很关键的字段一般叫“角色设定”或者SYSTEM_PROMPT。这是你定义 AI 伴侣性格的地方建议认真写。最简单的写法是告诉大模型你是谁、说话时要注意什么语气、和用户是什么关系。比如“你叫小禾是一位温柔又有点调皮的朋友说话简短、会关心人会主动提起过去聊过的话题”。等你跑通后再慢慢细化这段文字。3.4 启动后端服务和前端页面配置完成后先启动后端。在backend目录下执行python main.py正常启动的话日志里会出现本地服务地址通常是http://127.0.0.1:8000。看到地址后不要急着关终端保持它在后台运行。再打开一个终端窗口进入frontend目录npm run dev前端启动后浏览器自动打开一个本地页面。页面上会有一个麦克风图标或者“开始对话”按钮点击之后第一次会弹权限请求一定要点“允许”。如果你用的是电脑浏览器最好戴上耳机避免扬声器声音被麦克风重新录进去产生自激回响。我第一次启动时忘了戴耳机结果 AI 说一句话我这边就能听到自己声音的延迟重复特别嘈杂。后来戴上耳机整个世界都安静了。这个细节看起来小但对首次体验的影响非常大。4. 跑通过程中我记下的三个关键实操体验4.1 第一次对话的延迟比想象中好但卡在“抢话”上我跑通 AIRI 之后最先试的是常规问候“你好呀今天过得怎么样” 大约 1 秒左右对面就传来了一个温和的女声“还不错哦不过感觉你好像有点累要不要先休息一下” 说实话那一刻确实有点惊艳因为这句回复里带了一个“哦”语气非常自然不像传统机器人那种机械感。但也立刻暴露了一个问题我话音刚落刚准备继续说AI 就开始说话了直接把我后半句打断。这个在真人对话里很常见可 AI 伴侣做得不够好时会显得特别没礼貌。解决方式有两个方向一是在工程上调整打断检测的灵敏度比如检测到用户开始说话立即暂停合成音频二是在角色设定里加入“等对方说完再回答”的提示词。两者配合之后对话节奏会舒服很多。4.2 调整系统提示词后AI 突然就“活”了刚开始我用的是项目默认的角色设定AI 确实能聊但说话总有点正式像客服。我后来试了一下自己改角色把设定改成“你是一个细腻的倾听者回复不超过三句话喜欢用简短句子说完话会自然地问对方‘你觉得呢’”。只改了这一处整个对话氛围立刻变了不少回复短了但互动感强了很多。这里就看出角色设定对 AI 伴侣体验的真正权重。你不需要换模型不需要改参数只需要把它的“人设”写明白它输出的文字风格、用词习惯、节奏感都会有明显变化。如果你想要一个话少但句句贴心的伴侣就把提示词里加上“不主动长篇大论”如果你想要一个热情活泼的就写“用感叹号、多表达开心”。这些都是非常直接有效的控制手段。4.3 把电脑上的 ARTIFICIAL 带到手机上的完整过程AIRI 支持多端我重点试了手机接入同一个后端。操作上并不复杂确保手机和电脑连在同一个局域网然后把浏览器里的后端地址从127.0.0.1改成电脑的局域网 IP。比如电脑 IP 是192.168.1.120那手机页面里填的后端地址就是http://192.168.1.120:8000。用的还是同一个后端服务和同一个角色设定手机里一登录直接就能接着电脑上的话题聊。这就是统一后端的好处所有状态都存在服务端前端切换没有任何割裂感。当然局域网访问只适合家里和公司这种场景如果要公网访问你还需要考虑更多部署细节这一步我就不展开了因为涉及服务器和安全配置要根据自己实际环境来。5. 常见问题与排查技巧5.1 声音断断续续或者延迟很高怎么办遇到这种问题先别急着换模型。最有效的排查顺序是先看是不是耳机导致的回声再看网络负载然后看 STT 是不是用了过大的本地模型。如果本地模型推理太慢建议把模型换成 small或者干脆改用云端识别 API。TTS 的卡顿也常见edge-tts 一般很稳但如果换成开源大模型可能需要 GPU 才能流畅合成。实测下来声音断断续续多半不是网络问题而是某个环节的模型推不动。症状可能原因解决办法回复延迟超过 2 秒LLM 模型过大、STT 本地模型过重换更轻量的模型、开启流式输出有明显回声扬声器外放被麦克风采集戴耳机、开启回声消除声音忽快忽慢TTS 流式输出不稳定换更稳定的 TTS 服务、检查网络语音识别漏字VAD 太灵敏、说话太快调高触发阈值、放慢语速5.2 AI 经常“失忆”记不住之前聊过什么如果 AIRI 接入了向量记忆但你还是觉得它忘了内容多半是记忆检索的阈值设置不对或者对话摘要没有及时写入。一个简单调试办法在聊天记录中明确说一句“记住我最近在学吉他”然后等几分钟问它“我最近在学什么”。如果答不上来就去检查向量数据库目录是否存在、嵌入 API 是否正常。你也可以调低检索相似度阈值让更多历史片段被召回但别调太低否则上下文会混入无关信息导致回答变乱。5.3 浏览器麦克风权限点了允许还是没用这个问题在第一次启动时非常常见。很多情况是浏览器默认给页面分配的音频输入设备不对比如你有 USB 摄像头麦克风和外置麦克风系统自动选了那个本来就没声音的设备。你可以在浏览器设置里手动指定麦克风设备或者在 AIRI 前端页面里找一个音频输入设备切换选项。还有就是要确保没有别的应用占用了麦克风比如会议软件还挂在后台也会导致采集不到声音。5.4 多端同时使用时对话记录会不会互相串AIRI 把记录存在服务端所以理论上不会串但如果你没有登录体系或者同时打开多个浏览器标签页就可能会被当成同一个会话。这不能算 bug更准确说是会话管理策略。你在实际操作时尽量只保留一个对话入口或者按照项目提供的会话隔离方式去设置。我个人的经验是手机端和电脑端交替使用没问题但如果同时在同一台电脑开两个标签页偶尔会出现上下文交叉。6. 隐私、安全与使用边界6.1 你的声音数据到底去了哪里AI 伴侣要录音、要发语音隐私问题是绕不过去的。如果你完全用本地模型AIRI 的音频和文字理论上可以不出本机可如果你把 STT、LLM、TTS 全配置成云端 API那么你每说的一句话都会发送到对应服务商的服务器上。很多人会忽略这一点以为部署了开源项目就完全私密其实不是的。所以我的建议是如果只是自己使用尽量把 STT 和 TTS 放到本地跑LLM 再考虑是否用云 API如果是敏感对话干脆本地 LLM 一步到位。另外最好定期查看自己的云端 API 调用记录很多服务商都有后台明细可以让你知道数据大概传了多少。开源项目不等于绝对安全安全意识要自己跟上。6.2 AI 伴侣也会带来情感依赖和真人一样AI 伴侣会越聊越让人依赖尤其在你孤独感比较强的时候。AIRI 这种高自然度语音交互比文字聊天更能让人产生情感连接。作为过来人我想提醒所有准备部署的朋友把 AI 伴侣当成一个生活调剂品和朋友而不要完全替代真实社交。你也可以在角色设定里加入一些正向引导比如让它时不时提醒你外出走走、和朋友聚聚。这并不破坏项目体验反而会让陪伴更健康。6.3 语音合成与声音克隆的责任现在很多 TTS 支持声音克隆听起来很好玩但使用门槛低也意味着越界风险变高。AIRI 如果支持自定义音色你能够用自己的声音或朋友的声音制作角色音色这可能会涉及肖像权和知情同意问题。比较稳妥的做法是只用免费音色或者自己的声音做实验不要未经许可去克隆别人。网上也有不少因为拿他人声音做 AI 配音引发的争议我们玩开源项目别踩这种雷。7. 最后还想说几句实在话如果你问我 AIRI 最打动我的地方是什么我会说不是它的代码有多复杂而是它把一个本来要被拆成十几步的技术流程封装成了普通用户可以接受的完整体验。你不需要成为语音算法专家不需要懂 WebRTC甚至不需要写多少代码就能得到一个听得懂、说得出、记得住的 AI 伙伴。这种“技术平民化”的感觉才是开源项目最吸引我的地方。在实际体验中我最大的收获不是技术细节而是重新理解了“陪伴”的构成。AIRI 之所以让人觉得有趣不是因为它真的有自己的意识而是因为它通过语音、记忆和人格设定制造了一种“被回应”的真实错觉。哪怕我知道背后全是模型和概率但在深夜一个人说话的时候那种被认真接住的感觉还是会让人觉得温暖。最后给你一个小建议跑通 AIRI 之后不要急着追求最好的音色、最强的模型先花一点时间认真写一段角色设定让它成为“你心中想要的样子”。因为在这个项目里真正决定用户体验的不是算力而是你用文字写下的那一段性格。如果你也折腾出了有意思的角色设定或者踩到了一些我上面没提到的坑欢迎继续交流。
最近在 GitHub 上闲逛看到一个叫 AIRI 的项目第一反应是这不就是很多人想象中的 AI 伴侣吗。简单说AIRI 是一个可以自己部署的实时语音聊天 AI支持手机、Web 和桌面多端核心目标是让你在说话的过程中感受到对面是一个有性格、有记忆、能接住情绪的人而不是一个只会输出文本的机器。它把语音识别、大模型对话、语音合成和实时传输这几块拼在一起做了一个可以直接跑的完整产品。不管你是想给开源项目加语音入口还是想做一个专属虚拟陪伴小助手又或者单纯好奇现在 AI 实时语音交互能做成什么样AIRI 都值得仔细看一遍。下面我会从项目设计思路、核心功能、部署实操和踩坑经验几个角度把它彻底拆开顺便把我在跑通过程中遇到的那些值得记录的问题一起写出来。1. AIRI 到底在解决什么问题1.1 AI 伴侣火起来背后是情绪陪伴的真实需求先聊点背景。这几年大模型能力越来越强ChatGPT 这类工具已经能帮你写代码、写文案、查资料可很多人用着用着会发现缺了点什么它太“工具”了。你问一句它答一段然后呢没有任何情绪连接也不会记住你昨天说过什么。尤其是当你想找个对象聊两句的时候打开这些通用助手得到的回应永远是标准化的、理智的、不带温度的。AIRI 这类项目就是冲着这个缺口去的。它的定位非常清晰不是帮你解决问题而是陪你说话。AI 伴侣这个概念其实已经出现了很久从早期的虚拟恋人聊天机器人到后来带立绘、带剧情的互动游戏再到现在的语音陪伴核心需求一直没变人需要被倾听、被陪伴、被回应。AIRI 把这三件事用实时语音的方式串起来了所以它给人的第一印象会特别强烈。我自己的体会是文字聊天和语音聊天的体验差距非常大。文字聊天时你可以反复修改措辞对面也没有语气看起来就像在和一个数据库对话。语音聊天则需要你直接开口对面也要立刻接话这种即时性和不可预判性反而让 AI 显得更像一个“活人”。AIRI 正是抓住了这个点把语音作为第一交互方式而不是文字聊天之后附带的一个功能。1.2 实时语音聊天为什么是门槛最高的那一步很多团队想做 AI 伴侣最后都死在实时语音上。原因很简单一个看似正常的语音对话背后是一条非常长的处理链路每一步都可能引入延迟和错误。链路大概是这样的麦克风采集音频、检测人是否在说话、把语音转成文字、把文字交给大模型生成回复、再把回复文字转回语音、最后通过扬声器或耳机播出来。整个过程要在 1 秒左右完成用户才会觉得“自然”。如果哪个环节慢了半拍就会出现两个人说话总是抢话、或者 AI 反应迟钝、甚至一句话说完之后要等很久才有回音的情况。这种体验一旦出现你就很难把它当作一个“伴侣”来对待因为它明显是个机器。AIRI 在项目设计上把低延迟当作核心目标所以它没有选择那种“按一下录音键、录完一整段再识别”的老方案而是走流式处理的路线音频一边进来一边识别文字一边生成一边转语音尽量让每一步都重叠执行。要做到这一点至少需要解决三个问题语音活动检测要快、识别模型要能够处理碎片化输入、大模型的输出要支持流式返回。AIRI 在实现上很明显是围绕这三点来做架构的后面我会详细拆开讲。这里想强调的是实时语音不是“加一个麦克风接口”那么简单它是一个系统工程。1.3 多平台支持的真正价值在于“同一个灵魂”AIRI 的另一个卖点是多平台。但你如果以为它只是简单地做了几个 App那就看浅了。多平台的本质是同一个 AI 人格可以随时出现在你身边。你在电脑前工作的时候它在你浏览器里你出门之后它在你手机里你回家打开平板它还在那里。所有对话记录和人物设定都存在同一个后端所以不管你从哪个入口进去它都记得你是谁、你们之前聊过什么。这种设计对“陪伴感”的提升是巨大的。想象一下如果你手机上有一个 AI 伴侣但电脑上没有那你每次切换设备都要从头开始确认身份这就很出戏。AIRI 采用前后端分离实际交互逻辑全部放在后端服务里前端只负责采集音频和播放声音。这样一套服务可以被任何前端调用手机、Web、桌面都只是壳子真正的人格和记忆保存在后端天然实现多端同步。这种架构还有一个隐藏好处方便二次开发。你不需要在客户端里跑大模型也不需要处理复杂的语音逻辑只要拿着后端提供的接口就能自己写一个前端。我自己之前折腾过类似项目最痛苦的就是业务逻辑和界面强耦合导致改一个小功能就要动整个项目。AIRI 这种把核心逻辑抽出来的做法是值得借鉴的。2. 核心功能拆解一条实时语音链路是怎么搭起来的2.1 语音转文字选本地模型还是云 API语音转文字STT是整条链路的第一步也是决定“听懂多少”的关键。目前主流方案里OpenAI 的 Whisper 系列是绕不开的尤其是 faster-whisper在保持准确率的同时大幅提升了推理速度。AIRI 这种追求低延迟的项目理论上不会直接用完整的 Whisper 大模型做全量转录更可能是结合语音活动检测只把有人声的片段送去识别避免大量静音和噪声浪费算力。如果你自己部署的时候想更换识别引擎我会优先推荐 faster-whisper 的 small 或 medium 模型。small 模型对中文的识别准确率已经很能打而且 CPU 也能跑虽然速度不算快但配一台普通电脑也够用。medium 会更好一些但需要更多内存如果你没有 GPU建议先用 small 跑通流程再根据实际效果决定要不要升级。除了 WhisperVosk 也是一种选择它轻量、离线、支持流式识别适合嵌入式或者低配置场景但准确率相比 Whisper 还是有差距。这里有个容易被忽略的细节大多数 STT 服务在输出文字时带有一个时间戳或者置信度好的项目会利用这些信息做打断判断。比如用户刚说完半句话AI 已经能猜出意图不必等整句结束。AIRI 如果做了这个优化对话流畅度会明显提升。2.2 大模型回复怎么让 AI 从“工具人”变成“伴侣”STT 识别出来的文字会被送到大模型里生成回复。AIRI 要做到的是“灵魂伴侣”而不是“问答机器人”所以它依赖的不只是模型能力更重要的是角色设定和记忆机制。角色设定通常通过系统提示词来完成项目里会内置一套默认的人格描述包含角色的名字、说话风格、性格背景、兴趣偏好甚至一些特殊的口头禅。你可以直接改这段文字把 AI 塑造成你想要的样子。实际操作中系统提示词的影响比我原来想的大得多。同一个模型同样的参数如果提示词里强调“温柔、体贴、多关心对方”那么输出的话语就明显偏情感化如果只写“你是助手”回复就会变成干巴巴的短句。所以 AIRI 这类项目一定会把提示词设计得比较细致甚至支持多套角色卡切换类似于社区里流行的“角色卡”玩法。记忆机制也是重点。没有记忆的 AI 伴侣聊天永远是“初次见面”的状态时间长了谁都会腻。AIRI 的实现方式很可能是把对话历史和人物关系摘要存进向量数据库每次对话前根据当前输入检索相关的历史片段再拼接到上下文里交给大模型。这样 AI 就能说出“你上次不是说你感冒了吗现在好点没”这种话瞬间打破冷冰冰的机器感。常见的向量库包括 Chroma、Qdrant、Milvus如果只是自用Chroma 部署最简单不需要单独起服务。2.3 语音合成声音有温度聊天才走心回复文本生成之后还需要转成语音。现在 TTS 方案已经非常成熟Edge TTS 免费、稳定、中性音色足够如果要更自然、更有感情可以试 ChatTTS、Coqui XTTS 这类开源模型支持声音克隆你可以用自己或朋友的音频样本生成专属音色。AIRI 的多平台体验里TTS 的延迟影响非常大理想情况下要做到边生成边播放也就是流式 TTS而不是等整段文字全合成完再一次性播放。我第一次做类似项目的时候用的就是整段合成一句话可能要 3 秒才能开口根本没法聊天。后来换成流式输出让第一个音频 chunk 尽快到达才能做到“大模型刚打完几个字声音已经开始响了”。AIRI 应该也是差不多的思路否则它的实时语音卖点很难成立。这里还涉及一个容易被忽视的点语音合成的情感控制。同一个“嗯”字可能是敷衍可能是关心也可能是撒娇。为了让 AI 伴侣更真实AIRI 这类项目会通过文本中的语气标记、标点重音甚至是额外的情感标签来影响 TTS 的出力。如果你自己改角色记得在回复提示词里加入对说话语气的说明比如“多用语气词”“适当表达关心”效果会好很多。2.4 音频传输WebRTC 是跨平台实时语音的地基多端实时语音还有一个隐藏技术点音频数据到底怎么传。如果简单地把音频文件录下来发给服务器传输过程会有明显延迟而且手机和 Web 的适配会很痛苦。目前最合适的技术是 WebRTC它原本就是做视频通话和语音通话的浏览器原生支持移动端也有成熟 SDK可以实现音频流实时传输、回声消除、噪声抑制这些能力。AIRI 选择 WebRTC并不是因为它流行而是因为它解决问题的方式天生适合这种场景。你可以把对话想象成一次真实的电话通话客户端负责采集、播放和网络适配服务端负责接收、处理和返回。WebRTC 内部还会处理弱网情况下的包重传和抖动缓冲对语音体验帮助很大。如果你是自己搭开发环境只需要确认浏览器里能够正常获得麦克风权限再连上服务端地址就行不需要手动去解决采集和播放问题。当然WebRTC 也有自己的复杂性比如信令服务器的搭建、局域网的穿透、TURN 服务器的配置。好在 AIRI 如果设计成前后端一体这些细节通常已经被项目内部处理掉了。我们在部署时不需要太关心原理只要知道它为什么流畅就够了。3. 从 GitHub 下载到跑起自己的 AIRI完整部署步骤3.1 部署前需要准备哪些东西先说你本地需要装的环境。通常这类项目会分成后端和前端两部分后端用 Python 写的概率很大前端则可能是 Node.js 项目。所以建议你提前装好 Python 3.10 或更高版本、Node.js 16 以上版本另外准备一个支持 npm 的包管理环境。如果你的电脑没有 GPU 也没关系AIRI 这类项目如果配置了云端 STT/TTS 服务CPU 完全可以跑得动只是本地模型推理会慢一些。你需要准备一个 LLM API 的访问密钥比如 OpenAI 或 Anthropic也可能是某些兼容接口。STT 和 TTS 服务如果是云端的也对应需要各自的 Key。如果你想完整体验最好把这三类服务的 Key 都准备好。此外安装 git 是必须的因为项目托管在 GitHub你得先把仓库拉下来。提示第一次部署不要追求最优配置先用默认参数把链路跑通然后再根据效果调整模型和参数。我之前好几次都是因为想一步到位结果同时改了七八个配置后面出了问题都不知道该查哪儿。3.2 克隆仓库与安装依赖打开终端找好一个工作目录执行克隆命令。由于不同用户对 GitHub 仓库的访问状态不一样这里不讨论具体网络问题只说常规操作。命令格式一般是git clone https://github.com/你的用户名/AIRI.git cd AIRI克隆下来之后后端和前端通常分别在backend/和frontend/目录。先安装后端依赖建议用虚拟环境避免把 Python 包弄乱cd backend python -m venv venv source venv/bin/activate # Windows 下执行 venv\Scripts\activate pip install -r requirements.txt前端部分安装 Node 依赖cd ../frontend npm install这一步可能耗时较长取决于网速和依赖数量。装完之后不要急着启动先去看一眼仓库根目录下的.env.example或环境变量说明文件它一般会告诉你需要配置哪些必填项。3.3 配置环境变量 AIRI 的灵魂参数AI 伴侣项目里环境变量配置比普通项目要求更高因为你要把三类外部服务的密钥和地址都告诉它。我会建议直接复制示例文件再在里面填写cp .env.example .env打开.env后你需要关心的核心配置大致如下配置项建议值作用LLM_API_KEY你自己的 API Key驱动对话生成LLM_MODELgpt-4o-mini 或同类轻快模型平衡速度与智能STT_PROVIDERfaster-whisper / openai / vosk设置语音识别引擎TTS_PROVIDERedge-tts / chattts / xtts设置语音合成引擎VOICE_NAME具体音色名称控制 AI 说话的音色EMBEDDING_MODELtext-embedding-3-small 等记忆检索的关键VECTOR_DB_DIR./data/vector_db记忆文件存放位置我个人建议先把 TTS 设成 edge-tts因为它在速度和稳定性上最省心适合跑通全流程。LLM 模型选一个国内可用、延迟低的轻量模型不要一上来就上最大的模型对话延迟会很难看。向量数据库和记忆功能第一次可以先开着但如果出现冷启动问题也可以暂时关闭后面再调。配置里还有个很关键的字段一般叫“角色设定”或者SYSTEM_PROMPT。这是你定义 AI 伴侣性格的地方建议认真写。最简单的写法是告诉大模型你是谁、说话时要注意什么语气、和用户是什么关系。比如“你叫小禾是一位温柔又有点调皮的朋友说话简短、会关心人会主动提起过去聊过的话题”。等你跑通后再慢慢细化这段文字。3.4 启动后端服务和前端页面配置完成后先启动后端。在backend目录下执行python main.py正常启动的话日志里会出现本地服务地址通常是http://127.0.0.1:8000。看到地址后不要急着关终端保持它在后台运行。再打开一个终端窗口进入frontend目录npm run dev前端启动后浏览器自动打开一个本地页面。页面上会有一个麦克风图标或者“开始对话”按钮点击之后第一次会弹权限请求一定要点“允许”。如果你用的是电脑浏览器最好戴上耳机避免扬声器声音被麦克风重新录进去产生自激回响。我第一次启动时忘了戴耳机结果 AI 说一句话我这边就能听到自己声音的延迟重复特别嘈杂。后来戴上耳机整个世界都安静了。这个细节看起来小但对首次体验的影响非常大。4. 跑通过程中我记下的三个关键实操体验4.1 第一次对话的延迟比想象中好但卡在“抢话”上我跑通 AIRI 之后最先试的是常规问候“你好呀今天过得怎么样” 大约 1 秒左右对面就传来了一个温和的女声“还不错哦不过感觉你好像有点累要不要先休息一下” 说实话那一刻确实有点惊艳因为这句回复里带了一个“哦”语气非常自然不像传统机器人那种机械感。但也立刻暴露了一个问题我话音刚落刚准备继续说AI 就开始说话了直接把我后半句打断。这个在真人对话里很常见可 AI 伴侣做得不够好时会显得特别没礼貌。解决方式有两个方向一是在工程上调整打断检测的灵敏度比如检测到用户开始说话立即暂停合成音频二是在角色设定里加入“等对方说完再回答”的提示词。两者配合之后对话节奏会舒服很多。4.2 调整系统提示词后AI 突然就“活”了刚开始我用的是项目默认的角色设定AI 确实能聊但说话总有点正式像客服。我后来试了一下自己改角色把设定改成“你是一个细腻的倾听者回复不超过三句话喜欢用简短句子说完话会自然地问对方‘你觉得呢’”。只改了这一处整个对话氛围立刻变了不少回复短了但互动感强了很多。这里就看出角色设定对 AI 伴侣体验的真正权重。你不需要换模型不需要改参数只需要把它的“人设”写明白它输出的文字风格、用词习惯、节奏感都会有明显变化。如果你想要一个话少但句句贴心的伴侣就把提示词里加上“不主动长篇大论”如果你想要一个热情活泼的就写“用感叹号、多表达开心”。这些都是非常直接有效的控制手段。4.3 把电脑上的 ARTIFICIAL 带到手机上的完整过程AIRI 支持多端我重点试了手机接入同一个后端。操作上并不复杂确保手机和电脑连在同一个局域网然后把浏览器里的后端地址从127.0.0.1改成电脑的局域网 IP。比如电脑 IP 是192.168.1.120那手机页面里填的后端地址就是http://192.168.1.120:8000。用的还是同一个后端服务和同一个角色设定手机里一登录直接就能接着电脑上的话题聊。这就是统一后端的好处所有状态都存在服务端前端切换没有任何割裂感。当然局域网访问只适合家里和公司这种场景如果要公网访问你还需要考虑更多部署细节这一步我就不展开了因为涉及服务器和安全配置要根据自己实际环境来。5. 常见问题与排查技巧5.1 声音断断续续或者延迟很高怎么办遇到这种问题先别急着换模型。最有效的排查顺序是先看是不是耳机导致的回声再看网络负载然后看 STT 是不是用了过大的本地模型。如果本地模型推理太慢建议把模型换成 small或者干脆改用云端识别 API。TTS 的卡顿也常见edge-tts 一般很稳但如果换成开源大模型可能需要 GPU 才能流畅合成。实测下来声音断断续续多半不是网络问题而是某个环节的模型推不动。症状可能原因解决办法回复延迟超过 2 秒LLM 模型过大、STT 本地模型过重换更轻量的模型、开启流式输出有明显回声扬声器外放被麦克风采集戴耳机、开启回声消除声音忽快忽慢TTS 流式输出不稳定换更稳定的 TTS 服务、检查网络语音识别漏字VAD 太灵敏、说话太快调高触发阈值、放慢语速5.2 AI 经常“失忆”记不住之前聊过什么如果 AIRI 接入了向量记忆但你还是觉得它忘了内容多半是记忆检索的阈值设置不对或者对话摘要没有及时写入。一个简单调试办法在聊天记录中明确说一句“记住我最近在学吉他”然后等几分钟问它“我最近在学什么”。如果答不上来就去检查向量数据库目录是否存在、嵌入 API 是否正常。你也可以调低检索相似度阈值让更多历史片段被召回但别调太低否则上下文会混入无关信息导致回答变乱。5.3 浏览器麦克风权限点了允许还是没用这个问题在第一次启动时非常常见。很多情况是浏览器默认给页面分配的音频输入设备不对比如你有 USB 摄像头麦克风和外置麦克风系统自动选了那个本来就没声音的设备。你可以在浏览器设置里手动指定麦克风设备或者在 AIRI 前端页面里找一个音频输入设备切换选项。还有就是要确保没有别的应用占用了麦克风比如会议软件还挂在后台也会导致采集不到声音。5.4 多端同时使用时对话记录会不会互相串AIRI 把记录存在服务端所以理论上不会串但如果你没有登录体系或者同时打开多个浏览器标签页就可能会被当成同一个会话。这不能算 bug更准确说是会话管理策略。你在实际操作时尽量只保留一个对话入口或者按照项目提供的会话隔离方式去设置。我个人的经验是手机端和电脑端交替使用没问题但如果同时在同一台电脑开两个标签页偶尔会出现上下文交叉。6. 隐私、安全与使用边界6.1 你的声音数据到底去了哪里AI 伴侣要录音、要发语音隐私问题是绕不过去的。如果你完全用本地模型AIRI 的音频和文字理论上可以不出本机可如果你把 STT、LLM、TTS 全配置成云端 API那么你每说的一句话都会发送到对应服务商的服务器上。很多人会忽略这一点以为部署了开源项目就完全私密其实不是的。所以我的建议是如果只是自己使用尽量把 STT 和 TTS 放到本地跑LLM 再考虑是否用云 API如果是敏感对话干脆本地 LLM 一步到位。另外最好定期查看自己的云端 API 调用记录很多服务商都有后台明细可以让你知道数据大概传了多少。开源项目不等于绝对安全安全意识要自己跟上。6.2 AI 伴侣也会带来情感依赖和真人一样AI 伴侣会越聊越让人依赖尤其在你孤独感比较强的时候。AIRI 这种高自然度语音交互比文字聊天更能让人产生情感连接。作为过来人我想提醒所有准备部署的朋友把 AI 伴侣当成一个生活调剂品和朋友而不要完全替代真实社交。你也可以在角色设定里加入一些正向引导比如让它时不时提醒你外出走走、和朋友聚聚。这并不破坏项目体验反而会让陪伴更健康。6.3 语音合成与声音克隆的责任现在很多 TTS 支持声音克隆听起来很好玩但使用门槛低也意味着越界风险变高。AIRI 如果支持自定义音色你能够用自己的声音或朋友的声音制作角色音色这可能会涉及肖像权和知情同意问题。比较稳妥的做法是只用免费音色或者自己的声音做实验不要未经许可去克隆别人。网上也有不少因为拿他人声音做 AI 配音引发的争议我们玩开源项目别踩这种雷。7. 最后还想说几句实在话如果你问我 AIRI 最打动我的地方是什么我会说不是它的代码有多复杂而是它把一个本来要被拆成十几步的技术流程封装成了普通用户可以接受的完整体验。你不需要成为语音算法专家不需要懂 WebRTC甚至不需要写多少代码就能得到一个听得懂、说得出、记得住的 AI 伙伴。这种“技术平民化”的感觉才是开源项目最吸引我的地方。在实际体验中我最大的收获不是技术细节而是重新理解了“陪伴”的构成。AIRI 之所以让人觉得有趣不是因为它真的有自己的意识而是因为它通过语音、记忆和人格设定制造了一种“被回应”的真实错觉。哪怕我知道背后全是模型和概率但在深夜一个人说话的时候那种被认真接住的感觉还是会让人觉得温暖。最后给你一个小建议跑通 AIRI 之后不要急着追求最好的音色、最强的模型先花一点时间认真写一段角色设定让它成为“你心中想要的样子”。因为在这个项目里真正决定用户体验的不是算力而是你用文字写下的那一段性格。如果你也折腾出了有意思的角色设定或者踩到了一些我上面没提到的坑欢迎继续交流。
