企业官网建设流程全解析

智能家居这个词，这几年被说得有点烂了。打开任何一个电商平台，搜"智能家居"，跳出来的全是"一句话开灯""手机远程控制空调"这类功能。说实话，这些东西用起来并不"智能"——你还是得开口、得掏手机、得主动操作。真正的智能应该是：你还没意识到自己需要什么，环境已经替你调好了。这就是"主动式"智能家居和"被动式"智能家居的根本区别。

我接触智能家居系统前后有六七年时间，从最早的继电器模块加红外传感器，到后来的Home Assistant自动化，再到最近一年多在折腾生成式AI与家居系统的结合，踩过的坑比走过的路还多。这篇文章想聊的，就是怎么把LLM、RAG这些生成式AI技术真正落到智能家居场景里，让系统从"你命令它执行"变成"它判断你需要什么并主动执行"。涉及的核心技术点包括：主动式自动化的判定逻辑、LLM在意图理解中的角色、RAG如何解决家庭场景的个性化知识检索、以及整套系统的工程落地细节。不管你是刚入门想了解智能家居控制系统的设计思路，还是已经在做LLM应用想找一个垂直场景落地，这篇内容应该都能给你一些可以直接抄作业的东西。

1. 为什么传统智能家居根本"主动"不起来

1.1 规则引擎的天花板在哪里

绝大多数人做智能家居自动化的方式，是在Home Assistant、米家或者Apple Home里配一条条规则："如果人体传感器检测到有人 且 时间在18:00-23:00之间 且 光照低于50lux，则打开客厅灯。"这种基于触发条件-动作（Trigger-Condition-Action）的规则引擎，本质上是一个巨大的if-else树。

问题在于，真实生活不是if-else能覆盖的。我举几个我自己遇到过的场景：

• 夏天晚上，我在客厅看电影，人体传感器每隔几分钟就检测到"无人"（因为我坐着不动），灯自动关了。我不得不加一个"媒体播放器正在播放时不关灯"的条件，但有时候我只是开着电视听个响，人已经去厨房了，灯又该关。
• 家里来客人，坐在沙发上聊天，传感器检测到有人但光照充足，灯不亮。但客人可能觉得暗，想开灯，又不好意思说。
• 冬天早上，闹钟响了，我起床去洗漱。按照规则，卫生间灯应该亮。但有时候我只是起来上个厕所就回去睡了，灯亮了反而刺眼。

这些场景的共同点是：规则无法穷举，条件之间存在冲突，而且人的意图是动态变化的。你每加一条规则，系统的复杂度就上升一个量级，最终维护成本高到你想全部删掉。

1.2 "主动"的本质是预测而非响应

我后来想明白一件事：主动式自动化的核心不是"更快地响应"，而是"提前预测"。响应是被动的——事件发生了，我处理。预测是主动的——我判断事件即将发生或需求即将出现，提前处理。

预测需要什么？需要理解上下文。同样是"人体传感器检测到有人"，在不同的时间、不同的历史行为模式、不同的环境参数下，含义完全不同。传统规则引擎只能看到"有人"这个布尔值，看不到背后的语义。

这就是生成式AI切入的地方。LLM擅长什么？擅长理解自然语言的上下文、做模糊推理、处理非结构化信息。RAG擅长什么？擅长从大量个性化数据中检索出与当前情境最相关的信息。这两者结合起来，就能让智能家居系统具备"理解情境并预测需求"的能力。

1.3 从"自动化"到"智能体"的思维转变

我现在的做法是，把整个家居系统看作一个多智能体（Multi-Agent）系统。每个房间、每个设备组、甚至每个家庭成员，都可以抽象成一个Agent。Agent之间通过消息传递协作，由一个中央协调Agent（基于LLM）来做全局决策。

这个思路的转变很关键：以前我是"写规则让设备执行"，现在我是"定义Agent的能力边界和协作协议，让它们自己协商出最优解"。LLM在这里扮演的是"协调者"和"翻译官"的角色——把模糊的人类意图翻译成具体的设备指令，把多个Agent的状态汇总成全局情境判断。

2. 生成式AI在智能家居里的三个真实落点

2.1 意图理解：从"开灯"到"我觉得有点暗"

