企业官网建设流程全解析

过去几年我帮不少朋友和客户搭过智能家居，听得最多的需求是“我喊一声，灯就亮”；今年开始，同样一批人跑来问我的问题变成了“我还没开口，它能不能就先知道我要干嘛”。从“你喊我动”到“懂你所需”，这中间的差距，其实才是AI驱动智能家居真正的战场。语音控制、App开关、定时场景这些只是旧世界的地基，AI要做的是在这片地基上长出会观察、会判断、会自己编排行动的大脑。这篇内容我就是想踏踏实实地把这条路拆开讲透——从架构怎么搭、数据怎么采、模型怎么选、决策怎么做，到实际落地时那些文档里不会告诉你的坑，全部过一遍。

1. 从“你喊我动”到“懂你所需”：AI重新定义智能家居的核心价值

1.1 旧智能家居的问题不在设备，在“大脑”

传统智能家居的体验瓶颈我一直认为是逻辑层太死。你设了一个“晚上18点回家开灯”的定时，它就老老实实18点开灯；哪怕你出差在外、家里没人，它也照开不误。你设了“湿度低于40%打开加湿器”，它就固定在那个阈值触发，完全不管你是刚洗完澡湿度还没散，还是窗户开着外面在下雨。设备没坏，传感器也准，坏的是决策方式——所有规则都是人预先写死的，系统没有观察上下文的能力，更没有根据上下文微调动作的弹性。

AI驱动智能家居的第一层变化就在这里：把“固定的if-else规则”替换成“基于实时状态和长期习惯的动态决策”。不是说规则引擎要完全退役，而是在规则之上叠加一层理解能力。比如系统知道你今天比平时晚下班一小时，知道客厅湿度偏高是因为阳台刚晾了衣服，知道你这周连续三天加班、明早大概率想多睡半小时——这些信息单看任何一个传感器都拿不到，但把它们喂给一个能综合推理的模型，它就能做出比“定时+阈值”聪明得多的执行决策。

1.2 AI到底给智能家居加了哪三样东西

我做了几个项目之后的体会是，AI对智能家居的增量可以归纳成三件事。

第一是感知增强。普通智能家居也有传感器，但大多是单点数据：一个红外人体存在、一个温湿度计、一个门窗磁。AI把多个单点数据融合成一个“场景视图”。比如用摄像头做人体姿态识别，结合毫米波雷达的微动探测，再叠加语音指令的意图，系统才能确认“人在沙发上躺着，眼睛在看电视方向，没有睡觉”，而不是简单报告“客厅有人”。

第二是决策推理。过去的联动规则是“条件A触发动作B”，AI驱动后变成“连续状态序列，推断出意图C，再生成一组最优动作D”。而且D往往不是一个动作，是一连串互相有先后依赖的动作包：进门脱鞋的瞬间，玄关灯先亮，鞋柜除臭机启动，客厅窗帘拉开但主灯不亮，背景音乐调到低音量——这些动作之间还有逻辑关系，不能简单地同时执行。

第三是自适应学习。设备多、传感器多之后，每个人的生活习惯都不一样。AI系统能根据历史上的交互和被打断次数，持续修正自己的模型。比如它发现你每次夜里起来都会手动关掉卫生间走廊的灯，那下次它就默认不把那条走廊灯开满；发现你周末早上从不听新闻播报，周末的“早安场景”里就把语音播报这一项去掉。

这三件事加在一起，才是标题里那个“AI+”的完整含义。不是给音箱塞个大模型就叫AI智能家居，而是从感知、决策到执行的全链路都开始具备学习和推理能力。

2. 整体架构怎么搭：云端大脑、边缘网关与端侧设备的三角分工

2.1 为什么不能把AI全塞进云端

很多人一开始的设想特别简单：把所有传感器数据传到云端，让大模型处理完再把指令下发回来。这个方案听上去优雅，实际跑起来全是问题。

