meida/docs/用户系统与记忆系统-需求文档.md

# 用户系统与记忆系统需求文档

> 本文档为「美搭」App 的用户体系与个性化记忆体系需求文档，与 [产品方案](./鸿蒙美搭-智能穿搭美学助手-产品方案.md)、[美学报告需求文档](./美学报告-需求文档.md)、[穿搭 Agent 需求文档](./穿搭Agent-需求文档.md)、[美学知识库建设方案](./美学知识库-建设方案.md) 配套使用。

## 1. 概述

### 1.1 为什么需要记忆系统

穿搭建议的价值高度依赖"懂这个人"。同一句"帮我搭一套通勤 look"，对梨型身材柔夏型的设计师和对倒三角身材深冬型的销售，正确答案完全不同。没有记忆系统，产品只能给出百科式的通用答案，而通用答案在小红书上免费且更丰富——**记忆系统是本产品相对于内容平台和通用大模型的核心护城河**。

同时，记忆系统解决三个具体问题：

| 问题 | 无记忆的表现 | 有记忆的表现 |
|------|-------------|-------------|
| 重复询问 | 每次对话都问"你的身高体重体型是？" | 一次诊断，永久复用 |
| 建议漂移 | 今天推荐紧身裙，明天说避免紧身 | 结论一致且可解释 |
| 无法进化 | 用户拒绝 10 次露肩款，第 11 次还推荐 | 自动学习禁忌，越用越准 |

### 1.2 设计目标

1. **一次输入，全局可用**：任何一处采集的用户信息，所有模块都能读到
2. **越用越懂**：显式设置 + 隐式行为共同塑造画像，无需用户额外操心
3. **用户可见可控**：记忆全部可查看、可修改、可删除（既是信任基础，也是《个人信息保护法》的硬要求）
4. **可解释**：任何推荐都能回答"为什么推荐给我"，追溯到具体记忆项
5. **成本可控**：注入模型的记忆有 token 预算上限，不做无脑全量拼接

---

## 2. 用户系统

### 2.1 账号与登录

| 方式 | 优先级 | 版本 | 说明 |
|------|-------|:----:|------|
| **华为账号授权登录**（UnionID/OpenID） | P0（鸿蒙首发主路径） | V1 | 标准 OAuth 授权，**无特殊资质门槛** |
| 手机号 + 验证码 | P0 | V1 | 通用兜底，覆盖不愿授权华为账号的用户 |
| **游客模式** | P0 | V1 | 未登录即可体验核心功能，降低首启流失 |
| ⏸ 华为账号**一键登录**（直接获取绑定手机号） | **P1（降级）** | **V2** | ⚠️ 需**企业开发者资质** + `quickLoginMobilePhone` scope。V1 不做（`TD-29`） |
| 微信 / Apple 登录 | P2 | V2+ | 多端扩展阶段接入 |

> **为什么一键登录从 P0 降为 P1**：它需要企业开发者资质与额外 scope 申请，而它带来的收益只是"少输一次验证码"——**这是体验优化，不是能力缺口**。为它阻塞 V1 排期不值得。登录模块按多方式抽象设计，资质到位后补上属于纯增量改动（`TD-29`）。
>
> **仍需保留的前置项**：AGC 的 **SHA256 证书指纹需配置两套**（调试证书与发布证书），且指纹添加后最迟 25 小时生效。这与资质等级无关，漏配会导致登录**在发布包中直接失败而调试包正常** —— 这是个高频踩坑点，必须写入发布手册。

#### 游客模式与数据迁移（关键设计）

用户第一次打开 App 就被要求注册，是最大的流失点之一。设计如下：

- 游客获得本地 `guest_id`（设备级），可完成：1 次换装、1 次发型试戴、1 次初级报告、3 次 Agent 对话
- 游客数据（画像、试穿结果、报告）存储在本地 + 服务端匿名档案
- 触发注册时机：游客额度用尽 / 主动保存收藏 / 主动分享 → 提示"注册以永久保存你的形象档案"
- **注册后自动迁移**：`guest_id` 全部数据归属到 `user_id`，迁移过程对用户无感，且必须幂等（防重复迁移）
- 同一设备多游客、同一游客多设备的冲突以"先注册者绑定"为准，冲突时提示用户选择

### 2.2 用户数据模型

> 表名与列清单以《技术架构文档》§6.2 为唯一事实源。本节只写产品语义，**不再自造表名**。

#### 账号主表 `id_user`

内部主键与账号状态，与外部身份解耦。

| 字段 | 说明 |
|------|------|
| `user_id` | 雪花号，全局唯一。**不用手机号或 UnionID 做主键** |
| `nickname` / `avatar_key` | 昵称、头像 |
| `register_source` | 注册渠道（归因） |
| `status` | `active` / `frozen` / `deleting` / `deleted` |
| `created_at` / `last_active_at` | — |

