abot/docs/群运营分析2.0推进方案.md

ABOT 群运营分析 2.0 推进方案

1. 文档目标

本文档用于明确 ABOT 当前“群运营分析”能力的现状、缺口与下一阶段建议落地方向，帮助后续开发时避免重复建设，也避免一次性把范围做得过重。

本文重点不是从零设计一套全新系统，而是：

• 识别当前项目已经具备的群运营分析基础
• 找出哪些数据资产已经落库但尚未产品化使用
• 定义一版“最小但有感知”的群运营分析 2.0
• 给出可直接进入开发的页面、接口与迭代顺序建议

---

2. 当前能力现状

从现有代码与后台页面看，项目已经具备一版“群运营分析 1.0”，并不属于从零起步。

2.1 已有前台能力

当前后台已经有以下页面与展示能力：

• 群组统计总览页
• 群活跃度排行
• 群详情弹窗 / 详情面板
• 健康度评分
• 基于规则的运营建议
• 沉默成员排行
• 发言成员排行
• 消息趋势与高峰时段
• 插件调用情况与插件覆盖度

已存在的主要页面：

• admin/dashboard/templates/groups.html
• admin/dashboard/templates/contacts_management.html
• admin/dashboard/templates/robot_management.html

2.2 已有后端聚合能力

当前群详情接口已经不是简单查表，而是做了相当多的聚合计算，主要包括：

• 群成员概览统计
• 近 24 小时 / 7 天 / 30 天消息统计
• 消息类型占比
• 近 14 天消息趋势
• 近 30 天小时分布与高峰时段
• 插件调用汇总
• 插件成功率
• 群健康度评分
• 基于阈值规则的运营建议

对应核心接口：

• admin/dashboard/blueprints/robot.py 中的 /robot/api/group/<group_id>/detail

2.3 已有数据资产

项目中已经沉淀了不少可直接复用的运营分析数据表，这意味着 2.0 更多是“产品化串联”，而不是“重新采集数据”。

1. 消息与活跃度基础数据

• messages
• speech_counts
• t_chatroom_member
• t_chatrooms

可支持：

• 群消息量趋势
• 发言排行
• 活跃覆盖率
• 沉默成员识别
• 高峰时段识别

2. 机器人使用与插件渗透数据

• t_group_stats
• t_group_command_user_stats
• t_plugin_stats
• t_user_stats

可支持：

• 插件调用量
• 插件成功率
• 插件覆盖度
• 唯一触发人数
• 功能渗透度判断

3. 总结与画像类数据

• t_message_summary
• t_group_profile_snapshot
• t_member_context
• t_member_digest

可支持：

• 群定位摘要
• 高频讨论主题
• 群风格判断
• 核心成员画像
• 成员分层总结

4. 关系与互动网络数据

• t_message_mentions
• t_social_edges_daily

可支持：

• 谁经常主动互动
• 谁经常被点名 / 被@
• 谁是核心连接点
• 小圈层 / 搭子关系

5. 运营价值分层数据

• t_value_rank_snapshot

可支持：

• 群内核心成员识别
• 高价值成员榜单
• 待召回边缘成员识别

---

3. 当前缺口判断

虽然当前已经有不少分析能力，但整体上更偏：

• 机器人在群里的使用分析
• 群活跃度基础诊断

还没有完全升级成：

• 面向运营动作的群运营控制台

当前主要缺口在以下几个方面。

3.1 有统计，但缺少“结论表达”

当前很多页面已经能展示数字、排行与趋势，但管理员仍然需要自己把这些数字转化为判断。

例如：

• 这个群到底是闲聊群、工具群还是运营群
• 这个群最近是升温还是降温
• 这个群更适合推签到、排行还是话题互动

这些结论目前还没有被显式产品化。

3.2 有建议，但缺少“可执行动作”

当前已有 operation_suggestions，但更多是规则式提示，例如：

• 沉默成员较多
• 活跃覆盖率偏低
• 插件渗透率不足

这些建议已经有价值，但还不够“下一步就能做”。例如还缺：

• 建议在什么时间发互动
• 建议激活哪些成员
• 建议给这个群重点推什么功能
• 建议减少哪些高失败命令

3.3 有画像数据，但没有统一编排成运营视图

项目已经具备：

• 群画像
• 成员画像
• 成员摘要
• 群总结

