这些案例无法证明整个行业存在一个统一的故障率，也不能简单推导出所有用户都会遇到同样的问题。但它们共同呈现出一种反复出现的模式：助手的对话能力在进步，日常执行能力却依然不稳定。

自然语言越灵活，控制链路越复杂

较早一代的语音助手功能有限，但控制路径相对收敛。系统识别出请求后，通常会把它映射到预先定义、经过验证的意图和操作，例如：

setBrightness(device = kitchen, level = 50)

这种方式要求用户使用更固定的说法，但好处是可解释空间更小，语音到设备动作之间的链路也更容易重复和验证。

基于大语言模型的助手承担的任务则广得多。它可能需要依次完成以下工作：

1. 判断用户真正想做什么；
2. 解析“这里”“那些”或“灯”等指代；
3. 找到正确的房间、设备及其支持的功能；
4. 选择合适的工具或 API；
5. 填入合法的参数；
6. 结合设备当前状态执行操作；
7. 准确报告操作是否成功。

任何一个环节出错，都可能导致最终结果不对。助手可能选错设备、误解房间指代、调用设备不支持的功能、发送无效参数、依赖过时的状态信息，或者设备根本没有变化，却直接声称“已经完成”。

有关大语言模型控制智能家居的研究，将非确定性、推理延迟与成本，以及个性化能力有限，列为可靠控制设备的主要障碍。研究还指出，这类系统在处理明确、结构化的请求时表现更好；当它必须自行补全大量上下文时，表现往往会变差。

“会理解”不等于“能执行”

Amazon 和 Google 宣传的能力并非毫无价值。Alexa+ 的设计目标，是把用户对需求的口头描述映射到相关设备和功能；Google 则强调多段指令、例外条件，以及用户在一句话中途修改命令的能力。

这些能力适合用来：

• 根据“晚餐时想要温馨一点”的描述，提出一套灯光场景；
• 不打开复杂的应用菜单，直接通过语音创建例程；
• 解释一项自动化具体会做什么；
• 把含糊的请求转换为结构化的执行计划。

但理解请求和执行请求是两回事。“把房间布置得适合晚餐”确实需要一定判断；“把厨房灯调到 50%”则有明确且固定的目标。前者适合灵活的生成式模型，后者更需要一条狭窄、可验证的控制通道。

这也解释了为什么助手可能出色地处理一长串复杂指令，却在开一盏灯时失败。语言上的复杂程度，并不等于执行上的复杂程度。多设备操作有时能成功，只是因为模型恰好选对了工具和参数；而一句很短的指令，也可能因为设备解析或功能识别环节出错而失败。

延迟会放大“不可靠”的体感

可靠性不只是“最后有没有做对”。智能家居指令还需要在相对可预期的时间内完成。灯过了很久才亮，或者用户重复说了几遍才有反应，即使最终状态正确，也会让人觉得系统不可靠。

一篇对 Alexa+ 的评测称，部分回答最长需要约 15 秒，不过开灯和调节恒温器在某些情况下会更快。 关于 Gemini for Home 的后续报道也提到，更新重点包括加快响应、缩短日常指令的回答，这说明延迟仍是持续处理中的工程问题。

云端处理、模型选择、设备发现和工具调用，都可能增加等待时间。最终出现的结果是：系统理论上更强大，却在用户真正发出指令的那一刻显得更难预测。

早期用户是否成了“测试员”？

软件持续发布、不断迭代已经是行业常态。对于低风险的聊天功能，这种改进方式或许可以接受。但智能家居控制不同：它会影响实体设备和用户已经建立的生活习惯。一次更新如果改变了灯光、闹钟或自动化程序的行为，用户感受到的就不是聊天机器人界面里的小故障，而是家里的设备突然不按原来的方式工作。

不断出现的“上线后遭遇问题—随后发布修复和可靠性更新”的循环，并不能证明厂商有意把未完成的产品交给消费者。但它确实表明，用户正在系统持续调试的过程中承受实际影响。自动化被跳过、例程失效、回答前后不一致，以及投诉持续出现，都让“先发布、收集数据、再改进”的模式在日常设备控制场景中显得代价高昂。

