选智能家居供应商最贵的一种错误，是买了“Logo列表”，却没有买到一套自己真正看得懂的架构。

方案里写着“Matter兼容”“支持Thread”“本地控制”“兼容主流生态”，这些话可能都是真的，但仍然没有回答：谁负责Commissioning、谁是Controller、谁是Bridge、Thread Border Router在哪里、断网以后什么还工作、固件谁维护、换Hub怎么恢复、日志在哪里看、产品能支持多久。

到了2026年，这件事更重要。Connectivity Standards Alliance在2026年6月17日发布Matter 1.6，加入更完整的NFC Commissioning以及Joint Fabric等跨生态管理能力；Thread 1.4也正在不同平台和设备中推进。但标准发布和你今天拿到的这台Hub已经完整实现完全是两件事。

所以供应商会议不要再只问“支不支持Matter”，而要问：“在我们这个部署里，你的产品到底承担哪个角色，今天现场能不能演示？”

下面15个问题，适合采购、渠道、集成商、Builder或大规模部署前逐项问。

1. 你的产品到底承担哪些角色？

让供应商直接勾：

  • Matter Controller；
  • Matter Commissioner；
  • Thread Border Router；
  • 把Zigbee、Z-Wave或私有设备暴露到Matter的Bridge；
  • 本地自动化引擎；
  • Cloud Relay；
  • Wi-Fi路由/AP；
  • 远程访问与账号服务。

这些角色不是同一个东西。

Thread Border Router负责把Thread网络接到其他IP网络；它不自动等于Matter Controller。Bridge可以把旧设备映射给Matter生态，也不意味着旧设备突然变成原生Matter-over-Thread产品。

如果对方说“我们Hub全都做”，请让他画架构图。

2. 今天正式出货的到底实现了哪个Matter版本？

Matter 1.6是2026年6月17日发布的，但这不表示每个平台、每个设备当天就拥有全部1.6功能。

要求对方写清：

  • 当前认证/实现的Matter版本；
  • 对应固件版本；
  • 真正暴露的Device Type / Cluster；
  • 该版本里哪些功能已经实现；
  • 哪些明确没有实现；
  • 已安装硬件以后怎么升级。

关键词只有一个：今天可测试。

行业媒体对Matter 1.6的报道也一直提醒，Specification上线和Apple、Google、Amazon、SmartThings或具体厂商真正落地之间存在时间差。

3. 如果用了Thread，Border Router到底在哪里？

Thread Group对Border Router的定义很清楚：它把Thread网络路由到其他IP网络，不需要在应用层翻译内容，而且一个Thread网络可以存在多个Border Router。

落到住宅项目里，要继续问：

  • 具体哪台设备是Border Router？
  • 客户家里已有Apple/Google/Samsung设备时怎么办？
  • 多个Border Router会协作，还是生成多个网络？
  • 是否支持Thread 1.4相关凭证共享能力？
  • 最常用的Border Router掉线后，谁接管？

“Thread自己会Mesh”不能算完整答案。

4. 断网以后到底还有什么能用？

要求现场拔掉WAN演示。

测试：

  • 本地开关；
  • 传感器触发自动化；
  • 定时；
  • Scene；
  • 条件允许时的门锁操作；
  • 手机仍连本地Wi-Fi时的App控制；
  • 语音；
  • 通知；
  • 历史数据。

“支持Local”这个词太宽。它可能意味着真正本地运行，也可能只是“一个基础开关命令不走云，但App、自动化和远程逻辑仍依赖云”。

把断网行为写进验收表。

5. 如果你们的Cloud账号服务消失了，会怎样？

这是退出机制问题。

问：

  • 没有原云账号还能不能Reset和重新Commission？
  • 本地凭据掌握在客户还是厂商？
  • Automation能不能导出？
  • 配置能不能备份？
  • 远程访问是不是长期付费服务？
  • 厂商停止维护以后，本地功能是否继续？
  • 能不能换Controller而不换整屋硬件？

Hub属于基础设施，至少应该按“家里路由器”这个级别去考虑失败恢复，而不是按新奇小电器。

6. 你们现在真正的多生态控制怎么工作？

