会聊天了，却更不听话：生成式 AI 智能家居为何仍不可靠

生成式 AI 智能家居的问题，恰恰不是它们“不够聪明”，而是它们在最需要稳定的时候，仍然表现得像一个会猜测的语言模型。

用户让音箱关灯、播放一首歌、设置计时器，期待的不是一段漂亮的对话，而是设备立刻、准确地完成动作。语言模型可以理解更自由的说法，也能临时编排多步骤任务；但它的推理结果具有波动性，再加上额外延迟、工具选择错误和 API 兼容问题，反而可能让这些原本简单、重复的操作变得不可靠。16

失败的不是极端场景，而是“关灯”和“放歌”

目前最令人失望的地方，是故障往往出现在智能音箱最基本的职责上。

在对 Gemini for Home 的测试中，系统忽略了播放音乐的请求，聊天时突然转换话题，在周三坚持说当天是周二，还拒绝关闭智能灯，并声称自己“无法控制或操作家中的照明及其他实体设备”。1 对于一款主打智能家居控制的音箱来说，这些并不是罕见的边缘案例，而是用户每天都可能提出的请求。

Alexa+ 的表现同样有两面性。有评测发现，它可以仅凭语音创建包含触发条件、设备和时间范围的自动化例程，甚至能正确识别用户在应用中使用了不同名称的设备。2 但另一方面，Alexa+ 也被报道无法执行此前一直正常工作的咖啡例程；一些用户还表示，升级后原有例程消失了。67

这说明问题并非生成式助手完全没有能力，而是同一套能力缺乏一致性：它有时能完成复杂任务，却可能在下一次执行最简单的指令时出错。

传统助手追求确定，LLM 天生带有不确定性

传统语音助手的工作方式相对直接。系统识别出“关闭厨房灯”这样的指令后，会将设备名称和动作对应到一个固定意图，再调用预先定义好的 API。只要设备在线、权限正常，同样的指令通常会触发同样的操作。

大型语言模型则不同。它会结合上下文，对用户意图进行概率推断，并生成下一步应该调用哪个工具、以什么参数调用的方案。谷歌也将 Gemini 描述为具有“非确定性”（non-deterministic），也就是说，它并不是简单地按照固定脚本逐条执行。15

这种架构很适合开放式对话。用户不必记住严格格式，可以说“把客厅弄得舒服一点”，让系统自行理解可能涉及的灯光或温度。但对物理设备控制而言，灵活性也会变成风险：看似相同的请求，可能在不同轮次被不同地解释、路由或执行。315

“关掉灯”必须始终意味着同一个物理动作，而不能因为模型临时改变了判断，就变成追问、闲聊，或一个无法执行的工具调用。

家庭控制最看重的，仍是速度和可靠性

用户和业内观察者反复指出，智能家居助手的关键指标并不是它能否进行多轮闲聊，而是能否快速、稳定地完成任务。相关报道将可靠性、延迟和产品价值列为主要挑战；用户反馈则集中在响应变慢、回答错误、指令丢失、选错音乐以及例程消失等问题上。1257

这也意味着，生成式模型不应成为设备控制链路中唯一的决策者。更稳妥的设计，是让模型负责理解自然语言，再由确定性的验证和执行层检查设备、权限、参数与安全条件，最后调用明确的设备接口。对于高风险操作，还应提供确认步骤、清晰的失败原因和传统控制方式作为后备。

换句话说，智能家居需要的不是“更像人”，而是“像一个不会擅自发挥的可靠开关”。

苹果也没有绕开这道难题

这并不是亚马逊和谷歌独有的困境。苹果也曾因工程问题和软件缺陷推迟个性化 Siri 功能；由于新 Siri 尚未准备就绪，其原本规划中的智能家居显示设备也被推迟。482

另有报道指出，现有 HomePod 级别硬件的处理能力可能不足以支撑苹果更新后的 AI 目标，这也有助于解释相关硬件刷新延迟以及 Siri 体验的不均衡。914

演示成功，不等于产品已经成熟

生成式 AI 的演示很容易让人相信：只要助手能够理解自然语言、记住上下文并自动创建例程，智能家居就会迎来一次飞跃。但演示中的一次成功，不能证明系统已经具备长期运行所需的稳定性。

控制家庭设备的产品，至少应当满足四个条件：行为可预测、失败方式明确、响应足够迅速，并且在模型出错时有安全的备用路径。日历、购物和通信等任务同样如此。

如果这些基础属性尚未建立就把产品推向市场，集成测试、漏洞发现和故障成本就会转嫁给付费用户。说得更直白些，消费者就成了产品的测试团队。