meida/docs/美学知识库-建设方案.md

# 美学知识库建设方案

> 本文档定义「美搭」App 美学/穿搭知识库的**分类体系、模态构成、构建流程与检索链路**，与 [产品方案](./鸿蒙美搭-智能穿搭美学助手-产品方案.md)、[美学报告需求文档](./美学报告-需求文档.md)、[穿搭 Agent 需求文档](./穿搭Agent-需求文档.md)、[用户系统与记忆系统需求文档](./用户系统与记忆系统-需求文档.md) 配套使用。

## 1. 目标与定位

### 1.1 为什么必须自建知识库，不能只靠大模型

| 只用大模型的问题 | 知识库的作用 |
|-----------------|-------------|
| **幻觉**：编造"柔夏型适合正红色"这类错误结论 | 硬规则约束，核心结论不由模型自由生成 |
| **不可审计**：出错无法定位和修复 | 每条知识有 ID、来源、审核人，可定位可回滚 |
| **不可试穿**：推荐"一件卡其色阔腿裤"，但系统没有这条裤子的图，无法调用换装 API | 每个单品实体绑定白底图素材，建议可直接变成预览 |
| **不可解释**：无法回答"为什么推荐给我" | 图谱路径可还原推理链（体型→策略→单品→颜色） |
| **无壁垒**：能力等于公开模型能力 | 专家规则 + 素材资产 + 行为回流构成数据壁垒 |
| **成本高**：长提示词与长输出 | 结构化结论走规则引擎，模型只负责表达 |

### 1.2 知识库要服务的四个消费方

1. **美学报告**：提供规则结论（体型策略、色板映射、发型适配）与话术模板
2. **穿搭 Agent**：提供 RAG 检索片段与成套方案召回
3. **换装/发型模块**：提供可试穿的单品素材与发型标签
4. **推荐排序**：提供属性与适配矩阵作为过滤和打分依据

### 1.3 设计原则

- **能计算的不要写成文字**：色彩距离、比例判定用数值算法，不塞进文本让模型"读"
- **能硬约束的不要交给模型**：禁忌项、色板范围、体型规则用规则引擎强制
- **每条知识可溯源**：`source` + `reviewer` + `effective_period` 三字段必填
- **图文强绑定**：任何单品/搭配/发型知识必须有可用图像资产，否则无法完成"建议 → 预览"闭环
- **时效分离**：永恒法则（色彩理论、体型修饰）与时效内容（流行趋势）分库管理，更新节奏不同

---

## 2. 总体架构

知识库分四层，从下到上：

```
┌────────────────────────────────────────────────────────────┐
│  ④ 检索与推理层  Retrieval & Reasoning                      │
│  硬过滤 → 向量召回 → 图谱扩展 → 重排 → 生成（带引用）        │
├────────────────────────────────────────────────────────────┤
│  ③ 资产层  Assets                                           │
│  单品白底图 / 成套 look 图 / 发型图 / 色板图 / 教程视频      │
│  （对象存储 + CDN + 图像向量索引）                           │
├────────────────────────────────────────────────────────────┤
│  ② 内容层  Content                                          │
│  规则条目 / 专业解释文本 / 场景模板 / 报告话术 / 搭配方案     │
│  （关系库 + 全文索引 + 向量索引）                            │
├────────────────────────────────────────────────────────────┤
│  ① 本体层  Ontology                                         │
│  实体定义 + 属性字典 + 枚举值 + 实体间关系（图谱 Schema）      │
│  —— 一切的基础，必须先定义，后灌数据                          │
└────────────────────────────────────────────────────────────┘
```

**建设顺序不可颠倒**：先定义本体（属性字典与枚举值），再灌内容与资产。若先堆内容，后期会出现"同一个领型有 5 种写法"的灾难，导致检索与规则全部失效。

---

## 3. 知识分类体系（12 类实体）

### 3.1 分类总览

> 🔒 **规模数值的唯一定义位置是本文 §9**。下表的「长期目标」列与「V1 硬指标」列必须与 §9 一致；产品方案 §2.5.2 / §2.8 **一律引用 §9，不得复述**。此前四处文档给出过互相矛盾的规模数字（单品 800/400/300、规则 800~1200/800/400），已在本轮收口。

| # | 类目 | 定位 | 主要模态 | **V1 硬指标** | 长期目标 |
|---|------|------|---------|:-----------:|--------|
| 1 | 单品 Item | 服饰单品的属性化定义 | 结构化 + 图像 | **300 件 `tryon_ready`** | 800~1500 条 |
| 2 | 色彩 Color | 颜色体系与季型色板 | 数值 + 结构化 + 图像 | 12 季 × 30 色 ≈ 400 色 | 同 |
| 3 | 风格 Style | 风格体系与识别特征 | 文本 + 结构化 + 图像 | 9 基因型 + 20 潮流风格 | 同 |
| 4 | 身材 Body | 体型与局部特征的修饰策略 | 结构化 + 文本 + 图示 | 5 体型 × **13 局部特征** | 同 |
| 5 | 面部与发型 Face & Hair | 脸型/量感/直曲 与发型适配 | 结构化 + 图像 | 60 发型 + **7 脸型映射** | 同 |
| 6 | 场景 Occasion | 场合着装规范与温度带 | 结构化 + 文本 | 20 场景 × 4 季 | 同 |
| 7 | 材质 Material | 面料特性与季节适配 | 结构化 + 文本 | 40~60 种 | 同 |
| 8 | 配饰 Accessory | 配饰搭配规则 | 结构化 + 图像 | 8 品类 × 规则 | 同 |
| 9 | 妆容 Makeup | 与季型联动的妆容方案 | 结构化 + 文本 + 色值 | 12 季 × 3 部位 | 同 |
| 10 | 搭配法则 Rule | 可执行的 IF-THEN 规则 | 结构化（规则引擎） | **400 条** | 800~1200 条 |
| 11 | 搭配方案 Outfit | 成套 look（召回主单元） | 结构化 + 图像 | **100 套** | 300~500 套 |
| 12 | 趋势 Trend | 时效性流行趋势 | 文本 + 图像 | 每季 30~50 条 | 同 |

> ⚠️ **两处计数错误已更正**：脸型是 **7 种**（鹅蛋/圆/方/长/心形/菱形/梨形，与美学报告 §4 维度 #8 一致），原写「8 脸型」；局部特征实际列了 **13 项**（见 §3.2 ④），原写「12 项」。

