1. 项目概述：当衣柜开始自己“换季”
每年换季的时候，我家里那个双开门衣柜就要经历一次大工程——把夏天的T恤收进去，把冬天的羽绒服翻出来，顺便还要检查有没有发霉、有没有被虫蛀。这个场景想必很多人都不陌生。所以当我开始琢磨“AI Agent在智能衣柜中的季节性整理建议”这个项目时，最初的想法特别朴素：能不能让衣柜自己告诉我们，什么时候该换季、哪些衣服该收、哪些该留、还缺什么。
作为一个常年折腾智能家居方案的开发者，我对嵌入式设备、传感器和云服务之间的协作并不陌生。但真正动手做这个项目之后才发现，把“整理建议”这件事做成一个真正有用的AI Agent，远比我预想的复杂，也远比想象中更有意思。它不是一个简单的“智能衣柜APP”，而是一个完整的软硬件闭环系统：衣柜内部部署RFID识别模块、温湿度传感器、重量传感器和摄像头，边缘网关负责数据汇聚，云端则运行着一个具备记忆和推理能力的AI Agent。
这个Agent能综合利用衣柜内的衣物数据、当地天气预报、用户日程以及历史穿着记录，在季节交替之前主动给出整理建议。比如“未来一周气温将持续低于10℃，建议将夏季衣物收纳到上层储物格，同时抽出羽绒服和厚外套”，或者“湿度连续三天超过75%，建议打开除湿模块，并检查是否有发霉风险”。它不只是输出一条固定的提醒，而是能够结合上下文动态调整建议内容和优先级。
这个项目适合谁参考？我觉得有三类人会很受用：一是做智能家居或消费电子方向的开发者，想了解AI Agent如何嵌入具体的物理场景；二是对RFID、传感器等物联网技术有兴趣，想看看这些设备如何配合AI做决策的爱好者；三是有一定智能家居经验、想提升生活品质的用户——哪怕你不想自己动手开发，了解这个系统的能力边界和逻辑原理，也能帮你在选购相关产品时少踩坑。这篇文章我会把整个项目的设计思路、系统架构、核心实现、部署细节和踩坑记录都过一遍，信息量比较大，建议收藏后慢慢看。
2. 系统架构与核心模块拆解
2.1 感知层：衣柜怎么“看见”衣服
做这个项目遇到的第一个问题很现实：衣柜怎么知道里面放了什么衣服？这不是一个可以拍脑袋决定的问题，它直接决定了整个系统能不能跑起来。我对比了几种方案，各有各的利弊。
第一种是用摄像头做视觉识别。听起来很直接，衣柜里装个广角摄像头，每次开门拍一张照片，用目标检测模型识别衣物类型和颜色。但实际上问题很多：衣服叠在一起遮挡严重，深色衣服在柜内暗光环境下识别率惨不忍睹，还有隐私顾虑——谁也不想自己卧室的衣柜里长期挂着一个摄像头。我测试过几轮，最终放弃了这个方案作为唯一识别手段。
第二种是RFID标签方案。给每件衣物缝一个RFID标签，衣柜内固定位置布置RFID读写器天线，通过标签的唯一ID关联衣物信息。这是目前服装行业仓储管理里非常成熟的做法，识别稳定、不依赖光线、没有隐私问题。唯一的门槛是标签需要一一绑定衣物，录入成本高，而且部分面料（比如含金属纤维的）会屏蔽信号。
第三种是重量传感器配合门磁。在衣杆两端和储物隔板下方装压力传感器，通过总重量变化推断衣物的增减。这个方案精度不高，但能做辅助验证——比如Agent建议用户“取出3件厚外套”，系统可以通过重量变化判断用户是否真的照做了。
我最终采用的是“RFID为主、重量传感器为辅、摄像头仅用于拍照记录穿搭”的组合方案。RFID读写器采用超高频（UHF）频段，单天线覆盖范围大约1.2米，实测在60×60×120cm的衣柜空间里，只要衣物的标签不是被金属衣架完全遮挡，识别率能到95%以上。门磁传感器用来判断开门事件，触发识读流程而不是让读写器一直高频扫描，这样既省电又能减少误读。
提示：RFID标签选型上，我建议直接用服装行业用的洗涤标签，封装在纺布内，可以缝进衣物内侧缝边，正常洗衣机洗涤几十次没问题。那种硬质卡片的标签不适合衣物场景，弯折几次就废了。
2.2 数据层：衣物档案如何建模
感知层拿到的是RFID标签的“电子编码”，这串编码本身没有任何意义，必须和衣物信息数据库关联起来，才能变成Agent可以推理的语义数据。这里的数据建模决定了Agent的“智商上限”。
我设计了一套衣物信息模型，每条记录包含以下核心字段：
- 基本信息：类型（上衣/下装/外套/鞋/配饰）、品类（T恤/衬衫/卫衣/风衣/羽绒服）、颜色、材质、尺码
- 季节属性：四季/春夏/秋冬/夏季/冬季，这个字段不是死的，而是带置信度的权重，比如“轻羽绒”标记为冬季0.8、春秋0.2
- 穿着场景：通勤/休闲/运动/正式/居家，支持多选
- 当前状态：在柜/已取出/待清洗/已收纳
- 收纳位置：上层A区/下层B区/挂杆C区/抽屉D区
- 使用记录：最近穿着时间、累计穿着次数、洗涤次数
这个模型用JSON格式存储在本地数据库里（我用的SQLite），云端的Agent通过API读取。录入衣物时，不需要手动填写全部字段——你只需要扫描标签，然后对Agent说一句“这件是一件黑色的薄款羽绒服，主要冬天穿，也可以春秋当外套”，Agent会自动解析这句话，把信息写入结构化字段。这一步是AI Agent的核心价值之一：它把自然语言直接转换成了机器可操作的数据，省掉了传统录入方式里繁琐的表单填写过程。
我在实际使用中还加了一个“穿着上报”机制。衣柜门上的触控屏（或者手机APP）会在你取出衣物时弹出一个快捷确认：“是否穿着这件XXX？”一键确认后，系统记录穿着日期、时间、天气情况。这些数据累积起来，就是Agent学习你穿衣偏好的基础语料。没有这一层数据，Agent永远只是纸上谈兵，给不出贴合你个人习惯的建议。
2.3 决策层：Agent的推理链路设计
如果说感知层和数据层解决的是“看见”和“记住”，那么决策层要解决的是“思考”。这也是本项目里最大的设计挑战。
传统智能家居的自动化逻辑通常是“if-else”规则——比如“如果温度低于5℃，且湿度高于70%，则推送除湿提醒”。这种规则系统简单可靠，但它无法应对复杂的、上下文相关的决策场景。换季整理这件事，恰恰是典型的复杂决策：需要考虑温度趋势、湿度变化、衣物分布、用户日程、历史偏好、存储空间、甚至衣物状态（是否需要干洗）等多重因素。规则系统如果要覆盖所有组合情况，规则数量会爆炸式增长，而且难以维护。
所以我选择的方案是：用大语言模型作为Agent的推理核心，加上工具调用（Function Calling）机制，让它能主动查询各类数据源。这个设计借鉴了目前在智能体领域比较成熟的ReAct模式——推理-行动-观察的循环。
具体来说，Agent在接收到“生成季节性整理建议”的任务后，会执行以下几步：
- 调用天气API，获取未来7天的逐日天气预报，包括最高/最低温度、湿度、降水概率
- 调用衣物数据库接口，查询当前衣柜内的衣物分布情况
- 调用穿着记录接口，分析最近两周的穿着偏好
- 调用日历接口（如果用户授权），了解接下来一周的重要日程
- 基于以上所有数据，推理出换季判定、整理优先级、具体建议
每一步的中间结果都会进入Agent的“思考链”，最终生成的结构化建议通过消息队列推送到用户端。这个链路里最关键的一点是：Agent不是一次性把建议吐出来，而是先查数据、再推理、再输出，每一步都有据可依。
注意：这里要区分“AI Agent”和“聊天机器人”的本质差别。聊天机器人只负责对话，而Agent有自主调用工具、获取外部数据、执行动作的能力。在我这个项目里，Agent不仅是“说话”，而是真正去查天气、查数据库、推算趋势，然后才给出建议。
3. 季节性整理的核心逻辑与实现
3.1 季节判定：不靠日历靠数据
很多人第一反应是：换季整理难道不是看日历就行？3月换春装、6月换夏装、9月换秋装、12月换冬装，这有什么可智能的？
问题在于：日历上的季节和体感上的季节根本不是一回事。我所在的城市，3月中旬气温能到20℃，但一场冷空气就能打回5℃；10月国庆节还在穿短袖，11月突然就要开暖气了。如果按固定日期来做换季整理，要么收早了冻得发抖，要么收晚了衣柜塞不下。
所以这个项目里的季节判定，我采用了“气象学季节”的思路，结合未来一周的温度趋势做动态判断。具体逻辑如下：
- 连续5天日平均气温稳定低于10℃，判定进入冬季整理模式
- 连续5天日平均气温稳定超过22℃，判定进入夏季整理模式
- 10℃到22℃之间的过渡期，判定为春季/秋季模式
这个阈值来自气象学的季节划分标准，准确度高。但我更进一步：Agent不只依赖历史气温，还会结合天气预报看未来趋势。比如现在日均温度已经降到12℃，但未来三天有升温趋势，Agent就不会急着推送“全面换冬装”的建议，而是先提示“冷空气即将到来，建议准备2-3件厚外套备用，暂不需要大规模收纳”。
温度不是唯一的判定维度。湿度对换季整理的影响也很大：南方梅雨季和回南天，衣柜内湿度经常超过80%，这种情况下哪怕温度到了换季标准，Agent也会把“除湿防潮”作为优先级最高的建议，而不是着急让你收纳衣物。我在系统里设置了湿度告警联动：当柜内湿度连续24小时超过75%时，自动启动衣柜内置的半导体制冷除湿模块，并把状态通知发给用户。
除了温度和湿度，还有两个不那么显眼但很重要的信号：衣物使用频率变化和紫外线强度变化。Agent会监测“最近7天哪些衣物被取出频率最高”，如果羽绒服的使用频率突然下降、而薄外套的取出次数上升，这就是一个比天气预报更真实的换季信号。紫外线强度则影响防晒衣、墨镜这些季节性配饰的推荐优先级。
3.2 建议内容生成：不只是“该收衣服了”
生成建议这件事，最忌讳的就是千篇一律。让Agent在不同的场景下给出有差异化的、可执行的建议，需要精心设计输出格式和内容逻辑。
我定义了三种建议类型：整理类、维护类、补充类。
整理类建议聚焦“收什么、拿什么、放哪里”。Agent会根据衣物数据，比对当前季节属性和下一季度的需求，列出需要收纳的衣物清单和需要取出的衣物清单，并标明它们在你衣柜里的具体位置。比如“把挂杆C区的3件薄款风衣收纳到上层A区储物箱，把抽屉D区的保暖内衣取出放到挂杆下方收纳盒”。这种建议做到了位置级别的精确性——因为每件衣物在录入时都绑定了收纳位置，Agent完全可以给出物理坐标级的指导。
维护类建议关注衣物的健康和寿命。这部分很容易被忽略，但实际价值很高。比如“上周你连续穿了两次那件羊毛大衣，建议尽快干洗，否则汗渍残留容易招虫”，或者“柜内湿度偏高，已经有2件棉质衣物检测到轻微受潮迹象，建议启用除湿模块并把樟木条放到下层B区”。这些建议依赖的是长期累积的穿着记录和传感器数据，普通的换季提醒工具根本做不到。
补充类建议则是“你缺什么”。Agent分析当前衣物覆盖度，结合未来天气和用户日程，给出购买建议。注意这里不是无脑推销——Agent会明确指出缺失的具体品类和理由，比如“下周气温预计降至0℃以下，但你衣柜里没有厚羽绒服，只有两件轻薄款。建议考虑补充一件长款厚羽绒服，预算不够也可以先用现有薄款叠穿过渡”。这种建议有推理过程、有可行性判断，用户才会觉得靠谱。
建议的优先级排序也有讲究。我把所有建议按“时效性-影响度-难易度”三个维度打分排序：对未来3天有影响的建议排在前面，影响范围大的（比如全柜整理）排在单件衣物处理之前，操作难度高的建议后面。用户每天只会收到2-3条最值得处理的通知，而不是一打开APP就看到二十条建议刷屏。
3.3 建议落地的联动执行
Agent给建议只是第一步，怎么让用户“少动手”甚至“不动手”，才是智能衣柜和普通衣柜的本质区别。这个项目里我做了一些落地联动，虽然还称不上完全自动化，但已经能明显减少换季时的工作量。
首先是自动化的环境调节。衣柜内部集成了除湿模块和温控风扇，Agent判定即将进入潮湿季节时，会自动调整除湿策略：从“有人开门时启动”改为“24小时低功率运行”，同时通过智能插座联动家里的小型抽湿机。用户不需要做任何操作，衣柜里的环境就已经被提前控制住了。
其次是整理流程的引导。当Agent判定需要大规模换季整理时，它不会甩给你一张长长的清单就完事，而是会把整理任务拆解成多个小步骤，引导用户一步一步完成。衣柜门上的触控屏会显示引导界面：第一步“取出夏季衣物”——此时RFID识别系统实时监测，每当你取出一件衣服放进旁边的整理篮，屏幕上的清单就会减少一项，并自动记录这件衣服已经被收纳。这种交互方式把原本枯燥乏味的换季整理变成了一个有完成感的流程，实测下来我老婆都愿意主动用了。
最后是和外部分类垃圾桶、洗衣机的联动。整理过程中识别到需要干洗的衣物，Agent会标记出来，并推送洗衣机的“羊毛洗”“真丝洗”模式建议；识别到带有RFID标签的旧衣，还能生成回收清单。这些联动需要额外的设备和协议对接，不是所有场景都能做，但架构上预留了接口，后续扩展很方便。
实操心得：自动联动一定不能做得太激进。我做第一版的时候设了“检测到衣物受潮自动开启烘干”的规则，结果有次一件衣服还没完全晾干就放进衣柜，系统直接判定受潮并启动了长时间烘干，耗电不说还差点把衣服烤变形。后来我把所有涉及“可能造成不可逆后果”的动作，都改成“建议+一键确认”的模式，只有无风险的环境调节才允许全自动执行。
4. 部署实操与调优记录
4.1 硬件选型与安装要点
这个项目的硬件清单并不复杂，但每一样东西的选型都有讲究。我用的核心硬件包括：
- 边缘网关：基于ESP32-S3的定制主板，负责汇总传感器数据并通过WiFi上传云端。选ESP32-S3是因为它自带2.4G WiFi和BLE，接口丰富，IO引脚够用，而且支持本地跑轻量级的语音唤醒（后续可以扩展“对着衣柜说话”的场景）
- RFID读写器：UHF频段模块，外接柔性天线，固定在衣柜内部侧板上。建议天线位置不要正对金属挂杆，否则会形成反射干扰。我调试时发现天线离挂杆最近的地方识别率反而最低，后来把天线斜45度安装在柜门内侧，识别效果最好
- 传感器：DHT22温湿度传感器两个（柜内上部一个、下部一个）、门磁传感器一个、压力传感器四组（挂杆两端各一组、储物隔板下方两组）
- 触控屏：4.3寸电容屏，通过串口和网关通信，显示整理引导界面和Agent建议
安装时最需要留意的是RFID天线的位置调校和防干扰。衣柜里的金属衣架是最大的干扰源，我测试了三种衣架（金属、木质、塑料），金属衣架会让标签读取率直接下降20%左右。如果你不想全部换掉金属衣架，可以通过提高读写器功率来部分补偿，但要注意功耗和发热的问题。我的折中方案是挂杆区用木质衣架，叠放区随便。
网络架构上，我在本地跑了一个Mosquitto MQTT Broker作为设备通信中枢，传感器数据通过MQTT发布到指定Topic，边缘网关订阅这些Topic并做简单的数据清洗，然后通过HTTP API把结构化数据同步到云端。本地MQTT的好处是断网时衣柜的自动化规则还能跑（本地规则引擎），只是AI Agent的建议功能会暂时停用。
4.2 衣物数据录入的高效姿势
这是我踩坑最多的地方。最开始我设计的是“扫描标签→手动填表”的录入方式，结果录到第30件衣服就崩溃了——一件一件填写类型、颜色、材质、季节属性，每件至少一分钟，整个衣柜几百件衣服，光是录入就要好几个小时。这也是很多类似项目烂尾的根本原因。
后来我彻底改用“对话式录入”：在手机APP或触控屏上，对着Agent说自然语言描述，由Agent解析并写入数据库。比如你说“这件是蓝色的牛仔衬衫，春秋穿，通勤休闲都可以”，Agent会自动提取：类型=上衣，品类=衬衫，颜色=蓝色，材质=牛仔，季节属性=春秋，穿着场景=通勤/休闲。生成结果回显给你确认，没问题就点保存。实测单件录入时间从60秒左右降到了8秒，准确率在90%以上。
如果你不想依赖AI解析，还有半自动方式：在录入界面选择“拍照识别”，把衣服平铺拍一张照片，Agent用多模态能力识别颜色和品类，加上你的语音补充说明，组合成记录。这种方式适合那些材质比较特殊、难以用文字描述的衣服。
录入时还有一个容易忽略的细节：收纳位置字段。每一件衣物都要关联一个“当前存放位置”——这不仅是整理建议的基础，也是后续RFID寻找功能的依赖。我的经验是记到“哪一层哪个区域”这种粒度就够了，不用精确到单个格子，否则调整收纳格局后维护成本太高。
4.3 Agent提示词与参数调教
AI Agent的智能程度，很大程度取决于你给它配置的“人设”和工作流程。这个项目里我用的是有工具调用能力的API，通过系统提示词定义Agent的角色行为。
我的系统提示词核心内容大致如下：
你是一个智能衣柜整理助手，负责为用户提供季节性衣物整理建议。 你的工作流程： 1. 依次调用天气查询、衣物数据查询、穿着记录查询、日程查询工具 2. 根据温度趋势判断当前季节阶段 3. 比较当前衣柜衣物分布与季节需求，找出缺失和冗余 4. 结合湿度数据和穿着记录，判断是否有维护类需求 5. 按“时效性、影响度、难易度”排序输出建议，每条建议必须有具体位置信息和理由 6. 如果数据不充分，必须明确说明不确定的部分，不要强行给出建议 注意：不编造衣物存在，不编造天气数据，建议要具体到位置层面。这段提示词里最关键的是最后一条：“不编造数据”。大语言模型有一个本能，就是在信息不足时会“脑补”合理但不真实的内容，这在智能家居场景里是非常危险的——如果Agent编造了一件你根本没有的衣服，然后建议你“把这件大衣送去干洗”，用户信任感就瞬间崩塌了。所以我在Agent推理链路的前面加了一层数据校验：Agent输出的每个衣物ID必须出现在查询结果的返回列表里，否则这条建议会被拦截。
温度阈值参数也要因地制宜。我把气象学的季节判定阈值做成了可配置项，放在云端配置中心。南方用户和北方用户的阈值可以不同——比如广东用户可能觉得“25℃以上才算夏天”，而东北用户可能“15℃就可以穿短袖了”。通过长期穿着记录，Agent可以自动微调这些阈值，让它更符合用户的真实体感。这个“自适应阈值”功能上线后，建议的准确率明显提升，用户反馈“终于不用被傻傻的建议烦到了”。
5. 常见问题与排查技巧实录
5.1 换季误判的常见原因
在项目测试期间，误判是最大的问题来源。这里说的误判包括：该换季时没给建议、不该换季时频繁提醒、以及给出的整理方向完全相反。
我排查下来最常见的三个原因：
第一是温度数据源的问题。免费天气API的数据精度参差不齐，有些接口返回的是城市中心的气温，和用户所在郊区的实际温度能差3-5℃。尤其是那种“城市范围很大”的地区，一个API返回的温度可能是城南的数据，而用户在城北。解决方案是接入两个以上的天气数据源做交叉验证，取中位数；或者用周边3公里内的个人气象站数据（如果有的话）做校准。
第二是阈值设置太死板。如果判定“连续5天低于10℃才算入冬”，那你永远不会在“正合适”的时候收到换季建议——等到连续5天低于10℃的时候，你已经冻了好几天了。我后来加了一个“预判窗口”：当未来3天预报中至少有2天低于阈值，就提前触发“预备建议”，提醒用户先把厚衣服准备出来。这比等到温度真的稳定下降再提示要人性化得多。
第三是忽略了柜内温度和室外温度的差异。冬季衣柜内部的温度通常比室外高3-5℃，如果Agent只拿柜内传感器数据做季节判定，就会得出“还不冷”的错误结论。一定要明确区分“柜内环境数据”和“室外气象数据”两个数据源：柜内数据控制除湿、防潮等环境策略，室外数据用于季节判定和穿着建议。
5.2 识别率上不去怎么办
RFID识别率是个让人又爱又恨的话题：调好了能到98%，调不好就40%。我调试过程中总结了几个关键点。
天线位置是第一要素。RFID天线有方向性，标签的朝向和天线的夹角越接近90度，读取效果越好；夹角越小（也就是说标签面几乎平行于天线面），读取越困难。衣柜里衣物挂放时，标签又是缝在衣服内侧的，朝向完全是随机的。所以我在衣柜内部署了两组天线：一组在柜门内侧，一组在柜体侧面，双天线交叉扫描。这个改动把读取率从72%提升到了91%。
标签粘贴位置也很讲究。对于需要频繁洗涤的衣服，标签要缝在领口内侧或侧缝这种不容易被掰折的位置；对于不常洗的外套，可以直接用硅胶套方式挂在衣架环上，读取效果更好。但要注意，如果标签离金属拉链、金属纽扣太近，信号会被严重衰减，这些位置要避开。
还有一个隐藏问题：RFID标签本身的质量。市面上几毛钱一个的标签和一两块钱的标签性能差距很大。我在测试中买过一批低价标签，前几次读取正常，但过了大约十次洗涤后，天线部分就开始断裂，识别率断崖式下降。做这个项目，标签上不要省那几块钱，买正规渠道的服装洗涤标签，稳定性靠谱很多。
最后，识别策略要设计成“按需触发而不是持续轮询”。我的做法是：门磁检测到开门动作后，延迟2秒启动读头，持续扫描10秒，采集多次识别结果做去重合并；关门后再做一次短扫描，对比前后差异，推断“取出了什么/放回了什么”。这个策略比让读头7×24小时高频扫描的准确率高很多，而且省电。
5.3 建议“太傻”怎么办
很多用户（包括我自己）一开始对AI的建议期待很高，结果发现Agent经常给出一些“正确的废话”——比如“温度低建议穿厚一点”，这就让人很失望。这个问题的根源不在模型，而是上下文信息不足。
第一版系统中，Agent能看到的衣物信息只有类型、颜色、材质这些静态属性，它根本不知道用户今天要出席什么场合、有什么偏好。说白了，它就是“盲猜”。解决方法是把前面提到的穿着记录系统做起来，让Agent知道“用户在过去的30天里，工作日的早上8点到9点之间，穿深色衬衫的概率是70%”。有了这个历史信息的加持，建议就变得具体起来了：“明天是周三，有雨，气温14-18℃。根据你过去的穿衣习惯，你通常会穿深色长袖衬衫加薄外套。衣柜里那件藏青色衬衫目前是待清洗状态，建议选另一件灰色衬衫，搭配角落那件卡其色风衣。”
第二个调教方向是增加“反馈闭环”。每条建议下面都加了两个按钮：“有用”和“没用”。用户点击的结果会实时反馈给Agent，作为下一次推理的参考。一开始我没有做这个闭环，Agent反复推荐同一件用户并不喜欢的衣服，后来加入反馈后，Agent会逐渐降低那些“被点没用的衣服”的推荐权重。这个机制跑了大概两周，建议的采纳率从42%提升到了67%。
第三个经验是：不要试图让Agent一次搞定所有事。我最初设计的Agent同时负责换季整理、穿搭推荐、购物建议、洗衣提醒，结果发现它每条都做不好。后来按照“单一职责”原则拆分了三个Agent：整理Agent专门负责换季的收纳决策，穿搭Agent只做每日推荐，维护Agent管除湿、干洗提醒。三个Agent之间通过共享数据库协作，但各自的提示词更精简，分工更明确，效果立竿见影。
6. 沉淀下来的几点经验
这个项目从最初的想法到能稳定运行，前后花了大概四个月时间。中间推翻重来了两次，一次是因为识别方案选错，一次是因为Agent工作流设计过于复杂。回头总结，有几点经验想分享给正在做或者想做类似项目的朋友。
第一，智能家居项目里“数据闭环”比“智能算法”重要得多。AI Agent再聪明，没有持续、可靠、高质量的数据输入，它就是空中楼阁。我见过很多项目把精力花在调模型上，却忽略了最基础的“用户是否愿意使用这个系统”。你设计的使用流程必须足够省事——比如用自然语言录入衣物、开关门自动触发识别、一键确认穿着记录——用户才愿意持续用下去，数据才会积累起来，Agent才会越来越聪明。
第二，安全底线不能妥协。涉及衣物的处理动作，我始终坚持“不可逆操作必须人工确认”的原则。除湿、通风这类无风险的环境调节可以全自动，但烘干、熨烫、折叠这类可能损坏衣物的动作，一律只推送建议，让用户自己决定。这个原则不只是在衣柜项目里适用，任何智能家居场景都应该遵守。
第三，这个项目还有很多可以扩展的方向。我目前正在研究的是引入更丰富的穿衣场景数据——比如把手机上的日历日程和天气数据结合，生成“出差一周的行李箱打包清单”；还有通过衣物的累计穿着次数和洗涤次数，推算衣物的剩余使用寿命，提醒用户及时更换。如果再把多模态识别能力加强，让Agent能“看懂”衣服的破损和污渍情况，那就更接近一个真正懂衣物的智能管家了。
我个人在这个项目里最大的收获，其实是重新理解了“智能”两个字。真正的智能不是能听懂你说话，也不是能查出天气预报，而是能把这些零散的信息组合起来，在你没开口之前，把最合适的那件衣服、最合理的那个整理方案，提前放到你面前。这个目标目前只能说完成了一部分，但方向是对的。如果你也在做类似的尝试，希望这篇文章能帮你少走一些弯路。
