衣橱管理应用 wardrobe-manager

让记不住型用户快速确认衣橱里有什么，减少重复购买

6D 全流程

3主 Use Case

5能力卡

2条红线

8大品类

01 · 项目定位

为谁解决什么问题

从模糊想法到真实机会，Discover 阶段用证据收敛方向

目标用户

记不住型 · 衣物多的个人用户

衣物数量多，经常找不到
想买时不确定衣橱里有没有
不记得自己有什么，导致重复购买

核心 Job

在不知道自己有什么时，快速回忆

买前查询：有没有类似的 → 减少重复购买
拍照入库：快速建立衣橱数字资产
穿搭日志：日常循环留痕，对冲频率风险

Discover 证据

5 家竞品四维分析 + 18 问半结构化深访 + 频率探测问题组

三条核心假设：录入门槛、搭配推荐、家庭共享
区分「门槛致流失」与「低频致流失」
收敛方向：ToC 路径，不做搭配推荐算法

02 · 6D 进展

六个阶段，证据驱动

不用文件数量算进度，用结果和证据判断位置

D1

Discover

已完成

D2

Define

已确认

D3

Design

已确认

D4

Demo

进行中

D5

Detect

未开始

D6

Drive

未来

阶段	关键决定	关键产物
Discover	ToC 路径，5 竞品对比，不做搭配推荐	竞品调研 + 访谈提纲 + 频率探测
Define	P0=记不住型，Must=S1/S2/S3/S6	M2-M6 正式产物 + overview
Design	手机原生App，5 能力卡，3 Use Case	PRD v0.7 + v1.0 + API 设计
Demo	mock 闭环 5/5 Pass，红线守住	SUT + GT + Workspace + Trial + BadCase
Detect	—	（待 Demo 通过后进入）
Drive	未来能力（当前不可推进）	—

03 · Define 范围

承诺解决什么，不做什么

P0 主线 = 记不住型用户，MVP 闭环四步

Must 闭环（四步）

S1 入库：拍照→去背→识别→确认→入库
S2 浏览：浏览已有衣橱数据
S3 购买拦截：买前查相似，减少重复
S6 找单品：检索确认某件在不在

Won't（不做）

穿搭推荐算法（红线 2）
家庭共享
精确营养/医疗判断
自动写入不经确认（红线 1）
识别品牌/价格

4

Must 闭环

5

Won't 边界

3

业务成功指标层

04 · Use Case 与能力

三个主场景，五张能力卡

从用户旅程到 AI 能力，逐层写成行为合同

UC1 买前查询拦截

Flow F01 · CAP-01 + CAP-04

按品类筛选 / 搜相似款
确认有无后决定不买/买
查无→引导入库（不断言"没有"）

UC2 拍照入库

Flow F03 · CAP-02 + CAP-03

拍照→去背→识别品类→确认
低置信降级三选项
非衣物降级手动选

UC3 穿搭日志

Flow F04 · CAP-05

记录今天穿了什么
关联已入库单品留痕
日常循环提频钩子

CAP-01

查询检索

按品类筛选+相似款搜索

CAP-02

去背

去除拍照背景，得纯衣物图

CAP-03

品类识别

8 类分类+置信度，不假装准确

CAP-04

单品定位

检索确认某件在不在

CAP-05

穿搭日志

低负担留痕提频

05 · 红线与安全

不可触碰的两条红线

合规率 100%，任何场景下不得违反

红线 1 · 不自动写入

用户明确确认「对」才写入 items。草稿（capture）不等于已入库（item）。确认前不得写入，不得在无操作下改动数据。

红线 2 · 不生成穿搭推荐

不提供算法生成的搭配建议。用户问「怎么搭配」时受限回答，引导穿搭日志。留痕过程无推荐生成。

关键状态机（7 状态）

状态	用户知道什么	系统不得做什么
空（未录入）	衣橱没有数据	不得把"未录入"说成"没有"
入库中	照片在处理	不得确认前自动写入
识别不确定	AI 对品类低置信	不得假装已识别准确
待确认（草稿）	结果出来还没入库	不得自动入库
已确认	衣物已入库	不得无操作下改动
查无此件	没找到	不得断言"你没有"
暂停/退出	中途离开	不得产生补账/失败感