> 扩展类目（V3 电商阶段）：品牌 Brand、商品 SKU、价格与渠道。

### 3.2 各类目详细设计

#### ① 单品 Item —— 一切搭配的原子

**品类树（三级）**：
```
上装 ├ T恤/衬衫/针织衫/卫衫/背心/吊带/西装外套/风衣/大衣/羽绒服/夹克/开衫
下装 ├ 西裤/直筒裤/阔腿裤/锥形裤/牛仔裤/短裤/A字裙/百褶裙/包臀裙/半身长裙
连体 ├ 连衣裙/连体裤/套装
鞋履 ├ 乐福鞋/芭蕾鞋/小白鞋/高跟鞋/靴子（切尔西/长靴/短靴）/凉鞋/运动鞋
包袋 ├ 手提包/腋下包/斜挎包/托特包/双肩包/藤编包
配饰 ├ 腰带/耳饰/项链/手链/手表/丝巾/围巾/帽子/发饰
```

**核心属性字典（枚举值必须统一）**：

| 属性 | 枚举值示例 |
|------|-----------|
| 廓形 silhouette | 修身 / 直筒 / 宽松 / A 型 / H 型 / X 型 / O 型 / 茧型 |
| 领型 neckline | 圆领 / V 领 / 方领 / 船领 / 一字领 / 立领 / 翻领 / POLO / 荷叶领 |
| 袖型 sleeve | 无袖 / 短袖 / 七分 / 长袖 / 泡泡袖 / 灯笼袖 / 落肩 / 插肩 |
| 肩部 shoulder | 自然肩 / 垫肩 / 落肩 / 收肩 |
| 腰线 waistline | 高腰 / 中腰 / 低腰 / 无腰线 / 收腰 / 松紧 |
| 长度 length | 短款 / 常规 / 长款；裙长（超短/及膝/过膝/中长/及踝） |
| 图案 pattern | 纯色 / 细条纹 / 粗条纹 / 小碎花 / 大花 / 格纹 / 波点 / 印花 / 拼色 |
| 颜色 color | 色名 + HEX + 归属季型（关联类目②） |
| 面料 material | 关联类目⑦ |
| 正式度 formality | 1~5（居家 → 礼服） |
| 季节 season | 春/夏/秋/冬（多选）+ 适配温度带 |
| 露肤度 exposure | 0~5（合规与偏好过滤用） |
| 量感 volume | 小 / 中 / 大（与用户量感匹配） |
| 直曲 line | 偏直 / 适中 / 偏曲 |

**试穿相关字段（关键）**：

| 字段 | 说明 |
|------|------|
| `image_url` | 展示图 |
| `tryon_image_url` | **白底/透明底抠图**，用于换装 API 的 `cloth_img` / `kuzi_img` |
| `tryon_slot` | `top`（上衣）/ `bottom`（裤装）/ `dress`（连衣裙）/ `not_supported` |
| `tryon_ready` | 布尔值，是否可用于一键试穿 |
| `default_prompt` | 该单品的推荐 `change_desc` 提示词模板 |

> 现有换装接口只支持 `human_img` + `cloth_img` + `kuzi_img`，即上衣与裤子。**连衣裙、鞋、包、配饰无法参与换装**。因此 `tryon_slot` 必须准确标注，产品端只对 `tryon_ready = true` 的单品展示"一键试穿"，其余展示"加入搭配"，避免用户点了没反应。

#### ② 色彩 Color —— 最需要"数值化"的类目

不要把颜色当文本存，要当数值存，否则无法计算匹配度。

| 字段 | 说明 |
|------|------|
| `color_id` / `name_cn` / `name_en` | 灰蓝 / Dusty Blue |
| `hex` / `rgb` / `hsl` / `lab` | 多色彩空间值，`lab` 用于计算感知色差 ΔE |
| `hue_temp` | 冷 / 中性 / 暖（数值化 -1~1） |
| `value` | 明度 0~100 |
| `chroma` | 彩度 0~100 |
| `season_fit` | 所属季型列表（如 `["柔夏","冷夏"]`） |
| `role` | 主色 / 辅色 / 点缀色 / 中性色 |
| `pairs_well_with` | 推荐搭配色 ID 列表 |
| `conflicts_with` | 冲突色 ID 列表 |

**色板实体 ColorPalette**：
- 12 季型各一套：`best_colors`（24+）/ `neutrals`（时尚中性色：白、黑、灰、米驼、卡其的适配款）/ `harmony_colors`（调和色）/ `avoid_colors`（避雷色）
- 附季型解析文本（明度、饱和度、冷暖倾向）与配色公式（如"基础色 70% + 点缀色 30%"、"三色以内"）
- 附口诀类记忆文本（参考样例中的"柔冷低饱和为基，朦胧细腻要牢记"，这类内容传播性强）

**算法接口**：给定用户肤色 Lab 值 → 计算与各季型色板中心的距离 → 输出季型归属与置信度；给定任意单品颜色 → 计算与用户最佳色板的 ΔE → 输出"适合/可尝试/避免"三档。

#### ③ 风格 Style
- **基因风格 9 型**：戏剧型、睿智型、自然型、古典型、优雅型、浪漫型、前卫型、少女型、少年型
  - 每型字段：定义文本、线条特征、剪裁特征、色彩偏好、面料偏好、装饰程度、气质关键词、代表单品列表、避免项、参考图集
  - 参考样例中"自然型"的描述结构可直接作为模板（线条 → 剪裁 → 色彩 → 面料 → 装饰 → 气质）
- **潮流风格标签 20+**：法式、韩系、日系、City Boy、美拉德、清冷风、老钱风、多巴胺、Y2K、学院风、通勤简约、复古港风……
  - 潮流风格带 `trend_period` 字段（时效性），过期自动降权
- **风格关系**：基因风格 × 心理风格的 81 种组合的融合建议（不必穷举，用规则 + 模板生成）

#### ④ 身材 Body
- **整体体型 5 型**：O 苹果、A 梨、X 沙漏、T 倒三角、H 矩形
- **局部特征 13 项**：溜肩、平肩、宽肩、窄肩、短颈、长颈、粗手臂、小腹、宽臀、长腰、短腰、粗腿、腿型（直/O/X）
- 每项字段：判定标准（可量化的比例阈值）、视觉目标（如"视觉重心上移"）、推荐策略、推荐单品属性组合、明确避免项、图示
- **需求映射**：显高 / 显瘦 / 显白 / 遮肉 / 修饰肩颈 → 各自的策略集合
- 文案红线：所有描述使用中性表述（"下半身量感偏大"而非"腿粗"）

