Use when: 需要生成数据报告、收集整理用户反馈、进行数据驱动的分析汇报 Do NOT use when: 数据已由BI系统自动生成、无需人工分析
Scanned 5/27/2026
Install via CLI
openskills install konglong87/superPM---
name: pm-report
version: 2.0.0
description: |
Use when: 需要生成数据报告、收集整理用户反馈、进行数据驱动的分析汇报
Do NOT use when: 数据已由BI系统自动生成、无需人工分析
allowed-tools:
- Agent
- Read
- Write
- AskUserQuestion
- Bash
---
## Preamble
```bash
bash "$(dirname "${BASH_SOURCE[0]}")"/check-update.sh 2>/dev/null || true
mkdir -p docs/03-增长迭代/数据报告
mkdir -p docs/03-增长迭代/用户反馈
echo "📊 数据报告与用户反馈工具已启动"
# 检查数据指标体系
if [ -f "docs/02-方案设计/数据指标体系.md" ]; then
echo "✅ 数据指标体系 - 已找到"
else
echo "⏳ 数据指标体系 - 未找到(建议先执行 /pm-data)"
fi
```
---
## 执行流程
```dot
digraph pm_report {
rankdir=TB;
node [shape=box, style=filled, fillcolor="#e3f2fd"];
"选择报告类型" -> "收集数据";
"收集数据" -> "数据分析";
"数据分析" -> "用户反馈整理";
"用户反馈整理" -> "输出报告";
}
```
### 步骤 1: 选择报告类型
使用 AskUserQuestion 询问:
> 📊 选择报告类型
>
> A) 日报(核心指标概览)
> B) 周报(周度数据总结)
> C) 月报(月度数据分析)
> D) 专项报告(特定主题分析,如转化率分析)
> E) 用户反馈整理(收集和分类用户反馈)
> F) 其他(请手动输入)
>
> 💡 提示:
> - 日常监控 → 日报
> - 团队同步 → 周报
> - 管理层汇报 → 月报
> - 问题定位 → 专项报告
记录到变量 `REPORT_TYPE`
---
### 步骤 2: 收集数据
基于数据指标体系或手动输入,收集关键指标数据。
> 📈 指标数据采集
>
> 请提供以下核心指标数据(如无法提供,可跳过):
>
> **用户指标**:
> - DAU(日活跃用户数):[输入]
> - MAU(月活跃用户数):[输入]
> - 新增用户数:[输入]
>
> **业务指标**:
> - GMV/营收:[输入]
> - ARPU(每用户平均收入):[输入]
>
> **转化指标**:
> - 整体转化率:[输入]
> - 各环节转化率:[输入]
>
> A) 我有完整数据,逐项输入
> B) 我只有部分数据,先填能填的
> C) 暂无数据,只做趋势分析
---
### 步骤 3: 数据分析
> 📊 数据分析:
>
> **对比分析**:
> - 环比(对比上期):{[数据]}
> - 同比(对比去年同期):{[数据]}
> - 目标达成率:{[数据]}
>
> **趋势判断**:
> - 上升趋势:{指标} 持续上升
> - 下降趋势:{指标} 需要关注
> - 稳定状态:{指标} 在正常范围
>
> **异常识别**:
> - {指标1}:{描述异常}
> - {指标2}:{描述异常}
>
> 是否需要深入分析某个异常?
---
### 步骤 4: 用户反馈整理(可选)
如果选择了"用户反馈整理":
> 💬 用户反馈来源:
>
> A) 应用商店评价
> B) 客服工单
> C) 用户访谈/调研
> D) 社交媒体(微博/知乎)
> E) 内部反馈(运营/销售)
> F) 以上多项
>
> **反馈分类**:
> - Bug/故障:[X]条
> - 功能建议:[X]条
> - 体验问题:[X]条
> - 投诉/不满:[X]条
> - 表扬:[X]条
>
> **高频关键词**:{关键词1}、{关键词2}、{关键词3}
---
### 步骤 5: 输出报告
根据报告类型,使用 Write 生成对应文档。
**报告通用结构**:
```markdown
# {产品名称} - {报告类型} - {日期}
## 一、核心指标总览
| 指标 | 本期 | 上期 | 环比 | 目标 | 达成率 |
|------|------|------|------|------|--------|
| DAU | [X] | [X] | ±X% | [X] | X% |
| 新增用户 | [X] | [X] | ±X% | [X] | X% |
| GMV | [X] | [X] | ±X% | [X] | X% |
| 转化率 | X% | X% | ±Xpp | X% | X% |
## 二、数据趋势分析
### 2.1 核心指标趋势
{趋势描述}
### 2.2 关键变化说明
- {变化1}:{原因分析}
- {变化2}:{原因分析}
## 三、异常说明
| 异常指标 | 表现 | 原因 | 处理状态 |
|---------|------|------|---------|
| {指标} | {异常描述} | {初步判断} | 处理中/已解决 |
## 四、改进建议
1. {建议1}
2. {建议2}
3. {建议3}
---
**生成时间**: {时间戳}
**数据来源**: {数据来源}
```
**文件路径**:
- 日报 → `docs/03-增长迭代/数据报告/日报-YYYY-MM-DD.md`
- 周报 → `docs/03-增长迭代/数据报告/周报-YYYY-WW.md`
- 月报 → `docs/03-增长迭代/数据报告/月报-YYYY-MM.md`
- 用户反馈 → `docs/03-增长迭代/用户反馈/反馈汇总-YYYY-MM.md`
---
### 步骤 6: 完成提示
> ✅ {报告类型}已生成!
>
> 📄 文件:`docs/03-增长迭代/数据报告/{文件名}`
>
> 🎯 建议下一步:
>
> A) 执行 /pm-iteration - 基于数据制定迭代计划
> B) 执行 /pm-retro - 迭代复盘
> C) 生成其他类型报告
---
## 兜底机制
### 场景: 无数据指标体系
如果无前置数据指标体系文档,提示用户手动输入关键指标。
---
## V2 并行架构升级
### 架构概览
```dot
digraph pm_report_subagent {
rankdir=LR;
node [shape=box, style=filled, fillcolor="#e3f2fd"];
subgraph cluster_main {
label="主Agent";
style=filled;
fillcolor="#f5f5f5";
"主Agent交互";
}
subgraph cluster_parallel {
label="并行分析Subagent (V2)";
style=filled;
fillcolor="#f8f9fa";
"指标分析Subagent" [fillcolor="#c8e6c9"];
"趋势分析Subagent" [fillcolor="#bbdefb"];
"用户反馈Subagent" [fillcolor="#fff9c4"];
"异常检测Subagent" [fillcolor="#f8bbd0"];
}
"主Agent交互" -> "指标分析Subagent";
"主Agent交互" -> "趋势分析Subagent";
"主Agent交互" -> "用户反馈Subagent";
"主Agent交互" -> "异常检测Subagent";
"指标分析Subagent" -> "主Agent整合";
"趋势分析Subagent" -> "主Agent整合";
"用户反馈Subagent" -> "主Agent整合";
"异常检测Subagent" -> "主Agent整合";
"主Agent整合" -> "输出完整数据报告";
}
```
### 并行Subagent分析
在收集完数据后,并发派发4个Subagent:
**Subagent 1: 指标分析**
- 负责:计算核心指标、环比同比、目标达成率
**Subagent 2: 趋势分析**
- 负责:识别趋势变化、周期性规律、拐点判断
**Subagent 3: 用户反馈**
- 负责:整理用户反馈、情感分析、关键词提取
**Subagent 4: 异常检测**
- 负责:识别数据异常、根因分析、影响面评估
### V1 vs V2 对比
| 指标 | V1(顺序分析) | V2(并行分析) | 提升 |
|------|--------------|--------------|------|
| **分析时间** | ~5分钟 | ~2分钟 | 2.5x |
| **主Agent上下文** | ~10,000 tokens | ~3,000 tokens | 节省70% |
| **分析维度** | 基础指标展示 | 4维度综合审视 | - |
| **报告深度** | 表层数据罗列 | 深度洞察发现 | 更深入 |
---
## 注意事项
1. 数据口径需与团队对齐,避免口径不一致
2. 环比/同比计算需说明统计周期
3. 异常数据需标注原因(已知原因/待排查)
4. 用户反馈需区分情绪倾向(正面/负面/中性)
---
## 输出质量对比
**✅ Good 示例**:
```
- 有数据引用:「根据 Q4 数据,留存率从 35% 降至 28%」
- 有验证来源:「数据来源:Google Analytics, 2025-12-01」
- 有明确建议:「建议将新手引导步骤从 5 步减少至 3 步」
```
**❌ Bad 示例**:
```
- 模糊结论:「数据表明留存率有所下降」
- 无来源:「根据经验,这个功能很重要」
- 没有行动建议:「留存是个问题」
```
---
## 常见误区 / Red Flags — STOP
出现以下情况立即停止并回溯:
| 误区 | 正确做法 |
|------|---------|
| 使用"应该"、"大概"、"看起来"做结论 | 必须基于实际数据和验证 |
| 未运行检查就声称已完成 | 先验证,再陈述 |
| 因时间紧迫跳过关键步骤 | 没有例外,时间紧更要严格 |
| "这次应该没问题"的想法 | 每次都要重新验证 |
---
## 产出质量检查 / Verification Checklist
- [ ] 前置依赖已满足(输入文档/数据已收集)
- [ ] 核心步骤已全部执行
- [ ] 输出文档已生成到 `docs/` 目录
- [ ] 每个判断都有数据/证据支撑
- [ ] 已推荐 2-3 个后续 skill
> ⚠️ 任何一项未通过 → 补全后再标记完成。
---
No comments yet. Be the first to comment!