creating-dashboards（创建仪表板）Skill 是什么？如何下载？

创建仪表板Skill：把 KPI、图表、过滤器组装成一块能实时更新的数据指挥中心

一句话定位：这是一个专门用于构建「综合性数据分析界面」的 AI 技能，把 KPI 卡片、图表、表格、过滤器、实时更新和响应式布局组合成统一的仪表板体验。
解决的核心问题：仪表板难点不在单个图表，而在于布局协调、过滤器联动、数据流与性能。这个技能把这些经验固化成可复用的模式与脚本。
两条技术路线：追求「快速出成果」用 Tremor，追求「用户可拖拽自定义」用 react-grid-layout，也可两者结合。
附带可执行资源：包含布局生成、KPI 指标计算、配置校验、性能分析、导出等 Python 脚本，以及模板、组件目录、主题令牌等资产。
适合人群：前端工程师、数据分析师、独立开发者，以及需要快速交付内部 BI / 监控看板的团队。

该技能叫什么？如何下载安装 AI 技能提升开发效率？

技能中文名：创建仪表板Skill 技能英文名：creating-dashboards 技能ID：13437

这个技能要解决的问题很具体：当你要做一个「数据看板」时，真正耗时的往往不是画一张折线图，而是这些琐碎又容易出错的事情——多个 KPI 卡片的数字格式和同比趋势怎么统一、顶部改了日期范围为什么下面的图表没跟着变、实时刷新怎么做到既及时又不把浏览器卡死、用户想自己拖动小部件位置该怎么持久化。创建仪表板Skill 把这些环节拆成「架构选择 → 全局状态 → 数据获取 → 实时更新 → 响应式 → 性能优化 → 主题统一」的固定工作流，并给出可直接参考的代码结构与配套脚本，让 AI 助手在生成仪表板时按成熟套路走，而不是每次从零拼装。

一键安装的思路与步骤

确认安装前提：你需要一个支持「技能（Skill）」机制的 AI 编程助手或智能体环境，并具备 Node.js / npm 与 Python 运行环境（技能内置脚本以 Python 编写，示例以 React + TypeScript 为主）。具体支持的宿主环境与版本要求，以官方说明为准。
找到技能入口：在所用平台的技能市场、技能库或插件中心搜索技能名称「创建仪表板」或英文名 creating-dashboards，也可以按技能ID 13437 定位。各平台的检索入口与字段命名不同，以官方说明为准。
执行安装 / 启用：按平台提示完成添加与启用操作。若平台支持命令行安装，请以平台文档给出的命令为准，不要照搬非官方来源的指令。
安装项目侧依赖（按需）：技能本身不强制绑定某个库，但它的示例会用到 Tremor 或 react-grid-layout，仍以官方说明为准：

# 快速分析型仪表板：预置 KPI 卡片、图表、表格
npm install @tremor/react

# 可定制型仪表板：拖放、可调整大小的小部件
npm install react-grid-layout

验证是否生效：向助手提出一个明确的触发式请求，例如「帮我用 Tremor 搭一个包含 4 个 KPI 卡片和 1 个收入趋势面积图的销售仪表板，并加上日期范围过滤器」。若技能已正确加载，回答应体现它特有的套路：先确认「固定布局还是可定制布局」，再给出全局过滤器上下文、KPI 卡片结构（标签 + 大数字 + 趋势徽标 + 迷你图）、响应式断点与性能策略，而不是只丢一段孤立的图表代码。你也可以直接运行一个内置脚本作为二次验证：

python scripts/validate-widget-config.py --help

该技能的主要功能和特点

