baoyu-wechat-summary 群友画像系统（Profiles）完整指南：文件格式、更新规则与回溯流程-平芜编程栈

AI 技能
AI 插件

【免费下载链接】baoyu-skills

项目地址：https://gitcode.com/gh_mirrors/ba/baoyu-skills

微信群的精华简报若要“越写越懂这群人”，靠的正是 per-user 画像（Profiles）体系。本文基于 baoyu-skills 仓库中 baoyu-wechat-summary 技能的画像参考文档 references/profiles.md，完整拆解画像文件的结构规范、frontmatter 字段语义、normal/roast 双版本隔离机制、摘要落盘后的更新流程（Step 8.5）、回溯画像流程（Step 9）以及贯穿始终的隐私护栏。读完你既能直接按规范手工维护一套画像目录，也能理解该技能在生成每期“群聊精华”时如何利用历史画像实现跨期连续性（例如“蛙总今天罕见地没提空头”这类对比表达）的底层原理。

一、画像系统要解决什么问题

微信群聊摘要有天然的碎片化问题：每期简报都从零开始，读者很难感知某位群友的长期特征、惯用话术与反复出现的“名场面”。画像系统的核心目标，就是把跨多天的观察沉淀下来，让每期新摘要中的“群友画像”小节能够体现连续性——比如蛙总今天罕见地没提空头——而不是每期都从头刻画一个人。

为此，每个群的摘要目录旁边会并排维护两个画像目录：

profiles/—— 从普通版摘要中沉淀的观察；
profiles-roast/—— 从**毒舌版（roast）**摘要中沉淀的观察。

这两个目录被严格隔离：普通版生成只读取profiles/，毒舌版生成只读取profiles-roast/。这样做的目的是防止毒舌版的花式吐槽污染正经摘要的客观记录，反之亦然——普通版的克制观察也不会稀释毒舌版的锐度。

在该技能的整体工作流（SKILL.md）中，画像文件在三个环节被加载或更新：

Step 3.7：加载活跃用户的画像作为背景上下文；
Step 8.5：摘要文件落盘后更新画像；
Step 9：用户主动触发“回溯画像 / 初始化画像 / backfill profiles”时的批量回填。

二、画像文件格式规范

2.1 路径与命名

每个群一个画像目录，文件按群分组存放：

普通版：wechat/{group_id}-{group_name}/profiles/{wxid}-{nickname}.md
毒舌版：wechat/{group_id}-{group_name}/profiles-roast/{wxid}-{nickname}.md

其中{group_id}-{group_name}是群的目录名（例如12345678901@chatroom-相亲相爱一家人，完整目录结构见 SKILL.md 的 Storage layout 小节）。

命名上有两个关键设计：

wxid前缀是稳定标识符：这是索引键，一切查找都以{wxid}-*.md前缀匹配进行，绝不依赖昵称。
-{nickname}后缀仅为人工浏览便利：昵称变了，就重命名文件（{wxid}-{old_nickname}.md→{wxid}-{new_nickname}.md），wxid前缀保持不变。

2.2 文件名净化规则

无论群名、昵称还是文件名，只要进入文件系统路径，都必须做净化：

将/、\、:、*、?、"、<、>、|、NUL 及控制字符全部替换为_；
去除末尾的点和空白；
文件名总长度上限 200 字符（有些罕见昵称可以非常长）。

注意净化只针对上述字符，不剥离 emoji 和中文——因此onlytiancai-胡浩🐸.md这样的文件名是合法且被鼓励的（参见 SKILL.md 中的存储布局示例）。

2.3 YAML frontmatter 字段详解

每个画像文件顶部都有一份 YAML frontmatter，承载结构化元数据：

--- name: "<current display name>" wxid: "<wxid>" group_nicknames: ["<历史群昵称 1>", "<历史群昵称 2>"] aliases: ["<群友给的称呼 1>", "<群友给的称呼 2>"] tags: ["<标签 1>", "<标签 2>"] first_seen: "YYYY-MM-DD" last_seen: "YYYY-MM-DD" total_messages: N digest_appearances: N avg_messages_per_digest: N.N ---