更稳妥的发布方式，应当保留一条可靠的确定性路径，专门处理常规控制指令，再把生成式能力放在这条路径的外围。这样，用户可以获得更自然的交流体验，同时不必失去智能家居最基本的承诺：当用户发出一个明确指令时，目标设备应当及时进入目标状态。

更现实的答案：混合架构

最实际的方案并不是把大语言模型完全排除在智能家居之外，而是在错误代价最高的环节限制它的权限。

一个更稳健的系统可以让大语言模型负责理解语言和制定计划，再把结果交给控制层，由后者提供：

• 经过模式校验的设备和参数选择；
• 针对门锁、报警器等敏感操作的明确权限；
• 执行前后的实时状态检查；
• 重试机制和清晰的错误处理；
• 能区分“计划执行”与“操作已完成”的确认信息。

一项相关研究提出了“编译式 AI”的思路：大语言模型在编译阶段生成可执行的代码产物，运行阶段则由工作流编排系统以确定性方式处理分支、工具选择、错误和重试，不再让模型持续处于控制流程中。

放到智能家居里，这意味着模型可以帮助表达用户意图，却不应每次都成为决定实体动作的唯一权威。指令越接近一个固定的设备事务，执行路径就越应当受到约束、便于测试和验证。

结论：更会聊天，不代表更会操控家

Alexa+ 和 Gemini for Home 展示了生成式 AI 的一个更广泛的教训：更擅长对话，并不自动等于更擅长操作。评论员、用户和科技媒体的报道显示，这些助手能够理解更丰富的上下文、组合更复杂的请求，却仍会在灯光、调光、闹钟和例程等基础任务上失手。

真正耐用的智能家居助手，可能需要把两种方法结合起来：生成式 AI 负责让设置和交流更灵活；确定性软件负责让最终动作准确、迅速并且可验证。在这条边界被设计好之前，一个更健谈的助手可能听起来更聪明，却未必能更可靠地完成家里最基本的任务。

这些案例无法证明整个行业存在一个统一的故障率，也不能简单推导出所有用户都会遇到同样的问题。但它们共同呈现出一种反复出现的模式：助手的对话能力在进步，日常执行能力却依然不稳定。

自然语言越灵活，控制链路越复杂

较早一代的语音助手功能有限，但控制路径相对收敛。系统识别出请求后，通常会把它映射到预先定义、经过验证的意图和操作，例如：

setBrightness(device = kitchen, level = 50)

这种方式要求用户使用更固定的说法，但好处是可解释空间更小，语音到设备动作之间的链路也更容易重复和验证。

基于大语言模型的助手承担的任务则广得多。它可能需要依次完成以下工作：

1. 判断用户真正想做什么；
2. 解析“这里”“那些”或“灯”等指代；
3. 找到正确的房间、设备及其支持的功能；
4. 选择合适的工具或 API；
5. 填入合法的参数；
6. 结合设备当前状态执行操作；
7. 准确报告操作是否成功。

任何一个环节出错，都可能导致最终结果不对。助手可能选错设备、误解房间指代、调用设备不支持的功能、发送无效参数、依赖过时的状态信息，或者设备根本没有变化，却直接声称“已经完成”。

有关大语言模型控制智能家居的研究，将非确定性、推理延迟与成本，以及个性化能力有限，列为可靠控制设备的主要障碍。研究还指出，这类系统在处理明确、结构化的请求时表现更好；当它必须自行补全大量上下文时，表现往往会变差。

“会理解”不等于“能执行”

Amazon 和 Google 宣传的能力并非毫无价值。Alexa+ 的设计目标，是把用户对需求的口头描述映射到相关设备和功能；Google 则强调多段指令、例外条件，以及用户在一句话中途修改命令的能力。

这些能力适合用来：

• 根据“晚餐时想要温馨一点”的描述，提出一套灯光场景；
• 不打开复杂的应用菜单，直接通过语音创建例程；
• 解释一项自动化具体会做什么；
• 把含糊的请求转换为结构化的执行计划。