传统语音助手最让人抓狂的地方是，你必须说它认识的那几个词。"开灯"可以，"把灯打开"可能也行，"我觉得有点暗"它就懵了。因为传统NLU（自然语言理解）是基于意图分类和槽位填充的，训练数据里没有"我觉得有点暗"对应"开灯"的样本，它就识别不了。

LLM天然解决了这个问题。你不需要训练数据，只需要在System Prompt里告诉它："用户表达'暗''看不清''光线不好'等含义时，意图是调整照明。"LLM就能理解各种变体。我实测下来，用GPT-4级别的模型做意图理解，准确率比传统NLU方案高出至少30个百分点，尤其是在处理口语化、省略、指代等复杂表达时。

但这里有个工程上的坑：LLM的响应延迟。你不可能让用户说完"我觉得有点暗"之后等3秒钟灯才亮。我的做法是双通道：本地跑一个轻量级的意图分类模型（比如微调过的BERT或蒸馏后的小模型）做快速响应，同时把请求发给LLM做深度理解。如果本地模型置信度高，直接执行；置信度低，等LLM的结果。这样既保证了响应速度，又保证了复杂场景下的理解准确率。

2.2 情境推理：让系统知道"现在是什么情况"

意图理解解决的是"用户说了什么"，情境推理解决的是"现在发生了什么"。这两个是互补的。

情境推理需要融合多源数据：传感器数据（温度、湿度、光照、人体存在）、设备状态（灯、空调、窗帘的开闭状态）、时间信息（几点、星期几、是否节假日）、历史行为（过去这个时间点用户通常在做什么）、外部信息（天气、空气质量）。

传统做法是给这些数据设阈值，超过阈值就触发。但阈值是死的，情境是活的。比如"温度28度"这个数据，在夏天开空调的情况下是正常的，在冬天没开暖气的情况下就是异常的。LLM可以结合上下文做推理："当前是12月，室内温度28度，但暖气设定是22度，且窗户传感器显示窗户开着——用户可能在通风，不需要干预。"

我现在的系统里，情境推理模块每5分钟跑一次，把当前所有传感器的状态汇总成一个自然语言描述，发给LLM做判断。LLM返回一个"情境标签"（比如"用户在客厅看电影""用户准备出门""用户已经入睡"），后续的自动化决策都基于这个标签来做。

2.3 主动建议：在用户开口之前就行动

这是生成式AI在智能家居里最有价值但也最难做好的部分。主动建议意味着系统要判断"用户接下来可能需要什么"，并提前执行或询问。

我举一个我实际跑通的例子：系统检测到以下信号——（1）工作日早上7:00；（2）卧室人体传感器检测到用户已起床；（3）卫生间人体传感器在2分钟内被触发；（4）天气预报显示今天下雨，气温比昨天低5度；（5）用户日历显示今天9:00有会议。

LLM综合这些信息后判断：用户正在洗漱，准备出门上班，今天天气不好需要带伞，而且有会议不能迟到。于是系统执行：卫生间灯调到暖光模式（避免刚起床刺眼），客厅窗帘打开30%（让用户知道天亮了但不用全开），玄关灯提前亮起，同时在音箱里播报："今天有雨，气温12度，比昨天低5度，建议穿外套带伞。您9点有会议，现在7:15，建议7:40前出门。"

这个场景里，没有任何一条规则是"如果A则B"能覆盖的。它是多个信号的综合推理结果，而且每个信号单独看都不足以触发行动。

3. RAG在家庭场景里的独特价值

3.1 为什么家庭场景需要RAG而不是纯LLM

你可能会问：LLM不是已经能理解情境了吗，为什么还需要RAG？

原因很简单：LLM不知道你家的具体情况。它不知道你家客厅有几盏灯、分别是什么型号、你老婆对色温的偏好是暖光还是冷光、你儿子每天晚上几点必须上床睡觉、你家猫的活动规律是什么。这些信息是高度个性化的，不可能通过预训练获得。

RAG（检索增强生成）的作用就是：在LLM做推理之前，先从你的家庭知识库里检索出相关的个性化信息，作为上下文一起发给LLM。这样LLM的推理就是基于你家的真实情况，而不是泛泛的通用知识。

3.2 家庭知识库该放什么、怎么组织

我家的知识库目前包含以下几类数据，我用一个表格来说明：