06 · Demo 证据链

mock 闭环 5/5 Pass

不声称正式质量通过，evaluation_status = pending

Demo 四环循环

定义正确：GT/Oracle + 5 Atomic Case + Journey
构建能力：Workspace 底座→Skill→AGENTS 总装
执行取证：Trial 5/5 Pass，Bad Case 已修复
定位迭代：Continue，可升级真实依赖或进 Detect

双流程设计

流程 1 查相似：去背+预判→查相似→有则提示确认
流程 2 录入：去背+识别+置信度→确认门→入库
四道 Gate：写入 / 低置信 / 非衣物 / 重复
红线全部守住（不自动写入、不假装准确）

证据等级

层级	内容	状态
L0 合同	SUT + EvalConfig + GT/Oracle	有
L1 静态	Workspace 构建 build PASS	有
L2 组件 Trial	mock 走通闭环	有
L3 单路径	Journey 5 Case	有
L4 全量动态	正式 Eval	未完成（pending）

L0 合同 ✓ L1 静态 ✓ L2 组件 ✓ L3 单路径 ✓ L4 全量动态待

07 · Workspace 底座

三步构建：底座→能力→总装

对照 W4S1 三步法，已重做完整 Workspace 底座

第一步 · 底座

三层装配：Global / Published / UserDir
目录责任树：agents/knowledge/memory/scripts
三档案分离：items / captures / state
权限边界：协议只读、数据可写

第二步 · 能力

Skill A 拍照入库（UC2）
Skill B 买前查询（UC1）
Skill C 穿搭日志（UC3）
三条 Knowledge：K01/K02/K03
确定性脚本 load_context.py

第三步 · 总装

AGENTS.md：身份+首动作+路由
Must/Must-Not 硬边界
双流程 + 四道 Gate
7 状态异常恢复词典
语言规则：全中文

目录责任树

workspace/ ← Published Workspace（只读快照） ├── AGENTS.md ← 总机 ├── .agents/skills/ ← 三能力（Skill A/B/C） ├── knowledge/ ← K01 证据标准 + K02 品类 + K03 指标 ├── memory/ │ ├── contracts/ ← instance-state.yaml 协议 │ └── templates/ ← item/capture 模板 ├── scripts/ │ └── load_context.py ← 确定性上下文装配（只读） └── design/ ← 底座设计文档

08 · 数据模型

三档案分离，草稿≠真值

来源、修改权和生命周期不同的数据必须分开

items · 已入库

用户确认后写入 · 持久

item_id + category + confidence
low_confidence 标记粗记
用户可修改/删除
查询、日志、定位读取

captures · 草稿

拍照自动生成 · 临时

capture_id + stage + status
predicted_category + confidence
similar_item_ids 查相似
确认后转 item 或取消删除

state · 运行指针

系统自动维护 · 实例级

current_skill + current_stage
next_action + next_actor
跨会话恢复
每轮首动作读取

为什么分三份

档案	来源	修改权	生命周期
items	用户确认后	用户可改/删	持久，直到用户删除
captures	拍照自动	确认后转 items	临时，确认或取消后清除
state	运行时自动	系统写入	实例级，跨会话恢复
logs	用户记穿搭	用户可补充/删	持久

09 · 评测与下一步

三支柱评测，两条路径

大部分阈值未设——呼应「无基线不编数字」

评测三支柱

支柱	衡量什么
成功与质量	结果和体验是否达成
过程与轨迹	查询、耗时是否合理
可信与安全	红线和边界是否守住

3 条红线指标（100%）
2 条暂定需验证（≥85% / <3s）
5 条需采集基线

下一步两条路径

路径 A：升级真实依赖
rembg + torchvision 真实模型
真实采样本重跑 Trial
从 mock 变真实证据
路径 B：进入 Detect
用 mock 版本做候选 SUT
标准/评分/人审/总结
四包输入就绪检查通过

事实与边界

Mock 闭环 5/5 Pass 不证明业务价值/识别准确率
result_gate = needs_result（mock 证据不足）
evaluation_status = pending（未正式评测）
不宣布上线/发布，不声称识别准确率已验证