这些案例无法证明整个行业存在一个统一的故障率,也不能简单推导出所有用户都会遇到同样的问题。但它们共同呈现出一种反复出现的模式:助手的对话能力在进步,日常执行能力却依然不稳定。
较早一代的语音助手功能有限,但控制路径相对收敛。系统识别出请求后,通常会把它映射到预先定义、经过验证的意图和操作,例如:
setBrightness(device = kitchen, level = 50)这种方式要求用户使用更固定的说法,但好处是可解释空间更小,语音到设备动作之间的链路也更容易重复和验证。
基于大语言模型的助手承担的任务则广得多。它可能需要依次完成以下工作:
任何一个环节出错,都可能导致最终结果不对。助手可能选错设备、误解房间指代、调用设备不支持的功能、发送无效参数、依赖过时的状态信息,或者设备根本没有变化,却直接声称“已经完成”。
有关大语言模型控制智能家居的研究,将非确定性、推理延迟与成本,以及个性化能力有限,列为可靠控制设备的主要障碍。研究还指出,这类系统在处理明确、结构化的请求时表现更好;当它必须自行补全大量上下文时,表现往往会变差。
Amazon 和 Google 宣传的能力并非毫无价值。Alexa+ 的设计目标,是把用户对需求的口头描述映射到相关设备和功能;Google 则强调多段指令、例外条件,以及用户在一句话中途修改命令的能力。
这些能力适合用来:
但理解请求和执行请求是两回事。“把房间布置得适合晚餐”确实需要一定判断;“把厨房灯调到 50%”则有明确且固定的目标。前者适合灵活的生成式模型,后者更需要一条狭窄、可验证的控制通道。
这也解释了为什么助手可能出色地处理一长串复杂指令,却在开一盏灯时失败。语言上的复杂程度,并不等于执行上的复杂程度。多设备操作有时能成功,只是因为模型恰好选对了工具和参数;而一句很短的指令,也可能因为设备解析或功能识别环节出错而失败。
可靠性不只是“最后有没有做对”。智能家居指令还需要在相对可预期的时间内完成。灯过了很久才亮,或者用户重复说了几遍才有反应,即使最终状态正确,也会让人觉得系统不可靠。
一篇对 Alexa+ 的评测称,部分回答最长需要约 15 秒,不过开灯和调节恒温器在某些情况下会更快。 关于 Gemini for Home 的后续报道也提到,更新重点包括加快响应、缩短日常指令的回答,这说明延迟仍是持续处理中的工程问题。
云端处理、模型选择、设备发现和工具调用,都可能增加等待时间。最终出现的结果是:系统理论上更强大,却在用户真正发出指令的那一刻显得更难预测。
软件持续发布、不断迭代已经是行业常态。对于低风险的聊天功能,这种改进方式或许可以接受。但智能家居控制不同:它会影响实体设备和用户已经建立的生活习惯。一次更新如果改变了灯光、闹钟或自动化程序的行为,用户感受到的就不是聊天机器人界面里的小故障,而是家里的设备突然不按原来的方式工作。
不断出现的“上线后遭遇问题—随后发布修复和可靠性更新”的循环,并不能证明厂商有意把未完成的产品交给消费者。但它确实表明,用户正在系统持续调试的过程中承受实际影响。自动化被跳过、例程失效、回答前后不一致,以及投诉持续出现,都让“先发布、收集数据、再改进”的模式在日常设备控制场景中显得代价高昂。
更稳妥的发布方式,应当保留一条可靠的确定性路径,专门处理常规控制指令,再把生成式能力放在这条路径的外围。这样,用户可以获得更自然的交流体验,同时不必失去智能家居最基本的承诺:当用户发出一个明确指令时,目标设备应当及时进入目标状态。
最实际的方案并不是把大语言模型完全排除在智能家居之外,而是在错误代价最高的环节限制它的权限。
一个更稳健的系统可以让大语言模型负责理解语言和制定计划,再把结果交给控制层,由后者提供:
放到智能家居里,这意味着模型可以帮助表达用户意图,却不应每次都成为决定实体动作的唯一权威。指令越接近一个固定的设备事务,执行路径就越应当受到约束、便于测试和验证。
Alexa+ 和 Gemini for Home 展示了生成式 AI 的一个更广泛的教训:更擅长对话,并不自动等于更擅长操作。评论员、用户和科技媒体的报道显示,这些助手能够理解更丰富的上下文、组合更复杂的请求,却仍会在灯光、调光、闹钟和例程等基础任务上失手。
真正耐用的智能家居助手,可能需要把两种方法结合起来:生成式 AI 负责让设置和交流更灵活;确定性软件负责让最终动作准确、迅速并且可验证。在这条边界被设计好之前,一个更健谈的助手可能听起来更聪明,却未必能更可靠地完成家里最基本的任务。