这里的关键设计决策是：不是所有数据都适合向量化。设备档案这种结构化数据，用传统数据库查询更快更准。行为模式这种时序数据，需要结合时间窗口做检索。只有成员偏好和场景规则这种半结构化、语义丰富的数据，才适合用向量检索。

我用的技术栈是PostgreSQL + pgvector。选它的理由很实际：我本来就用PostgreSQL存设备状态和历史数据，加一个pgvector扩展就能同时做结构化查询和向量检索，不需要额外维护一个向量数据库。对于家庭场景这种数据量不大（我家大概几万条记录）的情况，pgvector的性能完全够用。

3.3 检索策略：什么时候查、查什么、怎么用

RAG在智能家居里的检索策略和通用问答场景不太一样。通用问答是"用户提问→检索→生成回答"，家居场景是"情境触发→检索相关个性化信息→辅助LLM推理→生成设备指令"。

我的实现是这样的：

# 情境触发时的RAG检索流程（简化版） async def retrieve_context(situation_embedding, current_time, room): # 1. 检索与当前情境最相关的成员偏好 preferences = await vector_search( table="member_preferences", query_vector=situation_embedding, filter={"room": room}, top_k=3 ) # 2. 检索当前时间窗口内的行为模式 behavior_patterns = await time_series_search( table="behavior_logs", time_range=(current_time - timedelta(hours=2), current_time), room=room ) # 3. 检索硬性规则（必须遵守的） hard_rules = await keyword_search( table="scene_rules", keywords=[room, "必须", "禁止"], limit=5 ) # 4. 组装成LLM可理解的上下文 context = format_context(preferences, behavior_patterns, hard_rules) return context

这里有个经验：硬性规则必须用关键词检索而不是向量检索。因为硬性规则是"必须遵守"的，不能因为语义相似度不够就漏掉。比如"孩子房间22:00后必须关灯"这条规则，如果用户说"把孩子的灯调暗一点"，向量检索可能匹配不到这条规则，但关键词检索能匹配到"孩子"和"灯"。

4. 搭建主动式智能家居系统的完整工程路径

4.1 技术选型：为什么我最终选了这套组合

我试过不少方案，最终稳定下来的技术栈是这样的：

• 消息层：MQTT（设备通信）+ Redis Streams（内部事件总线）
• 数据层：PostgreSQL + pgvector（结构化+向量）+ InfluxDB（时序数据）
• AI层：FastAPI + LangChain + LangGraph（Agent编排）+ 本地部署的7B模型（快速意图分类）+ 云端API（复杂推理）
• 自动化层：Home Assistant（设备控制）+ 自研的Agent协调服务

选LangGraph而不是简单的LangChain Chain，是因为主动式场景需要有状态的循环推理。比如系统判断"用户可能想看电影"，需要先查一下当前灯光状态，再决定要不要调暗，调暗之后还要确认用户是否满意（通过后续行为判断）。这种多步骤、有状态、可能循环的推理流程，用LangGraph的图结构来表达最自然。

4.2 从传感器数据到主动决策的完整链路

我把整条链路拆成五个阶段，每个阶段都有明确的输入输出：

阶段一：数据采集与清洗。传感器数据通过MQTT上报，经过一个清洗层过滤掉抖动和异常值。比如人体传感器在2秒内连续上报"有人""无人""有人"，这显然是抖动，清洗层会合并成一次"有人"事件。

阶段二：情境构建。每5分钟（或关键事件触发时），把当前所有传感器状态、设备状态、时间信息汇总成一个结构化的情境描述。这个描述是自然语言的，方便LLM理解。

阶段三：RAG检索。用情境描述的embedding去检索相关的成员偏好、行为模式、硬性规则。

阶段四：LLM推理。把情境描述+RAG检索结果+系统Prompt一起发给LLM，让LLM输出一个决策。决策格式是结构化的JSON，包含：是否执行动作、执行什么动作、执行参数、置信度、是否需要询问用户。

阶段五：执行与反馈。根据LLM的决策执行设备控制，同时记录执行结果和用户反馈（用户是否手动覆盖了系统的决策），用于后续优化。

4.3 让LLM稳定输出JSON的实战技巧

这是我在整个项目里踩坑最多的地方。LLM返回的JSON不稳定，有时候多一个逗号，有时候少一个引号，有时候干脆返回一段自然语言解释而不是JSON。我试过以下几种方案：

