Data Analysis Dashboard
核心红线 (不可逾越)
所有分析结论、看板数据、文字报告必须严格基于用户提供的实际数据,禁止编造、推测、填充、美化数据。
- 没有数据支撑时,写「数据不足,无法判断」而非给出一个看似合理的数字。
- 图表中的每个数字、每个标签、每个 KPI 值必须来自真实计算结果。
- 若数据有局限(如缺少时间维度、缺少用户标识),明确说明局限,不夸大结论适用范围。
- 发现异常值时,先判断是真实业务信号还是脏数据,不确定时写「疑似异常,需进一步核实」而非强行解释。
- 看板必须离线可渲染:Chart.js 只能本地引用
./chart.umd.min.js,绝不可回退到外网 CDN(你当前网络连不上 cdn.jsdelivr.net 等,一旦回退图表就会全空白)。
Overview
本技能将「拿到数据 → 分析 → 出报告」固化为标准流程:先做数据质量体检,再给出优势与劣势分析,最后产出可直接打开的 HTML 数据看板,并附上文字版分析结论。
可用看板模板
模板存放在 assets/templates/ 目录下,共 7 种风格。选择模板时根据数据场景和展示对象决定:
| 模板(中文名) | 模板文件 | 风格 | 适用场景 | 主色调 |
|--------------|----------|------|---------|--------|
| 深色科技风 | dark-tech.html | 深色科技风 | 大屏展示、监控看板、工业/IoT 数据 | 黑底 + 青色/蓝色高亮 |
| 深蓝商务风 | dark-blue.html | 深蓝商务风 | 金融数据、银行/保险报表、高级感深色 | 深蓝底 + 蓝金高亮 |
| 深紫科技风 | dark-purple.html | 深紫科技风 | 高端数据展示、科技感强烈、数据量大 | 深紫黑底 + 紫粉高亮 |
| 浅色商务风 | light-business.html | 浅色商务风 | 通用商业分析、领导汇报、销售运营 | 白底 + 蓝紫主色 |
| 白色综合经营风 | light-comprehensive.html | 白色综合经营风 | 综合经营回顾、多维度 KPI、财务分析 | 白底 + 紫粉主色 |
| 浅色清新风 | light-fresh.html | 浅色清新风 | 运营/流量/用户数据、移动端友好 | 白底 + 青绿主色 |
| 极简报告风 | light-minimal.html | 极简报告风 | 打印/PPT 嵌入、学术/审计报告、简洁 | 纯白 + 单色线条 |
重要:向用户展示和提问时一律用中文名(如「浅色商务风」),不要用英文文件名。
选择策略:
- 展示场景偏「大屏/监控/实时」→ 选深色科技风 / 深紫科技风
- 展示场景偏「汇报/PPT/打印」→ 选浅色商务风 / 极简报告风
- 数据类型偏「金融/交易」→ 选深蓝商务风,并遵循「涨红跌绿」
- 数据类型偏「运营/用户」→ 选浅色清新风
- 综合经营分析 → 选白色综合经营风
工作流
Step 1: 定位并读取数据
- 确认用户传入的数据文件路径(支持 CSV / Excel / JSON)或直接粘贴的数据内容。
- 用 Python 读取并确认可读性;若路径缺失,向用户索取,不要凭空假设。
- 记录基本盘:行列数、字段名、每列类型。
- 红线检查:所有后续结论的原始数据必须来自此文件,严禁编造。
Step 2: 选择看板模板(选项用中文)
- 向用户展示可用模板列表时,一律用中文名(深色科技风 / 深蓝商务风 / 深紫科技风 / 浅色商务风 / 白色综合经营风 / 浅色清新风 / 极简报告风),用表格列出「中文名 + 适用场景」,不要只给英文文件名。
- 使用 AskUserQuestion 让用户选择,选项 label 必须用中文。最多给 4 个常用选项(如「浅色商务风(推荐)」「白色综合经营风」「深蓝商务风」「深色科技风」),其余模板用户在自由输入框直接输入中文名(如「深紫科技风」「极简报告风」)即可。
- 可给出推荐:如「这份数据是销售运营类,推荐浅色商务风或白色综合经营风」。
- 若用户未指定或未明确选择,默认使用
light-business.html(浅色商务风)。 - 记录用户选择的模板(中文名 + 对应模板文件路径),后续 Step 6 使用此模板生成看板。
Step 3: 运行数据体检脚本
-
需要客观统计数据支撑时,运行
scripts/analyze_data.py做快速体检:python scripts/analyze_data.py <数据文件路径> --output <输出json路径> -
脚本输出每列的缺失值、唯一值、描述性统计、IQR 异常值,以及整体重复行。
-
将脚本输出转化为自然语言结论,不要原样罗列 JSON。
-
红线检查:体检报告中的每个数字必须来自脚本输出,不可目测估算或编造。
Step 4: 数据质量检查
对照 references/analysis_framework.md 的检查清单逐项核对,重点排查:
- 缺失与空值(是否集中、是否有关联规律)
- 重复记录(完全重复 / 关键字段重复)
- 异常值(IQR 或业务规则判断,区分「脏数据」与「真实业务信号」)
- 类型错乱与格式不一致(如日期混格式、数值带单位、文本带前后空格)
- 量纲不统一(元/万元、kg/吨)
- 时间连续性(缺口、乱序、时区问题)
红线: 每个质量问题必须指明具体字段、具体现象、数据证据(如「订单金额列有 3 个负值: -50, -120, -30」)。不写模糊表述如「有些异常」。
Step 5: 优势与劣势分析
- 优势:从完整性、粒度、时效性、覆盖度、规范性、一致性、字段丰富度等维度找亮点。
- 劣势:指出不足,并说明其对下游分析或决策的具体影响,再给可执行改进建议。
- 红线: 每个结论都要有数据依据(引用具体列名与数值),不写空话。不确定时写「数据不足,无法判断」。
Step 6: 产出 HTML 看板
- 以用户选择的模板文件(Step 2 中确定)为骨架,生成 HTML 看板(图表库用 Chart.js,必须本地引入,禁止任何外网 CDN)。
- 图表库本地化(强制,防止图表空白): 模板里的
<script src="./chart.umd.min.js"></script>引用的是同目录本地文件。生成看板时,必须把技能自带的库文件复制到看板 HTML 所在的同一目录:copy <skill目录>/assets/vendor/chart.umd.min.js <输出目录>/chart.umd.min.js- 复制后再保存
dashboard.html,确保两者在同一文件夹。用户打开看板时图表才能渲染,不依赖任何网络。 - 严禁把模板里的本地引用改回
https://cdn...等外网地址——你当前网络连不上外网 CDN,会导致 Chart 未定义、图表全空白。
- 复制后再保存
- 看板必须包含:标题栏、KPI 概览卡片、2–4 个核心图表、发现与建议区。
- 将模板中的
{{占位符}}替换为真实数据和文字结论。 - 红线检查: 看板中每一个数字、每一条标签、每一个百分比都必须来自真实数据的精确计算,严禁为了「好看」而调整或编造数据。图表数据必须与文字结论完全一致。
- 金融/股票数据遵循「涨红跌绿」配色惯例。
- 图表选型:时间趋势→折线图,占比→环形图,分类对比→柱状图,分布→直方图。
- 数字保留合理精度,KPI 卡片标注口径(如「近 30 天」「同比」)。
- 保存为
<输出目录>/dashboard.html,并用 present_files 呈现给用户。注意:移动或分享看板时,必须连chart.umd.min.js一起带走。
Step 7: 生成后全量质检(每次必做,不可跳过)
看板 HTML 生成后、呈现给用户前,必须先运行自动化质检脚本,并对结果逐项人工复核。四项检查缺一不可:
-
数据计算正确性
- 运行质检脚本(传入原始数据 + 看板 HTML + 本轮的体检报告/深度分析 JSON 作为参考):
python scripts/verify_dashboard.py <原始数据文件> <看板HTML> --ref <体检报告.json> --ref <深度分析.json> - 脚本会从原始数据重算权威数字,并与看板中出现的每个数字交叉核对(自动识别万元/亿/百分比换算)。
- 脚本输出的未匹配数字必须逐个人工复核:确认是真实数据换算(如 1.89 亿=189,181,440 元、11.96%=0.1196)或图表样式配置(如 pointRadius: 3)才可通过;凡是 KPI、图表数据、发现建议中的数字未匹配,一律修正后重新质检。
- 禁止用任何「目测」「心算」「感觉对」代替核对。
- 运行质检脚本(传入原始数据 + 看板 HTML + 本轮的体检报告/深度分析 JSON 作为参考):
-
文字无乱码无异常(含图表文字)
- 检查脚本输出:mojibake 乱码数、异常符号数、占位符残留数必须为 0;图表专项检查中,每个图表的 labels、图例 label 同样不得含乱码。
- 人工抽查:标题、KPI 标签、图表标题、图例、发现与建议区无乱码方框、无「�」替换符、无 mojibake(如 é)、无模板占位符
{{...}}残留。 - 全部文本统一 UTF-8 编码,中英文与数字之间排版正常。
-
图表正确生成 + 图表数据真实(新增图表专项检查)
- 脚本自动检查每张图表:
- 完整性:
<canvas>数量必须等于new Chart实例数量且 id 一一对应;每个图表type合法(line/bar/pie/doughnut 等)、labels非空、数据集data非空(否则图表画不出来)。 - 图表文字乱码: 检测每个图表的 labels、图例 label 是否含乱码/异常字符。
- 图表数据真实性: 提取每个数据集
data的数字,与权威数字集交叉核对,确保图表画出来的数字来自真实计算、与文字结论一致。
- 完整性:
- 脚本输出
canvas 数量 / Chart 实例 / 完整性 / 每图 type·labels·数据点 / 图表文字乱码 / 图表数据匹配数,逐项确认。 - 任一图表缺失、类型非法、数据为空、文字乱码、或图表数据与权威数字对不上 → 视为硬错误,修正后重跑质检。
- 脚本自动检查每张图表:
-
建议与发现准确无误
- 逐条核对「发现与建议」:每条结论必须能引用具体字段与真实数字作为证据,数字与看板图表一致。
- 无数据证据的表述一律删除或改写为「数据不足,无法判断」。
- 严禁为了凑条数、凑 Top3 而编造或夸大结论。
质检结论处理:
- 脚本硬错误(乱码/异常符号/占位符残留/图表未正确生成/图表文字乱码)> 0 → 修正看板 → 重跑质检,直到为 0。
- 未匹配数字(含图表数据):逐个人工确认后,在交付说明中注明「已复核」;发现错误数字 → 修正 → 重跑质检。
- 只有质检通过(硬错误为 0 且未匹配数字全部复核无误)后,才允许进入 Step 8 呈现看板。
- 用户提出修改意见、生成第二版后,同样必须重跑一次质检。
Step 8: 首版看板意见征询(只问一次)
- 呈现首版看板后,必须向用户征询一次修改意见,提问格式: 「看板已生成,是否需要修改?不需要修改请回复『否』;需要修改请直接告诉我改哪里,例如:去掉标题下面的小字、第一张图配色改成紫色、第六张图改成双折线图等。」
- 用户回复「否」「不用」「可以」「OK」等否定或确认表达 → 直接进入 Step 9 交付文字结论。
- 用户回复具体修改意见 → 严格按意见修改看板(如调整配色、更换图表类型、删除元素、调整布局、改标题文字),修改后重跑 Step 7 质检,再生成第二版并重新用 present_files 呈现;修改完成后不再二次征询,直接进入 Step 9。
- 修改看板时红线不变:允许改的是样式、图表类型、布局、文案措辞;数据与数字绝不可编造或改动,图表数据必须与 Step 3–5 的分析结果保持一致。
Step 9: 交付文字结论
在最终回复中总结(交付前同样确认文字无乱码、数字与看板一致):
- 数据问题 Top 3
- 优势 Top 3
- 劣势 Top 3(含影响与建议)
- 看板包含哪些内容、下一步可以做什么分析
- 附一句质检结论:「已通过生成后全量质检(数字核对/乱码检查/发现准确性)」
红线: 文字结论中的每个数字必须与看板中完全一致。若某条结论无法从现有数据得出,写「数据不足,无法判断」或「建议补充 XX 数据后验证」。
注意事项
- 大文件先抽样描述,避免长时间运行或内存溢出。
- 发现异常值先判断是真实信号还是脏数据,不要机械标注。
- 分析结论与图表口径一致,避免「文字说 A、图表画 B」。
- 用户只给了部分数据时,明确说明结论的适用范围,不夸大。
- 严禁在分析或看板中编造任何数据、推测未提供的指标、或美化数据以迎合预期。
Scan to join WeChat group