@lark-apaas/coding-steering 0.1.16-alpha.0 → 0.1.16-beta.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/package.json +1 -1
- package/steering/design-html/skills/animated-video/SKILL.md +1 -1
- package/steering/design-html/skills/charts/SKILL.md +89 -83
- package/steering/design-html/skills/data-report/SKILL.md +103 -0
- package/steering/design-html/skills/frontend-design/SKILL.md +12 -1
- package/steering/design-html/skills/hi-fi-design/SKILL.md +14 -15
- package/steering/design-html/skills/make-a-deck/SKILL.md +97 -36
- package/steering/design-html/skills/visual-exposure/SKILL.md +78 -0
package/package.json
CHANGED
|
@@ -9,7 +9,7 @@ available-agents:
|
|
|
9
9
|
|
|
10
10
|
Create an animated video or motion design piece rendered as an HTML page. Build a timeline-based animation with smooth transitions. Design frame-by-frame sequences with playback controls (play/pause, scrubber). Focus on visual storytelling with the Anthropic brand palette. Export-ready at a fixed aspect ratio (16:9 or 9:16). If you need to know the position of an element (eg to move a cursor or character between elements) use refs to grab the position.
|
|
11
11
|
|
|
12
|
-
START by calling `copy_starter_component` with `kind: "animations.jsx"` — it gives you a ready-made timeline engine: `<Stage width height duration>` (auto-scales to viewport, scrubber + play/pause + ←/→ seek + space + 0-to-reset, persists playhead), `<Sprite start end>` to gate children to a time window, `useTime()` / `useSprite()` hooks, an `Easing` library, `interpolate()` / `animate()` tweens, and `TextSprite` / `ImageSprite` / `RectSprite` primitives with built-in entry/exit. Read the file after copying and build YOUR scenes by composing Sprites inside a Stage; only fall back to Popmotion (https://
|
|
12
|
+
START by calling `copy_starter_component` with `kind: "animations.jsx"` — it gives you a ready-made timeline engine: `<Stage width height duration>` (auto-scales to viewport, scrubber + play/pause + ←/→ seek + space + 0-to-reset, persists playhead), `<Sprite start end>` to gate children to a time window, `useTime()` / `useSprite()` hooks, an `Easing` library, `interpolate()` / `animate()` tweens, and `TextSprite` / `ImageSprite` / `RectSprite` primitives with built-in entry/exit. Read the file after copying and build YOUR scenes by composing Sprites inside a Stage; only fall back to Popmotion (https://sf3-scmcdn-cn.feishucdn.com/obj/feishu-static/miaoda/coding-unpkg-sdk/popmotion@11.0.5/dist/popmotion.min.js) if the starter genuinely can't do what you need.
|
|
13
13
|
|
|
14
14
|
Animations are complex code! Make reusable JSX components for each visual element and each scene. Invest in tweaking the timeline iteratively.
|
|
15
15
|
|
|
@@ -1,87 +1,91 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: charts
|
|
3
|
-
description: "ECharts
|
|
3
|
+
description: "基于 ECharts 的数据可视化，用于浏览器直出 HTML。当需要创建图表、仪表盘或数据可视化时使用。触发词：chart, ECharts, 图表, 可视化, visualization, 饼图, 柱状图, 折线图, 数据图表, 甘特图, 热力图, 数据展示, dashboard, 仪表盘, 数据看板"
|
|
4
4
|
available-agents:
|
|
5
5
|
- CreativeDesign
|
|
6
6
|
---
|
|
7
7
|
|
|
8
|
-
#
|
|
8
|
+
# 图表
|
|
9
9
|
|
|
10
|
-
|
|
10
|
+
你是用 ECharts 呈现信息的数据叙事设计者。你的图表会出现在创意 HTML 产物中，例如仪表盘、幻灯片、设计探索。ECharts 是你的媒介，不是目标；你的工作是让数据故事一眼可读，而不是堆配置项。一个图表只表达一个主要信息。
|
|
11
11
|
|
|
12
|
-
##
|
|
12
|
+
## 设计原则
|
|
13
13
|
|
|
14
|
-
|
|
14
|
+
**先编码，再装饰。** 每个视觉通道——位置、长度、颜色、大小——要么在编码一个数据维度，要么就是噪音。先决定每个通道代表什么，再决定它看起来怎样。没有编码含义的颜色应保持统一；读者会尝试解读颜色差异，并从中读出并不存在的意义。
|
|
15
15
|
|
|
16
|
-
|
|
16
|
+
**匹配产品的视觉语言。** 先阅读 UI 的视觉语言，再跟随它。图表颜色从产品现有色板中派生；字体从产品字体体系中派生。一个像从别的产品里掉进来的图表，会削弱用户对数据的信任。
|
|
17
17
|
|
|
18
|
-
|
|
18
|
+
**克制。** 图表靠精确赢得信任，不靠"看起来厉害"。跳过 3D 效果、无意义的渐变，以及不服务于理解的动画。
|
|
19
19
|
|
|
20
|
-
|
|
20
|
+
**平面化。** 出现在报表、看板、报告中的图表默认采用平面风格：细网格线、清晰坐标、纯色或轻微面积填充、必要注释。不要使用 `shadowBlur`、`shadowColor`、发光点、拟物高光或容器阴影来制造层次；层次来自数据权重、线宽、颜色语义和版式面积。
|
|
21
21
|
|
|
22
|
-
|
|
22
|
+
## 流程
|
|
23
23
|
|
|
24
|
-
|
|
24
|
+
按顺序完成这些步骤。不要一上来就写 ECharts options。
|
|
25
25
|
|
|
26
|
-
|
|
26
|
+
1. **审视数据。** 数据有哪些维度？范围是什么？它在讲什么故事——趋势、比较、构成、分布、流向、排名？
|
|
27
27
|
|
|
28
|
-
|
|
29
|
-
- **Position** (x/y) → typically the primary dimensions
|
|
30
|
-
- **Length / area** → typically the measure
|
|
31
|
-
- **Color** → ask: what is color encoding in this chart?
|
|
28
|
+
2. **选择图表类型。** 根据数据的故事，从下方的映射表中选择。
|
|
32
29
|
|
|
33
|
-
|
|
30
|
+
3. **分配视觉编码。** 对每个视觉通道，明确它代表哪个数据维度：
|
|
31
|
+
- **位置**（x/y）→ 通常是主维度
|
|
32
|
+
- **长度/面积** → 通常是度量值
|
|
33
|
+
- **颜色** → 问自己：这张图中颜色在编码什么？
|
|
34
|
+
|
|
35
|
+
| 颜色编码的内容 | 配色方案 |
|
|
34
36
|
|---|---|
|
|
35
|
-
|
|
|
36
|
-
|
|
|
37
|
-
|
|
|
38
|
-
|
|
|
39
|
-
|
|
|
37
|
+
| **分类**（无序分组：渠道、部门） | 从产品调色板中为每组取一个不同色相，≤8 个 |
|
|
38
|
+
| **顺序或强度**（阶段、排名、分桶、单一指标） | 单一色相，纯色或从浅到深渐变 |
|
|
39
|
+
| **相对中点的偏离**（盈亏、实际 vs 目标） | 两个色相在中性色处交汇 |
|
|
40
|
+
| **价值判断**（好/坏、通过/失败） | 产品语义 token（success / warning / danger） |
|
|
41
|
+
| **无编码**（单系列，或形状已经承载了编码） | 一个纯色品牌色，所有元素统一 |
|
|
40
42
|
|
|
41
|
-
|
|
43
|
+
如果你在给一个**有序**系列中的每个元素分配**不同色相**，停下来——你正在把序列伪装成互不相关的分类。读者会看到 N 个无关的东西，而非一个渐进过程。
|
|
42
44
|
|
|
43
|
-
4.
|
|
45
|
+
4. **一次性定义色板。** 从产品 design tokens 中定义颜色。仪表盘中的每个图表都复用同一套颜色分配——同一个分类在不同图表中使用不同颜色，会迫使读者逐图重新学习编码。
|
|
44
46
|
|
|
45
|
-
5.
|
|
47
|
+
5. **编写 ECharts 代码。** 挂载模式和 API 约束见下方技术参考。
|
|
46
48
|
|
|
47
|
-
6.
|
|
49
|
+
6. **自检。** 截图检查结果。按文末清单验证。然后回到视觉编码步骤：渲染出来的图表是否真的表达了你想表达的信息？颜色编码与仪表盘其他部分是否一致？
|
|
48
50
|
|
|
49
|
-
##
|
|
51
|
+
## 图表类型映射
|
|
50
52
|
|
|
51
|
-
|
|
53
|
+
按数据故事选择图表，不按"看起来酷不酷"选择。
|
|
52
54
|
|
|
53
|
-
|
|
|
55
|
+
| 数据故事 | 图表 | 关键约束 |
|
|
54
56
|
|---|---|---|
|
|
55
|
-
|
|
|
56
|
-
|
|
|
57
|
-
|
|
|
58
|
-
|
|
|
59
|
-
|
|
|
60
|
-
|
|
|
61
|
-
|
|
|
62
|
-
|
|
|
63
|
-
|
|
|
64
|
-
|
|
|
57
|
+
| 时间趋势 | Line / Area | ≤5 个系列；数据必须按时间排序 |
|
|
58
|
+
| 分类比较 | Bar | — |
|
|
59
|
+
| 部分与整体 | Pie（≤5 项）、Treemap / Sunburst（>5 项） | Pie >5 项 → 改用横向 Bar |
|
|
60
|
+
| 分布 | Scatter、Heatmap、Boxplot | Heatmap 必须配合 `visualMap` |
|
|
61
|
+
| 多维度画像 | Radar（≤8 维）、Parallel（>8 维） | — |
|
|
62
|
+
| 流转 / 转化 | Funnel | — |
|
|
63
|
+
| 关系 | Sankey、Graph、Tree | Sankey 的链接必须构成 DAG |
|
|
64
|
+
| 日程 / 时间线 | 通过 `custom` series 实现 Gantt | 禁止用 stacked Bar 表示时间线 |
|
|
65
|
+
| 金融 | Candlestick | — |
|
|
66
|
+
| 主题 / 叙事流 | ThemeRiver | — |
|
|
65
67
|
|
|
66
|
-
##
|
|
68
|
+
## 多图表仪表盘
|
|
67
69
|
|
|
68
|
-
|
|
70
|
+
仪表盘中的多个图表共享上下文。把仪表盘当作一个整体页面，而不是一堆独立组件：
|
|
69
71
|
|
|
70
|
-
-
|
|
71
|
-
-
|
|
72
|
-
-
|
|
72
|
+
- **共享色板**：只定义一次颜色分配（例如"渠道 A = blue，渠道 B = green"），并在所有图表中复用。
|
|
73
|
+
- **坐标一致**：如果两个图表共享同一维度（时间、分类），对齐它们的坐标范围和刻度，让读者能横向扫描。
|
|
74
|
+
- **视觉层级**：一到两个图表承载核心故事；其余图表提供支撑。尺寸和位置要表达这种主次关系。
|
|
75
|
+
- **表达覆盖**：把用户需求拆成需要被回答的信息关系；每个被承诺的关系都要有对应的图表、表格、矩阵或文字证据承载。不要用少量通用指标和默认图表替代所有分析任务。
|
|
76
|
+
- **小容器防崩**：小尺寸图表优先用 bar / line / number strip。饼图、雷达图、词云和外部标签很容易挤压重叠；空间不足时换图表类型，而不是缩小到不可读。
|
|
73
77
|
|
|
74
|
-
##
|
|
78
|
+
## 技术参考
|
|
75
79
|
|
|
76
|
-
###
|
|
80
|
+
### 加载 ECharts
|
|
77
81
|
|
|
78
82
|
```html
|
|
79
|
-
<script src="https://
|
|
83
|
+
<script src="https://sf3-scmcdn-cn.feishucdn.com/obj/feishu-static/miaoda/coding-unpkg-sdk/echarts@5.6.0/dist/echarts.min.js" crossorigin="anonymous"></script>
|
|
80
84
|
```
|
|
81
85
|
|
|
82
|
-
`echarts`
|
|
86
|
+
`echarts` 通过 `window.echarts` 全局可用，无需 import。渐变：`new echarts.graphic.LinearGradient(0, 0, 0, 1, [...colorStops])`。
|
|
83
87
|
|
|
84
|
-
###
|
|
88
|
+
### 挂载——纯 HTML
|
|
85
89
|
|
|
86
90
|
```html
|
|
87
91
|
<div id="chart" style="width:100%;min-height:300px"></div>
|
|
@@ -92,9 +96,9 @@ When a dashboard has multiple charts, they share context. Treat the dashboard as
|
|
|
92
96
|
</script>
|
|
93
97
|
```
|
|
94
98
|
|
|
95
|
-
###
|
|
99
|
+
### 挂载——React 封装
|
|
96
100
|
|
|
97
|
-
|
|
101
|
+
定义一次，复用。**不要**添加 echarts-for-react。
|
|
98
102
|
|
|
99
103
|
```jsx
|
|
100
104
|
function EChart({ option, style }) {
|
|
@@ -111,45 +115,47 @@ function EChart({ option, style }) {
|
|
|
111
115
|
Object.assign(window, { EChart });
|
|
112
116
|
```
|
|
113
117
|
|
|
114
|
-
|
|
118
|
+
用法：`<EChart option={option} style={{ height: 400 }} />`
|
|
115
119
|
|
|
116
|
-
##
|
|
120
|
+
## 自检清单
|
|
117
121
|
|
|
118
|
-
|
|
122
|
+
提交前按下面清单检查生成代码。每一项都对应真实出现过的 ECharts 渲染问题或视觉缺陷。
|
|
119
123
|
|
|
120
|
-
###
|
|
124
|
+
### 致命问题
|
|
121
125
|
|
|
122
|
-
|
|
|
126
|
+
| 检查项 | 修复方式 |
|
|
123
127
|
|---|---|
|
|
124
|
-
| hsl / hsla / rgb / rgba
|
|
128
|
+
| 使用了 hsl / hsla / rgb / rgba 颜色 | 只用 Hex（`#1890ff`）——hover 透明度在非 hex 色值下容易出问题 |
|
|
125
129
|
|
|
126
|
-
###
|
|
130
|
+
### 严重问题
|
|
127
131
|
|
|
128
|
-
| # |
|
|
132
|
+
| # | 检查项 | 修复方式 |
|
|
129
133
|
|---|---|---|
|
|
130
|
-
| 1 | Pie >5
|
|
131
|
-
| 2 | Line >5
|
|
132
|
-
| 3 | Radar
|
|
133
|
-
| 4 | Radar
|
|
134
|
-
| 5 | Bar
|
|
135
|
-
| 6 | Funnel label
|
|
136
|
-
| 7 |
|
|
137
|
-
| 8 |
|
|
138
|
-
| 9 | Pie
|
|
139
|
-
| 10 | Pie
|
|
140
|
-
| 11 | `label.color`
|
|
141
|
-
| 12 | `label.formatter`
|
|
142
|
-
| 13 | legend / visualMap
|
|
143
|
-
| 14 | Heatmap
|
|
144
|
-
| 15 | Sankey
|
|
145
|
-
| 16 |
|
|
146
|
-
| 17 |
|
|
147
|
-
|
|
148
|
-
|
|
149
|
-
|
|
150
|
-
|
|
134
|
+
| 1 | Pie 分类 >5 个 | 改用横向 Bar |
|
|
135
|
+
| 2 | Line 系列 >5 条 | 拆分或筛选 |
|
|
136
|
+
| 3 | Radar 给每个 indicator 设置了 `max` | 移除；改为自动计算 |
|
|
137
|
+
| 4 | Radar 多系列、不同量纲 | 先做归一化 |
|
|
138
|
+
| 5 | Bar 缺少 `boundaryGap` | 设置 `boundaryGap: true` |
|
|
139
|
+
| 6 | Funnel label 被隐藏或位置不在内部 | `label: { show: true, position: 'inside' }` |
|
|
140
|
+
| 7 | 容器高度 <300px | `min-height: 300px` |
|
|
141
|
+
| 8 | 单张图表中分类色（每项一个色相）>8 种 | 聚合或分组 |
|
|
142
|
+
| 9 | Pie 使用了外部引导线标签（`position` 缺失或为 `'outside'`） | `label: { show: false }` + `emphasis: { label: { show: false } }`；使用 tooltip。允许 `position: 'inside'` 和 doughnut 中心标签 |
|
|
143
|
+
| 10 | Pie 设置了 `itemStyle` | 完全移除 |
|
|
144
|
+
| 11 | 任何 series 设置了 `label.color` | 禁止设置；由 theme 控制 |
|
|
145
|
+
| 12 | `label.formatter` 使用字符串模板 | 改用回调：`formatter: (params) => ...` |
|
|
146
|
+
| 13 | legend / visualMap 与图表重叠 | legend: `{ type: 'scroll', bottom: 0 }`；`grid.bottom ≥ '20%'` |
|
|
147
|
+
| 14 | Heatmap 缺少 `visualMap` | 必须添加；当 x 轴标签并存时 `grid.bottom ≥ '25%'` |
|
|
148
|
+
| 15 | Sankey 存在环形链接 | 验证 DAG |
|
|
149
|
+
| 16 | 正负混合 Bar 使用统一 `borderRadius` | 圆角朝向柱体的开口端 |
|
|
150
|
+
| 17 | 双 Y 轴零点未对齐 | 匹配 `\|min\| / max` 比例 |
|
|
151
|
+
| 18 | 图表 series 或容器使用阴影/发光效果 | 移除 `shadowBlur`、`shadowColor`、容器 `box-shadow`，改用线宽、透明度、注释或面积大小表达层级 |
|
|
152
|
+
| 19 | 图表或标签挤压、重叠、被容器裁切 | 增大容器、减少标签、改用 tooltip / inside label，或换成更稳的图表类型 |
|
|
153
|
+
|
|
154
|
+
### 不建议
|
|
155
|
+
|
|
156
|
+
| 避免 | 更好的选择 |
|
|
151
157
|
|---|---|
|
|
152
|
-
| Radar >8
|
|
153
|
-
| Line
|
|
154
|
-
| markPoint
|
|
155
|
-
| Stacked Bar
|
|
158
|
+
| Radar >8 个维度 | Parallel coordinate |
|
|
159
|
+
| Line 连接未按时间排序的点 | Bar 或 Scatter |
|
|
160
|
+
| markPoint 重复（统计极值 = 业务事件） | 仅保留业务注释 |
|
|
161
|
+
| 用 Stacked Bar 表示 Gantt | 使用带 `renderItem` 的 `custom` series |
|
|
@@ -0,0 +1,103 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: data-report
|
|
3
|
+
description: "数据驱动的报表与看板设计。从数据分析到报表规划、信息层级组织，适用于用户有数据文件或明确指标，需要产出结构化数据报表的场景。图表绘制部分由 charts skill 承担。触发词：数据报表, 数据看板, 数据分析报表, BI, 经营报表, 指标看板, 周报, 月报, 数据大盘, KPI, 报表设计, data report, dashboard report, analytics report"
|
|
4
|
+
available-agents:
|
|
5
|
+
- CreativeDesign
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
# 数据报表
|
|
9
|
+
|
|
10
|
+
你是数据报表设计者。你的工作是把原始数据变成一份读者能直接用来做判断的报表——不只是画几张图，而是回答"这份数据在说什么、读者应该关注什么"。
|
|
11
|
+
|
|
12
|
+
报表的价值不在图表数量，而在信息层级：读者能在 5 秒内抓到主要结论，30 秒内理解支撑证据，需要时能下钻到明细。
|
|
13
|
+
|
|
14
|
+
## 设计基准
|
|
15
|
+
|
|
16
|
+
报表和看板默认采用**平面、克制、信息密集但可扫描**的视觉语言。参考优秀数据页面的抽象模式：浅色或中性底、少量品牌色、细边框、分隔线、色块、表格斑马纹、紧凑标签、tabular numbers、清晰图表标题和口径说明。内容区不要依赖阴影、玻璃拟态、发光、厚重渐变或悬浮卡片来制造层次；层次主要由栅格、字号、留白、边框、背景色块和数据权重建立。
|
|
17
|
+
|
|
18
|
+
布局必须比普通上下堆叠更丰富。先根据数据任务选择版式骨架，再写代码：监控型、复盘型、诊断型、对比型、明细型、汇报型可以有完全不同的扫描路径。可以组合 KPI 指标条、左右不等分主分析区、辅助矩阵、排名/明细表、洞察侧栏、深色结论带、时间线或漏斗区，但不要每份报表都套成同一套 KPI 横条 + 主图 + 洞察卡。不要把每个章节都做成同宽标题加一张满宽卡片；核心模块占更大面积，支撑模块用不同宽度、密度和位置服务它。
|
|
19
|
+
|
|
20
|
+
报表不是产品原型。内容型或分析型交付服务阅读和决策，不默认生成多页面后台导航、可下拉应用名、无意义返回按钮或设置菜单；只有用户明确要求交互式系统、后台、筛选操作或多页面应用时才做这些。标题、范围、口径、结论、图表、洞察和明细都是可用的信息部件，不是每份报表都必须同时出现的固定章节。
|
|
21
|
+
|
|
22
|
+
不要让页面全是文字，也不要把所有章节都做成同一种"结论 + 指标 + 图表 + 洞察"结构。长材料先判断每段内容在当前报表里的作用：它是在给背景、定义口径、证明结论、展示变化、比较对象、解释异常、列明细，还是提出行动。每段只选择最适合的表达方式，可以是短结论、关键数字、对比、时间顺序、表格、矩阵、引用、图表、注释或截图。重要内容不能被塞进附录或角落；如果一个章节是汇报目标的核心，就给它相称的版面面积和区别于其他章节的版式处理。
|
|
23
|
+
|
|
24
|
+
## 流程
|
|
25
|
+
|
|
26
|
+
按顺序完成这些步骤。不要一上来就写代码。
|
|
27
|
+
|
|
28
|
+
### 1. 需求分析
|
|
29
|
+
|
|
30
|
+
从用户消息中提取报表的上下文：
|
|
31
|
+
|
|
32
|
+
- **产品类型**：数据看板、监控中心、分析报表、BI 面板、经营复盘等。
|
|
33
|
+
- **目标读者**：管理者、运营、销售、分析师、项目成员，或外部客户。
|
|
34
|
+
- **核心诉求**：监控指标、发现趋势、比较对象、解释异常、辅助决策、展示成果。
|
|
35
|
+
- **界面语言与口径**：跟随用户输入语言；指标命名、单位、时间粒度要统一。
|
|
36
|
+
|
|
37
|
+
产出：一句话概括"给谁看、回答什么问题"。
|
|
38
|
+
|
|
39
|
+
### 2. 数据分析
|
|
40
|
+
|
|
41
|
+
审视数据，确认可用的维度和指标：
|
|
42
|
+
|
|
43
|
+
- **字段列表**：名称、类型、示例值、是维度还是指标。
|
|
44
|
+
- **数据规模**：行数、时间跨度、类目数量、缺失值或异常值。
|
|
45
|
+
- **指标口径**：总量、均值、占比、增速、完成率、排名、转化率等。
|
|
46
|
+
- **维度切分**：时间、地区、渠道、产品、团队、状态、用户分组等。
|
|
47
|
+
- **叙事重点**：哪个变化、差异、结构或异常最值得被读者看到。
|
|
48
|
+
|
|
49
|
+
产出：维度-指标清单，以及一句话叙事重点。
|
|
50
|
+
|
|
51
|
+
### 3. 报表规划
|
|
52
|
+
|
|
53
|
+
在写代码之前，先确定报表由哪些组件构成：
|
|
54
|
+
|
|
55
|
+
- **视觉方向**：参考 `frontend-design` 的方法先定主题世界、受众姿态、材料、配色逻辑和视觉签名。例如环境数据可以像研究观测页，销售经营可以像运营战情室，财务/管理指标可以像管理层简报。风格必须服务数据可信度，不要套通用科技蓝或泛白卡。
|
|
56
|
+
- **阅读路径**：先判断读者是要快速扫现状、追异常、看趋势、比较对象、查明细还是读复盘。不同任务对应不同起手式，不要默认都从 KPI 卡开始。
|
|
57
|
+
- **候选部件**：标题 / 范围 / 口径、摘要、KPI、主图表、辅助图表、文字洞察、明细表、时间线、矩阵、截图或注释都只是候选。需要哪个用哪个，不要为了"完整"把它们凑齐。
|
|
58
|
+
- **核心承载**：只给真正承载核心问题的模块更大面积。核心可能是一张趋势图、一张排名表、一段异常解释、一个流程漏斗，也可能是一组明细，不固定。
|
|
59
|
+
- **版式差异**：为不同信息角色安排不同形态，例如紧凑指标条、宽图、窄侧栏、表格区、注释带、对比矩阵或分段背景。避免每个章节都重复同一张满宽白卡。
|
|
60
|
+
- **布局骨架**：明确每个模块的相对面积和扫描路径，例如 `1.2fr 2fr`、`1fr 1.6fr`、`repeat(4,1fr)`、`auto 1fr` 等混合栅格；移动端再自然折叠。
|
|
61
|
+
|
|
62
|
+
组件取舍由读者任务、数据复杂度和材料内容决定。
|
|
63
|
+
|
|
64
|
+
产出：视觉方向与报表结构大纲（哪些组件、各自承载什么信息）。
|
|
65
|
+
|
|
66
|
+
### 4. 图表设计
|
|
67
|
+
|
|
68
|
+
为报表中的每个图表完成选型和视觉编码。此步遵循 charts skill 的规则；若 charts skill 尚未加载，先加载它。
|
|
69
|
+
|
|
70
|
+
产出：每个图表的类型、编码分配、共享色板定义。
|
|
71
|
+
|
|
72
|
+
### 5. 报表组成
|
|
73
|
+
|
|
74
|
+
将所有组件组织成一个连贯页面：
|
|
75
|
+
|
|
76
|
+
- 布局按数据叙事组织，不按"先放所有图再放文字"组织。
|
|
77
|
+
- 顺序跟随读者任务：监控型可以先给状态概览，诊断型可以先给异常和原因链，对比型可以先给对象矩阵，复盘型可以先给时间线，明细型可以先给可查表格。
|
|
78
|
+
- 同一页面内至少使用两种不同的版式关系：例如 KPI 横条 + 左右不等分主图 + 双列洞察 + 表格/结论带。避免所有模块都是同尺寸白卡片上下排列。
|
|
79
|
+
- 内容块采用平面化处理：优先用 `border:1px solid ...`、浅底色、分隔线、色条、编号、标签和表格行背景；内容卡片和图表容器默认不加 `box-shadow`。
|
|
80
|
+
- 图表旁边应有短洞察、口径或排名摘要，不要让图表孤零零占满整行。
|
|
81
|
+
- 文字用于解释图表看不出的原因、口径、异常和行动建议，不重复图表标题。
|
|
82
|
+
- 表格用于精确查数和比较对象，不要把长表伪装成密集柱状图。
|
|
83
|
+
- KPI 用于概览，不要把每个字段都做成指标卡。
|
|
84
|
+
- 没有真实依据时不编造结论；可写"待补充口径"或使用中性描述。
|
|
85
|
+
|
|
86
|
+
产出：完整报表页面。
|
|
87
|
+
|
|
88
|
+
### 6. 自检
|
|
89
|
+
|
|
90
|
+
截图检查结果，验证以下几点：
|
|
91
|
+
|
|
92
|
+
- 报表是否回答了步骤 1 确定的核心问题。
|
|
93
|
+
- 信息层级是否清晰（读者能在 5 秒内抓到主要结论）。
|
|
94
|
+
- 布局是否有明确主次和变化，而不是标题、KPI、图表从上到下机械堆叠。
|
|
95
|
+
- 首屏重点信息是否可读，颜色对比是否足够；深色首屏尤其要检查标题、指标和图例。
|
|
96
|
+
- 是否没有大面积无意义留白、错位、重叠、截断或不同模块视觉重量失衡。
|
|
97
|
+
- 用户点名的图表类型和分析维度是否出现；如果因数据不适合改用其他图表，要在页面中用更合适的表达补足。
|
|
98
|
+
- 内容区是否保持平面化，主要靠边框、色块、分隔线和栅格建立层级，没有滥用阴影、发光或玻璃拟态。
|
|
99
|
+
- 文字洞察是否与图表数据互相支撑。
|
|
100
|
+
- 图表部分是否通过了 charts skill 的自检清单。
|
|
101
|
+
- 口径和单位是否全报表一致。
|
|
102
|
+
|
|
103
|
+
产出：确认或修正。
|
|
@@ -13,6 +13,17 @@ Approach this as the design lead at a small studio known for giving every client
|
|
|
13
13
|
|
|
14
14
|
If the brief does not pin down what the product or subject is, pin it yourself before designing: name one concrete subject, its audience, and the page's single job, and state your choice. If there's any information in your memory about the human's preferences, context about what they're building, or designs you've made before – use that as a hint. The subject's own world, its materials, instruments, artifacts, and vernacular, is where distinctive choices come from. Build with the brief's real content and subject matter throughout.
|
|
15
15
|
|
|
16
|
+
## Visual Direction
|
|
17
|
+
|
|
18
|
+
Before choosing colors or components, decide the direction in your thinking. Fill four slots — each pulled from *this* subject:
|
|
19
|
+
|
|
20
|
+
- **World** — what world does this page belong to? Go to the subject's own: its materials, instruments, artifacts, vernacular.
|
|
21
|
+
- **Materials** — what real surfaces and marks belong to that world? Name the ones from the subject before reaching for a generic one.
|
|
22
|
+
- **Palette** — which colors are semantic or branded, which are neutral supports, and which single accent earns attention?
|
|
23
|
+
- **Signature** — the one device the page is remembered by. Make it something that could only belong to this subject; a signature generic enough to reuse on the next brief is a default, not a choice.
|
|
24
|
+
|
|
25
|
+
Style is not decoration applied after layout. This direction decides typography, spacing, chart treatment, section rhythm, borders, icon style, and which components deserve emphasis.
|
|
26
|
+
|
|
16
27
|
## Design principles
|
|
17
28
|
|
|
18
29
|
For web designs, the hero is a thesis. Open with the most characteristic thing in the subject's world, in whatever form makes sense for it: a headline, an image, an animation, a live demo, an interactive moment. Be deliberate with your choice: a big number with a small label, supporting stats, and a gradient accent is the template answer, only use if that's truly the best option.
|
|
@@ -31,7 +42,7 @@ Consider written content carefully. Often a design brief may not contain real co
|
|
|
31
42
|
|
|
32
43
|
For calibration: AI-generated design right now clusters around three looks: (1) a warm cream background (near #F4F1EA) with a high-contrast serif display and a terracotta accent; (2) a near-black background with a single bright acid-green or vermilion accent; (3) a broadsheet-style layout with hairline rules, zero border-radius, and dense newspaper-like columns. All three are legitimate for some briefs, but they are defaults rather than choices, and they appear regardless of subject. Where the brief pins down a visual direction, follow it exactly — the brief's own words always win, including when it asks for one of these looks. Where it leaves an axis free, don't spend that freedom on one of these defaults. Just like a human designer who's hired, there's often a careful balance between doing what you're good at and taking each project as a chance to experiment and learn.
|
|
33
44
|
|
|
34
|
-
Work in two passes. First, brainstorm a short design plan based on the human's design brief:
|
|
45
|
+
Work in two passes. First, brainstorm a short design plan based on the human's design brief: expand the visual direction above into a compact token system: color, type, layout, and signature. Color: describe the palette as 4–6 named hex values. Type: the typefaces for 2+ roles (a characterful display face that's used with restraint, a complementary body face, and a utility face for captions or data if needed). Layout: a layout concept, using one-sentence prose descriptions and ASCII wireframes to ideate and compare. Signature: the single unique element this page will be remembered by that embodies the brief in an appropriate way.
|
|
35
46
|
|
|
36
47
|
Then review that plan against the brief before building: if any part of it reads like the generic default you would produce for any similar page (work through a similar prompt to see if you arrive somewhere similar) rather than a choice made for this specific brief — revise that part, say what you changed and why. Only after you've confirmed the relative uniqueness of your design plan should you start to write the code, following the revised plan exactly and deriving every color and type decision from it.
|
|
37
48
|
|
|
@@ -1,29 +1,28 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: hi-fi-design
|
|
3
|
-
description:
|
|
3
|
+
description: 用于创建高保真 UI mockup、设计探索，或带多种变体的视觉原型。触发词：mockup, hi-fi, prototype, UI design, 高保真, 设计稿, 原型, 界面设计, 视觉设计, 设计方案
|
|
4
4
|
available-agents:
|
|
5
5
|
- CreativeDesign
|
|
6
6
|
---
|
|
7
7
|
|
|
8
|
-
#
|
|
8
|
+
# 高保真设计
|
|
9
9
|
|
|
10
|
-
|
|
10
|
+
创建高保真、精细打磨的设计。
|
|
11
11
|
|
|
12
|
-
|
|
13
|
-
1.
|
|
14
|
-
2.
|
|
15
|
-
3.
|
|
16
|
-
4.
|
|
17
|
-
5.
|
|
12
|
+
遵循以下通用设计流程（用 todo list 记住）：
|
|
13
|
+
1. 澄清关键信息：能从需求、附件、截图或常见模式合理推断的，直接继续；只在关键信息缺失且会影响设计方向时才向用户提问
|
|
14
|
+
2. 查找现有 UI kit 并收集设计上下文——复制所有相关组件，阅读所有相关示例；如果找不到且会影响核心设计方向，再向用户询问
|
|
15
|
+
3. 在文件开头写下假设、上下文和设计推理（把自己当作初级设计师，用户是你的主管），放好设计占位，并尽早展示给用户
|
|
16
|
+
4. 尽快把设计做出来，再次展示给用户，并附上下一步建议
|
|
17
|
+
5. 使用工具检查、验证并迭代设计
|
|
18
18
|
|
|
19
|
-
|
|
19
|
+
好的高保真设计不会从零开始——它们扎根于已有的设计上下文。找到合适的 UI kit / 设计资源，或从截图、代码和品牌资产中提取设计规则。你必须花时间去获取设计上下文，包括组件。如果缺少素材但不影响核心方向，先用合理假设继续推进；只有缺失信息会改变设计方向时才向用户索要。从零 mock 一个完整产品是最后手段，会导致低质量的设计。使用 starter components（设备框架等）可以免费获得高质量的脚手架。
|
|
20
20
|
|
|
21
|
-
|
|
21
|
+
当并排展示多个方案或探索方向时，布局要清晰：给页面一个中性灰背景，把每个方案放进独立且带标签的框中（小标题 + 尺寸随内容变化的白色圆角卡片），并把相关方案分组。
|
|
22
22
|
|
|
23
|
-
|
|
23
|
+
设计时，提出好问题很重要——但只在问题会实质性影响设计方向时才提问，避免频繁打断用户。
|
|
24
24
|
|
|
25
|
-
|
|
25
|
+
给出选项：尽量围绕多个维度提供 3 个以上变体。把符合既有模式的稳妥方案，与新颖的交互方式混合搭配，包括有趣的布局、隐喻和视觉风格。部分方案使用色彩或高级 CSS，部分带图标，部分不带。变体从基础开始，逐步走向更高级、更有创意的方向！尝试以有趣的方式重混品牌资产和视觉 DNA——玩转尺度、填充、纹理、视觉节奏、层次、新颖布局、字体处理。目标不是找到完美方案，而是探索用户可以混搭组合的原子级变体。
|
|
26
26
|
|
|
27
|
-
CSS
|
|
27
|
+
CSS、HTML、JS 和 SVG 能力强大。用户往往不知道它们能做到什么。给用户惊喜。
|
|
28
28
|
|
|
29
|
-
If you do not have an icon, asset or component, draw a placeholder: in hi-fi design, a placeholder is better than a bad attempt at the real thing.
|
|
@@ -1,64 +1,125 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: make-a-deck
|
|
3
|
-
description:
|
|
3
|
+
description: 制作演示文稿 / PPT / pitch deck / slides / keynote。从零新建、从文档材料提炼重组、或对已有 PPTX 重新设计。触发词：presentation, slides, deck, PPT, PPTX, keynote, pitch, 演示文稿, 幻灯片, 路演
|
|
4
4
|
available-agents:
|
|
5
5
|
- CreativeDesign
|
|
6
6
|
---
|
|
7
7
|
|
|
8
|
-
#
|
|
8
|
+
# 制作演示文稿（deck）
|
|
9
9
|
|
|
10
|
-
|
|
10
|
+
把演示文稿做成单个自包含的 HTML 页面。HTML 是输出载体，但设计判断按 PPT 来做：固定画幅、强叙事、可投影 / 可异步阅读、每页只承担一个清楚的沟通任务。
|
|
11
11
|
|
|
12
|
-
|
|
12
|
+
把自己当成演示文稿设计师，不是网页开发者：像顾问、分析师、高管准备董事会材料那样思考——清晰、叙事流、后排可读。每一页都同时是版式设计和文案写作。开始落 HTML 前，先写大纲；好的大纲本身就是一次叙事结构训练。
|
|
13
13
|
|
|
14
|
-
|
|
14
|
+
## 信息密度
|
|
15
15
|
|
|
16
|
-
|
|
17
|
-
If the user does not tell you the visual aesthetic they want, use the `ask_user_question` tool to ASK what they want. Don't just provide a generic design!
|
|
16
|
+
选一种密度，不要停在模糊的中间态：
|
|
18
17
|
|
|
19
|
-
|
|
18
|
+
| 模式 | 场景 | 做法 |
|
|
19
|
+
| --- | --- | --- |
|
|
20
|
+
| 演讲型 / 低密度 | 发布会、公开演讲、keynote、现场 pitch | 一页一个观点，大标题强视觉、留白足、要点 1-3 条，必要时增加页数 |
|
|
21
|
+
| 阅读型 / 高密度 | 内部汇报、评审、复盘、异步传阅 | 每页更自洽，可用表格 / 结构卡片 / 注释 / 图表，但层级要明确 |
|
|
20
22
|
|
|
21
|
-
|
|
23
|
+
无论哪种，都不要让页面滚动、溢出、重叠或用过小字体；放不下就拆页。**不要把整份文档直接贴进幻灯片**——这是最常见的失败模式。落 plan 时就想清楚：哪些内容更适合做成表格、图表、流程、引用页或图片页。
|
|
22
24
|
|
|
23
|
-
|
|
25
|
+
## 叙事与标题
|
|
24
26
|
|
|
25
|
-
|
|
27
|
+
- 先写完整标题序列放进 `scratchpad.md`。只读标题就应能看懂整份 deck 的逻辑（像书的目录）。检查是否形成清楚路径：背景 → 问题 → 洞察 → 方案 → 证据 → 下一步。
|
|
28
|
+
- 选定一种标题语法并全程一致：要么名词短语（"市场机会""产品架构"），要么简短判断句（"新用户增长主要来自自然流量"）。
|
|
29
|
+
- 每页正文只服务本页标题，不塞旁支。封面、章节页、转场页、结尾页也要服务故事，不做纯装饰。
|
|
26
30
|
|
|
27
|
-
|
|
31
|
+
避免这些"AI 味"标题（它们会暴露 deck 是 AI 生成的）——标题的任务是**定位页面、推进叙事**，不是替演讲者甩结论 / 喊 punchline：
|
|
28
32
|
|
|
29
|
-
|
|
33
|
+
- "不是 X，而是 Y"式过度反转。
|
|
34
|
+
- "关键时刻""魔法时刻"式空泛或故作深刻。
|
|
35
|
+
- 过度夸张的行动号召、为制造张力而制造张力。
|
|
36
|
+
- 每页固定一个 takeaway 盒子，导致标题和正文重复。
|
|
30
37
|
|
|
31
|
-
|
|
38
|
+
## 页面类型与节奏
|
|
32
39
|
|
|
33
|
-
|
|
40
|
+
写第一页前先做 page-type map：为每页标注页型、叙事作用和需要承载的素材。避免所有页面都变成"标题 + 三栏卡片"。
|
|
34
41
|
|
|
35
|
-
|
|
42
|
+
常用页型包括：
|
|
36
43
|
|
|
37
|
-
|
|
44
|
+
- 封面 / 目录 / 使用说明：建立主题、范围、读法和关键承诺。
|
|
45
|
+
- 章节分隔页：承载章节编号、主题、过渡判断或下一段问题，不做纯装饰页。
|
|
46
|
+
- 观点 / 结论页：一句话 thesis + 1-3 个证据或影响。
|
|
47
|
+
- 数据 / 指标页：KPI strip、图表或表格、口径 / 来源、短结论必须在同屏闭环。
|
|
48
|
+
- 对比 / 选项页：A/B/多方案使用稳定代号、颜色和评价维度，贯穿方案封面、详情、排期和最终建议。
|
|
49
|
+
- 流程 / 日程 / 预算 / 清单页：优先用表格、矩阵、时间轴、泳道或 checklist，不要把结构化信息改写成散文卡片。
|
|
50
|
+
- 教学 / 练习页：保持稳定 scaffold，例如"编号 / 题型 / 进度 + 题干 + 条件 / 选项 + 答案 / 考点 / 易错点"。
|
|
51
|
+
- 叙事 / 案例页：可以使用 prologue、chapter、turning point、proof、epilogue 等章节节拍，让情绪和判断同步推进。
|
|
38
52
|
|
|
39
|
-
|
|
53
|
+
每 3-5 页安排一次节奏变化：章节页、全屏观点页、数据页、对比页、表格页、案例页之间轮换。同层级的并列内容（成组案例、系列练习、多个方案）保持同一 scaffold，利于跨页比较——此时节奏变化靠在块之间插入章节页或小结页，而不是改动系列内页面的版式。不要把叙事功能不同的页面压平成同一个版式。变化来自页型和信息结构，不靠堆装饰。
|
|
40
54
|
|
|
41
|
-
|
|
55
|
+
## 内容组织与版式策略
|
|
56
|
+
deck 每页先判断它要让观众完成什么阅读动作：抓结论、看证据、比较差异、理解过程、记住模型、看到风险、做选择，还是进入下一章节。版式、文字、图形和动效都只是表达手段，选择最能讲清这一页的组合。
|
|
57
|
+
- 根据当前页内容现场生成结构，不局限于常见页型。可以保留强文字页，也可以把材料转成模型图、关系图、流程、对比矩阵、时间线、象限、分层结构、地图、系统图、路径图、图表注释、截图标注或视觉隐喻；还可以把重要句子放大成观点页。示例只是启发，不是清单。
|
|
58
|
+
- 同一章节内可以有连续叙事，但每页的结构不必一样。核心页给足面积和视觉重量，支撑页可以更密集；重要概念可以用图形和标注解释，也可以用排版、引用、数字、对照文本或图文组合解释。
|
|
59
|
+
- 单页可以承载“小型演示过程”：先出现结论，再让支撑内容逐步显现，最后高亮关键判断。支撑内容可以是文字、数字、图形、数据、截图或关系结构；是否使用动效由表达目的决定。
|
|
60
|
+
- 如果一页只有少量概念，不要机械铺成几张卡片。先判断概念之间有没有关系：并列、递进、因果、闭环、漏斗、分层、坐标、路径、前后对比或组合模型。关系明确时可以画出来；关系不明确时，可以改成更有力量的文字观点页、引用页，或合并到相邻页。
|
|
61
|
+
- 版式变化来自内容关系，不来自凑组件。不要为了“丰富”而加无依据内容、无意义图标或装饰图形；图形、图片和动效只有在能帮助观众理解时才使用。
|
|
42
62
|
|
|
43
|
-
|
|
44
|
-
There are generally a few types of title structures that are used in slide decks:
|
|
45
|
-
- Short textbook-title-style, all capitalized (e.g., Market Research, Engagement Overview, Team Structure)
|
|
46
|
-
- Action titles, which are more like short phrases (e.g., “Asia is our largest market….”, “...but Eastern Europe has the highest potential for growth”)
|
|
47
|
-
Pick the appropriate title structure and stick with it.
|
|
63
|
+
## 版式系统（写第一页前先定）
|
|
48
64
|
|
|
49
|
-
|
|
50
|
-
|
|
51
|
-
|
|
52
|
-
-
|
|
65
|
+
- 用 CSS 变量定义字号 / 间距，放在 `<head>` 的 `<style>` 里，**先于任何 slide**。这让整份 deck 改一个数（直接改变量，或用 Tweaks 滑块绑同一变量）就能统一缩放，slide 本体保持无脚本的静态 HTML。1920×1080 起点：
|
|
66
|
+
```css
|
|
67
|
+
:root {
|
|
68
|
+
--type-title: 64px; --type-subtitle: 44px; --type-body: 34px; --type-small: 28px;
|
|
69
|
+
--pad-top: 100px; --pad-bottom: 80px; --pad-x: 100px;
|
|
70
|
+
--gap-title: 52px; --gap-item: 28px;
|
|
71
|
+
}
|
|
72
|
+
```
|
|
73
|
+
1280×720 时整体 ×0.67。每个 font-size 都用 `--type-*`，每个 padding / gap 都用 `--pad-*` / `--gap-*`。`--pad-bottom` 是结构性的底部呼吸空间，不是空白。
|
|
74
|
+
- 网页默认（14-16px 正文、48-72px 边距）对投影太小。标题 ≥ 48px，正文 / 注释**不得小于 24px**（验证器会对 < 24px 抛错）。用户说字号一般指 pt，按 PowerPoint / Keynote 换算：`px = pt × 1.333`（"标题 36pt" → CSS 设 ~48px）。
|
|
75
|
+
- 规划页面类型：封面、章节页、观点页、数据页、对比页、流程页、图片页、结束页各有稳定样式。同类页面的标题位置、页码、章节名、脚注、来源、关键数字、图片位置要**平行对齐**，方便观众跨页比较。
|
|
76
|
+
- 为每种页型固定布局锚点：标题、章节号、页码、来源、图表、主视觉和关键数字的位置不要随机漂移。相同页型要像同一个系统，不同页型再负责制造节奏。
|
|
53
77
|
|
|
54
|
-
|
|
78
|
+
## 视觉设计
|
|
55
79
|
|
|
56
|
-
|
|
80
|
+
视觉服务演示场景，不是网页首页。
|
|
57
81
|
|
|
58
|
-
|
|
59
|
-
|
|
60
|
-
|
|
61
|
-
|
|
82
|
+
- **明暗按需求选择**：根据品牌 / 主题 / 图片素材 / 演示场景选择浅色、暗色或混合背景。无论选择哪种，都要保证投影、截图和后排阅读的对比度。明暗切换应落在叙事节点上（章节转换、关键强调），不要无来由地跳变。
|
|
83
|
+
- 字体克制（1-2 套）：展示字体可有个性，正文必须稳定可读；整体对比清楚、信息块边界明确。
|
|
84
|
+
- 图片先判断内容和用途：摄影 / 氛围图可满版裁切；截图、图表、产品界面、架构图必须完整展示（aspect-fit），不能裁掉关键边界或文字；透明图 / 细线图放到有对比的底色上。图上压字用品牌常见方式保护可读性（遮罩、渐变、模糊或文字容器）。
|
|
85
|
+
- 视觉要有节奏变化：全图页、大数字页、表格页、引用页、流程页、文字页交替出现；不要整套都是同一种卡片。也不要每页硬加描边卡片、固定结论框或装饰分割线——只有内容需要分组时才用容器。
|
|
86
|
+
- 扁平基线：好的 deck 不依赖阴影和悬浮卡片堆叠。优先用全页背景、色带、分隔线、编号、表格网格、图片裁切、对比色块和尺度差建立层次。只有在需要表达真实物件、票券、照片或舞台层次时才少量使用阴影。
|
|
87
|
+
- 不用 emoji、不临时手绘复杂假图；优先用用户素材、品牌资产、图标库或真实图片。
|
|
88
|
+
- **空间重心**：内容集中在上方 2/3、底部留白，通常是**正确**的 slide 构图。看到 `align-items: flex-start` 加底部留空就想改成 `center`——那是网页设计的条件反射，忍住，留白是有意的。但留白有下界：内容页的主内容应占版心高度约 2/3 以上，撑不满就升格版式——放大成大数字、大卡片，或重排为居中的宣言页，而不是把原内容原样居中或任其悬浮在顶部。空本身不是缺陷，不均才是：同一页一处大空、一处拥挤，要重排。双栏页两列视觉重量要对等，悬殊时改 7:5 / 8:4 不对称栅格或并回单栏。
|
|
62
89
|
|
|
63
|
-
|
|
64
|
-
|
|
90
|
+
## HTML 实现（deck-stage 外壳）
|
|
91
|
+
|
|
92
|
+
- **不要手写 stage / 缩放 / 导航 / 页码**。先调用 `copy_starter_component`，`kind: "deck-stage.js"`（连字符、含扩展名，照抄；传裸名字或错扩展名会失败）。用普通 `<script src="deck-stage.js"></script>` 引入（vanilla JS，不是 JSX）。
|
|
93
|
+
- 用 `<deck-stage width="1920" height="1080">` 包住所有 slide，每页一个 `<section data-label="…">` 子元素。deck-stage 负责等比缩放、键盘 / 点击 / 翻页导航、页数与导航条、speaker-notes 的 postMessage，以及打印成 PDF（一页一张）。
|
|
94
|
+
- deck-stage 会**自动**按位置生成 `data-screen-label` 并注入 `data-miaoda-validate`——你只需给每页写 `data-label`（人类可读的页名），不用手写另两个。
|
|
95
|
+
- `data-label` 使用可读页名或章节名，例如"30秒结论""A方案日程""数据·增长产出"，不要写成无语义的 `slide-1`。
|
|
96
|
+
- **不要**在 slide `<section>` 上自行设置 position / inset / width / height——deck-stage 会绝对定位每个子元素。
|
|
97
|
+
- 演讲者备注写在全局 `<script type="application/json" id="speaker-notes">`（置于 `<deck-stage>` 之外），内容是一个**按页顺序排列的扁平字符串数组**——第 N 个元素就是第 N 个 `<section>` 的备注（含封面，从 0 起按位置对齐）；某页没有备注也要用空串 `""` 占位，让数组长度始终等于页数。随翻页 postMessage 给宿主。
|
|
98
|
+
```html
|
|
99
|
+
<script type="application/json" id="speaker-notes">
|
|
100
|
+
["首页开场白…", "", "第 3 页的讲解要点…"]
|
|
101
|
+
</script>
|
|
102
|
+
```
|
|
103
|
+
|
|
104
|
+
### slide 正文写成静态 HTML，不要用脚本生成
|
|
105
|
+
|
|
106
|
+
这条最影响用户体验，理解**为什么**再执行：当一页正文是 `<deck-stage>` 里的普通静态标记时，用户在编辑态点任意标题 / 段落就能直接改字，编辑器会把改动即时 splice 回源文件；一旦这页由 `<script type="text/babel">`、React 组件或"遍历 JS 数组"渲染，这条直改路径就断了——每次微调都要通过 chat message 往返到你这里，更慢、也更难让用户自己打磨 deck。所以凡是静态页能表达的（文字、布局、背景、图片、表格），就把字面元素写进 HTML、用 CSS 定样式；只有当这页**真的**需要静态标记给不了的行为（交互图表、真实 demo、真实状态）才引入 babel / React 或额外 `<script>`。同样的渲染结果，静态版永远优先，因为它可直接编辑。
|
|
107
|
+
|
|
108
|
+
两个细节保住"可直接编辑"：
|
|
109
|
+
|
|
110
|
+
- 每段可编辑文字放在自己的叶子节点里——把"Revenue"放进 `<h2>` 内它自己的 `<span>`，别写成 `<h2>Revenue <span class="sub">2025</span></h2>` 这种文本和子元素混在同一父节点。
|
|
111
|
+
- 重复结构写出来、不要生成——三条 bullet 就写三个 `<li>`，不要用数组渲染一个 `<li>` 三次。重复正是重点：它让用户改第二条时不碰第一条。
|
|
112
|
+
- 例外：`tweaks-panel.jsx` 是挨着 slide 的控制面板、不是 slide 正文，可以用 `<script type="text/babel">`；它不影响各静态 slide 各自走直改路径。
|
|
113
|
+
|
|
114
|
+
## 交付前自检
|
|
115
|
+
|
|
116
|
+
- 每页 16:9，无溢出 / 重叠 / 裁切；字号符合投影阅读（正文没有小到像网页）。
|
|
117
|
+
- 留白均匀：同一页没有一处大空、一处拥挤；内容页主内容占版心高度约 2/3 以上；双栏视觉重量对等。
|
|
118
|
+
- 只读标题能讲通故事；标题语法全程一致，没有 punchline / takeaway 盒子。
|
|
119
|
+
- 已建立 page-type map，并通过页型轮换避免单一上下布局。
|
|
120
|
+
- 章节分隔页推动叙事，而不是只做装饰。
|
|
121
|
+
- 演讲型页面没堆太多字；阅读型页面没变成文档截图。
|
|
122
|
+
- 同类页面布局、标题位置、页码、章节标识平行一致；图片没被不合理拉伸，截图 / 图表完整展示。
|
|
123
|
+
- 多方案、教学练习、叙事案例、数据汇报等特定场景使用了稳定 scaffold。
|
|
124
|
+
- slide 正文是静态可编辑 HTML，没用脚本循环生成；`data-label`、speaker-notes、打印分页完整。
|
|
125
|
+
- deck-stage 外壳、导航、页码来自 starter component，没有手写重复实现。
|
|
@@ -0,0 +1,78 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: visual-exposure
|
|
3
|
+
description: 用于制作可视化报告、专题视觉页、信息图、视觉长图、概念可视化、产品能力曝光、方案亮点展示等内容型 HTML 视觉作品。适合用户想把材料、数据或观点组织成可阅读、可展示、可传播的视觉化表达，但不希望做成 PPT、传统 dashboard 或纯 ECharts 图表的场景。触发词：可视化报告, 视觉报告, 可视化曝光, 视觉化曝光, 信息图, 长图, infographic, 视觉表达, 概念可视化, 亮点展示, 能力曝光
|
|
4
|
+
available-agents:
|
|
5
|
+
- CreativeDesign
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
# 可视化报告与专题表达
|
|
9
|
+
|
|
10
|
+
创建内容驱动的 HTML 视觉作品。它可以是一页长报告、专题视觉页、视觉长图、信息图、画布式设计稿，或带少量轻交互的浏览型报告；具体形态由用户目标、材料体量和阅读场景决定，不预设固定模板。
|
|
11
|
+
|
|
12
|
+
## 工作方式
|
|
13
|
+
|
|
14
|
+
1. 先读用户材料，提取主题、受众、阅读场景、核心结论、必须出现的事实和可省略的细节。
|
|
15
|
+
2. 判断报告目的：汇报、解释、披露、说服、传播、留档，还是做视觉方向探索。
|
|
16
|
+
3. 选择交付形态：长页报告、专题页、视觉长图、单屏摘要、画布式多方案、图文混排报告、偏打印感的正式报告等。不要把所有需求压成同一种版式。
|
|
17
|
+
4. 按材料逻辑组织内容，而不是套固定目录、固定模块或固定视觉模板。参考样式只能启发表达方式，不能替代对当前材料的判断。
|
|
18
|
+
5. 把材料拆成具体阅读任务：这一段要让读者完成什么判断、理解什么关系、记住什么事实、比较什么差异、追踪什么过程、相信什么证据。不要把这些任务名直接变成目录或模块标题。
|
|
19
|
+
6. 为每个阅读任务现场生成合适的组件、视觉和布局：先说明这段内容需要什么表达方式，再落成具体 UI / 图形 / 排版 / 图表 / 截图 / 文字组合。可以创造新的结构和视觉隐喻，不受现有组件名限制；避免所有章节共享同一套组件组合。
|
|
20
|
+
7. 先写风格 brief：主题隐喻、受众姿态、材料语言、配色逻辑和视觉签名。财务报告可以像正式报告册，员工调研可以像组织研究档案，产品上市总结可以像品牌战报；这些只是启发，必须从用户材料里推导。
|
|
21
|
+
8. 建立版式系统：画幅、栅格、字号层级、颜色、图标/线条语言、强调方式和章节节奏。版式系统必须说明不同章节如何变化，而不是所有章节都用同一种上下结构。
|
|
22
|
+
9. 产出单个 HTML 文档。用户需求明确时直接做；只有主题、素材或交付形态完全无法判断时，才问少量必要问题。
|
|
23
|
+
|
|
24
|
+
## 内容组织
|
|
25
|
+
|
|
26
|
+
本 skill 中出现的报告形态、表达方式、组件和版式都只是示意，不是必须参考的清单。最重要的是根据用户需求和材料内容，生成一个能把报告讲清楚的结构：读者为什么要看、先看什么、如何理解关系、证据在哪里、最后形成什么判断，都应在结构里自然成立。
|
|
27
|
+
|
|
28
|
+
可视化报告不是把图表排满，也不是把文字切成很多卡片。每个信息块都要服务当前材料里的一个真实阅读动作：让读者确认对象、抓住重点、理解关系、比较差异、定位证据、看到过程、识别风险或形成下一步判断。把这些阅读动作翻译成本次需求专属的视觉结构，而不是复用固定模块名。
|
|
29
|
+
|
|
30
|
+
允许为当前需求重新发明表达结构：可以合并、拆分、放大、弱化、横向展开、纵向叙事、图文化、表格化、截图化或做成完全不同的布局。只要它能更清楚地解释报告内容，就优先于任何示例组件或常见版式。
|
|
31
|
+
|
|
32
|
+
如果材料很长，先压缩成报告叙事，不要把原文完整铺上去。需要精确查数时使用表格或附录；需要快速传播时使用摘要和视觉重点；需要正式汇报时保留章节编号、图表标题和口径说明。
|
|
33
|
+
|
|
34
|
+
不要把关键内容压成角落里的附录片段。用户明确要求展示的部分，应按报告目标给足版面权重，并选择合适的信息结构承载。
|
|
35
|
+
|
|
36
|
+
## 版式策略
|
|
37
|
+
|
|
38
|
+
可视化报告要像一份经过编辑设计的专题，而不是由同款卡片拼起来的长页面。先决定阅读节奏，再落组件：
|
|
39
|
+
|
|
40
|
+
- 根据材料的展开方式设计版式：它可能需要连续叙事、密集证据、空间关系、过程推进、对照判断、沉浸式主视觉、正式报告册，或完全不同的结构。先为当前需求命名一个版式概念，再确定栅格、密度、视觉重心和章节变化。
|
|
41
|
+
- 版式变化来自内容关系，不来自凑组件。关键段落可以被放大、拆页、满版化、图文化或变成精确表格；次要段落可以压缩、并列、收进注释或弱化。
|
|
42
|
+
- 每个章节的结构可以不同，但要属于同一套视觉系统。变化要能解释：为什么这里适合宽图、那里适合密集表格、另一处适合分段叙事。
|
|
43
|
+
|
|
44
|
+
不要为了“丰富”而乱放装饰。变化应该来自内容关系和阅读任务，而不是从组件清单里凑满页面。
|
|
45
|
+
|
|
46
|
+
## 视觉原则
|
|
47
|
+
|
|
48
|
+
- 优先清楚，其次好看。读者应该先理解结构，再感受到风格。
|
|
49
|
+
- 明暗主题由需求、品牌、素材、受众和阅读场景决定；浅色、暗色、中性或局部深色都可以。选择后要保证对比度、可读性和信息层级，并能解释为什么适合当前主题。
|
|
50
|
+
- 默认平面化处理：内容区优先使用细边框、分隔线、浅底色、色块、表格斑马纹、编号和标签建立层级；不要给章节、卡片、图表容器加各种 `box-shadow`。
|
|
51
|
+
- 少用装饰性渐变、发光、玻璃拟态。视觉效果要帮助分组、强调或引导视线。
|
|
52
|
+
- 风格跟随内容、受众和品牌：可以正式、温和、技术、编辑化、品牌化或实验感，但不要从某个样例场景继承固定颜色、固定目录或固定组件。
|
|
53
|
+
- 每份报告应有一个可解释的视觉签名。视觉签名要从用户主题、材料质感和阅读任务中生成，而不是复用固定手法；它可以是任何能组织内容、建立记忆点并保持一致性的视觉规则。
|
|
54
|
+
- 真实素材优先：用户给的截图、logo、图片、图标、数据片段要优先使用。没有素材时，用清楚的占位结构和可替换文案。
|
|
55
|
+
- 允许少量动效，但只用于进入、强调或引导阅读，不做干扰理解的持续动画。
|
|
56
|
+
- 可以包含数字、图表和表格，但它们服务于报告叙事；不要为了“可视化”而把所有内容都做成图。
|
|
57
|
+
- 深色区域可以用于封面、结论、行动区或整篇报告的主视觉；只要它服务主题气质和阅读体验，而不是作为无依据的装饰。
|
|
58
|
+
|
|
59
|
+
## 画布与交付
|
|
60
|
+
|
|
61
|
+
- 多方案、设计稿、方向探索：使用 `design-canvas.jsx`，每个方向一个 `<DCArtboard>`。
|
|
62
|
+
- 单一可视化报告、视觉长图或专题视觉稿：做成完整 HTML 页面，保持明确画幅、节奏和层级。
|
|
63
|
+
- 如果用户要“设计稿”，优先走画布式交付；如果用户要“可直接展示/传播”，可以做成完整页面式视觉作品。
|
|
64
|
+
- 所有文字应直接写在 HTML 中，便于用户后续编辑。
|
|
65
|
+
|
|
66
|
+
## 检查清单
|
|
67
|
+
|
|
68
|
+
- 交付形态匹配用户需求：长页报告、专题页、长图、画布设计稿或单屏摘要，而不是被固定模板绑住。
|
|
69
|
+
- 当前需求的主题、边界和最重要信息在第一屏或开篇清楚可见。
|
|
70
|
+
- 章节顺序跟随材料逻辑，不按评测集样例或预设场景套目录。
|
|
71
|
+
- 章节版式有节奏变化，并且变化来自材料关系；没有一路同款上下卡片，也没有因为预设组件清单而硬凑结构。
|
|
72
|
+
- 没有大面积空白、错位、低对比、文字不可读或模块之间风格突兀。
|
|
73
|
+
- 内容区保持平面化，没有滥用阴影、发光、玻璃拟态或厚重悬浮效果。
|
|
74
|
+
- 所有表达载体各司其职，没有为了数据而堆图，也没有用空泛文字或预设组件填空间。
|
|
75
|
+
- 文字密度可读，没有小字堆叠。
|
|
76
|
+
- 图标、线条、颜色和卡片样式属于同一套视觉语言。
|
|
77
|
+
- 明暗选择能解释为什么适合这个主题；无论浅色还是暗色，都保证长文、图表和表格可读。
|
|
78
|
+
- 事实性内容没有编造；不确定内容用中性描述或占位说明。
|