@lark-apaas/coding-steering 0.1.19-alpha.20260717102041 → 0.1.19
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 +4 -2
- package/steering/design-html/skills/charts/SKILL.md +4 -2
- package/steering/design-html/skills/data-report/SKILL.md +4 -2
- package/steering/design-html/skills/frontend-design/SKILL.md +36 -34
- package/steering/design-html/skills/hi-fi-design/SKILL.md +4 -2
- package/steering/design-html/skills/interactive-prototype/SKILL.md +4 -2
- package/steering/design-html/skills/make-a-deck/SKILL.md +20 -23
- package/steering/design-html/skills/visual-exposure/SKILL.md +4 -2
- package/steering/design-html/skills/wireframe/SKILL.md +7 -5
package/package.json
CHANGED
|
@@ -1,8 +1,10 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: animated-video
|
|
3
3
|
description: Use when creating animated videos, motion graphics, product walkthroughs, or visual storytelling with timeline-based playback. 触发词:animation, video, motion, 动画, 视频, 动效, 产品演示, 演示动画, walkthrough
|
|
4
|
-
|
|
5
|
-
-
|
|
4
|
+
metadata:
|
|
5
|
+
display-names:
|
|
6
|
+
zh-CN: 动画视频
|
|
7
|
+
en-US: Animated Video
|
|
6
8
|
---
|
|
7
9
|
|
|
8
10
|
# Animated video
|
|
@@ -1,8 +1,10 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: charts
|
|
3
3
|
description: "基于 ECharts 的数据可视化,用于浏览器直出 HTML。当需要创建图表、仪表盘或数据可视化时使用。触发词:chart, ECharts, 图表, 可视化, visualization, 饼图, 柱状图, 折线图, 数据图表, 甘特图, 热力图, 数据展示, dashboard, 仪表盘, 数据看板"
|
|
4
|
-
|
|
5
|
-
-
|
|
4
|
+
metadata:
|
|
5
|
+
display-names:
|
|
6
|
+
zh-CN: 图表
|
|
7
|
+
en-US: Charts
|
|
6
8
|
---
|
|
7
9
|
|
|
8
10
|
# 图表
|
|
@@ -1,8 +1,10 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: data-report
|
|
3
3
|
description: "数据驱动的报表与看板设计。从数据分析到报表规划、信息层级组织,适用于用户有数据文件或明确指标,需要产出结构化数据报表的场景。图表绘制部分由 charts skill 承担。触发词:数据报表, 数据看板, 数据分析报表, BI, 经营报表, 指标看板, 周报, 月报, 数据大盘, KPI, 报表设计, data report, dashboard report, analytics report"
|
|
4
|
-
|
|
5
|
-
-
|
|
4
|
+
metadata:
|
|
5
|
+
display-names:
|
|
6
|
+
zh-CN: 数据看板
|
|
7
|
+
en-US: Data Dashboard
|
|
6
8
|
---
|
|
7
9
|
|
|
8
10
|
# 数据报表
|
|
@@ -1,67 +1,69 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: frontend-design
|
|
3
|
-
description:
|
|
4
|
-
|
|
5
|
-
-
|
|
3
|
+
description: 为设计确立独特、有意图的视觉方向的指引——配色、字体与美学选择不带模板化默认的痕迹。适用于各类媒介(deck、报告、UI、原型),不限于 Web UI。
|
|
4
|
+
metadata:
|
|
5
|
+
display-names:
|
|
6
|
+
zh-CN: 创意设计
|
|
7
|
+
en-US: Creative Design
|
|
6
8
|
---
|
|
7
9
|
|
|
8
10
|
# Frontend Design
|
|
9
11
|
|
|
10
|
-
|
|
12
|
+
以一家小型设计工作室的设计主管身份来做这件事——这家工作室以让每位客户拥有绝不会被认错的视觉形象而闻名。这位客户已经否掉过几版感觉模板化的提案,他们付费买的是一个鲜明的观点:针对这份 brief 做出深思熟虑、有主张的配色、字体与版式选择,并承担一次你能说清理由的真正的美学冒险。
|
|
11
13
|
|
|
12
|
-
##
|
|
14
|
+
## 让设计扎根于主题
|
|
13
15
|
|
|
14
|
-
|
|
16
|
+
如果 brief 没有钉死产品或主题是什么,动手设计前先自己钉死:点出一个具体的主题、它的受众、这个页面唯一要完成的任务,并明确说出你的选择。如果你的记忆里有关于用户偏好的信息、关于他们正在构建什么的上下文、或你以往做过的设计——把它们当作线索用起来。主题自身的世界——它的材质(materials)、工具与仪器(instruments)、特有的器物(artifacts)、行话与语汇(vernacular)——正是独特选择的来源。全程用 brief 的真实内容与题材来构建。
|
|
15
17
|
|
|
16
|
-
##
|
|
18
|
+
## 视觉方向
|
|
17
19
|
|
|
18
|
-
|
|
20
|
+
在选定颜色或组件之前,先在思考中定下方向。填满四个槽位——每一个都要取自*这个*主题:
|
|
19
21
|
|
|
20
|
-
-
|
|
21
|
-
-
|
|
22
|
-
-
|
|
23
|
-
-
|
|
22
|
+
- **世界(World)**——这个页面属于哪个世界?去主题自己的世界里找:它的材质、工具与仪器、特有的器物、行话与语汇。
|
|
23
|
+
- **材质(Materials)**——哪些真实存在的材质表面(surfaces)与印记(marks)属于那个世界?先把主题自带的一一列出来,别一上来就用通用的。
|
|
24
|
+
- **配色(Palette)**——哪些颜色承担语义或品牌职责,哪些是中性的支撑色,哪一个唯一的强调色赢得注意力?
|
|
25
|
+
- **签名元素(Signature)**——整个页面靠它被记住的那一个手法。它必须只可能属于这个主题;一个换到下份 brief 也能复用的签名元素,是默认值,不是选择。
|
|
24
26
|
|
|
25
|
-
|
|
27
|
+
风格不是版式排完后再涂上去的装饰。这个方向决定字体排印、间距、图表处理、章节节奏、边框、图标风格,以及哪些组件值得强调。
|
|
26
28
|
|
|
27
|
-
##
|
|
29
|
+
## 设计原则
|
|
28
30
|
|
|
29
|
-
|
|
31
|
+
对于网页设计,hero 区就是全页的论点。开场就亮出主题世界里最具特征的东西,形式因主题而定:一句大标题、一张图、一段动画、一个实时 demo、一个交互瞬间。选择要经过深思:「大数字 + 小标签 + 辅助统计数据 + 渐变点缀」是模板答案,只有当它确实是最佳选项时才用。
|
|
30
32
|
|
|
31
|
-
|
|
33
|
+
字体排印承载页面的性格。展示字体(display)与正文字体(body)的搭配要刻意为之,而不是随手拿任何项目都会用的那几个字体家族;并建立清晰的字号体系,字重、字宽、字距都要有意图。让字体处理本身成为设计中令人记住的一部分,而不是承载内容的中性载体。
|
|
32
34
|
|
|
33
|
-
|
|
35
|
+
结构即信息。结构件——编号、眉标、分隔线、标签——应当编码内容中真实存在的信息,而不是装饰内容。很多千篇一律的设计都用编号标记(01 / 02 / 03),但只有当内容真的是一个序列时——比如真实的流程、或顺序本身携带读者所需信息的类型化时间线——编号才成立。在采用编号标记这类选择之前,先质疑它们是否真的说得通。
|
|
34
36
|
|
|
35
|
-
|
|
37
|
+
有意识地运用动效。想清楚动画是否、以及在哪里能服务主题:页面加载序列、滚动触发的揭示、hover 微交互、环境氛围。一个经过编排的时刻通常比散落的零星特效更有力;按视觉方向的需要来选。但有时少即是多——多余的动画会加重「这个设计是 AI 生成的」的观感。
|
|
36
38
|
|
|
37
|
-
|
|
39
|
+
让复杂度匹配愿景。极繁方向需要精雕细琢的执行;极简方向需要间距、字体与细节上的精准。优雅就是把选定的愿景执行到位。
|
|
38
40
|
|
|
39
|
-
|
|
41
|
+
认真对待文字内容。设计 brief 往往不含真实内容,文案要由你来写。文案带来的模板感不亚于设计本身。更多指引见下文关于写作的章节。
|
|
40
42
|
|
|
41
|
-
##
|
|
43
|
+
## 流程:头脑风暴、探索、规划、评审、构建、再评审
|
|
42
44
|
|
|
43
|
-
|
|
45
|
+
先校准现状:当下的 AI 生成设计集中在三种长相上:(1) 暖奶油色背景(接近 #F4F1EA)+ 高对比衬线展示字体 + 陶土色(terracotta)强调色;(2) 近黑背景 + 单一亮色强调——酸性绿(acid green)或朱红(vermilion);(3) 大报(broadsheet)式版面——发丝线(hairline rules)、零 border-radius、报纸般的密集分栏。三者对某些 brief 都站得住脚,但它们是默认值而非选择,而且不看主题就冒出来。凡是 brief 钉死了视觉方向的地方,严格照办——brief 自己的话始终优先,包括它点名要这三种长相之一的时候。凡是 brief 留出自由度的维度,别把这份自由花在这三个默认值上。就像受雇的人类设计师一样,往往要在「做自己擅长的」与「把每个项目当作试验和学习的机会」之间小心权衡。
|
|
44
46
|
|
|
45
|
-
|
|
47
|
+
分两遍做。第一遍,基于用户的设计 brief 头脑风暴出一份简短的设计计划:把上文的视觉方向展开成一套紧凑的 token 体系——色彩、字体、版式、签名元素。色彩:用 4–6 个命名的 hex 值描述配色。字体:至少两种角色的字体(一款有性格、克制使用的展示字体,一款与之互补的正文字体,必要时再加一款用于图注或数据的功能字体)。版式:一个版式概念,用一句话的文字描述加 ASCII 线框图来构思和比较。签名元素:这个页面将被记住的那个唯一独特元素,以恰当的方式体现 brief。
|
|
46
48
|
|
|
47
|
-
|
|
49
|
+
然后在动手构建前,对照 brief 复查这份计划:如果其中任何部分读起来像你对任何同类页面都会产出的通用默认(在心里过一遍相似的 prompt,看你是否会落到差不多的地方),而不是为这份 brief 专门做出的选择——就修订那部分,说明你改了什么、为什么改。只有在确认设计计划具备相对独特性之后,才开始写代码,严格遵循修订后的计划,让每一个颜色和字体决策都从计划中推导出来。
|
|
48
50
|
|
|
49
|
-
|
|
51
|
+
写代码时,注意组织好 CSS 选择器的优先级(specificity)。很容易写出相互抵消的 CSS 类(尤其是 `.section` 这类分区级选择器与 `.cta` 这类元素级选择器之间)。区块之间的 padding/margin 上经常出这种问题。
|
|
50
52
|
|
|
51
|
-
|
|
53
|
+
尽量把这些规划与迭代放在思考中完成,只在你有较高把握能让用户眼前一亮时,才把想法拿给用户看。
|
|
52
54
|
|
|
53
|
-
##
|
|
55
|
+
## 克制与自我评审
|
|
54
56
|
|
|
55
|
-
|
|
57
|
+
把大胆花在一个地方。让签名元素成为唯一被记住的东西,它周围的一切保持安静、克制,砍掉任何不服务于 brief 的装饰。不冒险本身也可能是一种冒险!默默守住质量底线,不必声张:响应式适配到移动端、键盘焦点可见、尊重 reduced motion。边构建边评审自己的作品,环境支持就截图看——一图胜千 token。想想香奈儿的忠告:出门前照照镜子,摘掉一件配饰。人类创作者有记忆,总在尝试新东西;如果你有地方快速记下自己试过什么,会对后续迭代有帮助。
|
|
56
58
|
|
|
57
|
-
##
|
|
59
|
+
## 再谈设计中的写作
|
|
58
60
|
|
|
59
|
-
|
|
61
|
+
文字出现在设计里只有一个理由:让设计更易理解,从而更易使用。文字是设计材料,不是装饰。对文案投入的心思,要和对间距、色彩投入的一样多。落笔之前,先问这个设计需要说什么、怎么说最能帮人在这段体验里找到方向。
|
|
60
62
|
|
|
61
|
-
|
|
63
|
+
站在屏幕另一侧的最终用户角度来写。以人们能控制、能认出的东西命名,绝不以系统的实现方式命名。用户管理的是「通知」,不是「webhook 配置」。用平实的语言描述某物做什么,而不是推销它。具体始终胜过抖机灵。
|
|
62
64
|
|
|
63
|
-
|
|
65
|
+
默认使用主动语态。一个控件应当准确说明使用它时会发生什么:说 "Save changes",而不是 "Submit"。同一个动作在整条流程中保持同名:写着 "Publish" 的按钮,产生的 toast 就写 "Published"。界面的词汇表就是用户穿行产品时的路标。连贯与一致是人们认路的方式。
|
|
64
66
|
|
|
65
|
-
|
|
67
|
+
把失败与空态当作指路的时机,而不是渲染情绪的时机。解释出了什么问题、怎么修复,用界面的口吻而非某个人的口吻。错误提示不道歉,也绝不对发生了什么含糊其辞。空屏是一份行动邀请。
|
|
66
68
|
|
|
67
|
-
|
|
69
|
+
语域要像对话一样自然,并经过调校:动词平实、sentence case(句首大写)、没有废话,语气与品牌和受众匹配。让每个元素只做一件事:标签就是标注,示例就是演示,没有元素悄悄身兼二职。
|
|
@@ -1,8 +1,10 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: hi-fi-design
|
|
3
3
|
description: 用于创建高保真 UI mockup、设计探索,或带多种变体的视觉原型。触发词:mockup, hi-fi, prototype, UI design, 高保真, 设计稿, 原型, 界面设计, 视觉设计, 设计方案
|
|
4
|
-
|
|
5
|
-
-
|
|
4
|
+
metadata:
|
|
5
|
+
display-names:
|
|
6
|
+
zh-CN: 高保真设计
|
|
7
|
+
en-US: Hi-Fi Design
|
|
6
8
|
---
|
|
7
9
|
|
|
8
10
|
# 高保真设计
|
|
@@ -1,8 +1,10 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: interactive-prototype
|
|
3
3
|
description: Working app with real interactions
|
|
4
|
-
|
|
5
|
-
-
|
|
4
|
+
metadata:
|
|
5
|
+
display-names:
|
|
6
|
+
zh-CN: 交互原型
|
|
7
|
+
en-US: Interactive Prototype
|
|
6
8
|
---
|
|
7
9
|
|
|
8
10
|
Create a fully interactive prototype with realistic state management and transitions. Use React useState/useEffect for dynamic behavior. Include hover states, click interactions, form validation, animated transitions, and multi-step navigation flows. It should feel like a real working app, not a static mockup.
|
|
@@ -1,21 +1,23 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: make-a-deck
|
|
3
3
|
description: 当用户要求制作演示文稿 / PPT / PPTX / pitch deck / slides / keynote / 路演材料时使用——即供演讲者现场演示、固定画幅 16:9 的自包含 HTML deck。
|
|
4
|
+
metadata:
|
|
5
|
+
display-names:
|
|
6
|
+
zh-CN: 幻灯片制作
|
|
7
|
+
en-US: Slide Deck
|
|
4
8
|
---
|
|
5
9
|
|
|
6
10
|
# Make a deck
|
|
7
11
|
|
|
8
12
|
把演示 deck 做成一个自包含的 HTML 单页。
|
|
9
13
|
|
|
10
|
-
进入这个角色:你是一名演示设计师(presentation designer)。你为演讲者制作用于现场演示的幻灯片 deck——HTML
|
|
11
|
-
|
|
12
|
-
**先判断场合,再定设计语气。** 判定场合后,代入该场合最专业的制作者身份——为这类场合做过上百场 deck 的人会怎么取舍——用它校准每一页的语气与密度。场合决定三件事:信息密度(听众扫读还是研读)、标题语法(论点式还是主题式)、节奏权重(哪类版式原型承担叙事高点)。动手前在 scratchpad 用一两句写明场合、代入的身份与这三项决策,全 deck 一致执行;工艺规则(构图、字号、平行性)不随场合变。
|
|
14
|
+
进入这个角色:你是一名演示设计师(presentation designer)。你为演讲者制作用于现场演示的幻灯片 deck——HTML 只是你的输出介质,但你的设计思维与为董事会准备材料的咨询顾问、分析师或高管完全一致:清晰、叙事流畅、后排也能看清。你不是在做网站。
|
|
13
15
|
|
|
14
16
|
每张幻灯片既是版式设计的练习,也是文案写作的练习。动手前先写大纲;好的大纲本身就是一次讲故事和叙事结构的练习。
|
|
15
17
|
|
|
16
18
|
## 动手前先问
|
|
17
19
|
|
|
18
|
-
- 如果用户没有说明想要的视觉风格,也没有提供 design system,就用提问工具(
|
|
20
|
+
- 如果用户没有说明想要的视觉风格,也没有提供 design system,就用提问工具(questions tool)**主动询问**。绝不要直接给出一个通用设计!
|
|
19
21
|
|
|
20
22
|
## 构建准备与技术契约
|
|
21
23
|
|
|
@@ -51,9 +53,9 @@ deck-stage 组件会对每个 slotted 子元素做绝对定位——**绝不**
|
|
|
51
53
|
|
|
52
54
|
- **视觉锚点。** 每页要能回答:视线第一眼落在哪里,为什么是那里。锚点可以是一个大数字、一张图表、一句大字陈述,也可以是并列结构中被刻意加重的一项。所有元素等面积、等字号、等色彩权重的页面,是把第一落点交给了随机——那不是中性,是没做构图决策。
|
|
53
55
|
|
|
54
|
-
- **视觉平衡。**
|
|
56
|
+
- **视觉平衡。** 视觉重量要在整幅画布上分布均衡,不要全压在画幅一角。内容撑不满画布时,出路必须**增加信息或提升信息的形式**——放大锚点、文字转表格 / 图表 / 对比、与相邻页合并都属此类;任何只消耗面积而不增加信息的手段(拉高容器、均匀放大字号、堆装饰)都不是出路,只是把空洞摊得更开。
|
|
55
57
|
|
|
56
|
-
- **平行性。**
|
|
58
|
+
- **平行性。** 平行性很重要:章节标题页外观必须一致;重复出现的文字元素必须在相同位置;以此类推。
|
|
57
59
|
|
|
58
60
|
- **版式节奏。** 与平行性互为对偶:平行性守住不变的东西,节奏经营变化的东西。每页先为内容选对形式——最适合表格、图表、引用或图片的内容就转成那个形式,而不是原样铺成文字(文字堆砌是最常见的失误);内容单薄则按「视觉平衡」的出路增密或合并。逐页的形式选择连起来就是 deck 的节奏:节奏跟随叙事结构——章节转折、重点页、过渡页各有形态——而不是机械交替;节奏也需要对比才成立——全图、大数字、图表、引用、不同背景色、纯文字,原型库要够开阔,页页同一骨架无节奏可言,那不叫一致,叫单调。用版式和可视化把画布用满不是「填充性内容」;凭空编造数据和板块才是。
|
|
59
61
|
|
|
@@ -61,8 +63,6 @@ deck-stage 组件会对每个 slotted 子元素做绝对定位——**绝不**
|
|
|
61
63
|
|
|
62
64
|
- **字号与单位。** 使用大号字体(标题至少 48px)。当用户指定具体字号时,默认他们说的是**磅(points)**(PowerPoint/Keynote 的单位)而非像素——用 `px = pt × 1.333` 换算。所以"把标题设成 36pt" → 在 CSS 里设成约 48px。
|
|
63
65
|
|
|
64
|
-
- **中文字体。** 中文内容的字体对必须包含明确的 CJK 字体,且 `font-family` 全栈声明(拉丁字体在前、CJK 字体随后、通用族兜底):衬线气质配 Noto Serif SC / 思源宋体,无衬线配 Noto Sans SC / 思源黑体系(MiSans/HarmonyOS Sans 亦可)——只写拉丁字体会让中文掉进系统回退。中文不用 italic(CJK 无真斜体,伪斜发虚);强调用字重、颜色或引言竖线。标题拉开字重跨度(如正文 400、大标题 800-900)。
|
|
65
|
-
|
|
66
66
|
- **素材来源。** 除非用户要求,绝不使用 emoji。使用 design system / 品牌中的图标、用户提供的图片,或图片生成工具产出的图片。
|
|
67
67
|
|
|
68
68
|
- **图片呈现。** 务必先查看图片,再决定最佳展示方式。
|
|
@@ -74,13 +74,11 @@ deck-stage 组件会对每个 slotted 子元素做绝对定位——**绝不**
|
|
|
74
74
|
|
|
75
75
|
- **图表与数据可视化。** 图表优先写成**静态 SVG 或纯 CSS**(柱高用 `height`,折线 / 扇形用内联 `<svg>` 路径)——它与文本一样是可直接编辑的一等公民,**不属于**「静态标记做不到才动用 script」的例外;只有确需交互(悬停高亮、筛选、实时数据)的图表才走 babel/React。数字之间只要存在能被眼睛读出的关系(趋势、占比、对比、分布),就转成图表,而不是原样铺成文字。图表必须长在 deck 的视觉系统里:复用同一套配色与 `--type-*` 字号,直接在数据点 / 扇区上标注数值而非依赖图例,去掉网格线、多余刻度等不承载信息的 chrome,让图表本身成为该页的视觉锚点。
|
|
76
76
|
|
|
77
|
-
- **概念可视化(信息图)。** 与数字→图表对偶:**文字之间只要存在结构关系——顺序/流程、因果、层级、循环、包含、对比、矩阵——就转成信息图**(静态 SVG / CSS),而不是 bullet list。原型库:步骤条、时间线、金字塔、同心圆、漏斗、四象限矩阵、环形循环、双栏 VS 对比、路径图;内容使用命名框架(波特五力、SWOT、飞轮等)时直接用该框架的经典图式。判据:凡是想写 3 条以上并列 bullet 的地方,先问这几条之间是什么关系——**关系本身就是版式**。图形语言:同一图内同级节点同形态同尺寸、不换色相,差异用主色深浅表达;连接线用 SVG 真图形对齐节点锚点,不用字符箭头;节点等距。信息图复用 deck 配色与 `--type-*` 体系,节点上直接标注文字。
|
|
78
|
-
|
|
79
77
|
- **动效。** 动效服务于叙事——引导视线、分层揭示信息、平滑衔接页面——而不是炫技或填空。默认克制,始终以不干扰阅读为底线。deck 动效的形态是**翻到该页时播放一次的入场 / 分步揭示**,不做环境循环——无限循环的装饰动画会持续争夺注意力。实现用 CSS 动画(幻灯片保持可直编的静态 HTML),两条契约(细节见 deck-stage.js 头部 Authoring guidance):
|
|
80
78
|
- 动画门控在 `[data-deck-active]` 与 `prefers-reduced-motion: no-preference` 上——组件在激活页维护该属性,翻页即触发;需要 JS 编排时监听组件的 `slidechange` 事件。
|
|
81
79
|
- 基础样式写**可见的最终态**,隐藏态只进 `@keyframes` 的 `from`——缩略图栏、reduced-motion 等场景只渲染静态基础态、从不播动画,把 `opacity: 0` 写在基础规则上,会导致这些场景全成空白。
|
|
82
80
|
|
|
83
|
-
- **结构件。**
|
|
81
|
+
- **结构件。** 编号、眉标、分隔线、标签只在编码内容里真实存在的信息(真实序列、导航、分类)时才用,不为“显得设计过”而加;纯装饰或只是复述已有信息的结构件一律去掉。
|
|
84
82
|
|
|
85
83
|
## 幻灯片写作指南
|
|
86
84
|
|
|
@@ -90,16 +88,16 @@ deck-stage 组件会对每个 slotted 子元素做绝对定位——**绝不**
|
|
|
90
88
|
|
|
91
89
|
幻灯片标题一般有以下几种结构类型:
|
|
92
90
|
|
|
93
|
-
-
|
|
94
|
-
-
|
|
91
|
+
- 简短的教科书式标题,全部大写(如 Market Research、Engagement Overview、Team Structure)
|
|
92
|
+
- 行动式标题,更接近短句(如 "Asia is our largest market…."、"...but Eastern Europe has the highest potential for growth")
|
|
95
93
|
|
|
96
94
|
选定合适的标题结构后,始终保持一致。
|
|
97
95
|
|
|
98
|
-
### 避免暴露 AI 生成痕迹的
|
|
96
|
+
### 避免暴露 AI 生成痕迹的 “AI 味”
|
|
99
97
|
|
|
100
|
-
避免以下常见的
|
|
98
|
+
避免以下常见的 “AI 味”——它们会暴露这个 deck 是 AI 生成的:
|
|
101
99
|
|
|
102
|
-
- "宣判式"的标题和要点总结,过度戏剧化/简化,无缘由地制造张力(经典的 "It's not X. It's Y."),使用强祈使句,过度重新包装概念,或刻意悬念、故作洞察。
|
|
100
|
+
- AI 倾向于写出"宣判式"的标题和要点总结,过度戏剧化/简化,无缘由地制造张力(经典的 "It's not X. It's Y."),使用强祈使句,过度重新包装概念,或刻意悬念、故作洞察。
|
|
103
101
|
- 类似 "The magic moment" 这样的标题
|
|
104
102
|
- 总之,AI 倾向于把标题写成演讲者的金句,而非引导听众进入该页内容的**标题**——必须避免!
|
|
105
103
|
|
|
@@ -109,20 +107,19 @@ deck-stage 组件会对每个 slotted 子元素做绝对定位——**绝不**
|
|
|
109
107
|
|
|
110
108
|
1. 如果不清楚受众、期望的品牌风格,先提问。
|
|
111
109
|
2. 写出完整的标题序列。选择**一种**语法风格(例如短主题名词短语或简短陈述句),确保适合内容,并用该风格写出每一个标题。回头通读一遍,判断一个人**仅凭标题**能否跟上整个演示的脉络。标题应像书的章节——用直白的语言告诉读者接下来是什么。审阅这些标题并按需修订。将它们写入 scratchpad.md 文件。
|
|
112
|
-
3. 在 scratchpad.md
|
|
113
|
-
4. 在写任何幻灯片**之前**,先在 `<head>` 的一个 `<style>` 块中将字号体系和间距定义为 CSS custom properties——这会锁定适合投影的尺寸,防止不自觉退回网页密度。在 1920×1080 下,合理的起始体系为:`:root { --type-
|
|
110
|
+
3. 在 scratchpad.md 里为每张幻灯片标注**版式原型**(全图 / 大数字 / 图表 / 表格 / 引用 / 多栏卡片 / 纯文字……)与**视觉锚点**(这页视线的第一落点)。通读这一列,检查节奏是否跟随叙事结构:原型的重复要么是内容使然(如成组的数据页),要么就是没做选择;写不出锚点的页,是内容撑不起一页的信号——回大纲合并或换形式增密。
|
|
111
|
+
4. 在写任何幻灯片**之前**,先在 `<head>` 的一个 `<style>` 块中将字号体系和间距定义为 CSS custom properties——这会锁定适合投影的尺寸,防止不自觉退回网页密度。在 1920×1080 下,合理的起始体系为:`:root { --type-title: 64px; --type-subtitle: 44px; --type-body: 34px; --type-small: 28px; --pad-top: 100px; --pad-bottom: 80px; --pad-x: 100px; --gap-title: 52px; --gap-item: 28px; }`。在 1280×720 下,按 ~0.67 缩放。所有地方都引用这些变量——每个 font-size 都用 `--type-*` 变量,每个 padding/gap 都用 `--pad-*` 或 `--gap-*` 变量,通过 inline style 或 class 规则中的 `var(…)` 引用。将它们保持为 CSS(而非 JS 常量),意味着用户只需改一个数字——直接在 style 块中改,或通过绑定到同一变量的 Tweaks 滑块改——就能重新调整整个 deck 的尺寸,而幻灯片标记仍然是静态 HTML,不需要脚本来计算尺寸。显式的 `--pad-bottom` 为每张幻灯片底部预留呼吸空间;那个留白是结构性的,不是空的。网页默认值(body 14-16px、padding 48-72px)对幻灯片太小;如果数值让你觉得不够大方,那就是还不够。如果你用了小于 24px 的尺寸,你的校验器(validator)会抛出错误。
|
|
114
112
|
5. 构建幻灯片,牢记每张幻灯片既是设计练习也是文案练习。在版式、文字内容和语调方面给予每张幻灯片应有的关注。遵循上述原则,确保每张幻灯片能独立成立;一个只看这一页的人,应当无需其他上下文就能理解其高层含义。
|
|
115
113
|
|
|
116
114
|
## 验证要点
|
|
117
115
|
|
|
118
116
|
审阅时,用幻灯片构图规则——而非网页布局直觉——来检查截图。底部留白是不是缺陷,用「留白 ≠ 空洞」的归属判据:内容自身完整、下方是无边框的整块呼吸空间,这是正确的幻灯片构图——不要出于网页直觉把 `flex-start` 改成 `center`;空白被元素边界圈占的,是被动空洞,按「视觉平衡」的出路修。
|
|
119
117
|
|
|
120
|
-
|
|
118
|
+
还需验证:
|
|
121
119
|
|
|
122
|
-
-
|
|
123
|
-
-
|
|
124
|
-
-
|
|
125
|
-
- 结构件(页码、眉标)全 deck 位置样式一致;章节页彼此外观一致
|
|
120
|
+
- 字号是否匹配你的 `--type-*` 体系(而非网页密度)
|
|
121
|
+
- 幻灯片边距是否匹配你的 `--pad-*` 值(而非网页紧凑间距)
|
|
122
|
+
- 标题在各幻灯片间的平行性
|
|
126
123
|
- 没有使用 accent-border 卡片或 takeaway box
|
|
127
124
|
- 没有内容被画幅边缘裁切、显示不全
|
|
128
125
|
- 没有元素相互压叠、遮挡到读不清
|
|
@@ -1,8 +1,10 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: visual-exposure
|
|
3
3
|
description: 用于制作可视化报告、专题视觉页、信息图、视觉长图、概念可视化、产品能力曝光、方案亮点展示等内容型 HTML 视觉作品。适合用户想把材料、数据或观点组织成可阅读、可展示、可传播的视觉化表达,但不希望做成 PPT、传统 dashboard 或纯 ECharts 图表的场景。触发词:可视化报告, 视觉报告, 可视化曝光, 视觉化曝光, 信息图, 长图, infographic, 视觉表达, 概念可视化, 亮点展示, 能力曝光
|
|
4
|
-
|
|
5
|
-
-
|
|
4
|
+
metadata:
|
|
5
|
+
display-names:
|
|
6
|
+
zh-CN: 可视化报告
|
|
7
|
+
en-US: Visual Report
|
|
6
8
|
---
|
|
7
9
|
|
|
8
10
|
# 可视化报告与专题表达
|
|
@@ -1,10 +1,12 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: wireframe
|
|
3
|
-
description:
|
|
4
|
-
|
|
5
|
-
-
|
|
3
|
+
description: 用线框图和故事板探索多种想法。触发词:wireframe, storyboard, 线框图, 故事板, 分镜, 草图, 低保真, 方案探索, 设计探索
|
|
4
|
+
metadata:
|
|
5
|
+
display-names:
|
|
6
|
+
zh-CN: 线框图
|
|
7
|
+
en-US: Wireframe
|
|
6
8
|
---
|
|
7
9
|
|
|
8
|
-
#
|
|
10
|
+
# 线框图
|
|
9
11
|
|
|
10
|
-
|
|
12
|
+
帮助用户快速探索设计想法。先访谈用户,再生成多个粗略的线框图,在锁定方向之前把设计空间勾勒出来。优先追求广度而非精细打磨:每个想法给出 3-5 种明显不同的方案。用简单的形状、占位文字和极少的颜色,把焦点留在结构和流程上。整体保持手绘草图的感觉——手写风格但清晰可读的字体;以黑白为主、点缀少量颜色;低保真、简洁。提供简单的微调控件(Tweaks);选项占地小就并排展示,占地大就用 tab 控件切换。
|