但理解请求和执行请求是两回事。“把房间布置得适合晚餐”确实需要一定判断；“把厨房灯调到 50%”则有明确且固定的目标。前者适合灵活的生成式模型，后者更需要一条狭窄、可验证的控制通道。

这也解释了为什么助手可能出色地处理一长串复杂指令，却在开一盏灯时失败。语言上的复杂程度，并不等于执行上的复杂程度。多设备操作有时能成功，只是因为模型恰好选对了工具和参数；而一句很短的指令，也可能因为设备解析或功能识别环节出错而失败。

延迟会放大“不可靠”的体感

可靠性不只是“最后有没有做对”。智能家居指令还需要在相对可预期的时间内完成。灯过了很久才亮，或者用户重复说了几遍才有反应，即使最终状态正确，也会让人觉得系统不可靠。

一篇对 Alexa+ 的评测称，部分回答最长需要约 15 秒，不过开灯和调节恒温器在某些情况下会更快。 关于 Gemini for Home 的后续报道也提到，更新重点包括加快响应、缩短日常指令的回答，这说明延迟仍是持续处理中的工程问题。

云端处理、模型选择、设备发现和工具调用，都可能增加等待时间。最终出现的结果是：系统理论上更强大，却在用户真正发出指令的那一刻显得更难预测。

早期用户是否成了“测试员”？

软件持续发布、不断迭代已经是行业常态。对于低风险的聊天功能，这种改进方式或许可以接受。但智能家居控制不同：它会影响实体设备和用户已经建立的生活习惯。一次更新如果改变了灯光、闹钟或自动化程序的行为，用户感受到的就不是聊天机器人界面里的小故障，而是家里的设备突然不按原来的方式工作。

不断出现的“上线后遭遇问题—随后发布修复和可靠性更新”的循环，并不能证明厂商有意把未完成的产品交给消费者。但它确实表明，用户正在系统持续调试的过程中承受实际影响。自动化被跳过、例程失效、回答前后不一致，以及投诉持续出现，都让“先发布、收集数据、再改进”的模式在日常设备控制场景中显得代价高昂。

更稳妥的发布方式，应当保留一条可靠的确定性路径，专门处理常规控制指令，再把生成式能力放在这条路径的外围。这样，用户可以获得更自然的交流体验，同时不必失去智能家居最基本的承诺：当用户发出一个明确指令时，目标设备应当及时进入目标状态。

更现实的答案：混合架构

最实际的方案并不是把大语言模型完全排除在智能家居之外，而是在错误代价最高的环节限制它的权限。

一个更稳健的系统可以让大语言模型负责理解语言和制定计划，再把结果交给控制层，由后者提供：

• 经过模式校验的设备和参数选择；
• 针对门锁、报警器等敏感操作的明确权限；
• 执行前后的实时状态检查；
• 重试机制和清晰的错误处理；
• 能区分“计划执行”与“操作已完成”的确认信息。

一项相关研究提出了“编译式 AI”的思路：大语言模型在编译阶段生成可执行的代码产物，运行阶段则由工作流编排系统以确定性方式处理分支、工具选择、错误和重试，不再让模型持续处于控制流程中。

放到智能家居里，这意味着模型可以帮助表达用户意图，却不应每次都成为决定实体动作的唯一权威。指令越接近一个固定的设备事务，执行路径就越应当受到约束、便于测试和验证。

结论：更会聊天，不代表更会操控家

Alexa+ 和 Gemini for Home 展示了生成式 AI 的一个更广泛的教训：更擅长对话，并不自动等于更擅长操作。评论员、用户和科技媒体的报道显示，这些助手能够理解更丰富的上下文、组合更复杂的请求，却仍会在灯光、调光、闹钟和例程等基础任务上失手。

真正耐用的智能家居助手，可能需要把两种方法结合起来：生成式 AI 负责让设置和交流更灵活；确定性软件负责让最终动作准确、迅速并且可验证。在这条边界被设计好之前，一个更健谈的助手可能听起来更聪明，却未必能更可靠地完成家里最基本的任务。