第一是延迟。家里的人体存在传感器每500毫秒上报一次状态，如果每次都走“设备→网关→云→模型推理→云→网关→设备”这条链路，一个动作从发生到执行轻松超过800毫秒到1.5秒。开个灯等一秒多，体验立刻回到原始社会。第二是可靠性。家庭网络一抖动、宽带一断，云端大脑直接失联，连基础的安防联动都瘫了，这是任何用户都没法接受的。第三是隐私。全屋的睡眠数据、在家作息、活动轨迹全部上传到云端，本身就是一个巨大的法律和信任风险。

所以真正可落地的架构一定是分层的：云端做全局学习和跨家庭的知识沉淀，边缘网关做本地的实时决策与场景编排，端侧设备做最基础的信号采集和简单判断。三者之间不是替代关系，而是按“时效性、隐私性、复杂度”三个维度分工。

2.2 边缘网关：AI驱动场景的中枢神经

边缘网关是整个架构里我最看重的部分。它不一定要有什么强悍的GPU，但必须满足三个条件：本地推理能力、多协议接入能力、规则与AI模型双引擎运行能力。

拿我做过的一套方案举例，网关用的是一块带2.0 TOPS NPU的嵌入式主板，跑了一个轻量级的人体存在分类模型和一个本地语音命令词识别模型。所有传感器数据先在网关内完成第一层融合，再决定是直接执行联动还是上报云端做进一步分析。实测下来，本地链路从“传感器变位到灯光动作”的端到端延迟控制在150毫秒以内，体感上就是“刚走到门口，灯就亮了”。

这个角色之所以关键，还因为它天然负责协议转换。家里Zigbee的开关、蓝牙Mesh的灯、Wi-Fi的空调、Matter的门锁，全部汇到网关这一层。AI往上要能读统一语义的数据格式，往下要能下发不同协议的控制指令。没有这层抽象，前面的模型根本没法设计——你总不能让AI为一个蓝牙灯泡单独写一套控制函数。

2.3 云端大脑：离线学不来的“慢思考”放在这里

边缘网关负责的是快思考，云端大脑则负责慢思考。什么样的任务需要云端参与？我总结了三类。

一是跨天周期的习惯学习。只凭当天晚上的数据，系统判断不了“用户是否处于出差状态”，需要在云端长期记录作息和行程卡片，通过离线任务做习惯聚类和偏好建模。二是自然语言理解和复杂意图推理。今天的大语言模型动辄百亿千亿参数，边缘端跑不动，只能把语音转写后的文本送到云端理解。三是多家庭的共性经验。比如“睡眠状态应该联动什么场景”，云端能从大量脱敏数据里学到交叉特征，再给各家的边缘网关下发更新后的模型参数。

这里要特别注意：云端不可用时，整套系统必须降级到“本地规则+本地模型”模式继续运行。我在架构设计里都会加一条硬性原则——所有核心安全场景（燃气、漏水、门锁）绝对不允许依赖云端，边缘网关必须有独立执行和告警能力。

3. 感知层才是地基：多模态数据采集与融合的工程实践

3.1 单一传感器永远不够用

AI驱动智能家居最容易翻车的地方，恰恰是最不起眼的感知层。很多人想当然地认为“我家装了人体传感器，人来了它当然知道”。但普通PIR红外传感器的“有人”判断极其粗糙——它只能感知大动作，你坐在沙发上看书超过五分钟，它对你就完全“失明”了。这也是为什么很多人家里的“人来灯亮”用了一个星期就关掉：灯光频繁熄灭的挫败感比手动开关还要强。

要支撑AI决策，感知层必须“多模态”和“多层次”融合。目前我比较常用的组合是：