各字段语义与写入规则：

字段	含义与规则
`name`	最近的显示名，取自消息的`from_nickname`（本人即`self_wxid`时取`self_display`）。
`wxid`	稳定标识符，一旦写入永不改变。
`group_nicknames`	只追加的历史群昵称列表。当`name`发生变化时，把旧的`name`压入这里。去重、保持时间顺序（旧→新）。不包含当前`name`。
`aliases`	其他群成员对该用户的称呼（如`蛙总`、`老王`、`X 哥`）。在本批观察到时去重追加。不包含当前`name`，也不与`group_nicknames`重复——后者记录的是用户自己用过的昵称，前者是群友如何称呼他。
`tags`	自由标签，独立于正文的“角色标签 / 人设标签”小节。用于承载不属于角色/人设框架的横向属性（地区、职业、社群、长期兴趣等）。观察到稳定模式时可追加或精炼，无上限。
`first_seen`/`last_seen`	首次/最近一次出现在摘要中的日期，格式`YYYY-MM-DD`。
`total_messages`	该画像被更新以来累计的消息数。
`digest_appearances`	该用户达到“3 条以上消息”门槛的摘要文件数量。
`avg_messages_per_digest`	`total_messages / digest_appearances`，保留一位小数。

向后兼容规则：早期版本的技能曾用aliases承载现在group_nicknames的职责。读取一个缺少group_nicknames或tags的旧画像时，把缺失字段当作[]处理，并在下一次写入时补上。但不要自动迁移非空的旧版aliases值——Agent 无法可靠地区分“历史显示名”和“群友给的昵称”，硬迁移会把两类数据混在一起。正确做法是保持aliases原值不动，由用户在有需要时手动把历史显示名挪进group_nicknames。

2.4 正文自由格式 —— 普通版（normal）

正文是小节标题独占一行、顺序固定的纯文本结构（不使用 Markdown 标题语法）：

角色标签 • {4-6 短语标签} 关注领域 • {领域 1} • {领域 2} 发言风格 {1-3 句描述，可以多段} 互动模式 • {与某某的互动模式} • {另一种互动模式} 经典金句 • [YYYY-MM-DD] 「{直接引用}」 • [YYYY-MM-DD] 「{直接引用}」 标志性事件 • [YYYY-MM-DD] {事件描述} • [YYYY-MM-DD] {事件描述}

要点：

角色标签为 4–6 个短语标签，是一行式的人物速写；
经典金句必须带日期且逐字引用，是后续“callback 金句”的素材库；
标志性事件每条带日期与事件描述。

2.5 正文自由格式 —— 毒舌版（roast）

毒舌版采用同样的纯文本小节标题风格，但小节完全不同：

人设标签 • {4-6 放大版标签} 核心槽点 • {可吐槽点 1} • {可吐槽点 2} 毒舌语录库 • [YYYY-MM-DD] 「{该用户说过的话} — {简短毒舌点评}」 • [YYYY-MM-DD] 「{...}」 经典翻车现场 • [YYYY-MM-DD] {翻车描述 + 引用 / 证据} • [YYYY-MM-DD] {...}

这里的毒舌语录库与普通版的经典金句互为镜像，但每条都附带一句毒舌点评；经典翻车现场则记录那些“在群里翻车”的公开名场面（带引用或证据）。

三、更新规则：哪些可改写，哪些只能追加

画像更新的总原则是：只追加的小节永远不能丢失历史，可合并的小节可以随认知加深而重写。具体按版本分列如下。

3.1 普通版各小节更新模式

小节	更新模式	备注
角色标签	Merge（合并）	上限 4–6 个。可以用更有代表性的标签替换较弱的标签。始终保留“被最稳定支持”的标签。
关注领域	Merge 去重	增加新领域；按语义去重而非按字符串精确匹配。
发言风格	Refine（精炼）	只有出现明显的新模式时才更新；避免每期都改写。
互动模式	Merge（合并）	新增模式；可用更细节的内容精炼既有条目。
经典金句	Append-only（只追加）	永不删除，无上限。每条必须带日期、逐字引用。
标志性事件	Append-only（只追加）	永不删除，无上限。每条带日期。

