我把天猫精灵改造成大模型语音助手，然后放弃了
折腾了两天、约 8 小时，从规划、编码、部署到调通全链路，最后得出一个结论：此路不通。把踩过的坑都写在这里，给想干同样的事的人省点命。
缘起
家里吃灰的天猫精灵 X1，一直想给它接上大模型，让它从”人工智障”变成真正的智能助手。
参考对象是 GitHub 上很火的 mi-gpt——给小爱音箱接入 ChatGPT，无缝对话，体验丝滑。我就想：同样的思路，能不能在天猫精灵上复刻一份？
手头资源：一台天猫精灵 X1、一个天猫精灵开发者平台账号、一台跑 Termux 的小米 10（当局域网服务器）、一台 Windows 电脑。
先研究 mi-gpt 的原理。它能做到”无缝劫持”，靠的是小米云端暴露了非官方的 MiNA/MiIOT 接口：每秒轮询音箱对话记录 → 检测到新提问 → 暂停小爱原生回答 → 调 LLM → 通过 TTS 指令推送回复。全程零硬件改造，纯云端遥控。
再看天猫精灵这边：X1 跑的是轻量 RTOS（不是 Android），256MB 内存，没有 root 方案，更关键的是——天猫精灵没有开放任何类似 MiNA 的对话轮询接口。mi-gpt 那套”监听+替换”的玩法，从架构上就走不通。
于是退而求其次，选了官方支持的路线：AliGenie 自定义技能 + LLM Webhook。
方案架构
1 | 用户语音 → 天猫精灵X1 → AliGenie云端NLU → Webhook回调 |
听起来不复杂：在开放平台建一个技能，把后端指向自己的 Flask 服务，收到请求转手喂给大模型，把回答塞进回复字段。
理想很丰满。
实战：三个阶段，一路填坑
阶段一：后端搭建
技术选型 Python + Flask + requests，图一个轻。服务代码核心就一个 POST 接口，接收平台 JSON、提取用户话语、调 LLM、按协议返回。
坑 1：千问 Coding Plan 的 endpoint 和模型名。
用的是阿里云百炼 Coding Plan 的 key，base_url 是 coding.dashscope.aliyuncs.com/v1。结果 qwen-turbo、qwen-plus 全部报”model not supported”。查了一圈才发现这个端点只支持 Coding Plan 套餐内的模型（qwen3-coder-plus、qwen3.5-plus、kimi-k2.5、glm-5 等）。换成 qwen3-coder-plus 才通。
阶段二：部署到 Termux
打算让小米 10 的 Termux 当 24 小时服务器。然后迎来了本文章节最密集的一段坑。
坑 2：Termux 的 pip 是坏的。
Python 升级到 3.14 后，pip 的 shebang 还指向 python3.13，直接报 bad interpreter。解法：用 python -m pip 代替 pip。
坑 3：openai SDK 在 Android 上装不上。
新版 openai SDK 依赖 jiter（Rust 写的），Termux 编译需要 maturin 且要 ANDROID_API_LEVEL 环境变量，直接失败。解法：干脆不用 openai SDK，用 requests 直接调 OpenAI 兼容 API，依赖从一堆缩到 flask + requests 两个。
坑 4：Flask 跑在 /sdcard 上，热重载是假的。
改完代码 push 到手机，Flask debug 模式检测不到文件变更（FUSE 文件系统的锅），必须手动重启。更惨的是多次重启残留了 4 个 python 进程抢 5000 端口，新代码死活不生效，一度以为代码写错了。排查到 ps 看见多实例才破案。
阶段三：对接平台
在 AliGenie 技能应用平台创建语音技能、配置意图、下载认证文件、填后端 URL。
坑 5：认证文件机制。
平台保存后端 URL 时，会去访问 你的域名/aligenie/xxx.txt 验证域名所有权。文件放对位置前，保存一直报”未正确获取到认证文件”。
坑 6：Windows 的 curl 发中文 JSON 是 GBK 编码。
这个坑迷惑性极强：明明改了代码，测试却”行为不变”。真相是 git-bash 里的 curl 把中文按 GBK 编码发出去，Flask 按 UTF-8 解析成乱码，字符串匹配全部失效。测中文接口一律用 Python requests，别用 curl。
坑 7：调用词”AI”直接”调用失败”。
第一版调用词设成”AI”，结果对音箱说”天猫精灵，AI”，返回”调用失败”。英文短词在平台 NLU 里有冲突。改中文。
坑 8：调用词”问小杜”被”小度”截胡。
改成”问小杜”后，对音箱说”天猫精灵，问小杜”，它开始一本正经地介绍百度的小度机器人……谐音撞车，内置技能优先级压过自定义技能。
坑 9：意图不支持自由文本。
这是最致命的一个。理想中”天猫精灵，两只小可爱，今天天气怎么样”，平台会剥离调用词”两只小可爱”，拿剩余文案去匹配意图例句。例句没有的内容，一律匹配失败（意图 null），根本不会回调你的服务器。
所谓”动态意图”（官方文档里接收任意输入的机制），实测无效。
坑 10：改完意图必须手动”语音交互模型训练”。
例句、意图标识任何改动，都要点”语音交互模型训练”重新上传训练，还要等几分钟生效。不知道这点的话，会陷入”明明配了例句为什么匹配不上”的死循环。
坑 11：技能审核中无法编辑。
提交审核后想改后端 URL？不行，”期间无法进行编辑”，必须先撤回审核。
最终能跑通的交互形态
绕了这么多弯，这个技能实际能做到的对话形态是这样的：
1 | 用户：天猫精灵，两只小可爱 |
注意两个硬约束：
- 用户说的话必须命中预配置例句，否则平台直接兜底”对不起，我暂时还不支持这项功能”，压根不给你服务器机会。想覆盖更多场景，只能一条条加例句、重新训练。
- LLM 必须在几秒内返回。 平台回调超时阈值很短。中间试过通用模型 qwen3.5-plus，写诗要 32 秒，音箱直接”歇菜”；换回 qwen3-coder-plus 约 4 秒才勉强达标。
还有一个隐蔽问题：LLM 回复里的换行符会让音箱 TTS 播报中断。写诗、列清单这类结构化输出必踩。解决办法是在返回前做文本清洗：
1 | def clean_for_tts(text, max_len=200): |
算一笔账
| 项目 | 成本 |
|---|---|
| 时间 | 约 8 小时，含凌晨两点调试 |
| 现金 | ≈ 0（复用已有 API 套餐，隧道免费，零硬件购置） |
| 连带损失 | Termux 环境被折腾坏过一次，额外花时间恢复 |
| 产出 | 一套可用但鸡肋的技能 + 一肚子平台限制知识 |
为什么说是鸡肋
因为做出来之后发现，它连最基本的”自由对话”都做不到：
- 想问的问题得先命中例句，等于提前把用户话术枚举一遍；
- 简单问题（天气、时间）平台内置技能自己就能答，显得我们的 LLM 很多余；
- 稍微开放一点的问题（写诗、推理、闲聊），要么匹配不上，要么超时；
- 每改一次话术，要重新训练、等生效、甚至撤回审核。
折腾到最后，音箱能体面回答的，还是那些它本来就会的问题。
复盘：不是实现问题，是架构问题
回头看 mi-gpt 为什么成：小米云端开放了对话记录的读取和 TTS 的写入接口，等于给第三方留了一条”旁路劫持”的通道，所以能做到无缝接管。
天猫精灵这边，开放平台只给了”技能回调”这一条正门，而正门的通行规则（例句匹配、超时阈值、审核流程）决定了它天然做不了自由对话。
平台没打算让第三方这么玩，再精巧的实现也只是在别人的地基上违章搭建。
给后来者的建议
如果你也想给智能音箱接大模型：
- 小米音箱 + mi-gpt：生态最开放，方案最成熟，直接抄作业；
- 自带 LLM 的新款音箱：比如已接入各家大模型的产品，别折腾二开；
- 预算够的话：ESP32/树莓派 + 开源语音助手（wukong-robot 之类），完全自主可控；
- 只有天猫精灵的话：趁早放弃这个念头，把它当个普通音箱用就好。
代码我留在本地了（Flask + 协议封装 + TTS 清洗那一套），万一哪天平台政策松动，或者要抄这份避坑指南的人需要，随时能捡起来。
但大概率是不会了。
本文涉及的所有 API Key、账号、设备标识均已脱敏。项目全程未产生硬件费用，API 调用走已有订阅套餐。