• 毫米波雷达：感知微动、呼吸、姿态，不受光线影响，适合卧室、卫生间这种需要长时间静置判断的场景；
• 人体存在传感器（多普勒+红外双鉴）：弥补纯PIR的误判问题，区分人和宠物；
• 摄像头视觉：做人脸识别、姿态分析、跌倒检测，精度最高但隐私负担最重；
• 环境传感器：温湿度、光照、CO2、PM2.5、噪音，提供场景的“背景上下文”；
• 语音信号：通过麦克风阵列做声源定位、命令词识别和情绪大概感知；
• 设备自身状态：门锁状态、窗帘开合百分比、空调当前模式，作为执行结果的反馈回读。

把这些数据放平了看，每个都很普通。但放到同一个时间轴里对齐之后，AI能回答的问题就完全不一样了。“雷达说卧室有人，摄像头识别出是成年人躺在床上，门磁显示门已关闭，温湿度正常，灯光状态是关闭”——这六个数据合在一起，AI可以高置信度地推断“用户已就寝，进入睡眠场景”，而不是简单触发一个“夜间有人移动报警”。

3.2 数据对齐、补全与质量治理

多模态感知在工程上最麻烦的不是传感器不够多，而是数据怎么对齐。毫米波雷达上报频率是1秒一次，摄像头产生事件是每200毫秒一帧，温湿度传感器是5分钟一个包。AI要做的场景判断往往需要在时间轴上把不同频率的数据裁剪到一个统一窗口。我在实际项目里用的是一个简单的策略：以“事件ET”为基准，把前后2秒内其他传感器的状态快照一并打包，形成一个场景事件记录。这套记录结构既喂给实时规则引擎，也异步同步给云端做训练。

另一个问题是数据缺失和脏数据。传感器离线、被遮挡、低电量导致的异常读数，这些都会让AI模型输出匪夷所思的决策。我踩过的坑是：卫生间湿度传感器被水蒸气糊住，连续上报99%湿度，导致除湿机全天开了一个星期。后来加了一层简单的数据质量网关，超过物理上限的值直接丢弃，并要求至少两个独立数据源确认后才允许触发持续性设备动作。这条经验后来被我写进每一个项目的数据链路里，算是花了真金白银买来的教训。

4. 决策层是灵魂：从规则引擎到单模型再到Multi-Agent的演进

4.1 规则引擎没有死，它变成了AI的“手和脚”

AI驱动不等于推翻规则引擎。正好相反，规则引擎在架构里变成了AI决策之后的执行翻译器。你让大模型决定“客厅进入观影模式”，它最终还是要翻译成一系列具体动作：灯光亮度调到20%，色温2700K；电视切入HDMI2；窗帘关闭；音响音量设为30。这些动作的粒度控制、依赖关系和安全边界，仍然用规则引擎来承载最可靠。

所以我把决策链路设计成“三段式”：意图理解（AI模型）→ 场景选择（规则+模型混合） → 命令翻译（规则引擎）。AI负责的是模糊判断，规则负责的是准确执行。二者不是替代关系，而是前后道工序的关系。

4.2 把大模型放进决策链路：Prompt编排与工具调用

真正把大模型引入智能家居决策，是我在过去一年尝试最多的方向。一个比较稳的做法是函数调用（Function Calling）模式：大模型不直接控制设备，而是输出一个结构化的决策意图，再由本地的执行框架去调用设备控制函数。比如用户对音箱说“我有点冷”，语音转写文本进到大模型后，模型结合当前室温22度、湿度60%、用户穿着习惯，输出“执行升温动作：空调制热26度，同时打开电暖器低档”，然后这个意图被拆成两条命令分别发给两个设备。

这里有个关键设计：大模型必须知道自己能调用哪些工具，不能凭空想象不存在的设备。所以我的Prompt里会给它一份“家庭工具清单”，每个工具包含名称、参数、约束条件和当前状态。这样做还有一个额外的好处——模型的输出可以被校验，如果它提出调用一个不存在的设备，执行层可以直接拦截，避免幻觉带来的误操作。

4.3 Multi-Agent协作：让不同角色各管一摊

