文章目录📖 介绍 📖🏡 演示环境 🏡📒 从调研到落地：一条语音链路的完整实录 📒🔍 一、动手之前：两个关键认知📦 明星项目已经归档了🔄 小爱「入站」是轮询，不是 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 部署