用过小爱音箱的人应该都有同感硬件做工在同价位里确实不错但“大脑”总是差点意思。你问它稍微深一点的问题不是“对不起我没有听懂”就是给你返回一堆网页搜索的标题列表压根不像在对话更像在调AI客服。把大模型接进去的想法我想了很久直到看到 MiGPT 这个项目才意识到小爱音箱的改造可以做得这么干净。今年 DeepSeek 的接口价格和响应速度都到了一个很适合家用折腾的节点我就尝试在 Windows 下用 MiGPT 的 GUI 发行版把“小爱同学”的默认大脑换成了 DeepSeek整个过程从拆机开 SSH 到远程管理都走了一遍这篇就按完整流程记下来。1. “换脑”先换思路MiGPT到底接管了哪一段对话链路1.1 小爱原生对话为什么让人想动手小爱音箱的内部结构其实不算复杂麦克风阵列负责收音音频解码芯片负责放音真正决定“它怎么回答你”的是小米云端的语音服务。你喊一声“小爱同学”音箱本地只做唤醒词检测把音频传到云端云端先跑一遍语音识别ASR再用一套固定的意图引擎去猜你想干什么——查天气、设闹钟、控制米家设备这些都被提前写好了。它的困难在于只要你的话不在它的意图库里或者说法稍微绕一点系统就抓瞎了。我们说的“给音箱换脑”并不是要重新写音箱固件而是把“云端意图解析 固定答案生成”这一整段替换成我们自己的大模型。你需要一个能长期在你电脑上运行的本地服务它伪装成小米云端的那几个接口让小爱音箱继续把语音传上来但真正“思考怎么回答”的却是 DeepSeek。MiGPT 这个项目和其它 Miot 类的接管方案不同它对整条链路做的是全局接管不是简单发指令控制音箱。1.2 MiGPT架构里最核心的四个环节从部署角度看你只需要理解下面这条链路的四个关键节点环节原生小爱做法MiGPT接管后的做法唤醒检测音箱本地芯片检测“小爱同学”不变仍是本地唤醒语音识别ASR小米云端ASR本地服务请求ASR接口语义理解与回答生成小米意图引擎固定模板大模型API这里就是DeepSeek语音合成TTS小米云端TTS调用设备TTS能力播放返回文本在实际体验里你喊“小爱同学”这个动作没有变音箱依然会亮灯、有回声提示。区别是后续的“思考过程”从云端的死板逻辑变成了大模型的生成式回答。这让它不仅能回答“今天天气怎么样”这种指令型问题还能陪你聊上几句或者把一段长文本总结成几句口语化的话再念出来。对我这种主要用它当家庭语音助手的人来说聊天的连续性比原来好了不止一档。1.3 先给新手打的预防针MiGPT 不是“双击安装完就能用”的傻瓜软件它在 Windows 上的部署至少要接触三样东西Node.js 或 Docker、串口或米家 token、以及大模型 API 的配置。如果这三样你都没有概念建议先按顺序看完本文第三、四、五节再动手。另外改造不代表小米官方支持固件升级可能会让某些协议失效所以我会在后面强调拿到能用的稳定版本后第一时间把配置文件备份到一个独立目录。2. 哪些音箱能改、怎么改局域网token与TTL串口的两条路2.1 先判断你的音箱属于哪种改造路线不是所有小爱音箱都能直接通过局域网协议接管。我把市面上的型号粗分成两类一类支持通过米家局域网协议直接访问MiGPT 只需要你提供音箱在局域网内的认证信息就能工作另一类协议锁得比较死或者你想获得更底层的控制权这时候就要拆机走 TTL 串口在系统层面开启 SSH。我这次用的是一台小爱音箱 Pro刚好属于第二类。它机身底部没有眼见的螺丝拧下来之后电路板上有预留的调试串口焊盘。如果你的音箱也是 Pro 或小爱音箱 Play 增强版这类经典型号网上对应的拆机教程非常多核心思路都是一样的找 UART 引脚、接 USB-TTL 模块、在系统里开 SSH。如果你的音箱是最新的小米音箱比如带屏幕的版本建议先去项目社区确认有没有人成功跑通别盲目拆机。2.2 TTL串口接线与串口参数最容易翻车的一步拆机后你会看到一排针脚或者焊盘通常有四根线要接TX、RX、GND、VCC。注意绝大多数小爱音箱的串口电平是 3.3V不是 5V。我曾经图省事直接用了手头 5V 的 TTL 模块结果串口完全没输出查了半天才发现是电平不匹配。建议用 CH340 或 CP2102 这类常见的 3.3V TTL 模块接线方式如下小爱音箱主板USB-TTL模块TX发送RXRX接收TXGNDGNDVCC不接或按模块要求选择 3.3V接好后把 USB-TTL 插到电脑上打开设备管理器确认一下占用的 COM 口然后用 PuTTY 或 Windows Terminal 连接串口参数是波特率 115200数据位 8停止位 1无校验。这里有一个很常见的坑如果你开机后串口屏幕是乱码大概率不是波特率问题而是 TX 和 RX 接反了。对调两根线再试。如果完全没有输出先检查 GND 是否真的共地了——我见过不少人漏接 GND导致信号浮空屏幕上自然什么都没有。另外插线的时候最好在断电状态下操作别带着电去碰 TX/RX静电或短路都有可能把调试串口烧掉。2.3 在系统层开启SSH的通用思路串口连上并看到 Linux 启动日志后一般会进入一个 root shell不同型号的固件策略不一样有些需要按 Enter 激活有些直接给 root 权限。这时候我做的事情是先备份关键分区信息再开启 SSH 服务或者设置一个后门入口这样以后就不必每次都拆机连串口了。具体到不同固件路径差别很大这里不贴死命令只说通用思路先mount看看文件系统结构确认系统分区位置找到启动脚本所在目录在合适位置加入 SSH 服务启动命令如果固件里没有现成的 SSH 服务端可以准备一个静态编译的 dropbear 或对应架构的二进制文件通过串口复制进系统设置好 root 密码或密钥关闭串口之前先测试一遍 SSH 能否从局域网连上。这一步的风险和处理固件一样操作不当可能变砖。所以两个原则很重要第一全程尽量只读、可回滚不要乱删文件第二改完立刻测试重启如果 SSH 起不来至少还能靠串口救回来。我自己始终留着一个写好串口参数的 PuTTY 会话防止后续 SSH 挂了还得重新拆机。2.4 不需要拆机的用户直接走局域网token如果你判断自己的音箱位于局域网协议可接管的范围内就不用走到串口这一步。MiGPT 的配置里通常要求设置一个token或speaker标识用来在局域网内“找到”你的这台音箱。常见做法是用米家 App 或第三方工具获取设备信息把音箱的 IP、设备 ID、认证 token 填进配置里。这个 token 相当于局域网内的门禁卡作用域只在同一网段内。配置好以后你的电脑和音箱必须处于同一个局域网否则服务连不上设备。总结一下这节的结论能走局域网就走局域网别为了“极客感”去拆机。只有在局域网协议搞不定、或者你想获得更高权限时TTL 才值得动手。我这次拆机一方面是因为手上这台 Pro 的协议兼容性一般另一方面也是想顺便开个 SSH 方便后续排查属于“一劳永逸”的折腾。3. Windows侧的准备Node、端口、DeepSeek密钥一个都不能少3.1 部署方式选择直接跑Node比Docker更省心MiGPT 本身是一个 Node.js 项目社区有打包好的 GUI 版本。你在 Windows 下有两种跑法一种是装 Docker Desktop用容器跑服务另一种是直接装 Node.js用 npm 安装依赖然后启动。我的建议是如果你只是为了小爱音箱这一个用途直接用 Node.js 就好。原因很实际Docker 在 Windows 上的磁盘占用、内存占用和文件共享配置都比较重而且 MiGPT 需要和设备做局域网通信容器网络模式偶尔会出一些诡异的问题排查起来很花时间。直接跑 Node 则简单得多日志就在当前目录重启也快。安装 Node.js 时去官网下载 LTS 版本即可我用的 20.x。安装过程一路默认装完在 PowerShell 里执行node -v和npm -v能看到版本号就说明环境没问题。Git 工具也建议装一个之后从仓库拉取或更新代码会方便很多。3.2 DeepSeek密钥接口地址和模型名别填错DeepSeek 的 API 兼容 OpenAI 格式所以 MiGPT 里配置 OpenAI 客户端时只需要把默认的api.openai.com换成 DeepSeek 的地址。你需要去 DeepSeek 开放平台注册账号创建一个 API Key保存好那串sk-开头的字符串。这串 Key 就是音箱“大脑”的钥匙一定不要直接写死在别人看得到的帖子里。DeepSeek 官方给的基础地址是https://api.deepseek.com所有 SDK 请求都走这个域名如果你用的库需要拼上版本路径就写https://api.deepseek.com/v1。模型名这块Chat 场景填deepseek-chat如果要更强的推理能力可以试deepseek-reasoner。这两个名字是新版平台的标准叫法网上那些“hermes”“harness”之类的词大概率是别人瞎编的或者旧版本遗留信息别被带偏。3.3 端口规划先检查再启动MiGPT 的 GUI 管理面板会占用一个本地端口我见过不少默认是18100不同版本可能不同同时服务本体监听一个端口。Windows 上最常见的翻车原因是端口被别的程序抢了。启动服务之前可以先看一眼netstat -ano | findstr 18100如果有输出说明这个端口已经被占用后面那串数字是 PID再用tasklist | findstr PID查是哪个进程占用的。是无关程序就结束它或者去 MiGPT 的配置里改端口。这一步真的很值得做我第一次启动时 Win10 自带的一个服务就占了18100GUI 一直打不开排查了很久才发现是端口冲突。3.4 目录规划与日志习惯建议单独建一个干净的目录比如D:\dev\migpt所有配置文件、日志都放在这里。Windows 上最怕的是把日志散落在系统用户目录里以后想找都找不到。我的习惯是这样D:\dev\migpt ├── config\ # 配置文件备份 ├── logs\ # 运行日志 ├── app\ # MiGPT程序本体 └── tools\ # 串口工具、SSH客户端这看起来没什么技术含量但真到排查问题时特别管用。4. 部署MiGPT并打开GUI从配置文件到第一次出声4.1 GUI版和命令行版有什么区别社区里发布的 MiGPT GUI 版本质上是把命令行工具包了一层 Web 管理界面启动后会拉起一个本地 Web 服务你通过浏览器访问管理面板在页面里改配置、看日志、重启服务。好处是对 Windows 用户友好很多不用每次都开终端敲命令坏处是面板做得比较朴素别期待什么华丽界面它能帮你把配置和日志管好就算完成任务。我这次的启动方式是双击解压目录里的启动脚本终端窗口先出现一串日志然后浏览器自动打开http://127.0.0.1:18100这样的地址。页面里可以看到服务状态、设备连接状态、最近对话记录。这个 GUI 面板是我日常管理的主要入口后面第五节说的所有调参基本都在页面上完成。4.2 配置文件到底要填什么无论用 GUI 还是命令行核心都是那份配置。以我这次的配置为例核心长这样module.exports { speaker: { name: 小爱音箱Pro, wakeWord: 小爱同学, }, openai: { model: deepseek-chat, apiKey: sk-你的密钥, baseURL: https://api.deepseek.com/v1, temperature: 0.7, maxTokens: 200, }, };别小看这几个字段每一行都有讲究。speaker.name必须和你局域网里识别到的小爱音箱名字对上GUI 面板通常会提供一个“扫描设备”的功能点一下就能列出局域网里的音箱选择后再回填到这里。apiKey和baseURL就不用多说了DeepSeek 的 Key 填进去地址路径写成/v1结尾更保险。maxTokens这里的 200 是我根据语音场景反复试出来的值既能让 DeepSeek 给出完整回复又不会因为生成太长导致音箱念到一半就断掉。4.3 第一次启动怎么判断它真的接管成功了配置保存后重启服务然后在音箱旁边喊一声“小爱同学”。正常情况下你会听到音箱回应一声然后 GUI 的实时日志区开始滚动大致能看到这样的流程检测到唤醒词开始录音音频上传ASR 识别出文字识别文本发送给 DeepSeekDeepSeek 返回回答文本文本交给音箱 TTS 播放。这个顺序很重要。如果日志停在第 2 步说明 ASR 链路有问题停在第 3 步说明 LLM 配置不对如果在第 5 步没声音那大概率是 TTS 或音箱连接的问题。把日志当成体检报告来看后面的排查就能有的放矢。我第一次跑通时看到“音箱开口念出 DeepSeek 的回答”那一刻还是挺有成就感的因为中间踩过的坑实在太多了。4.4 用GUI管理面板做了哪些日常维护说几个我日常真实在用的 GUI 功能实时日志不用再去终端里翻所有请求和报错都按时间排好最直观配置热更新小改动比如改 prompt、改温度保存后点一下重启就能生效不用关掉整个终端窗口状态灯能看到“服务正常”还是“设备离线”音箱离线时页面会标红省得我每次都去喊一嗓子试日志导出出问题时可以一键导出当天日志方便去社区提问或自己分析。Windows 上跑这类常驻服务最怕的是休眠和网络切换。你可以去电源设置里把睡眠改成“从不”但更推荐的做法是在计划任务里给它做一个开机自启再配合一个保活脚本后面第六节会细说。5. 把DeepSeek塞进对话循环模型命名、参数与大模型语音调优5.1 DeepSeek两个模型的正确打开方式很多人刚接触 DeepSeek 时会纠结到底用哪个模型这里我直接说结论。日常语音对话场景无脑用deepseek-chat。它是标准的对话模型响应速度快对语音问答这种“短平快”的需求非常合适。deepseek-reasoner的推理能力更强但它的特点是会先思考再回答生成的文本往往更长、步骤更多用到小爱音箱上很容易出现“音箱还在念人已经听走神”的情况。除非你明确要让它做逻辑题、写代码方案或者多步推理否则不要在小爱音箱上用 reasoner。我把两个模型都试了一周最终还是固定在了deepseek-chat。接口调用的路径是一样的MiGPT 只关心配置里的model字段改一下重启就能切换测试成本很低。5.2 给大模型写一份“适合耳朵听”的提示词这是整个改造里最容易被忽略、又最能提升体验的一步。网页聊天里DeepSeek 可以给你列一堆 Markdown 标题、表格、加粗重点但在音箱端这些东西要么被 TTS 一字一句念出来要么被转成奇怪的停顿。我踩过最尴尬的坑是让它介绍一本书结果 TTS 念出了“书名-冒号-副标题-回车-第一章-回车间隔”简直灾难。我给小爱音箱的 system prompt 大致是这样你是小爱音箱里的大模型助手。请用简洁、口语化的中文回答问题。 每次回答控制在50字以内直接给结论不要列点不要使用markdown符号。 如果用户只是闲聊就自然接话不要主动建议或反问太多。这个 prompt 不是说 DeepSeek 做不到长回答而是长回答在语音场景下信息密度太低。50 字大概是念 15 秒这个时长对家庭对话场景刚刚好。如果你家里人习惯问“今天晚饭做什么”可以把回答风格改成“先给菜名再补一句做法”效果比让它输出一份菜谱好很多。5.3 温度和长度让回答既稳定又不会念断DeepSeek API 支持标准的temperature参数可以理解成“脑洞大小”。太高了回答会飘本来就短的口语回答还可能跑题太低了又显得死板。我测试下来的甜点位在0.6~0.8之间语音场景推荐0.7。maxTokens这里我建议手动限制在150~300之间别偷懒不填。因为一旦不限制遇到复杂问题 DeepSeek 可能会生成几千字的回答小爱音箱的 TTS 不会因为内容长就中断它会一直念下去你只能干等着。把上限卡死以后回答虽然可能被截断但至少不会出现“次次都要念一分钟”的尴尬情况。5.4 如何避免“AI味”太重还有一个经验值得分享让 DeepSeek 用更口语化甚至有点“家常”的语气回话比设定一堆条条框框管用。比如我试过在 prompt 里写“不要使用‘首先、其次、最后’这类词”效果一般改成“就像跟熟人说话一样一次说一句”之后回答的节奏立刻自然很多。你还可以在 prompt 里给它一个人设比如“一个住在家里、熟悉家庭成员的助手”这样它回答时会不自觉地带入场景而不是每次都端着一副通用助手的腔调。做这个项目本来就是图个“对话舒服”如果回答还是像复制粘贴的说明文那换再强的模型也没意义。6. 从“能跑”到“稳用”常见翻车现场与远程管理方式6.1 叫了没反应先从日志定位是哪一环断了“小爱同学”喊出去音箱没动静这是日常使用中最常遇到的情况。按照我的经验原因通常是这几类现象可能原因处理办法完全没反应灯不亮服务挂了看GUI状态是否正常重启服务灯亮了但没有回音ASR没连上检查网络、ASR接口地址回音了但迟迟不回答LLM请求超时检查DeepSeek Key和网络调低maxTokens回答了但声音断断续续设备连接不稳检查音箱是否进入休眠重启MiGPTGUI 日志就是定位这些问题的最好工具。我遇到过一次很诡异的现象白天用得好好的晚上回家喊没反应打开日志看到设备状态一直显示“连接中”。后来发现是路由器重启后音箱拿到了新 IP但 MiGPT 配置里还是旧 IP。这个问题在 GUI 里重新扫描一次设备就能解决但如果你没有看日志的习惯可能会以为是程序坏了。6.2 回答太慢如何判断是模型慢还是链路慢DeepSeek 在非高峰时段通常很快但偶尔也会有慢的时候。我自己的判断方法很简单看一眼 GUI 日志里“请求 LLM 开始”到“收到 LLM 回答”的时间差。如果这一步的耗时超过 5 秒基本就是 DeepSeek API 或者网络的问题如果这一步很快但音箱迟迟没声音那就要检查 TTS 环节。这里有一个现实选择DeepSeek 的reasoner模型通常要额外思考几秒所以在小爱音箱这种实时交互场景我宁可牺牲一点“聪明度”换响应速度让对话保持流畅比偶尔一次惊艳的深度回答更重要。6.3 Windows下的保活计划任务与进程守护Windows 没有 Linux 那种天然的 service 体系MiGPT 这种 Node 项目一旦窗口被关或者系统重启进程就没了。我现在的做法是把启动命令写成一个.bat脚本然后用 Windows 任务计划程序设为“开机自动运行”再把“如果任务失败每5分钟重启一次”也配好等于一个简单的保活机制。echo off cd /d D:\dev\migpt\app npm start脚本没什么复杂逻辑但配合计划任务已经能覆盖 90% 的场景。更讲究的做法是用pm2这类进程守护工具它自带崩溃重启和日志管理不过对家庭用户来说有点用力过猛。如果你和我一样只想稳定跑着不管它计划任务就够了。6.4 远程管理别随便开公网端口部署完了以后最爽的是在客厅喊一声然后躺在卧室打开手机看一眼 GUI 面板。但这里我要强调一个安全底线不要直接把 GUI 端口暴露到公网。MiGPT 这种工具一旦端口被暴露任何公网访问者都可能看到你的配置甚至拿到你的 API Key。如果你一定要在外面远程查看状态建议优先考虑局域网内远程桌面或者使用带访问控制的 Web 服务做二次代理不要把端口直接做端口映射。即便只在局域网访问GUI 面板最好也设置一个访问口令很多版本支持简单的密码鉴权别嫌麻烦。我的原则是家庭环境里“能用”和“安全”之间的平衡点就是所有网络服务默认只对局域网开放不给外部直连的机会。6.5 我踩过的一个隐藏坑Windows防火墙拦截第一次部署完同一局域网的另一台电脑死活访问不了 GUI 面板音箱和 MiGPT 之间也频繁断连。排查到最后发现是 Windows 防火墙把 Node.js 进程的入站连接默认拦了。解决办法是在防火墙高级设置里给 Node.js 或对应端口添加一条允许规则。这个问题藏得比较深因为本机访问一直正常只有跨设备才暴露。如果你也遇到类似情况先别怀疑代码检查防火墙最实在。7到这里小爱音箱在 Windows 下用 MiGPT GUI 接入 DeepSeek 的完整流程就这些了。这套方案稳定跑了两周之后我最大的感受是改造的难点并不在“接 API”这一步而在对整条语音链路的理解以及日常运维里那些不起眼的细节。直到现在我手机收藏夹里最常用的一条链接既不是配置教程也不是 API 文档而是我自己的那份排错日志。最后再说一个实际操作中的体会不要把这次改造当成一锤子买卖。DeepSeek 那边的模型版本会更新MiGPT 社区也会修 Bug每隔一段时间去升个级、看两眼日志其实挺有趣。你部署的不仅是一个会回答问题的音箱更是一台可以让全家人都感受到“啊原来 AI 真的能这么用”的家庭设备。