但这些数据更多还停留在插件内部能力或独立存储层，后台没有统一组装成“运营者一眼能看懂”的页面。

3.4 有关系数据，但没有做成差异化能力

t_message_mentions 和 t_social_edges_daily 已经是很有价值的数据资产，但当前群运营页面里还没有把它们真正用起来。

如果后续继续做群运营分析，这一块最容易形成差异化。

---

4. 群运营分析 2.0 的目标

建议把“群运营分析 2.0”定义为：

从“看群数据”升级为“理解群状态，并给出下一步运营动作建议”。

它不应只是增加更多图表，而应该让后台具备以下能力：

• 看懂这个群是什么群
• 看懂这个群最近变好了还是变差了
• 看懂谁是核心成员、谁是边缘成员、谁值得激活
• 看懂机器人在这个群里应该推什么、不应该推什么
• 给出下一步可执行的运营动作建议

---

5. 建议产品形态

建议 2.0 不再只围绕“群组统计排行页”，而是把重点放在“单个群的运营分析详情页 / 详情面板”上。

推荐拆成 4 个核心板块。

5.1 板块一：群体检

定位：回答“这个群当前健康不健康，最近趋势如何”。

建议展示：

• 群健康分
• 近 7 天 / 30 天消息趋势
• 活跃覆盖率趋势
• 沉默成员占比
• 插件渗透趋势
• 新增活跃成员数
• 最近 30 天消息类型结构

输出价值：

• 这个群是在升温还是降温
• 互动是变多还是变少
• 机器人功能是否在被持续使用

5.2 板块二：群画像

定位：回答“这是一个什么群，大家最近在聊什么”。

建议展示：

• 群定位摘要
• 群风格标签
• 高频主题
• 最近热点内容
• 活跃时段画像
• 群公告 / 群定位与实际讨论是否一致

优先复用数据：

• t_message_summary
• t_group_profile_snapshot
• messages

输出价值：

• 管理员不用翻聊天记录，也能快速理解群状态
• 为后续机器人策略和运营动作提供上下文

5.3 板块三：成员分层与关系

定位：回答“这个群是谁在带动、谁沉默了、谁值得运营”。

建议展示：

• 核心成员榜
• 高价值成员榜
• 沉默成员榜
• 边缘活跃成员列表
• 最近被@最多成员
• 最近主动互动最多成员
• 核心关系对 / 搭子关系

优先复用数据：

• t_chatroom_member
• t_member_context
• t_member_digest
• t_message_mentions
• t_social_edges_daily
• t_value_rank_snapshot

输出价值：

• 从“谁发言多”升级为“谁值得重点运营”
• 为召回、分层激活、群活动设计提供依据

5.4 板块四：运营动作建议

定位：回答“下一步具体该做什么”。

建议展示：

• 推荐互动时间
• 推荐激活对象
• 推荐主推插件类型
• 推荐减少 / 优化的高失败指令
• 推荐欢迎语 / 菜单引导策略
• 推荐一条可直接发布的话题引导文案

输出形式建议：

• 直接给行动卡片
• 每张卡片包含：问题、原因、建议动作、适用对象

输出价值：

• 把群运营分析从“分析报表”变成“决策辅助工具”

---

6. 建议先做的最小版本

为了降低改动风险，建议群运营分析 2.0 第一版只做“最有感知、最少侵入”的部分，不要一上来就做复杂关系图谱和大规模新表。

6.1 第一版范围

建议第一版只落以下内容：

1. 群画像摘要卡

展示内容：

• 群定位摘要
• 最近 7 天热点主题
• 群风格标签
• 推荐运营方向

优先数据源：

• t_group_profile_snapshot
• t_message_summary
• 若无画像快照，则用现有统计数据兜底输出

2. 群趋势体检卡

展示内容：

• 近 7 / 30 天消息变化
• 活跃覆盖率变化
• 沉默成员变化
• 插件调用变化

说明：

• 第一版不必做太多新图表，可以先用趋势值 + 小型趋势图

3. 成员分层卡

展示内容：

• 核心成员 Top N
• 待激活成员 Top N
• 沉默成员 Top N

说明：

• 第一版先不做关系网络可视化
• 先把“谁值得运营”这件事讲清楚

4. 运营动作建议卡

展示内容：

• 建议高峰互动时间
• 建议主推功能
• 建议重点激活成员
• 建议优化命令入口

说明：