智能家居场景涉及的子任务太多，一个模型同时处理环境控制、安防、娱乐、能耗优化，效果往往很散。我最近在尝试的是Multi-Agent架构：给不同Agent明确分工，再通过一个调度Agent做协同。

比如环境管家Agent负责温湿度、空气质量和节能策略；安防Agent负责门锁、摄像头和异常行为识别；生活助理Agent负责日程、语音交互和信息播报。每个Agent都有自己的模型、记忆和工具权限。调度Agent收到用户请求或传感器事件后，先判断这个任务归属哪些领域，再决定是单Agent处理还是多Agent协作。

举一个我实际跑通的例子：用户说“我要睡觉了”。调度Agent把任务同时发给环境管家和安防Agent。环境管家决定调整卧室空调、关掉公共区灯光、启动助眠香薰；安防Agent检查门锁状态、启动夜间安防布防、调整摄像头联动策略。两个Agent并行决策，最终由调度Agent合并出一份不冲突的执行计划。整个过程比单个大模型硬处理逻辑清晰很多，出错的概率也小。

4.4 模型参数怎么定：轻量、量化、蒸馏三步走

决策层模型的选择方向，我遵循一个简单的原则：能用本地轻量模型解决的绝不上大模型，必须上大模型的先做蒸馏和量化。边缘网关上的环境决策模型，我用的是MobileNetV3做视觉特征提取、BERT-Tiny做本地语义理解，参数量从千万压到百万级别，量化到INT8后跑在NPU上单次推理只要几十毫秒。云端用的才是7B级别的大模型，负责复杂对话和跨场景推理。

这里要提醒一句：别被大模型参数数量绑架。智能家居的决策大部分是“小任务”，拿千亿参数模型做开灯关灯纯属浪费。先把任务分类，再把任务分给合适大小的模型，才是工程正道。

5. 执行层不能只看“动没动”：闭环控制、场景编排与异常兜底

5.1 执行结果必须回读，否则AI就是瞎指挥

传统智能家居的执行层是“命令发出去了就完事”，AI驱动后这远远不够。设备有没有真正执行成功？灯是调到了20%亮度还是没反应？空调是进入了制冷模式还是运行出错？这些执行结果如果不能回读，AI的下一轮决策就是在错误的现状上做推理，越推越偏。

所以我在执行链路中加了一层“状态回读”机制。网关下发控制命令后，会主动查询设备返回的当前状态，和预期值做比对。偏差超过阈值就触发一次重试，重试两次仍失败的，就把这条失败记录作为异常事件喂给上层AI，让决策层换一个执行策略。比如卧室灯控失败，AI可以判断是不是灯泡离线，转而命令智能开关切断该回路电源再上电尝试复位。

5.2 场景编排：一次决策触发一串动作的编排技巧

AI决策输出的经常不是单个动作，而是场景包。场景编排的难点在动作之间的时序和依赖。我的做法是把场景包拆成三个层次：立即执行动作、延迟执行动作、条件执行动作。每个动作除了命令本身，还带一个“前置条件”和一个“超时时间”。

用“回家模式”举例：门锁验证通过这个事件触发场景时，玄关灯是立即执行；窗帘电机启动要等1秒，因为需要等灯亮起来给人视线缓冲；空调暖风是延迟3秒启动，避免和窗帘电机同时拉高配电负荷；如果门口温湿度传感器显示室外下雨，那么阳台晾衣杆的收回动作才执行，否则跳过。这些条件判断放在边缘网关本地做，整个编排过程不依赖云端，稳定性和实时性都最好。

5.3 异常兜底：AI也会错，必须有“断后”机制

AI决策再聪明，也会有误判和故障时刻。设备离线、模型推理结果异常、多个Agent决策互相冲突，这些在长时间运行中几乎一定会遇到。我在落地时坚持三条兜底原则。