方案一：Prompt Engineering。在System Prompt里反复强调"只返回JSON，不要任何其他文字"，并给出严格的JSON Schema。效果一般，大概80%的情况下能返回正确格式。

方案二：JSON Mode。OpenAI的API支持response_format={"type": "json_object"}，强制模型返回合法JSON。效果好很多，但模型仍然可能返回不符合你Schema的JSON（比如字段名拼错、类型不对）。

方案三：Function Calling。把决策定义为一个Function，让LLM通过Function Calling来输出。这是目前最稳定的方案，我实测下来格式正确率接近100%。缺点是灵活性稍差，复杂的嵌套决策需要定义多个Function。

方案四：输出后修复。不管用哪种方案，我都会在代码里加一层JSON修复逻辑。用Python的json.loads尝试解析，失败则用正则提取JSON部分，再失败则调用一个轻量级模型做格式修复。这个兜底逻辑救了我无数次。

import json import re def parse_llm_decision(raw_output: str) -> dict: """解析LLM输出的决策JSON，带多级兜底""" # 第一级：直接解析 try: return json.loads(raw_output) except json.JSONDecodeError: pass # 第二级：提取JSON块 json_match = re.search(r'\{.*\}', raw_output, re.DOTALL) if json_match: try: return json.loads(json_match.group()) except json.JSONDecodeError: pass # 第三级：修复常见问题后重试 cleaned = raw_output.strip() cleaned = re.sub(r',\s*}', '}', cleaned) # 去掉尾逗号 cleaned = re.sub(r',\s*]', ']', cleaned) cleaned = cleaned.replace("'", '"') # 单引号转双引号 try: return json.loads(cleaned) except json.JSONDecodeError: pass # 第四级：返回安全默认值 return {"action": "none", "reason": "parse_failed", "confidence": 0.0}

提示：第四级兜底非常重要。当所有解析都失败时，系统必须有一个安全的默认行为——什么都不做，而不是执行一个可能错误的指令。在智能家居场景里，错误执行（比如半夜把灯全打开）比不执行糟糕得多。

5. 那些只有真正跑起来才会遇到的问题

5.1 延迟：用户等不了3秒钟

这是主动式智能家居最大的工程挑战。用户说了一句话，期望在500毫秒内得到响应。但LLM的推理时间通常在1-3秒，如果加上RAG检索，可能到5秒。

我的解决方案是分级响应：

• Level 0（<100ms）：本地规则引擎处理明确的、高频的指令。比如"开灯"这种，直接走本地NLU+规则，不经过LLM。
• Level 1（<500ms）：本地小模型处理意图明确的指令。比如"我觉得有点暗"，本地微调过的模型能识别为"调亮灯光"。
• Level 2（1-3s）：LLM处理复杂情境推理。比如"我要看电影"，需要综合判断灯光、窗帘、音响、空调的状态。
• Level 3（后台异步）：主动建议和长期学习。不要求实时响应，可以在后台慢慢跑。

关键设计是：Level 2和Level 3的决策结果会缓存起来。如果同样的情境再次出现，直接走缓存，响应时间降到毫秒级。缓存的有效期根据情境的稳定性来定，比如"工作日早上7点"这个情境的缓存可以管24小时，"有人移动"这个情境的缓存只能管30秒。

5.2 误报：系统太"主动"反而烦人

我刚开始跑主动建议的时候，系统特别积极。我走到客厅，它问我要不要开灯；我坐下，它问我要不要开电视；我去厨房，它问我要不要开抽油烟机。一天下来问了我几十次，我烦得直接把主动建议关了。

后来我总结了几条原则：

原则一：主动执行，被动询问。对于低风险、高确定性的动作（比如开灯、调温度），直接执行，不要问。对于高风险、低确定性的动作（比如锁门、关燃气），先询问再执行。

原则二：设置"静默期"。同一个主动建议，如果用户连续拒绝两次，接下来24小时内不再提。如果用户接受了，可以适当增加频率。

原则三：置信度阈值动态调整。刚开始跑的时候，置信度阈值设高一点（比如0.85），只在高置信度时才主动。随着系统学习用户行为，逐步降低阈值，增加主动性。