**不在本表的字段（此前误画在主表上）**：

| 数据 | 实际位置 | 原因 |
| --- | --- | --- |
| 手机号 | `id_user_identity`（`provider='phone'`，`phone_enc` + `phone_hash`） | 登录凭证，不是用户属性；加密与检索要和华为身份走同一张映射表 |
| 华为账号 | `id_user_identity`（`provider='huawei'`，`union_id` / `open_id`） | 同上 |
| 性别 / 生日 | 画像与问卷（`pf_profile` / 报告问卷），不进账号主表 | 生日用途限于权益与年龄段，五行推算已取消（`TD-31`） |
| 会员档位 / 到期 | V2 的 `bl_membership`；V1 不建 | V1 全员同一套配额，主表预留会员字段会造成「看起来能升级」的假接口 |
| 余额 | `bl_wallet.balance`，以 `bl_ledger` 为真相 | 主表冗余余额会引入两处不一致 |

#### 登录身份表 `id_user_identity`

一个用户可有多条外部身份。`UNIQUE(provider, union_id)`。手机号检索用 `phone_hash`，展示用解密后掩码。

#### 授权记录表 `id_consent`（合规必需）

| 字段 | 说明 |
|------|------|
| `consent_type` | `privacy` / `face` / `personalization` / `push` / `minor`。**人脸必须独立成行** |
| `doc_version` | 协议版本号 |
| `granted` | 是否同意 |
| `granted_at` / `revoked_at` | 授权与撤回时间 |
| `client_ip` / `ua` | 授权来源留证 |

> 人脸信息属敏感个人信息，必须**单独授权**并可**单独撤回**；撤回后停止相关功能并删除派生数据。

### 2.3 用户中心功能

```
我的
├─ 形象档案
│   ├─ 我的形象报告（历史版本时间轴 + 前后对比）
│   ├─ 我的美学画像（结构化维度，可逐项修正）
│   └─ 我的记忆（偏好与禁忌管理，见 §3.7）
├─ 我的作品
│   ├─ 换装记录
│   ├─ 发型记录
│   └─ 收藏夹（搭配 / 发型 / 单品 / 色板）
├─ 我的衣橱（V2）
├─ 我的额度（剩余次数、任务换额度）   ← V1；无价格与购买入口
│   └─ 会员中心（权益、点数、订单）    ← V2
├─ 设置
│   ├─ 隐私与授权管理（单项开关、撤回）
│   ├─ 数据管理（导出个人数据 / 清空照片 / 注销账号）
│   ├─ 内容偏好（关闭个性化推荐）
│   ├─ 关于（**模型名称 + 备案编号公示**，合规必需）
│   └─ 通知设置
└─ 帮助与反馈
```

### 2.4 权益设计：V1 只有配额，没有付费

**原方案的成本风险**："会员 ¥9.9/月 = 无限换装"在成本上不成立 —— 换装是长耗时 GPU 推理，单次成本在角到元量级，重度用户一个月可消耗数十元，**会员越活跃越亏损**。

**V1 的解法：完全不收费，用配额限制控成本**（`TD-28`）。

#### 2.4.1 V1 配额表

> 🔗 **配额数值的唯一定义位置是《产品方案》§3.2**（含**游客额度**一列）。本节不再复述数值，避免出现第二套口径。此前游客额度只写在 §2.1 的叙述里、没进配额表，导致 `FR-ACC-02` 的验收标准无法判定 —— 已在产品方案 §3.2 补入。

所有注册用户共用同一套配额，无会员、无点数购买；游客另有一套**设备维度的终身额度**（不是每日额度）。

**任务奖励额度**（全部不涉及金钱）：每日签到、完善画像资料、给报告结论打反馈、邀请好友、分享报告长图。

**三条不可违反的纪律**：

1. **额度是服务端硬限制**（`FR-BILL-06`）—— 服务端校验后直接拒绝，不存在绕过路径。这是成本可事前算准的前提。
2. **文案中不出现任何价格或购买字样**（`FR-BILL-07`）—— 额度用尽的提示是「今日额度已用完，明天再来，或做个任务多换 3 次」，**不是**「升级会员解锁」。V1 出现价格暗示会污染 V2 的定价空间，也会让用户觉得这是个处处收费的产品。
3. **每次消耗前置提示剩余量**，禁止静默扣减。

#### 2.4.2 V2 权益规划（仅作架构预留，V1 不实现）

> ⚠️ 下表价格全部为**占位**，需按 V1 采集的真实数据重算（`TD-16`、`T-P6-16`）。