第一，安全类动作永远人工优先。燃气阀、门锁这两类设备的AI自动控制权限默认关闭，必须用户显式开启，且每一次自动动作都留存完整日志。第二，冲突仲裁有固定优先级。设备安全 > 用户主动指令 > 场景自动执行 > 节能优化。一旦两个Agent同时争夺一个设备，低优先级的一律让路。第三，全局熔断。如果边缘网关在1秒内出现超过3个设备控制失败，说明执行通道可能出了问题，系统自动停止所有场景自动触发，降级为仅告警模式，避免一连串错误动作把全屋搞乱。

6. 隐私与安全这道坎：本地推理、联邦学习与权限边界

6.1 摄像头和麦克风数据处理的底线

AI驱动智能家居绕不开隐私问题，尤其是摄像头和麦克风数据。我的一个铁律是：敏感原始数据不出本地，只上传脱敏后的特征向量和事件标签。比如摄像头做人体姿态分析时，在端侧直接把姿态关键点坐标提取出来，上传到云端的是“在家、站立、客厅、置信度0.95”这样的抽象标签，而不是图像本身。人脸识别更严格，特征向量只存储在用户的本地密钥环境中，云端只拿哈希后的ID做跨设备去重。

这套方案在合规性和用户体验上都站得住，但工程上要注意特征向量的逆向风险。关键点坐标虽然不直观，理论上也能被反向攻击。所以我还会对特征做添加随机噪声和时效性过期处理，保证同一人的特征向量不会长期固定不变。

6.2 联邦学习：各家数据不出门的模型进化方案

要让AI越用越懂用户，需要持续用新数据微调模型。如果把每个人的作息数据集中到云端训练，隐私风险太大。这两年我验证过一条可行的路线是联邦学习：云端只下发初始模型，家庭网关用本地数据做增量训练，然后把模型梯度（而不是原始数据）加密回传，云端聚合后再下发更新版本。这样模型学到了通用的偏好规律，但训练过程没有碰过任何一家的原始数据。

这套方案落地时有两个现实问题：一是家庭网关的计算资源有限，全参数微调跑不动，实践中用的是LoRA这类轻量微调方案，只在原模型上加了一层极小规模的适配模块；二是梯度反推在理论上也存在泄露风险，所以加密传输之外，梯度还会加噪声，隐私安全和经济效率做一个平衡取舍。

6.3 权限边界：AI能动的设备必须有白名单

无论模型多聪明，我都坚持给AI控制加一张白名单。哪些设备允许AI自动执行，哪些设备只允许用户手动控制，这个边界在系统初始化时定死，并能被用户随时修改。白名单之外，AI即使推理出“应该开窗”，也只能生成建议推送到用户手机，不能直接驱动开窗器。安防摄像头、门锁、燃气阀门三类设备默认禁止AI自动控制，除非用户专门打开高级权限，并且每一次执行都要经过二次确认。

这个设计不是为了限制AI，而是为了建立用户对系统的信任。AI智能家居的体验好，前提是用户敢把控制权交出去；敢交出去的前提，就是系统有清晰、可预期的安全边界。

7. 一个真实落地案例复盘：从需求梳理到全屋AI化的完整过程

7.1 客户需求其实不是“全屋智能”，是“省心和安全感”

我带过的一个项目可以拿来做完整复盘。客户是一套四室两厅，一开始他的需求写的是“每间房都要能语音控制灯光窗帘”。我跟他聊了两轮之后发现，他真实的痛点是：孩子刚出生，夜里要频繁起床看孩子，不想摸黑去找灯的开关；同时他和爱人工作忙，经常加班到深夜回家，希望家里能有一种“有人等你回来”的体验；另外母亲一个人在家时，他们担心摔倒或异常情况不能及时发现。

这三个真实诉求，语音控制只是最表面的实现方式。最终方案定下来后，整个项目已经不是“全屋智能装修”，而是“一个关注家庭安全与情绪体验的AI感知系统”。

7.2 方案设计与设备选型的关键决策