Matter一直在推进多生态，1.6又加入Joint Fabric，希望多个授权Controller更协调地管理同一网络。

但采购必须问今天的产品：

  • Apple Home、Google Home、Alexa、SmartThings、Home Assistant等目标生态是否都能控制？
  • 是不是每个生态都要单独Commission？
  • Automation是否共享？
  • 权限是否同步？
  • 一个生态删掉设备以后，其他生态发生什么？
  • Joint Fabric是今天支持、Roadmap支持，还是根本不支持？

不要用标准路线图替代当前交付能力。

7. 通过Bridge以后，到底丢了哪些能力？

Bridge很有价值，尤其是存量设备，但“设备能出现”不等于“功能完全一样”。

直接要求一张表：

设备 原生能力 Bridge后暴露 缺失/变化
灯 调光、颜色、场景 ? ?
锁 状态、PIN、日志 ? ?
温控 设定点、模式、Schedule ? ?
传感器 数值、电量、提醒 ? ?

真正要问的是：客户在意的工作流通过Bridge以后还在不在。

8. Firmware与Security Update怎么做？

至少问：

  • 自动还是人工；
  • 分批灰度还是一次全推；
  • Firmware有没有签名；
  • 能不能Rollback；
  • 最低支持年限；
  • 安全公告机制；
  • Hub、Bridge、App、Cloud分别谁负责Patch；
  • 更新把第三方集成打坏以后谁处理。

如果你是Builder、门店、集成商或物业运营，还要问能不能跨多个项目看版本状态。

9. 认证到底对应哪个SKU和Firmware？

“Matter Certified”后面应该跟证据。

要求精确到：

  • Model Number；
  • 销售地区；
  • Firmware/Software Branch；
  • Radio Variant。

同时把协议认证和当地可能要求的电气、无线、产品安全、法规审批分开。

认证能降低某一类风险，但不等于“所有第三方生态组合都一定表现完全相同”。

10. 晚上8点客户家网络坏了，你们怎么诊断？

销售Demo发生在干净环境，售后发生在真实住宅：Mesh Wi-Fi、厚墙、旧路由器、多个Hub、拥挤2.4GHz，以及家人刚改过密码。

要求看看真正的诊断界面：

  • Device Health；
  • Last Seen；
  • 能提供时的Topology/Route；
  • RSSI/Link Quality；
  • Thread Network Identity；
  • Border Router状态；
  • Controller日志；
  • Firmware；
  • Commissioning History；
  • 一线客服能看懂的Error Code。

如果供应商唯一的排错方案永远是“恢复出厂再试”，售后成本只是被推迟了。

11. 谁拥有网络凭据和Commissioning Authority？

租房、新建住宅、物业、安装商代装项目里，这一点特别容易出问题。

问：

  • Installer是Owner还是住户是Owner？
  • 交房时Ownership能不能干净转移？
  • 员工离职后能不能撤销访问而不用全屋重置？
  • 谁能增加新的管理员？
  • 租客更换怎么处理？
  • Commissioning Code如何保存？
  • 原安装商以后还能不能访问？

技术互通不等于运营所有权清楚。

12. 真正的容量上限是多少？

不要理论值，要实测：

  • 每个Hub/Controller设备数；
  • Thread设备规模；
  • 同时运行Automation数量；
  • Scene/Routine数量；
  • User数量；
  • 多家庭/多Site数量；
  • 历史数据保留；
  • API Rate Limit；
  • Bridge Child Device上限。

然后继续问：在25%、50%、80%和接近上限时，延迟和稳定性分别怎么样？

“支持500设备”这句话，如果180个开始明显卡，就不完整。

13. 哪些数据会离开家？

让供应商画Data Flow。

至少拆：

  • Device ID；
  • Telemetry；
  • 音视频；
  • Occupancy；
  • 能耗；
  • Location；
  • 账号信息；
  • Diagnostics；
  • 保留时间；
  • 处理地区；
  • 第三方Processor。

这不仅是隐私问题。Cloud Dependency还会影响延迟、断网行为、成本和产品寿命。

