三个遥控器、四五个 App外加一个失联的地下停车库——这就是我每天回家前最真实的混乱场面。Wanny 这个项目最初就是为了终结这场混乱而动手做的一个能把微信、家电、汽车和 AI 大模型串成一个整体的个人管家。这套系统跑到现在已经小半年中间翻过不少车也踩出了一堆文档里根本不会写的坑。如果你也想把手头零散的智能设备、微信入口和大模型能力粘合成一个真正能“干活”的助手这篇东西应该能给你一份完整的路线图。1. 三个遥控器、四个 App 和一个失联的地下车库Wanny 的起点1.1 一个再普通不过的回家场景暴露了什么问题我住的小区地下车库信号不好车停进去之后 App 基本处于“失联”状态。夏天的时候我一般会在楼上先把车里的空调打开但每次都得经历这么一套流程打开微信处理完消息切到车厂 App等它慢慢连上车机然后发现还要再切到另一个智能家居 App 去开家里的空调。要是中途有个电话进来前面的流程全部白搭。更别提不同设备各有各的语义有的说“空调 26 度制冷”有的说“AC on temp 26”还有的压根没有状态回读点完了就是个黑盒。这种体验让我意识到问题根本不在于某个 App 做得好不好而在于所有服务都在各自的孤岛里缺一个能把它们串起来的中枢。微信里有我的社交关系家电里有我日常的舒适度需求车里有我的出行轨迹AI 大模型则能理解这些需求背后的意图——把它们连在一起才是“管家”该有的样子。Wanny 这个名字就是“万”的音译目标也很直白万物的消息和操控统统归它管。1.2 为什么市面上的方案总是差一口气有人会说米家、苹果 HomeKit、天猫精灵不也能做联动吗说实话这些平台在自己生态内做得都不错但一旦跨域就捉襟见肘了。车厂 App 通常不开放给第三方微信本身又不具备“控制一切”的形态智能家居平台更不会去对接车机状态。你有见过哪个智能家居 App 能根据车快到家的位置自动把空调打开、灯调暗、然后通过微信语音跟你确认一遍基本没有。而且生态捆绑也是个麻烦。家里总会有几个“不合群”的电器老空调没有 Wi-Fi只能靠红外遥控空气净化器是某小众品牌云 API 时不时抽风车库门更搞笑原厂遥控器只有一个固定码。这些设备在平台体系里全是孤儿。所以我在动手设计 Wanny 时就定了三条原则不绑定单一云平台、本地优先、适配器化接入。所有设备只要能连上局域网或提供开放接口就有办法纳入统一管理云端只是加速和远程入口绝不是唯一通道。1.3 这篇博文适合谁看如果你是一个想折腾智能家居的开发者、一个对“车家互联”好奇的车主或者单纯想用大模型做点真正有用工具的人这篇文章能省你不少时间。我会把 Wanny 整体的架构思路、微信接入的细节、家电与汽车的三种接入档位、AI Agent 的编排逻辑以及我实际运行三个月的翻车记录全部摊开来讲。代码层面的具体实现我不会贴很多但这些选型决策和踩坑过程比代码值钱得多。2. Wanny 的系统骨架消息中枢、适配器插槽与本地优先原则2.1 整体分层入口-适配-编排-模型Wanny 不是某一个超大的单体程序而是一个由四层组成的小型平台。最上面是入口层目前实际可用的是微信消息和 Web 控制台语音助手接口也预留了下面是适配层每个设备或平台对应一个独立适配器互相不影响中间是编排层负责理解消息、调用工具、执行规则最底下是 AI 层接本地小模型和云端大模型按需路由。层级职责运行方式入口层微信消息、Web 面板、语音指令Node.js 服务 WebSocket适配层微信、红外、米家/涂鸦、Home Assistant、车联网 API独立进程或插件方式加载编排层消息归一化、意图识别、规则引擎、权限校验核心路由服务AI 层本地模型Ollama、云端大模型 APIDocker 容器 网关这层结构有一个直接的好处加新设备时我只需要写一个新的适配器不影响其他任何模块。Wanny 的“超级管家”能力本质上是靠这层适配器把外部世界抽象成了统一的指令集。2.2 适配器设计每个外部平台都是一个“插头”我给每个适配器定义了同一套接口核心只有四个方法authorize负责授权/登录send负责下发指令query负责读取状态callback负责接收平台主动推上来的事件。拿空调红外适配器来说send的入参不是“REMO-xxx 0001010B”这种底层码而是一个统一的语义对象。{ device: air_conditioner, action: set, params: { mode: cool, temperature: 26, fan_speed: auto }, source: wechat, request_id: wx_msg_20241120153001_abc }适配器收到这个对象后负责把“制冷、26 度、自动风”翻译成对应红外码或云 API 的字段。这样设计的核心价值在于编排层永远不需要关心设备长什么样它只处理语义指令至于指令怎么变成红外脉冲、怎么以 HTTPS 请求发给车厂那是适配器自己的事。2.3 消息归一化把微信消息、设备事件、模型输出变成同一种“语言”Wanny 内部跑着一条消息总线所有进来的东西都会经过归一化处理统一转成一种内部消息结构source来源、type指令/查询/事件、payload载荷、request_id幂等标识。微信里发来“帮我把空调开到 26 度”会被转成上面那段 JSON车联网平台推送“充电已完成”也会被转成一个事件消息AI 模型想执行动作时同样通过这个结构返回。request_id是我在最早期就埋下的一个关键设计后来的很多坑都靠它兜底。因为微信回调、设备回调、HTTP Webhook 这些通道天然会重复投递消息如果没有一个全局唯一的 ID 做幂等你会发现某个指令被执行了三次还浑然不觉。这个字段后来帮我避免了一次“关灯被重复执行八次”的惨剧后面翻车现场章节里会细讲。2.4 本地优先与隐私边界哪些东西绝不出局域网在设计之初我坚持把所有家中的敏感数据留在本地设备状态、历史操作记录、语音指令文本全部放在家里的服务器上。云端的模型调用只有拿到“被允许发送”的消息内容才会发送到 API并且发送前会做一次脱敏——把地址、手机号、人名替换成占位符。这么做还有一个现实原因家里的网络偶尔会断如果整套系统依赖云断网时连灯都开不了就太蠢了。Wanny 的家电控制链路默认走局域网微信远程入口走自建网关网关断了也没关系只要人在家语音助手和 Web 面板照常可用。对于所有外部通道我只暴露必要接口并且在网关上做了双向证书校验宁可自己麻烦一点也不给外部扫描留口子。3. 微信接入实操企业微信通道、支付 V3、扫码登录和 Linux 端的真实踩坑3.1 第一道选择题个人微信还是企业微信每个人的第一反应都是“那我能不能直接把个人微信接入 Wanny”这里我给个非常实际的经验个人微信没有稳定开放的开发者接口靠自动化工具去挂协议不仅随时可能被封号而且逆向难度高不值得。我最终的选择是把消息通道放在了企业微信上——创建一个只有我自己的企业然后通过企业微信自建应用接收和发送消息。这个方案完全走官方 API稳定、合规而且架构上跟一个“智能客服机器人”完全一致生态成熟坑少。如果你只是个人使用企业微信自建应用和个人微信之间的体验差异其实可以接受。日常交互方式是我给 Wanny 发消息它在企业微信里回复同时 Wanny 也可以主动给我推通知比如“充电完成”“门锁异常”“天气预报”。微信生态里的支付和扫码登录则通过企业微信和公众号的能力实现——这是后面几节的重点。3.2 消息收发层的实现思路与格式约定接入企业微信应用消息核心就是两件事配置回调 URL 接收用户消息调用 send API 返回回复。回调 URL 必须是一个 HTTPS 地址并且要支持企业微信的签名校验机制——从 URL 参数里取msg_signature、timestamp、nonce和你自己配置的 Token、EncodingAESKey 做计算比对一致才处理。我踩过的第一个坑就是回调地址返回时间太长。企业微信要求服务器必须在 5 秒内响应否则会重试。而最初我在回调里同步调用了 AI 模型一次大模型推理轻松超过 5 秒企业微信就开始重复推送导致同一句话被模型处理了好几遍。后来我把流程改成先立刻返回“收到”再异步处理并把结果主动推送给用户这个问题才算根治。3.3 支付 V3、扫码登录与小程序的签名心得项目里有一个和微信支付相关的场景为了方便家里人使用部分增值功能比如月度汇总报告我接入了微信支付 V3。V3 和 V2 最大的区别在于全链路使用证书签名任何请求都需要用商户私钥对请求内容签名响应还需要用平台证书验签。很多教程不会强调的一点是V3 默认要求接口请求头里带上Authorization: WECHATPAY2-SHA256-RSA2048格式的认证头其中签名串的构建顺序非常容易出错。我建议直接用官方 SDK别自己手写但 SDK 版本要对准商户平台接口文档。扫码登录相对就轻松不少。企业微信扫码登录的标准流程是构造 OAuth2 授权链接带appid、agentid、redirect_uri和state参数用户扫码确认后企业微信回调你的跳转地址带上code后端拿code换用户身份。这里有个经验state参数一定要自己生成并校验能有效防止回调伪造。我是随机生成了带过期时间的一次性 state本地缓存校验通过后才继续。另外微信开发者工具里的“小程序签名”特别容易出问题。真机预览时如果报签名错误先看看是不是开发者工具里的 AppID 和密钥不匹配再看小程序的 request 合法域名有没有配置——别问我为什么提醒这个坑我蹲了两天。3.4 Linux 版微信、界面虚化与聊天记录迁移的杂症Wanny 的家用服务器是 Ubuntu 24.04所以我在 Linux 上装过微信 Linux 版 4.1.11。这个版本大部分功能正常但有一个非常难受的问题界面里的中文渲染成虚化模糊的状态。我先后试过调整字体渲染、设置环境变量最后发现最有效的组合是在启动时禁用 GPU 加速渲染并把缩放比例设为 1.0实测字体边缘清晰了很多。还有一次我在迁移系统时才发现微信的数据目录里保留着以前版本的聊天记录但新版客户端的导入入口藏得比较深。如果你也遇到类似情况先确认旧版本的聊天记录数据库文件还在再从新版客户端的设置里找到“迁移与备份”通过导入本地记录的方式恢复千万不要直接删旧目录。官方文档里对这一块的说明不够清晰我第一次没注意差点把几年的聊天记录都折腾没了。关于“伪造微信浏览器头信息”这个方向我也多说一句。早期我在 Web 端做过一个判断用户是不是在微信内置浏览器里打开页面的逻辑网上很多方案都是让你识别 UA 里是否包含MicroMessenger。我实测发现这玩意儿一点都不靠谱部分安卓定制 ROM 里的 UA 会被改写有些新版本甚至不再默认带这个字段。后来我彻底放弃了这种判断方式改用官方开放能力的 JSSDK 初始化结果来识别微信环境既稳定又安全。4. 家电接入红外遥控、智能设备 SDK 与 Home Assistant 的三档实战4.1 三种接入档位按设备情况选型家电这块我在 Wanny 里跑了三套接入方式按“顺手程度”排个序方案适用设备优点缺点推荐度Home Assistant 桥接支持 Wi-Fi 的主流智能设备生态全、有统一状态模型需要额外部署 HA 环境高智能设备官方 SDK/云 API米家、涂鸦等平台设备对接稳定、权限清晰不同平台协议不统一中高红外码库 万能红外棒老旧空调、传统电视、风扇等几乎通吃所有遥控设备无状态回读、码库需要学习中我家里最麻烦的是一个用了七八年的老空调没有任何 Wi-Fi 模块但制冷效果很好没理由换。最终方案是买了一个支持局域网 API 的万能红外棒放在客厅对着空调和电视的方向。红外棒本身有一个学习功能用原装遥控器对码红外棒记录下原始的时序码然后 Wanny 通过 HTTP 接口触发发射。4.2 没有状态回读的设备怎么保证“语义一致”这是整套家电接入里最大的难点。红外方案只能单向发码设备改没改变状态Wanny 完全不知道。比如你用原装遥控器把空调关了但 Wanny 内部还记着“当前 26 度制冷”就会说出错误的信息。我的做法是引入一个设备状态机每个没有回读能力的设备在 Wanny 里维护一份“推测状态”每次下发的指令都会更新这个状态用户如果手动操作设备需要在 Web 面板告诉它“我手动改了状态”或等它定时问你一次。这个方案不完美但在当前硬件条件下已经是性价比最高的解法。如果是带状态反馈的 Wi-Fi 插座、智能灯就尽量走带查询接口的协议优先使用真实的query结果覆盖推测状态。另外别小看发码时序。红外设备往往不能连续快速接收指令两声指令间隔至少要在 800 毫秒以上否则会丢码。我最初没有做过任何速率限制连续下发“调到 26 度、风量自动、摆风”三个指令时空调经常只执行了第一条。后来我在红外适配器里加了一个指令队列每条指令之间强制间隔 1 秒这个问题就基本解决了。4.3 场景联动的一个实战例子回家前的“不折腾”模板Wanny 最吸引我的地方就是可以基于规则做跨域联动。我写了一套简单的 ECA 规则引擎Event-Condition-Action事件源是“位置信息、时间、设备状态”条件是一堆比较表达式动作则是调用前面做的统一语义指令。一个我每天都在用的“回家”场景是这样的手机连接到小区 Wi-Fi 时Wanny 收到位置事件再过 3 分钟经过一个延迟确认机制确认我没有中途离开接着触发一连串动作客厅空调开到 26 度制冷、空气净化器开到自动档、热水器提前启动、车联网平台查询剩余电量并在电量不足时给我微信推送充电建议。这套逻辑如果用传统 App 的人工操作少说要 3 个 App 切来切去、花上 5 分钟Wanny 自动跑完也就 15 秒左右。对我不否认直接喊智能音箱也能做到一部分但那仅限于同一生态内的设备——车和微信这一个跨域动作智能音箱至今做不了。4.4 安全边界物理开关永远是最高优先级家电接入再多我有一条铁律没动摇过任何自动化都不能覆盖物理层面的安全保护。比如离家布防模式下Wanny 可以关闭灯光和插座但绝对不会自动执行“打开门锁”这种操作电热毯、烤箱这类高温设备我可以定时关但绝不接受 AI 自动开启。所有这些高危动作在规则引擎里被标成high_risk任何来源的指令想触达它们都必须经过人工确认环节。宁可在便利性上打折扣也不让“管家”变成隐患的来源。5. 汽车接入OBD、原厂 App 与开放 API 之间我做了什么取舍5.1 接入汽车的三档方案成本与风险天差地别汽车是 Wanny 跨域能力的重要一环。车联网这块我在调研时把方案分成了三个档次方案成本能力范围风险我的建议OBD 蓝牙/Wi-Fi 盒子低几十到几百发动机转速、电瓶电压、故障码、部分行车数据低只读为主适合老车、数据党原厂 App 私有接口无需硬件与原厂 App 几乎一致中高接口未公开、随时会变不推荐长期依赖车厂开放平台 API视厂商而定官方定义的车辆状态与远程控制低平台可控最推荐优先选择很多朋友会建议我走第二条路抓原厂 App 的包、模拟请求从而拿到车锁、空调、充电桩的远程接口。我确实也做过短期实验也佩服那些逆向做得精细的作者——但对个人项目来说这套方案的脆弱性太高了原厂随手改一个接口签名整个适配器就得重写而且一旦涉及敏感功能接口的权限边界根本说不清万一操作出问题责任完全是自己的。所以最终 my recommend 是只要你的车厂提供任何形式的开发者接口或开放平台就优先用官方能力接入没有开放平台就老老实实停在 OBD 只读数据这个档位远程控制宁可手动去 App 里操作。5.2 我为什么没碰 VCU 和控制类接口功能安全视角在做调研的时候我翻了不少关于汽车 VCU整车控制器设计方案和功能安全的内容。ISO 26262 标准里有一个技术安全概念TSC它是在安全需求分析阶段把功能安全需求细化成技术安全需求的步骤背后那一整套“失效会导致什么后果”的分析思路对个人做车联项目的启示非常大。一辆车的转向、制动、动力控制属于整车控制单元管辖的高安全等级功能任何外部系统都不应该直接插手。哪怕技术上存在绕过车辆网关直连 CAN 总线的方案——这个在大学生智能汽车竞赛和点云数据处理圈里我也常看到类似的做法——也绝对不适合在个人项目上使用。我可以读取车辆的充电状态、位置、剩余续航这些是数据层面的交互但任何会对真实行车轨迹产生影响的控制指令比如远程启动、泊车挪动、OTA 触发我个人建议不碰也不建议你碰。智能网联汽车相关的安全通行规范越来越强调“车-路-云”协同下的边界清晰个人开发者在这一点上更要有敬畏心。5.3 实际用起来的三个高频场景目前 Wanny 里和汽车相关且稳定的功能集中在三个场景。第一个是充电提醒当车在充电时Wanny 每隔一小时通过开放 API 查一次电量到达 80% 或 100% 时通过微信给我推消息。这件事原厂 App 虽然也有通知但经常延迟或者收不到Wanny 自己轮询之后可以做到基本准时。第二个是到达联动手机定位显示我距离家 1 公里以内时自动提前开启家里空调和灯光。第三个是异常位移通知车辆在非我授权时段出现位置变化Wanny 会立刻给我发微信报警——这个仅仅依赖官方接口的vehicle_location上报功能取数逻辑不复杂但非常有价值。我也考虑过用 OBD 盒子读取电瓶电压来判断车是否需要启动补电但折腾了一阵发现 OBD 设备在停车后会持续耗电反而可能把电瓶亏空最终这个功能被我搁置了如果要做必须选择低功耗模式且定期休眠的硬件。5.4 智能汽车竞赛和行业规范给我的一些启发在调研过程中我专门看了全国大学生智能汽车竞赛的竞速规则和不少获奖方案。里面那些学生在传感器标定、路径规划上做的优化思路很值得借鉴——虽然他们玩的是赛道模型车但对执行机构的响应延迟、任务优先级设计跟真实车辆的控制系统是一脉相承的。尤其他们如何设计“失效安全”如果感知模块掉线车会怎么减速、怎么靠边这种思维模式放在个人智能管家里也同样适用——某个适配器挂掉时Wanny 应该怎么降级而不是瞎执行。这也是我始终坚持“决策与执行分离”的原因之一。6. AI Agent 编排function calling、模型路由和“决策与执行分离”6.1 从闲聊到干活关键的转折点是 function calling最早我想把大模型接进 Wanny 时采用的是“让模型输出一段 JSON然后我解析执行”的方式效果很不稳定。有时候模型会把参数名改掉有时候会在一段回复里夹带多个指令解析逻辑怎么写都别扭。后来换成了标准的 function calling工具调用情况才彻底改观。在 function calling 模式下我向模型声明一个叫control_device的工具描述它支持的参数设备名、动作、参数、优先级等。模型理解了用户消息“把空调调到 26 度”后不会再硬憋一段中文而是返回一个结构化的工具调用请求。{ function: control_device, arguments: { device: air_conditioner, action: set, params: { mode: cool, temperature: 26 } } }Wanny 的编排层收到这个调用请求后不是直接执行而是先过规则引擎校验再交给适配器执行。执行结果会作为一条工具消息回传给模型让它基于真实结果组织给用户的回复。这一步做完之后AI 从“聊天机器人”跃迁成了“能做事的 Agent”。6.2 本地模型与云端模型的分工路由决定成本AI 模型调用是 Wanny 里最烧钱和最高延迟的环节。我的做法不是简单地把所有请求都丢给云端而是采取分级路由第一级本地小模型Ollama 跑的轻量模型先对用户指令做一次快速分类判断这是“闲聊”、“设备控制”还是“信息查询”。第二级“设备控制类”请求直接走本地规则解析根本不经过大模型又快又省。第三级只有“闲聊”和需要复杂理解的“信息查询”才走云端大模型 API。这样一个设计让 Wanny 的响应速度基本稳定在 1 到 2 秒内。如果每个请求都等云端大模型返回延迟随随便便三五秒起步微信体验会很糟糕。而且本地模型对用户隐私更友好离线也能做基础控制。6.3 智能决策必须套上规则兜底AI 只负责理解不负责冒险我对 AI 的定位很明确它可以把模糊的自然语言转成结构化的操作意图但最终能不能执行要由编排层的规则引擎来决定。比如模型理解了“我今天不想开空调”之后返回了一条关闭空调的指令规则引擎会先检查当前室内温度、设备状态再决定是否执行。这里还有一张“禁止动作表”包括给陌生人下发一次性临时密码、取消布防模式、远程开锁这类高危动作任何来源的请求都必须进入人工二次确认队列。这一点我是在吃过亏之后才坚定的。有一回朋友在微信上开玩笑说“要不我远程开一下你家的门”本地模型把这句话理解成了一个设备控制意图差点就要触达门锁。虽然最终由于我的高危操作需要人工确认而拦住了但那次之后我立刻把所有涉及门锁、告警、支付的动作全部移出 AI 自动执行范围。AI 可以做万能的理解者但不能做不受约束的执行者。6.4 上下文管理塞全文给模型不如给一张“设备状态卡”对 Agent 来说上下文窗口的使用也是一门学问。一开始我把设备历史记录全塞进 prompt既费 token 又容易让模型抓不住重点。后来我改成了一种“状态卡片”方式每次注册工具调用前自动把当前所有在线设备的状态压缩成一段摘要比如“客厅空调 26 度制冷中、书房灯关闭、空气净化器自动档、车辆电量 85% 充电中”。这些摘自真实query状态的数据比历史消息列表更能帮助模型做出情景化回复同时还省了一大半 token 开销。会话记忆方面我在本地用 SQLite 存了最近 20 轮对话摘要配合固定格式的“临时记忆”字段让模型处理需要连续上下文的问题时不至于失忆。如果你的使用场景更重问答可以考虑接向量数据库但至少在我当前的需求下SQLite 的轻量方案已经足够。7. 稳定运行三个月后高频指令、翻车现场与选型清单7.1 高频指令数据哪些功能是“真香”哪些是“摆设”Wanny 稳定跑了三个月后我拉了一下后台记录梳理出用户侧其实就是我自己和家人真正每天都用到的功能功能调用次数日均使用评价微信查车/充电提醒6-8 次真香基本离不开了远程开关空调4-5 次夏天刚需回家场景联动3-4 次自动化后就忘了它的存在这才是成功AI 闲聊与信息查询2-3 次偶尔用不算高频家电耗电统计1 次/天我自己看的多家人不怎么看有意思的是一开始我花了大力气做的“AI 自然语言对话控制”反而是低频功能。大家更习惯固定句式比如“打开客厅灯”“空调 26 度”很少会对着它长篇大论。这说明语义理解这种能力做后备就好真正的核心是把那 20% 的高频操作做到极致稳定。7.2 三个典型翻车现场每个都值得你记笔记第一个翻车是空调“假回读”误导用户。当时我用红外方案控制空调但因为红外设备没有状态回读Wanny 只能靠“推测”。有一天家人用原装遥控器把空调关了Wanny 不知道AI 还信誓旦旦地回复“空调已调到 26 度模式”。后来的修复就是前面那张状态机所有无回读设备在受控情况下尽量避免 AI 断言回复里统一加上“已发送指令但该设备没有状态回读请确认实际运行状态”。第二个翻车是企业微信回调重复推送导致指令重复执行。有一次我发了一条“关掉书房灯”结果企业微信回调网速抖动平台重试了三次Wanny 连续执行了三次关灯。因为灯已经是关的表现不明显但换成风扇这类设备就会很伤硬件。修复就是前面提到的request_id幂等表相同 ID 的消息在 10 分钟内只处理一次。第三个翻车是汽车 API Token 过期导致充电提醒失效。车联网开放平台的 access_token 有效期是 7 天我最初只在启动时获取一次结果第 8 天开始充电通知就断了我隔了一天半才发现。修复方式是每个适配器自己维护 access_token并且对所有 401 响应统一做“刷新令牌 重试一次”的处理。这不算复杂但没有自动刷新机制几乎必然会在某个周日晚上突然失灵。7.3 硬件与软件选型清单如果你也想复刻一个类似系统我的选型可以作为起点主机用一块功耗较低的 x86 迷你小主机N100 级别即可内存 16G跑 Ubuntu 24.04软件栈用 Node.js 做微信接入和 HTTP API、Python 做 AI Agent 编排和模型路由、SQLite 做存储设备侧用 Docker Compose 统一管理容器红外棒选支持局域网 API 的品牌Home Assistant 直接官方容器起就行。这套组合的成本大概在几百到一千出头比买一堆独立智能家居网关便宜而且能统一管理。8. 接下来我还想让它学会的几件事Wanny 目前的状态并不是终点。接下来我自己在琢磨两个方向一个是把“固定位置触发联动”升级成“预测性联动”比如根据日历、天气和充电状态提前判断明天早上需不需要热车另一个是给 AI 层加入更细的“记忆”能力让它能记住家庭成员的偏好而不是每次只理解单条指令。如果你也想做一个类似的东西我最诚恳的建议是千万别一开始就想着把微信、家电、汽车、AI 全打通先跑通一个你每天都会用的小场景比如“微信远程开关空调”等这条链路真的稳了再往外面扩。超级管家不是一步到位的它是在一次次修修补补里慢慢长出来的。 
长河君 · 2026/9/9 23:19:15 · 阅读 1.2k 从微信到车家互联：用AI Agent打造个人智能管家的实战路线图
三个遥控器、四五个 App外加一个失联的地下停车库——这就是我每天回家前最真实的混乱场面。Wanny 这个项目最初就是为了终结这场混乱而动手做的一个能把微信、家电、汽车和 AI 大模型串成一个整体的个人管家。这套系统跑到现在已经小半年中间翻过不少车也踩出了一堆文档里根本不会写的坑。如果你也想把手头零散的智能设备、微信入口和大模型能力粘合成一个真正能“干活”的助手这篇东西应该能给你一份完整的路线图。1. 三个遥控器、四个 App 和一个失联的地下车库Wanny 的起点1.1 一个再普通不过的回家场景暴露了什么问题我住的小区地下车库信号不好车停进去之后 App 基本处于“失联”状态。夏天的时候我一般会在楼上先把车里的空调打开但每次都得经历这么一套流程打开微信处理完消息切到车厂 App等它慢慢连上车机然后发现还要再切到另一个智能家居 App 去开家里的空调。要是中途有个电话进来前面的流程全部白搭。更别提不同设备各有各的语义有的说“空调 26 度制冷”有的说“AC on temp 26”还有的压根没有状态回读点完了就是个黑盒。这种体验让我意识到问题根本不在于某个 App 做得好不好而在于所有服务都在各自的孤岛里缺一个能把它们串起来的中枢。微信里有我的社交关系家电里有我日常的舒适度需求车里有我的出行轨迹AI 大模型则能理解这些需求背后的意图——把它们连在一起才是“管家”该有的样子。Wanny 这个名字就是“万”的音译目标也很直白万物的消息和操控统统归它管。1.2 为什么市面上的方案总是差一口气有人会说米家、苹果 HomeKit、天猫精灵不也能做联动吗说实话这些平台在自己生态内做得都不错但一旦跨域就捉襟见肘了。车厂 App 通常不开放给第三方微信本身又不具备“控制一切”的形态智能家居平台更不会去对接车机状态。你有见过哪个智能家居 App 能根据车快到家的位置自动把空调打开、灯调暗、然后通过微信语音跟你确认一遍基本没有。而且生态捆绑也是个麻烦。家里总会有几个“不合群”的电器老空调没有 Wi-Fi只能靠红外遥控空气净化器是某小众品牌云 API 时不时抽风车库门更搞笑原厂遥控器只有一个固定码。这些设备在平台体系里全是孤儿。所以我在动手设计 Wanny 时就定了三条原则不绑定单一云平台、本地优先、适配器化接入。所有设备只要能连上局域网或提供开放接口就有办法纳入统一管理云端只是加速和远程入口绝不是唯一通道。1.3 这篇博文适合谁看如果你是一个想折腾智能家居的开发者、一个对“车家互联”好奇的车主或者单纯想用大模型做点真正有用工具的人这篇文章能省你不少时间。我会把 Wanny 整体的架构思路、微信接入的细节、家电与汽车的三种接入档位、AI Agent 的编排逻辑以及我实际运行三个月的翻车记录全部摊开来讲。代码层面的具体实现我不会贴很多但这些选型决策和踩坑过程比代码值钱得多。2. Wanny 的系统骨架消息中枢、适配器插槽与本地优先原则2.1 整体分层入口-适配-编排-模型Wanny 不是某一个超大的单体程序而是一个由四层组成的小型平台。最上面是入口层目前实际可用的是微信消息和 Web 控制台语音助手接口也预留了下面是适配层每个设备或平台对应一个独立适配器互相不影响中间是编排层负责理解消息、调用工具、执行规则最底下是 AI 层接本地小模型和云端大模型按需路由。层级职责运行方式入口层微信消息、Web 面板、语音指令Node.js 服务 WebSocket适配层微信、红外、米家/涂鸦、Home Assistant、车联网 API独立进程或插件方式加载编排层消息归一化、意图识别、规则引擎、权限校验核心路由服务AI 层本地模型Ollama、云端大模型 APIDocker 容器 网关这层结构有一个直接的好处加新设备时我只需要写一个新的适配器不影响其他任何模块。Wanny 的“超级管家”能力本质上是靠这层适配器把外部世界抽象成了统一的指令集。2.2 适配器设计每个外部平台都是一个“插头”我给每个适配器定义了同一套接口核心只有四个方法authorize负责授权/登录send负责下发指令query负责读取状态callback负责接收平台主动推上来的事件。拿空调红外适配器来说send的入参不是“REMO-xxx 0001010B”这种底层码而是一个统一的语义对象。{ device: air_conditioner, action: set, params: { mode: cool, temperature: 26, fan_speed: auto }, source: wechat, request_id: wx_msg_20241120153001_abc }适配器收到这个对象后负责把“制冷、26 度、自动风”翻译成对应红外码或云 API 的字段。这样设计的核心价值在于编排层永远不需要关心设备长什么样它只处理语义指令至于指令怎么变成红外脉冲、怎么以 HTTPS 请求发给车厂那是适配器自己的事。2.3 消息归一化把微信消息、设备事件、模型输出变成同一种“语言”Wanny 内部跑着一条消息总线所有进来的东西都会经过归一化处理统一转成一种内部消息结构source来源、type指令/查询/事件、payload载荷、request_id幂等标识。微信里发来“帮我把空调开到 26 度”会被转成上面那段 JSON车联网平台推送“充电已完成”也会被转成一个事件消息AI 模型想执行动作时同样通过这个结构返回。request_id是我在最早期就埋下的一个关键设计后来的很多坑都靠它兜底。因为微信回调、设备回调、HTTP Webhook 这些通道天然会重复投递消息如果没有一个全局唯一的 ID 做幂等你会发现某个指令被执行了三次还浑然不觉。这个字段后来帮我避免了一次“关灯被重复执行八次”的惨剧后面翻车现场章节里会细讲。2.4 本地优先与隐私边界哪些东西绝不出局域网在设计之初我坚持把所有家中的敏感数据留在本地设备状态、历史操作记录、语音指令文本全部放在家里的服务器上。云端的模型调用只有拿到“被允许发送”的消息内容才会发送到 API并且发送前会做一次脱敏——把地址、手机号、人名替换成占位符。这么做还有一个现实原因家里的网络偶尔会断如果整套系统依赖云断网时连灯都开不了就太蠢了。Wanny 的家电控制链路默认走局域网微信远程入口走自建网关网关断了也没关系只要人在家语音助手和 Web 面板照常可用。对于所有外部通道我只暴露必要接口并且在网关上做了双向证书校验宁可自己麻烦一点也不给外部扫描留口子。3. 微信接入实操企业微信通道、支付 V3、扫码登录和 Linux 端的真实踩坑3.1 第一道选择题个人微信还是企业微信每个人的第一反应都是“那我能不能直接把个人微信接入 Wanny”这里我给个非常实际的经验个人微信没有稳定开放的开发者接口靠自动化工具去挂协议不仅随时可能被封号而且逆向难度高不值得。我最终的选择是把消息通道放在了企业微信上——创建一个只有我自己的企业然后通过企业微信自建应用接收和发送消息。这个方案完全走官方 API稳定、合规而且架构上跟一个“智能客服机器人”完全一致生态成熟坑少。如果你只是个人使用企业微信自建应用和个人微信之间的体验差异其实可以接受。日常交互方式是我给 Wanny 发消息它在企业微信里回复同时 Wanny 也可以主动给我推通知比如“充电完成”“门锁异常”“天气预报”。微信生态里的支付和扫码登录则通过企业微信和公众号的能力实现——这是后面几节的重点。3.2 消息收发层的实现思路与格式约定接入企业微信应用消息核心就是两件事配置回调 URL 接收用户消息调用 send API 返回回复。回调 URL 必须是一个 HTTPS 地址并且要支持企业微信的签名校验机制——从 URL 参数里取msg_signature、timestamp、nonce和你自己配置的 Token、EncodingAESKey 做计算比对一致才处理。我踩过的第一个坑就是回调地址返回时间太长。企业微信要求服务器必须在 5 秒内响应否则会重试。而最初我在回调里同步调用了 AI 模型一次大模型推理轻松超过 5 秒企业微信就开始重复推送导致同一句话被模型处理了好几遍。后来我把流程改成先立刻返回“收到”再异步处理并把结果主动推送给用户这个问题才算根治。3.3 支付 V3、扫码登录与小程序的签名心得项目里有一个和微信支付相关的场景为了方便家里人使用部分增值功能比如月度汇总报告我接入了微信支付 V3。V3 和 V2 最大的区别在于全链路使用证书签名任何请求都需要用商户私钥对请求内容签名响应还需要用平台证书验签。很多教程不会强调的一点是V3 默认要求接口请求头里带上Authorization: WECHATPAY2-SHA256-RSA2048格式的认证头其中签名串的构建顺序非常容易出错。我建议直接用官方 SDK别自己手写但 SDK 版本要对准商户平台接口文档。扫码登录相对就轻松不少。企业微信扫码登录的标准流程是构造 OAuth2 授权链接带appid、agentid、redirect_uri和state参数用户扫码确认后企业微信回调你的跳转地址带上code后端拿code换用户身份。这里有个经验state参数一定要自己生成并校验能有效防止回调伪造。我是随机生成了带过期时间的一次性 state本地缓存校验通过后才继续。另外微信开发者工具里的“小程序签名”特别容易出问题。真机预览时如果报签名错误先看看是不是开发者工具里的 AppID 和密钥不匹配再看小程序的 request 合法域名有没有配置——别问我为什么提醒这个坑我蹲了两天。3.4 Linux 版微信、界面虚化与聊天记录迁移的杂症Wanny 的家用服务器是 Ubuntu 24.04所以我在 Linux 上装过微信 Linux 版 4.1.11。这个版本大部分功能正常但有一个非常难受的问题界面里的中文渲染成虚化模糊的状态。我先后试过调整字体渲染、设置环境变量最后发现最有效的组合是在启动时禁用 GPU 加速渲染并把缩放比例设为 1.0实测字体边缘清晰了很多。还有一次我在迁移系统时才发现微信的数据目录里保留着以前版本的聊天记录但新版客户端的导入入口藏得比较深。如果你也遇到类似情况先确认旧版本的聊天记录数据库文件还在再从新版客户端的设置里找到“迁移与备份”通过导入本地记录的方式恢复千万不要直接删旧目录。官方文档里对这一块的说明不够清晰我第一次没注意差点把几年的聊天记录都折腾没了。关于“伪造微信浏览器头信息”这个方向我也多说一句。早期我在 Web 端做过一个判断用户是不是在微信内置浏览器里打开页面的逻辑网上很多方案都是让你识别 UA 里是否包含MicroMessenger。我实测发现这玩意儿一点都不靠谱部分安卓定制 ROM 里的 UA 会被改写有些新版本甚至不再默认带这个字段。后来我彻底放弃了这种判断方式改用官方开放能力的 JSSDK 初始化结果来识别微信环境既稳定又安全。4. 家电接入红外遥控、智能设备 SDK 与 Home Assistant 的三档实战4.1 三种接入档位按设备情况选型家电这块我在 Wanny 里跑了三套接入方式按“顺手程度”排个序方案适用设备优点缺点推荐度Home Assistant 桥接支持 Wi-Fi 的主流智能设备生态全、有统一状态模型需要额外部署 HA 环境高智能设备官方 SDK/云 API米家、涂鸦等平台设备对接稳定、权限清晰不同平台协议不统一中高红外码库 万能红外棒老旧空调、传统电视、风扇等几乎通吃所有遥控设备无状态回读、码库需要学习中我家里最麻烦的是一个用了七八年的老空调没有任何 Wi-Fi 模块但制冷效果很好没理由换。最终方案是买了一个支持局域网 API 的万能红外棒放在客厅对着空调和电视的方向。红外棒本身有一个学习功能用原装遥控器对码红外棒记录下原始的时序码然后 Wanny 通过 HTTP 接口触发发射。4.2 没有状态回读的设备怎么保证“语义一致”这是整套家电接入里最大的难点。红外方案只能单向发码设备改没改变状态Wanny 完全不知道。比如你用原装遥控器把空调关了但 Wanny 内部还记着“当前 26 度制冷”就会说出错误的信息。我的做法是引入一个设备状态机每个没有回读能力的设备在 Wanny 里维护一份“推测状态”每次下发的指令都会更新这个状态用户如果手动操作设备需要在 Web 面板告诉它“我手动改了状态”或等它定时问你一次。这个方案不完美但在当前硬件条件下已经是性价比最高的解法。如果是带状态反馈的 Wi-Fi 插座、智能灯就尽量走带查询接口的协议优先使用真实的query结果覆盖推测状态。另外别小看发码时序。红外设备往往不能连续快速接收指令两声指令间隔至少要在 800 毫秒以上否则会丢码。我最初没有做过任何速率限制连续下发“调到 26 度、风量自动、摆风”三个指令时空调经常只执行了第一条。后来我在红外适配器里加了一个指令队列每条指令之间强制间隔 1 秒这个问题就基本解决了。4.3 场景联动的一个实战例子回家前的“不折腾”模板Wanny 最吸引我的地方就是可以基于规则做跨域联动。我写了一套简单的 ECA 规则引擎Event-Condition-Action事件源是“位置信息、时间、设备状态”条件是一堆比较表达式动作则是调用前面做的统一语义指令。一个我每天都在用的“回家”场景是这样的手机连接到小区 Wi-Fi 时Wanny 收到位置事件再过 3 分钟经过一个延迟确认机制确认我没有中途离开接着触发一连串动作客厅空调开到 26 度制冷、空气净化器开到自动档、热水器提前启动、车联网平台查询剩余电量并在电量不足时给我微信推送充电建议。这套逻辑如果用传统 App 的人工操作少说要 3 个 App 切来切去、花上 5 分钟Wanny 自动跑完也就 15 秒左右。对我不否认直接喊智能音箱也能做到一部分但那仅限于同一生态内的设备——车和微信这一个跨域动作智能音箱至今做不了。4.4 安全边界物理开关永远是最高优先级家电接入再多我有一条铁律没动摇过任何自动化都不能覆盖物理层面的安全保护。比如离家布防模式下Wanny 可以关闭灯光和插座但绝对不会自动执行“打开门锁”这种操作电热毯、烤箱这类高温设备我可以定时关但绝不接受 AI 自动开启。所有这些高危动作在规则引擎里被标成high_risk任何来源的指令想触达它们都必须经过人工确认环节。宁可在便利性上打折扣也不让“管家”变成隐患的来源。5. 汽车接入OBD、原厂 App 与开放 API 之间我做了什么取舍5.1 接入汽车的三档方案成本与风险天差地别汽车是 Wanny 跨域能力的重要一环。车联网这块我在调研时把方案分成了三个档次方案成本能力范围风险我的建议OBD 蓝牙/Wi-Fi 盒子低几十到几百发动机转速、电瓶电压、故障码、部分行车数据低只读为主适合老车、数据党原厂 App 私有接口无需硬件与原厂 App 几乎一致中高接口未公开、随时会变不推荐长期依赖车厂开放平台 API视厂商而定官方定义的车辆状态与远程控制低平台可控最推荐优先选择很多朋友会建议我走第二条路抓原厂 App 的包、模拟请求从而拿到车锁、空调、充电桩的远程接口。我确实也做过短期实验也佩服那些逆向做得精细的作者——但对个人项目来说这套方案的脆弱性太高了原厂随手改一个接口签名整个适配器就得重写而且一旦涉及敏感功能接口的权限边界根本说不清万一操作出问题责任完全是自己的。所以最终 my recommend 是只要你的车厂提供任何形式的开发者接口或开放平台就优先用官方能力接入没有开放平台就老老实实停在 OBD 只读数据这个档位远程控制宁可手动去 App 里操作。5.2 我为什么没碰 VCU 和控制类接口功能安全视角在做调研的时候我翻了不少关于汽车 VCU整车控制器设计方案和功能安全的内容。ISO 26262 标准里有一个技术安全概念TSC它是在安全需求分析阶段把功能安全需求细化成技术安全需求的步骤背后那一整套“失效会导致什么后果”的分析思路对个人做车联项目的启示非常大。一辆车的转向、制动、动力控制属于整车控制单元管辖的高安全等级功能任何外部系统都不应该直接插手。哪怕技术上存在绕过车辆网关直连 CAN 总线的方案——这个在大学生智能汽车竞赛和点云数据处理圈里我也常看到类似的做法——也绝对不适合在个人项目上使用。我可以读取车辆的充电状态、位置、剩余续航这些是数据层面的交互但任何会对真实行车轨迹产生影响的控制指令比如远程启动、泊车挪动、OTA 触发我个人建议不碰也不建议你碰。智能网联汽车相关的安全通行规范越来越强调“车-路-云”协同下的边界清晰个人开发者在这一点上更要有敬畏心。5.3 实际用起来的三个高频场景目前 Wanny 里和汽车相关且稳定的功能集中在三个场景。第一个是充电提醒当车在充电时Wanny 每隔一小时通过开放 API 查一次电量到达 80% 或 100% 时通过微信给我推消息。这件事原厂 App 虽然也有通知但经常延迟或者收不到Wanny 自己轮询之后可以做到基本准时。第二个是到达联动手机定位显示我距离家 1 公里以内时自动提前开启家里空调和灯光。第三个是异常位移通知车辆在非我授权时段出现位置变化Wanny 会立刻给我发微信报警——这个仅仅依赖官方接口的vehicle_location上报功能取数逻辑不复杂但非常有价值。我也考虑过用 OBD 盒子读取电瓶电压来判断车是否需要启动补电但折腾了一阵发现 OBD 设备在停车后会持续耗电反而可能把电瓶亏空最终这个功能被我搁置了如果要做必须选择低功耗模式且定期休眠的硬件。5.4 智能汽车竞赛和行业规范给我的一些启发在调研过程中我专门看了全国大学生智能汽车竞赛的竞速规则和不少获奖方案。里面那些学生在传感器标定、路径规划上做的优化思路很值得借鉴——虽然他们玩的是赛道模型车但对执行机构的响应延迟、任务优先级设计跟真实车辆的控制系统是一脉相承的。尤其他们如何设计“失效安全”如果感知模块掉线车会怎么减速、怎么靠边这种思维模式放在个人智能管家里也同样适用——某个适配器挂掉时Wanny 应该怎么降级而不是瞎执行。这也是我始终坚持“决策与执行分离”的原因之一。6. AI Agent 编排function calling、模型路由和“决策与执行分离”6.1 从闲聊到干活关键的转折点是 function calling最早我想把大模型接进 Wanny 时采用的是“让模型输出一段 JSON然后我解析执行”的方式效果很不稳定。有时候模型会把参数名改掉有时候会在一段回复里夹带多个指令解析逻辑怎么写都别扭。后来换成了标准的 function calling工具调用情况才彻底改观。在 function calling 模式下我向模型声明一个叫control_device的工具描述它支持的参数设备名、动作、参数、优先级等。模型理解了用户消息“把空调调到 26 度”后不会再硬憋一段中文而是返回一个结构化的工具调用请求。{ function: control_device, arguments: { device: air_conditioner, action: set, params: { mode: cool, temperature: 26 } } }Wanny 的编排层收到这个调用请求后不是直接执行而是先过规则引擎校验再交给适配器执行。执行结果会作为一条工具消息回传给模型让它基于真实结果组织给用户的回复。这一步做完之后AI 从“聊天机器人”跃迁成了“能做事的 Agent”。6.2 本地模型与云端模型的分工路由决定成本AI 模型调用是 Wanny 里最烧钱和最高延迟的环节。我的做法不是简单地把所有请求都丢给云端而是采取分级路由第一级本地小模型Ollama 跑的轻量模型先对用户指令做一次快速分类判断这是“闲聊”、“设备控制”还是“信息查询”。第二级“设备控制类”请求直接走本地规则解析根本不经过大模型又快又省。第三级只有“闲聊”和需要复杂理解的“信息查询”才走云端大模型 API。这样一个设计让 Wanny 的响应速度基本稳定在 1 到 2 秒内。如果每个请求都等云端大模型返回延迟随随便便三五秒起步微信体验会很糟糕。而且本地模型对用户隐私更友好离线也能做基础控制。6.3 智能决策必须套上规则兜底AI 只负责理解不负责冒险我对 AI 的定位很明确它可以把模糊的自然语言转成结构化的操作意图但最终能不能执行要由编排层的规则引擎来决定。比如模型理解了“我今天不想开空调”之后返回了一条关闭空调的指令规则引擎会先检查当前室内温度、设备状态再决定是否执行。这里还有一张“禁止动作表”包括给陌生人下发一次性临时密码、取消布防模式、远程开锁这类高危动作任何来源的请求都必须进入人工二次确认队列。这一点我是在吃过亏之后才坚定的。有一回朋友在微信上开玩笑说“要不我远程开一下你家的门”本地模型把这句话理解成了一个设备控制意图差点就要触达门锁。虽然最终由于我的高危操作需要人工确认而拦住了但那次之后我立刻把所有涉及门锁、告警、支付的动作全部移出 AI 自动执行范围。AI 可以做万能的理解者但不能做不受约束的执行者。6.4 上下文管理塞全文给模型不如给一张“设备状态卡”对 Agent 来说上下文窗口的使用也是一门学问。一开始我把设备历史记录全塞进 prompt既费 token 又容易让模型抓不住重点。后来我改成了一种“状态卡片”方式每次注册工具调用前自动把当前所有在线设备的状态压缩成一段摘要比如“客厅空调 26 度制冷中、书房灯关闭、空气净化器自动档、车辆电量 85% 充电中”。这些摘自真实query状态的数据比历史消息列表更能帮助模型做出情景化回复同时还省了一大半 token 开销。会话记忆方面我在本地用 SQLite 存了最近 20 轮对话摘要配合固定格式的“临时记忆”字段让模型处理需要连续上下文的问题时不至于失忆。如果你的使用场景更重问答可以考虑接向量数据库但至少在我当前的需求下SQLite 的轻量方案已经足够。7. 稳定运行三个月后高频指令、翻车现场与选型清单7.1 高频指令数据哪些功能是“真香”哪些是“摆设”Wanny 稳定跑了三个月后我拉了一下后台记录梳理出用户侧其实就是我自己和家人真正每天都用到的功能功能调用次数日均使用评价微信查车/充电提醒6-8 次真香基本离不开了远程开关空调4-5 次夏天刚需回家场景联动3-4 次自动化后就忘了它的存在这才是成功AI 闲聊与信息查询2-3 次偶尔用不算高频家电耗电统计1 次/天我自己看的多家人不怎么看有意思的是一开始我花了大力气做的“AI 自然语言对话控制”反而是低频功能。大家更习惯固定句式比如“打开客厅灯”“空调 26 度”很少会对着它长篇大论。这说明语义理解这种能力做后备就好真正的核心是把那 20% 的高频操作做到极致稳定。7.2 三个典型翻车现场每个都值得你记笔记第一个翻车是空调“假回读”误导用户。当时我用红外方案控制空调但因为红外设备没有状态回读Wanny 只能靠“推测”。有一天家人用原装遥控器把空调关了Wanny 不知道AI 还信誓旦旦地回复“空调已调到 26 度模式”。后来的修复就是前面那张状态机所有无回读设备在受控情况下尽量避免 AI 断言回复里统一加上“已发送指令但该设备没有状态回读请确认实际运行状态”。第二个翻车是企业微信回调重复推送导致指令重复执行。有一次我发了一条“关掉书房灯”结果企业微信回调网速抖动平台重试了三次Wanny 连续执行了三次关灯。因为灯已经是关的表现不明显但换成风扇这类设备就会很伤硬件。修复就是前面提到的request_id幂等表相同 ID 的消息在 10 分钟内只处理一次。第三个翻车是汽车 API Token 过期导致充电提醒失效。车联网开放平台的 access_token 有效期是 7 天我最初只在启动时获取一次结果第 8 天开始充电通知就断了我隔了一天半才发现。修复方式是每个适配器自己维护 access_token并且对所有 401 响应统一做“刷新令牌 重试一次”的处理。这不算复杂但没有自动刷新机制几乎必然会在某个周日晚上突然失灵。7.3 硬件与软件选型清单如果你也想复刻一个类似系统我的选型可以作为起点主机用一块功耗较低的 x86 迷你小主机N100 级别即可内存 16G跑 Ubuntu 24.04软件栈用 Node.js 做微信接入和 HTTP API、Python 做 AI Agent 编排和模型路由、SQLite 做存储设备侧用 Docker Compose 统一管理容器红外棒选支持局域网 API 的品牌Home Assistant 直接官方容器起就行。这套组合的成本大概在几百到一千出头比买一堆独立智能家居网关便宜而且能统一管理。8. 接下来我还想让它学会的几件事Wanny 目前的状态并不是终点。接下来我自己在琢磨两个方向一个是把“固定位置触发联动”升级成“预测性联动”比如根据日历、天气和充电状态提前判断明天早上需不需要热车另一个是给 AI 层加入更细的“记忆”能力让它能记住家庭成员的偏好而不是每次只理解单条指令。如果你也想做一个类似的东西我最诚恳的建议是千万别一开始就想着把微信、家电、汽车、AI 全打通先跑通一个你每天都会用的小场景比如“微信远程开关空调”等这条链路真的稳了再往外面扩。超级管家不是一步到位的它是在一次次修修补补里慢慢长出来的。