#### ⑤ 面部与发型 Face & Hair
- **脸型**：鹅蛋、圆、方、长、心形、菱形、梨形 —— 各带加分项与避坑点
- **面部量化维度**：三庭五眼比例、量感（小/中/大 + 分值）、直曲（偏曲/适中/偏直 + 分值）、立体度（0~10）、动静
- **发型实体**（对接现有 60 款发型库，必须补齐标签）：

| 字段 | 说明 |
|------|------|
| `hairstyle_id` | 对应发型 API 的 ID（如 `1953267161121464322`） |
| `image_url` | 预览图（634×950） |
| `length` | 超短 / 短 / 齐肩 / 中长 / 长 |
| `curl` | 直发 / 微卷 / 大波浪（卷径 cm）/ 小卷 |
| `bangs` | 无 / 空气刘海 / 侧分长刘海 / 齐刘海 / 八字刘海 |
| `parting` | 中分 / 3:7 / 4:6 / 无 |
| `volume_top` | 颅顶蓬松度等级 |
| `outline` | 椭圆型 / V 型 / A 型 / 圆型 |
| `fit_face_shape` | 适配脸型列表 |
| `fit_volume` / `fit_line` | 适配量感 / 直曲 |
| `formality` | 适配场景正式度 |
| `styling_tips` | 造型手法（卷发棒温度、圆梳吹整等） |

> **这是当前最大的数据缺口**：现有 60 款发型只有 `id / name / image_url`，没有任何适配标签，导致"根据脸型推荐发型"无法实现。必须先完成 60 款发型的人工打标（预计 1~2 人日），这是发型推荐能力的前置条件。

- **发色实体**：色值 + 冷暖 + 明度 + 适配肤色档位 + 适配季型 + 对应换发色 API 的 `rgb` 与推荐 `ratio`

#### ⑥ 场景 Occasion
- 场景树：通勤 / 面试 / 商务正式 / 休闲日常 / 约会 / 聚会 / 婚礼观礼 / 宴会 / 旅行 / 运动 / 居家 / 毕业典礼 / 见家长 / 年会
- 每场景字段：着装规范（Dress Code 等级）、正式度区间、推荐单品组合、禁忌、配色倾向、行业差异（互联网 vs 金融 vs 教培的通勤差异）
- **温度带映射**：`< 0℃ / 0~5 / 5~10 / 10~15 / 15~20 / 20~25 / 25~30 / > 30℃` × 天气（晴/雨/雪/风）→ 穿衣层数与单品建议
- 每场景配 2~4 套完整方案（关联类目⑪）

#### ⑦ 材质 Material
垂感 / 挺括度 / 透气性 / 保暖性 / 易皱度 / 光泽度 / 厚薄 / 适配季节 / 适配季型（如柔夏偏好真丝、雪纺、细针织、缎面）/ 保养要点 / 价格感知（廉价感 vs 高级感）

#### ⑧ 配饰 Accessory
按品类（腰带/耳饰/项链/手链手表/包/鞋/丝巾/帽子）定义：尺寸量感档位、材质、颜色策略、佩戴位置（如"细腰带系于高腰位置"）、适配脸型/颈长/量感、避免项

#### ⑨ 妆容 Makeup
底妆（色调/质地/定妆）、眼妆（眼影色系/眼线色/睫毛）、唇妆（色系/饱和度/质地）× 12 季型，附具体色值与避免色

#### ⑩ 搭配法则 Rule —— 规则引擎的燃料

这是知识库最核心、最难替代的部分。规则采用结构化的条件-结论形式，可执行、可测试、可审计：

```json
{
  "rule_id": "R-BODY-A-002",
  "category": "body_shape",
  "priority": 90,
  "conditions": {
    "body_shape": "A型",
    "features": { "include": ["溜肩"] },
    "goals": { "include": ["修饰溜肩"] }
  },
  "conclusions": {
    "recommend": [
      { "slot": "top", "attrs": { "shoulder": ["垫肩", "自然肩"], "sleeve": ["泡泡袖"], "neckline": ["V领", "方领", "船领"] } }
    ],
    "avoid": [
      { "slot": "top", "attrs": { "shoulder": ["落肩"], "silhouette": ["修身"] } }
    ],
    "explanation": "溜肩需要在肩部建立结构感，垫肩或泡泡袖可撑起肩线；V领/方领拉长颈部线条，把视觉焦点从肩部转移。"
  },
  "source": "《服装造型与人体》+ 形象顾问审核",
  "reviewer": "顾问A",
  "confidence": 0.95,
  "effective_period": "permanent",
  "version": "1.0"
}
```

规则分组与优先级（数字越大越优先，冲突时高优先级胜出）：

| 优先级 | 规则组 | 说明 |
|-------|-------|------|
| 100 | 合规与安全 | 露肤度、内容安全（不可覆盖） |
| 95 | 用户禁忌 | 来自记忆系统 L2 的禁忌项（用户明确不接受） |
| 90 | 体型修饰 | 体型 + 局部特征策略 |
| 85 | 色彩适配 | 季型色板约束 |
| 80 | 场景规范 | 场合 Dress Code |
| 75 | 温度适配 | 天气与温度带 |
| 70 | 风格一致 | 基因/心理风格 |
| 60 | 用户偏好 | 偏好加权（非硬约束） |
| 50 | 流行趋势 | 趋势加权 |

> 冲突消解示例：用户禁忌（95）"不接受露肩" > 体型规则（90）"倒三角建议一字领" → 最终不推荐一字领，改用 V 领替代方案。**用户禁忌永远高于专业规则**，这与记忆系统的冲突消解原则一致。

#### ⑪ 搭配方案 Outfit —— 检索召回的主单元

Agent 和报告推荐的实际交付物是"成套 look"，而非零散规则。

