Aloudata CAN SKILLS - analysis-report
by @jackyujun
编排并生成完整的数据分析报告。当用户需要一份结构化的分析报告（而非单个指标查询或单点分析）时，必须使用此 Skill。本 Skill 是编排层——它不包含分析逻辑，而是知道"一份好报告该有什么内容"，按报告模板依次调度能力层 Skill（metric-query、anomaly-detection、metric-...
clawhub install analysis-report📖 About This Skill
name: analysis-report description: | 编排并生成完整的数据分析报告。当用户需要一份结构化的分析报告（而非单个指标查询或单点分析）时，必须使用此 Skill。本 Skill 是编排层——它不包含分析逻辑，而是知道"一份好报告该有什么内容"，按报告模板依次调度能力层 Skill（metric-query、anomaly-detection、metric-attribution、forecast-simulation）执行各板块分析，最后将结果串联为连贯的分析叙事。 触发场景包括但不限于：用户提到"出一份报告""月报""周报""分析报告""汇报""工作总结""经营分析""数据复盘""业绩回顾""出一份XX分析""帮我做个报告""总结一下上月情况""给老板看的报告""经营简报""数据报告"，或用户希望对某个业务领域做一次全面、系统的分析并输出文档时，都应使用此 Skill。 触发判定关键：用户想要的是一份完整的、多板块的分析文档，而非单个数据点查询或单项分析。区分方式： - "出一份月报""做个销售分析报告" → analysis-report（完整报告） - "上月销售额多少" → metric-query（单个数据查询） - "销售额有没有异常" → anomaly-detection（单项异常检测） - "以后每月都出月报" → scheduled-report（含"以后/每月"=定时意图） 与 scheduled-report 的区分：本 Skill 管"现在就出一份报告"（一次性执行）；scheduled-report 管"以后定期出"（录制+定时重放）。判断依据是用户表达中是否包含"定时/定期/每X/以后都"等重复执行意图。没有 → 本 Skill；有 → scheduled-report。 前提：本 Skill 不直接查数据或做分析，所有分析工作委派给能力层 Skill。它的核心价值是报告结构知识和叙事编排能力。
分析报告编排 Skill
执行模式
> 如果你不确定自己属于哪个类别，请按"标准模型"模式执行。
定位
本 Skill 是编排层，扮演"报告总编"的角色：
1. 知道一份好报告该有什么——不同类型报告的标准板块和组织结构 2. 调度能力层 Skill 执行分析——按报告结构依次调用 metric-query、anomaly-detection 等 3. 串联结果为连贯叙事——不是把数据表格堆砌在一起，而是形成有逻辑的分析故事
它不包含任何分析逻辑——不自己查数据、不自己判异常、不自己做归因。
整体流程
┌─────────────────────────────────────────────────────────────────┐
│ 报告生成流程 │
│ │
│ Step 1 理解需求：什么类型的报告？覆盖什么范围？ │
│ ↓ │
│ Step 2 确定报告结构：选择/生成报告模板 │
│ ↓ │
│ Step 3 逐板块执行分析：调度能力层 Skill │
│ ↓ │
│ Step 4 串联叙事，输出报告 │
│ │
└─────────────────────────────────────────────────────────────────┘
Step 1：理解需求
1.1 确定报告类型
从用户的表达中提取：
| 提取项 | 说明 | 示例 | |-------|------|------| | 报告主题 | 分析什么业务领域 | 销售、库存、会员、运营 | | 报告周期 | 分析什么时间范围 | 上月、上周、上季度、本年至今 | | 受众 | 报告给谁看 | 老板（要结论和建议）、团队（要细节）、自己（要数据） | | 深度 | 全面概览还是深入分析 | 简报（核心KPI一页纸）vs 深度分析（含归因） |
1.2 模糊需求处理
用户只说了领域（"出一份销售报告"）： → 默认上月，标准深度，通过 metric-query 搜索该领域核心指标
委派 metric-query 搜索指标：关键词="销售"，返回数量=20
用户完全模糊（"出一份报告"）： → 询问报告主题和时间范围
用户指定了受众（"给老板看的月报"）： → 调整报告风格：结论前置、减少技术细节、突出行动建议
Step 2：确定报告结构
根据报告类型选择对应的模板。模板定义了报告的板块组成和每个板块应调用哪个能力层 Skill。
2.1 通用报告模板
适用于大多数业务分析报告，可根据具体需求增减板块：
一、核心指标概览
- 本期核心 KPI 一览表（值 + 环比/同比变化）
- 调用：metric-query二、趋势分析
- 核心指标的时间趋势（按月/按周展开）
- 调用：metric-query（dimensions 含时间维度）
三、异常扫描
- 哪些指标/维度出现了异常波动
- 调用：anomaly-detection
四、异常归因（如有异常）
- 对检测到的异常做根因分析
- 调用：metric-attribution
五、维度拆解
- 按关键维度（渠道/品牌/地区）拆分看各自表现
- 调用：metric-query + 排名/占比
六、目标达成（如有目标）
- 目标完成情况 + 预测能否达标
- 调用：forecast-simulation
七、关键发现与建议
- 基于以上分析的结论和行动建议
- 由本 Skill 汇总各板块发现，生成叙事
2.2 板块裁剪规则
不是每份报告都需要全部板块：
| 条件 | 处理 | |------|------| | 用户要"简报" | 只保留板块一 + 板块七 | | anomaly-detection 未发现异常 | 跳过板块四（归因） | | 用户没提目标 | 跳过板块六（目标达成） | | 用户指定了特定维度 | 板块五只做该维度 | | 报告周期是日报 | 简化板块二（趋势），聚焦板块三（异常） |
2.3 向用户确认结构
展示报告大纲，让用户确认：
📋 报告大纲：一、核心指标概览（销售额、客单价、转化率、订单数 + 环比同比）
二、月度趋势（近6个月走势）
三、异常扫描（检测各指标是否偏离正常范围）
四、异常归因（如发现异常，分析原因）
五、渠道拆解（各渠道表现 + TOP/BOTTOM 排名）
六、关键发现与建议
这个结构可以吗？需要增减什么板块？
板块间上下文传递（标准模型必做）
编排多个分析板块时，每个板块完成后将关键发现写入 report_context，确保后续板块能引用前面的结论。
# 初始化上下文（在第一个板块开始前执行）
report_context = {
"report_title": "", # 报告标题
"time_range": "", # 分析时间范围
"kpi_summary": {}, # 板块一：核心 KPI 摘要
"trend_findings": [], # 板块二：趋势发现
"anomalies": [], # 板块三：异常检测结果
"attribution_findings": [], # 板块四：归因发现
"key_conclusions": [], # 最终结论汇总
}===== 板块一完成后 =====
report_context["kpi_summary"] = {
"metrics": [
{"name": "销售金额", "value": 12345678, "change": -0.08, "direction": "下降"},
{"name": "客单价", "value": 680, "change": 0.03, "direction": "上升"},
],
"overall_assessment": "销售额下滑但客单价提升，量跌价升"
}===== 板块三完成后 =====
report_context["anomalies"] = [
{"metric": "retail_amt", "dimension": "first_channel", "value": "Retail",
"severity": "🔴", "detail": "Retail 渠道销售额环比下跌 18%"},
]===== 板块四开始时（必须先读取 anomalies） =====
if report_context["anomalies"]:
for anomaly in report_context["anomalies"]:
print(f"归因目标：{anomaly['metric']} 在 {anomaly['value']} 的异常（{anomaly['severity']}）")
# 对该异常调用 metric-attribution 能力
else:
print("无异常，跳过归因板块")===== 板块六（结论）开始时 =====
汇总所有板块发现
for finding in report_context["trend_findings"]:
report_context["key_conclusions"].append(finding)
for finding in report_context["attribution_findings"]:
report_context["key_conclusions"].append(finding)
print(f"最终结论数量：{len(report_context['key_conclusions'])}")
标准模型执行原则：
Step 3：逐板块执行分析
按确认后的报告结构，依次调度能力层 Skill 执行各板块。
3.1 执行顺序
严格按模板的板块顺序执行，因为后面的板块可能依赖前面的结果：
3.2 各板块的调用方式
板块一：核心指标概览 → 调用 metric-query：查核心 KPI 及环比/同比 → 所需信息：指标列表、时间范围、对比基准
板块二：趋势分析 → 调用 metric-query：dimensions 含时间维度，拉近 N 期数据 → 所需信息：指标列表、时间粒度、时间范围
板块三：异常扫描 → 调用 anomaly-detection：对板块一中的指标做异常检测 → 所需信息：指标列表、检测维度、基线类型
板块四：异常归因 → 调用 metric-attribution：对板块三发现的异常指标做归因 → 前置条件：板块三发现了异常 → 所需信息：异常指标、对比基准、归因维度
板块五：维度拆解 → 调用 metric-query：按维度分组查询 + 占比/排名 → 所需信息：指标、维度、排名方式
板块六：目标达成 → 调用 forecast-simulation：目标缺口分析 + 趋势预测 → 前置条件：用户提供了目标值 → 所需信息：目标值、当前累计值、剩余时间
3.3 执行原则
逐板块向用户展示中间结果：不要等全部做完再一次性输出。每完成一个板块就展示该板块的结果，让用户可以随时调整方向。
灵活应对：如果某个板块的分析发现了用户可能关心的新角度，可以在展示时提议增加分析内容。
板块间传递上下文：后面的板块应引用前面板块的发现。例如板块四归因时说"在板块三中我们发现 Retail 渠道销售额异常下跌，下面分析原因..."。
Step 4：串联叙事，输出报告
4.1 叙事编排原则
先结论后细节：报告开头用 2-3 句话概括全篇核心发现，然后再展开各板块细节。
数据+洞察，不只是数字：每个板块不只是表格，还要有一句解读。不是"Retail 渠道环比 -18%"，而是"Retail 渠道环比下跌 18%，是所有渠道中跌幅最大的，需要重点关注"。
板块间有过渡：不是孤立的数据块拼接，而是有逻辑链的叙事。"核心指标中，销售额环比下降 8%（板块一）。从趋势看，这已经是连续第二个月下滑（板块二）。异常检测显示 Retail 渠道是主要拖累（板块三）。归因发现..."
结论要有行动指向：最后的"关键发现与建议"不能只是复述数据，要给出可执行的建议。
4.2 输出格式
默认输出 Markdown 格式。报告结构：
# {报告名称} — {时间范围}> 核心摘要：{2-3 句话概括全篇最重要的发现}
一、核心指标概览
{KPI 表格 + 简要解读}
二、趋势分析
{趋势描述 + 变化拐点标注}
三、异常扫描
{异常/正常的结构化结果}
四、异常归因
{针对异常指标的根因分析}
五、{维度}拆解
{TOP/BOTTOM 排名 + 占比分析}
六、关键发现与建议
{总结发现 + 可执行的行动建议}
如果用户需要其他格式（docx / pptx / xlsx），在 Markdown 生成后调用对应的文档 Skill 转换。
注意事项
与能力层 Skill 的边界
本 Skill 是"总编"，不是"记者"。它决定报告需要什么内容，但每个内容板块的具体分析工作都交给对应的能力层 Skill。
与 scheduled-report 的边界
典型连续使用场景：用户先用本 Skill 出了一份月报 → 觉得不错 → 说"以后每月都这么出" → scheduled-report 接手，把本次 analysis-report 的过程录制为 cron 任务。
不要过度分析
用户要的是"报告"，不是"论文"。每个板块点到为止，不需要把每个维度都穷尽分析。重点突出，篇幅适中。如果用户需要对某个板块深入，可以单独触发对应的能力层 Skill。
常见错误模式
❌ 自己做分析而不委派：在报告中直接构建 metric-query 的请求体查数据。应该通过调用 metric-query Skill 的流程来获取数据。
❌ 报告只有数据没有洞察：每个板块只放了表格，没有解读。用户要的是分析报告，不是数据导出。
❌ 板块之间孤立无关联：板块三发现了异常，板块四的归因却没有引用。各板块之间应有明确的逻辑衔接。
❌ 不确认结构就开始做：直接按默认模板全量执行。用户可能只想要一份简报，不需要完整的 7 个板块。
❌ 结论没有行动指向："销售额下降 8%"不是结论，"Retail 渠道销售额连续两月下滑，建议排查该渠道近期的运营策略变化"才是结论。
❌ 触发词混淆，误触发 scheduled-report：用户说"出一份月报"（一次性）被当成"定时月报"处理。注意区分"出/生成/做"（一次性）和"每月/定期/定时"（重复执行）。