nezumi/astrbot_plugin_qq_group_daily_analysis
1
0
Fork 0
mirror of https://github.com/Nezumi-2711/astrbot_plugin_qq_group_daily_analysis.git synced 2026-09-22 13:38:43 +00:00
Code Issues Packages Projects Releases Wiki Activity

docs(MBTI): 为多样化 MBTI 增加开发说明文档 (#167)

Browse Source
This commit is contained in:
SXP-Simon
2026-04-13 16:51:34 +08:00
parent d47a9411b2
commit 06ea0e7812
2 changed files with 1351 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/mbti_variant_integration_proposal.md
+916
View File
@@ -0,0 +1,916 @@
# 趣味人格标签体系接入与扩展方案
## 背景
Issue #167 提出的核心诉求不是“把 MBTI 算得更准”，而是让群日常分析里的“用户称号”部分更有趣、更可玩。
结合参考项目来看，这类能力更适合做成一个“可切换的人格标签体系”，而不是继续把输出能力绑定死在 `MBTI` 上。
这份文档基于以下内容整理：
- 当前插件实现
- [nexu-io/sbti-skill](https://github.com/nexu-io/sbti-skill)
- [tianxingleo/ACGTI](https://github.com/tianxingleo/ACGTI)
## 结论先行
推荐分三步推进：
1. 第一阶段只做“语义扩展，不改链路”
先保留当前 `mbti` 字段和现有 JSON schema，不动渲染和数据模型，只把它解释为“人格标签结果位”。
2. 第二阶段做“配置化标签体系”
增加 `label_system` 配置和对应的标签库/提示词片段，让 MBTI、SBTI、ACGTI 原型可以切换。
3. 第三阶段做“可扩展人格玩法”
将标签体系抽象成数据驱动注册表，支持更多二创体系、群体画像、相性和彩蛋玩法。
如果只想低成本满足需求，第一阶段其实就够了，而且风险最低。
## 当前插件的切入点
当前插件已经天然具备接入基础，不需要重做分析主流程。
### 已有基础
- [`_conf_schema.json`](C:/Helianthus/SXP-Simon/astr/official/AstrBot/data/plugins/astrbot_plugin_qq_group_daily_analysis/_conf_schema.json) 默认的 `user_title_prompt` 已要求模型返回 `title + mbti + reason`
- [`src/infrastructure/analysis/analyzers/user_title_analyzer.py`](C:/Helianthus/SXP-Simon/astr/official/AstrBot/data/plugins/astrbot_plugin_qq_group_daily_analysis/src/infrastructure/analysis/analyzers/user_title_analyzer.py) 会把活跃用户统计整理成 prompt 输入
- [`src/domain/models/data_models.py`](C:/Helianthus/SXP-Simon/astr/official/AstrBot/data/plugins/astrbot_plugin_qq_group_daily_analysis/src/domain/models/data_models.py) 的 `UserTitle` 数据结构已经有 `mbti` 字段
- [`src/infrastructure/analysis/utils/structured_output_schema.py`](C:/Helianthus/SXP-Simon/astr/official/AstrBot/data/plugins/astrbot_plugin_qq_group_daily_analysis/src/infrastructure/analysis/utils/structured_output_schema.py) 和 [`src/infrastructure/analysis/utils/response_validation.py`](C:/Helianthus/SXP-Simon/astr/official/AstrBot/data/plugins/astrbot_plugin_qq_group_daily_analysis/src/infrastructure/analysis/utils/response_validation.py) 已经把 `mbti` 当成结构化输出字段进行校验
### 当前约束
现在的字段名、schema、校验器、渲染层大概率都默认这个字段叫 `mbti`。
因此如果直接把字段重命名为 `persona_label` 或 `label`，会产生一串兼容性修改。
所以最稳的策略是：
- 第一阶段继续保留 JSON 字段名 `mbti`
- 但在产品语义上把它解释成“人格标签”
- UI 文案和提示词里可以写“MBTI / SBTI / ACGTI 等趣味标签”
也就是说，先“改语义”，后“改字段”。
## 参考仓库分析
## 1. `sbti-skill` 的启发
`sbti-skill` 的强项不在算法复杂度，而在“人格库和文案库外置”。
它的关键特点：
- 用 `SKILL.md` 驱动完整交互流程
- 用 `references/personalities.md` 存人格定义、文案、稀有度
- 用 `references/questions.md` 存题库和计分规则
- 输出非常强调“人格代码、人格文案、展示仪式感”
对本插件最有价值的不是“30 道题测试”，而是这三个思想：
- 人格体系本身可以作为独立内容资产维护
- 提示词只要引用“标签库 + 风格说明”，就能产出有趣结果
- 彩蛋、稀有度、专属开场白都很适合做二次创作增强项
对群日常分析来说，可以直接借鉴为：
- 做一个 `labels/sbti.*` 的标签库文件
- 给每个标签补一句“群友画像文案”
- 允许模型只基于聊天统计做“轻量命中”，不追求测试式精确
这和 Issue 里“没必要太精确，省点 token”的方向完全一致。
## 2. `ACGTI` 的启发
`ACGTI` 的强项是“分层抽象稳定，上层内容可扩”。
它把能力拆成了几层：
- 底层维度：MBTI 四维
- 中层原型：8 个 archetype
- 上层角色：24 个具体角色
- 展示层：visual、tag、note、海报
对本插件最值得借鉴的是这种结构化分层：
- 不一定直接输出最细的标签
- 可以先输出“趣味原型”，再映射到更具体的标签
- 标签库、原型库、文案库都可以数据驱动扩展
对于群日常分析，适合转化成：
- 底层仍使用现有群聊统计特征
- 中层引入“群聊人格原型”
- 顶层再映射到 SBTI、ACGTI 风格标签或自定义称号
这样后面想继续加：
- 二次元原型
- 职场梗原型
- 互联网抽象人格
- 某个群专属黑话人格
都会更自然。
## 前端展示层思考
上一版方案更多集中在后端链路和数据结构，但这类玩法真正让用户感知到差异的地方，其实是展示页。
当前插件本身已经有比较成熟的 HTML 报告模板体系，不是从零开始：
- [`src/infrastructure/reporting/generators.py`](C:/Helianthus/SXP-Simon/astr/official/AstrBot/data/plugins/astrbot_plugin_qq_group_daily_analysis/src/infrastructure/reporting/generators.py) 会在 `_prepare_render_data` 里生成 `titles_html`
- [`src/infrastructure/reporting/templates.py`](C:/Helianthus/SXP-Simon/astr/official/AstrBot/data/plugins/astrbot_plugin_qq_group_daily_analysis/src/infrastructure/reporting/templates.py) 会按当前模板目录加载 Jinja2 模板
- 各模板目录下已经有独立的 `user_title_item.html` 片段，适合承载人格卡片
这意味着“人格标签结果”完全可以升级成“人格视觉卡片”，而不是停留在一行文字。
## 为什么前端展示很重要
`SBTI` 和 `ACGTI` 之所以传播强，不只是因为标签本身有趣，还因为它们普遍具备：
- 强主题色
- 明显的角色或原型形象
- 适合截图传播的结果页
- 清晰的层级结构：代码、人格名、短句、说明、扩展标签
如果本插件只输出：
- 称号
- 一个标签
- 一段理由
那可玩性会明显弱于参考项目。
所以建议把“趣味人格标签”视为一个独立展示模块来设计。
## 推荐的前端展示结构
以每个群友的人格卡片为单位，建议拆成 4 层：
### 1. 核心识别层
- 用户头像
- 用户名
- 群内称号
- 人格标签代码或人格名
### 2. 视觉氛围层
这一层最值得补强。
建议支持：
- 人格主题色
- 人格背景纹理
- 人格装饰图层
- 人格角色形象图或原型图
对于你提到的“像 ACGTI / SBTI 那样的人物形象图作为装饰背景”，建议优先做成弱化背景视觉，而不是主内容图：
- 右下角半透明立绘
- 卡片边缘剪影
- 低透明度 emblem
- 主题色渐变叠加
这样能兼顾可读性和氛围感。
### 3. 描述信息层
不建议只有一条 `reason`，建议预留扩展字段。
推荐展示字段：
- `subtitle`
一句副标题，例如“把场子点亮的人”
- `one_liner`
一句 punchline
- `reason`
基于群聊数据的命中说明
- `traits`
2 到 4 个关键词标签
- `rarity`
稀有度或趣味等级
### 4. 扩展信息层
适合高配 HTML 模板使用：
- `accent`
- `archetype`
- `match_score`
- `mood`
- `quote`
- `series`
## 前端实现切入点
当前最直接的切入点就是：
- 在 `_prepare_render_data` 里丰富 `title_data`
- 在各模板的 `user_title_item.html` 中消费新增字段
当前 `title_data` 只有：
- `name`
- `title`
- `mbti`
- `reason`
- `avatar_data`
建议后续扩展成：
```python
title_data = {
"name": title.name,
"title": title.title,
"mbti": title.mbti,
"reason": title.reason,
"avatar_data": avatar_data,
"label_system": "...",
"label_name": "...",
"label_code": "...",
"subtitle": "...",
"one_liner": "...",
"traits": [...],
"accent": "#7b6cff",
"rarity": "SR",
"background_image": "...",
"overlay_image": "...",
}
```
这样模板就可以自由决定展示深度：
- 简版模板只显示 `label_code + reason`
- 炫酷模板显示 `overlay_image + accent + subtitle + traits`
## 人物形象图的接入建议
你提到希望展示 `ACGTI`、`SBTI` 相关的人物形象图作为装饰背景，这个方向是对的，但建议分成两种来源。
### 1. 原型图层
适用于通用人格体系。
例如：
- `发光主角位` 对应一张统一原型图
- `冰面观察者` 对应一张统一原型图
- `CTRL` 对应一张统一视觉卡面
优点：
- 可控
- 不依赖具体 IP
- 容易统一风格
### 2. 角色图层
适用于更强的二次元产品化路线。
例如：
- `发光主角位` 命中后再映射一个具体角色形象
- 或者给某个标签体系附带角色视觉配置
这个方向更接近 `ACGTI`，但也更重：
- 要维护图资源
- 要考虑版权和来源
- 要解决模板适配
所以更推荐：
- 第一版先做“原型图层”
- 后续再允许体系作者配置“角色图层”
## 视觉资源配置建议
为了不把前端写死，建议让视觉资源也进入配置。
例如每个标签可配置：
- `accent`
- `background`
- `overlay_image`
- `badge_style`
- `layout_variant`
示例数据：
```json
{
"code": "CTRL",
"name": "拿捏者",
"subtitle": "方向感和控制力都很强",
"accent": "#6a5cff",
"background": "gradients/ctrl-purple-grid",
"overlay_image": "personas/ctrl-figure.webp",
"traits": ["推进型", "高控制感", "高响应"],
"rarity": "SR"
}
```
然后模板层按这些字段决定：
- 背景渐变
- 装饰图位置
- 标签胶囊颜色
- 是否展示角标
## 推荐的展示形态
基于当前插件的 HTML 报告能力，最建议做这三种展示形态：
### 1. 卡片墙
对应当前 `群友风云榜`。
每个群友一张人格卡：
- 左上头像
- 右侧称号和人格标签
- 右下角半透明原型图
- 下方命中描述
这是最容易落地的形态。
### 2. 详情弹层或展开区
HTML 报告可以做 hover / 展开效果，显示：
- 人格副标题
- 关键词
- 趣味短句
- 详细原因
- 稀有度
这会让页面更像一个测试产品，而不是普通报表。
### 3. 顶部群人格 Hero
参考 `ACGTI` 的结果页，可以在整份 HTML 报告顶部增加一个 Hero 区：
- 今日群人格主题
- 一句副标题
- 一张大号背景图或原型图
- 今日 dominant archetype
这样会显著提升页面的产品感。
## 可扩展字段设计
如果未来想让这块不止支持 `SBTI / ACGTI / MBTI`，而是轻松变成“自定义类 MBTI 产品”，那么字段设计需要前置抽象。
建议把当前 `UserTitle` 的趣味人格部分理解成两层：
- 群友结果层
- 标签体系定义层
## 群友结果层
每个用户的结果建议至少支持：
- `title`
- `label_code`
- `label_name`
- `subtitle`
- `reason`
- `traits`
- `rarity`
- `accent`
- `visual_key`
- `extra`
其中 `extra` 用于体系自定义扩展。
## 标签体系定义层
建议每个体系文件包含：
- `system_id`
- `display_name`
- `theme`
- `fields`
- `labels`
- `visuals`
- `prompt_strategy`
这里最关键的是 `fields`。
它决定“这个类 MBTI 产品想展示什么”。
示例：
```json
{
"system_id": "acgti-lite",
"display_name": "ACGTI Lite",
"theme": {
"card_style": "anime-archetype",
"hero_layout": "character-cover"
},
"fields": [
{"key": "label_code", "label": "原型代码", "type": "text"},
{"key": "label_name", "label": "人格原型", "type": "text"},
{"key": "subtitle", "label": "副标题", "type": "text"},
{"key": "one_liner", "label": "一句话描述", "type": "text"},
{"key": "traits", "label": "关键词", "type": "tag_list"},
{"key": "rarity", "label": "稀有度", "type": "badge"}
]
}
```
这样前端模板就不需要知道“是不是 MBTI”，而是根据体系定义去渲染。
## 轻松配置自己的类 MBTI 产品
如果目标是让使用者自己扩展一个新的“类 MBTI 产品”，推荐把门槛压到“写数据，不改代码”。
理想方式是让用户只要提供：
1. 一个体系定义文件
2. 一个标签列表文件
3. 一组可选视觉资源
4. 一段 prompt 提示策略
就能新增一个玩法。
### 最小可配置单元
建议插件支持下面这种最小结构：
```text
data/persona_systems/
my_fun_system/
manifest.json
labels.json
visuals/
hero.webp
labels/
label_a.webp
label_b.webp
```
### `manifest.json` 建议包含
- 系统名称
- 系统描述
- 输出字段
- 默认模板风格
- prompt 拼装策略
- 是否允许开放生成
### `labels.json` 建议包含
- 标签 code
- 标签名
- 副标题
- 短句
- 关键词
- 命中提示
- 视觉 key
- 稀有度
### 这样做的意义
以后如果想做这些，都不用重写后端逻辑：
- 职场人格测试版
- 二次元原型版
- 抽象互联网人格版
- 游戏公会群专属人格版
- 某项目组内部黑话人格版
## 面向模板的扩展建议
为了让模板不反复重写，建议把展示分成三个层级：
### Level 1：通用字段
所有模板都能消费：
- 头像
- 名称
- 称号
- 标签
- 理由
### Level 2：增强字段
高级模板可以消费：
- 副标题
- 关键词
- 稀有度
- 一句话文案
- accent
### Level 3：视觉字段
炫酷模板专用：
- 背景图
- 原型图
- 装饰贴纸
- 角色立绘
- card style variant
这样模板作者可以按能力选择支持深度。
## 推荐的产品化方向
如果把这块当成长期玩法，我更建议把它产品化成：
“群聊人格宇宙生成器”
而不只是：
“给用户加一个 MBTI 字段”
因为后者很快会遇到上限，前者则可以持续扩：
- 换标签体系
- 换视觉风格
- 换展示字段
- 换 prompt 策略
- 换群体玩法
## 对当前插件最值得优先落地的前端点
如果只挑最值得做的几个点，我会建议优先级如下：
1. 把 `user_title_item.html` 里的 “MBTI” 文案统一升级为“人格标签”或按体系动态显示
2. 给每个人格卡新增 `subtitle / traits / rarity / accent`
3. 支持卡片背景装饰图或人格原型图
4. 在整份 HTML 报告顶部增加“今日群人格” Hero 区
5. 抽象出“体系定义 + 标签定义 + 视觉资源”的配置结构
这五步一旦落下去，这个功能就不再只是“趣味标签补丁”，而会开始接近真正可扩展的类 MBTI 产品平台。
## 推荐方案
## 方案 A：仅改 Prompt，最快上线
### 做法
- 不改 Python 结构
- 不改 schema
- 不改渲染模板
- 只修改 `user_title_prompt`
- 在 prompt 中明确告诉模型：
- `mbti` 字段现在代表“人格标签结果”
- 可以输出 `MBTI`、`SBTI`、`ACGTI` 风格标签
- 优先输出更有趣、更贴合群聊气质的标签
### 优点
- 改动最小
- 几乎没有兼容成本
- 可以非常快验证用户是否买账
### 缺点
- 不可控，标签风格容易漂移
- 每次都靠 prompt 描述，复用性差
- 想新增体系时会让 prompt 越来越长
### 适合场景
- 想快速响应 Issue
- 想先做 A/B 试验
- 暂时不想引入额外数据文件
## 方案 B：配置化标签体系，推荐
这是我最推荐的落地方案。
### 目标
把“MBTI”升级为“可配置的人格标签体系”，但对现有调用链尽量保持兼容。
### 建议新增配置
可在 [`_conf_schema.json`](C:/Helianthus/SXP-Simon/astr/official/AstrBot/data/plugins/astrbot_plugin_qq_group_daily_analysis/_conf_schema.json) 中新增一组配置，例如：
- `persona_label_system`
可选值：`mbti`、`sbti-lite`、`acgti-lite`、`mixed`
- `persona_label_mode`
可选值：`strict`、`prefer_fun`
- `persona_label_candidates`
可选的候选标签列表，用于群定制
- `persona_label_show_name`
控制前端/报告里显示为“MBTI”“人格标签”“赛博人格”等文案
### 建议新增数据资产
建议在插件内新增一个数据目录，例如：
- `data/persona_label_systems/mbti.json`
- `data/persona_label_systems/sbti_lite.json`
- `data/persona_label_systems/acgti_lite.json`
每个体系文件建议至少包含：
- `id`
- `display_name`
- `style`
- `description`
- `labels`
其中每个 `label` 可包含：
- `code`
- `name`
- `prompt_hint`
- `tone`
- `examples`
- `rarity`
- `extra_tags`
### Prompt 组织方式
不要把所有体系说明硬编码到一个超长 prompt 里，建议按以下思路拼装：
1. 通用任务说明
2. 当前启用的标签体系说明
3. 当前体系允许输出的标签候选
4. 用户统计数据
5. 返回 JSON 结构
这样可以明显减少 token 浪费，也方便继续扩。
### 兼容建议
为了不打断现有链路：
- 仍然返回 `mbti` 字段
- 但允许其值为 `INTJ`、`CTRL`、`发光主角位` 这类结果
- 如果想让报告里显示更自然，可以在渲染层把字段标题从“MBTI”改成更中性的“人格标签”
这个方案下，内部字段名还是 `mbti`，但对用户展示时不再强调“必须是 MBTI 类型”。
## 方案 C：体系注册表，适合后续演进
如果后续准备把这块做成插件特色玩法，建议再往前走一步，做成注册式体系。
### 可抽象的接口
每个标签体系都定义这些能力：
- `build_prompt_context`
- `allowed_labels`
- `display_name`
- `result_formatter`
- `extra_sections`
更轻一点的做法是不做 Python 类，而是做数据驱动注册表：
- 一个注册文件声明有哪些体系
- 一个体系文件声明 prompt 片段、候选标签、展示文案
- 通用分析器负责装载和拼 prompt
### 这样做的收益
- 后面新增一个人格体系基本只要补数据文件
- 不需要不断改主分析器
- 很适合做社区共创
## 接入建议
## 推荐的第一版产品行为
第一版不建议把它做成“严肃人格测试”，建议定义成：
“根据群聊行为特征，为活跃群友生成趣味人格标签和称号”
这样产品预期更稳定，也更适合现有输入数据。
### 推荐输出格式
保持现在的结构不变：
```json
[
{
"name": "用户名",
"user_id": "123456",
"title": "沉默终结者",
"mbti": "CTRL",
"reason": "经常开启话题并推动群聊节奏，控制感强。"
}
]
```
这里的 `mbti` 实际就是“人格标签位”。
### 推荐的提示词原则
- 不追求心理学准确性
- 允许夸张和趣味化表达
- 必须基于群聊统计特征，不要完全瞎编
- 优先从有限候选中挑选，避免结果失控
- 当统计特征不明显时，允许回落到保守标签
## 与参考项目的映射建议
### `SBTI` 映射方式
适合做成“轻量趣味标签库”，不适合原样照搬完整测试流程。
建议做法：
- 选取 8 到 12 个辨识度高的 SBTI 标签做精简版
- 为每个标签写一条短描述和命中倾向
- 让模型基于统计特征做软匹配
示例：
- 高发言、高回复、高推进感 -> `CTRL` / `BOSS`
- 深夜活跃、低互动、高潜水回归 -> `ZZZZ`
- 高表情、高整活、高轻松内容 -> `JOKE-R` / `WOC!`
### `ACGTI` 映射方式
更适合借它的“原型层”思路，而不是直接输出具体角色。
建议做法：
- 先引入 `acgti-lite` 原型层
- 第一版只输出 8 个 archetype 风格标签
- 暂时不输出具体角色名，避免知识偏移和用户圈层门槛
示例：
- 高表达、高带头 -> `发光主角位`
- 高秩序、高责任 -> `誓约队长`
- 低表达、高观察 -> `冰面观察者`
- 高戏剧性、高整活 -> `混沌火花`
这类标签对大多数用户更友好，也更通用。
## 建议的实现拆分
## 第一阶段：低风险接入
目标：先把“支持趣味 MBTI 变体”做出来。
建议改动：
1. 调整 `user_title_prompt` 文案
2. 将“MBTI 类型”改写成“人格标签”
3. 在 prompt 中加入可选体系说明和候选标签示例
4. 若展示层有“MBTI”字样，统一改成更中性的文案
这一阶段可以不改数据模型。
## 第二阶段：配置化
目标：让运营或使用者可切换标签体系。
建议改动：
1. `_conf_schema.json` 增加 `persona_label_system`
2. `ConfigManager` 增加对应读取方法
3. `user_title_analyzer.py` 在构建 prompt 时注入当前体系上下文
4. 新增标签体系数据文件
这一阶段仍可保留 `mbti` 字段名。
## 第三阶段：完整扩展
目标：做成插件特色玩法。
建议改动：
1. 抽象标签体系注册表
2. 支持体系专属展示文案
3. 支持体系专属扩展字段
4. 为 HTML 模板增加标签体系样式区块
5. 加入群体级人格总结和彩蛋玩法
## 可以做的玩法扩展
除了“给每个人一个趣味标签”，还可以继续扩展：
### 1. 群整体人格
给整群一个标签，例如：
- “今日群像：混沌火花型技术吐槽局”
- “本群常驻人格：高压锅版 CTRL 群”
### 2. 今日人格漂移
对比最近几天，输出：
- 今天比昨天更 `BOSS`
- 最近一周从“冰面观察者”漂移到“混沌火花”
### 3. 相性/组合梗
识别群内典型组合：
- `CTRL + JOKE-R` 负责带节奏
- `月下守护者 + 温柔修复者` 负责接情绪
### 4. 彩蛋机制
参考 `SBTI` 的做法，可以做：
- 深夜消息比例极高触发隐藏标签
- 表情包占比极高触发表情彩蛋标签
- 某类高频群梗触发专属人格
### 5. 群专属标签体系
允许群主或管理员自定义：
- 标签名
- 标签简介
- 命中倾向
- 群内黑话
这会非常适合私域群、游戏群、项目群。
## Token 与效果平衡建议
Issue 里提到“没必要太精确，省点 token”，这一点非常合理。
建议控制方式：
- 单次只对 Top N 活跃用户做标签分析
- 每个体系只提供有限候选标签，不做开放生成
- 每个标签说明尽量控制在一两句话
- 不做复杂问卷，不新增多轮交互
- 需要时优先用统计特征做硬约束，再让 LLM 写 `reason`
简单说：
- “让模型选标签”比“让模型创造体系”更省
- “给有限候选列表”比“完全开放生成”更稳
## 风险与注意事项
### 1. 字段名风险
内部字段目前就是 `mbti`。
如果急着改字段名，会牵涉：
- 数据模型
- schema
- 校验
- 正则提取
- 报告渲染
所以建议先保留。
### 2. 标签漂移风险
如果候选不收敛，模型会出现：
- 一会儿输出 MBTI
- 一会儿输出二次元原型
- 一会儿输出自己瞎造的标签
所以一定要给“当前体系允许输出的候选列表”。
### 3. 圈层门槛风险
像 `ACGTI` 具体角色名虽然好玩，但不是所有群都懂。
因此第一版建议输出“原型标签”，不要直接输出角色名。
### 4. 解释过拟合风险
当前输入数据主要是：
- 发言数
- 平均字数
- 表情比例
- 夜间比例
- 回复比例
这些特征足够做趣味标签，但不足以支撑太细的人格论断。
所以文案风格要保持“娱乐化、观察式”，不要写得像心理测评结论。
## 推荐落地顺序
如果目标是“先把 Issue 做漂亮”，推荐这样排：
1. 先做 `方案 A`，验证用户接受度
2. 很快补成 `方案 B`，把体系切换能力做出来
3. 有反馈后再考虑 `SBTI` 彩蛋、`ACGTI` 原型层、群整体人格等玩法
## 最终建议
这次需求最合适的方向，不是“新增一个 MBTI 功能”，而是：
“把用户称号分析升级成可扩展的趣味人格标签系统”
其中：
- `SBTI` 适合提供“标签库、文案库、彩蛋感”
- `ACGTI` 适合提供“分层抽象、原型扩展、数据驱动”
- 当前插件非常适合从 `user_title_analysis` 这一层切入
如果只做一版最划算的实现，我建议：
- 保留 `mbti` 字段
- 新增 `persona_label_system` 配置
- 提供 `mbti`、`sbti-lite`、`acgti-lite` 三种体系
- 报告展示文案统一改成“人格标签”
这样能用很小的改动，把后续扩展空间直接打开。
docs/simple_mbti_profile_mapping_spec.md
+435
View File
@@ -0,0 +1,435 @@
# MBTI 三模式角色映射规范
## 结论先行
这次需求的本质不是改分析逻辑，而是改展示逻辑。
第一版建议这样做：
1. 保留现有 `MBTI` 分析链路
2. 不修改分析区提示词
3. 不新增复杂人格推断
4. 只在渲染阶段，根据当前选择的模式，把 `MBTI` 映射成对应主题的角色图和中文标签
也就是说：
- LLM 继续输出 `mbti`
- 插件渲染前根据模式做一次查表
- 把对应图片、中文名、缩写一起塞到群友画像卡片里
这是最稳、最省改动、也最符合当前插件结构的方案。
## 产品行为定义
建议把原本单一的 `MBTI` 展示拆成三个模式：
- `mbti`
- `sbti`
- `acgti`
这三个模式只影响“展示映射”和“背景图呈现”，不影响 LLM 分析本身。
## 三种模式的定义
### 1. `mbti` 模式
直接展示原始 MBTI。
例如：
- `INFP`
- `ENTJ`
可选显示文案：
- `INFP`
- `INFP（调停者）`
这一模式下不强制使用角色图，可以留空，或者允许用户自行配置一张通用背景图。
### 2. `sbti` 模式
先拿现有 `MBTI`，再查一张 `MBTI -> SBTI` 的朴素映射表。
例如：
- `INTJ -> CTRL（拿捏者）`
- `INFP -> SOLO（孤儿）`
- `ENTP -> JOKE-R（小丑）`
展示时不要只显示缩写，建议统一使用：
- `CTRL（拿捏者）`
- `SOLO（孤儿）`
- `JOKE-R（小丑）`
### 3. `acgti` 模式
先拿现有 `MBTI`，再查 `MBTI -> ACGTI 角色`。
例如：
- `INFP -> BCHI（后藤一里）`
- `INTP -> KNAN（江户川柯南）`
- `ENTJ -> SAKI（丰川祥子）`
展示时同样不要只显示缩写，建议统一使用：
- `BCHI（后藤一里）`
- `KNAN（江户川柯南）`
- `SAKI（丰川祥子）`
## 关键原则
### 1. 不改提示词
这一版明确不改：
- `user_title_prompt`
- 其他分析 prompt
- 分析 schema
原因很简单：
- 当前链路已经能稳定输出 `mbti`
- 需求只是“换主题展示”
- 如果为了展示层去改分析 prompt，收益很低，风险反而上升
所以第一版只做展示映射。
### 2. 中文必须跟着缩写一起展示
`SBTI` 和 `ACGTI` 的缩写对普通用户不友好。
因此建议统一采用：
- `缩写（中文名）`
例如：
- `CTRL（拿捏者）`
- `THIN-K（思考者）`
- `BCHI（后藤一里）`
- `FRNA（芙宁娜）`
不要只显示：
- `CTRL`
- `BCHI`
否则用户几乎看不懂。
### 3. 图片只做底层淡淡显示
考虑到当前模板很多已经成型，不适合大改布局，建议角色图只做背景装饰层。
推荐效果：
- 右下角淡化立绘
- 卡片底层低透明度剪影
- 遮罩后只保留 8% 到 18% 可见度
- 永远不压住正文
不要做：
- 大图占满卡片
- 直接盖在文字上
- 高饱和实底遮挡
## 最适合当前插件的实现方式
当前插件最适合的实现点不是分析器，而是渲染器。
直接在 [`src/infrastructure/reporting/generators.py`](C:/Helianthus/SXP-Simon/astr/official/AstrBot/data/plugins/astrbot_plugin_qq_group_daily_analysis/src/infrastructure/reporting/generators.py) 的 `_prepare_render_data` 阶段，把 `title_data` 扩展一下即可。
当前已经有：
```python
title_data = {
"name": title.name,
"title": title.title,
"mbti": title.mbti,
"reason": title.reason,
"avatar_data": avatar_data,
}
```
建议扩成：
```python
title_data = {
"name": title.name,
"title": title.title,
"mbti": title.mbti,
"reason": title.reason,
"avatar_data": avatar_data,
"profile_mode": "mbti",
"profile_display": "INFP（调停者）",
"profile_image": "https://...",
"profile_image_opacity": 0.12,
"profile_code": "INFP",
"profile_name_zh": "调停者",
}
```
或者在 `sbti` / `acgti` 模式下：
```python
title_data = {
...
"profile_mode": "sbti",
"profile_display": "SOLO（孤儿）",
"profile_image": "https://...",
"profile_image_opacity": 0.12,
"profile_code": "SOLO",
"profile_name_zh": "孤儿",
}
```
## 三模式的简单映射表
下面这张表就是第一版最够用的范式。
| MBTI | SBTI | SBTI中文 | ACGTI | ACGTI中文 |
|------|------|----------|-------|-----------|
| INTJ | CTRL | 拿捏者 | MRTS-X | Mortis |
| INTP | THIN-K | 思考者 | KNAN | 江户川柯南 |
| ENTJ | BOSS | 领导者 | SAKI | 丰川祥子 |
| ENTP | JOKE-R | 小丑 | CHKA | 藤原千花 |
| INFJ | LOVE-R | 多情者 | DLRS | 三角初华 |
| INFP | SOLO | 孤儿 | BCHI | 后藤一里 |
| ENFJ | THAN-K | 感恩者 | YCYO | 月见八千代 |
| ENFP | GOGO | 行者 | HTMK | 初音未来 |
| ISTJ | OH-NO | 哦不人 | MRTS | 若叶睦 |
| ISTP | POOR | 贫困者 | AYRE | 绫波丽 |
| ESTJ | SHIT | 愤世者 | MIKT | 御坂美琴 |
| ESTP | WOC! | 握草人 | ASKA | 明日香 |
| ISFJ | MUM | 妈妈 | SOYO | 长崎爽世 |
| ISFP | MALO | 吗喽 | LTYI | 洛天依 |
| ESFJ | ATM-er | 送钱者 | ANON | 千早爱音 |
| ESFP | SEXY | 尤物 | FRNA | 芙宁娜 |
说明：
- `ACGTI` 基本直接使用其 `characters.json` 中的 `matchCode`
- `SBTI` 没有现成 MBTI 对照，这里采用产品化朴素映射
## 推荐的资源组织方式
不要直接把参考仓库路径写死在业务里。
建议统一在插件自己的目录中组织资源。
例如：
```text
data/profile_assets/
sbti/
CTRL.png
THIN-K.png
SOLO.png
acgti/
BCHI.png
KNAN.png
HTMK.png
mbti/
INFP.png
ENTJ.png
```
如果你不想把图片打包进插件，也可以完全用外链。
重点是：插件只消费配置里的图片地址，不负责图片可访问性。
也就是说：
- 插件不保证 URL 有效
- 插件不代理图片
- 插件不检查 CDN 稳定性
- 用户自行维护图片可用性
## 推荐的配置方式
考虑到 AstrBot 插件配置的使用习惯，建议不要让用户去改复杂 JSON 文件路径嵌套。
第一版更适合：
1. `_conf_schema.json` 里新增几个简单配置项
2. 再加一个可编辑的 JSON 文本配置项
## 建议新增配置项
### 1. 展示模式
```json
"profile_display_mode": {
"type": "string",
"description": "人格展示模式",
"options": ["mbti", "sbti", "acgti"],
"default": "mbti",
"hint": "只影响群友画像卡片的角色主题展示，不影响实际 MBTI 分析结果。"
}
```
### 2. 图片透明度
```json
"profile_image_opacity": {
"type": "float",
"description": "人格背景图透明度",
"default": 0.12,
"hint": "建议 0.08 ~ 0.18，仅作为卡片底层装饰，避免遮挡正文。"
}
```
### 4. 人格映射配置
这个配置项建议直接给用户一个可编辑文本框。
```json
"profile_mapping_config": {
"type": "text",
"description": "人格映射配置(JSON)",
"editor_mode": true,
"editor_language": "json",
"default": "{ ... }",
"hint": "按 MBTI 映射到当前展示模式的人格名称与图片地址。插件不负责校验图片链接可访问性。"
}
```
这样非常符合 AstrBot 插件当前配置编辑习惯：
- 简单开关和枚举用普通字段
- 稍复杂结构用 JSON 文本编辑
不需要用户去改仓库文件，也不需要特别麻烦的路径维护。
## 推荐的映射配置范式
建议把最终配置压成一个容易编辑的结构。
例如：
```json
{
"mbti": {
"INFP": {
"code": "INFP",
"name_zh": "调停者",
"display": "INFP（调停者）",
"image": "https://example.com/mbti/INFP.png"
}
},
"sbti": {
"INFP": {
"code": "SOLO",
"name_zh": "孤儿",
"display": "SOLO（孤儿）",
"image": "https://example.com/sbti/SOLO.png"
}
},
"acgti": {
"INFP": {
"code": "BCHI",
"name_zh": "后藤一里",
"display": "BCHI（后藤一里）",
"image": "https://example.com/acgti/BCHI.png"
}
}
}
```
这份结构有几个好处：
- 用户不需要理解 `systems`、`items`、`asset_base` 这类抽象概念
- 直接按当前模式查 `mode -> mbti`
- 修改图片地址最直观
- 修改中文标注也最直观
## 最简单的查表逻辑
伪代码如下：
```python
mode = config_manager.get_profile_display_mode()
mapping_config = config_manager.get_profile_mapping_config()
mbti = (title.mbti or "").strip().upper()
profile_info = mapping_config.get(mode, {}).get(mbti, {})
title_data["profile_mode"] = mode
title_data["profile_code"] = profile_info.get("code", mbti)
title_data["profile_name_zh"] = profile_info.get("name_zh", "")
title_data["profile_display"] = profile_info.get(
"display",
f"{title_data['profile_code']}（{title_data['profile_name_zh']}）"
if profile_info.get("name_zh")
else title_data["profile_code"],
)
title_data["profile_image"] = profile_info.get("image", "")
title_data["profile_image_opacity"] = config_manager.get_profile_image_opacity()
title_data["profile_image_size_mode"] = config_manager.get_profile_image_size_mode()
```
## 模板呈现建议
当前模板不适合大改，所以建议只做轻微增强。
### 必做项
- 在卡片中显示 `profile_display`
- 也就是：
- `INFP（调停者）`
- `SOLO（孤儿）`
- `BCHI（后藤一里）`
### 选做项
- 如果 `profile_image` 存在，就作为卡片底层背景图
- 使用绝对定位
- 透明度由配置控制
- 默认放右下角
### 推荐 CSS 策略
```css
.profile-overlay {
position: absolute;
right: 8px;
bottom: 8px;
width: 40%;
height: 70%;
object-fit: contain;
opacity: 0.12;
pointer-events: none;
filter: saturate(0.9) contrast(1.02);
}
```
建议再加一个浅遮罩，保证文字可读。
## 不建议做的事情
为了保持简单，第一版不建议：
- 改分析提示词
- 改 `mbti` 字段语义
- 引入复杂前端交互
- 做随机抽卡式角色匹配
- 一次同时显示 `MBTI + SBTI + ACGTI` 三套大块内容
第一版就做“单模式切换显示”最合理。
## 最终建议
如果把这次需求收敛成一句话，就是：
“现有 MBTI 结果不变，只新增三种主题展示模式，在群友画像卡片中用中文补全后的标签和淡化角色底图进行呈现。”
对应实现策略就是：
1. 不改 prompt
2. 不改分析结果结构
3. 配置里新增一个模式开关
4. 配置里新增一个易编辑的映射 JSON
5. 模板里只增加一个淡化背景图层和一个新的显示字段
这就是当前插件里最轻量、最稳、最容易扩展的做法。