```json
{
  "outfit_id": "OF-00231",
  "title": "自然优雅通勤 · 灰蓝西装套装",
  "items": [
    { "slot": "top", "item_id": "IT-1042", "name": "灰蓝色西装外套" },
    { "slot": "inner", "item_id": "IT-2210", "name": "柔雾紫真丝衬衫" },
    { "slot": "bottom", "item_id": "IT-3391", "name": "冷米黄直筒西裤" },
    { "slot": "shoes", "item_id": "IT-5120", "name": "灰蓝色低跟鞋" },
    { "slot": "accessory", "item_id": "IT-6011", "name": "细款皮质腰带" }
  ],
  "color_formula": "灰蓝 + 柔雾紫 + 浅灰绿（三色以内，浅冷调为主）",
  "fit_profile": {
    "body_shape": ["A型", "H型"],
    "features": ["溜肩"],
    "season_type": ["柔夏", "冷夏"],
    "style": ["自然型", "优雅型"],
    "volume": ["中量感"],
    "line": ["适中"]
  },
  "occasion": ["通勤", "商务正式"],
  "temperature_range": [15, 22],
  "formality": 4,
  "tryon": { "ready": true, "cloth_img": "...", "kuzi_img": "...", "change_desc": "..." },
  "images": { "cover": "...", "detail": ["..."] },
  "source": "专家原创",
  "quality_score": 0.92,
  "adoption_rate": 0.38
}
```

- `fit_profile` 是检索时的**硬过滤字段**，必须完整
- `tryon.ready` 决定是否展示"一键试穿"
- `adoption_rate` 由用户行为回流，用于排序（形成数据飞轮）

#### ⑫ 趋势 Trend
- 字段：趋势名、season（2026SS/2026AW）、关键单品、关键色、适配风格、`valid_until`、来源
- 独立库、独立更新节奏（月更），过期自动降权，避免"去年的流行"污染建议
- 与永恒法则严格分离：趋势只能加权，不能覆盖体型与色彩规则

---

## 4. 模态设计

这是"知识库的模态是什么"的直接回答。本知识库是**多模态混合知识库**，共 7 种模态，每种有明确的存储、索引与用途分工：

| 模态 | 内容 | 存储与索引 | 用途 | 优先级 |
|------|------|-----------|------|:------:|
| **① 结构化数据**<br>Structured | 属性字典、枚举值、适配矩阵、色值、发型标签 | 关系型数据库 + 二级索引 | **硬过滤与计算**：确定性筛选、可审计、零幻觉 | P0 |
| **② 规则**<br>Rule | IF-THEN 条件规则（类目⑩） | 关系库 + 规则引擎（决策表） | **核心结论生成**：报告结论、推荐约束 | P0 |
| **③ 文本**<br>Text | 定义、专业解释、场景模板、报告话术、口诀 | 全文索引 + 向量索引（分块 200~400 字） | **RAG 生成**：解释"为什么"、组织语言 | P0 |
| **④ 图像**<br>Image | 单品白底图、成套 look 图、发型图、色板图、体型图示 | 对象存储 + CDN + 图像向量（CLIP 类） | **展示 + 试穿素材 + 图搜**：卡片渲染、换装 API 入参、以图找相似 | P0 |
| **⑤ 色彩数值**<br>Color / Numeric | HEX / RGB / HSL / Lab、比例阈值、温度带 | 关系库 + 向量距离计算 | **数值匹配**：肤色-季型归属、ΔE 色差、比例判定 | P0 |
| **⑥ 图谱**<br>Graph | 实体关系三元组（体型—策略—单品—颜色—场景—风格） | 图数据库或关系库邻接表 | **多跳推理 + 可解释性**：还原"为什么推荐"路径 | P1 |
| **⑦ 视频 / 音频** | 造型教程（卷发、系丝巾）、报告语音讲解 | CDN；音频用 TTS 实时生成 | **教程内容 + 无障碍收听** | P2 |

### 4.1 模态之间的关系（重要）

不同模态**不是并列的四份数据，而是同一实体的多个面**，必须通过统一 ID 串联：

```
                        Item: IT-1042「灰蓝色西装外套」
                                     │
   ┌──────────────┬──────────────────┼──────────────────┬────────────────┐
   ▼              ▼                  ▼                  ▼                ▼
① 结构化        ⑤ 色彩数值        ④ 图像             ③ 文本          ⑥ 图谱
廓形=直筒       hex=#7C8FA6        展示图             "灰蓝色西装      IT-1042
领型=翻领       lab=(58,-3,-11)    白底试穿图 ✔       是柔夏型的       ─适合→ A型体型
肩部=垫肩       季型=柔夏          细节图             安全牌…"        ─属于→ 自然优雅
量感=中                                                              ─用于→ 通勤场景
```

**一致性要求**：同一实体在各模态中的属性不得矛盾。例如图像标注的颜色必须与 `color_id` 的色值一致，否则会出现"推荐了正确的颜色但展示了错误的图"。需在入库流水线中做交叉校验。

### 4.2 图像资产规范（换装闭环的前置条件）

这是**第一版最容易被忽视、但最可能导致功能不可用**的环节。换装接口需要传入具体的服装图片，如果知识库没有合规的单品图，"AI 建议 → 一键试穿"的闭环就是断的，用户只能自己找图上传，体验极差。

| 资产类型 | 规范 |
|---------|------|
| 单品试穿图 | 纯白或透明背景、正面平铺或正挂、无模特、无水印、主体占比 > 70%、长边 1024~2048px、PNG/JPG |
| 单品展示图 | 可带模特，用于卡片展示 |
| 成套 look 图 | 统一构图与背景，用于方案卡片 |
| 发型图 | 沿用现有 634×950 规范 |
| 色板图 | 程序化生成（由色值渲染），不手工制图 |
| 体型/脸型图示 | 统一插画风格，避免真人照片的合规风险 |

- 抠图流水线：原图 → BiRefNet 抠图（`TD-07`）→ 白底合成 → 质量抽检 → 入库并置 `tryon_ready = true`
- **版权来源已收口为「全部自采」**（`TD-26`）：不采购授权图库、不使用品牌供图、**禁止抓取电商与社交平台图片**。`license` 字段统一标记 `self_shot`
- AI 生成素材需标注 `ai_generated = true`，符合生成内容标识要求

#### 4.2.1 素材自采流水线（`TD-26` 落地方案）

**为什么定为全部自采**：这是唯一版权彻底干净的路径。图库授权通常限制"用于生成合成内容"的场景，品牌供图受合作关系约束（合作终止即须下架），而素材库是我们的核心资产之一，不能建在别人的授权之上。另外实物在手时属性标注的准确率远高于靠图片反推，而属性准确性直接决定检索与推荐质量。

**五个工序**：