KPI 卡片标准化：定义了 KPI 卡片的完整结构——带时间段的标签、大数字主指标、带比较的趋势指示器（如「↑ 15.3% 对比上月」）、迷你可视化，避免每个卡片各写一套。
小部件容器规范：标题栏（名称 + 操作）、加载态（骨架屏或旋转器）、带重试的错误边界、调整手柄、设置菜单（导出 / 配置 / 刷新），让每个小组件都具备生产级的边界处理。
三种布局范式：固定布局（设计者定义、跨用户一致）、可定制网格（用户拖放、可调整大小、布局可保存）、基于模板（预置模式、行业起点），可按业务选择。
全局控制体系：日期范围选择器统一影响所有小部件、过滤器面板跨小部件协调、手动 / 自动刷新、导出（PDF、图像、数据）、浅色 / 深色主题切换。
过滤器上下文机制：通过 DashboardContext 之类的共享状态，把过滤条件从「每个组件各管各的」变成「一处修改、全局响应」。
实时更新三套方案：SSE（推荐用于服务端到仪表板的单向推送）、WebSocket（需要双向交互时）、智能轮询回退（环境不支持前两者时，且标签页不可见自动暂停）。
性能优化成体系：懒加载（先渲染可见小部件）、并行数据获取（Promise.all 同时拉取 KPI / 图表 / 表格）、小部件级 TTL 缓存（先用缓存渲染再拉新数据）。
跨技能协同：与数据可视化技能（图表小部件）、表格技能（DataGrid）、设计令牌技能（主题变量）、表单技能（日期范围选择器、多选过滤器）组合，形成统一的分析体验。
捆绑可执行资源：generate-dashboard-layout.py（生成响应式网格配置）、calculate-kpi-metrics.py（计算趋势与迷你图）、validate-widget-config.py（校验小部件与过滤器配置）、optimize-dashboard-performance.py（性能分析）、export-dashboard.py（多格式导出）。

和普通做法比强在哪：普通做法是「要图表就给图表代码」，得到的是一个孤立组件；这个技能交付的是「界面 + 状态 + 数据流 + 性能 + 主题」的完整拼图，尤其是过滤器联动和实时更新这两块，通常最容易被忽略、也最容易在上线后返工。

如何使用该技能？

第 1 步：描述需求，锁定布局类型

先把三件事说清楚：谁看（管理层 / 运营 / 运维）、看什么（收入、活跃用户、告警）、要不要让用户自己改布局。示例提示词：

帮我做一个面向运营团队的电商销售仪表板。需要 4 个 KPI 卡片（总收入、活跃用户、订单量、转化率），1 个收入趋势面积图，1 个交易明细表格，顶部一个日期范围过滤器和分类多选过滤器。布局允许用户拖动，刷新间隔 30 秒。

第 2 步：确定技术路线

技能会按「快速分析用 Tremor、可定制用 react-grid-layout、两者结合」给出选型。上面的需求既需要拖放又需要专业卡片，通常会建议「Tremor 出小部件内容 + react-grid-layout 管布局」。

第 3 步：搭骨架——全局状态与过滤器上下文

先建立共享的过滤器上下文，把日期范围和分类放进去，并用 Provider 包住整个仪表板，保证后续所有小部件都能读到同一份过滤条件。

第 4 步：建小部件——从 KPI 卡片开始

import { Card, Grid, Metric, Text, BadgeDelta, AreaChart } from '@tremor/react';

function QuickDashboard({ data }) {
  return (
    <Grid numItems={1} numItemsSm={2} numItemsLg={4} className="gap-4">
      <Card>
        <Text>总收入</Text>
        <Metric>$45,231.89</Metric>
        <BadgeDelta deltaType="increase">+12.5%</BadgeDelta>
      </Card>
      <Card>
        <Text>活跃用户</Text>
        <Metric>1,234</Metric>
        <BadgeDelta deltaType="decrease">-2.3%</BadgeDelta>
      </Card>
      <Card className="lg:col-span-2">
        <Text>收入趋势</Text>
        <AreaChart
          data={data.revenue}
          index="date"
          categories={["revenue"]}
          valueFormatter={(value) => `$${value.toLocaleString()}`}
        />
      </Card>
    </Grid>
  );
}

输出说明：1 列 / 2 列 / 4 列的响应式网格，窄屏自动堆叠；每张卡片自带标签、主指标与趋势徽标；面积图通过 valueFormatter 统一货币格式——这正是普通图表代码容易漏掉的细节。

第 5 步：接数据流

