05-用户画像自动沉淀-从一句话到长期印象黒漂技术佬的 AI 伙伴AI-Partner源码拆解系列。前面讲了记忆表、记忆工具、检索排序、注入成本。本篇收个尾这些散落的记忆怎么聚合成一个用户画像让机器人从第一次见面的陌生人变成记得你爱喝绿茶的老朋友。一、画像不是另起炉灶是记忆的提炼物先纠正一个常见误会AI 伙伴AI-Partner没有一张专门的画像表。用户画像不是单独维护的结构化档案年龄、爱好、职业各填一格而是从t_memory的生效记忆里实时提炼出来的一段文字存在t_user表的personaSummary字段里。换句话说记忆是原材料画像摘要personaSummary是成品。先有记忆后有画像记忆变了画像跟着重算。这种单一数据源设计很聪明——不会出现记忆说 A、画像说 B的对不上。二、User 实体里和画像相关的字段画像宿主是t_user表实体User。字段不少但和画像直接相关的就几个我们分开看。基础身份字段人工/登录时填非记忆沉淀字段类型/约束说明是否进系统提示词id自增主键用户 ID记忆隔离键否仅作关联openIdlength64非空、唯一索引微信/支付宝/网页账号标识否platformlength16wechat/alipay/web否nicknamelength64昵称默认新朋友是phonelength20普通索引手机号是birthdayLocalDate生日用于生日提醒是rolelength16elder/child/adult家庭角色是画像沉淀字段由记忆自动生成字段类型/约束说明personaSummarylength2000画像摘要由MemoryService.refreshPersonaSummary写入deviceIdlength64绑定设备 ID非画像但属用户侧avatarUrllength512头像statusInteger默认 11 正常 / 0 禁用createdAt/updatedAt时间生命周期PersonaProvider拼系统提示词时从User取的就是nickname / role / phone / birthday / personaSummary这几项回顾前面几篇的源码。所以画像在工程上 基础身份字段静态 personaSummary动态记忆提炼。索引小知识t_user给openId建了唯一索引idx_user_openid保证一个第三方账号只对应一个用户给phone建了普通索引idx_user_phone方便按手机号查。记忆表t_memory则只给userId建了索引——两条表靠userId逻辑关联不建物理外键项目整体约定。三、画像摘要怎么拼取前 10 条用连起来核心逻辑在MemoryService.refreshPersonaSummary每次保存或删除记忆后都会触发// 项目源码沉淀用户画像摘要privatevoidrefreshPersonaSummary(LonguserId){userRepository.findById(userId).ifPresent(user-{ListMemoryItemtopmemoryRepository.findByUserIdAndActiveTrueOrderByImportanceDescCreatedAtDesc(userId);if(top.isEmpty()){return;// 没记忆就不写personaSummary 保持原样}Stringsummarytop.stream().limit(10)// 只取前 10 条.map(MemoryItem::getContent)// 只要正文.collect(Collectors.joining());// 用分号拼成一段user.setPersonaSummary(summary);userRepository.save(user);});}几个要点拆开讲复用重要度降序 时间降序那条查询。和第 03 篇的主查询是同一个方法所以画像摘要天然是最重要的 10 条记忆。只取content丢掉类型和重要度。画像是一段给人/模型读的印象文字不需要[偏好·重要度3]这种机器标注。用中文分号拼接。多条记忆连成一句形如“用户喜欢喝绿茶用户有一只叫团团的猫用户本周三要去医院复查”。读起来像真人旁白。最多 10 条不是 20 条。注意注入系统提示词的记忆是 20 条第 04 篇但沉淀进personaSummary的只有前 10 条。为什么少一半因为personaSummary还要和那 20 条记忆同时出现在系统提示词里回顾第 04 篇指出的重复注入若也取 20 条就严重冗余。10 条是一句话印象的体量20 条是可逐条引用的明细分工不同。触发时机也很关键save()成功后调一次新记忆进来了重算remove()软删后也调一次记忆没了画像要跟着瘦下来。记忆增删画像自更新——这保证了单一数据源不漂移。四、画像冷启动刚认识你时机器人是空白的任何画像系统都绕不开冷启动用户第一天来一条记忆都没有personaSummary是null这时候系统提示词长啥样看PersonaProvider当user.getPersonaSummary()为空时整段画像摘要行都不追加同时记忆段也因memories.isEmpty()不追加。于是新用户的系统提示词只剩【用户信息】 - 昵称新朋友 - 家庭角色- - 手机号- - 生日-也就是只有固定人设 当前时间 几乎空白的用户信息。机器人此时是个有礼貌但还不了解你的陌生人不会假装认识你也不会乱编你的喜好呼应人设里不可以编造用户未提供的信息。冷启动怎么破两条自然路径路径机制对话自然沉淀用户聊着聊着模型调saveMemory记几条画像慢慢长出内容注册时补全UserRequest带入nickname首次登录就有昵称后续可引导填生日/角色冷启动阶段体验偏通用这是合理的——宁可慢热也不要伪个性化一上来就瞎猜你爱喝什么。陪伴讲究的是真实积累不是开局假装熟。五、画像准确性风险模型会记错自动沉淀最迷人的地方也最危险画像完全由大模型在对话中自己判断写库没有人工逐条确认。这意味着它可能出错风险例子后果记错事实用户说我姐在杭州模型记成用户住在杭州画像把亲属位置误成本人位置记错类型我妈高血压被存成fact而非health健康类按类型召回失效过度推断用户随口说今天有点累模型存用户长期疲惫画像失真机器人总问你还累吗重要度虚高闲聊被打 5 分挤占真正重要记忆的位置源码只在工程层做了两道护栏normalizeType归一类型、importance夹 1-5语义正确性这道关是没守的。也就是说当前实现的画像“大概率对错了靠软删纠正”。这对陪伴闲聊够用但对健康/安全相关记忆就有隐患——记错了可能误导关怀再次提醒任何健康判断以专业意见为准。六、人工纠偏入口得给用户改你印象的按钮既然模型可能记错产品上必须留人工纠偏的口子。当前工程里纠偏能力是半成品删除纠偏MemoryTool.removeMemory以及背后的MemoryService.remove已经能软删某条记忆删完会触发refreshPersonaSummary重算画像。这是最基础的纠偏。检索查看searchMemory能列出相关记忆用户/家属可先看看它记了啥。但现状是这些能力藏在 Agent 工具里主要服务于模型自己调并没有一个面向用户的我的画像/我的记忆管理页把记忆列表展示出来、允许手动编辑content或type、或一键纠正。调研报告也确认项目目前没有独立的人工补录/修正入口source实际只写入agent。一个可落地的纠偏入口设计示意非现有代码模块作用记忆列表页调searchMemory展示机器人记得你的事逐条可看单条编辑允许改content/type/importance保存后重算画像单条删除复用removeMemory软删画像预览展示personaSummary当前值让用户直观看到机器人眼里的我敏感标记健康/家庭类记忆打标纠偏时需二次确认设计原则纠偏要低成本、可撤销、留痕。改完一条记忆后台自动refreshPersonaSummary下次对话画像就更新——这正是现有save/remove已经具备的联动机制只差一个前端把它暴露给用户。合规提醒收尾尤其重要用户画像是高度个人化的敏感聚合可能含健康史、家庭关系、生活习惯。请务必做到——①数据最小化只沉淀陪伴必需的记忆别把画像当全量档案②授权与告知首次使用明确告知对话可能生成长期记忆与画像并取得用户同意③未成年人保护涉及儿童rolechild时记录与展示须取得监护人同意且默认更保守④纠偏权用户应能查看、更正、删除自己的记忆与画像这是基本的数据权利⑤医疗边界画像中的健康信息仅作陪伴提醒之用任何健康/用药判断以专业医疗意见为准机器人不得据此给出诊断。老人陪护场景更需家属协同授权避免机器人比子女更了解老人带来的隐私与责任错配。从一条记忆到十句摘要再到每次对话里那个懂你的语气——用户画像自动沉淀把陪伴从功能变成了关系。这套机制现在能跑通基本闭环而记得更准、纠得更易就是它下一步值得打磨的方向。