| 权益项 | 免费 | 会员 | 高级 |
|--------|------|------|------|
| 每日换装 / 发型 | 3 次 | 10 次 | 20 次 |
| 每日 AI 对话 | 10 轮 | 100 轮 | 不限（防刷上限） |
| 月度权益点数 | 0 | 待定 | 待定 |
| 初级美学报告 | 每 30 天 1 次 | 每 7 天 1 次 | 不限（每日 ≤3） |
| 全面美学报告 | 单次付费 | 折扣价 | 含 1 次/季 |
| 我的衣橱容量 | 20 件 | 200 件 | 不限 |
| 记忆条数上限 | 200 条 | 500 条 | 不限 |
| 高清导出 / 去水印 | ❌ | ✅ | ✅ |

**V1 → V2 免数据迁移的关键设计**：配额账本与点数账本是**同一张表**（`bl_wallet` + `bl_ledger`）。V1 只使用 `system_grant` / `consume` / `refund` 三种 `tx_type`，V2 增加 `purchase` / `gift`。消耗侧的预扣三段式逻辑完全复用，V2 只需新增「购买」这一条发放路径（架构 §6.2、§7.4）。

### 2.5 配额与计量（V1 最重要的隐性交付物）

- 所有 AI 能力调用统一走**配额中心**：`check(user_id, ability) → allow/deny`，**服务端校验，客户端提示仅为体验**
- 消耗采用**预扣三段式**：`reserve`（冻结）→ `commit`（确认）/ `refund`（退还）。长耗时任务可能失败，直接扣会产生「扣了次数没拿到结果」的客诉 —— **V1 没有客服退款兜底手段，只能靠机制保证**
- 每次调用落 `ob_ai_call`：`user_id / scene / provider / model / tokens / duration / cost / result / trace_id`
- 每次额度变动落 `bl_ledger` 流水，余额可由流水重算校验，**每日自动对账，不一致告警**
- 失败调用不扣额度（区分用户侧失败与服务端失败）；**预检拦截发生在预扣之前**，不合格照片不消耗额度
- 风控：设备维度 + 账号维度 + IP 维度三重限流，异常账号冻结并进人工审核

> ⚠️ **为什么 V1 不收费反而让计量更重要**：V1 没有收入，成本是唯一的财务变量；同时 `ob_ai_call` 与 `bl_ledger` 是 **V2 定价的唯一数据来源** —— 单次真实成本与人均使用频次都从这里出。**埋点缺失的功能，在 V2 定价时就是一个必须靠猜的空洞**。这一项不允许「先上线后补埋点」（`NFR-COST-01`、`FR-BILL-08`）。

### 2.6 账号生命周期

| 操作 | 处理 |
|------|------|
| 注销 | 二次确认 + 短信验证 → 状态置 `deleting`，7 日冷静期内可恢复，到期彻底删除全部个人数据与派生画像 |
| 数据导出 | 提供 JSON + 图片包下载（画像、报告、记忆、作品），24h 内生成 |
| 清空照片 | 单独入口，删除所有上传原图与结果图（保留结论型画像，需明确告知） |
| 撤回人脸授权 | 停用报告与换装功能，删除人脸派生特征，保留自评类画像 |
| 冻结 | 违规内容触发，功能受限但数据保留 |

---

## 3. 记忆系统

### 3.1 设计原则

| 原则 | 说明 |
|------|------|
| **分层** | 稳定信息与易变信息分开存储，注入策略不同 |
| **带证据** | 每条记忆记录来源与证据，可回溯、可解释、可撤销 |
| **带置信度** | 显式 > 隐式，新证据 > 旧证据，用户确认 = 最高置信 |
| **会衰减** | 长期未被强化的隐式记忆自动降权，避免陈旧偏好长期干扰 |
| **可编辑** | 用户可见、可改、可删，且改动立即生效 |
| **有预算** | 注入模型的记忆有 token 上限，超出则摘要压缩 |
| **不存敏感原图** | 记忆库只存结论与特征，不存人脸原图 |

### 3.2 分层记忆模型

| 层级 | 名称 | 内容示例 | 写入方式 | 生命周期 | 主要消费方 |
|------|------|---------|---------|---------|-----------|
| **L0** | 身份档案<br>Identity | 性别、生日、身高、体重、职业、城市 | 用户填写 | 长期，随时可改 | 全模块（硬约束） |
| **L1** | 美学画像<br>Aesthetic Profile | 体型、脸型、肤色、季型、量感、直曲、动静、基因/心理风格、核心诉求 | **美学报告生成时写入**（唯一权威源） | 长期，90 天建议复核 | 报告、Agent、换装、发型推荐 |
| **L2** | 偏好与禁忌<br>Preference | 偏好风格/颜色/品类/长度；禁忌项（不穿短裙、不露肩、不接受高饱和）；预算区间；品牌倾向 | 显式设置 + 隐式行为推断 | 长期，隐式项带衰减 | Agent、推荐排序与过滤 |
| **L3** | 事件记忆<br>Episodic | 试穿记录、收藏、分享、采纳/拒绝、对话摘要、报告版本 | 自动埋点 | 180 天滚动 | 相似召回、复盘、主动推荐 |
| **L4** | 会话记忆<br>Working | 当前多轮对话上下文、当前场景槽位（场合/天气/日期） | 运行时写入 | 会话结束或 24h 过期 | Agent 多轮对话 |
| **L5** | 衣橱记忆<br>Wardrobe | 用户已有单品（图片 + 结构化属性 + 使用频率） | 用户上传 + 视觉识别 | 长期，可标记淘汰 | 基于已有衣物的搭配（V2 核心差异化） |