3.2 毒舌版各小节更新模式

小节	更新模式	备注
人设标签	Merge（合并）	上限 4–6 个；随模式重复出现可不断锐化。
核心槽点	Append-only（只追加）	永不删除；反复出现的槽点在此累积。
毒舌语录库	Append-only（只追加）	永不删除，无上限。每条带日期，且同时包含原话与毒舌点评。
经典翻车现场	Append-only（只追加）	永不删除，无上限。每条带日期。

3.3 每次更新时 frontmatter 的处理

无论哪一版，每次更新画像都必须同步处理 frontmatter：

昵称变更：如果当前显示名与记录的name不同——
- 将旧的name压入group_nicknames（若尚未存在；去重且保持时间顺序）；
- 将name更新为当前显示名；
- 把文件从{wxid}-{old_nickname}.md重命名为{wxid}-{new_nickname}.md。
扫描群友称呼：在本批消息中扫描其他成员称呼该用户的方式（区别于其当前name），去重追加进aliases。判定信号包括：
- @mention解析到该wxid；
- 直接称呼该用户且名称与name不同的问候（如蛙总你怎么看、老王说得对）；
- 摘要正文中引用该用户时用了非当前name的名称。
- 仅在归属明确时添加，不确定的匹配一律跳过。
tags 更新：如果本批暴露了不属于角色/人设框架的稳定横向属性（地区、职业、社群、长期兴趣等），追加或精炼tags。tags独立于正文的标签小节，不要镜像。
数值更新：last_seen更新为当前摘要的结束日期；total_messages累加本批该用户的消息数；digest_appearances加 1；重新计算avg_messages_per_digest。

四、Step 8.5：摘要落盘后的画像更新流程

这一步在摘要文件写完之后执行，遍历本批消息数 ≥ 3 条的每一位用户，共 6 个步骤：

查找画像：扫描profiles/（毒舌版为profiles-roast/），按文件名{wxid}-前缀匹配。找到则打开；找不到则按 frontmatter 模板新建文件：group_nicknames = []、aliases = []、tags = []、first_seen = last_seen = 当前摘要结束日期、total_messages = 本批数量、digest_appearances = 1，然后按 §2.3 用本批观察补充初始的 aliases/tags。
为新用户解析 wxid：新用户出现时，wxid已可直接从 wx-cli 消息数据中取得。若只能拿到昵称，则运行wx contacts --query "{nickname}" --json解析；命中多个匹配时，优先选择当前在群内的那个（必要时用wx members <group>交叉验证）。
更新 frontmatter：按 §2.3 规则执行。
更新正文小节：
- 可合并小节（普通版：角色标签、关注领域、发言风格、互动模式；毒舌版：人设标签）：读取既有内容，把本批新观察整合进去后重写该小节；
- 只追加小节（普通版：经典金句、标志性事件；毒舌版：毒舌语录库、经典翻车现场、核心槽点）：追加新条目，每条带日期、逐字引用。绝不编辑或删除既有条目。
写回文件：覆盖写入。
来源隔离：普通版运行只写profiles/，毒舌版运行只写profiles-roast/。即使两个版本在同一次技能调用中生成，也必须跑两遍独立的更新流程，互不交叉。

需要说明的是：该技能没有内置脚本目录（依赖外部 wx-cli 二进制提供数据），画像的读写完全由 Agent 按上述流程在文件系统上完成。这与技能文档中 Completion checklist 相互印证——该清单要求每期运行结束前逐项确认profiles/{wxid}-*.md（include_normal时）与profiles-roast/{wxid}-*.md（include_roast时）已为每个 3 条以上消息的用户更新，画像更新是“摘要落盘后最容易漏掉、但绝不能漏”的一环。

五、Step 9：回溯画像（Backfill）流程