原则四：给用户一个"闭嘴"按钮。我在每个房间都放了一个物理按钮，按一下就是"接下来1小时不要主动建议"。有时候用户就是想要安静，不想被系统打扰。

5.3 隐私：数据放本地还是放云端

这是每个做智能家居+AI的人都会纠结的问题。传感器数据、行为记录、语音指令，这些数据如果全部上传云端，隐私风险很大。但如果全部本地处理，算力又不够。

我的方案是分层处理：

• 敏感数据本地处理：语音唤醒、语音转文字、人体存在检测，这些全部在本地完成。我用的是一个本地部署的Whisper模型做语音转文字，识别结果只保留文本，原始音频立即删除。
• 脱敏数据上传云端：需要LLM做复杂推理时，只上传脱敏后的情境描述（比如"客厅有人，光照低，时间晚上8点"），不上传原始传感器数据和个人身份信息。
• 个性化数据本地存储：成员偏好、行为模式这些数据存在本地PostgreSQL里，RAG检索也在本地完成。只有检索结果（已经脱敏的上下文）才会和情境描述一起发给LLM。

这样做的代价是本地需要一台性能还行的服务器。我用的是一个Intel NUC，16GB内存，跑一个7B的量化模型做本地意图分类，同时跑PostgreSQL和Home Assistant，负载大概在60%左右，完全够用。

5.4 模型更新：LLM升级后行为变了怎么办

这个问题很隐蔽但很致命。你花了一个月调好的Prompt和决策逻辑，某天LLM提供商升级了模型版本，行为突然变了。原来能正确输出的JSON现在格式不对了，原来能理解的指令现在理解错了。

我的应对策略是：

策略一：锁定模型版本。如果用的是云端API，尽量选择有版本号的模型（比如gpt-4-0613而不是gpt-4），避免自动升级到最新版。

策略二：建立回归测试集。我收集了200个典型情境+期望决策的测试用例，每次模型更新或Prompt修改后，跑一遍回归测试，确保核心场景的行为不变。

策略三：A/B测试。新模型先跑影子模式（Shadow Mode），也就是新模型和旧模型同时推理，但只有旧模型的决策被执行。对比两者的决策差异，确认新模型没有退化后再切换。

6. 从单点智能到全屋智能体的演进路线

6.1 第一阶段：单房间的主动照明

如果你刚开始做，我建议从最简单的场景入手：单房间的主动照明。选一个你待得最久的房间（通常是客厅或卧室），部署人体传感器、光照传感器、智能灯，然后跑一个简单的主动照明逻辑。

这个阶段的目的是跑通整条链路：传感器→情境构建→LLM推理→设备控制。不要追求完美，先让系统跑起来。我第一个版本只用了三天就搭好了，虽然经常误判，但至少验证了技术可行性。

6.2 第二阶段：多房间的情境联动

单房间跑通后，扩展到多房间。这个阶段的核心挑战是情境的跨房间传递。比如用户在客厅看电影，然后起身去厨房，系统需要判断：用户是去拿饮料（厨房灯调亮，客厅灯保持），还是去睡觉（厨房灯调暗，客厅灯关闭）。

我的做法是在Agent之间加一个"意图广播"机制。客厅Agent检测到用户离开，广播一个"用户离开客厅"事件，附带当前情境（正在看电影）。厨房Agent收到事件后，结合自己的传感器数据（用户进入厨房）和广播的情境，判断用户意图。

6.3 第三阶段：全屋智能体的自主协商

最终形态是全屋Agent自主协商。每个房间的Agent有自己的目标（比如"保持舒适""节约能源"），Agent之间通过协商达成全局最优。

这个阶段我还在探索中。目前的做法是用LangGraph定义一个协商协议：当多个Agent的目标冲突时（比如客厅想开空调降温，卧室想关空调省电），由一个协调Agent（也是LLM驱动的）来做仲裁。仲裁的依据是全局优先级：用户舒适度>能源节约>设备寿命。

说实话，这个阶段的技术挑战还很大。LLM做多Agent协商时，有时候会陷入"无限循环"——两个Agent互相说服不了对方，一直来回发消息。我目前的解决方案是设置最大协商轮数（比如3轮），超过就由协调Agent强制裁决。

7. 我踩过的几个印象深刻的坑

7.1 传感器抖动导致的"幽灵触发"