| 工序 | 内容 | 输出 | 质检标准 |
|------|------|------|---------|
| ① 采购 | 按品类与季型需求清单采购实物 | 实物 + 采购凭证 | 覆盖计划中的 `tryon_slot` 与色系分布 |
| ② 拍摄 | 白底棚拍，正面平铺或正挂，无模特 | 原始图（RAW/高质量 JPG） | 见下方拍摄规范 |
| ③ 抠图 | BiRefNet 批量处理 → 白底合成 | 标准化白底图 | 边缘无残留、无破洞，人工抽检通过率 ≥ 90% |
| ④ 标注 | 品类、`tryon_slot`、色值（Lab）、材质、版型、季型适配、场合 | 结构化属性 | 必填项无缺失；色值由实物取样而非图片估计 |
| ⑤ 入库 | 置 `tryon_ready`、`license=self_shot`，归档原始文件 | 可用素材 | 换装接口实测可出图 |

**拍摄规范（`T-P0-22` 需定稿为 SOP）**：纯白背景、均匀无影灯光、主体占比 > 70%、长边 1024~2048px、正面无透视畸变、无水印无标牌遮挡。**规范必须写到新人照做即可的程度** —— 拍摄是重复性工序，标准不明确会导致大量返工，而返工的代价是重新占用棚时。

**产能是本项目的关键路径（必须正视）**：

备案已完成后，素材自采成为**唯一无法靠 AI 辅助开发压缩的工序** —— 采购要等物流、拍摄要占棚时、质检要人眼。因此：

- `T-P0-21` 的核心交付物不是"跑通流程"，而是**测出每周产能**（件/周），据此倒排 300 件 `tryon_ready` 的达成时间
- 若产能不足，**降级路径要提前定好**：优先保证「上衣 + 裤子」两个 `tryon_slot`（换装接口仅支持这两类），其余品类只做「加入搭配」不做「一键试穿」
- **不要用"再等等素材"来阻塞功能上线** —— 功能按已有素材量降级发布，素材持续补充

---

## 5. 建设流程

### 5.1 五个阶段

| 阶段 | 内容 | **V1 产出**（规模见 §9.1） | 人力 |
|------|------|------|-----------|
| **P0 本体定义** | 定义 12 类实体的字段、枚举值、关系；建立属性字典 | Schema 文档 + 数据库表 | 产品 + 架构 + **顾问评审**（须在建表前） |
| **P1 专家冷启动** | **全职形象顾问**撰写核心规则、色板、风格定义；产品整理场景模板 | **400 条规则** + 12 季色板 + 9 型风格 + 20 场景 | **全职顾问 1 人** + 产品 1 人，按实测产能倒排 |
| **P2 素材生产** | **自采**：采购 → 拍摄 → 抠图 → 属性标注；60 款发型补齐标签 | **300 件 `tryon_ready`** + 60 发型标签 | 运营 2 人，产能待 `T-P0-21` 实测 |
| **P3 方案组装** | 由规则 + 单品组合出成套 look，顾问审核 | **100 套 Outfit** | 顾问 + 运营 |
| **P4 半自动扩充** | LLM 从专业书籍/公开资料抽取候选知识 → **人工审核后入库** | V2 起持续扩充至长期目标 | 持续 |

> **关键判断**：P1（专家冷启动）不可跳过、不可用大模型代替。这批规则是产品专业性的地基，也是唯一无法被竞品快速复制的资产。用 LLM 生成规则再让顾问审核，效率高于纯人工，但**审核环节是准确率红线，不可省略**。

> ⚠️ **本表已删除全部周期估算**（原有「1 周」「2 周」「3~4 周」）。全职顾问与自采流水线的实际产能需由 `T-P0-20`/`T-P0-21` 实测后倒排 —— **凭估算排期在这两项上风险最高**，因为它们是备案解除后唯一无法靠 AI 辅助开发压缩的工序。

#### 5.1.1 全职形象顾问的工作流（`TD-27` 落地方案）

**为什么是全职而非外部按条计酬**：规则库不是一次性交付物。V1 的 400 条写完只是起点，之后要根据用户反馈与结论修正率反复校准 —— 而按条计酬的外部顾问在"交付完成"后就没有继续投入的动力，恰恰错过质量提升最关键的阶段。另外黄金评测集若由多位外部顾问分批标注，口径漂移几乎不可避免，而黄金集是所有质量指标的基准，口径一旦不稳，后续准确率数字就失去意义。

**顾问的四项职责（按投入顺序）**：

| # | 职责 | 交付物 | 与开发的接口 |
|---|------|-------|------------|
| 1 | 本体 Schema 评审 | 修订意见 | 到岗第一件事。字段设计错了后面全要返工，**必须在建表前完成** |
| 2 | 规则库撰写与校准 | **V1 400 条**，长期 800~1200 条（含 `is_hard` 标记与解释链） | 通过运营后台自行录入，不经工程转录 |
| 3 | 黄金评测集标注 | **330 例，分四个子集**（见 §7 黄金集子集表） | 单人标注保证口径一致 |
| 4 | 持续校准 | 按结论修正率与用户反馈迭代规则 | 长期职责，是全职的主要理由 |

**这对运营后台提出了更高要求**：顾问是后台的**日常使用者**而非偶尔录入者。因此后台的易用性直接决定规则库产能 —— 一个难用的后台会让顾问的有效产出打对折。这是 `TD-25` 把极简后台从 Phase 2 提前到 V1 的核心原因，也意味着后台应在顾问到岗后**根据其真实使用反馈快速迭代**，不能一次交付就不管。

**排期上的含义**：顾问到岗时间直接决定 P1 启动时间，进而决定 M2 与 M3 的时间。因此 `T-P0-20`（招聘）应与技术验证**并行且最早启动**，不要等技术方案确定后再招人。

### 5.2 内容来源与合规

| 来源 | 使用方式 | 注意事项 |
|------|---------|---------|
| 专业书籍/教材（色彩理论、服装造型学） | 提炼知识点，**不得整段摘录** | 版权风险，需重述表达 |
| **全职形象顾问**（`TD-27`） | 直接撰写与校准，通过后台录入 | 建立署名与背书（可作为营销资产） |
| 公开时尚媒体/品牌资料 | 趋势类参考 | 标注来源，不复制图片 |
| 用户 UGC 与行为数据 | 高采纳方案入候选库 | 需审核 + 用户授权 |
| AI 生成 | 初稿与扩充 | 必须人审，标注 `ai_generated` |
| **单品图像素材** | **全部自采实拍**（`TD-26`） | 不采购图库、不用品牌供图、不抓取平台图片；保留采购凭证与原始文件 |

### 5.3 数据治理