当用户说出回溯画像、初始化画像、backfill profiles等触发词时，技能执行回填流程：直接基于已写好的历史摘要文件批量构建初始画像，而无需重新从 wx-cli 拉取消息。完整流程共 8 步：

列出输入：列出wechat/{group_id}-{group_name}/顶层（不含profiles/、profiles-roast/内部）所有*.md摘要文件；按文件名后缀分区：*-roast.md归入毒舌通道，其余归入普通通道。可选地先读history-digests.jsonl快速获取日期、消息数等元数据，避免逐个打开文件。
决定是否回填毒舌版：仅当存在至少一个*-roast.md文件时才运行毒舌通道。
分批处理：每批 10–15 个摘要文件（一次全读会撑爆上下文）。对每批：
- 读取摘要；
- 对在排行榜或“群友画像”小节中出现的用户，累积：每期消息数（来自统计块）、角色标签与观察（来自群友画像小节）、金句（来自正文中的「」引用）、带日期的事件（来自正文分类中提到的具体事件）；
- 通过wx contacts --query "{nickname}" --json为累积到的用户解析 wxid（未缓存时），并在回填余下流程中缓存 wxid↔昵称映射。
门槛：只为在语料中出现于 3 个及以上摘要的用户生成画像文件；低于此门槛者跳过（大概率是一次性访客）。
写画像文件：普通通道写入profiles/{wxid}-{nickname}.md，毒舌通道写入profiles-roast/{wxid}-{nickname}.md。用最近的昵称作为文件名后缀，把更早的显示名压入group_nicknames。经典金句、标志性事件、毒舌语录库、经典翻车现场按日期时间顺序排序。回填时只追加小节不设上限——让历史尽量完整地流进来。
计算 frontmatter：
- first_seen= 用户出现的最早摘要日期；
- last_seen= 用户出现的最近摘要日期；
- total_messages= 各期数量之和；
- digest_appearances= 用户跨过 3 条消息门槛的摘要数；
- group_nicknames= 尽力而为。若同一wxid在历史摘要中出现在多个不同显示名之下（例如排行榜行X — N 条中 X 变化），按时间顺序填入较早的显示名（最新的留在name）；时间顺序不明时去重，留给后续运行修正；
- aliases= 尽力而为。扫描历史摘要正文中其他成员用非当前name称呼该用户的形式（@提及、直接问候）；不确定的匹配跳过，无可靠结果则留[]；
- tags=[]。回填不播种 tags，交给后续正常运行的观察累积。
报告：两个通道都完成后，打印简短汇总：
- Backfilled {N} normal profiles from {M} digests.
- Backfilled {K} roast profiles from {L} roast digests.（仅当毒舌通道运行时）
- 列出因 wxid 解析失败而跳过的用户，便于用户手动修复。
重复运行安全：如果用户跑两次回填，把既有画像文件视为先前状态并按 Step 8.5 的规则合并——不要清空既有只追加条目。

值得注意的是，回填与增量更新共享同一套“只追加不删除”的语义，这保证了无论历史多长、无论重跑几次，金句与事件这类高价值内容都不会丢失。

六、隐私护栏（Privacy Guardrails）

画像是一种持久化记忆，因此隐私约束比单期摘要更严格。规则适用于普通版与毒舌版，毒舌版另有额外一层红线。

6.1 禁止写入（两版皆禁）

真实姓名：群里只用昵称时，不得写入真实全名。若本人自我介绍说“我叫王二”，王二可以记；从其他渠道推断出的王晓明不可以。
联系方式与身份信息：电话号码、邮箱、身份证号、家庭住址、雇主地址、精确出生日期——即使在群里提过，也不得搬进画像文件。
健康与心理信息：即使本人自述（如“我最近有点抑郁”），也不得固化进长期画像。
私人感情/家庭细节：除非本人公开在群里讨论；其他成员顺带一提不算。
尴尬的私人失败：公开翻车（在群里当众被打脸的观点）可以记；私人失败（顺带一提的求职被拒）不可以。
从时间戳推断作息/时区：服务器时间 ≠ 接收者本地时间，且这本质上是一种监视行为。

