企业官网建设流程全解析

做AI陪伴机器人这件事，最容易被低估的不是模型选型，也不是硬件成本，而是“把一颗AI大脑塞进一个会动的小身板里”之后，整套系统能不能稳定、自然、不打脸地跑起来。Spark这个项目，说白了就是我当时较真折腾的一台情感陪伴机器人：能听懂人话、能看出情绪、能主动说话、能在地板上巡游，还会把每天的交互数据汇总成一张可复盘的报告。这篇文章不聊PPT，只讲我从需求拆解、硬件选型、软件架构到真机调试踩过的实际坑，以及每一步为什么这么选。

如果你正准备做自己的陪伴机器人、AI Agent的实体化原型，或者单纯想把大模型从网页聊天窗口里“拽”进一个真实的移动设备上，这篇内容应该能帮你省下好几周的弯路。

1. 项目概览：为什么叫Spark，以及它到底解决什么问题

1.1 核心需求解析

先明确Spark要做的事。它不是一个玩具遥控车，也不是一个语音音箱的套壳，而是一个具备“感知-认知-表达-移动”闭环的情感陪伴机器人。拆开看，核心需求有四层：

• 感知层：能听到用户说话，并且能判断用户说话时的情绪状态（开心、低落、平静、紧张等）。
• 认知层：能基于大模型做开放域的对话，同时根据情绪识别结果调整回应策略。
• 表达层：通过语音、表情屏、头部/身体姿态动作反馈情绪和态度，让交互有“人格感”。
• 移动层：能在地面上自主巡航，靠近用户，或者在指定区域内完成简单的格子式路径移动，配合交互场景。

为什么取名Spark？一方面是“火星/火花”的寓意——它应当成为激发用户表达欲的小火花；另一方面也暗含一点我对技术的执念：情感计算本质上要从大量稀疏的交互信号里“擦出”有用的特征，这个过程跟Spark在大数据生态里做计算有某种神似。后面我会专门讲一个轻量化“Mini Spark”数据管道来处理交互日志，一会儿细说。

1.2 目标用户与适用场景

Spark适合谁？我当时的定位有三类人群：

• 独居青年和轻度情绪陪伴需求者：他们不想要一个冷冰冰的智能音箱，而想要一个“会回应情绪”的实体伙伴。
• 老年人和儿童陪护场景：需要语音交互足够简单，同时机器人要有主动关怀行为（比如提醒喝水、讲故事、陪散步）——注意，这涉及安全边界，所以我把危险动作和敏感话题都做了强约束。
• 极客开发者与产品原型验证者：把LLM接入实体机器人，验证AI Agent在物理世界的交互效果，为后续产品化做技术预研。

从场景上看，室内环境为主，要求机器人在10-30平方米的空间内完成巡航、寻人、返回充电座这类基础动作。

1.3 整体技术路线的思考

我最初纠结过两条路线：一条是完全云端方案，所有语音识别、大模型推理、TTS都走云API，机器人只做采集和执行；另一条是尽量本地化，至少把语音唤醒、意图识别和TTS放在端侧，大模型推理走本地小模型或按需云端切换。

最终我选择“端侧优先、云端可选”的混合架构。原因有三：

• 隐私和响应速度：陪伴场景会涉及大量日常闲聊，甚至情绪低落时的心里话，全部传云端既让用户心里打鼓，也会让流式对话延迟变得不可控。端侧语音链路能做到1秒内响应首字，这是云API很难稳定保证的。
• 成本可控：云端大模型按token计费，陪伴聊天一天几十轮，一个月下来都是实打实开销，本地推理一次到位。
• 可离线运行：我不想让Spark在断网时变成一个只会说“网络异常”的废物，这在真实居住环境里经常发生。

这也是为什么我在后面煞费苦心地折腾本地大模型、本地唤醒、本地TTS，而不是躺平全套接API。顺便提一句，2025年桌面级AI工作站也开始进入个人开发者视野，这类设备让“一人一台模型部署环境”成为可能，思路和Spark的本地化路线是一致的。

2. 硬件选型与系统架构

2.1 分层架构设计

Spark的软件架构我按数据流拆成五层，这个分层决定了后续每个模块的边界：

1. 交互接入层：麦克风阵列、摄像头、触摸/按钮传感器。
2. 感知处理层：语音唤醒、语音识别（STT）、声纹/情绪特征提取、人脸/存在检测。
3. 认知决策层：大模型推理引擎、情感状态机、对话管理、行为规划。
4. 运动与控制层：底盘运动控制、避障、路径规划、舵机关节控制。
5. 数据与记忆层：SQLite交互日志、每日ETL汇总、向量记忆库。