根据需求，我把全屋架构分成四个核心系统：感知系统、决策系统、执行系统、交互系统。

感知系统选了毫米波雷达为主的方案，主卧和儿童房各装一个带呼吸监测的雷达，客厅用双鉴传感器加一个视觉摄像头（摄像头只覆盖玄关公共区，卧室不装）。决策系统用本地边缘网关加云端大模型协同，边缘跑轻量姿态判断和环境决策，云端跑语音语义和长期习惯学习。执行系统沿用客户家原有的部分灯和窗帘电机，新增了一些支持状态回读的智能开关，把品牌生态统一到了一个本地网关下管理。交互系统保留了智能音箱，但把过去的“命令式交互”升级成“场景意图交互”。

这个方案选型的核心逻辑是：保护隐私优先（卧室不装摄像头）、实时性优先（本地决策为主）、兼容性优先（不更换客户已有的昂贵灯具）。

7.3 调试过程中暴露的三个真实问题

项目上线后两个星期的磨合期里，我记录了三个很有代表性的问题。

第一个是“误判断离”。客厅雷达把风扇摇头的微动识别成了人在活动，导致离家模式一直不能自动触发。解决方法是给雷达加了“目标形状特征”过滤，风扇这类周期性摆动的回波模式被单独打标排除。

第二个是“语音误唤醒”。客户家里电视声音比较大，智能音箱经常把电视剧台词误判成控制指令。后来我在麦克风阵列前端加了声纹比对，只响应登记过的几个家庭成员的声音，误唤醒率下降了一大截。

第三个是“多设备动作打架”。有一次回家场景里，AI同时命令餐厅灯和厨房灯开启，但客户其实只路过客厅去厨房倒杯水，餐厅灯被点亮后他还要手动关闭。这个问题的本质是场景触发粒度过粗。后面我把回家模式拆成了“归家探测模式”和“长驻客厅模式”，用进门后3分钟的停留位置分布来决定真正要打开的灯光组。

这三个问题都不是设备故障，而是AI对真实生活语境理解不到位。它们让我更坚信一件事：AI驱动智能家居的落地，核心不是算法多强，而是要对生活细节有足够的建模深度。

8. 从Demo到产品化：那些文档里不会写的坑与经验

8.1 模型在实验室跑得好，不代表在家里能跑稳

我见过太多团队拿着测试环境里99%准确率的模型做演示，一放到真实用户家里就崩溃的案例。家庭环境的多变性是训练集永远覆盖不完的：窗帘是半遮光的和全遮光的，室内有宠物走来走去，深夜的雷达回波里可能有风扇也有空调气流。所以在产品化阶段，我坚持一个原则：任何模型先做至少两周的A/B影子运行——只记录模型决策和用户实际操作，不真正控制设备。两周后对比模型决策和用户行为的偏差率，达标了才切换到自动模式。

这个做法听着保守，实际能帮大忙。因为AI系统真正的价值不在于单次判断准确，而在于长期运行中不犯让人反感的愚蠢错误。用户在经历两次“AI乱开灯”之后，大概率会永久关闭所有自动场景。

8.2 状态同步、消息丢失与设备离线是三大隐形杀手

智能家居产品的稳定性敌人，往往不是AI，而是底层通信。Zigbee网络偶尔会丢消息，Wi-Fi设备会因为路由器漫游掉线，设备重启之后状态和云端记录不一致。这些在网络环境单纯的测试房里很少露头，一到用户家庭复杂路由环境下就被无限放大。

我的经验是三层防护。应用层要有消息队列，命令下发失败要自动重入队列再试；网络层要用有状态的网关管理每个子设备的在线心跳，超过30秒失联立刻标记离线；产品层要给AI决策一个“设备可用性矩阵”，如果房间内超过三分之一的设备离线，自动跳过该区域的场景编排，避免对着一半瞎设备发号施令。