**分层的意义**：L0/L1 是"硬约束"，进任何一次推荐的系统提示；L2 是"排序与过滤器"；L3 是"检索素材"，按需 Top-K 召回而非全量注入；L4 是短时状态；L5 是差异化能力。

### 3.3 记忆项数据结构

```json
{
  "memory_id": "mem_8f3a2c",
  "user_id": "u_10086",
  "layer": "L2",
  "type": "taboo",
  "key": "avoid_category",
  "value": "短裙",
  "display": "不接受短裙",
  "confidence": 0.92,
  "source": "explicit_user_input",
  "evidence": [
    { "type": "chat", "ref": "conv_991", "at": "2026-08-10T21:03:00+08:00", "excerpt": "我从来不穿短裙" }
  ],
  "scope": ["outfit_recommend", "agent_chat", "report"],
  "created_at": "2026-08-10T21:03:12+08:00",
  "last_reinforced_at": "2026-08-10T21:03:12+08:00",
  "decay_after_days": 365,
  "status": "active",
  "user_editable": true
}
```

字段约定：
- `source`：`explicit_user_input`（用户明说）/ `user_setting`（设置页配置）/ `report_vision`（报告视觉分析）/ `self_reported`（自评问卷）/ `behavior_inferred`（行为推断）/ `llm_extracted`（对话抽取）
- `confidence`：见 §3.5 置信度规则
- `status`：`active` / `pending_confirm`（待用户确认）/ `decayed` / `overridden` / `deleted`
- `scope`：该记忆生效的业务域，避免"对话里说的玩笑话"污染报告结论

### 3.4 写入机制

#### ① 显式写入（高置信）
- 问卷填写、设置页配置、报告数据修正
- 对话中的明确陈述："我不喜欢黄色""我 160cm""帮我记住我不穿高跟鞋"
- 对话抽取到显式偏好时，**回执确认**："已记住：不穿高跟鞋。可在「我的记忆」中修改" —— 让用户感知到系统在学习，是信任建立的关键动作

#### ② 隐式推断（低置信，需累积）
从行为中提取候选记忆，不直接生效：

| 行为信号 | 推断方向 | 生效阈值 |
|---------|---------|---------|
| 采纳/试穿某搭配 | 该风格、色系、品类为正样本 | 累积计数，用于排序加权 |
| 收藏 | 强正样本（权重 > 试穿） | 同上 |
| 连续拒绝/换一套 | 该方案的共有属性为负样本 | **同属性连续 3 次拒绝** → 生成 `pending_confirm` 候选 |
| 长时间浏览未操作 | 弱兴趣 | 仅作排序微调，不落记忆 |
| 主动删除某记录 | 负样本 | 计数 |
| 反复搜索某关键词 | 兴趣点 | 3 次以上 → 候选偏好 |

- 候选记忆生成后，选择**恰当时机**征询确认（不打断当前任务，放在下一次推荐结果页）："看起来你不太喜欢露肩款，要设为不推荐吗？[是/否/不再提示]"
- 用户确认 → `confidence = 1.0`，`source` 升级为 `explicit`；用户否认 → 记录反例并不再推断该项

#### ③ 派生写入
- 报告生成完成 → 批量写入 L1 全部维度
- 换装/试戴成功 → 写入 L3 事件
- 对话结束 → LLM 生成 ≤100 字对话摘要写入 L3

### 3.5 置信度与衰减

**置信度初值**：

| 来源 | 初始置信度 |
|------|-----------|
| 用户确认 / 设置页配置 | 1.00 |
| 对话中明确陈述 | 0.90 |
| 报告视觉分析（高置信维度，如体型） | 0.85 |
| 报告视觉分析（争议维度，如十二季细分） | 0.65 |
| 自评问卷 | 0.60 |
| 行为推断（达阈值） | 0.50 |

**衰减规则**：
- 每 30 天未被强化，隐式记忆（`source = behavior_inferred / llm_extracted`）置信度 × 0.9
- 置信度 < 0.3 时状态置 `decayed`，不再参与推荐，但保留可查（用户可恢复）
- 显式记忆与 L0/L1 不衰减，仅通过新证据覆盖
- 每次被新证据强化：`confidence = min(1.0, confidence + 0.1)`，刷新 `last_reinforced_at`