这样分层的核心好处是：每一层都能独立替换和升级。比如今天想把语音识别从Sherpa换成Whisper，只需要改感知层接口；明天想给机器人换个更强大的底盘，运动控制层改动也能被隔离。

2.2 硬件平台选型对比

硬件选型上我列过一张对比表，这里直接放出来：

我最后的主力配置是：树莓派5（8GB）做“大脑”，负责语音识别、大模型推理、TTS、对话管理，同时外接一块ESP32-S3作为“小脑”，负责电机控制、传感器采集和舵机动作。这样设计的原因很简单：树莓派跑Linux、跑Python生态太方便了，但GPIO实时控制差，走PWM控制电机容易掉帧；ESP32擅长硬实时，两边通过串口+协议帧通信，各干各的活，互相不拖后腿。

语音采集我用了ReSpeaker 2-Mic Hat，两个麦克风做简单的波束形成，实测比单个USB麦克风在嘈杂环境下的唤醒准确率高不少。底盘部分用的是两款直流减速电机加编码器，配合TB6612驱动板，便宜、皮实，坏了就换。

2.3 “大脑在哪”的取舍：本地模型与云API的博弈

这是Spark项目里我反复权衡最多的地方。大模型推理到底是本地跑还是接云API，我的演进路线是这样的：

• 第一阶段：全部走云API做验证，快速跑通对话闭环，一周就完成了原型验证。
• 第二阶段：把语音唤醒、STT、TTS全部切换到本地，只剩下对话模型走云端，这时候断网时机器人还能做几轮固定话术兜底。
• 第三阶段：用Ollama在树莓派上跑Qwen2.5-7B-Instruct的4bit量化版，本地推理，彻底打通断网闭环。实测生成速度大约8-12 token/s，口语短句场景够用，长文本会有点慢，但陪伴对话本来就不需要长篇大论。

本地模型和云API的取舍，我整理成表：

一个经验结论：如果场景是开放域闲聊、心理咨询式引导，云端大模型质量确实更好；但如果做长期陪伴，稳定、免费、私密的本地模型才是正解。最后我把两条路都保留了——默认走本地，检测到用户说“问个难问题”之类触发词时自动走云端强模型，相当于一个“增强模式”。

3. 核心模块拆解：从感知到表达的实现路径

3.1 语音链路：唤醒、听清、听懂

语音链路是陪伴机器人的第一道门槛。用户叫一声“Spark”没反应，后面全白搭。整个链路拆成三段：

第一段是唤醒词检测，我选的是sherpa-onnx框架，预训练模型里有现成的“Hey Snap”之类的唤醒词，只需要准备几十条“Spark”的录音做微调就能用。唤醒模型的优点是常驻内存占用只有几十MB，树莓派上跑毫无压力。这里有一个细节：麦克风采样率要固定为16000Hz单声道，否则模型推理出来的置信度会飘。

第二段是语音识别，同样用sherpa-onnx里的中文流式模型，WAV格式或者PCM流直接喂进去，输出文本。这套方案效果稳定，离线识别准确率在安静环境下能到90%以上，嘈杂环境就需要先做降噪。这里我踩过一个坑：ReSpeaker的驱动加载顺序会影响ALSA设备编号，导致系统重启后识别模块找不到麦克风，后面第五部分详述。

第三段是“听懂”——也就是语义理解。陪伴对话不像指令式交互，用户可能说“我今天好累”，也可能说“陪我聊会天吧”，所以不能靠固定槽位抽取。我把大模型作为对话核心，同时维护一份系统Prompt，严格规定Spark的人设、说话风格、话题边界和各种兜底策略。这里的Prompt不是随便写几句话就完事，我后面单独讲讲我踩过的“设定冲突”问题。

3.2 情感计算：如何知道用户现在不开心

这是Spark项目的灵魂模块，也是最难做“有用”的部分。情感计算我分两道线索来融合：

第一道是文本情感分析。基于大模型做零样本情感分类，输入对话文本，输出情绪维度，比如：valence（正负向）、arousal（激活度）、dominance（支配度）。举个例子，用户说“别管我”和“我不想说话”，两者表面都是负向，但前者支配度高，后者退避感强，机器人回应的策略应当不同。我封装了一个函数，每轮对话后异步调一次本地大模型做情感打分，耗时不到一秒，不阻塞主对话流程。

