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

美学知识库建设方案

本文档定义「美搭」App 美学/穿搭知识库的分类体系、模态构成、构建流程与检索链路，与 产品方案、美学报告需求文档、穿搭 Agent 需求文档、用户系统与记忆系统需求文档 配套使用。

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 —— 规则引擎的燃料

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

{
  "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"，而非零散规则。

{
  "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 种模态，每种有明确的存储、索引与用途分工：

模态	内容	存储与索引	用途	优先级
① 结构化数据 Structured	属性字典、枚举值、适配矩阵、色值、发型标签	关系型数据库 + 二级索引	硬过滤与计算：确定性筛选、可审计、零幻觉	P0
② 规则 Rule	IF-THEN 条件规则（类目⑩）	关系库 + 规则引擎（决策表）	核心结论生成：报告结论、推荐约束	P0
③ 文本 Text	定义、专业解释、场景模板、报告话术、口诀	全文索引 + 向量索引（分块 200~400 字）	RAG 生成：解释"为什么"、组织语言	P0
④ 图像 Image	单品白底图、成套 look 图、发型图、色板图、体型图示	对象存储 + CDN + 图像向量（CLIP 类）	展示 + 试穿素材 + 图搜：卡片渲染、换装 API 入参、以图找相似	P0
⑤ 色彩数值 Color / Numeric	HEX / RGB / HSL / Lab、比例阈值、温度带	关系库 + 向量距离计算	数值匹配：肤色-季型归属、ΔE 色差、比例判定	P0
⑥ 图谱 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 硬指标」与「长期目标」两列。此前四处文档给出五套互相矛盾的数字（单品 8001500 / 800 / 400 / 300，规则 8001200 / 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）：初始版本

关联文档：

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