• 第一版仍然可以以规则引擎为主
• 不需要一开始就上 LLM 动作建议

6.2 第一版暂不处理

为了避免范围膨胀，建议先不做：

• 复杂关系网可视化
• 群与群之间横向对标
• 自动生成完整运营周报 / 月报
• 大量新增定时任务
• 全自动策略闭环
• 基于 LLM 的高成本全量分析

---

7. 建议数据复用策略

群运营分析 2.0 尽量优先复用现有数据表，减少对主链路侵入。

7.1 直接复用

• messages
• t_chatroom_member
• t_group_stats
• t_message_summary
• t_group_profile_snapshot
• t_member_context
• t_member_digest
• t_message_mentions
• t_social_edges_daily
• t_value_rank_snapshot

7.2 能不用新增表就先不用

第一版尽量通过已有聚合查询和轻量接口拼装页面，不要急着新增“群运营宽表”。

原因：

• 当前仓库数据层职责已经偏重
• 先验证产品结构是否有效，比先扩表更重要
• 宽表可以放到后续性能优化阶段再做

7.3 需要注意的数据口径

后续实现时要统一口径，避免页面数值互相打架：

• 成员统计只基于 status = 1 的在群成员
• 活跃覆盖率要区分 7 天和 30 天窗口
• 插件渗透度要明确是“插件种类数”还是“触发人数占比”
• 沉默成员口径要统一为“30 天未发言或从未发言”
• 趋势对比要说明是“环比上周 / 环比上月”

---

8. 推荐接口拆分

建议不要继续把所有逻辑都堆在一个群详情接口里，可以在不破坏兼容性的前提下做轻拆分。

8.1 可保留现有接口

保留：

• /robot/api/group/<group_id>/detail

用途：

• 继续服务现有页面
• 作为兼容入口存在

8.2 建议新增的 2.0 接口

建议新增以下接口：

1. 群运营概览接口

• /robot/api/group/<group_id>/ops_overview

职责：

• 返回健康分
• 趋势摘要
• 活跃覆盖率
• 沉默成员占比
• 插件渗透度

2. 群画像接口

• /robot/api/group/<group_id>/ops_profile

职责：

• 返回群画像摘要
• 热点主题
• 群风格标签
• 高峰时段建议

3. 成员分层接口

• /robot/api/group/<group_id>/ops_members

职责：

• 返回核心成员
• 沉默成员
• 待激活成员
• 高价值成员

4. 动作建议接口

• /robot/api/group/<group_id>/ops_actions

职责：

• 返回可执行的运营建议卡片

这样做的好处：

• 降低单接口复杂度
• 页面可按模块懒加载
• 后续更容易单独优化每个板块

---

9. 页面推进建议

推荐优先在现有群详情视图上增强，而不是立即新开一套全新后台模块。

9.1 第一阶段

优先增强现有群详情视图：

• contacts_management.html 中的群洞察面板
• 或 groups.html 的详情弹层

原因：

• 改动更小
• 用户路径更短
• 不需要重新设计入口

9.2 第二阶段

如果第一阶段效果好，再考虑独立成真正的“群运营分析详情页”。

页面结构建议：

• 群体检
• 群画像
• 成员分层
• 行动建议

---

10. 推荐迭代顺序

建议按以下顺序推进。

第一步：群画像摘要卡

优先级最高。

原因：

• 用户感知最强
• 可直接复用已有画像/总结数据
• 风险相对低

第二步：成员分层卡

原因：

• 最贴近运营动作
• 能立刻产生“该找谁运营”的价值

第三步：动作建议卡

原因：

• 把分析结果转成可执行动作
• 让页面从“报表”变成“工具”

第四步：趋势增强

原因：

• 趋势图和环比更像锦上添花
• 可以放在前面几项做完后补

第五步：关系网络能力

原因：

• 虽然价值高，但实现与展示复杂度也最高
• 适合作为 2.1 或 3.0 增强项

---

11. 最终建议

群运营分析这条线现在不应该再理解为“补一个统计页”，而应该升级为：

• 用现有数据资产理解单个群
• 给出可执行的运营动作建议
• 逐步把后台从“管理面板”做成“运营辅助台”

如果只做一个最小且最值得推进的版本，建议直接落：

1. 群画像摘要卡
2. 成员分层卡
3. 运营动作建议卡

这三块最容易体现价值，也最不容易把工程范围做炸。