### 3.6 冲突消解

多来源必然冲突（自评"我是苹果型"，视觉分析"梨型"），规则如下：

1. **优先级**：`用户确认` > `显式陈述` > `视觉分析` > `自评` > `行为推断`
2. **同级取新**：同优先级时以时间更新者为准
3. **画像 vs 偏好冲突**：专业结论与用户主观偏好冲突时，**以用户偏好执行，同时给出专业提示**
   > 示例：报告判定不适合正红色，但用户明确喜欢正红色 → 仍然推荐正红色单品，附加建议"可通过下装用低饱和色平衡，或让红色远离面部"
   这条规则很重要：产品不能因为"专业正确"而否定用户喜好，否则会被感知为说教。
4. **视觉覆盖自评**：有照片诊断结果时自动覆盖自评项，并提示用户"已根据照片更新你的体型判定"
5. **冲突留痕**：被覆盖的记忆置 `overridden` 而非删除，保留在历史中可追溯

### 3.7 用户可见可控：「我的记忆」页面

这是合规刚需，也是差异化体验（大多数 AI 产品的记忆是黑盒）。

```
我的记忆
├─ 我的画像（L0 + L1）
│   └─ 逐项展示：值 + 来源 + 置信度标签（"照片诊断" / "你告诉我的" / "我猜的"）
│       └─ 操作：修正 / 恢复系统判定
├─ 我的偏好（L2）
│   ├─ 喜欢：风格标签、颜色、品类（可增删）
│   └─ 不接受：禁忌清单（可增删，删除后不再过滤）
├─ 待确认（pending_confirm）
│   └─ "看起来你不太喜欢露肩款？" [确认 / 否认]
├─ 最近记录（L3，按时间线）
│   └─ 单条可删除（删除后不再参与推荐计算）
└─ 全局操作
    ├─ 关闭个性化推荐（关闭后仅用 L0 通用建议）
    └─ 清空全部记忆（二次确认）
```

- 置信度不向用户暴露数值，用自然语言标签表达（"照片诊断""你告诉我的""我猜的"）
- 任何修改**立即生效**，且明确反馈影响范围："已更新，之后的搭配建议会避开短裙"

### 3.8 记忆检索与注入

**Token 预算是硬约束**，不能把全部记忆塞进提示词。策略：

> 🔗 **本表的分项已被采纳为全局唯一事实源**，完整预算表（含系统提示词、检索知识、用户输入与总输入合计 ≤ 4200）见《技术架构文档》§7.2。本表只管「记忆注入」这一段。

| 阶段 | 处理 | 预算 | V1 是否启用 |
|------|------|------|-----------|
| 画像摘要 | L0 + L1 压缩为固定结构短文本（模板化，非 LLM 生成） | ≤ 250 token | ✅ |
| 偏好摘要 | L2 中 `confidence ≥ 0.5` 的项，按置信度排序取 Top 15 | ≤ 150 token | ✅ |
| 事件召回 | 按当前 query 向量检索 L3，取 Top 3~5 条摘要 | ≤ 200 token | ❌ V2 |
| 会话上下文 | L4 最近 6 轮原文（≤ 400）+ 更早轮次的滚动摘要（≤ 400） | ≤ 800 token | ✅ |
| **记忆注入合计** | — | **≤ 1400 token**（**V1 实际 ≤ 1200**） | — |

**裁剪时硬禁忌永不丢弃**（`FR-MEM-04`）—— 裁掉它会导致推荐用户明确拒绝的品类，属 P0 缺陷。完整裁剪优先级见架构 §7.2。

画像摘要示例（注入 Agent 系统提示的实际形态）：

```
【用户画像】女 / 160cm / 53kg / 设计师 / 上海
体型：梨型(A型)，溜肩，核心诉求：显高显瘦、修饰溜肩与下半身
面部：鹅蛋脸，三庭五眼均匀，中量感，轮廓适中，静态型
色彩：黄二白，柔夏型（低饱和冷调），最佳色：灰蓝/灰紫/雾霾蓝/冷灰粉/浅灰绿
风格：基因自然型 + 心理优雅型 → 自然优雅
【偏好】喜欢：法式、通勤、真丝/棉麻｜不接受：短裙、露肩、高饱和亮色
【近期】3 天前试穿"灰蓝西装 + 冷米黄西裤"并收藏；拒绝过 2 套包臀裙方案
```

- 缓存策略：画像摘要在画像未变更时缓存复用，避免每轮重算
- 未命中记忆时的降级：明确告知"我还不了解你的身材数据，建议先做个形象诊断（1 分钟）"，而不是编造假设

### 3.9 存储与技术形态

> 选型结论见《[技术选型与调研报告](./技术选型与调研报告.md)》`TD-02`/`TD-08`；表结构见《[技术架构文档](./技术架构文档.md)》§6.2。

