xsl/meida
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
0075c130bd00e8b3364c47d656d970ad7f1379f3
meida/docs/用户系统与记忆系统-需求文档.md
T
xslandCursor 2934954eb2 按交叉评审对齐文档与代码口径，并挡住 reference 下的密钥文件 
表名、配额种子和字段名以产品方案与架构为准；文档仓库补 .gitignore，避免 git add -A 把 API Key 推进远端。

Co-authored-by: Cursor <cursoragent@cursor.com>
2026-08-14 11:28:35 +08:00

35 KiB
Raw Blame History

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

本文档为「美搭」App 的用户体系与个性化记忆体系需求文档，与 产品方案、美学报告需求文档、穿搭 Agent 需求文档、美学知识库建设方案 配套使用。

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

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

3.3 记忆项数据结构

{
  "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 存储与技术形态

选型结论见《技术选型与调研报告》TD-02/TD-08；表结构见《技术架构文档》§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）：初始版本

关联文档：

Reference in New Issue View Git Blame Copy Permalink