人体传感器（尤其是红外PIR类型的）有个通病：当环境温度接近人体温度时，检测精度会大幅下降。夏天的时候，我家客厅的PIR传感器经常在没人时误报"有人"，导致灯莫名其妙地亮。

我一开始以为是传感器坏了，换了好几个都一样。后来查资料才知道这是PIR的物理特性决定的。解决方案是多传感器融合：PIR + 毫米波雷达 + 摄像头（本地处理，只输出"有人/无人"）。三个传感器投票，两个以上说有人才判定为有人。这样误报率从每天十几次降到了几乎为零。

7.2 LLM的"过度推理"

LLM有个毛病：你给它一个简单的情境，它非要推理出一堆有的没的。比如情境是"客厅有人，晚上8点，灯关着"，LLM可能推理出："用户可能刚回家，需要开灯；也可能用户准备出门，不需要开灯；还可能用户在找东西，需要开灯但亮度要高……"然后给你返回一个模棱两可的决策。

我的解决方案是在Prompt里加约束："如果情境信息不足以做出高置信度决策，返回action=none，不要猜测。"同时给LLM提供更多的上下文信息（比如"用户5分钟前从玄关进入"），减少不确定性。

7.3 RAG检索到的信息互相矛盾

家庭知识库里经常有矛盾的信息。比如成员偏好里写着"用户喜欢暖光"，但行为模式显示用户最近一周都在用冷光。RAG检索会把两条都返回给LLM，LLM就懵了。

我的处理方式是给检索结果加时间权重和置信度权重。近期的行为模式权重高于早期的偏好设置，用户手动设置的偏好权重高于系统学习的行为模式。在组装上下文时，明确标注每条信息的来源、时间和置信度，让LLM自己判断该采信哪条。

7.4 设备离线时的决策降级

智能家居系统不可能100%在线。网络断了、设备没电了、MQTT broker挂了，这些都会发生。当系统检测到某个设备离线时，LLM的决策需要降级。

我的做法是维护一个"设备可用性"状态表，在发给LLM的情境描述里明确标注哪些设备可用、哪些不可用。同时准备一套降级规则：如果LLM不可用（比如云端API超时），自动切换到本地规则引擎；如果某个设备不可用，LLM会尝试用其他设备达到类似效果（比如用智能插座控制台灯代替直接控制吸顶灯）。

8. 给想入坑的朋友几条实在建议

如果你看到这里，说明你对生成式AI+智能家居这个方向是真感兴趣。我最后分享几条个人经验，都是踩过坑之后总结出来的。

第一条：先做减法，再做加法。不要一上来就想做全屋智能体。先选一个房间、一个场景、一个设备，把整条链路跑通。我见过太多人买了一堆设备，结果连最基本的自动化都没配好，最后全部吃灰。

第二条：数据比模型重要。你用什么LLM其实没那么关键，7B的本地模型和GPT-4在意图理解上的差距，远没有你家的个性化数据质量带来的差距大。花时间整理你家的设备档案、成员偏好、行为记录，这些数据才是让系统"懂你"的关键。

第三条：留好手动兜底。不管系统多智能，一定要保留物理开关和手动控制。我家的所有智能灯都保留了物理开关，所有智能插座都有手动按钮。系统出问题的时候，你至少还能正常生活。

第四条：接受不完美。主动式智能家居不可能100%准确。我现在系统的准确率大概在85%左右，也就是说每20次主动决策里有3次是错的。这个准确率已经让我觉得"利大于弊"了，但如果你追求100%准确，那还是回去用规则引擎吧。

第五条：关注成本。如果你用云端LLM API，每次推理都是钱。我算过一笔账：如果每5分钟推理一次，一天288次，一个月8640次，按GPT-4的价格，一个月大概几十美元。如果加上RAG检索和语音转文字，成本更高。我的做法是本地模型处理80%的请求，只有20%的复杂推理走云端，这样成本降到了每月几美元。

这个方向还在快速演进。我最近在试的是用Agentic RAG的思路，让系统不仅能检索信息，还能主动去"问"设备要数据、去"查"外部API获取信息。比如系统判断"用户可能要出门"，会主动去查一下天气API、交通API，然后综合判断要不要提醒用户带伞。这种主动获取信息的能力，比被动等待检索又进了一步。等我这部分跑稳定了，再找机会跟大家分享。