| 数据 | 存储 | 说明 |
|------|------|------|
| L0 / L1 / L2 结构化画像 | PostgreSQL（`pf_profile` / `pf_diagnosis` / `pf_memory`） | 强一致、可索引、可审计 |
| L3 事件与对话摘要 | PostgreSQL + pgvector | 同一库内完成硬过滤与语义召回，不引入专用向量库 |
| L4 会话状态 | Redis（带 TTL）+ `ag_conversation.rolling_summary` | 高频读写 |
| L5 衣橱单品 | PostgreSQL + COS（图片）+ pgvector（图像向量） | 支持图搜与属性筛选 |
| 变更审计 | 追加写 `pf_memory_event` | 记录每次记忆变更的 before/after 与操作者 |

- 端侧仅缓存画像**摘要**，支持弱网/离线时的基础个性化展示；**不缓存记忆明文**（含体型尺寸等敏感项）
- 所有记忆读写走统一 `MemoryService`，禁止各业务模块直连表，保证冲突消解与审计逻辑唯一

### 3.10 隐私与合规

- 记忆系统写入必须建立在「个性化推荐」授权之上，用户可随时关闭（关闭后仅保留 L0）
- 人脸原图不入记忆库；L1 只存结论型特征
- 记忆数据参与账号注销的彻底删除流程
- 记忆内容不得包含健康、宗教信仰、政治倾向等敏感类别推断（即使用户提及，也不作为记忆项持久化）
- 未成年人账号不启用行为推断类隐式记忆

---

## 4. 与各模块的关系

```
                   ┌──────────────────┐
   照片 + 问卷 ───▶ │   美学报告       │ ──写入 L1──┐
                   └──────────────────┘            │
                                                   ▼
   显式设置 ─────────────────────────────▶ ┌──────────────┐
   对话陈述 ─────────────────────────────▶ │  记忆系统    │
   行为埋点 ─────────────────────────────▶ │ L0~L5        │
                                          └──────┬───────┘
                                                 │ 画像摘要 + 偏好过滤 + 事件召回
                          ┌──────────────────────┼──────────────────────┐
                          ▼                      ▼                      ▼
                   ┌────────────┐         ┌────────────┐         ┌────────────┐
                   │ 穿搭 Agent │         │ 换装/发型  │         │  知识库    │
                   │            │         │  推荐      │         │  检索过滤  │
                   └────────────┘         └────────────┘         └────────────┘
                          │                      │
                          └──── 采纳/拒绝反馈 ───┴──▶ 回写 L2 / L3
```

| 模块 | 读取 | 写入 |
|------|------|------|
| 美学报告 | L0、L2（禁忌影响建议） | L1 全量、L3 报告版本 |
| 穿搭 Agent | L0/L1/L2 摘要、L3 召回、L4 上下文 | L2 候选偏好、L3 对话摘要、L4 上下文 |
| 换装模块 | L1（体型/季型用于素材推荐）、L2（禁忌过滤） | L3 试穿事件 |
| 发型模块 | L1（脸型/量感/直曲/发色） | L3 试戴事件 |
| 知识库检索 | L0/L1/L2 作为硬过滤条件 | — |
| 我的衣橱（V2） | L1/L2 用于衣橱适配分析 | L5 单品 |

---

## 5. 指标

### 5.1 用户系统
- 游客 → 注册转化率 > 25%
- **华为账号授权登录占比 > 60%**（首发平台；一键登录 V1 不做，故不考核其占比）
- 登录成功率 > 99%，注销请求处理时效 100% 达标
- 人脸授权通过率 > 60%
- **配额对账差异 = 0**（每日校验余额与流水一致性）
- **额度耗尽提示中出现价格字样的次数 = 0**（`FR-BILL-07` 的红线，发版前全文案扫描）

### 5.2 记忆系统
| 指标 | 目标 | 意义 |
|------|------|------|
| 画像完备率（L1 关键 8 项填充率） | > 70% | 个性化能力的地基 |
| 人均记忆条数（L2） | > 8 条 | 衡量学习深度 |
| 记忆确认率（pending → active） | > 50% | 隐式推断的准确性 |
| 记忆修正率 | < 20% | 过高说明诊断或推断不准 |
| 「我的记忆」页访问率 | > 15% | 透明度是否被感知 |
| 关闭个性化推荐比例 | < 5% | 信任度反向指标 |
| 有画像 vs 无画像用户的建议采纳率差值 | > 15pp | **验证记忆系统的实际价值** |
| 重复询问率（Agent 询问已知信息的比例） | < 3% | 记忆注入是否生效 |

---

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

### 6.1 已确认