- **版本化**：知识库整体带版本号（如 `kb-v1.3`），报告与推荐记录生成时使用的知识库版本，便于问题追溯与结论复现
- **审核工作流**：`草稿 → 顾问审核 → 抽检 → 发布`，每条知识记录 `reviewer` 与 `reviewed_at`
- **变更影响评估**：修改高优先级规则前，跑黄金集回归，评估对历史报告的影响
- **运营后台**：必须提供知识库管理后台（增删改查 + 审核 + 版本对比 + 效果看板），否则知识库无法迭代。**V1 就要做极简版**（`TD-25`）—— 全职顾问是它的日常使用者，后台易用性直接决定规则库产能。

---

## 6. 检索与推理链路

### 6.1 混合检索链路（不能只用向量 RAG）

纯向量 RAG 的致命问题：它会召回"语义相似"的内容，但无法保证"不违反硬约束"。例如用户明确不接受短裙，向量检索仍可能召回一篇讲短裙搭配的优质内容并被模型采用。因此必须是**规则前置 + 向量召回 + 图谱扩展 + 重排**的混合链路：

```
用户 query（如"下周有面试，帮我搭一套"）
   ↓
① 意图识别 + 槽位提取（场景=面试，季节=秋，缺失=行业）
   ↓
② 读取记忆（L0/L1/L2）：A型体型 / 溜肩 / 柔夏型 / 自然优雅 / 禁忌：短裙、露肩
   ↓
③ 【硬过滤】用结构化条件筛选候选集
    · 场景 = 面试 且 正式度 ≥ 3
    · 温度带 ∈ 当前城市天气区间
    · fit_profile.body_shape 包含 A型
    · 颜色 ∈ 柔夏色板（ΔE 阈值内）
    · 排除命中用户禁忌的方案       ← 这一步决定了结论不会踩雷
   ↓
④ 【规则引擎】执行命中的规则（体型/色彩/场景/风格），生成约束与建议属性组合
   ↓
⑤ 【向量召回】在候选集内做语义检索（Outfit + 专业解释文本），Top-K = 20
   ↓
⑥ 【图谱扩展】沿实体关系补充关联知识（推荐单品 → 适配配饰 → 适配发型）
   ↓
⑦ 【重排】综合打分：规则匹配度 40% + 用户偏好 25% + 方案质量分 20% + 采纳率 10% + 趋势 5%
   ↓
⑧ 【生成】LLM 组织语言：输入 = 画像摘要 + 规则结论 + Top3 方案 + 检索片段
    · 要求引用知识 ID，便于溯源与"为什么推荐"
    · 禁止引入检索结果之外的具体单品或色值
   ↓
⑨ 【校验】输出后检查：是否含禁忌项？色值是否在色板内？是否自相矛盾？
   ↓
⑩ 【素材绑定】为方案匹配 tryon_ready 素材 → 展示"一键试穿"
```

### 6.2 「为什么推荐」的实现

图谱路径可直接转成用户可读的解释链，这是专业感的具体来源：

```
你是 A 型身材 + 溜肩
  → 需要「视觉重心上移 + 肩部建立结构」
    → 推荐 泡泡袖 / 小垫肩上衣，V 领拉长颈部线条
      → 你的季型是柔夏，所选灰蓝在你的最佳色板内
        → 搭配高腰阔腿裤修饰下半身，整体正式度 4 符合面试场景
```

### 6.3 性能与缓存
- 硬过滤走数据库索引，P95 < 50ms
- 向量检索 Top-K，P95 < 200ms
- 高频 query（"面试穿什么"）+ 相同画像分桶 → 结果缓存 24h
- 通用解释类文本（如"什么是柔夏型"）静态缓存，不走 LLM

---

## 7. 质量保障

#### 黄金集的四个子集（🔒 唯一事实源）

> 此前七处文档给出过 200 / 100 / 30 等不同数字，看似矛盾，实际是**四个用途不同的子集**，但没有一处说清它们的关系。下表明确定义，`FR-KB-11`、`FR-AGT-05`、`FR-RPT-07`、美学报告 §9.4、产品方案 §6.1.2 **一律引用本表**。

| 子集 | 规模 | 用途 | 标注内容 | 引用编号 |
|------|:----:|------|---------|---------|
| ① **检索黄金集** | **100 条** query | 校验混合检索的 Top-5 命中率 ≥ 80% | query → 期望命中的知识条目 ID | `FR-KB-11`、`FR-AGT-04` |
| ② **Agent 问答黄金集** | **100 例** 对话 | 校验回答质量与**禁忌违反数 = 0** | 问题 → 标准答案要点 + 红线项 | `FR-AGT-05` |
| ③ **诊断黄金集** | **100 例** 人像 | 校验体型/脸型/季型准确率（两档门槛见美学报告 §9.4） | 照片 → 顾问标注的各维度真值 | `FR-RPT-05` |
| ④ **报告结构黄金集** | **30 例** 报告 | 校验报告结构完整性、术语释义覆盖、无贬损表述 | 输入 → 期望的章节与字段完整性 | `FR-RPT-07` |
| **合计** | **330 例** | — | **全部由全职顾问单人标注**，保证口径一致（`TD-27`） | — |

**为什么必须分开而不是合成一个大集**：四者的失败后果完全不同 —— ①②退化说明知识库或检索有问题，③退化说明视觉算法有问题，④退化说明生成链路有问题。合成一个集会让"准确率下降了"这句话失去可操作性，定位不到该修哪里。

| 机制 | 说明 |
|------|------|
| **准确率门槛** | 知识准确性 ≥ 95%；禁忌项违反率 = 0（红线，任何一例都要阻断发布） |
| **回归测试** | 每次知识库版本发布前全量跑黄金集，不达标不发布 |
| **一致性校验** | 入库流水线校验：枚举值合法性、色值与图像一致性、规则冲突检测、孤儿实体检测 |
| **线上监控** | 采纳率、"不满意"反馈率按知识 ID 归因，定位低质量条目 |
| **用户反馈闭环** | 报告/建议页的"这条不准"反馈 → 人工复核 → 修正知识条目 → 版本发布 |

---

## 8. 更新与运营机制

| 内容类型 | 更新频率 | 责任方 |
|---------|---------|--------|
| 流行趋势（类目⑫） | 月更 | 内容运营 |
| 场景模板与季节方案 | 季更（换季前 1 个月） | 内容运营 + 顾问 |
| 单品素材库 | 双周新增 | 素材运营 |
| 搭配方案 Outfit | 双周新增 20~30 套 | 内容运营 |
| 核心规则（体型/色彩） | 季度复审 | 形象顾问 |
| 本体 Schema | 半年评估 | 产品 + 架构 |
| 高频问题驱动补充 | 每周看板 → 补齐知识缺口 | 产品运营 |