首屏用 Promise.all 并行拉取 KPI、图表、表格三路数据，避免串行等待。
实时更新优先选 SSE：前端用 new EventSource('/api/dashboard/stream') 订阅，服务端按 { widgetId, data } 推送增量，前端 updateWidget 精确刷新单个小部件。
需要向服务端回传操作（如过滤器变更）时再上 WebSocket；环境不支持时退回智能轮询，并在 document.hidden 时自动暂停。

第 6 步：调性能与主题

懒加载首屏以下的小部件，给高成本小部件加 TTL 缓存，用性能脚本体检，再用设计令牌统一 KPI 数值字号与涨跌色：

python scripts/optimize-dashboard-performance.py --analyze dashboard-config.json
python scripts/calculate-kpi-metrics.py --data metrics.json --period monthly

第 7 步：导出与交付

需要给管理层发周报时，用导出脚本或技能的导出小部件产出 PDF / 图像 / 数据；最后按桌面（>1200px 多列）、平板（768–1200px 两列）、移动（<768px 单列）三档断点逐一验收。

同类型竞品对比分析

方案名称	定位	核心功能	安装 / 使用门槛	适用场景	优势与不足
创建仪表板Skill（creating-dashboards）	面向 AI 助手的仪表板构建方法论与资源包	KPI 卡片规范、三种布局范式、全局过滤器、SSE/WS/轮询三套实时方案、性能脚本与模板资产	需在支持技能机制的环境中启用，配合 React 项目与 Python 脚本使用	从零搭建 BI 看板、监控大屏、执行报告、SaaS 多租户仪表板	优势：覆盖「布局 + 状态 + 数据流 + 性能」全链路，附可执行脚本；不足：偏前端工程范式，非纯零代码，需一定 React 基础
Tremor（组件库）	预样式化仪表板组件库	KPI 卡片、面积图、条形图、表格等即用组件	`npm install @tremor/react`，通常需配合 Tailwind CSS	标准分析界面、追求快速交付	优势：开箱即用、样式专业；不足：拖放与自定义布局能力弱，深度定制受限
react-grid-layout（布局库）	网格拖放布局引擎	拖放、可调整大小、断点响应、布局持久化	`npm install react-grid-layout` 并引入样式文件	可定制仪表板、看板编辑器、布局构建工具	优势：布局灵活、用户自主性强；不足：只解决布局，图表、KPI、数据流需自行实现
商业 BI / 自托管 BI 平台	面向业务人员的分析平台	可视化建模、拖拽报表、权限与分享	平台部署或订阅，按官方说明为准	业务自助分析、组织级报表	优势：非技术用户可上手；不足：深度定制与前端集成灵活度低，成本与厂商绑定需评估

怎么选：如果目标是把仪表板能力做进自己的产品里、并且要能改代码改样式，创建仪表板Skill 的「方法论 + 组件组合」更合适；如果只是内部快速出几张固定报表，直接用商业 BI 平台可能更快。

该技能的典型应用场景与实际体验情况

场景一：运营团队的电商销售看板 运营同学每天要回答「今天卖得好不好」。痛点是指标口径不统一、改一次日期要挨个组件重算。用这个技能，先定义全局日期范围上下文，4 个 KPI 卡片（收入、活跃用户、订单量、转化率）+ 收入趋势面积图 + 交易明细表格全部挂在同一份过滤条件下，改一次时间全局联动。实际体验：上手难度中等，难在首次把上下文搭对，一旦搭好，后续加小部件几乎是复制粘贴；注意 KPI 的对比周期要在文案里写清楚（比如「对比上月」而不是模糊的「环比」）。

场景二：运维实时监控大屏 值班同学需要异常发生后几十秒内看到指标抬头。技能的实时更新章节直接给出 SSE 首选方案，以及不支持 SSE 时的智能轮询回退（标签页切到后台自动暂停，避免无意义请求）。实际体验：效果取决于后端推流能力，前端侧代码量很小；注意务必给每个小部件加错误边界和重试，否则一条失败的推送可能让整块看板白屏。

