编排并生成完整的数据分析报告。适用于需要结构化报告的场景,负责协调调用底层技能(如指标查询、异常检测等),不执行具体分析逻辑。
分析报告编排 Skill
功能概述
分析报告编排 Skill是一项面向实际任务的技能,主要用于强模型 (Claude Opus/Sonnet, GPT-4o/5):遵循"原则"段落,自行决定实现细节;标准模型 (Qwen, DeepSeek, Llama):严格按"模板"段落执行,使用提供的代码块,不要自行改写;
核心要点
- 如果你不确定自己属于哪个类别,请按"标准模型"模式执行;
- 本 Skill 是 编排层 ,扮演"报告总编"的角色:;
- 知道一份好报告该有什么。
使用与执行
它将相关步骤、工具调用和结果整理方式集中到统一流程中,帮助使用者更快完成目标并减少重复操作。从功能定位来看,该技能强调把分散的操作要求整理成清晰、可复用的处理流程,使用户能够围绕既定目标快速准备输入、选择执行方式并获得结构化结果。实际使用前应先确认任务范围、数据来源、运行环境、必要权限和关键参数,再依据技能说明逐步执行;若输入条件不完整,应先补齐信息或采用保守配置,避免因错误假设导致结果偏离需求。
结果检查与注意事项
执行过程中需要关注工具调用是否成功、接口或依赖是否可用、输出格式是否符合预期,并对异常提示、缺失字段和边界情况进行处理;涉及批量任务时,还应保存进度,避免中断后重复操作。该技能适合用于一次性任务,也可以接入自动化工作流,与其他技能或上层代理配合完成更完整的业务链路;在组合使用时,应明确每一步的输入输出关系,并避免不同步骤之间出现参数冲突。
分析报告编排 Skill
执行模式
- 强模型(Claude Opus/Sonnet, GPT-4o/5):遵循"原则"段落,自行决定实现细节
- 标准模型(Qwen, DeepSeek, Llama):严格按"模板"段落执行,使用提供的代码块,不要自行改写
如果你不确定自己属于哪个类别,请按"标准模型"模式执行。
定位
本 Skill 是编排层,扮演"报告总编"的角色:
- 知道一份好报告该有什么——不同类型报告的标准板块和组织结构
- 调度能力层 Skill 执行分析——按报告结构依次调用 metric-query、anomaly-detection 等
- 串联结果为连贯叙事——不是把数据表格堆砌在一起,而是形成有逻辑的分析故事
它不包含任何分析逻辑——不自己查数据、不自己判异常、不自己做归因。
整体流程
┌─────────────────────────────────────────────────────────────────┐ │ 报告生成流程 │ │ │ │ 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'])}")
标准模型执行原则:
- 每个板块完成后,立即更新 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 格式。报告结构:
# {报告名称} — {时间范围}
> **核心摘要**:{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:用户说"出一份月报"(一次性)被当成"定时月报"处理。注意区分"出/生成/做"(一次性)和"每月/定期/定时"(重复执行)。
热门AI工具
相关专题
本专题聚焦Go-Zero的API开发,拆解.api描述文件的语法结构、路由与分组定义、参数绑定与校验规则,说明统一响应体、JWT鉴权、跨域与接口文档生成的落地方式,并给出网关聚合与接口测试的实践建议。
0
2026.11.12
本专题围绕Go-Zero的安装与工具链配置展开,讲清Go版本要求、goctl安装方式、代理镜像、protoc依赖与环境变量设置,说明多版本共存、升级回退与CI流水线安装的做法,并整理安装阶段的常见报错与验证步骤。
0
2026.11.12
本专题整理Go-Zero的入门知识,从框架定位、环境准备到跑通第一个API服务,讲清目录分层、配置加载、日志与中间件的基本用法,并对比Gin、Kratos的差异,帮助Go开发者建立整体认知,判断它是否适合当前项目。
0
2026.11.12
本专题从实际API接口调试场景出发,讲解Postman身份认证的完整配置流程,包括常见认证协议介绍、授权参数设置、访问令牌填写、OAuth 2.0授权及认证失败排查,帮助用户正确完成接口授权与访问验证。
0
2026.11.06
围绕Postman HTTP请求头配置展开,讲解Headers选项的具体使用方式,包括Key和Value参数填写、请求头信息添加、常见Header字段设置及请求头修改方法,帮助用户解决接口调试过程中遇到的请求头配置问题。
0
2026.11.06
详细介绍Postman接口请求的创建与发送方法,涵盖GET和POST请求、URL配置、请求参数、Headers请求头、Body请求体设置以及响应结果查看,帮助用户掌握Postman接口请求的完整操作流程。
0
2026.11.06
DBeaver数据导入专题,整理Excel、CSV、SQL、TXT等常见文件的数据导入方法,涵盖目标数据库选择、数据表创建、字段映射、数据类型设置及导入参数配置等操作,帮助用户将本地文件中的数据写入数据库,并了解批量导入、重复数据处理和导入失败等常见问题的解决方法。
0
2026.11.05
DBeaver安全防护专题,围绕数据库连接安全、账号密码保护和访问权限管理展开,整理SSL/TLS加密连接、SSH隧道、数据库凭据保存及证书验证等配置方法,同时介绍敏感信息保护、远程连接风险和高权限账号使用等注意事项,帮助用户提高数据库日常管理的安全性。
0
2026.11.05
本专题聚焦DBeaver数据库连接配置与管理,覆盖从新建连接、选择数据库类型到填写连接参数和验证连接的完整流程。针对MySQL、PostgreSQL、SQL Server等常见数据库,整理相应的连接设置方法,并提供驱动缺失、认证失败和连接异常等问题的排查方向。
0
2026.11.04
热门下载
相关下载
最新文章