**知识缺口发现机制**：统计 Agent 回答中"知识未命中"的 query（无检索结果或低相似度），每周输出 Top 20 缺口清单，驱动定向补充。这是知识库从"人工规划"走向"数据驱动"的关键。

---

## 9. 规模与成本估算

### 9.1 知识库规模（🔒 唯一事实源）

> 全项目引用本表。产品方案 §2.5.2 / §2.8、`FR-KB-*`、`T-P2-*` **不得复述数值**。此前「第一版目标」列与文末「分期建议」自相矛盾（规则 800 vs 400、方案 300 vs 100），已合并为下表两列。

| 项目 | **V1 硬指标**（上线门槛） | 长期目标 | 说明 |
|------|:---------------------:|--------|------|
| 规则条目 | **400 条** | 800~1200 条 | V1 覆盖 5 体型 × 主要场景；长期覆盖 5 体型 × 13 局部 × 场景 |
| 单品实体 | **300 件 `tryon_ready`** | 800~1500 条 | 试穿闭环的最小可用量；全部自采（`TD-26`） |
| 搭配方案 | **100 套** | 300~500 套 | V1 覆盖 4 场景 × 主要季型；长期覆盖 4 场景 × 12 季型 |
| 色彩条目 | 400 色 + 12 套色板 | 同 | 一次做完，无需分期 |
| 发型标签 | 60 款全量打标 | 同 | 补齐现有发型库，一次做完 |
| 文本知识块 | 800 块 | 1500 块 | 用于 RAG |
| 图像资产 | 1000 张 | 2000 张 | 含单品/look/发型/图示 |

**为什么 V1 只做这些就够**：规则 400 条 + 单品 300 件 + 方案 100 套 + 发型 60 款打标 + 12 套色板即可支撑初级报告与基础对话。**不要为了知识库的完整性阻塞首版上线** —— 知识库是持续运营的资产，V1 的目标是跑通"生产 → 检索 → 建议 → 试穿"的闭环，而不是把库填满。

### 9.2 成本估算

| 项目 | 估算 | 说明 |
|------|------|------|
| 人力投入 | **全职顾问 1 人**（`TD-27`）+ 内容运营 2 人 + 开发 1.5 人月（后台） | 预估 ¥12~18 万 |
| 自采单品成本 | 300 件 × 单件采购均价 + 棚拍与抠图人工 | ⚠️ 需在 `T-P0-21` 跑通流水线后按实际单件成本核算（自采模式新增，`TD-26`） |
| 存储与检索成本 | 月度 < ¥2000 | 向量库 + 对象存储 + CDN |

---

## 10. 待确认事项（已收口）

### 10.1 已确认

| 原待确认项 | 结论 | 依据 |
|-----------|------|------|
| 向量库 | **PostgreSQL + pgvector**，不引入 Milvus/Qdrant。知识库向量在万级到十万级，远未到需要专用库的量级；且检索链路的第一步是硬过滤（季型、场合、体型禁忌），这是典型 SQL `WHERE`，专用向量库的元数据过滤反而是短板。**切换条件**：向量 > 500 万，或过滤后召回 p99 > 200ms 且确认无法通过索引优化解决 | `TD-08` |
| 图谱 | **PG 邻接表 `kb_relation` + 递归 CTE**，不上 Neo4j。我们的图查询是有界的 1~3 跳浅层遍历，递归 CTE 完全够用；Neo4j 的价值在任意深度路径与图算法，我们不需要，却要为它承担独立运维与数据同步 | `TD-09` |
| 规则引擎 | **自研数据驱动决策表**，规则以 JSON DSL 存库。规则形态高度规整（条件 → 建议/禁忌 → 权重 → 依据），本质是决策表；且必须由顾问在后台维护而非写代码。通用规则引擎的表达能力我们用不到 20%，却要接受其 DSL 学习成本与调试困难。自研可直接透出「命中规则 ID 列表」，天然满足可解释与可审计 | `TD-10` |
| **抠图模型** | **BiRefNet**（开源可商用）自建，离线批处理。⚠️ **禁用 RMBG-2.0** —— 它是被引用最多的「开源抠图模型」，但许可是 **CC BY-NC 4.0，仅限非商业使用**，商用需与 BRIA 单独签协议。同样提醒：`rembg` 库本身是 MIT，但其封装的 18+ 模型各自许可不同 | `TD-07` |
| 抠图验收标准 | 10 件样本走通「原图 → 抠图 → 白底标准化 → 规格校验 → 入库 → 换装可用」全流程；人工质检通过率 ≥ 90%；边缘毛刺与透明材质失败样本走人工修图 | `FR-KB-08`、`T-P0-12` |
| **12 季色彩体系版权** | **自建色板，不引进外部授权**。四季/十二季理论本身属思想与方法，不受著作权保护，可借鉴其冷暖/明度/纯度三维划分逻辑；但「四季色彩」「CMB / Color Me Beautiful」在国内**存在注册商标**，不得用作服务名称、功能名称或宣传标识；他人的具体色布/色卡集合（如某机构的「20+2 鉴定色布」）属独创性劳动成果，直接复制其色值集合存在侵权风险 | `TD-18` |
| 是否引进外部内容授权 | **不引进**。改为自建色板 + **全职顾问**撰写与校准，既规避授权与商标风险，又形成自有资产 | `TD-18`、`TD-27` |
| **单品素材来源** | **全部自采实拍**。不采购授权图库、不使用品牌供图。版权最干净、规格可统一、属性可在拍摄时同步准确记录。**代价是这成为项目的关键路径**（备案已完成后，它是最长工序），详见 §4.2.1 | `TD-26` |
| **形象顾问合作模式** | **全职编制**。规则库需持续迭代而非一次交付；顾问是运营后台的日常使用者；黄金集需单人标注保证口径一致。详见 §5.1.1 | `TD-27` |
| 知识库管理后台排期 | **提前到 V1，做极简版**（条目 CRUD、规则编辑与发布、素材上传与抠图触发、审核、发布回滚）。知识库是持续运营的资产，靠改数据库运营意味着每次内容更新都要工程介入，冷启动阶段会直接卡住内容生产节奏。完整的版本管理与效果看板留到 V2 | `TD-25`、`FR-ADM-01`~`04` |
| Embedding 模型 | 自建 **BGE-M3**。条目量级不大且更新不频繁，离线批量向量化即可；自建避免向量维度被厂商绑定。`kb_chunk` 保留 `embedding_model` 与 `embedding_version` 字段以支持双写平滑迁移 | `TD-22` |
| 属性标注降本 | 引入**视觉大模型辅助预标注**（智谱提供开箱的衣物识别智能体 `clothes_recognition_agent`，可输出品类/颜色/材质/款式/版型/图案/风格/领型等结构化属性）+ 人工复核。预标注准确率 ≥ 70% 即达标（目的是降低人工量，不是替代人工） | `TD-04`、`FR-KB-12` |