场景三：面向管理层的执行报告页 需求是「一页看清季度经营状况」，强调美观、可导出、可分享。使用固定布局 + 主题令牌（KPI 数值统一用同一字号变量、涨跌色统一用成功 / 错误色），并通过导出功能产出 PDF 或图像。实际体验：视觉一致性提升明显，因为颜色和字号来自令牌而不是各人凭感觉调；注意移动端要单独验收，管理层很可能在手机上打开链接。

场景四：多租户 SaaS 的自定义仪表板 不同客户想看不同指标。这里走 react-grid-layout 路线，允许拖放与调整大小，把 layouts 存入 localStorage（生产环境建议改为按用户存到后端），并配合小部件目录让用户从「组件库」里挑。实际体验：灵活性很强，但要额外处理默认布局、越界拖拽和升级兼容；注意事项是布局结构变更时需要有迁移策略，避免老用户保存的布局在新版本下错位。

该技能能为用户带来的价值

把「隐形工作」显性化：过滤器联动、加载骨架、错误重试、后台暂停轮询这些不出现在需求文档里、却决定仪表板好不好用的细节，被固化成默认动作，减少上线后的返工。
显著缩短首版交付时间：示例与模板覆盖销售、监控、执行报告、可定制四类完整实现，配合可执行脚本生成布局、计算 KPI 趋势，省掉的往往是反复试错的时间。具体提效幅度因团队与项目而异。
降低专业门槛：不熟悉实时推送的开发者也能按 SSE → WebSocket → 轮询的优先级选型；不熟悉设计系统的团队也能借助设计令牌保持视觉一致。
为后续扩展留好接口：基于模板的布局、小部件目录与配置资产，意味着第二块、第五块看板不必再从零开始，长期看是把一次性项目变成可复用的能力资产。
性能有据可依：懒加载、并行获取、小部件级缓存与性能分析脚本形成闭环，数据量增长时仍有明确的优化路径。

常见问题 FAQ

Q1：这个技能怎么安装？装完怎么确认能用？ 在支持技能机制的 AI 助手中搜索技能名称「创建仪表板」或英文名 creating-dashboards（技能ID 13437）并按提示启用，具体入口和命令以官方说明为准。项目侧按需安装 @tremor/react 或 react-grid-layout。验证方式：让它生成一个带日期过滤器的 KPI 仪表板，若回答体现布局类型选择、过滤器上下文与响应式断点等特有套路，即为生效。

Q2：这个技能收费吗？ 技能本身在详情中未说明定价信息，是否收费取决于承载它的平台与你的订阅方案，以官方说明为准。它引用的 Tremor、react-grid-layout 属于第三方开源库，各自遵循其开源许可；如果你选商业 BI 平台作为替代方案，则需按该平台规则评估成本。

Q3：我该选 Tremor 还是 react-grid-layout？ 一句话判断：要不要让用户自己改布局。不需要就选 Tremor，组件预置、代码最少、样式专业；需要拖放和调整大小就选 react-grid-layout；既要专业卡片又要自由布局，就两者结合——Tremor 负责小部件内容，react-grid-layout 负责布局管理。

Q4：适合谁用？不做前端的同学能用吗？ 最适合前端工程师、数据分析师、独立开发者和需要交付内部 BI / 监控界面的团队。它给出的示例是 React + TypeScript 代码，因此完全不懂前端的人直接使用会有门槛；如果你只是想给业务同学做几张固定报表，更适合选商业 BI 平台或自托管 BI 工具。

Q5：实时更新一定要上 WebSocket 吗？ 不必，技能的建议是分场景：只需要服务端往看板单向推数据，优先用 SSE，实现简单、开销小；需要前端把过滤器变更等指令回传给服务端，再用 WebSocket；运行环境不支持前两者时，退回智能轮询，并记得监听页面可见性变化，在标签页隐藏时暂停请求。

Q6：数据量变大后看板卡顿怎么办？ 按技能给出的顺序排查：先做懒加载（首屏只渲染可见小部件）、再改成并行数据获取避免串行等待、然后给小部件加 TTL 缓存（先用旧数据渲染，同时拉新数据），最后用 optimize-dashboard-performance.py 分析配置定位瓶颈。