6.2 允许写入

公开群行为——说了什么、怎么争论、分享了什么；
群里说过的直接引语（对群成员而言已属公开信息）；
群讨论中表达的兴趣、爱好、工具偏好；
与其他群成员的互动模式；
本人公开提过的消费（如“蛙总今天又分享了买了什么书”）——前提是本人自己提过；
本人向群里公开分享的旅行/生活轶事。

6.3 毒舌版额外红线

在 §6.1 之上，毒舌画像不得包含：

任何关于外貌、体重、身材、长相的内容；
任何关于家庭成员的内容（孩子、父母、伴侣）——只针对本人；
心理健康猜测，即使是玩笑（如“这位需要看医生”、“典型 ADHD”）；
身份属性向的嘲讽——性取向、宗教、民族、国籍、性别。

毒舌可以嘲讽的是：

愚蠢的观点、自相矛盾、事实错误；
重复性行为（如“第 47 次预测见顶”）；
自我拆台时刻（“昨天说 X，今天说 not X”）；
没立住脚的表演式炫技。

一句话准则：嘲讽观点本身，不嘲讽人（roast the take, not the person）。这与 output-formats.md 中毒舌版的写作红线一脉相承——毒舌但不恶毒，调侃但不人身攻击，目标是让群友看了会笑而不是生气。

七、生成摘要时如何读取画像（Step 3.7）

画像既是写入的产物，也是生成的输入。在生成新一期摘要时，技能按如下方式加载画像：

遍历本批活跃用户（消息数 ≥ 3 条）；
普通通道：为每人读取profiles/{wxid}-*.md，缺失则跳过；
若本次同时生成毒舌版：在毒舌生成通道中另行读取profiles-roast/{wxid}-*.md；
将画像压缩成一个精简的工作记忆块，包含：
- 用户当前的name、group_nicknames和aliases（用于在旧显示名或群友昵称下仍能认出该用户）；
- tags（横向属性——地区、职业、社群——便于在“群友画像”中做点题）；
- 角色标签 / 人设标签（用于延续或对比）；
- 最近 3–5 条经典金句/毒舌语录（用于检测 callback 与重复）；
- 最近 3–5 条标志性事件/翻车现场（用于发现反复出现的主题）。
不要把整个画像倒进摘要——画像是“背景”，摘要属于“今天”。

关键的使用原则：

只加载本批活跃用户的画像，绝不预先加载所有人；
画像是背景而非模板，当期消息仍是主要素材；
用历史标签做连续性表达（“又双叒叕化身空中直播员”）或对比性表达（“一向省钱的 XX 今天居然……”）；
严格隔离：普通通道只读profiles/，毒舌通道只读profiles-roast/，绝不交叉加载。

一个值得注意的细节：如果画像与当期观察矛盾（比如画像写着“从不主动发起话题”，今天该用户却连开三个话题），技能要求在当天“群友画像”里明确点出这种反差——这正是让摘要变得有趣的内容来源。

八、与整体工作流的衔接

画像系统不是孤岛，它与其他持久化组件配合构成群聊记忆体系：

组件	职责	文件
`profiles/`与`profiles-roast/`	按人沉淀长期画像（本文主题）	`wechat/{group_id}-{group_name}/profiles/`
`memory.md`	群级事实记忆：被指正/确认的客观事实（事实只有一份，两版共用）	`{folder}/memory.md`
`history.json`	最近一期摘要指针，供增量模式定位起点	`{folder}/history.json`
`history-digests.jsonl`	只追加的摘要归档，供回填与历史查询	`{folder}/history-digests.jsonl`

从实现角度看，画像系统完全基于约定式文件格式运行，不依赖任何打包脚本；所有读写动作由 Agent 依据本文档的字段规则与更新模式执行。这也意味着：只要严格遵循“wxid 前缀索引、frontmatter 字段语义、只追加/可合并的更新模式、隐私护栏”这套约定，任何人或任何兼容工具都可以直接维护这套画像目录，并与 baoyu-wechat-summary 的每期摘要生成流程无缝衔接。