| 原待确认项 | 结论 | 依据 |
|-----------|------|------|
| 华为账号登录接入方式 | 客户端改为**鸿蒙原生 ArkTS**，直接使用 **Account Kit**（`@kit.AccountKit`），不再涉及跨端框架兼容性问题。主登录取 UnionID/OpenID | `TD-01`、`TD-15` |
| 用户主标识 | 内部主键用自有 `user_id`（雪花 ID），UnionID 存独立映射表。**不用手机号或 UnionID 做主键**，否则将来接入其他登录方式很难改 | 架构 §6.2 |
| 向量库选型 | **PostgreSQL + pgvector**，不引入专用向量库。规模在十万级向量，且我们的检索是「强过滤 + 弱语义」，硬过滤与向量召回可在同一条 SQL 完成 | `TD-08` |
| 记忆数据保留时长 | 对话原文 90 天；L3/L4 摘要 180 天；报告与画像随账号存续；注销后 7 日内彻底删除 | `CR-03`、合规方案 §4.3 |
| 多形象档案 | V1 **仅预留 `pf_profile.profile_id`** 并创建默认档案，不做 UI | `FR-ACC-12` |
| 端侧记忆缓存加密 | V1 **端侧不缓存记忆明文**。记忆快照在服务端组装与缓存（Redis），端侧只持有展示所需的片段。这样既避免端侧加密方案的复杂度，也减少泄露面 | 架构 §10 |
| 记忆快照的性能方案 | 服务端 `pf_memory_snapshot` 表 + Redis 缓存，按 `content_hash` 变更才重建；记忆写入时按 `user_id` 主动失效 | 架构 §8.4 |

| **V1 是否收费** | **完全不收费**（`TD-28`）。无会员、无点数购买、无 IAP。用配额硬限制控成本，额度用尽只有「等恢复」与「做任务换额度」两条路径，文案不出现价格字样 | `TD-28`、`FR-BILL-07` |
| **登录方式** | V1 用「华为账号授权登录 + 手机号验证码」双通道；**一键登录降级为 P1 推至 V2**（需企业资质，属体验优化非能力缺口） | `TD-29`、`FR-ACC-13` |
| **余额字段位置** | 余额存 `bl_wallet`，**不在 `id_user` 冗余** `points_balance`；以 `bl_ledger` 流水为真相 | 架构 §6.2 |
| **配额账本与点数账本的关系** | **同一张表**。V1 用 `system_grant`/`consume`/`refund` 三种 `tx_type`，V2 增加 `purchase`/`gift`，V2 上支付**无需数据迁移** | 架构 §6.2、§7.4 |

### 6.2 仍待业务输入

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

唯一保留的开放项属于 V2 范畴，且需 V1 数据支撑：

- [ ] 隐式记忆推断的阈值与确认时机 A/B 方案 —— V2 功能（`FR-MEM-08`），需 V1 行为数据支撑
- [ ] V2 定价与点数消耗比 —— 依赖 V1 的真实成本与频次数据，并需按 IAP 抽成后的到账口径计算（`T-P6-16`）

### 6.3 本轮补充的关键约束

| 约束 | 说明 | 依据 |
|------|------|------|
| 一键登录有资质门槛 | 华为账号一键登录（获取绑定手机号）**仅支持企业开发者**、仅面向中国大陆用户，需申请 `quickLoginMobilePhone` scope，且服务端必须部署在中国大陆。**已据此降级为 P1 推至 V2**（`TD-29`） | `TD-15` |
| **证书指纹配置** | AGC 需配置 SHA256 证书指纹，**调试证书与发布证书是两套**，指纹添加后最迟 25 小时生效（改 `versionCode` 可加速）。⚠️ 漏配的表现是**调试包登录正常、发布包登录失败**，很容易在临上线时才暴露。必须写入发布手册 | `TD-15` |
| ~~虚拟商品必须走 IAP~~ | **V1 不适用**（不接支付）。V2 起：会员、点数、全面报告均属虚拟商品，鸿蒙上必须接入 IAP Kit 并签署联运协议；Payment Kit 明确不支持虚拟商品；服务端必须做收据二次校验，`purchase_token` 唯一约束防重复发货 | `TD-16`、`FR-BILL-09` |
| 配额消耗采用预扣三段式 | `reserve`（冻结）→ `commit`（确认）/ `refund`（退还）。长耗时任务可能失败，直接扣会产生「扣了次数没结果」的客诉 —— **V1 无客服退款兜底，只能靠机制保证**。所有变更写流水，余额可由流水重算对账 | `FR-BILL-05`、架构 §7.4 |
| 游客合并策略 | 合并操作幂等；多设备场景以先登录设备为准并给用户明确提示 | `FR-ACC-03` |
| **备案编号需在设置页公示** | 「设置 → 关于」固定展示模型名称与备案编号，入口硬编码不可隐藏，且展示内容须与 LLM 网关实际路由同源 | `CR-08`、合规方案 §2.2.4 |

---

