让家理解具体的人，让车成为家的延伸，让不同品牌与仍然好用的旧设备，在同一套身份、空间、场景和安全规则下协同工作。
初赛时，我用一个能够运行的 Demo 证明了：Tesla、米家、格力、海尔、石头扫地机、Apple Watch、自研 ESP32 和十几年前的旧家电，可以跨越品牌与协议，在同一个系统里工作。
复赛阶段，我想解决的已经不是“还能再接多少设备”，而是一个更接近真实产品的问题：
如果把 SmartHome AI 交给一个第一次使用它的人，他能不能从注册账号开始，独立完成建家、安装本地网关、扫码绑定、发现并认领设备、创建场景，最后看到真实设备执行并回传结果？
现在，这条从 0 到 1 的主体路径已经形成。SmartHome AI 也从一个证明想法成立的技术 Demo，推进为一套可安装、可从零开始使用，由 iPhone / Apple Watch、Cloud、LocalBridge、厂商插件、ESP32 硬件、HomeSpatial 空间引擎与本地 AI 共同组成的产品。
0. 关于我
大家好，我是 Ren，SmartHome AI 的开发者。
我一直觉得，真实家庭不会像智能家居样板间那样，只购买同一个品牌、同一个年代的设备。现实中更常见的是：新买的扫地机、用了很多年的空调、只支持遥控器的投影仪、不同家庭成员的手机和手表，以及一辆每天伴随用户出行的汽车，同时存在于一个家里。
SmartHome AI 就是我对这个问题的回答：品牌决定设备从哪里来，但不应该决定它们能不能一起工作。
从产品设计、iOS / watchOS、Cloud、LocalBridge、Python Worker、本地 AI、ESP32 固件，到真实设备联调、安装包和演示素材，项目均在 TRAE Work / TRAE IDE 协作下持续完成。
1. 一分钟看懂 SmartHome AI 2.0
| 项目 | 说明 |
|---|---|
| 产品形态 | iOS / Apple Watch App + Cloud + macOS / Windows LocalBridge + 可安装厂商插件 + ESP32-S3 学习型遥控硬件 + 本地 AI + Wi-Fi CSI 实验网络 |
| 核心用户 | 已装修家庭、多品牌设备用户、希望保留旧家电的用户、智能家居爱好者与二次开发者 |
| 核心问题 | 不同品牌各有 App，车辆与家庭割裂，旧设备无法加入自动化，系统只知道设备状态却不了解具体成员与空间 |
| 核心价值 | 统一人、车、家、空间与设备能力；用增量改造保留存量设备；让成员状态、睡眠、车辆和空间变化进入自动化 |
| 当前交付 | 已形成 iOS / Watch、Cloud、LocalBridge、插件 Worker、ESP32 与真实设备的端—边—云闭环 |
| 体验方式 | 社区公开展示产品说明与完整演示视频；安装包、测试账号、体验说明及其他作品本体通过复赛飞书问卷私密提交 |
| 初赛作品 | SmartHome AI：一个真正打通“人、车、家”的跨品牌智能生态 |
当前能力成熟度
| 状态 | 能力范围 | 说明 |
|---|---|---|
| 已形成主体闭环 | 账号与家庭、LocalBridge 绑定、插件安装、设备发现与认领、iPhone / Watch 控制、场景、ESP32 红外学习、HomeSpatial 建模 | 可在受控评审和真实家庭环境中完成完整演示 |
| 受外部生态影响 | Tesla、Roborock、Gree、Haier、Xiaomi 等厂商接入 | 真实体验受官方 API、账号区域、网络和设备在线状态影响，系统已提供降级、缓存、重试与错误分类 |
| 实验与验证中 | Wi-Fi CSI、BLE 遥控学习、连续灯光跟随 | 已具备实验入口或部分能力，但不作为稳定产品能力宣传 |
它不是“把很多遥控器放进一个 App”
传统智能家居通常以设备或品牌为中心；SmartHome AI 以家庭成员和真实生活过程为中心。
| 传统方案 | SmartHome AI 2.0 |
|---|---|
| 一个品牌一个 App | 多品牌设备进入统一家庭、房间和能力模型 |
| 人、车、家彼此割裂 | 成员、车辆、住宅共享身份、状态、场景与安全策略 |
| 旧家电只能继续使用遥控器 | ESP32 学习红外命令，保存为标准动作后进入 App、Watch、场景和自动化 |
| 自动化只看时间或单个传感器 | 可组合成员 Presence、房间、睡眠、设备、车辆、时间和空间状态 |
2. 产品演示视频
高清版：
Bilibili：https://b23.tv/P1a7GrU
3. 复赛版本最重要的变化：从 Demo 到完整用户路径
初赛版本重点证明底层能力能够打通；复赛版本则把这些能力整理成一个新用户可以从头走完的产品流程。
3.1 第一次使用：从注册账号到拥有一个家
- 用户通过邮箱验证码注册账号，也可以完成密码重置；
- 第一次登录后，可以创建自己的家庭，或通过一次性邀请码加入已有家庭；
- 家庭 Owner / Admin 可以管理成员角色、设备控制权限、车辆权限与管理权限；
- App 根据当前账号和家庭关系加载对应的房间、成员、设备、场景与自动化。
这一步让 SmartHome AI 不再依赖预置账号或开发者数据，而是具备了完整的账号与家庭起点。
3.2 安装 LocalBridge：扫码完成本地网关安全绑定
对于局域网设备、BLE 传感器和需要本地凭据的厂商生态，用户可以在 macOS 或 Windows 上安装 LocalBridge。
完整流程为：
- 安装并启动 LocalBridge；
- LocalBridge 生成二维码和短时配对信息；
- 用户在 iPhone App 中扫描并批准绑定；
- LocalBridge 在后台自动兑换安全凭据，无需用户再点击一次“完成绑定”；
- 绑定成功后，家庭名称、网关在线状态和最近心跳会同步显示；
- 厂家授权由 LocalBridge 在本地发起，密码、Token、BLE bindKey 等敏感凭据仅保存在本机凭据库，不经 Cloud 传输；首次授权时，手机与 LocalBridge 需处于同一局域网。
3.3 添加智能设备：选择品牌插件，而不是手动配置进程
LocalBridge 采用插件化 Worker 架构。用户先选择品牌或协议，再安装对应插件并完成授权/局域网扫描，系统随后显示可认领设备。
当前已形成七类 Worker 接入清单，覆盖：
- Tesla Fleet API；
- Roborock 扫地机；
- Gree 空调；
- Haier 冰箱与热水器；
- Xiaomi miIO 设备与 MiWiFi 路由器状态；
- BLE 温湿度传感器；
- ESP32 本地硬件。
插件 Catalog 支持版本、哈希和签名校验；插件更新不会要求重启云端服务。临时网络错误、厂家限流、车辆休眠和真正的授权失效会被区分处理，避免把“网络波动”误报成“账号失效”。
3.4 添加传统设备：ESP32 无串口配网，学习红外后直接加入场景
SmartHome AI 的 ESP32-S3 学习型遥控模块面向仍然好用、但只有红外 / BLE 遥控器的空调、电视、投影仪和风扇。
复赛版本将开发者式配网改成了用户流程：
- ESP32 启动
SmartHome-IR-*配网热点； - 手机连接热点，只填写家庭 Wi-Fi 名称与密码；
- ESP32 联网后由 LocalBridge 自动发现并进入认领流程；
- 用户在 App 中开始学习，并按下原遥控器按键；
- 红外 / BLE 波形被捕获、测试、命名并保存为家庭命令；
- 命令可以绑定为“开机”“关机”“观影”“温度预设”等标准动作；
- 动作最终可被 iPhone、Apple Watch、场景和自动化统一调用。
硬件还增加了明确的重置逻辑：按住 BOOT 3–8 秒只清除 Wi-Fi、保留家庭认领；按住至少 8 秒才恢复出厂。配合外壳，这一模块已经从裸开发板向可安装实物继续推进。
3.5 建立空间：扫描或手动搭建自己的数字家庭
复赛新增的 HomeSpatial 是 SmartHome AI 的空间层。它基于 RealityKit，将原先分散的 3D 试验入口替换为一套统一空间引擎。
用户可以：
- 使用 RoomPlan 扫描真实空间，或像建房游戏一样手动搭建房间；
- 调整墙体、门窗、尺寸和布局；
- 从家具目录中摆放、旋转和缩放家具；
- 将 Cloud 中的真实设备绑定到空间对象；
- 在 2D 平面、3D 视图和第一人称沉浸模式之间切换；
- 为房间启用“灯光跟随”等空间自动化。
HomeSpatial 的价值不是“做一个好看的 3D 户型”，而是给成员、房间、设备和自动化建立共同坐标：系统不仅知道“灯 01 在线”，还开始知道它在哪个房间、服务哪个区域，以及成员正在向哪里移动。
4. 三段完整场景，看懂这套产品为什么要把人、车、家放在一起
场景一：第一次安装，也能独立把真实设备接进来
用户注册账号并创建家庭，在电脑上安装 LocalBridge，用手机扫码完成绑定。随后在 App 中选择“格力”，安装对应 Worker，扫描到局域网空调并认领。
回到首页后，用户可以看到空调的真实开关、模式、目标温度和室温；从 Apple Watch 或 iPhone 发出操作后，命令经过权限校验，到达 LocalBridge 和真实设备，再通过影子与实时事件回到 App。
这段流程证明的不是某个按钮可以点击，而是一个陌生用户能够从空账号走到真实设备控制，并获得执行反馈。
场景二：一个“观影模式”，同时跨越新设备与旧设备
用户在 Apple Watch 上运行“观影模式”：
- 主灯关闭，氛围灯打开；
- 米家窗帘合拢；
- ESP32 向旧投影仪发射已学习的红外开机指令；
- 格力空调调整到舒适温度；
- 扫地机停止当前清扫并回到基站；
- 每一步的结果写入运行日志，并通过设备影子与 SSE 回传。
对于用户而言只有一次操作；对于系统而言，这次操作跨越了 Watch、Cloud、MQTT、LocalBridge、厂商局域网协议和自研硬件。
场景三：家开始服务具体的人，而不是一组设备
经用户授权后，iPhone 从 HealthKit 读取由 Apple Watch 采集的睡眠数据，只将睡眠摘要上传到 Cloud。系统等待确认用户真正醒来，再根据这个成员的权限和偏好运行专属早安场景。
同一个成员的在家/离家、房间、睡眠和活动状态，也可以与车辆状态共同参与自动化：
- 用户离家后，关闭不必要的灯光、空调和影音设备；
- Tesla 充电完成后，向对应成员发送通知；
- 用户回家前，根据车辆与成员状态准备回家场景；
- 进入室内后，HomeSpatial 与房间状态为灯光跟随提供空间关系；
- 无人区域在确认后延迟关闭设备，减少无效能耗。
其中，车辆回家、CSI 空间感知和连续灯光跟随的组合仍会按可靠性逐步开放；已经稳定的成员、睡眠、房间、设备、场景和车辆能力则构成这条体验的底座。
5. 相比初赛 Demo，复赛版本完成了什么升级
从 7 月 13 日初赛提交到 8 月 8 日，项目仓库继续产生了 178 个提交。迭代重点不是简单增加页面，而是补齐安装、引导、异常、安全、测试和真实设备闭环。
| 维度 | 初赛 Demo | 复赛完整作品 |
|---|---|---|
| 产品入口 | 以已有环境演示核心能力 | 邮箱注册/重置、建家/邀请、选家、退出登录形成完整账号流程 |
| LocalBridge | 更接近开发者运行环境 | macOS PKG、Windows Setup、系统服务、本地管理 UI、自动更新与恢复出厂流程 |
| 网关绑定 | 依赖配置与人工确认 | 二维码 + 短时挑战 + App 批准 + 后台自动兑换凭据 |
| 厂商接入 | Worker 能运行 | 品牌/协议选择、插件安装、授权、扫描、发现、验证、认领与状态诊断形成向导 |
| ESP32 接入 | 偏开发板联调 | AP 配网、自动发现/认领、分级重置、V5 壁装外壳 |
| 空间能力 | People/Room/CSI 能力底座 | RealityKit HomeSpatial：扫描/手建、家具、设备绑定、2D/3D、沉浸与灯光跟随入口 |
| 设备体验 | 功能分散，部分长列表易跳动 | 统一可搜索选择页、首页快捷控制、按家庭保存排序、明确在线/波动/需重新授权状态 |
| 异常处理 | 外部 API 异常容易统一显示为离线/失效 | 厂家限流、网络故障、车辆休眠、服务异常与真实授权失效分类处理并降级重试 |
| 安全 | 已有权限和高风险确认 | HTTPS/MQTTS、原子认领、Gateway 来源约束、本机凭据库、一次性确认与审计进一步加固 |
| 质量保障 | 以手工 Demo 验证为主 | 29 个 Cloud *Tests.cs、LocalBridge/Worker/iOS 测试，以及覆盖 .NET、Python Worker、ESP32、iOS 的 GitHub Actions CI |
6. 产品功能地图
| 能力域 | 已建立的能力 | 用户价值与当前边界 |
|---|---|---|
| 账号与家庭 | 邮箱验证码注册、密码重置、多家庭、邀请码加入、成员角色与权限 | 新用户无需预置账号即可开始体验 |
| iPhone / Watch | 首页、房间、设备、场景、自动化、设置；Watch 摘要与快捷控制 | 常用操作不必打开多个品牌 App |
| HomeSpatial | RoomPlan、手动建房、家具、真实设备绑定、2D/3D、沉浸 | 将设备列表升级为空间化家庭视图 |
| People Layer | 成员、角色、偏好、Presence、房间状态、睡眠摘要 | 自动化开始服务具体成员 |
| Vehicle Layer | Tesla 状态、电量、续航、温度、充电与分级控制 | 车辆成为家庭生态中的移动空间；真实能力依赖官方 API 与车辆在线状态 |
| Home Layer | Xiaomi、Gree、Haier、Roborock、BLE Sensor、ESP32 | 统一不同品牌和协议的设备能力 |
| 传统设备改造 | 红外学习、测试、保存、命名、按钮/动作绑定和执行 | 不更换仍然好用的家电；BLE 遥控学习兼容仍在真机矩阵验证中 |
| 场景与自动化 | WHEN—IF—THEN、顺序动作、延时、冷却、防抖、运行日志、安全策略 | 一次操作或一个状态变化驱动多个设备协同 |
| 本地 AI | Qwen + LoRA 将自然语言解析为结构化意图 | AI 不直接控制设备，Cloud 保留最终执行权 |
| Wi-Fi CSI | 六节点、30 条有向链路采集、校准、保存、回放和区域实验 | 无摄像头空间感知仍属实验能力，不把研究结果包装成稳定定位产品 |
| 交付与运维 | Cloud 部署产物、LocalBridge 跨平台安装、插件 Catalog、CI | 从“我的电脑能跑”推进到“评审可安装、可复现、可诊断” |
7. 系统架构：Cloud 负责规则，LocalBridge 负责接入，AI 不能绕过安全链
┌──────────────────────────────────────────────────────────┐
│ iPhone / Apple Watch / HealthKit / HomeSpatial / Voice │
└──────────────────────────┬───────────────────────────────┘
│ HTTPS REST / SSE
┌──────────────────────────▼───────────────────────────────┐
│ SmartHomeCloud │
│ Account · Home · People · Vehicle · Device · Scene │
│ Automation · Shadow · Permission · Confirmation · Audit │
└──────────────┬────────────────────┬───────────────────────┘
│ MQTTS │ Secure Edge Channel
▼ ▼
┌────────────────┐ ┌──────────────────────────────┐
│ ESP32-S3 │ │ LocalBridge macOS / Windows │
│ IR / BLE / CSI │ │ Plugin Runtime · Local Vault│
└────────────────┘ └──────────────┬───────────────┘
│
┌─────────────────┼─────────────────┐
▼ ▼ ▼
Local AI Worker Brand Workers LAN / BLE
Qwen + LoRA Tesla/Roborock ESP32 discovery
Gree/Haier/
Xiaomi
一次设备操作的闭环为：
用户/场景/自动化发出意图
↓
Cloud 校验家庭、成员权限、设备能力和风险等级
↓
MQTT / LocalBridge / 厂商 Worker / ESP32 执行
↓
真实设备状态、命令回执与运行日志返回
↓
设备影子 + SSE 更新 iPhone / Watch
8. 五项核心创新
8.1 把“接入协议”做成用户可以完成的产品流程
很多跨品牌智能家居项目能在开发者电脑上运行，却无法交给普通用户。SmartHome AI 2.0 将安装、扫码绑定、插件下载、厂商授权、设备发现、验证与认领串成一条完整路径，并让 macOS / Windows LocalBridge 具备安装、更新、诊断和恢复出厂能力。
8.2 统一的不是设备列表，而是人、车、家与空间
设备、成员、车辆和房间不再属于四套互不相干的页面。它们共享家庭身份、成员权限、场景、自动化和状态反馈；HomeSpatial 又进一步为房间、家具与真实设备提供共同的空间关系。
8.3 用低成本硬件延长旧设备生命周期
学习型遥控模块把一个真实遥控器按键转成可以命名、保存、测试、绑定和编排的标准动作。旧投影仪、空调、电视和风扇无需更换，也能进入今天的 iPhone、Watch 与自动化体验。
8.4 AI 负责理解，确定性系统负责执行
本地 Qwen + LoRA 只把自然语言转换为结构化意图。它不能直接发布 MQTT，也不能绕过家庭权限、设备能力或 Tesla 高风险确认。这样既保留自然交互，也避免“模型一句话直接开锁/启动车辆”的危险路径。
8.5 对“不可知”诚实建模
真实物联网最大的难点不是发出命令，而是知道结果是否可信。SmartHome AI 会区分：
- 真实设备上报状态与仅根据指令推测的状态；
- 设备离线、连接波动、厂家限流与授权真正失效；
- 低风险刷新、中风险控制与高风险车辆命令；
- 已验证产品能力与仍在实验的 CSI / BLE 兼容能力。
这种可信度和故障分类，让系统不会把“消息发出去了”伪装成“现实世界已经执行成功”。
9. 安全、隐私与可靠性设计
SmartHome AI 连接真实家庭和车辆，因此安全不是附加功能，而是命令链路的一部分。
- iOS 与 Cloud 使用 HTTPS，Cloud 与边缘链路使用 MQTTS；
- LocalBridge 管理服务仅开放本地安全通道，并使用短时配对与本机凭据库；
- 设备发现与认领绑定 Gateway 来源，认领过程使用条件更新避免并发抢占；
- Tesla 高风险命令使用独立权限、二次确认、短时会话、冷却和审计；
- 高风险车辆命令不能通过普通自动化规则绕过；
- HealthKit 默认只上传睡眠摘要，不上传完整原始健康数据；
- 厂商密码、Token、BLE bindKey 等敏感凭据仅保存在 LocalBridge 本机，且不经 Cloud 传输；
- CSI 不采集面部、衣着与家庭画面；
- 红外设备属于开环控制，界面会明确区分推测状态与可靠回传；
- 厂商限流、超时和车辆休眠采用降级与重试，不会轻易清空已有授权。
10. 创作历程：三个阶段，把一个痛点做成一套生态
第一阶段：证明端—边—云链路能够跑通
项目最初从“能不能用同一个 App 控制不同设备”出发，建立账号、家庭、房间、设备、Cloud、MQTT 与 ESP32 的基础链路。这个阶段最重要的结果，是证明一条命令能够经过身份和设备查找，到达真实硬件，并返回执行结果。
第二阶段：跨越品牌，建立统一设备、场景和安全模型
随后，LocalBridge 与 Worker 逐步接入 Tesla、Roborock、Gree、Haier、Xiaomi、BLE 传感器和自研 ESP32；Cloud 增加设备影子、场景、自动化、运行日志、SSE、人员权限和车辆风险分级。
初赛提交证明了这套“人—车—家”架构成立，但它仍然更像一套由开发者维护的复杂系统。
第三阶段：把开发者系统变成用户产品
复赛阶段的重点是产品化：
- 建立邮箱注册、密码重置、建家和邀请流程；
- 将 LocalBridge 打包为 macOS / Windows 安装程序；
- 设计二维码安全绑定与自动兑换；
- 将厂商 Worker 变成可选择、可下载、可升级的插件；
- 将 ESP32 改为无串口 AP 配网和自动认领；
- 用 RealityKit HomeSpatial 统一扫描、编辑、设备绑定与沉浸体验；
- 补齐错误分类、授权失效、设备离线、登录过期和删除家庭等异常路径；
- 建立跨 .NET、Python、ESP32 与 iOS 的自动测试/构建流程；
- 为 ESP32 完成可壁装外壳设计，让硬件从开发板继续靠近实物产品。
这段历程让我认识到：完整产品与 Demo 的差别，往往不在最耀眼的功能，而在第一次安装、失败后的提示、凭据放在哪里、设备断网后怎么办，以及用户能否真正独立走完整条路径。
11. TRAE 实践过程
SmartHome AI 的复赛迭代继续全程使用 TRAE Work / TRAE IDE。TRAE 在这个项目中不只是生成代码，而是参与了需求拆解、跨仓库影响分析、架构重构、真实设备故障定位、测试补齐、构建打包与说明材料整理。
11.1 典型协作方式
| 阶段 | 我和 TRAE 的协作 |
|---|---|
| 产品拆解 | 把“评审能不能独立使用”拆成注册、安装、绑定、授权、发现、认领、控制、反馈八段路径 |
| 架构重构 | 将旧 Room3D / SceneKit 入口替换为统一 RealityKit HomeSpatial，并通过回归测试保护迁移 |
| 真实故障定位 | 根据日志、状态码与调用链区分 Tesla 休眠、厂家限流、网络超时、Worker 异常与真正的授权失效 |
| 安全加固 | 审查设备认领、配对、凭据存储、高风险命令、HealthKit 与日志链路，补充负向测试 |
| 产品体验 | 修复动态 Picker 跳回顶部、卡片手势冲突、401 后停留旧页面、重复提示与错误文案不准确等问题 |
| 交付工程 | 生成并验证 macOS PKG、Windows Setup、插件包、Catalog、SBOM、部署产物和跨平台构建 SOP |
| 质量验证 | 增加 Cloud、LocalBridge、Worker、iOS 与 UI 测试，并建立 GitHub Actions 构建矩阵 |
11.2 开发关键步骤截图
截图 1：使用 TRAE 拆解复赛产品化任务，分析 iOS、Cloud、LocalBridge、Worker 与 ESP32 之间的跨端影响。
截图 2：结合日志、状态码和调用链定位真实设备异常，区分网络波动、厂家限流、车辆休眠与授权失效。
截图 3：补充自动化测试、跨平台构建和安装验证，让多端项目形成可重复的交付流程。
11.3 任务 Session ID
任务一：跨端产品化与架构调整
1589217918721272:8cb27ab8953a38b418471f517168b701_6a6ab81e0d01537d17436296.6a6afb5c0d01537d17437845.6a6afb5c0d01537d17437843:TraeWork CN.0.1.45.no_sid.no_ppe.T(2026/7/30 15:21:00)
任务二：真实设备接入与异常定位
1589217918721272:1a95128f46b36a78d35add02e71af3b2_6a64b4ae0f9e8c13a735ad30.6a64bb060f9e8c13a735aefa.6a64bb060f9e8c13a735aef8:TraeWork CN.0.1.45.no_sid.no_ppe.T(2026/7/25 21:32:54)
任务三：测试、构建与交付验证
1589217918721272:8939ac46d719ca768a9771bff388e720_6a6b0f257ad0b3599e10de2b.6a6c2dec29058b21fe76357c.6a6c2dec29058b21fe76357a:TraeWork CN.0.1.45.no_sid.no_ppe.T(2026/7/31 13:09:00)
12. 技术栈
| 层级 | 技术与实现 |
|---|---|
| iPhone / Watch | SwiftUI、RealityKit、RoomPlan、HealthKit、WatchConnectivity、SSE |
| Cloud | .NET 8、ASP.NET Core、EF Core、SQLite、REST、SSE、MQTTnet、JWT |
| LocalBridge | .NET 8、Avalonia、系统服务、本地安全 API、插件运行时、加密凭据库 |
| 厂商 Worker | Python、FastAPI、Tesla Fleet API、Roborock、Gree LAN、Haier Cloud、Xiaomi miIO / MiWiFi、Bleak |
| 本地 AI | Qwen + LoRA、结构化意图、FastAPI、训练/评测脚本 |
| 硬件 | ESP32-S3、红外收发、BLE、Wi-Fi AP 配网、MQTT、六节点 Wi-Fi CSI |
| 交付 | macOS PKG、Windows Setup、Cloud Windows/Docker 产物、插件 ZIP/Catalog、SBOM |
| 自动化验证 | GitHub Actions 构建/测试 Cloud、LocalBridge、Python Worker、ESP32 PlatformIO 与 iOS Simulator |
13. 商业化与社会价值
13.1 面向真实家庭的渐进式改造
SmartHome AI 不要求用户一次性替换整套设备。用户可以先安装 LocalBridge，只接入最常用的空调或扫地机；再按房间增加 ESP32 遥控模块，将旧投影仪、电视和风扇逐步纳入场景。
这种方式适合已经装修完成的家庭，也适合小型商铺、民宿和工作室：保留原有装修和设备，只在需要的地方增加智能能力。
13.2 可能的产品形态
- 面向家庭：SmartHome App + LocalBridge + ESP32 学习型遥控套件；
- 面向小型商铺：开店/打烊、节能、设备状态与多人权限方案；
- 面向设备与开发者：统一能力模型、Worker 插件规范与设备接入 SDK；
- 面向隐私敏感用户：本地凭据、本地 AI 与无摄像头空间感知选项。
13.3 可持续价值
保留仍然能正常工作的家电，可以减少为了“加入某个生态”而提前淘汰设备造成的浪费。People Layer、房间状态、睡眠与空间感知则让自动化更接近“有人且需要时才运行”，减少无人区域照明、空调和影音设备的无效能耗。
SmartHome AI 希望实现的不是“为了智能而购买更多设备”，而是让已有设备用得更久、在更合适的时间工作。
14. 当前边界与后续计划
SmartHome AI 已经具备完整演示和独立体验所需的主体链路，但我不会把所有研究能力都描述成成熟产品：
- Wi-Fi CSI 当前是六节点采集、校准、保存/回放与区域实验能力，正式进入自动化前仍需建立准确率、误报率与家庭环境泛化指标；
- 红外学习是当前传统设备改造的主要稳定路径，BLE 遥控学习与更多设备兼容性仍在真机矩阵验证；
- Tesla、Roborock、Haier 等外部生态会受到官方 API、账号区域、网络与设备在线状态影响，系统重点通过降级、缓存、重试和准确错误分类提升体验；
- HomeSpatial 当前以本地空间模型为主，后续将补充 Cloud 同步与多设备冲突策略；
- 系统已适合受控评审与真实家庭演示，面向大规模公开部署仍需继续完成更完整的备份、可观测性、设备身份与容量验证。
下一阶段将重点推进：
- 让 HomeSpatial 中的设备位置、房间状态和成员移动稳定进入自动化；
- 建立 CSI 数据集与可量化评测，再逐步开放无摄像头 Presence / 区域判断；
- 扩展更多协议和 Worker，并形成第三方接入文档；
- 完善 Cloud 备份恢复、设备级身份、命令幂等和监控；
- 继续降低安装与授权门槛，让“添加一个新品牌”像安装一个插件一样清晰。
15. 总结：复赛版本完成的，不是更多功能，而是从想法到产品的最后一公里
初赛时，SmartHome AI 证明了不同品牌、新旧设备、人和车可以进入同一个生态。
复赛时，它进一步回答了：
- 新用户如何从空账号开始？
- 本地网关怎样安装和安全绑定？
- 厂商插件怎样下载、授权、发现与升级？
- 旧设备怎样无串口配网、学习命令并进入场景？
- 设备放在哪个房间，如何进入一个可交互的数字家庭？
- 网络波动、限流、休眠与授权失效怎样被准确区分？
- AI、自动化和车辆控制怎样服从同一套权限与安全边界？
- 一个跨 iOS、Watch、Cloud、桌面、Python 和 ESP32 的系统怎样持续验证与交付？
SmartHome AI 仍会继续生长，但它已经不再只是一个“可以展示的 Demo”。它开始成为一套能够安装、能够从零使用、能够连接真实设备，也愿意诚实面对现实世界不确定性的人—车—家智能产品。
品牌决定设备从哪里来，不再决定它们能否一起工作；设备决定系统能做什么，而具体的人决定它应该在什么时候做。