第二道是语音韵律特征。人在开心、紧张、疲惫时，语速、音量、音高都有差异。我从前端音频里提取三组特征：平均能量、语速（字/秒）、基频Pitch均值与抖动率。用开源的parselmouth库做Pitch提取，实测对“明显激动”和“明显低落”的判别效果不错。两道线索最后做一个加权融合，得到当前交互的情感标签。

这套融合方案不复杂，但工程上很实用。有个限制要说明：它判断的是“当前这句话的情绪”，不是“长期心理状态”，所以Spark不会试图诊断用户，只会根据情绪调整当下的陪伴话术。做情感陪伴机器人，边界感必须清清楚楚。

3.3 情感状态机与主动交互引擎

有了情感标签，接下来就是怎么用。我给Spark设计了一个情感状态机，本质是5个状态：平静、愉悦、低落、警觉、兴奋。状态机根据情感识别结果和正在进行的任务推动状态迁移。状态会直接影响三件事：

• 语音TTS的音色参数：愉悦时语速略快、音调偏高；低落时语速放慢、音量降低；警觉时语气干脆简短。
• 表情屏显示：我用一个1.3寸LCD屏做眼睛，根据状态显示不同表情动画。
• 头部动作策略：愉悦时头微微上扬，低落时低头。

主动交互引擎解决“什么时候主动说话”的问题。我设置了多种触发条件：静默超过2小时后随机开启闲聊；检测到环境声音异常（比如用户咳嗽、叹气）时询问是否需要帮助；用户连续使用超过1小时后主动提醒休息。触发策略用一套简单的优先级队列实现，避免多个条件同时触发时行为打架。

3.4 运动控制系统：让机器人“走格子”

Spark的底盘移动参考了“机器人走格子”这类经典路径规划思路。室内地板天然适合抽象成栅格地图，机器人按网格移动，每格实际尺寸40cm。在目标点确定后，路径规划用A*算法输出一串“前进、左转、右转、停止”的离散动作序列。

我写了一个简化的A*实现，核心函数如下：

import heapq def astar(grid, start, goal): open_set = [] heapq.heappush(open_set, (0, start)) came_from = {} g_score = {start: 0} f_score = {start: heuristic(start, goal)} while open_set: _, current = heapq.heappop(open_set) if current == goal: path = [] while current in came_from: path.append(current) current = came_from[current] path.reverse() return path for neighbor in get_neighbors(current, grid): tentative_g = g_score[current] + 1 if tentative_g < g_score.get(neighbor, float('inf')): came_from[neighbor] = current g_score[neighbor] = tentative_g f_score[neighbor] = tentative_g + heuristic(neighbor, goal) heapq.heappush(open_set, (f_score[neighbor], neighbor)) return []

这里get_neighbors会过滤掉障碍物栅格，heuristic我用曼哈顿距离，因为机器人只支持十字方向移动。实测下来，10x10栅格地图的规划耗时在1ms以内，树莓派上毫无压力。真正的瓶颈不在规划，而在“走直线”——电机差速会让机器人跑偏，所以我加了编码器里程计做闭环：每走一格，左右轮编码器读数差超过阈值就微调电机PWM占空比。

转向动作也有讲究。我最初直接让两个电机反向转90度，结果因为轮子打滑，实际转角常常只有80度或100度，路径越走越偏。后来改成“先原地转向、再用IMU（惯性测量单元）验证角度”的闭环方式：转完读MPU6050的Z轴角速度积分值，误差超过5度就补偿一次。

3.5 通信桥梁：从EKI借鉴的模块解耦思路

在查阅工业机器人通信方案时，我看到过Ethernet KRL Interface（EKI）这类设计——它本质上是把机器人控制器和外部计算机通过以太网接口连接，让外部程序能以标准化请求方式控制机器人执行器。这种“通信桥梁”的思路对Spark很有借鉴意义。

我没用传统工业协议，而是把“大脑”（树莓派）和“小脑”（ESP32）之间的通信设计成一组轻量JSON协议帧。树莓派向ESP32下发指令，例如：

{"cmd": "move", "distance_cm": 40, "direction": "forward"} {"cmd": "turn", "angle": 90} {"cmd": "head", "pitch": -15, "yaw": 0, "speed": 0.3}

ESP32解析后执行，并回传状态帧：

{"status": "ok", "odom_left": 12345, "odom_right": 12340, "battery": 78}