**文档版本**：v1.3
**创建日期**：2026-08-11
**更新日期**：2026-08-14
**作者**：产品团队
**状态**：待评审
**变更说明**：
- v1.3（2026-08-14）：§2.2 / §3.9 表名与架构 §6.2、实际代码对齐。原 `user` / `user_consent` / `memory_audit` 以及把手机号、华为账号画在主表上，是概念模型残留；现改为 `id_user` / `id_user_identity` / `id_consent` / `pf_memory_event`，并写明性别生日归画像、会员归 V2 `bl_membership`
- v1.2 rev.2（2026-08-13）：文档一致性评审修订
  - **§3.8 的记忆注入分项预算被采纳为全局唯一事实源**。评审发现架构 §7.2 与本节存在两套口径（会话 400 vs 800、合计 3700 vs 1400），**错在架构表** —— 本节的 800 是「最近 6 轮原文 + 更早轮次滚动摘要」，架构表只算了滚动摘要、漏掉近轮原文。故以本节分项为准，架构侧总输入合计由 3700 修正为 **4200**；`FR-MEM-04` 的「≤ 500」为误写，已改为 ≤ 1400（V1 实际 ≤ 1200，L3 为 V2 能力）
  - **§2.4.1 配额数值改为引用产品方案 §3.2**，不再复述。同时**游客额度已补入产品方案 §3.2 的配额表**（此前只写在本文 §2.1 的叙述里，导致 `FR-ACC-02` 的验收标准无法判定），并明确它是**设备维度的终身额度而非每日额度**
  - **§3.3 / §3.5 的记忆枚举与置信度初值被采纳为唯一事实源**：架构原写的 `status`=archived/rejected、`source`=explicit/implicit/report/behavior 无法承载衰减与冲突消解语义（`decayed` 可恢复、`overridden` 不可恢复必须区分），已按本文修订；显式陈述置信度以本文的 **0.90** 为准（架构原写 0.95）
  - `id_consent` 的同意类型补入 **`personalization`（个性化推荐）** —— 本文 §3.10 要求记忆写入建立在该项授权之上，而架构枚举里原先没有这一项，属**有合规后果**的遗漏
- v1.2（2026-08-13）：业务决策收口，§6 已无 V1 遗留待确认项
  - **§2.4 重构为「V1 只有配额，没有付费」**（`TD-28`）：拆为「§2.4.1 V1 配额表（唯一生效）」与「§2.4.2 V2 权益规划（仅架构预留）」。给出 V1 配额与任务奖励额度的具体数值，以及三条纪律（服务端硬限制、文案不出现价格字样、禁止静默扣减）。说明配额账本与点数账本共用同一张表，V2 上支付免数据迁移
  - **§2.1 登录方式调整**（`TD-29`）：一键登录由 P0 降为 **P1 并推至 V2**（需企业资质，属体验优化非能力缺口）；V1 用「华为账号授权登录 + 手机号验证码」双通道。强调证书指纹双套配置漏配时"调试包正常、发布包失败"的表现
  - **§2.2 移除主表 `points_balance` 字段**：余额统一存 `bl_wallet`，避免两处数据不一致；`member_level`/`member_expire_at` 保留为预留字段。`birthday` 用途收窄，五行推算已取消（`TD-31`）
  - **§2.5 强化计量要求**：说明 V1 不收费反而让计量更重要 —— `ob_ai_call` 与 `bl_ledger` 是 V2 定价的唯一数据来源，不允许"先上线后补埋点"
  - §2.3 用户中心新增「我的额度」与「关于（备案编号公示）」，移除五行模块开关
  - §5.1 新增两项红线指标：配额对账差异 = 0、额度提示中价格字样出现次数 = 0
- v1.1（2026-08-13）：§6 待确认事项收口，7 项确认、3 项转入业务输入；补充一键登录的企业开发者资质门槛与 scope 申请要求、证书指纹双套配置、虚拟商品强制 IAP 与抽成影响、点数预扣三段式；明确向量库为 pgvector、端侧不缓存记忆明文
- v1.0（2026-08-11）：初始版本

**关联文档**：
- [文档索引](./README.md)
- [需求规格说明](./需求规格说明.md)（本文需求对应 `FR-ACC-*`、`FR-MEM-*`、`FR-BILL-*`）
- [美搭 · 智能穿搭美学助手 产品方案](./鸿蒙美搭-智能穿搭美学助手-产品方案.md)
- [技术架构文档](./技术架构文档.md)（数据模型见 §6.2，记忆读写见 §8.4，配额与支付链路见 §7.4）
- [技术选型与调研报告](./技术选型与调研报告.md)
- [合规与安全方案](./合规与安全方案.md)
- [美学报告需求文档](./美学报告-需求文档.md)
- [穿搭 Agent 需求文档](./穿搭Agent-需求文档.md)
- [美学知识库建设方案](./美学知识库-建设方案.md)