文章目录
- 📖 介绍 📖
- 🏡 演示环境 🏡
- 📒 从调研到落地：一条语音链路的完整实录 📒
- 🔍 一、动手之前：两个关键认知
- 📦 明星项目已经归档了
- 🔄 小爱「入站」是轮询，不是 webhook
- ⚖️ 二、方案选型：四条路，为什么选桥接容器
- 🅰️ 方案 A：直接用小爱 ⇄ AI 的现成项目
- 🅱️ 方案 B：让点歌服务的 webhook 直连网关
- 🌉 方案 C：独立桥接容器（最终采用）
- ⏰ 方案 D：网关自己的定时任务轮询
- 📊 四条路摆在一起看
- 🎯 选型结论
- 🏗️ 三、架构与消息流转
- 🕳️ 四、实战：10 个真实的坑与修复
- 🛡️ 坑 ① 语音容器的 webhook 带不了认证头
- 📚 坑 ② 两边数据格式差了六层
- 🗺️ 坑 ③ NAS 上 Docker 的路径陷阱（最隐蔽的一个）
- 🔌 坑 ④ 容器端口绑定不生效
- 🚪 坑 ⑤ 飞书 open_id 跨应用被拒（排查最久的一个）
- 🔇 坑 ⑥ 语音容器的 webhook 推送会静默卡死
- 🕳️ 坑 ⑦ 静默黑洞：被跳过的消息不留日志
- 🔍 坑 ⑧ 日志级别盲区
- 🕐 坑 ⑨ 容器时区不是本地时间
- 🏷️ 坑 ⑩ compose 标签陷阱
- 🧩 附：两个小坑
- ⏱️ 排查时间线：这些坑分别花了多久
- 🧭 十个坑的分布规律
- 🛠️ 五、完整实现步骤（读者手动版）
- 📋 前置条件
- 🎵 01 部署语音服务并装 miot 插件
- 🔗 02 开启网关的 hooks 接口
- 🐳 03 部署桥接容器
- 📡 04 在语音服务注册 webhook
- 📍 05 确认投递目标（最容易翻车的一步）
- ✅ 06 端到端验证
- 🎚️ 07 调优
- 🤖 六、提示词版：让 AI 帮你自动部署
- 🎙️ 七、口播体验优化：一个容易被忽略的细节
- 💬 两次回复的节奏
- 🎭 确认语要即兴，不重复
- 📢 口播适配硬规则
- 🚧 生效范围必须隔离
- ⏳ 追问窗口
- 📌 八、总结与延伸
- 💡 这个方案的本质
- 🎓 五个最值得记住的教训
- 🚀 延伸方向
- ⚓️ 相关链接 ⚓️
📖 介绍 📖
我在 NAS 上用 OpenClaw（我喜欢叫它「小龙虾」🦞）搭了一套自己的 AI 助理团队——查资料、盯持仓、管家务。平时使唤它靠飞书打字，方便是方便，但总有腾不出手的时刻：开会、做饭、手上正忙，想让它查个东西，只能先放下手里的活儿。
家里那台小爱触屏音箱，买回来没多久就吃灰了。有天做饭时手上全是油，又特别想让它查个东西，才忽然意识到：语音才是最自然的入口——这话说出来，音箱就摆在那儿，可它和我的 Agent 团队之间，隔着一条没人接的链路。
于是花半天时间，把「小爱音箱 ⇄ 小龙虾 OpenClaw」打通了。现在对着音箱喊一声「小龙虾，帮我看下持仓」，两秒后小龙虾开始干活，结果直接从小爱嘴里念出来。吃灰的音箱，就这么重新变成了最好用的那个入口。
这篇文章不是「Hello World」式的教程。整个过程——四条方案的取舍、十个真实的坑、完整的复现步骤、以及一段可以直接喂给 AI 的部署提示词——全部摊开写出来。坑那部分尤其值得看：每一个都有日志实证，是文档里查不到、只有真部署才会撞上的。
🏡 演示环境 🏡
- 🏠 运行平台：飞牛 NAS（fnOS），Docker 部署
