鸿蒙AI穿搭应用实战：ArkTS数据模型、大模型调用与本地规则兜底
一、痛点与产品定位“今天穿什么”看似简单，实际涉及温度、降雨、场合、衣橱状态等多重约束。传统衣橱App只做记录，天气App只提供信息，两者之间缺少决策层。“衣见倾心”将问题定义为轻量级个人决策场景：从用户已有、状态可用的衣物中组合，返回衣物ID、推荐理由和护理提示，并引入本地规则限制温度、状态等硬约束，让模型在约束内做风格协调与语言解释。这正契合鸿蒙应用智能化实践的核心：AI能读取业务上下文、遵守业务规则、驱动业务状态变化。
二、ArkUI页面搭建与状态管理
应用底部由“今日、衣橱、护理、我的”四个Tab组成，按用户行为路径切分。首页TodayTab使用@State定义关键状态：
@State clothes: Clothing[] = [];
@State weather: WeatherInfo = OutfitAI.mockWeather();
@State plan: OutfitPlan | null = null;
@State scene: string = '通勤';
@State loading: boolean = false;
@State feedback: string = '';
状态粒度做到与用户可见内容一一对应，避免过粗引发大量无关刷新，也不将所有临时状态放全局。生成搭配的异步方法用finally确保loading在成功、失败、异常后都能复位，防止按钮永久禁用。
页面主题集中在Theme.ets中维护，包括背景色、卡片色、主色、圆角和统一边距，视觉风格柔和，降低高频浏览压力。
三、可计算的数据模型：Clothing接口
衣物不能只存照片和名称，否则AI无法可靠匹配。项目定义的Clothing接口：
export interface Clothing {
id: string;
name: string;
category: string;
color: string;
season: string[];
style: string[];
temperatureMin: number;
temperatureMax: number;
emoji: string;
status: ClothingStatus;
wornCount: number;
lastWorn: string;
careTip: string;
}
其中id是模型输出与本地实体间的稳定主键；category确保一套搭配包含上装、下装、鞋履等必要角色；temperatureMin/temperatureMax是硬约束；status、wornCount、lastWorn使衣橱进入动态生命周期管理。状态机采用clean|worn|washing|drying四种状态，覆盖“能不能穿、该不该洗、是否晾晒”等关键事实。
四、本地持久化：Preferences存储
衣物数据默认可离线使用。通过@kit.ArkData的Preferences封装WardrobeStore，将存储细节从UI中移除。初始化时获取Preferences实例，首次运行写入示例衣物；查询、添加、状态更新都经由Store完成。updateStatus方法在写入后调用flush()使数据及时落盘，确保后台回收时不丢失。
static async updateStatus(id: string, status: ClothingStatus): Promise<void> {
const list = await WardrobeStore.list();
list.forEach((item: Clothing) => {
if (item.id === id) {
item.status = status;
if (status === 'worn') {
item.wornCount += 1;
item.lastWorn = '今天';
}
}
});
await WardrobeStore.save(list);
}
五、大模型调用：结构化上下文与JSON约束
模型服务层OutfitAI.ets构建输入为WeatherInfo + scene + WardrobePromptItem[]组成的JSON，只发送ID、名称、分类、颜色、风格、适温、状态、最近穿着时间等关键字段，避免无关UI数据。系统提示词要求模型返回严格JSON：
{
"title": "搭配标题",
"itemIds": ["衣物id"],
"reason": "推荐理由",
"tips": "穿着或天气提醒"
}
必须返回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必须可失败，网络异常、限流、格式问题都不应让用户失去基本功能，本地兜底与清晰反馈是智能化体验的一部分。
“衣见倾心”已完成闭环：衣物被结构化记录，状态随使用变化，天气与场景触发推荐，模型在受控上下文中产生建议，结果写回可理解卡片，护理任务让衣物回到可穿状态。未来接入视觉识别、实时天气、小艺意图、服务卡片和跨设备数据流转后，这个闭环将成长为鸿蒙全场景生活服务的一个具体切面。
Re: 鸿蒙AI穿搭应用实战：ArkTS数据模型、大模型调用与本地规则兜底
这篇文章非常详尽，把「衣见倾心」从痛点分析到工程落地都梳理清楚了。最让我印象深刻的是三、五、六节——把Clothing接口设计成可计算的元数据（温度范围、状态机、穿着次数），再让大模型在结构化上下文中输出严格JSON，最后用本地规则做兜底，这个闭环既务实又优雅。特别是规则负责可靠性、模型负责个性化这个分工，正好解决了AI落地常见的“胡说八道”和“缺乏约束”问题。 想追问一个细节：Clothing状态机里“washing”和“drying”是互斥的吗？如果用户在烘干时又去洗另一件，updateStatus时如何保证并发安全性？目前是直接遍历列表赋值，感觉在多线程写入或分布式场景下可能会有覆盖问题，不知道你后续有没有考虑锁或事务机制？Re: 鸿蒙AI穿搭应用实战：ArkTS数据模型、大模型调用与本地规则兜底
非常棒的实战分享！从痛点定位到工程实现，逻辑非常清晰。尤其欣赏你明确区分了本地规则和AI模型的职责——规则兜底可靠性，模型负责个性化和表达力，这种分层思想对于医疗、穿戴等容错率要求较高的场景特别关键。 对Clothing接口的设计印象深刻：category、temperatureMin/Max、status状态机，甚至wornCount和lastWorn都纳入了数据模型，这让衣橱具备了动态生命周期，AI推荐时的上下文也更有依据。Preferences持久化+flush落盘的做法，在离线场景下很实用。 想进一步请教：在模型返回的itemIds与本地衣物映射时，如果遇到模型幻觉输出了不存在的ID，你这边是如何优雅降级处理的？是直接使用本地推荐方案替代整个结果，还是只替换无效的那一件衣物？另外，在“护理”页的状态流转中，如果用户手动修改了衣物的清洗状态，导致原本AI推荐的结果失效，你们的UI侧是如何提示用户刷新推荐的？Re: 鸿蒙AI穿搭应用实战：ArkTS数据模型、大模型调用与本地规则兜底
非常详实的实战分享！数据模型设计得很扎实，尤其是`temperatureMin/temperatureMax`作为硬约束、`status`状态机管理衣物的生命周期，这些细节让AI的推荐既有规则底线又有表达空间。本地规则兜底配合结构化JSON约束的思路也很务实地解决了模型“胡编”的问题。 有一点想请教：当本地规则兜底也凑不齐完整搭配（比如缺少鞋履）时，应用目前的处理方式是直接提示用户，还是会尝试下调约束（比如放宽温度范围或允许复用同类衣物）？另外，多轮反馈的修正——比如用户手动替换某件衣物后，是否会将这次选择回传给模型做后续优化？
页:
[1]