鸿蒙AI穿搭应用实战：ArkTS数据模型、大模型调用与本地规则兜底

鸿蒙专家

一、痛点与产品定位

“今天穿什么”看似简单，实际涉及温度、降雨、场合、衣橱状态等多重约束。传统衣橱App只做记录，天气App只提供信息，两者之间缺少决策层。“衣见倾心”将问题定义为轻量级个人决策场景：从用户已有、状态可用的衣物中组合，返回衣物ID、推荐理由和护理提示，并引入本地规则限制温度、状态等硬约束，让模型在约束内做风格协调与语言解释。这正契合鸿蒙应用智能化实践的核心：AI能读取业务上下文、遵守业务规则、驱动业务状态变化。

二、ArkUI页面搭建与状态管理

应用底部由“今日、衣橱、护理、我的”四个Tab组成，按用户行为路径切分。首页TodayTab使用@State定义关键状态：

2. @State clothes: Clothing[] = [];
3. @State weather: WeatherInfo = OutfitAI.mockWeather();
4. @State plan: OutfitPlan | null = null;
5. @State scene: string = '通勤';
6. @State loading: boolean = false;
7. @State feedback: string = '';

复制代码

状态粒度做到与用户可见内容一一对应，避免过粗引发大量无关刷新，也不将所有临时状态放全局。生成搭配的异步方法用finally确保loading在成功、失败、异常后都能复位，防止按钮永久禁用。

页面主题集中在Theme.ets中维护，包括背景色、卡片色、主色、圆角和统一边距，视觉风格柔和，降低高频浏览压力。

三、可计算的数据模型：Clothing接口

衣物不能只存照片和名称，否则AI无法可靠匹配。项目定义的Clothing接口：

2. export interface Clothing {
3.   id: string;
4.   name: string;
5.   category: string;
6.   color: string;
7.   season: string[];
8.   style: string[];
9.   temperatureMin: number;
10.   temperatureMax: number;
11.   emoji: string;
12.   status: ClothingStatus;
13.   wornCount: number;
14.   lastWorn: string;
15.   careTip: string;
16. }

复制代码

其中id是模型输出与本地实体间的稳定主键；category确保一套搭配包含上装、下装、鞋履等必要角色；temperatureMin/temperatureMax是硬约束；status、wornCount、lastWorn使衣橱进入动态生命周期管理。状态机采用clean|worn|washing|drying四种状态，覆盖“能不能穿、该不该洗、是否晾晒”等关键事实。

四、本地持久化：Preferences存储

衣物数据默认可离线使用。通过@kit.ArkData的Preferences封装WardrobeStore，将存储细节从UI中移除。初始化时获取Preferences实例，首次运行写入示例衣物；查询、添加、状态更新都经由Store完成。updateStatus方法在写入后调用flush()使数据及时落盘，确保后台回收时不丢失。

2. static async updateStatus(id: string, status: ClothingStatus): Promise<void> {
3.   const list = await WardrobeStore.list();
4.   list.forEach((item: Clothing) => {
5.     if (item.id === id) {
6.       item.status = status;
7.       if (status === 'worn') {
8.         item.wornCount += 1;
9.         item.lastWorn = '今天';
10.       }
11.     }
12.   });
13.   await WardrobeStore.save(list);
14. }

复制代码

五、大模型调用：结构化上下文与JSON约束

模型服务层OutfitAI.ets构建输入为WeatherInfo + scene + WardrobePromptItem[]组成的JSON，只发送ID、名称、分类、颜色、风格、适温、状态、最近穿着时间等关键字段，避免无关UI数据。系统提示词要求模型返回严格JSON：

2. {
3.   "title": "搭配标题",
4.   "itemIds": ["衣物id"],
5.   "reason": "推荐理由",
6.   "tips": "穿着或天气提醒"
7. }

复制代码

必须返回itemIds而非名称，因为名称不可靠（可能重复）；限制为JSON格式确保UI可渲染；客户端还需检查映射结果，防止模型输出不存在ID。网络请求使用@kit.NetworkKit的http.createHttp()，设置JSON头、认证头、超时，并在finally中释放Http实例，这是移动端资源管理的关键细节。

六、本地规则兜底：可靠性保障

模型调用失败时，localRecommend先筛选状态为clean且适温范围覆盖当前气温的衣物，再寻找上衣、外套、下装/裙装、鞋履。这是确定性规则，不应被模型突破。两者分工明确：规则负责可靠性，模型负责个性化和表达力。当用户认为推荐不合适时，可判断是天气数据错误、衣物标签不完整、本地规则太严还是提示词策略不佳，便于定位问题。

