diff --git a/docs/群运营分析2.0推进方案.md b/docs/群运营分析2.0推进方案.md
new file mode 100644
index 0000000..0ed90c9
--- /dev/null
+++ b/docs/群运营分析2.0推进方案.md
@@ -0,0 +1,580 @@
+# 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. 运营动作建议卡
+
+这三块最容易体现价值，也最不容易把工程范围做炸。