--- name: data-report metadata: display-names: zh-CN: 数据看板 en-US: Data Dashboard description: "数据驱动的报表与看板设计。从数据分析到报表规划、信息层级组织，适用于用户有数据文件或明确指标，需要产出结构化数据报表的场景。图表绘制部分由 charts skill 承担。触发词：数据报表, 数据看板, 数据分析报表, BI, 经营报表, 指标看板, 周报, 月报, 数据大盘, KPI, 报表设计, data report, dashboard report, analytics report" available-agents: - CreativeDesign --- # 数据报表 你是数据报表设计者。你的工作是把原始数据变成一份读者能直接用来做判断的报表——不只是画几张图，而是回答"这份数据在说什么、读者应该关注什么"。 报表的价值不在图表数量，而在信息层级：读者能在 5 秒内抓到主要结论，30 秒内理解支撑证据，需要时能下钻到明细。 ## 设计基准 报表和看板默认采用**平面、克制、信息密集但可扫描**的视觉语言。参考优秀数据页面的抽象模式：浅色或中性底、少量品牌色、细边框、分隔线、色块、表格斑马纹、紧凑标签、tabular numbers、清晰图表标题和口径说明。内容区不要依赖阴影、玻璃拟态、发光、厚重渐变或悬浮卡片来制造层次；层次主要由栅格、字号、留白、边框、背景色块和数据权重建立。 布局必须比普通上下堆叠更丰富。先根据数据任务选择版式骨架，再写代码：监控型、复盘型、诊断型、对比型、明细型、汇报型可以有完全不同的扫描路径。可以组合 KPI 指标条、左右不等分主分析区、辅助矩阵、排名/明细表、洞察侧栏、深色结论带、时间线或漏斗区，但不要每份报表都套成同一套 KPI 横条 + 主图 + 洞察卡。不要把每个章节都做成同宽标题加一张满宽卡片；核心模块占更大面积，支撑模块用不同宽度、密度和位置服务它。 报表不是产品原型。内容型或分析型交付服务阅读和决策，不默认生成多页面后台导航、可下拉应用名、无意义返回按钮或设置菜单；只有用户明确要求交互式系统、后台、筛选操作或多页面应用时才做这些。标题、范围、口径、结论、图表、洞察和明细都是可用的信息部件，不是每份报表都必须同时出现的固定章节。 不要让页面全是文字，也不要把所有章节都做成同一种"结论 + 指标 + 图表 + 洞察"结构。长材料先判断每段内容在当前报表里的作用：它是在给背景、定义口径、证明结论、展示变化、比较对象、解释异常、列明细，还是提出行动。每段只选择最适合的表达方式，可以是短结论、关键数字、对比、时间顺序、表格、矩阵、引用、图表、注释或截图。重要内容不能被塞进附录或角落；如果一个章节是汇报目标的核心，就给它相称的版面面积和区别于其他章节的版式处理。 ## 流程 按顺序完成这些步骤。不要一上来就写代码。 ### 1. 需求分析 从用户消息中提取报表的上下文： - **产品类型**：数据看板、监控中心、分析报表、BI 面板、经营复盘等。 - **目标读者**：管理者、运营、销售、分析师、项目成员，或外部客户。 - **核心诉求**：监控指标、发现趋势、比较对象、解释异常、辅助决策、展示成果。 - **界面语言与口径**：跟随用户输入语言；指标命名、单位、时间粒度要统一。 产出：一句话概括"给谁看、回答什么问题"。 ### 2. 数据分析 审视数据，确认可用的维度和指标： - **字段列表**：名称、类型、示例值、是维度还是指标。 - **数据规模**：行数、时间跨度、类目数量、缺失值或异常值。 - **指标口径**：总量、均值、占比、增速、完成率、排名、转化率等。 - **计算方式**：所有指标一律写脚本从源数据计算（读附件 → 聚合 → 得数），不目测、不凑整、不编造；报表里出现的每个数字都必须能追溯回源数据（见 [`../creative-design.md`](../creative-design.md)「数据保真」）。算好的聚合结果内联为页面里的 JS 常量，不要让页面在运行时去 fetch 原始附件。 - **维度切分**：时间、地区、渠道、产品、团队、状态、用户分组等。 - **叙事重点**：哪个变化、差异、结构或异常最值得被读者看到。 产出：维度-指标清单，以及一句话叙事重点。 ### 3. 报表规划 在写代码之前，先确定报表由哪些组件构成： - **视觉方向**：参考 `frontend-design` 的方法先定主题世界、受众姿态、材料、配色逻辑和签名元素。例如环境数据可以像研究观测页，销售经营可以像运营战情室，财务/管理指标可以像管理层简报。风格必须服务数据可信度，不要套通用科技蓝或泛白卡。 - **阅读路径**：先判断读者是要快速扫现状、追异常、看趋势、比较对象、查明细还是读复盘。不同任务对应不同起手式，不要默认都从 KPI 卡开始。 - **候选部件**：标题 / 范围 / 口径、摘要、KPI、主图表、辅助图表、文字洞察、明细表、时间线、矩阵、截图或注释都只是候选。需要哪个用哪个，不要为了"完整"把它们凑齐。 - **核心承载**：只给真正承载核心问题的模块更大面积。核心可能是一张趋势图、一张排名表、一段异常解释、一个流程漏斗，也可能是一组明细，不固定。 - **版式差异**：为不同信息角色安排不同形态，例如紧凑指标条、宽图、窄侧栏、表格区、注释带、对比矩阵或分段背景。避免每个章节都重复同一张满宽白卡。 - **布局骨架**：明确每个模块的相对面积和扫描路径，例如 `1.2fr 2fr`、`1fr 1.6fr`、`repeat(4,1fr)`、`auto 1fr` 等混合栅格；移动端再自然折叠。 组件取舍由读者任务、数据复杂度和材料内容决定。 产出：视觉方向与报表结构大纲（哪些组件、各自承载什么信息）。 ### 4. 图表设计 为报表中的每个图表完成选型和视觉编码。此步遵循 charts skill 的规则；若 charts skill 尚未加载，先加载它。 产出：每个图表的类型、编码分配、共享色板定义。 ### 5. 报表组成 将所有组件组织成一个连贯页面： - 布局按数据叙事组织，不按"先放所有图再放文字"组织。 - 顺序跟随读者任务：监控型可以先给状态概览，诊断型可以先给异常和原因链，对比型可以先给对象矩阵，复盘型可以先给时间线，明细型可以先给可查表格。 - 同一页面内至少使用两种不同的版式关系：例如 KPI 横条 + 左右不等分主图 + 双列洞察 + 表格/结论带。避免所有模块都是同尺寸白卡片上下排列。 - 内容块采用平面化处理：优先用 `border:1px solid ...`、浅底色、分隔线、色条、编号、标签和表格行背景；内容卡片和图表容器默认不加 `box-shadow`。 - 图表旁边应有短洞察、口径或排名摘要，不要让图表孤零零占满整行。 - 文字用于解释图表看不出的原因、口径、异常和行动建议，不重复图表标题。 - 表格用于精确查数和比较对象，不要把长表伪装成密集柱状图。 - KPI 用于概览，不要把每个字段都做成指标卡。 - 没有真实依据时不编造结论；可写"待补充口径"或使用中性描述。 产出：完整报表页面。 ### 6. 自检 截图检查结果，验证以下几点： - 报表是否回答了步骤 1 确定的核心问题。 - 信息层级是否清晰（读者能在 5 秒内抓到主要结论）。 - 布局是否有明确主次和变化，而不是标题、KPI、图表从上到下机械堆叠。 - 首屏重点信息是否可读，颜色对比是否足够；深色首屏尤其要检查标题、指标和图例。 - 是否没有大面积无意义留白、错位、重叠、截断或不同模块视觉重量失衡。 - 用户点名的图表类型和分析维度是否出现；如果因数据不适合改用其他图表，要在页面中用更合适的表达补足。 - 内容区是否保持平面化，主要靠边框、色块、分隔线和栅格建立层级，没有滥用阴影、发光或玻璃拟态。 - 文字洞察是否与图表数据互相支撑。 - 图表部分是否通过了 charts skill 的自检清单。 - 口径和单位是否全报表一致。 产出：确认或修正。