为什么不用ROS 2？原因很现实：ROS 2在树莓派上部署调试成本偏高，而且这个项目只需要点对点通信，用串口加简单协议帧就完全够用。接口设计的核心心得是：指令帧必须包含超时重试机制，否则一旦ESP32卡死，整个机器人就会“脑”与“身”分离，表现为大脑还在对话、底盘毫无反应。

4. 实操实录：从零搭建我的Spark

4.1 硬件组装与系统初始化

硬件部分我按功能块分组安装，方便拆卸排查：

• 底盘层：电机、编码器、TB6612驱动板、18650电池组（两串两并，7.4V）。
• 感知层：ReSpeaker麦克风、摄像头、ToF避障传感器、MPU6050 IMU。
• 计算层：树莓派5装在底盘上层，加一个5V/3A的DC-DC降压模块供电，以及一个小风扇主动散热。
• 表达层：1.3寸LCD屏做眼睛，两个舵机做头部俯仰和左右摆动。

系统初始化时，我把树莓派刷了64位Bookworm系统，开启I2C和串口，禁用板载蓝牙（省电且避免干扰）。然后装依赖，给ESP32刷MicroPython固件，串口波特率固定为115200。

一个很实用的建议：所有外设模块先单独测试，再组合起来。我见过太多人一上来就把所有硬件焊到一起，出了问题根本不知道是供电不足还是接线错误。

4.2 部署语音AI链路：唤醒、识别、大模型、合成

语音链路的部署是项目里最耗时的一环。流程如下：

第一步，安装sherpa-onnx并下载中文语音识别模型，推理时用SherpaOnnx类加载。第二步，配置Ollama本地模型：

ollama pull qwen2.5:7b-instruct-q4_K_M ollama serve

通过/api/generate接口调用。我给调用设了num_ctx为4096，temperature为0.7，repeat_penalty为1.1，这套参数在陪伴对话场景表现最自然。第三步，TTS用Piper本地合成，选中文女声音色，生成16kHz WAV后直接用aplay播放。为了让回复更有情感，我在TTS前会插入SSML标签（Piper支持部分韵律控制），愉悦时提高pitch，低落时降低speed。

整个链路串起来后，我写了一个主循环脚本，结构大致是：

while running: wake_word = listen_for_wake_word() if wake_word: play_tone('start') text = recognize_speech() if text: emotion = analyze_emotion(text, audio_features) state_machine.update(emotion) reply = generate_reply(text, state_machine.current_state) speak_with_style(reply, state_machine.current_state) log_to_sqlite(text, emotion, reply)

这套逻辑跑通之后，Spark终于可以在10秒内完成“被唤醒-听懂-思考-开口回应”闭环，体感上已经像一个基本可用的陪伴机器人了。

4.3 运动控制子系统的落地

运动控制子系统分两阶段落地：第一阶段是底盘闭环，先让“走格子”稳定；第二阶段是自主导航，把路径规划和底盘闭环对接。

底盘闭环的核心是电机PID调速。我调试时用了一组非常直观的参数：Kp=1.2，Ki=0.08，Kd=0.3，目标转速来自编码器每秒脉冲数（PPS）。调试方法很简单：先只调Kp到临界振荡，再缓慢加Ki消除稳态误差，最后加一点Kd抑制超调。这样调出来的效果，转向后能快速稳在目标速度，不来回抖。

自主导航模块我把它做成了一个状态机：收到目标点后，先“地图加载”，再“路径规划”，然后“逐格执行”，每执行一格检查一次避障传感器和里程计一致性，一旦偏差超过阈值就“重新定位”。这套设计在真实地面上的成功率大概是85%，剩下的15%基本是被地毯边缘、拖鞋这类动态障碍物干扰，逼着我给Spark加上“动态避障”能力，简单粗暴地采用“遇到障碍物后退10cm，右转30度重新规划”的策略，实测应对零散家居障碍足够。

4.4 交互数据管道与复购率分析

在Spark跑通基础交互后，我遇到一个新问题：怎么判断机器人是否真的做得好？这不能靠自我感觉，得看数据。为此我写了一条轻量级数据管道，整个思路继承自大数据里的批处理心智——虽然Spark机器人用不到Apache Spark集群，但这种“采集-清洗-汇总-洞察”的路数非常值得参考。

交互日志统一写入SQLite，表结构包含：会话ID、时间戳、用户文本、情感标签、回复文本、对话延迟、机器人状态等。每天凌晨，我用脚本做ETL：

