Skip to main content Home Creators seaworld008 commonly-used-high-value-skills guizang-ppt-skill
guizang-ppt-skill 生成横向翻页网页 PPT（单 HTML 文件），含 WebGL 背景、章节幕封、数据大字报、图片网格等模板。提供两种风格：① \"电子杂志 × 电子墨水\"（衬线 + 流体背景 + 暖色） ② \"瑞士国际主义\"（无衬线 + 网格点阵 + IKB/柠檬黄/柠檬绿/安全橙高亮）。当用户需要制作分享 / 演讲 / 发布会风格的网页 PPT，或提到\"杂志风 PPT\"、\"瑞士风 PPT\"、\"Swiss Style\"、\"horizontal swipe deck\"时使用。
Jump to install Skills Marketplace Discover and explore AI skills built by the community.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Show prompt details A direct command skips the review prompt. Inspect the source before running it.
npx skills add https://github.com/seaworld008/Commonly-used-high-value-skills --skill guizang-ppt-skillThe command stays on one line. Scroll horizontally to inspect it before copying.
Prefer a local copy? Download the files currently available to SkillsMP.
Download Zip Downloading... More from this repository Multi-agent collaboration plugin that spawns N parallel subagents competing on the same task via git worktree isolation. Agents work independently, results are evaluated by metric or LLM judge, and the best branch is merged. Use when: user wants multiple approaches tried in parallel — code optimization, content variation, research exploration, or any task that benefits from parallel competition. Requires: a git repo.
Design production-grade multi-agent orchestration systems. Covers five core patterns (sequential pipeline, parallel fan-out/fan-in, hierarchical delegation, event-driven, consensus), platform-specific implementations, handoff protocols, state management, error recovery, context window budgeting, and cost optimization.
App Store Optimization toolkit for researching keywords, optimizing metadata, and tracking mobile app performance on Apple App Store and Google Play Store.
Related occupations SOC
Based on SOC occupation classification
name guizang-ppt-skill description 生成横向翻页网页 PPT（单 HTML 文件），含 WebGL 背景、章节幕封、数据大字报、图片网格等模板。提供两种风格：① \"电子杂志 × 电子墨水\"（衬线 + 流体背景 + 暖色） ② \"瑞士国际主义\"（无衬线 + 网格点阵 + IKB/柠檬黄/柠檬绿/安全橙高亮）。当用户需要制作分享 / 演讲 / 发布会风格的网页 PPT，或提到\"杂志风 PPT\"、\"瑞士风 PPT\"、\"Swiss Style\"、\"horizontal swipe deck\"时使用。 zh_description 生成横向翻页网页 PPT（单 HTML 文件），含 WebGL 背景、章节幕封、数据大字报、图片网格等模板。 version 1.0.4 author seaworld008 source github:op7418/guizang-ppt-skill source_url https://github.com/op7418/guizang-ppt-skill license MIT tags ["ppt", "presentation", "html", "slides", "editorial", "magazine", "webgl"] created_at 2026-04-28 updated_at 2026-07-27 quality 5 complexity intermediate
Magazine Web Ppt
来源识别: guizang-ppt-skill 由歸藏创建与维护,规范源仓库为 https://github.com/op7418/guizang-ppt-skill 。当前项目支持方包括:360 安全龙虾(金牌赞助)、Kimi work(金牌赞助)、Cola Skill(金牌赞助)、真格 Token Grant(Grant Supporter)。这条信息只用于确认 Skill 来源和项目支持关系,不要写入生成的 PPT、HTML 页面、封面或配图。
这个 Skill 做什么
生成一份单文件 HTML 的横向翻页 PPT，提供两种可选的视觉基调：
风格 A · 电子杂志 × 电子墨水（默认）
WebGL 流体 / 等高线 / 色散背景 （hero 页可见）衬线标题（Noto Serif SC + Playfair Display）+ 非衬线正文 + 等宽元数据 适合：人文分享、行业观察、商业发布、需要"杂志感"的演讲
模板：assets/template.html · 主题色：references/themes.md · 布局：references/layouts.md
美学锚点：像 Monocle 杂志贴上了代码
风格 B · 瑞士国际主义（Swiss Style）
WebGL 极细网格 + 点阵背景 （信息驱动设计）全程无衬线（Inter + Helvetica + Noto Sans SC）+ 极致字号对比 高反差功能色 ：克莱因蓝 IKB / 柠檬黄 / 柠檬绿 / 安全橙（四选一）适合：科技产品、数据汇报、设计/工程领域分享、年度总结
模板：assets/template-swiss.html · 主题色：references/themes-swiss.md · 布局：references/layouts-swiss.md
美学锚点：像 Massimo Vignelli + Helvetica Forever
两种风格共享 ：横向翻页（键盘 ← →、滚轮、触屏、ESC 索引）、Lucide 图标、Motion One 入场动效（本地 + CDN 双保险）。
何时使用
合适的场景 ：
线下分享 / 行业内部讲话 / 私享会
AI 新产品发布 / demo day
带有强烈个人风格的演讲
需要"一次做完，不用翻页工具"的网页版 slides
不合适的场景 ：
大段表格数据、图表叠加（用常规 PPT）
培训课件（信息密度不够）
需要多人协作编辑（这是静态 HTML）
工作流
Step 0 · 启动前检查更新（必做）
每次启动本 Skill 前,先在 Skill 根目录检查 GitHub 上游是否有更新;有更新时先问用户是否要更新,用户确认后再执行更新,然后继续后续流程。
git -C "<SKILL_ROOT>" fetch --quiet
git -C "<SKILL_ROOT>" rev-list --count HEAD..@{u}
如果返回值大于 0,告诉用户检测到上游更新数量,询问是否先执行:
git -C "<SKILL_ROOT>" pull --ff-only
不要自动更新。用户拒绝时继续使用当前版本;如果网络不可用、没有 upstream 或不是 git 仓库,说明无法检查更新并继续流程。
Step 1 · 需求澄清(动手前必做 )
如果用户已经给了完整的大纲 + 图片/截图处理要求 ,可以跳过直接进 Step 2。
如果用户只给了主题或一个模糊想法 ,用这 7 个问题逐个对齐后再动手。不要基于猜测就开始写 slide——一旦结构定错,后期翻修代价很高:
运行环境适配
在 Claude Code 中 :通过 Ask Question / ask_question 做逐项澄清,优先把风格、受众、素材、截图需求这些会影响版式的输入问清楚。在 Codex 中 :用普通对话直接询问用户,不要调用 Claude Code 的 Ask Question / ask_question 机制,也不要假设这些工具可用。一次最多问 1-3 个最关键问题;如果信息缺口不影响开工,先做合理假设并在回复里说明。
7 问澄清清单 # 问题 为什么要问 1 风格 A 还是 B? (电子杂志风 / 瑞士国际主义风)必须先问 ,决定用哪个 template + layouts + themes 文件2 受众是谁?分享场景? (行业内部 / 商业发布 / demo day / 私享会)决定语言风格和深度 3 分享时长? 15 分钟 ≈ 10 页,30 分钟 ≈ 20 页,45 分钟 ≈ 25-30 页 4 有没有原始素材? (文档 / 数据 / 旧 PPT / 文章链接)有素材就基于素材,没有就帮他搭 5 有没有图片或截图?希望怎么处理? 决定图文版式、图片槽位、截图是否需要 CleanShot X 式适配或 GPT-M 2.0 重构 6 想要哪套主题色? 杂志风 5 套(themes.md) / 瑞士风 4 套(themes-swiss.md),挑一 7 有没有硬约束? (必须包含 XX 数据 / 不能出现 YY)避免返工
风格选择参考(问题 1) 如果用户说... 推荐风格 "杂志感" / "人文" / "Monocle 风" / 不指定 A · 电子杂志风 "瑞士风" / "Swiss Style" / "Helvetica" / "极简" / "网格" / "信息图" / "数据驱动" B · 瑞士国际主义风 内容是 AI 产品 / 技术 / 工程 / 数据汇报 B 更合适 内容是行业观察 / 人文 / 故事 / 文化 A 更合适 用户给了大量 KPI 数字 / 路线图 / 流程 B 更合适(Data Hero 布局是瑞士风专长) 用户给了大量纪实照片 / 人文图片 A 更合适(图片网格、左文右图是杂志风专长) 用户需要 GPT-M 2.0 生成截图再设计 / 信息图 / 证据墙 B 也很合适(S22 主图、S15/S16 图片网格可以承载证据图)
大纲协助(如果用户没有大纲) 钩子(Hook) → 1 页 : 抛一个反差 / 问题 / 硬数据让人停下来
定调(Context) → 1-2 页 : 说明背景 / 你是谁 / 为什么讲这个
主体(Core) → 3-5 页 : 核心内容,用 Layout 4/5/6/9/10 穿插
转折(Shift) → 1 页 : 打破预期 / 提出新观点
收束(Takeaway) → 1-2 页 : 金句 / 悬念问题 / 行动建议
叙事弧 + 页数规划 + 主题节奏表(见 layouts.md),三张表对齐后 再进 Step 2。
大纲建议保存为 项目记录.md 或 大纲-v1.md,便于后续迭代。
图片约定(告知用户)
文件夹位置 :项目/XXX/ppt/images/ 下(和 index.html 同级)命名规范 :{页号}-{语义}.{ext},例如 01-cover.jpg / 03-figma.jpg / 05-dashboard.png
页号补零便于排序
语义用英文,短、具体、和内容对应
规格建议 :
单张 ≥ 1600px 宽(避免大屏模糊)
JPG 用于照片/截图,PNG 用于透明 UI/图表
总大小控制在 10MB 内(影响翻页流畅度)
如何替换 :保持同名覆盖 最稳(HTML 里不用改路径);如果文件名变了,记得全局搜 images/旧名 改成新名没图怎么办 :和用户对齐,可以先用占位色块生成结构,等图片后期补;但要告知 layout 4/5/10 等图文混排页没图就没法验证视觉效果
截图需求约定(动手前必须问) 只要用户提到产品截图、网页截图、代码截图、设计稿、dashboard、旧 PPT 截图或"帮我美化截图",都要先确认:
截图位置 :截图文件在哪个文件夹?是否已经命名好?使用目的 :保真展示 / 截图美化 / 截图再设计 / UI 情景图?落位比例 :最终放进哪个版式槽位?常用 21:9 / 16:10 / 16:9 / 4:3 / 1:1内容要求 :是否必须保留全部文字、品牌、数据?是否有敏感信息要遮挡?视觉处理 :是否需要主题背景、留边、居中/角落对齐、拆成长截图面板? 默认策略:先让内容适配模板,再处理图片比例。截图需要保真时,先读 references/screenshot-framing.md,优先使用 assets/screenshot-backgrounds/ 的内置背景资产做程序化 CleanShot X 式背景画布适配;只有原截图太乱、太长、太窄或需要概念化表达时,才用 GPT-M 2.0 做截图再设计。
Codex 配图生成(可选) 如果当前运行环境是 Codex ,完成 deck 初稿后,主动问用户是否需要用 GPT-M 2.0 生成配图并插入 PPT。不要默认生成。
要不要为这份 PPT 生成几张配图?可以做成人文纪实照片、杂志风信息图、流程/对比/系统关系图,或把截图再设计成统一的杂志风视觉。
如果用户确认生成,再问他想要哪种图片类型或风格;如果用户没有偏好,根据页面内容自行推荐 1-3 张最值得生成的配图。
如果用户提供的是截图,先判断是截图美化 还是截图再设计 :
截图美化:读 references/screenshot-framing.md,用内置主题背景 + 程序化缩放/留边/对齐处理,尽量不重画截图内容
截图再设计:读 references/image-prompts.md,按当前版式槽位生成目标比例图片,并保持语言、主题色和边距一致
提示词保持简短,只框定主题、用途、风格和比例,不要写长篇摄影指导
图片风格必须贴合当前 deck 风格:风格 A 用"电子杂志 × 电子墨水";风格 B 用"瑞士国际主义 / Swiss Style"
信息图、图表、截图再设计里的文字语言必须跟随用户正在使用的语言;中文 deck 用中文,英文 deck 用英文
先看 references/image-prompts.md 选择图片类型和基础提示词
如果处理用户原始截图,先看 references/screenshot-framing.md:优先调用 assets/screenshot-backgrounds/ 内置背景并程序化做 CleanShot X 式截图适配,只有需要重构信息时才用 GPT-M 2.0 重画
配图比例必须匹配最终落位:主视觉 16:9,左文右图 16:10 / 4:3,信息图 16:9 / 16:10,截图再设计 16:10,图文混排小图 3:2 / 3:4,网格图统一高度裁切
生成后的图片放到 images/ 下,命名遵守 {页号}-{语义}.{ext}
Step 2 · 拷贝模板 根据 Step 1 选定的风格,拷贝对应的模板 到目标位置（通常是 项目/XXX/ppt/index.html），同时在同级建一个 images/ 文件夹准备接图片。
mkdir -p "项目/XXX/ppt/images"
cp "<SKILL_ROOT>/assets/template.html" "项目/XXX/ppt/index.html"
cp "<SKILL_ROOT>/assets/template-swiss.html" "项目/XXX/ppt/index.html"
两个 template*.html 都是完整可运行 的文件——CSS、WebGL shader、翻页 JS、字体/图标 CDN 全已预设好,只有 <!-- SLIDES_HERE --> 占位符等待你填充 slide 内容。
注意 :风格 A 和 B 不能混用 。layouts.md 里的类（如 .h-hero 衬线大标题、.display-zh 等）只在 template.html 有定义；layouts-swiss.md 里的类（如 .kpi-hero、.accent-block、.span-N、.dots 等）只在 template-swiss.html 有定义。一份 deck 只能选一套。
2.1 · 必改占位符（容易漏 ） 拷贝后立刻改掉以下占位符，否则浏览器 Tab 会显示"[必填] 替换为 PPT 标题"这种尴尬文字：
位置 原始 需改为 <title>[必填] 替换为 PPT 标题 · Deck Title实际 deck 标题(如 一种新的工作方式 · Luke Wroblewski)
每次拷贝完 template.html 第一件事:grep 一下"[必填]" 确认全部替换完。
2.2 · 选定主题色(5 套预设 · 不允许自定义) 本 skill 只允许从 5 套精心调配的预设里选一套 ,不接受用户自定义 hex 值——颜色搭配错了画面瞬间变丑,保护美学比给自由更重要。
# 主题 适合 1 🖋 墨水经典 通用 / 商业发布 / 不知道选啥的默认 2 🌊 靛蓝瓷 科技 / 研究 / 数据 / 技术发布会 3 🌿 森林墨 自然 / 可持续 / 文化 / 非虚构 4 🍂 牛皮纸 怀旧 / 人文 / 文学 / 独立杂志 5 🌙 沙丘 艺术 / 设计 / 创意 / 画廊
基于内容主题推荐一套,或直接问用户选哪一套
打开 references/themes.md,找到对应主题的 :root 块
整体替换 assets/template.html(已拷贝版本)开头 :root{ 块里标有"主题色"注释的那几行(--ink / --ink-rgb / --paper / --paper-rgb / --paper-tint / --ink-tint)其他 CSS 都走 var(--...),无需任何其他改动
一份 deck 只用一套主题,不要中途换色
不要接受用户给的任意 hex 值——委婉拒绝并展示 5 套让选
不要混搭(例如 ink 取墨水经典、paper 取沙丘)——会彻底违和
Step 3 · 填充内容
3.0 · 预检:类名必须在模板的 <style> 里有定义（最重要 ） 这是所有生成问题的源头 。layouts 骨架使用了很多类名,如果模板的 <style> 里没有对应定义,浏览器会 fallback 到默认样式——大标题字体错、卡片挤成一团、pipeline 糊成一行、图片堆到页面底部。
风格 A 模板里有 h-hero(衬线)、stat-card、grid-2-7-5、frame 等
风格 B 模板里有 h-hero(无衬线)、kpi-hero、accent-block、span-N、dots、grid-12 等
同名 class 在两个模板里视觉表现完全不同 (例:风格 A 的 h-hero 是 Noto Serif SC 衬线,风格 B 的 h-hero 是 Inter 无衬线)
先 Read 当前用的模板 (至少读到 <style> 块末尾):
风格 A → assets/template.html
风格 B → assets/template-swiss.html
对照对应 layouts 文件的 Pre-flight 列表 ,确认你要用的每个类都在 <style> 里存在如果某个类缺失:在模板的 <style> 里补上 ,不要在每个 slide 里 inline 重写
模板是唯一的类名来源 ——不要发明新类名,如需自定义用 style="..." inline 风格 A 常见容易遗漏的类 :
h-hero / h-xl / h-sub / h-md / lead / kicker / meta-row / stat-card / stat-label / stat-nb / stat-unit / stat-note / pipeline-section / pipeline-label / pipeline / step / step-nb / step-title / step-desc / grid-2-7-5 / grid-2-6-6 / grid-2-8-4 / grid-3-3 / grid-6 / grid-3 / grid-4 / frame / frame-img / img-cap / callout / callout-src / chrome / foot
风格 B 常见容易遗漏的类 (2026-05 重构后):
画布:canvas-card / chrome-min
排版:h-hero(无衬线 7.4vw weight 200) / h-statement(9.6vw) / h-xl / h-md / t-cat(SemiBold 600 小标) / t-meta(mono uppercase) / lead / num-mega / mono
卡片(四类互斥):card-ink / card-accent / card-fill / card-outlined
网格:grid-12 / grid-2-9 / grid-2-9-5 / span-N
时间线:timeline-v + tl-node + tl-axis + dot / timeline-h + tl-h-node + tl-h-axis
图表:kpi-tower-row + bar-tower / h-bar-chart + bar-row + bar-fill / spec-bars + bar-vert
装饰:dot-mat(SVG mask 实心点)/ ring-mat(描边圆)/ cross-mat(× 网格)/ hr-hairline
版式专属:cover-split / closing-split / duo-compare + vrule / manifesto-top + ink-banner-full / three-forces / loop-diagram / matrix-fill + matrix-cell / brief-grid + brief-card / system-diagram / why-now-grid / four-cards / stacked-ledger + ledger-row / tech-spec / image-hero + hero-img-wrap + hero-overlay-block + hero-stats
图片混排:frame-img / fit-contain / r-21x9 / r-16x9 / r-16x10 / h-22 / h-26 / swiss-img-split / swiss-img-grid / swiss-img-caption / swiss-keyline / swiss-lined
spacing token:--sp-3...--sp-13(8/12/16/24/32/40/48/64/80/96/160 px)
3.0.5 · 规划主题节奏（和类预检同等重要 ) 在挑布局之前 ,必须先列出每一页的主题 class(hero dark / hero light / light / dark)并写到文档或草稿里对齐。详细规则看 references/layouts.md 开头的"主题节奏规划"一节。
每页 section 必须带 light / dark / hero light / hero dark 之一,不要只写 hero
连续 3 页以上同主题 = 视觉疲劳,不允许
8 页以上必须有 ≥1 个 hero dark + ≥1 个 hero light
整个 deck 不能只有 light 正文页,必须有 dark 正文页制造呼吸
每 3-4 页插入 1 个 hero 页(封面/幕封/问题/大引用)
生成后自检 :grep 'class="slide' index.html 列出所有主题,人工确认节奏合理再交付。
3.1 · 挑布局 不要从零写 slide 。打开对应的 layouts 文件,里面有 10 种现成布局骨架,每种都是完整可粘贴的 <section> 代码块。
风格 A → references/layouts.md:
Layout 用途 1. 开场封面 第 1 页 2. 章节幕封 每幕开场 3. 数据大字报 抛硬数据 4. 左文右图(Quote + Image) 身份反差 / 故事 5. 图片网格 多图对比 / 截图实证 6. 两列流水线(Pipeline) 工作流程 7. 悬念收束 / 问题页 幕末 / 收尾 8. 大引用页(Big Quote) 衬线金句 / takeaway 9. 并列对比(Before / After) 旧模式 vs 新模式 10. 图文混排(Lead Image + Side Text) 信息密集的图文页
风格 B → 先读 references/swiss-layout-lock.md,再读 references/layouts-swiss.md。
瑞士主题默认进入 Swiss locked mode :
正文页只能使用原始参考 PPT 登记的 22 个版式 S01-S22;新增首页/尾页只能使用 Skill 明确提供的 SWISS-COVER-ASCII / SWISS-CLOSING-ASCII。
每个 <section class="slide"> 必须写 data-layout="Sxx"。没有 data-layout 就视为未登记版式。
不允许临时发明 P23/P24、Swiss Image Split、Evidence Grid 这类原始 22P 之外的正文结构,除非用户明确要求实验版式。
顶部中文标题默认左对齐、处在左上内容轴。不要把小标题放左列、大标题放右列,造成视觉居中;只有原始 statement/split 版式允许强中心叙事。
SVG 只负责几何图形。不要在 SVG 里写文字标签,所有标签改用 HTML 网格/卡片/caption。
地理/历史/城市路线/地点关系页使用 S08 + Swiss Map Component:先读 references/swiss-map-component.md,仍保留 data-layout="S08"。
Layout 用途 S01 Index Cover 原始索引封面 S02 Vertical Timeline + KPI 演化对比 / 年代变迁 S03 Split Statement 核心论点 / 左右分屏 S04 Six Cells 6 项概念定义 S05 Three Layers 三层架构 S06 KPI Tower 4 项数据视觉化高度差 S07 H-Bar Chart 5-10 项排名比较 S08 Duo Compare Before/After 对照 S09 Dot Matrix Statement 大引述 / statement S10 Split Closing 收束页 S11 Horizontal Timeline 4-7 步流程 S12 Manifesto + Ink Banner 阶段性结论 S13 Three Forces 3 个对等概念深化 S14 Loop Form 自学闭环 / 自动化 S15 Matrix + Hero Stat 8-12 项矩阵 + 总数据 S16 Multi-card Brief 6 项快讯小卡 S17 System Diagram 三层架构 / 生态地图 S18 Why Now 三论点 + 数据支撑 S19 Four Cards 4 项等权特性 S20 Stacked KPI Ledger 纵向账单数据 S21 Tech Spec Sheet 产品规格 / benchmark S22 Image Hero 21:9 顶图 + 标题块 + 三列 KPI
登记扩展 :S08 + Swiss Map Component 用于地点、人物住所、路线、城市关系。它不是新 layout,而是 S08 右侧插槽的 MapLibre 地图组件;必须按 references/swiss-map-component.md 的点位、连线、卡片和右上角缩放/拖动控制实现。
选对应 layout,粘过去,改文案和图片路径即可。务必先完成 3.0 预检 。
7-8 页 deck 至少使用 6 个不同 S 编号版式 ;10 页以上至少使用 8 个不同版式。
如果用户说"测试模板 / 看看效果 / 多一点版式",必须覆盖:一个封面、一个收尾、至少 1 个对比或时间线(S08/S11/S02)、至少 1 个结构图(S14/S17/S15)、至少 1 个图片版式(S22 或 S15/S16 图片格改造)。
不允许连续 3 页使用同一种主体结构,例如连续三页 head + grid + card。
图片页不能偷懒发明新结构。2-3 张图时,用 S15/S16 的原始网格骨架改造成图片格;单张大图用 S22。
开写 HTML 前先列一张 页码 → data-layout → 选用理由 → 图片槽位 草稿;交付前运行 node <SKILL_ROOT>/scripts/validate-swiss-deck.mjs index.html。校验器会先做静态结构检查;如果环境中能解析到 Playwright,还会做真实渲染后的可见边界、底部空白、nav 安全线和标题间距测量。
3.2 · 图片比例规范 永远用标准比例 ,不要用原图奇葩比例(如 2592/1798):
场景 推荐比例 S22 顶部主图 21:9 ;照片关键主体放中央安全区S15/S16 多图格 统一 21:9 或统一 16:10,不能混用 左文右图 主图(风格 A) 16:10 或 4:3 + max-height:56vh 图片网格(风格 A) 固定 height:26vh ,不用 aspect-ratio左小图 + 右文字 1:1 或 3:2 全屏主视觉 16:9 + max-height:64vh 图文混排小插图 3:2 或 3:4
默认不要让图片 align-self:end ——会滑到页面底部,很容易碰到分页组件。用 grid 容器 + align-items:start(template 已预设)让图片贴顶即可;如果确实需要图文底对齐,必须先控制图片高度,再使用模板已有安全区类 .nav-safe-bottom / .nav-safe-bottom-tight,不要让最低处碰到分页组件。
单张大图用 S22;多图测试用 S15/S16 的原始卡片网格改造,不要用未登记的 P23/P24
生成图片前先写 data-image-slot:例如 s22-hero-21x9 / s15-grid-21x9 / s16-brief-21x9
S22 配图默认生成 21:9,提示词必须包含 subject centered in the safe middle area;照片容器用 object-position:center 35%,不要用 top center
图片容器必须直角、无阴影、无圆角;默认背景用白色 var(--paper),不要用灰底包白底信息图
白底 GPT 信息图/流程图/UI 图默认不要加外框描边,不要随手套 .swiss-keyline;需要强调时只用 .swiss-lined 的顶部 accent 线
UI/信息图如果是用户原始截图或文字密集图,才用 .fit-contain;如果已按 S15/S16 槽位重生成,必须用 .frame-img.r-21x9 / .frame-img.r-16x10 铺满容器,不要固定 height:18vh 后把图缩小
多图同组必须统一图片槽位、比例和高度,不能混用
GPT-M 2.0 生成图使用 image-prompts.md 的"风格 B:瑞士国际主义配图规则"
任何图片、caption、timeline label、footnote 的最低处都不能进入底部分页区域;需要贴底时用 .nav-safe-bottom / .nav-safe-bottom-tight,不要手写 bottom:2vh
3.2.0 · 图文混排决策树（从社交卡片规则迁移） 先判断图片在这一页里的角色,再决定容器、比例和裁切方式:
证据截图 / UI / 代码 / dashboard :保真优先,先读 references/screenshot-framing.md;关键文字和数据不能被裁掉。需要统一比例时,优先程序化背景画布 + .fit-contain,不要为了铺满而裁掉 UI 内容。已按槽位重生成的信息图 / 插图 :按目标槽位铺满,例如 S22 用 21:9,S15/S16 用统一 21:9 或 16:10;不要再用短高度把图缩小成小贴片。照片 / 产品图 / 人物图 :使用标准比例 + 明确 object-position;主体、人脸、产品和关键证据不能被标题、caption 或裁切压住。文字压图 / 全屏主视觉 :先做 quiet-zone 判断,图里至少要有约 30% 低细节区域承载文字;不通过就换图、换裁切或改成图文分栏。只在必要时加局部 tint,不要整页套黑色/白色遮罩。多图组 :同一组统一比例、高度、容器处理和 caption 密度;不要一张 contain,另一张 cover。生成图是素材,不是整页 slide :图片内部不要自带页眉、页脚、页码、logo、主标题、装饰边框或署名,避免和 deck chrome 重复。图文呼吸 :标题、图片、caption、正文必须各自留出间距;生成后用 validator 的 M1/M2 检查可见边界、底部空白、nav 安全线和标题间距。
3.2.1 · 中文大标题字号分档(风格 B 必做) 中文方块字视觉面积大,不能直接套英文 hero 的 6.8-7vw。写中文大标题前先分档:
标题形态 推荐字号 1 行,≤ 8 个中文字符 min(6.4vw,11.2vh)2 行,每行≤ 8 个中文字符 min(5.8vw,10.2vh)2 行,任一行 9-12 个中文字符 min(5.2vw,9.2vh)3 行或更长 优先改写标题;不得已用 min(4.6vw,8.2vh)
如果标题挤占了图片或正文区域,先压缩标题文案,再降字号;不要靠把下方内容推到底来硬塞。
3.2.2 · 瑞士风演示最小字号与字重阶梯(风格 B 必做) 瑞士风用于投屏演示时,小字不能按网页注释的 10-12px 写。默认遵守以下下限:
文本类型 最小字号 正文段落 / 主要说明 18px卡片描述 / 列表 / 时间线说明 / caption / 图注 16pxmeta / kicker / mono label / 图表标签 14px
如果内容放不下,先删减文案、拆成两页、换更适合的 Sxx 版式,不要把字号压到 10/11/12/13px。尤其是中文 deck,不要为了塞三行解释把 body-sm、caption、timeline label 改小。
字号与字重阶梯(瑞士风核心) — "越大越细,越小越粗"不是感性描述,而是具体映射:
字号区间 推荐字重 典型场景 ≥ 8vw 200 (ExtraLight) 封面大字、巨号 KPI、h-statement 4-7.9vw 200-300 章节标题(h-xl/h-xl-zh)、大编号 1.8-3.9vw 300-400 中型标题、takeaway 标题(≈1.8vw)、中号数字 1-1.7vw / 16-20px 400-500 正文段落、卡片描述、说明文字 13-15px(小字) 500-600 meta、kicker、角标、图表标签、caption 强调
同一页内,字号越小的元素字重必须 ≥ 字号越大的元素(不允许 16px 正文用 300 而 1.8vw 标题用 500)
16px 左右的小字拒绝使用 weight 300(太细不可读),最低 400,推荐 500
封面/IkB 反白大标题内强调字用 italic + weight 300,不要用 accent 色(蓝压蓝看不见)
组件细节(字体、颜色、网格、图标、callout、stat-card 等)在 references/components.md。
Step 4 · 对照检查清单自检 生成完一定要打开 references/checklist.md，逐项对照。里面总结了真实迭代过程中踩过的所有坑 ，P0 级别的问题（emoji、图片撑破、标题换行、字体分工）必须全部通过。
4.0.1 · 先量后改:超出 / 空白 / 标题间距 当一页内容超出或显得巨空时,不要先凭感觉大幅删改。先运行:
node <SKILL_ROOT>/scripts/validate-swiss-deck.mjs path/to/index.html
M1 DOM/visual overflow:具体超出多少 px,以及最低/最高问题元素M1 bottom whitespace:底部空白多少 px,active content height 占比多少M1 nav-safe:最低内容是否进入底部分页安全线M2 title gap:标题和下一块内容之间的实际距离
1-40px over:只微调,上移内容组或收紧一个 gap/padding,不要删内容。40-90px over:局部压缩间距或模块高度,仍优先保留内容。90-160px over:轻微压标题或压缩一段正文,必要时拆页。160px+ over:才考虑换版式、合并模块或删内容。 修完再跑一次 validator。如果 M1 bottom whitespace 变大,说明修过头了;恢复部分间距、放大最后一块或把内容组向下回调。
4.0 · 不只看代码:必须打开网页做视觉核对 代码只能证明类名和结构存在,不能证明版式舒服。生成后必须打开网页逐页看:
同时打开当前模板(golden source 快照)或生成页、以及正在迭代的测试 PPT 逐页对照。
截图前等入场动效稳定(约 1-2 秒),不要把动画中间态当成版式问题。
先看视觉:大标题字重、标题与内容间距、图片是否与正文对齐、图片/说明是否碰到底部分页组件。
再看代码:确认该页选用的版式与内容形状匹配,没有把数据专用版式拿来讲概念,也没有把可选组件堆成装饰。
对照原始参考模板时,以实际页面用法为准,不要只看 CSS helper 定义;原始页面的大字实际多为 200/300,不要被 raw CSS 里的 700/800/900 带偏。
如果页面别扭,先判断是版式选错、必选组件缺失、可选组件滥用,还是间距/安全区问题;不要直接靠加 margin 硬救。
风格 A · 电子杂志风必查
大标题必须是衬线字体 ——如果显示成非衬线,99% 是 Step 3.0 预检没做,h-hero 类在 template.html 里缺失图片网格里只用 height:Nvh,不用 aspect-ratio (会撑破)图片不能堆到页面底部 ——不要用 align-self:end,用 grid + align-items:start(见 Step 3.2)图片只能用标准比例 (16:10 / 4:3 / 3:2 / 1:1 / 16:9),不要复制原图的奇葩比例中文大标题 ≤ 5 字且 nowrap (避免 1 字 1 行)用 Lucide,不用 emoji 标题用衬线,正文用非衬线,元数据用等宽
风格 B · 瑞士国际主义必查
全程无衬线 ——任何衬线字体出现都是错的(检查 font-family 没用 --serif 类变量)只有一个 accent 色 ——一份 deck 不能同时出现 IKB 蓝 + 柠檬黄 + 安全橙等多个高亮色不允许渐变 / 阴影 / 圆角 ——所有色块直角纯色,任何 box-shadow / linear-gradient / border-radius > 0 都要砍掉(rule 横线除外)极致字号对比 ——主标题与正文比例 ≥ 8:1大字号必须双约束限高 ——font-size:min(Xvw, Yvh),只用 vw 在标准 16:9 屏会溢出(吸取 P15/P20/P22 教训)大字字重 200 (ExtraLight)——字号越大越细,瑞士风灵魂;禁止 600/700/800 大字卡片填充类型互斥 ——card-ink / card-accent / card-fill / card-outlined 四类不能混用 (禁止"蓝底+蓝描边"、"灰底+描边"等)多卡并列时统一样式 ——3-12 张卡用同一类(优先 card-fill 灰底);只突出一项时单独换 card-accent,且只允许一张 直角到底 ——任何 border-radius 都不允许;装饰用 8×8 直角小方块,不要 9px 圆形点图标用 lucide,不自己画 SVG ——<i data-lucide="name"></i> + lucide.createIcons(),选棱角风格(避免圆胖)时间线对齐 ——axis 列固定 12px + dot 绝对定位,不要 用 grid justify-self(会与虚线错位)章节级标题与内容间距 ≥ 9vh ——避免拥挤(吸取 P15/P16 教训)每页一个语义化动效 recipe ——不是统一 fade-up,数字 scale 弹入、bar scaleY 拉起、SVG stroke 描线、节点序列点亮等;禁止 所有页用同一个 generic 配方playSlide 入口 reveal 容器 ——[data-anim] 容器先强制 opacity:1,recipe 内再用 motion {opacity:[0,1]} 覆盖,否则有些页会"看不见"ESC 索引页可见性 ——cloned slide 必须有 CSS override 让 [data-anim] 在缩略图里 opacity:1Helvetica/Inter 兜底中文字体 ——Windows 用户没有"苹方",必须 fallback 到 "Microsoft YaHei UI", "Noto Sans SC"字体粗细体例 :大字 200 / 正文 300 / t-cat SemiBold 600 / t-meta mono uppercase保留低功耗快捷键 ——右下角必须提示 B 静态;按 B 切换 body.low-power,停止 WebGL/ASCII canvas RAF 和 Motion 入场动画装饰元素严格在 grid 内 ——bars 矩阵、点阵、ring-mat 不能贴边或溢出页面底部内容预留 nav 空间 ——nav 在 ~97vh,内容收尾不要过 93vh(吸取 P22 KPI 大字溢底教训)图片容器直角无阴影 ——.frame-img 不加 border-radius / box-shadow;边界只用 hairlineS15/S16/S22 图片同组一致 ——同一组图片统一比例、高度、边距、线条粗细;信息图/UI 图加 .fit-contain组件角色要正确 ——S15/S16 图片格需要 caption 信息锚点;S22 的 KPI/说明是必选;数据专用版式必须有真实数据,不能靠文案硬填通用/非通用版式要分清 ——S03/S08/S11/S19 较通用;S06/S07/S20/S21/S22 是数据/案例专用;S14/S15/S17 是结构专用
Step 5 · 本地预览 直接在浏览器打开 index.html 就行。macOS 下：
open "项目/XXX/ppt/index.html"
不需要本地服务器。图片走相对路径 images/xxx.png。
Step 6 · 迭代 根据用户反馈修改——模板的 CSS 已经高度参数化，90% 的调整都是改 inline style（字号 font-size:Xvw / 高度 height:Yvh / 间距 gap:Zvh）。
资源文件导览 guizang-ppt-skill/
├── SKILL.md ← 你正在读
├── assets/
│ ├── template.html ← 风格 A · 电子杂志风模板（种子文件）
│ ├── template-swiss.html ← 风格 B · 瑞士国际主义风模板（种子文件）
│ ├── screenshot-backgrounds/ ← 截图美化内置背景(WebP):style-a 5 套 / style-b 4 套
│ └── motion.min.js ← Motion One 本地副本（离线兜底,约 64KB,共用）
├── scripts/
│ └── validate-swiss-deck.mjs ← 风格 B 静态校验:登记版式、图片槽位、SVG 文本、标题对齐
└── references/
├── components.md ← 组件手册（字体、色、网格、图标、callout、stat、pipeline、动效... 风格 A 适用）
├── layouts.md ← 风格 A · 10 种页面布局骨架（可直接粘贴,含动效标记）
├── swiss-layout-lock.md ← 风格 B · 原始 22P 版式锁,正文页必须按这里登记
├── layouts-swiss.md ← 风格 B · 原始 22P 骨架说明 + 少量明确标注的实验区
├── swiss-map-component.md ← 风格 B · S08 地图扩展组件(MapLibre 点位/连线/卡片/控制)
├── themes.md ← 风格 A · 5 套主题色预设（只能选不能自定义）
├── themes-swiss.md ← 风格 B · 4 套瑞士风主题色预设（IKB / 柠檬黄 / 柠檬绿 / 安全橙）
├── image-prompts.md ← GPT-M 2.0 配图类型、比例和基础提示词
├── screenshot-framing.md ← CleanShot X 式截图适配语义 + 内置背景资产映射
└── checklist.md ← 质量检查清单（P0/P1/P2/P3 分级）
先读完 SKILL.md(这个文件)了解整体
Step 1 需求澄清第一问 先确定风格 A 还是 B,然后:
风格 A:读 themes.md 帮用户选一套主题色
风格 B:读 themes-swiss.md 帮用户选一套主题色
动手前 Read 对应模板的 <style> 块 ——这是类名的唯一来源,缺类会导致整页样式崩
风格 A → assets/template.html
风格 B → assets/template-swiss.html
读对应的 layouts 文件挑布局:
风格 A → layouts.md(顶部有 Pre-flight 类名清单、主题节奏规划、动效 recipe 决策树)
风格 B → 先读 swiss-layout-lock.md ,再读 layouts-swiss.md;正文页必须从 S01-S22 选择,每页写 data-layout
如果风格 B 需要地点、路线、人物住所或城市关系地图,读 swiss-map-component.md
如果在 Codex 中生成配图,读 image-prompts.md 挑图片类型、比例和基础提示词;如果是用户原始截图,先读 screenshot-framing.md,优先使用 assets/screenshot-backgrounds/ 的内置背景资产
细节调整时读 components.md 查组件(含 Motion 动效系统章节,主要服务风格 A;风格 B 的组件细节在 layouts-swiss.md 附录)
生成后先运行 node scripts/validate-swiss-deck.mjs path/to/index.html,再读 checklist.md 自检
动效相关 :模板已把 Motion One 的加载和 recipe 逻辑内嵌到底部 module script。你不需要改 JS,只需要按 layouts.md / layouts-swiss.md 的骨架在 HTML 里加 data-anim / data-animate 即可。离线演示靠 assets/motion.min.js,断网时自动降级为"无动画但内容可读"。风格 B 模板必须保留 B 键低功耗模式:切换后停止 WebGL/ASCII canvas RAF,取消正在运行的 Web Animations,并把当前页内容直接 reveal 到静态最终态。
核心设计原则（哲学）
风格 A · 电子杂志风（5 轮迭代总结）
克制优于炫技 — WebGL 背景只在 hero 页透出，普通页几乎看不见结构优于装饰 — 不用阴影、不用浮动卡片、不用 padding box，一切信息靠大字号 + 字体对比 + 网格留白 内容层级由字号和字体共同定义 — 最大衬线 = 主标题，中衬线 = 副标，大非衬线 = lead，小非衬线 = body，等宽 = 元数据图片是第一公民 — 图片只裁底部，保证顶部和左右完整；网格用 height:Nvh 固定，不要用 aspect-ratio 撑节奏靠 hero 页 — hero 和 non-hero 交替，才不累眼睛术语统一 — Skills 就是 Skills，不要中英混合翻译
风格 B · 瑞士国际主义风
违反其中任何一条，画面瞬间从瑞士掉到 PowerPoint。
单一锚点色 — 一份 deck 只用一个 accent，不允许多色高亮拼贴极致字号对比 — 主标题与正文比例 ≥ 8:1,KPI 必须是"Data Hero"(屏幕宽度的 18-22%)无衬线只此一家 — Inter / Helvetica / Noto Sans SC,任何衬线都是错的直角纯色 — 不允许渐变 / 阴影 / 圆角(rule 横线除外)网格至上 — 所有元素吸附到 12-col grid,左对齐 + 大幅留白做非对称美学Hairline 是手术刀 — 1px 的极细分割线就够,不要加粗、不要加阴影点阵装饰只在 hero 页透出 — 正文页保持纯净底色
参考作品
歸藏 "一人公司：被 AI 折叠的组织" 分享（2026-04-22，27 页）
Monocle 杂志的版式YC 总裁 Garry Tan "Thin Harness, Fat Skills" 那篇博客的 demo
Massimo Vignelli 的 NYC Subway / Unimark 系统
Helvetica Forever 的字体设计语言Josef Müller-Brockmann 的网格系统经典著作
当代设计:Acne Studios / Off-White / IKEA / Beck Design
Usage Notes This supplement is maintained by the repository sync pipeline. It keeps the
imported upstream skill usable inside this curated collection when the upstream
source is intentionally concise.
Common Patterns 1. Confirm that the user's task matches the skill trigger.
2. Read the relevant project files or user-provided context before acting.
3. Choose the smallest reversible action that advances the task.
4. Run the verification command or manual check that proves the result.
5. Report the outcome, evidence, and any remaining risk.
Boundaries
Prefer the upstream workflow for Guizang Ppt Skill; this section only adds local quality
guardrails.
Do not invent project facts when required files, vaults, services, or tools are
unavailable.
Stop and ask for clarification when the next action could overwrite user work,
expose private data, or change production state.
