给家庭中控、语音终端或智能家居系统加入大模型，不能只确认“支持Matter”。Matter帮助设备与控制平台建立共同的交互方式；理解用户的话、决定能做什么、核对设备是否真的执行，还需要另外设计。设备接得进来、指令发得出去、用户任务完成，是三个需要分别验收的结果。
本文面向智能家居品牌方、家庭终端厂商和方案采购负责人，由普众数智整理。我们以官方技术资料说明能力边界，并给出项目讨论清单；文中的家庭情境与实施流程均为需求分析示例，不是客户案例或产品性能承诺。
一、Matter主要解决“怎样互联”，并不替你定义产品任务
Google Home开发者文档将Matter介绍为智能家居开放标准，并说明其提供基于IP的本地连接路径，同时提醒开发者核对设备类型、硬件资源和网络条件。[1] 对采购方而言，“支持Matter”应当进一步落实为具体型号、功能和目标控制平台。
例如，一盏灯接入了目标平台，用户可以控制开关，不代表灯具原厂应用里的每一种动态灯效都会同时出现。设备支持的功能、控制平台开放的功能，以及项目应用最终呈现的功能，可能有差别。项目不能只凭包装上的标识判断全部体验。
把“支持”写成可以逐条验证的清单会更有效：
- 哪些型号和固件版本已验证？只是计划支持的，单独列出。
- 哪些操作可以读写，哪些状态能返回？不要把能开关当作全部功能可用。
- 首次添加、设备重置、平台更换分别由谁完成？失败后有哪些恢复步骤？
- 需要额外控制器或网关吗？相关硬件、部署和维护是否包含在报价里？
若方案涉及桥接，继续确认桥接后有哪些设备和属性对外可见。不要把某个网关能连接若干品牌，扩展成它能让这些品牌的全部设备、全部功能互通。
给项目负责人的直接建议：先确定首批兼容清单，再做全屋方案的范围和报价。 “一个系统控制所有设备”可以作为愿景，合同与验收应当写到已经确定的对象和功能。
二、Matter、Thread和家庭控制器，分别要问什么？
Home Assistant官方文档区分了Matter控制协议与Thread网络，并提醒：有Thread标识，并不必然代表设备支持Matter；Matter over Thread设备还涉及边界路由器。[2] 采购时，不应把这几个名词当成可以互换的产品能力。
可以从实际采购问题来区分：
买设备时，问“它接受什么控制”。 除了品牌与型号，还要确认目标设备的Matter支持情况、固件条件，以及需要对接的操作。不要只检查芯片是否具备某种无线能力。
做网络时，问“消息怎样到达设备”。 如果项目使用Thread设备，就要把相应网络与边界路由器纳入部署。现场已有的Wi-Fi设备也要确认能否与控制器稳定通信。多个网络区域、路由器更换或访客网络，都值得列入现场检查。
选控制平台时，问“谁管理设备和状态”。 控制器、设备列表、命名、房间归属及接入权限，需要有明确的管理入口。如果设备在测试人员手机上能用，但交付给客户后无法添加或恢复，项目仍然没有完成交付。
这些问题看似琐碎，却直接影响安装成本和售后责任。与其在报价后补一台网关、补一次上门配置，不如在方案阶段把现场现状记录清楚。
三、本地控制可用，不等于整条AI语音链路都能离线
“断网还能用”必须明确断的是哪一段网络、保留的是哪项功能。例如，外网中断、家庭局域网故障、某个无线设备掉线，是不同的测试条件。
Matter设备的本地控制路径与语音识别、模型推理、语音合成是否依赖远端服务，需要分别讨论。Home Assistant也提供了完整本地语音助手的官方配置路径。[3] 这说明语音处理可以采用本地路线，但不能据此推断任意家庭终端已经具备相同能力。
假设目标任务是“关掉书房的灯”，可以把依赖写成四行：
- 听到指令： 唤醒与语音输入是否在本地处理？外网中断后是否仍接受输入？
- 理解对象： “书房的灯”对应哪个设备？需要远端模型才能识别，还是存在明确的本地命令？
- 完成控制： 控制器与目标设备之间的网络和权限是否可用？
- 给出答复： 设备状态能否返回，提示是否依赖在线语音合成？
其中一项依赖外网，就不能用“本地控制”概括整条体验。反过来，如果开放式问答不可用，但固定设备指令仍可执行，也应当在产品提示里清楚区分。
建议验收至少包含外网正常、外网中断但局域网正常、目标设备离线三个条件。每种条件都记录用户输入、系统提示和设备实际状态。这里的测试组合是工程建议，不是任何标准规定的统一合格门槛。
四、大模型接入后，关键变化是权限和执行流程
大模型能够理解更自然的表达，但理解不是执行授权。Home Assistant的OpenAI集成文档明确说明，设备控制依赖Assist API，并允许用户配置向智能体开放的实体。[4] 这是一个可以参考的实现例子，不是所有平台共同具备的功能保证。
对居家智能项目，我们建议先给设备操作分类，再决定智能体可以怎样调用。
查询类： 例如查询已经接入的传感器读数。先确认数据来源、更新时间和不可用时的提示，避免把旧状态说成当前状态。
普通控制类： 例如关闭已经授权的灯具。需要明确对象、可用操作、请求是否重复，以及成功依据。接口返回“已接收”时，只能说明请求进入了处理流程，不应直接说设备已经关闭。
需要额外确认的操作： 对项目认为影响较大的设备或场景，单独设计确认条件、操作者范围和人工处理入口。不能仅凭一句自然语言指令，就默认拥有整个家庭所有设备的操作权限。
权限设计不应只留在提示词里。建议让应用或控制服务实际限制允许操作的设备和动作；智能体生成的参数仍经过校验。用户调整家庭成员、设备归属或授权范围后，系统也应能同步处理。
这里还存在一个容易忽视的问题：名称会变化。“客厅灯”“沙发边那盏灯”“阅读灯”可能指向同一对象，也可能不是。命名、别名、房间和当前对话上下文，应形成可维护的映射；对象不明确时先询问，优于猜测后执行。
五、用一个“离家场景”验收，不要只看一次成功演示
下面是一个需求分析示例：用户说“我要出门了”，系统按用户预先确认的场景关闭指定灯具，并反馈结果。这个例子并不预设家庭里所有设备都已接入，也不包含门锁、安防等额外操作。
先写清动作范围。 哪些灯应该关闭，哪些设备需要保持？场景范围由用户配置，不能让模型临时扩大。
再写清完成条件。 如果目标包含三盏灯，其中两盏成功、一盏离线，回复应说明部分完成。不能因为场景接口整体返回成功，就把每台设备都视为执行成功。
然后测试重复与中断。 用户连续说两次、执行中改口、控制器重启后恢复，分别怎么处理？针对这些情况设计测试，才能发现单次演示覆盖不到的问题。
最后保存可以复查的记录。 保留场景配置、设备版本、网络条件、请求时间和返回状态。需要保存哪些信息、谁能查看、保存多久，应在项目的数据管理方案中明确，不是越多越好。
这套验收方法的重点，是让每个“完成”都对应具体证据。不能把模型回答流畅、控制平台显示在线、设备最后处于目标状态这三个现象，简单当成同一条任务可靠完成的证明。
六、方案讨论时，把这六项放在同一张清单上
设备范围： 首批型号、固件、已验证操作、可读取状态，以及暂不支持的部分。
网络与控制器： 现场网络条件，所需网关或控制器，部署方式和故障处理责任。
语音与智能体： 哪些输入由本地处理，哪些请求调用远端服务，服务不可用时保留什么能力。
权限与数据： 可访问设备、允许操作、家庭成员配置、数据发送位置及必要的管理入口。
验证与交付： 成功、部分成功、离线、重复请求、恢复过程分别怎样验证，哪些材料随项目交付。
持续费用： 除设备和定制开发外，是否包含模型调用、语音服务、云端功能、现场安装和后续维护；计费口径与服务边界分别是什么。
对品牌方而言，这份清单比单独比较“用了什么模型”更能判断方案是否适合。不同供应商也可以围绕同一批设备、同一组任务、同一套网络条件给出报价，避免把范围不同的方案直接比总价。
常见问题
设备有Matter标识，还需要实机联调吗？
需要。项目仍要确认目标型号、版本、平台功能和现场条件，尤其是希望交付的具体任务。标准支持与项目验收解决的是不同层面的问题。
先做设备互联，还是先选大模型？
可以同步评估，但建议先固定首批设备与任务边界。接入条件不明时，单纯比较模型回答质量，无法判断最终能否控制目标设备。
智能体可以自动发现并管理家里所有设备吗？
不能这样承诺。发现、接入、授权、功能开放和实际执行需要分别验证；本文没有证明任何方案已经覆盖全部品牌和设备。
旧设备一定要更换吗？
不能一概而论。先核对现有设备是否有可用的本地或云端接口、桥接方案，以及它们能开放哪些功能，再比较保留、改造与替换的成本。不要预先把所有旧设备都算成可以接入，或全部必须淘汰。
普众数智建议，从一个明确的家庭任务和一份兼容清单开始讨论居家智能方案。官网：https://www.puzkj.com/ 。本文提供需求与选型方法，不承诺具体设备兼容范围、产品性能或交付周期。
参考资料
以下为原始官方文档，核对日期：2026年10月17日。动态文档后续可能更新；资料中的平台能力不代表普众产品已逐项实现。
[1] Google Home Developers：What is Matter? https://developers.home.google.com/matter/overview
[2] Home Assistant：Matter集成及Thread、控制器说明 https://www.home-assistant.io/integrations/matter/
[3] Home Assistant：Set up a fully local voice assistant https://www.home-assistant.io/voice_control/voice_remote_local_assistant/
[4] Home Assistant：OpenAI集成、Assist API及实体开放范围 https://www.home-assistant.io/integrations/openai_conversation/