8.3 用户习惯的采集要从“被动”变“主动”

AI要学习用户习惯，前提是有高质量的行为数据。但如果只是被动等用户在App里点按钮，样本量太少，学习周期太长。我在产品设计里加了两个主动采集机制：一是交互式询问，比如系统发现用户手动调了空调温度，会轻轻问一句“以后这个时间段需要默认保持这个温度吗”；二是隐性试探，比如系统在某个时间点先主动打开一次窗帘，然后看用户是否在几分钟内拉上，用这个反馈做偏好标记。

这两个方式一个直接一个含蓄，配合起来能让模型在短时间内积累足够语义明确的训练样本。但要注意试探频率不能高，一天不超过两三次，否则用户会觉得系统在窥探自己，产生严重反感。

8.4 版本升级和模型迭代的灰度策略

AI智能家居一旦接入几十台设备，升级就是一场手术。我的做法是：先选一个“内部测试家庭”，然后扩大到三个“友好用户家庭”，再进入10%的设备群灰度，最后才全量。灰度期间对比的关键指标不只是错误率，还有用户的“干预频率”——用户手动修正AI动作的次数，才是衡量模型是否真正变聪明的金标准。这个指标不好看，模型再准都别急着放量。

9. 下一站：AI Agent、具身智能与全屋智能的结合点

9.1 从“全屋自动”到“家庭Agent”的转变趋势

现在的AI驱动智能家居，本质上还是“场景导向”：系统判断当前场景，然后执行对应场景包。下一步的趋势是“角色导向”：家里存在一个虚拟的家庭Agent，它不只是一个语音助手，而是能记住家庭成员偏好、安排家庭日程、协调全屋设备的长期智能体。这个Agent和用户之间是持续对话和合作的关系，不是“命令—反馈”的一次性问答。

我预判家庭Agent的关键能力有三项：长期记忆（记住三个月前用户在某个场景下的偏好）、主动建议（根据日程和状态提前给出建议而不是等指令）、跨设备规划（把一个模糊目标拆解成全屋协调计划）。这正好对应了大模型Agent领域最热门的记忆、规划和工具调用三项技术，只是应用场景从办公室会议转移到了家里的吃喝住行。

9.2 具身智能：智能家居的新载体是机器人

比家庭Agent更远一步的是具身智能。这两年机器人底盘技术成熟之后，我已经开始尝试把智能家居AI从“固定在天花板和墙上的传感器”延伸到“能移动的载体”上。扫地机器人不再只是扫地图，而是在清扫的同时做全屋环境巡检，补充固定传感器覆盖不到的死角数据。未来真正值得期待的是一个能抓取物品的家庭机器人：你说“把茶几上的水杯拿到厨房”，它调用视觉识别、抓取规划、路径导航和机械臂控制，把感知、决策、执行链路的闭环从“固定设备控制”升级成“物理世界操作”。

这段路还有很多工程难点，但方向已经明确。智能家居的下一个十年，拼的不只是谁家算法准，而是谁先把AI从云端请进客厅，再请进每一个房间，真正变成家庭的一部分。

9.3 我对AI+智能家居的判断和最后一条建议

做了这么多个项目，我最大的体会是：AI驱动智能家居不是用AI取代人的判断，而是用AI接管那些重复、琐碎、耗时的小决策，把人从“和开关、App、遥控器搏斗”的过程中解放出来。但在做产品设计时，永远要保留用户的人工优先权和控制权。一套好系统应该在用户想“放手”时足够可靠，在用户想“介入”时足够透明。

如果你正打算入局这个方向，我的建议是不要一上来就追大模型、追Agent，先花时间把感知和执行的闭环打磨扎实。AI再聪明，也需要稳定、低延迟、高可用的设备底座。先把“灯该亮的时候一定能亮，该灭的时候一定能灭”做到极致，再谈“AI懂你想要什么”的惊喜感。从我的实际项目经验来看，这个顺序从来没变过。