七、衣物护理：完整生活闭环

护理页按状态汇总待清洗、晾晒中、洁净可穿数量，将非洁净衣物显示为待办清单。用户每次操作调用WardrobeStore.updateStatus更新实体并重新拉取列表，页面自动刷新。护理建议绑定同一份Clothing数据，与今日推荐天然一致。

八、智能体与跨设备协同展望

当前已具备将业务能力开放为智能体工具的条件，可设计RecommendOutfit、AddClothing、QueryWardrobe、UpdateCareStatus、QueryCareList等意图。跨设备共享的核心不是UI，而是衣物实体、状态流转、用户偏好与推荐历史。后续使用分布式KV存储同步时，按用户授权、设备可信关系和最小必要原则分层处理。

九、工程组织与可维护性

项目目录按职责划分：pages只关心显示与交互，model定义领域对象和持久化，service负责天气、模型或未来系统能力，common放置主题与配置，entryability处理应用生命周期。这样便于AI功能扩展（视觉识别、语音意图、云端同步）。已使用DevEco Studio与Hvigor验证通过。实际生产应将模型密钥放在服务端代理，客户端只请求自有服务。

十、复盘：从AI功能走向可信智能体验

核心经验：1）AI输出必须落在业务对象上，返回本地衣物ID而非不可执行的描述；2）AI必须有边界，温度、清洁状态等事实约束由确定性规则守住；3）AI必须可失败，网络异常、限流、格式问题都不应让用户失去基本功能，本地兜底与清晰反馈是智能化体验的一部分。

“衣见倾心”已完成闭环：衣物被结构化记录，状态随使用变化，天气与场景触发推荐，模型在受控上下文中产生建议，结果写回可理解卡片，护理任务让衣物回到可穿状态。未来接入视觉识别、实时天气、小艺意图、服务卡片和跨设备数据流转后，这个闭环将成长为鸿蒙全场景生活服务的一个具体切面。

热心网友4

这篇文章非常详尽，把「衣见倾心」从痛点分析到工程落地都梳理清楚了。最让我印象深刻的是三、五、六节——把Clothing接口设计成可计算的元数据（温度范围、状态机、穿着次数），再让大模型在结构化上下文中输出严格JSON，最后用本地规则做兜底，这个闭环既务实又优雅。特别是规则负责可靠性、模型负责个性化这个分工，正好解决了AI落地常见的“胡说八道”和“缺乏约束”问题。 想追问一个细节：Clothing状态机里“washing”和“drying”是互斥的吗？如果用户在烘干时又去洗另一件，updateStatus时如何保证并发安全性？目前是直接遍历列表赋值，感觉在多线程写入或分布式场景下可能会有覆盖问题，不知道你后续有没有考虑锁或事务机制？

热心网友4

非常棒的实战分享！从痛点定位到工程实现，逻辑非常清晰。尤其欣赏你明确区分了本地规则和AI模型的职责——规则兜底可靠性，模型负责个性化和表达力，这种分层思想对于医疗、穿戴等容错率要求较高的场景特别关键。 对Clothing接口的设计印象深刻：category、temperatureMin/Max、status状态机，甚至wornCount和lastWorn都纳入了数据模型，这让衣橱具备了动态生命周期，AI推荐时的上下文也更有依据。Preferences持久化+flush落盘的做法，在离线场景下很实用。 想进一步请教：在模型返回的itemIds与本地衣物映射时，如果遇到模型幻觉输出了不存在的ID，你这边是如何优雅降级处理的？是直接使用本地推荐方案替代整个结果，还是只替换无效的那一件衣物？另外，在“护理”页的状态流转中，如果用户手动修改了衣物的清洗状态，导致原本AI推荐的结果失效，你们的UI侧是如何提示用户刷新推荐的？

热心网友4

非常详实的实战分享！数据模型设计得很扎实，尤其是`temperatureMin/temperatureMax`作为硬约束、`status`状态机管理衣物的生命周期，这些细节让AI的推荐既有规则底线又有表达空间。本地规则兜底配合结构化JSON约束的思路也很务实地解决了模型“胡编”的问题。 有一点想请教：当本地规则兜底也凑不齐完整搭配（比如缺少鞋履）时，应用目前的处理方式是直接提示用户，还是会尝试下调约束（比如放宽温度范围或允许复用同类衣物）？另外，多轮反馈的修正——比如用户手动替换某件衣物后，是否会将这次选择回传给模型做后续优化？