衣橱管理穿搭助手

解决什么问题

衣柜数据越攒越多之后，两个问题会同时暴露：一是 wardrobe_index.json 这类索引文件体积膨胀，每次全量读进上下文既慢又贵，筛选结果也不稳定；二是标签 schema、温度档位、推荐日志分散在不同文件里，手工维护容易写出不一致的记录。这个技能把「查衣服、搭一套、记日志」收敛成脚本化流程，让推荐结果可复现。

核心能力与关键步骤

意图路由是入口。根据用户当前这句话的目标，分到 A（已有衣柜推荐）、A-CRON（每日早晨定时推荐）、B（买新衣服参考）、C（上传衣物生成试穿图）、D（衣柜增删改查）、E（人像库管理）六条主流程之一，中途改目标就切流程。

A 流程大致是：

• A0 初始化：先查 Is_this_the_first_run.md，首次运行先补 user_info.md 里的城市、禁忌和偏好。
• A1 天气：按最高温度映射温度档位；查询失败时让用户补大致温度，普通任务可按季节/体感做保守推荐并说明假设。
• A2 筛选：走 scripts/filter_by_criteria.py，绝不展开完整索引 JSON；至少结合 temperature 与 occasion，结果不足时按 occasion → style → function 顺序放宽，但不放宽到明显不合温度的单品。
• A3 搭配：按 Universal_Dressing_Rules.md 组成 1 套或多套，并排除已推荐日志里的衣物 ID。
• A4/A5/A6 确认与试穿：多套方案先用 scripts/Image_stitching_tool.py 拼图预览；需要上身图时读 generate_outfit_image_powershell_reference.md 与 api_keys_mapping.md，同脚本最多重试 2 次，仍失败再切备用脚本或告知阻塞原因。

A-CRON 复用 A0–A3，但无人值守：不等待确认、不生成试穿图、不写日志，并在消息末尾提示回复「选方案 1」才会记录。

数据写入有硬约束：任何增删改都必须经 scripts/wardrobe_manager.py 与 scripts/face_manager.py，写标签前先对照 Dressing_schema.json、tag_spec.md、faceinfo_schema.json 校验字段；user_info.md 的「已推荐日志」只在用户明确回复确认语时追加，仅展示方案、自动推送或生成拼图都不写入。

适用边界

• 天气查询失败且是 Cron 任务时，不允许等待询问，只能按当前季节给保守方案并说明数据不可用。
• generate_outfit_image_doubao_reference.md 是长文档，默认不读，只在豆包脚本连续失败或用户明确要求排查时打开。
• 图片识别先看 vision_test_log.md；没有可用记录时先拿 1 张测试图验证能力，再做正式识别。
• 缺少 API Key 会直接阻塞试穿图生成，需要用户先配置 Key。
• 温度档位、穿搭规则与用户档案是推荐质量的上限，资料不全时会退化成保守推荐。