具体法律责任取决于地区和场景，应结合真实市场审查供应商的Privacy Statement，而不是只看营销介绍。

14. API / Integration Contract到底保证什么？

“我们有API”远远不够。

要问：

  • Local还是Cloud API；
  • 有没有正式文档；
  • Authentication方式；
  • Rate Limit；
  • Versioning；
  • Deprecated提前多久通知；
  • Webhook可靠性；
  • Sandbox；
  • 商业条款；
  • Support SLA；
  • 数据能不能导出或缓存。

对于集成商来说，API突然变化的成本可能比一台硬件坏掉还高。

15. 最后别讲PPT，做一次Recovery Drill

评估结束前，要求对方现场恢复三种故障：

  1. Internet Outage；
  2. Hub/Controller替换；
  3. Ownership Transfer或Factory Reset。

给每一种恢复计时，记录哪些数据和Automation丢失，哪些步骤必须联系厂家支持。

这个测试往往比一小时“生态架构介绍”更能暴露真实能力。

最后做一张0–2分评分表

每家供应商只评这十项：

  • Role是否清楚；
  • 版本是否清楚；
  • 断网行为；
  • 多生态行为；
  • 诊断能力；
  • 更新政策；
  • 认证证据；
  • 数据控制权；
  • 容量证据；
  • 退出/恢复方案。

Logo更少、回答更清楚的供应商，可能反而比“兼容列表很长、Support Model很模糊”的厂商更适合长期做基础设施。

2026年最值得记住的一句话是：

协议支持是具体Implementation的属性，不是营销口号。

Matter、Thread、Wi-Fi、Bridge、Hub和Cloud完全可以配合得很好，但采购方必须知道每一层责任到底属于谁。

合同测试：把每一句架构承诺变成可观察的验收项

最危险的供应商回答不一定是“说错了”，而是买完以后根本无法验证。

对方说“本地控制”，就要求明确断开外网后哪些功能仍工作；说“支持Matter”，就问当前出货固件版本、支持设备类型，以及认证或互操作测试覆盖了哪些生态；说“支持多生态”，就让它现场把同一设备加入两个承诺支持的生态。

把模糊承诺改成验收测试：

供应商承诺 验收方式
本地可用 断开WAN，再运行双方约定的控制与自动化
支持Thread 明确Border Router，并检查网络如何建立
多生态可用 加入约定生态，再移除其中一个控制器
恢复简单 对测试设备恢复出厂，并按文档完成恢复
API长期可用 检查版本策略、废弃通知和认证机制
更新安全 写清签名、分发路径和停止支持流程

这些测试最好直接放进采购记录。一个项目如果重要到需要画架构图，就同样重要到值得写验收标准。

交付以后，故障到底归谁

智能家居项目通常至少有四方：设备厂商、中枢或生态提供方、安装方和家庭网络所有者。第五方云服务平时看不见，出故障时却可能突然变得非常重要。

签约前做一张升级责任表。如果Thread设备还能被发现，但某个自动化失败，谁先排查？如果一个生态显示设备离线，另一个生态仍能控制，谁负责诊断？如果换路由器后配网失效，谁恢复凭据或Fabric成员关系？

好合作方不需要承诺“永远不出问题”，但应该能说明如何隔离故障、客服需要什么证据，以及什么条件下责任会移交到另一层。

Matter很重要，但这一点尤其不能被“Matter兼容”四个字掩盖：互操作标准能减少一部分集成工作，却不会消灭设备固件、生态实现、网络条件或供应商售后责任之间的差异。

采购红旗

供应商反复出现下面情况时，建议暂停：

  • 把未来路线图说成今天已经出货的能力；
  • 把Matter、Thread和Wi‑Fi混成同一个概念；
  • 说不清自己的中枢到底承担哪个角色；
  • 不愿书面说明断网后什么会失效；
  • 永久安装设备却没有更新周期或停止支持政策；
  • 宣称“全兼容”，却不给出测试过的设备类别和生态；
  • 恢复故障只能依赖某个员工脑子里的经验，没有文档。

这些现象不能直接证明产品差，但说明买方正在承担一块没有被定价、也没有被写清楚的架构风险。

Sources

Related Reading