82 lines
8.3 KiB
Markdown
82 lines
8.3 KiB
Markdown
---
|
||
name: visual-exposure
|
||
metadata:
|
||
display-names:
|
||
zh-CN: 可视化报告
|
||
en-US: Visual Report
|
||
description: 用于制作可视化报告、专题视觉页、信息图、视觉长图、概念可视化、产品能力曝光、方案亮点展示等内容型 HTML 视觉作品。适合用户想把材料、数据或观点组织成可阅读、可展示、可传播的视觉化表达，但不希望做成 PPT、传统 dashboard 或纯 ECharts 图表的场景。触发词：可视化报告, 视觉报告, 可视化曝光, 视觉化曝光, 信息图, 长图, infographic, 视觉表达, 概念可视化, 亮点展示, 能力曝光
|
||
available-agents:
|
||
- CreativeDesign
|
||
---
|
||
|
||
# 可视化报告与专题表达
|
||
|
||
创建内容驱动的 HTML 视觉作品。它可以是一页长报告、专题视觉页、视觉长图、信息图、画布式设计稿，或带少量轻交互的浏览型报告；具体形态由用户目标、材料体量和阅读场景决定，不预设固定模板。
|
||
|
||
## 工作方式
|
||
|
||
1. 先读用户材料，提取主题、受众、阅读场景、核心结论、必须出现的事实和可省略的细节。
|
||
2. 判断报告目的：汇报、解释、披露、说服、传播、留档，还是做视觉方向探索。
|
||
3. 选择交付形态：长页报告、专题页、视觉长图、单屏摘要、画布式多方案、图文混排报告、偏打印感的正式报告等。不要把所有需求压成同一种版式。
|
||
4. 按材料逻辑组织内容，而不是套固定目录、固定模块或固定视觉模板。参考样式只能启发表达方式，不能替代对当前材料的判断。
|
||
5. 把材料拆成具体阅读任务：这一段要让读者完成什么判断、理解什么关系、记住什么事实、比较什么差异、追踪什么过程、相信什么证据。不要把这些任务名直接变成目录或模块标题。
|
||
6. 为每个阅读任务现场生成合适的组件、视觉和布局：先说明这段内容需要什么表达方式，再落成具体 UI / 图形 / 排版 / 图表 / 截图 / 文字组合。可以创造新的结构和视觉隐喻，不受现有组件名限制；避免所有章节共享同一套组件组合。
|
||
7. 先写风格 brief：主题隐喻、受众姿态、材料语言、配色逻辑和签名元素。财务报告可以像正式报告册，员工调研可以像组织研究档案，产品上市总结可以像品牌战报；这些只是启发，必须从用户材料里推导。
|
||
8. 建立版式系统：画幅、栅格、字号层级、颜色、图标/线条语言、强调方式和章节节奏。版式系统必须说明不同章节如何变化，而不是所有章节都用同一种上下结构。
|
||
9. 产出单个 HTML 文档。用户需求明确时直接做；只有主题、素材或交付形态完全无法判断时，才问少量必要问题。
|
||
|
||
## 内容组织
|
||
|
||
本 skill 中出现的报告形态、表达方式、组件和版式都只是示意，不是必须参考的清单。最重要的是根据用户需求和材料内容，生成一个能把报告讲清楚的结构：读者为什么要看、先看什么、如何理解关系、证据在哪里、最后形成什么判断，都应在结构里自然成立。
|
||
|
||
可视化报告不是把图表排满，也不是把文字切成很多卡片。每个信息块都要服务当前材料里的一个真实阅读动作：让读者确认对象、抓住重点、理解关系、比较差异、定位证据、看到过程、识别风险或形成下一步判断。把这些阅读动作翻译成本次需求专属的视觉结构，而不是复用固定模块名。
|
||
|
||
允许为当前需求重新发明表达结构：可以合并、拆分、放大、弱化、横向展开、纵向叙事、图文化、表格化、截图化或做成完全不同的布局。只要它能更清楚地解释报告内容，就优先于任何示例组件或常见版式。
|
||
|
||
如果材料很长，先压缩成报告叙事，不要把原文完整铺上去。需要精确查数时使用表格或附录；需要快速传播时使用摘要和视觉重点；需要正式汇报时保留章节编号、图表标题和口径说明。
|
||
|
||
不要把关键内容压成角落里的附录片段。用户明确要求展示的部分，应按报告目标给足版面权重，并选择合适的信息结构承载。
|
||
|
||
## 版式策略
|
||
|
||
可视化报告要像一份经过编辑设计的专题，而不是由同款卡片拼起来的长页面。先决定阅读节奏，再落组件：
|
||
|
||
- 根据材料的展开方式设计版式：它可能需要连续叙事、密集证据、空间关系、过程推进、对照判断、沉浸式主视觉、正式报告册，或完全不同的结构。先为当前需求命名一个版式概念，再确定栅格、密度、视觉重心和章节变化。
|
||
- 版式变化来自内容关系，不来自凑组件。关键段落可以被放大、拆页、满版化、图文化或变成精确表格；次要段落可以压缩、并列、收进注释或弱化。
|
||
- 每个章节的结构可以不同，但要属于同一套视觉系统。变化要能解释：为什么这里适合宽图、那里适合密集表格、另一处适合分段叙事。
|
||
|
||
不要为了“丰富”而乱放装饰。变化应该来自内容关系和阅读任务，而不是从组件清单里凑满页面。
|
||
|
||
## 视觉原则
|
||
|
||
- 优先清楚，其次好看。读者应该先理解结构，再感受到风格。
|
||
- 明暗主题由需求、品牌、素材、受众和阅读场景决定；浅色、暗色、中性或局部深色都可以。选择后要保证对比度、可读性和信息层级，并能解释为什么适合当前主题。
|
||
- 默认平面化处理：内容区优先使用细边框、分隔线、浅底色、色块、表格斑马纹、编号和标签建立层级；不要给章节、卡片、图表容器加各种 `box-shadow`。
|
||
- 少用装饰性渐变、发光、玻璃拟态。视觉效果要帮助分组、强调或引导视线。
|
||
- 风格跟随内容、受众和品牌：可以正式、温和、技术、编辑化、品牌化或实验感，但不要从某个样例场景继承固定颜色、固定目录或固定组件。
|
||
- 每份报告应有一个可解释的签名元素。签名元素要从用户主题、材料质感和阅读任务中生成，而不是复用固定手法；它可以是任何能组织内容、建立记忆点并保持一致性的视觉规则。
|
||
- 真实素材优先：用户给的截图、logo、图片、图标、数据片段要优先使用。没有素材时，用清楚的占位结构和可替换文案。
|
||
- 允许少量动效，但只用于进入、强调或引导阅读，不做干扰理解的持续动画。
|
||
- 可以包含数字、图表和表格，但它们服务于报告叙事；不要为了“可视化”而把所有内容都做成图。
|
||
- 深色区域可以用于封面、结论、行动区或整篇报告的主视觉；只要它服务主题气质和阅读体验，而不是作为无依据的装饰。
|
||
|
||
## 画布与交付
|
||
|
||
- 多方案、设计稿、方向探索：使用 `design-canvas.jsx`，每个方向一个 `<DCArtboard>`。
|
||
- 单一可视化报告、视觉长图或专题视觉稿：做成完整 HTML 页面，保持明确画幅、节奏和层级。
|
||
- 如果用户要“设计稿”，优先走画布式交付；如果用户要“可直接展示/传播”，可以做成完整页面式视觉作品。
|
||
- 所有文字应直接写在 HTML 中，便于用户后续编辑。
|
||
|
||
## 检查清单
|
||
|
||
- 交付形态匹配用户需求：长页报告、专题页、长图、画布设计稿或单屏摘要，而不是被固定模板绑住。
|
||
- 当前需求的主题、边界和最重要信息在第一屏或开篇清楚可见。
|
||
- 章节顺序跟随材料逻辑，不按评测集样例或预设场景套目录。
|
||
- 章节版式有节奏变化，并且变化来自材料关系；没有一路同款上下卡片，也没有因为预设组件清单而硬凑结构。
|
||
- 没有大面积空白、错位、低对比、文字不可读或模块之间风格突兀。
|
||
- 内容区保持平面化，没有滥用阴影、发光、玻璃拟态或厚重悬浮效果。
|
||
- 所有表达载体各司其职，没有为了数据而堆图，也没有用空泛文字或预设组件填空间。
|
||
- 文字密度可读，没有小字堆叠。
|
||
- 图标、线条、颜色和卡片样式属于同一套视觉语言。
|
||
- 明暗选择能解释为什么适合这个主题；无论浅色还是暗色，都保证长文、图表和表格可读。
|
||
- 事实性内容没有编造；不确定内容用中性描述或占位说明。 |