• 从SQLite抽取当天日志。
• 清洗：去掉空文本、去掉唤醒误触发记录。
• 汇总：计算日均对话轮次、平均情感分布、平均对话延迟、单轮对话平均字数。
• 洞察：统计“连续7天活跃用户比例”——这个指标我戏称为“机器人版复购率”，它本质上反映的是用户黏性。

一个示例汇总脚本片段：

sql = """ SELECT COUNT(*) AS total_turns, AVG((strftime('%s', end_time) - strftime('%s', start_time))) AS avg_delay_s, SUM(CASE WHEN emotion='positive' THEN 1 ELSE 0 END) * 1.0 / COUNT(*) AS positive_ratio FROM interactions WHERE date(created_at) = date('now', '-1 day'); """

这个管道跑了两周以后，我发现一个有趣结论：当我加入“主动问候”功能后，日均对话轮次从40轮涨到65轮，但“复购率”没有显著变化——说明用户被问候之后愿意多聊几句，但并没有因此更愿意打开机器人。后来我改了策略，把主动问候变成“基于记忆的个性化问候”（比如提到前一天聊过的电影），复购率才有明显提升。这就是数据复盘带来的直接价值。

5. 踩坑实录与调试手记

5.1 常见问题速查表

把这段时间遇到的高频问题整理成表，希望能帮大家省点排查时间：

这里面我想特别强调“唤醒词没反应”这个问题。它排查起来很隐蔽：表面上是音频设备问题，实际上是Linux下ALSA设备名在每次重启后可能变化。后来我通过/etc/udev/rules.d/给USB音频设备写了固定别名规则，彻底解决了。这类问题不是算法能解决的，属于典型的嵌入式Linux工程坑。

5.2 独家避坑技巧

第一点：对话系统Prompt的人设必须隔离。我一开始把所有角色设定、情感策略、安全规则全写进一个系统Prompt，结果模型偶尔会在不同要求之间“精神分裂”，说出不符合人设的话。后来我改成“核心人设”+“会话策略”+“安全护栏”三段式Prompt，并加上“如果你不确定，宁可少说也不乱说”的指令，稳定多了。

第二点：电机PID调参千万别在硬地板上调。刚开始我在瓷砖地面调参，轮子容易打滑，导致同样的PWM占空比下速度漂移很大，调出来的参数完全没有参考价值。换成短毛地毯或瑜伽垫上调试后，编码器读数稳定，PID参数才真正收敛。

第三点：不要让你的机器人在线学习用户隐私对话。我在存储层面对所有对话日志做了本地化加密，字段级脱敏，API调用也只把必要信息发给云端强模型，并且加了内容安全过滤。情感陪伴产品的信任门槛很高，数据越少上传越好，这不仅是合规问题，更是产品底线。

第四点：陪伴机器人最容易翻车的就是“接话”时机。用户没说完就被TTS打断，用户体验极其糟糕。我加入了双向VAD检测：机器人说话时检测到用户插话，立即降低音量并停住，等用户说完再恢复。这个“让话”机制虽然简单，但对真实交互体验的提升比任何模型调优都明显。

6. 一些想对后来者说的话

Spark做到现在这个状态，坦白讲离“完美陪伴”还差很远，但作为一套完整落地的AI情感陪伴机器人原型，它让我验证了很多书本上不会写的工程细节。

我个人最大的体会是：情感陪伴机器人的核心竞争力不是单点模型的聪明程度，而是“稳定可用”和“边界清晰”。用户会容忍一个机器人偶尔说错话，但不会容忍它时好时坏、聊着聊着断线、或者在一个情绪低落时刻给出不合时宜的玩笑。因此，把底层链路做扎实，把数据管道跑清楚，把安全边界设明白，比一味追求更大的模型更重要。

如果你也想动手做一台类似Spark的陪伴机器人，我建议从最简闭环开始：一块能跑Linux的开发板、一个麦克风、一个喇叭、一个能动的底盘，然后把“唤醒-识别-大模型-合成-移动”这条链路先打通。不要在第一天就想着全功能，等基础链路稳定了，再逐步叠加情感计算、记忆和主动交互。最后再分享一个小技巧：给你的机器人取一个固定的名字，并在所有交互中保持一致称呼，这个细节会让用户更快产生“它是有生命的”这种感觉。Spark是我的尝试，希望你的那一台，也能点燃属于你的火花。