Aloudata CAN SKILLS - analysis-report

编排并生成完整的数据分析报告。当用户需要一份结构化的分析报告（而非单个指标查询或单点分析）时，必须使用此 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

执行模式

• 强模型（Claude Opus/Sonnet, GPT-4o/5）：遵循"原则"段落，自行决定实现细节
• 标准模型（Qwen, DeepSeek, Llama）：严格按"模板"段落执行，使用提供的代码块，不要自行改写

如果你不确定自己属于哪个类别，请按"标准模型"模式执行。

定位

本 Skill 是编排层，扮演"报告总编"的角色：

1. 知道一份好报告该有什么——不同类型报告的标准板块和组织结构
2. 调度能力层 Skill 执行分析——按报告结构依次调用 metric-query、anomaly-detection 等
3. 串联结果为连贯叙事——不是把数据表格堆砌在一起，而是形成有逻辑的分析故事

它不包含任何分析逻辑——不自己查数据、不自己判异常、不自己做归因。

---

整体流程

text

┌─────────────────────────────────────────────────────────────────┐
│                     报告生成流程                                  │
│                                                                 │
│  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 通用报告模板

适用于大多数业务分析报告，可根据具体需求增减板块：

text

一、核心指标概览
   - 本期核心 KPI 一览表（值 + 环比/同比变化）
   - 调用：metric-query

二、趋势分析
   - 核心指标的时间趋势（按月/按周展开）
   - 调用：metric-query（dimensions 含时间维度）

三、异常扫描
   - 哪些指标/维度出现了异常波动
   - 调用：anomaly-detection

四、异常归因（如有异常）
   - 对检测到的异常做根因分析
   - 调用：metric-attribution

五、维度拆解
   - 按关键维度（渠道/品牌/地区）拆分看各自表现
   - 调用：metric-query + 排名/占比

六、目标达成（如有目标）
   - 目标完成情况 + 预测能否达标
   - 调用：forecast-simulation

七、关键发现与建议
   - 基于以上分析的结论和行动建议
   - 由本 Skill 汇总各板块发现，生成叙事

2.2 板块裁剪规则

不是每份报告都需要全部板块：

条件	处理
用户要"简报"	只保留板块一 + 板块七
anomaly-detection 未发现异常	跳过板块四（归因）
用户没提目标	跳过板块六（目标达成）
用户指定了特定维度	板块五只做该维度
报告周期是日报	简化板块二（趋势），聚焦板块三（异常）

2.3 向用户确认结构

展示报告大纲，让用户确认：

text

📋 报告大纲：

一、核心指标概览（销售额、客单价、转化率、订单数 + 环比同比）
二、月度趋势（近6个月走势）
三、异常扫描（检测各指标是否偏离正常范围）
四、异常归因（如发现异常，分析原因）
五、渠道拆解（各渠道表现 + TOP/BOTTOM 排名）
六、关键发现与建议

这个结构可以吗？需要增减什么板块？

---

板块间上下文传递（标准模型必做）

编排多个分析板块时，每个板块完成后将关键发现写入 report_context，确保后续板块能引用前面的结论。

python

# 初始化上下文（在第一个板块开始前执行）
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'])}")

标准模型执行原则：

• 每个板块完成后，立即更新 report_context
• 下一个板块开始前，先读取 report_context 中相关字段
• 板块六（结论）必须引用前面板块的具体数据，不可凭记忆编造

---

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 格式。报告结构：

markdown

# {报告名称} — {时间范围}

> **核心摘要**：{2-3 句话概括全篇最重要的发现}

## 一、核心指标概览

{KPI 表格 + 简要解读}

## 二、趋势分析

{趋势描述 + 变化拐点标注}

## 三、异常扫描

{异常/正常的结构化结果}

## 四、异常归因

{针对异常指标的根因分析}

## 五、{维度}拆解

{TOP/BOTTOM 排名 + 占比分析}

## 六、关键发现与建议

{总结发现 + 可执行的行动建议}

如果用户需要其他格式（docx / pptx / xlsx），在 Markdown 生成后调用对应的文档 Skill 转换。

---

注意事项

与能力层 Skill 的边界

本 Skill 是"总编"，不是"记者"。它决定报告需要什么内容，但每个内容板块的具体分析工作都交给对应的能力层 Skill。

• 需要查数据 → 委派给 metric-query
• 需要判断异常 → 委派给 anomaly-detection
• 需要解释原因 → 委派给 metric-attribution
• 需要预测推演 → 委派给 forecast-simulation

与 scheduled-report 的边界

• 本 Skill："现在就出一份报告"（一次性）
• scheduled-report："把这个过程录下来，以后定时出"（定时重放）

典型连续使用场景：用户先用本 Skill 出了一份月报 → 觉得不错 → 说"以后每月都这么出" → scheduled-report 接手，把本次 analysis-report 的过程录制为 cron 任务。

不要过度分析

用户要的是"报告"，不是"论文"。每个板块点到为止，不需要把每个维度都穷尽分析。重点突出，篇幅适中。如果用户需要对某个板块深入，可以单独触发对应的能力层 Skill。

---

常见错误模式

❌ 自己做分析而不委派：在报告中直接构建 metric-query 的请求体查数据。应该通过调用 metric-query Skill 的流程来获取数据。

❌ 报告只有数据没有洞察：每个板块只放了表格，没有解读。用户要的是分析报告，不是数据导出。

❌ 板块之间孤立无关联：板块三发现了异常，板块四的归因却没有引用。各板块之间应有明确的逻辑衔接。

❌ 不确认结构就开始做：直接按默认模板全量执行。用户可能只想要一份简报，不需要完整的 7 个板块。

❌ 结论没有行动指向："销售额下降 8%"不是结论，"Retail 渠道销售额连续两月下滑，建议排查该渠道近期的运营策略变化"才是结论。

❌ 触发词混淆，误触发 scheduled-report：用户说"出一份月报"（一次性）被当成"定时月报"处理。注意区分"出/生成/做"（一次性）和"每月/定期/定时"（重复执行）。