### 10.2 仍待业务输入

本文档的待确认事项**已全部收口**，无遗留项。

需要持续关注的不是决策，而是**两项产能数据**（它们决定排期，但只能实测得出）：

| 待实测 | 任务 | 用途 |
|-------|------|------|
| 自采流水线每周产能（件/周） | `T-P0-21` | 倒排 300 件 `tryon_ready` 的达成时间 |
| 全职顾问规则产出速率（条/周） | `T-P0-20` | 倒排 M2 知识库可运营的时间 |

### 10.3 本轮补充的实现约束

| 约束 | 说明 | 依据 |
|------|------|------|
| 硬约束必须在生成后强制校验 | 规则的 `is_hard=true` 项不能只当作提示词。LLM 输出的搭配方案要逐项比对禁忌规则，违反则重新生成或剔除。这是「禁忌违反 = 0」这条质量指标的唯一可靠实现方式 | `TD-10`、`FR-KB-05` |
| 解释链的事实部分不得由 LLM 生成 | 「为什么推荐」的推理路径必须来自数据库的图谱遍历路径与命中规则 ID，LLM 只做自然语言转写。否则解释听起来专业但不可审计，恰恰违背自建知识库的初衷 | `TD-09`、`FR-AGT-13` |
| 知识库版本号驱动缓存失效 | 所有检索缓存键带全局 `kb_version`，发布时版本号 +1，旧缓存自然失效，不需精确追踪受影响缓存 | 架构 §10 |
| 内容伦理约束写入规则库 | 「描述而非评判」「不使用缺陷框架」「不做医疗判断」等红线需同时落在三处：系统 Prompt、规则库禁忌用词表、生成后校验。缺一处就会漏 | 合规方案 §3 |
| 每条内容必须有 `source` 与 `license` | 杜绝来源不明的内容混入，这是版权风险的第一道闸门 | `FR-KB-03` |

---

**文档版本**：v1.2
**创建日期**：2026-08-11
**更新日期**：2026-08-13
**作者**：产品团队
**状态**：待评审
**变更说明**：
- v1.2（2026-08-13）：业务决策收口，§10 已无遗留待确认项
  - **§4.2.1 新增「素材自采流水线」**（`TD-26`）：素材来源定为**全部自采实拍**，不采购图库、不用品牌供图。给出五个工序（采购→拍摄→抠图→标注→入库）、拍摄规范要点、以及产能倒排要求。⚠️ 明确指出**备案完成后素材自采成为项目关键路径**，并预设了产能不足时的降级路径（优先保上衣+裤子两个 `tryon_slot`）
  - **§5.1.1 新增「全职形象顾问工作流」**（`TD-27`）：顾问定为**全职编制**，四项职责按投入顺序排列（本体 Schema 评审须在建表前完成 → 规则库撰写 → 黄金集标注 → 持续校准）。指出顾问是运营后台的日常使用者，后台易用性直接决定规则库产能
  - **§5.1 修正两处口径**：V1 单品硬指标由「800+」改为**300 件 `tryon_ready`**；删除「3~4 周」等周期估算，改为按 `T-P0-20`/`T-P0-21` 实测产能倒排
  - §9 成本估算新增自采单品采购与棚拍成本项
- v1.2 rev.2（2026-08-13）：文档一致性评审修订
  - **§9.1 升为知识库规模的唯一事实源**，并拆为「V1 硬指标」与「长期目标」两列。此前四处文档给出五套互相矛盾的数字（单品 800~1500 / 800 / 400 / 300，规则 800~1200 / 800 / 400），且本文 §9 表格与其自己的文末分期建议就自相矛盾。现统一为 **V1 = 规则 400 / 单品 300 `tryon_ready` / 方案 100**，长期目标另列
  - **§7 黄金集拆为四个子集共 330 例**（检索 100 / Agent 问答 100 / 诊断 100 / 报告结构 30）。此前七处文档的 200/100/30 看似矛盾，实为不同子集但无一处说清。**分开的理由是四者的失败后果完全不同**：①②退化指向知识库或检索、③指向视觉算法、④指向生成链路 —— 合成一个集会让"准确率下降了"失去可操作性
  - **修正两处计数错误**：脸型 8 种→**7 种**（与美学报告 §4 维度 #8 一致）；局部特征 12 项→**13 项**（按 §3.2 ④ 实际列举数）
  - **§5.1 删除全部周期估算**（原「1 周」「2 周」），与「按实测产能倒排」的排期原则统一
- v1.1（2026-08-13）：§10 待确认事项收口，10 项确认、2 项转入业务输入；关键变更三处 —— ① 抠图明确用 BiRefNet 并**禁用 RMBG-2.0**（非商用许可）；② 12 季色彩体系改为**自建色板 + 规避 CMB/四季色彩商标**，不引进外部授权；③ 知识库管理后台从 Phase 2 **提前到 V1 极简版**。另补充硬约束强制校验、解释链事实不得由 LLM 生成、版本号驱动缓存失效等实现约束
- v1.0（2026-08-11）：初始版本

**关联文档**：
- [文档索引](./README.md)
- [需求规格说明](./需求规格说明.md)（本文需求对应 `FR-KB-01`~`FR-KB-13`、`FR-ADM-*`）
- [美搭 · 智能穿搭美学助手 产品方案](./鸿蒙美搭-智能穿搭美学助手-产品方案.md)
- [技术架构文档](./技术架构文档.md)（kb 域数据模型见 §6.2，混合检索实现见 §8.3）
- [技术选型与调研报告](./技术选型与调研报告.md)
- [合规与安全方案](./合规与安全方案.md)
- [美学报告需求文档](./美学报告-需求文档.md)
- [穿搭 Agent 需求文档](./穿搭Agent-需求文档.md)
- [用户系统与记忆系统需求文档](./用户系统与记忆系统-需求文档.md)