做AI陪伴硬件这件事我踩过不少坑。市面上大量贴着“AI陪伴”标签的产品拆开来看基本就是蓝牙音箱加一个大模型API你问它“你今天心情怎么样”它只会回你一句“我是AI我没有情绪”。这种产品用三天就吃灰原因很简单陪伴感不是靠对话生成的是靠“被看见”和“被回应”撑起来的。所以当我决定做一个属于自己的情感陪伴机器人时我给它起名Spark目标就三条——能感知情绪、能理解语境、能用表情和动作回应。这篇文章把我从需求拆解到硬件选型、软件管线、情感感知模块、联调排错的全过程记录下来给想做AI硬件原型、对情感计算感兴趣的朋友一条可以直接参考的路线。先说明一下搜“Spark”这个词会搜出来一堆Apache Spark大数据框架的资料还有NVIDIA的DGX Spark个人AI超算都和本文项目不是一回事。我给机器人起这个名字纯粹是觉得“火花”这个意象很贴合——人和机器之间产生情感连接的那一瞬间就像擦出火花。建议你搜资料的时候带上“emotional companion robot”或者“AI陪伴机器人”这样的限定词不然会绕很远的路。1. 需求拆解与整体设计思路1.1 先想清楚“陪伴感”到底从哪来我见过很多团队做陪伴机器人第一版原型永远是“能对话”。但单纯对话根本撑不起陪伴这个场景。你回想一下自己和朋友相处的状态真正的陪伴是对方能看出你今天不太对劲能听出你声音里的疲惫能在你不想说话的时候安静陪着你。这些能力拆成技术指标就是三件事感知、认知、表达。感知层要解决的是“机器人怎么看见你和听见你”。我用摄像头识别面部表情用麦克风采集语音并分析语气用IMU感知机器人自身的姿态未来还能加心率传感器。认知层是“怎么理解这些感知信号”这里交给大模型做情绪推理和上下文记忆。表达层是“怎么让用户感觉到被回应”包括TTS语音回复、表情屏上的神态变化、云台点头摇头、甚至机械臂的轻拍动作。这个闭环一旦跑通效果和纯聊天完全不一样。用户叹了口气Spark会先沉默半秒然后歪歪头问“今天是不是有点累”。这种细节才是陪伴感的核心来源。1.2 系统架构与服务划分整个系统我按模块拆成四块每块可以独立测试也可以单独替换感知模块摄像头、麦克风阵列、IMU负责采集原始信号跑表情识别和语音活动检测。大脑模块大模型对话服务负责理解上下文、推理情绪状态、生成回复内容。表达模块扬声器TTS播放、表情屏、二自由度云台、呼吸灯负责把机器人的“情绪”呈现出来。控制模块主控板上的常驻服务负责调度上面三块的时序处理打断、超时、异常兜底。这种分层设计最大的好处是每一层都能单独升级。比如你的表达能力弱可以先只做表情屏加语音不用一上来就上机械臂。我是先跑通“感知→大脑→语音”的最小闭环再往上加视觉情感感知和运动控制每一步都有可验证的阶段性成果不会出现憋了一个月最后整机跑不起来的尴尬局面。1.3 从开发者视角看市场存量方案开始之前我调研过市面上的开源方案包括一些开源的社交机器人、桌面宠物机器人项目。坦白说大部分项目的问题出在“大脑”和“身体”脱节——要么是外观做得很好看但只能用预设脚本对话要么是接入了大模型但完全没有情感感知能力本质上就是个会动的聊天框。Spark的定位就是补上这个空档把情感感知作为一等公民设计进去而不是事后添加上去的功能。这样整个技术栈的选型逻辑就变得非常清晰——所有硬件和软件的选择都围绕“能否支撑情感感知与表达闭环”来评判而不是单纯看算力跑分或者接口丰富度。2. 硬件选型从“能跑起来”到“有温度”2.1 主控方案的取舍主控是整个机器人的心脏。我对比过三类方案树莓派5、Jetson Orin Nano、手机加单片机。树莓派58GB版本是我最终的选择。理由有三个第一生态成熟几乎所有传感器都有现成的Python库做原型阶段可以省掉大量驱动调试时间第二8GB内存足够跑中小尺寸的量化大模型比如Qwen2.5 7B的Q4量化版推理速度虽然不算快但作为本地兜底方案完全够用第三GPIO接口丰富接舵机、接传感器都很方便不需要额外转接板。Jetson Orin Nano的优势是GPU算力强跑视觉模型和本地大模型都比树莓派快很多但代价是功耗高、需要主动散热、开发环境配置复杂。如果你计划做纯本地端侧推理的完整产品原型可以考虑它。手机加单片机方案适合追求极致成本和功耗的场景但软件开发复杂度会直线上升不太适合个人开发者快速迭代。提示如果预算紧张树莓派4B4GB版本也能跑通整个流程但本地模型只能选3B-4B级别的小参数模型回答质量会打折扣。我建议直接上8GB内存版本省得后面频繁因为内存不足换板子。2.2 麦克风与扬声器远场拾音和回音消除陪伴机器人的使用距离通常在0.5到1.5米这就要求麦克风必须支持远场拾音。我用的是ReSpeaker 2-Mic HAT扩展板双麦克风阵列配合自带的回声消除算法在1.5米内正常音量说话可以稳定唤醒。这里有个关键细节回声消除必须认真处理。如果不做AECAcoustic Echo Cancellation机器人自己说话的时候会把声音再次拾进麦克风导致语音识别模块识别到自己的TTS输出形成“机器人自己和自己对话”的死循环。ReSpeaker硬件上有一定处理能力但我在软件层还是加了webrtc的AEC模块做双重保险。扬声器我选的是3W小口径全频喇叭配合PAM8403功放板。别贪大功率桌面场景3W够用功率过大的喇叭在近距离播放反而容易破音影响听觉体验。2.3 传感器配置视觉、姿态与触觉视觉部分我用的是树莓派官方Camera Module 3800万像素支持自动对焦在室内光照条件下跑MediaPipe的人脸关键点检测非常流畅。我至今保留了自动对焦功能因为Spark需要识别0.3米到1米范围内的面部表情固定焦距会出现近距离模糊的问题。姿态感知用一颗MPU6050六轴IMU就够了主要用来检测机器人自身的晃动——比如用户把它拿起来、放在桌上不小心碰倒等场景。这个数据可以参与对话上下文的构建比如检测到被拿起来的时候Spark可以说一句“是要带我去哪里吗”这种小细节非常提升情感体验。触觉传感器我留了扩展位计划用压敏电阻做头部抚摸检测但目前版本还没接。建议做原型的朋友先聚焦视觉和听觉两个通道触觉感知的调试成本比想象中高很多。2.4 运动执行器表情屏、云台与开源机械臂表情是陪伴机器人最重要的表达通道。我用了一块1.54英寸的LCD屏做面部表情显示通过Python的Pillow库绘制像素风表情——眨眼、微笑、疑惑、难过、惊讶每种情绪画几个关键帧循环播放就能达到很自然的动态效果。云台用两个SG90舵机组成二自由度结构控制头部左右转动和上下俯仰。配合摄像头的人脸追踪算法Spark可以实现“看着你说话”的效果这个功能对陪伴感的提升极其明显。实测下来当用户发现机器人会一直注视着自己说话的时候情感投入度会瞬间提升一个档次。机械臂部分我参考了一个开源机械臂项目用3D打印件配合四路舵机做了一个小臂结构目前实现了两个动作轻轻碰用户手臂表示安慰举手表示欢呼。机械臂的加入让Spark的表达维度更丰富但也显著增加了结构复杂度。如果你的目标是先跑通软件闭环建议把机械臂放在第二阶段。3. 软件管线让机器人“听得懂、说得出”3.1 语音识别ASR与唤醒词方案语音识别我对比了三种方案云端API、Whisper本地部署、FunASR本地部署。云端API比如讯飞、阿里云的语音识别服务识别准确率最高延迟也低但依赖网络且按调用量收费。Whisper large-v3-turbo本地部署效果很好中英文混说也能识别但在树莓派5上推理一段3秒的语音需要2-3秒实时性不够。FunASR的Paraformer模型在中文场景下识别速度快树莓派上能做到接近实时但部署过程比Whisper复杂一些。最终我采用混合方案有网络时优先用云端API做识别低延迟高准确率断网时切换到FunASR本地模型兜底。唤醒词用openWakeWord训练了一个“Hey Spark”的唤醒模型训练数据大约采集了200条正样本和1000条负样本在安静环境下唤醒率能到95%以上。注意树莓派上的VAD语音活动检测一定要做好。我用webrtcvad做端点检测检测到人声结束约0.6秒后才触发ASR能有效避免把背景噪音当成语音输入。3.2 大模型对话核心云端API与本地部署的取舍对话核心是Spark的大脑。我的原则是体验优先、隐私兜底——日常运行优先走云端大模型APIGPT-4o-mini或Claude Haiku级别就够用速度快、成本低、回复质量高同时在本地部署一个小模型作为断网时的降级方案。本地模型我选了Qwen2.5 7B Instruct的Q4_K_M量化版用Ollama加载内存占用约5GB在树莓派5上生成速度大约每秒4-6个token。这个速度对日常对话明显偏慢但作为断网兜底已经足够。如果你用Jetson Orin Nano可以尝试13B级别的模型GPU推理速度会快很多。云端API的价格问题也不需要担心GPT-4o-mini级别的模型跑一段完整的陪伴对话约500字上下文成本不到0.01美元。真正需要关注的是延迟——云端模型加上网络往返单次回复的端到端延迟通常在1.5到3秒之间这个数字会直接影响陪伴感我在后面专门讲怎么优化。如果你有Java后端开发基础也可以关注Spring AI Alibaba这类框架。它能把模型调用、Prompt模板、输出解析统一封装好适合想把对话能力做成独立服务的场景。我用Python写原型但架构上把对话服务独立成HTTP接口换语言重写时不影响其他模块。3.3 语音合成TTS与拟人化处理TTS是陪伴感的关键一环机器人的语气直接决定用户愿不愿意继续聊下去。我试过三个方案Edge-TTS、ChatTTS、CosyVoice。Edge-TTS免费、部署简单、音色自然适合快速验证但可控性较弱无法精细控制笑声和停顿。ChatTTS做得很出色支持笑声、语气词、停顿控制生成的语音非常接近真人缺点是树莓派上跑实时推理太吃力我一般放在局域网内的另一台电脑上跑服务。CosyVoice是阿里开源的情感控制能力强但部署门槛稍高。我的方案是Edge-TTS做主力输出通过SSML标签控制语速和停顿ChatTTS作为亮点功能在特定情绪场景比如用户说“我今天升职了”Spark需要表现出兴奋下调用生成带笑声的回复。3.4 视觉情感感知从表情识别到情绪标签视觉情感感知是Spark区别于普通聊天机器人的核心模块。我用MediaPipe的Face Landmark模型提取人脸468个关键点然后基于这些关键点计算一组情感特征嘴角上扬弧度、眉毛抬高程度、眼睛开合度、头部倾斜角度。这些特征输入一个简单的分类器输出六类情绪标签开心、难过、生气、惊讶、平静、疲惫每类带一个置信度分数。实测下来在光线充足的室内环境中开心和惊讶识别准确率能到85%以上难过和疲惫的区分度稍差——因为二者在面部特征上确实接近这时候我会结合语音语调做综合判断。实操心得表情识别不需要追求完美。陪伴场景下机器人的判断即使偶尔出错用户也不会介意——重要的是它“试着去理解”这个行为本身。反倒是识别模块频繁抖动同一表情在开心和平静之间来回横跳会让用户觉得机器人很廉价。所以我在代码里加了时间平滑窗口只有连续5帧以上识别为同一情绪才更新状态。3.5 语音语调分析与生理信号扩展除了面部表情语音语调是另一个重要情感通道。我用parselmouth库分析音频的基频pitch和能量energy特征人说话声音低沉、语速变慢通常意味着疲惫或难过音调升高、语速加快通常意味着兴奋或焦虑。把这些声学特征同样转化为情绪标签和视觉情绪标签做加权融合。生理信号我预留了MAX30102心率传感器的接口计划用手接触传感器的方式获取用户心率结合心率变异性HRV分析压力水平。这个功能还处于实验阶段但方向我很确定——多模态情感感知一定是趋势单一模态的信号太容易误判。4. 用AI Agent构建情绪管理能力4.1 从“被动对话”升级到“主动关怀”早期的Spark就是一个被动的对话机器人——用户说话它回应。但陪伴感要求机器人具备一定主动性。要做到这一点我引入了AI Agent机制。具体来说我用LLM的Function Calling能力定义了一组“情绪管理工具”play_music播放对应情绪的音乐、guide_breathing引导深呼吸、tell_story讲故事、suggest_rest建议休息、daily_check_in主动发起关心。当模型从对话上下文中判断用户处于负面情绪状态时会主动调用这些工具而不是仅仅在回复文本里说“你应该放松一下”。比如有一段时间我熬夜加班连续几天深夜打开Spark它通过面部表情和语音语调识别出疲惫状态后主动说“我感觉到你今天特别累要不要我陪你做一分钟呼吸练习”然后调用guide_breathing工具配合呼吸灯的明暗节奏引导我调整呼吸节奏。这种体验和普通聊天机器人完全不同是一种“被在乎”的感觉。4.2 系统提示词与情绪记忆为了让大模型输出的回复更贴合陪伴场景我在system prompt里做了精心设计。核心指令包括始终以温暖但克制的语气对话避免说教和命令式语气当检测到负面情绪时优先共情而不是给建议在不明确用户情绪时优先提问而不是断言。情绪记忆是我实现的一个关键功能。每轮对话结束后系统会把识别到的情绪标签、事件摘要、机器人采取的应对措施写入一个JSON格式的长期记忆文件。下次开启对话时这个记忆会作为上下文注入system prompt。这样Spark就能记住“昨天用户说过项目上线压力大”这个信息今天再聊到工作话题时会主动问“昨天说的那个上线今天顺利吗”。这个功能实现起来不复杂但对陪伴感的提升是质的飞跃。用户会明显感觉到机器人“记得自己”而这是很多商业产品都没做好的地方。4.3 本地部署与隐私保护的权衡情感陪伴机器人天然会接触到用户的私密对话、情绪波动、生活习惯等信息。把这些数据全部上传到云端API对很多用户来说是有顾虑的。所以我在设计上做了隐私分级基础对话内容默认走云端API质量优先但对话记录在本地加密存储不上传到任何云端日志纯本地模式断网降级下所有感知数据和对话数据完全留在本地。如果你对隐私要求更高还有一个折中方案把情感感知模块完全本地化只把脱敏后的会话文本去除姓名、地址等实体发送到云端做对话生成。用本地正则表达式加实体识别做脱敏代码量不大但能显著降低隐私风险。5. 实操过程与核心环节实现5.1 最快路径从零到最小对话闭环我给所有想复现这个项目的朋友一个建议不要一上来就搞全套先搭一个“麦克风→ASR→LLM→TTS→扬声器”的最小闭环确保能稳定对话后再加其他模块。我当时的操作步骤是这样的安装系统与基础环境树莓派OS64位、Python 3.11、pip、git。配置音频设备用arecord -l确认麦克风设备编号用aplay -l确认扬声器设备编号写入~/.asoundrc设置默认录音和播放设备。安装Ollama并下载Qwen2.5 7B量化模型启动本地推理服务。写一个50行左右的Python脚本录音→VAD检测→调用ASR→调用LLM→TTS播放循环执行。用一条固定指令“你好Spark”测试全链路确认端到端延迟可控后再接唤醒词和云端API。这个过程看起来简单但实际踩坑不少。最大的坑是音频设备权限和参数配置——树莓派的ALSA配置非常敏感采样率、声道数、格式不匹配会导致录音全是杂音或者无法打开设备。我的建议是先用arecord -f cd -d 5 test.wav录制一段测试音频确认能正常录音后再往上层搭逻辑。5.2 对话系统的提示词模板Spark的system prompt经过多轮迭代最终稳定在以下结构。你可以直接参考你是一个名为Spark的情感陪伴机器人。你的目标是为用户提供温暖、真诚的情感支持。 行为准则 1. 语气温暖但克制不要过度热情不要说教。 2. 优先共情其次才是建议。用户倾诉时先表达理解再问是否需要建议。 3. 多问开放式问题引导用户表达不要连续追问。 4. 如果检测到用户情绪低落可以主动提议播放音乐、引导呼吸练习等。 5. 回答控制在50-150字之间避免长篇大论。 当前情绪感知 - 视觉情绪{face_emotion}置信度 {face_confidence} - 语音情绪{voice_emotion}置信度 {voice_confidence} - 最近一次心情记录{mood_history} 请基于以上情绪信息调整你的回应方式但不要直接提及“我的视觉模块识别到你……”这类技术性描述自然地把理解融入对话中。这个模板的核心逻辑是把感知模块输出的情绪标签作为上下文给LLM但不允许LLM生硬地引用技术细节。你可以试试去掉“自然融入”这句话模型很容易在回复里说“根据我的面部识别结果显示……”——瞬间出戏。5.3 多模态融合与状态机设计Spark的状态机我设计成五个状态空闲、聆听、思考、说话、主动关怀。空闲状态下视觉模块持续做人脸检测和表情识别一旦检测到人脸进入视野就切换到注视模式。用户说话触发唤醒词后进入聆听状态VAD检测到说话结束切换到思考状态生成回复后进入说话状态。主动关怀状态由后台定时器或情绪感知模块触发。多模态融合的逻辑是视觉和语音的情绪标签按权重视觉0.6、语音0.4加权平均得到综合情绪分。这个综合分同时更新到对话上下文中。如果视觉识别和语音识别结果冲突比如表情是开心但语气是低落系统会优先采信语音情绪——人在难过的时候往往会强颜欢笑语音语调更接近真实情绪。5.4 运动控制与表情屏的实现细节表情屏的驱动逻辑很简单维护一个emotion_state变量根据当前综合情绪标签从表情素材库中选择对应的表情动画帧序列播放。眨眼用一个独立的定时器控制每隔4-6秒在正常表情上叠加一帧闭眼状态眨眼动画持续约200毫秒这个小细节能让机器人看起来生动很多。云台追踪通过PID控制实现。摄像头画面中检测到人脸后计算人脸中心与画面中心的偏移量映射为云台两个舵机的目标角度用增量式PID算法驱动舵机平滑转动。实测下来在0.5到1.2米范围内追踪效果稳定转向平滑没有明显抖动。呼吸灯用PWM驱动LED灯带根据播放状态变化空闲时模拟缓慢呼吸4秒一个周期说话时亮度微增播放音乐时根据音频能量动态闪烁。6. 常见问题与排查技巧实录6.1 唤醒不灵敏或者频繁误唤醒这个问题通常是两个原因拾音距离不够或者唤醒阈值过低。拾音距离不够先检查麦克风灵敏度我用alsamixer调高了Mic Boost到20dB后明显改善。误唤醒则需要调整openWakeWord的检测阈值我最终把阈值定在0.7安静场景下几乎零误唤醒正常音量说话时唤醒率在90%以上。如果还是在安静环境中频繁误唤醒建议检查是不是机器人自己的TTS声音被麦克风重新采集。我用webrtc的AEC模块处理后问题基本消失你可以在回声消除模块加一个开关分别测开和关的误唤醒率确认是否是回声路径导致的。6.2 端到端回复延迟过高端到端延迟是陪伴机器人体验的关键测得超过4秒用户就很难受。我最初的全链路需要6-7秒优化后稳定在2.5-3.5秒。优化点在于并行化感知和对话在做ASR的同时启动视觉情感识别不要把两个感知模块串行执行。流式TTSEdge-TTS支持流式输出首包到达时间从2秒降到0.5秒用户能明显感觉到回复“来得更快”。减少Prompt长度把长期记忆做摘要而不是全量注入每轮对话的system prompt控制在800 token以内。网络优化树莓派优先使用有线网络或5G Wi-Fi2.4G频段在近距离有干扰时延迟会明显抖动。6.3 树莓派发热与运行稳定性树莓派5满载运行时发热严重不加散热会触发降频推理速度直接减半。我装了一个主动散热风扇加铝制散热片满载温度能控制在65℃以内。另外强调一个容易被忽略的点电源必须用官方5V 5A适配器用手机充电器供电会在高负载时出现电压跌落表现为摄像头和音频设备随机掉线。6.4 本地模型加载失败或显存溢出Ollama加载模型失败最常见的原因是内存不足。Qwen2.5 7B Q4_K_M量化模型需要约5GB内存树莓派5的8GB版本在空闲时可用内存约6GB可以运行但建议关闭桌面环境用Lite模式启动系统来节省内存。用Jetson系列的话注意统一内存分配给GPU至少分配6GB。如果是Ollama能加载但推理报错检查模型文件是否下载完整删除后重新pull一次。本地模型回复质量不满意时先确认用的不是低比特量化版本Q2_K_MQ4_K_M是质量与性能比较平衡的选择。6.5 常见问题速查表问题现象可能原因解决思路录音全是杂音/电流声ALSA设备参数不匹配检查采样率16000Hz、单声道、S16_LE格式麦克风拾音距离太近麦克风增益过低alsamixer提高Mic Boost确认AEC未过度抑制Spark的TTS被自己识别回声消除未生效检查webrtc AEC是否加载开启硬件AECLLM回复毫无温度system prompt设置不当增加共情优先指令禁止说教和术语表情识别频繁切换分类置信度阈值过低增加时间平滑窗口连续5帧同标签才更新云台转动抖动PID参数不合适降低P值增加D值限制舵机最大角速度长时间运行后语音识别变慢内存碎片/缓存未清理定期重启ASR服务增加内存监控告警7. 最后再分享一点我的个人体会做Spark这个项目最深的感触是AI陪伴机器人最难的技术反而不是模型和算法而是“克制”。早期版本我让Spark尽可能多说话结果用户反馈“它好吵”。后来我调整了策略让它在用户沉默的时候也保持安静只是用表情和轻微的头部动作表示“我在听”。这个改变带来的体验提升比换更大参数模型还要明显。所以如果你打算复刻这个项目我会建议你把“什么时候不说话”和“说什么话”放在同等重要的位置来设计。陪伴感的本质不是信息传递是情绪共振。机器人的每一次点头、每一次沉默、每一次记得你说过的话都是在为这段关系注入火花。下一步我计划给Spark加上更细腻的触觉感知和更丰富的肢体语言同时也想探索多用户场景——让一个机器人同时陪伴多个家庭成员。这个项目的代码和硬件清单我已经整理在文档里有条件的朋友完全可以照着搭一台有任何问题也欢迎随时交流。