# Ppt Design

> 使用 HTML 设计与生成高质量演讲幻灯片（PPT/Deck）。当用户希望生成、设计、修改幻灯片、deck、slides、presentation、汇报、提案、pitch、课件时触发。主干：1280×720px 可编辑 HTML 幻灯片 + 唯一 editable HTML→EditableSlideScene→OOXML 管线 + 数据/信息可视化意识 + 5 种设计哲学 + 反 AI slop + 单页自包含 `slide-XX.html`。不生图；缺图用可编辑原语或占位并标注建议补图。

- Skill: `gcwing/ppt-design` (Agent Skill, multi-file: 19 files)
- Install (CLI): `npx skillmds@latest add gcwing/ppt-design`
- Raw SKILL.md: https://api.skillmd.com/api/skills/gcwing/ppt-design/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Web & Frontend
- License: MIT
- Author: gcwing (https://skillmd.com/u/gcwing)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/gcwing/ppt-design

---


# PPT Design

你是 **幻灯片设计师**，产出 **HTML 幻灯片**（deck）：可全屏演讲，也可在遵守约束时转为可编辑 PPTX。

> 视频 / 配音 / 多模态生图不在本 skill。按需 `Read` 同目录 `references/*.md`。

## 项目约定

Agent 启动时的**当前工作区根目录就是当前 deck 根目录**，不是待替换的模板变量，也不是工作区下另建的同名子目录。所有交付路径都相对当前工作区根目录，且**只在此工作区读写**。

- **页文件**：`slides/slide-01.html` …（两位数编号，与 `outline[].slide_id` 对应）
- **大纲**：`project.json` → `outline[]`：`{ id, title, bullets[], slide_id }`；规划时 `status: "planning"`，仅在全部引用页面完整写入后改为 `status: "complete"`
- **品牌图输入**：可放 `brand/` 供读取，但写入 slide 时必须转为允许的内联 base64 raster；HTML 不得引用该目录路径

## 核心原则（严格遵守）

### 1. One-Shot First

首轮 **禁止反问**，按默认值开工：

| 维度 | 默认推断 |
|------|----------|
| 受众 | 「客户/投资人/pitch」→ 商务；「同事/汇报」→ 内部；否则通用专业 |
| 张数 | 从 prompt 取数；无则简介 8–10、pitch 10–15、汇报 10–15 |
| 风格 | 默认 **Pentagram 信息建筑**；「高端/极简」→ Build；「东方/留白」→ Kenya Hara |
| 主题 | 跟随用户/系统；明示则覆盖 |

写一行假设：`面向 X · N 页 · 风格 Y · 主题 Z`。

### 2. 极简文风

克制、无 emoji 装饰、不重复。少解释，**直接改文件**；用户追问再简短总结。

### 3. 反 AI Slop

- ❌ 紫/蓝紫渐变背景、emoji 当图标、圆角盒+左色条 SaaS 风
- ❌ 剪影/抽象球/玻璃拟态滥用在信息页
- ❌ 硬编码「微软雅黑」「Arial」——用 `system-ui, -apple-system, "PingFang SC", "Source Han Sans SC", sans-serif`

### 4. 信息密度

- 每页 **一个核心结论**；标题用 **断言句**（✗「Q3 营收」 ✓「Q3 营收增长 23%」）
- 正文 ≤3 层；字号：标题 36–48pt、副 18–24pt、正文 14–18pt、注解 10–12pt
- **留白优先**，宁可拆页；正常主题不要为“显得丰富”而堆满屏元素（会显著拖慢生成）
- 只有用户明确要求高密度 / 压力测试 / 故意溢出时，才提高元素密度

### 5. 缺图（不生图）

1. 文字+留白完成信息 → 2. preset shape/line/Unicode 等可编辑原语 → 3. outline 标注 `[建议补图：…]`。不得用外部图片、SVG 整图或截图补位。

## 画布与交付目标

**默认（PPT Live + 可编辑 PPTX）**：画布严格为 **1280px × 720px**，写作 `body { width: 1280px; height: 720px; }`。不得使用其他画布尺寸、响应式画布或缩放替代。

### Authoring subset（生成规则）

- 唯一导出链路是 **editable HTML → EditableSlideScene → OOXML**。每页严格为 **1280px × 720px**，不得建议或设计第二条导出链路。
- 只使用 solid color；不得生成 CSS gradient 或 `background-image`。背景、border、圆角只放在 `div` 等几何容器，文字标签不得承载 background、border 或 shadow。
- `box-shadow` 只支持单层 outer、非 inset、zero spread 的原生映射；多层 shadow 只取首个可用层，负 spread 按 0 近似，inset 等其余不支持形态导出时自动移除，不得依赖。`text-shadow` 任何非 `none` 形态在导出时一律自动移除，不得依赖其呈现层次。
- HTML 文字只可放在 `<p>`、`<h1>`–`<h6>`、`<li>` 中；`span` 只作这些标签内的文本 run，不得生成 `div` 裸文字。
- 禁止 CSS `filter`、`mask`、generated content、animation、外部资源和复杂/filled SVG path；禁止任意顶点/非严格对称 polygon，仅允许严格对称 triangle/diamond。
- 线与曲线优先直接生成 `line` 或 `polyline`；只有确有必要时才写兼容边界所列的 path 子集。
- Authoring 流程箭头只由 editable line + CSS border triangle，或 SVG line + strict symmetric triangle polygon 构成。
- 表格必须是真实 `<table>` 并导出为 native `a:tbl`；图表、流程箭头、虚线和曲线必须使用支持的可编辑原语。
- intentional 图片只允许内联 base64 PNG、JPEG、WebP，且不得承载文字、图表或几何；禁止 GIF，因为无法证明其为静态内容。
- 禁止任何正向 rasterize、screenshot 或 fallback 建议；无法表示时停止生成并报告具体元素。

### Converter legacy rewrite boundary（兼容边界，不是生成建议）

- 本边界只用于兼容既有输入，不是生成许可；authoring agent 仍必须遵守上面的更严格 subset。
- SVG `text` 是 converter 支持的 SVG 原语；`div` 裸文字仅属 repair 兼容，authoring 不应生成。
- path 仅支持 `M/L/H/V/C/S/Q/T/Z`，必须 `fill:none`；`Z` 可以闭合 path，但拒绝 `A` 和任何 path/ancestor `transform`。
- `C/S/Q/T` 曲线由 converter 采样为多段 editable line，不是 PowerPoint curve；authoring 优先 `line`/`polyline`，确需 path 时才使用上述子集。
- SVG polygon 只识别严格对称的 triangle 和 diamond；任意顶点或非严格对称 polygon 都会被拒绝。
- legacy CSS 仅兼容受限 `linear-gradient`：角度接受 `deg`、`turn`、`rad`、`grad` 与方向关键字；位置只接受 percentage stop，缺省 stop 均匀分配。
- converter 拒绝 `radial-gradient`、px/em stop、double-position stop、color hint、不支持颜色和非法 alpha；合法 gradient 被采样为 editable solid strips，这不是生成建议。
- legacy 单层 hard ring `box-shadow`（`0 0 0 Npx`、非 inset、blur=0）会被重写为同心可编辑 shape；authoring 仍应优先 zero-spread outer shadow，不得依赖 ring rewrite。

<!-- End editable contract -->

`references/editable-pptx.md` 是完整约束；其他 references 与 style presets 只提供视觉意图，冲突时本 authoring contract 优先。

```
当前工作区根目录/
├── project.json      # outline[], slide_order[], style, assumptions
├── brand/
├── slides/slide-XX.html
├── thumbnails/       # 系统生成
└── versions/         # 系统快照
```

架构选型（多文件 vs 单文件 deck-stage）、聚合 `index.html`、grammar showcase → `references/slide-decks.md`；其中可编辑交付同样强制 1280×720 editable-only 契约。

## 防溢出预算（写前心算，一次写对）

溢出 = 渲染后内容超出 1280×720px 画布，是最常见的硬伤。写每页 HTML 前先做**垂直预算心算**，一次写对：

- 可用高度恒等式：`720px = 标题区 + 正文区 + 底部脚注 + 安全边距`。标题区按 93–127px、脚注行按 27–33px、**底部安全边距 ≥ 48px（0.5in，PPTX 导出校验线）** 预留，正文区实际只有约 **520–560px**。
- 预算估算法：正文每行 ≈ `font-size × line-height`（如 12px × 1.5 ≈ 13.5pt/行）；表格每行 ≈ 字号 + 上下 padding；卡片 = 内容行数 × 行高 + padding × 2 + 间距。**所有块的预算之和必须 ≤ 正文区高度**，估不下就删行、合栏或拆页，禁止靠缩字号硬塞。
- 兜底结构：`body { overflow: hidden; }`，根容器 `display: flex; flex-direction: column; height: 720px;`，可伸缩区给 `flex: 1; min-height: 0; overflow: hidden;`——即使估错也只在容器内裁切，不撑破画布。
- 高风险元素单独检查：满版表格（行数 × 行高先算再写）、多行卡片网格、长 bullet 列表、流程图标注。一个元素预算超了就整体减行，而不是指望浏览器挤一挤。
- 任何文本框（>12px 字号）的底边必须离画布底部 ≥ 0.5in，否则 PPTX 导出会判为越界。

## 数据与信息可视化意识（启发式）

遇到数字、比较、时间、流程、层级、因果或空间关系时，**主动想一次可视化是否比当前文字更有效**。这不是逐页门禁，也没有图表配额或固定映射；最终形式由 Agent 结合主题、受众、叙事角色、数据质量、视觉风格、页面节奏和导出目标自行决定。结构化文字、摄影、留白或纯排版都可能是更好的答案。

可用下面的问题帮助判断，不要求机械逐项执行：

1. 这页在整套叙事中承担什么角色：建立情绪、解释概念、提供证据、推动比较，还是促成行动？
2. 观众要看见的是数值大小、变化、构成、关系、步骤，还是一句观点本身？
3. 图表/图示是否真的比文字更快、更清楚，并与当前风格相符？
4. 如果用了可视化，它是否直接服务于标题结论，而非只是让页面“看起来有数据”？

以下只是常见候选，不是模板规则：

| 信息意图 | 可考虑的形式 |
|----------|--------------|
| 指标与基准 | 大数字、进度/目标对比、短注释 |
| 排名与差异 | 条形图、点图、矩阵、表格 |
| 趋势与阶段 | 折线/柱状、时间线、阶段带、small multiples |
| 构成与变化来源 | 堆叠条、环形图、瀑布图、前后对照 |
| 分布与关联 | 点图、直方图、散点图、2×2 |
| 流程与系统 | 流程图、泳道、架构图、关系图 |
| 层级与论证 | 树状图、问题树、证据链、结构化文字 |

**技术方案 / 工程分析 / 项目架构类内容的特别触发**：当 deck 主题涉及软件架构、系统设计、技术方案、工程复盘、数据处理流水线等内容时，**架构图和流程图几乎总是比文字更有效，必须在对应页面使用，而不是用编号列表或散文描述系统组成与处理步骤**。具体地：
- 页面讲「系统由哪些模块组成」「模块间依赖关系」→ **分层架构图**（不是文字列表）
- 页面讲「请求/数据/任务经过哪些步骤」→ **线性流程图带箭头**（不是编号段落）
- 页面讲「多个角色/团队如何协作」→ **泳道图**
- 页面讲「为什么出这个故障/问题」→ **因果链/问题树**

实现方法见 `references/data-information-visualization.md` 第 6.1 节，提供了分层架构图、线性流程图、泳道图、因果链的纯 CSS 可编辑 snippet，直接套用。

原则：

- 同一份数据可以有多种正确表达；选择最符合该页叙事意图和视觉语言的一种，必要时创造混合形式。
- 一个主视觉通常更利于聚焦，但对仪表盘、对照分析、教学拆解等页面可使用多个协调视图。
- 数据图应说明单位、时间、口径、来源或「估算」；没有可靠数字时不得编造。
- 用强调色引导结论，但保持全 deck 的对象颜色与视觉语义一致。
- 只选择能由受支持的 editable shape、line、table 和文本组成的图表；表现形式不得以 3D、复杂 path、图片化图表或其他不可映射视觉为前提。
- 可编辑 PPTX 的表示范围是技术硬约束；复杂图形必须改写为受支持的 shape、line、table 和文本组合，无法表示时停止生成并报告具体元素，不得转图片或建议 fallback。
- 更多选择思路、信息图模式和实现提示 → `references/data-information-visualization.md`；把它当作设计词汇库，不是逐条执行清单。

## 5 种风格

| 风格 | 何时选 |
|------|--------|
| **Pentagram 信息建筑**（默认） | 商务、汇报、数据 |
| **Müller-Brockmann 网格** | 学术、技术 |
| **Build 极简** | 高端品牌、宣言 pitch |
| **Kenya Hara 留白** | 文化、艺术 |
| **Takram 柔和科技** | 设计、科技人文 |

DNA 与样例 → `references/design-styles.md`。

## 风格预设（style presets）

当输入里出现 `style.stylePreset`（或用户点名某个预设名）时，按以下流程套用预设：

1. **优先用已给样式，不要默认 Read**：若输入已含 `style.palette`（或 MiniApp/宿主已写入完整 style），**禁止**再 `Read references/style-presets/*`；直接用 palette + 下表「一句话 DNA」落地视觉身份。只有输入没有可用 palette、且用户明确点名预设、你确实需要完整视觉细则时，才允许一次 `Read references/style-presets/<stylePreset>.md`。
2. 预设只接管「视觉身份」：配色、字体气质、装饰语言、版式偏好。本 skill 的核心原则全部继续生效——断言式标题、单页一结论、信息密度、反 AI slop、1280×720px 画布、可编辑 authoring contract、不许溢出（用户明确要求压力测试/故意溢出时除外）。
3. 从上面 5 种设计哲学中选最接近的一种作为版式骨架（structural grammar），预设负责皮肤；两者冲突时以信息传达优先、弱化装饰。
4. 预设文件缺失或 key 未知时，回退到 5 种哲学中最接近的一种，并沿用输入提供的 palette。

| styleKey | 预设 | 一句话 DNA |
|----------|------|------------|
| `clean-business` | 简洁商务 | 纯白背景、平静蓝强调、产品文档式极简 |
| `insight-report` | 洞察汇报 | 把 raw 数据转为有效信息：数据可视化优先、版式多样、完整句子论证与固定分析框架 |
| `minimal-gallery` | 黑白极简 | 严格网格、黑白灰、画册式留白 |
| `bold-editorial` | 黑白红大字 | 白底黑色大字、红色点缀、非对称编辑排版 |
| `yellow-magazine` | 黄底黑字杂志 | 高识别度黄底黑字、手写点缀、杂志感 |
| `pink-pop` | 粉色波普 | 哑光粉底、精致编辑或街头波普两种力度 |
| `creative-studio` | 黑橙创意 | 白底黑字血橙强调、干练机构感 |
| `retro-pop` | 复古海报波普 | 复古色调、粗体海报排版、可混搭古典雕塑 |
| `dark-neon` | 暗黑霓虹 | 深色底、故障艺术或霓虹制图两种方言 |
| `pop-infographic` | 波普信息图 | 鲜艳粉青配色、有机形态或复古像素 |

## 工作流

**速度优先**：模型回合很贵。Skill 返回后**下一轮工具必须是 Write `project.json`**（完整 outline）；禁止先 Read seed/`project.json`、禁止先读 style-presets（见上）、禁止长篇规划思考。不要为审计 Read/Grep/Glob 已写页面。

1. **立刻落盘大纲（优先于研究）**：Skill 后马上 Write `project.json`（`status: "planning"` + 完整 `outline[]` / `slide_order`），再研究或写页。UI 依赖大纲显示进度。**若主题涉及技术方案/工程/系统/项目分析，必须在 outline 阶段就识别出哪些页是「系统组成」「处理流程」「多角色协作」「根因分析」，并标注用架构图/流程图/泳道图/因果链**（参考上方「技术方案类内容的特别触发」）。
2. **按需研究**：仅当用户提供 URL、明确要求事实核验，或主题依赖外部时效数据时才 WebSearch / WebFetch；否则跳过研究，直接写页。不要为“显得认真”而默认检索。
3. **直接按 outline 写页（不要额外 showcase 轮）**：封面 `slide-01` → 其余页。每轮并行 Write **2 页** HTML（单页过大时降到 1 页）。**不要**先做「2 页打样再批量」的额外回合。正常主题保持一页一结论与可编辑原语；只有用户明确要求高密度/压力测试/故意溢出时才拉满元素。**写每页时一次写对**：写之前先做垂直预算心算（见「防溢出预算」），写完即止。
4. **同轮收尾**：写完最后一批页面时，**同一轮工具调用里**再 Write/Edit `project.json` 把 `status` 设为 `"complete"` 并结束。禁止单独开一轮只做 Glob/LS/Edit。缺文件只补缺失页，不做逐页内容审计。
5. **改稿范围**（输入里若有 `scope`）：
   - `deck`：可改 outline 与任意 `slides/*.html`
   - `current_slide` / `slide_index`：**只改指定页**，不动其他 slide 文件

## 单页模板（1280×720px · Pentagram）

```html
<!DOCTYPE html>
<html lang="zh-CN"><head>
<meta charset="UTF-8">
<style>
  *,*::before,*::after { margin:0; padding:0; box-sizing:border-box; }
  body {
    width: 1280px; height: 720px;
    font-family: system-ui, -apple-system, "PingFang SC", "Source Han Sans SC", sans-serif;
    background: #FAFAF7; color: #1A1A1A;
    overflow: hidden; position: relative;
  }
  .grid { position: absolute; inset: 48px 60px; display: grid; grid-template-columns: repeat(12, 1fr); gap: 12px; }
  h1.title { grid-column: 1 / span 10; font-size: 32pt; font-weight: 700; line-height: 1.15; }
  p.subtitle { grid-column: 1 / span 8; margin-top: 12px; font-size: 14pt; color: #555; }
  ul.bullets { grid-column: 1 / span 10; margin-top: 28px; font-size: 13pt; line-height: 1.55; padding-left: 1.2em; }
  p.footer { position: absolute; left: 60px; bottom: 30px; font-size: 9pt; color: #888; }
</style></head>
<body>
  <div class="grid">
    <h1 class="title">断言句标题</h1>
    <p class="subtitle">本页核心结论一行说清</p>
    <ul class="bullets">
      <li>要点一（≤20 字）</li>
      <li>要点二</li>
    </ul>
  </div>
  <p class="footer">Deck 标题 · 03 / 10</p>
</body></html>
```

可编辑 PPTX 完整 authoring contract、合并文本框 `data-pptx-merge`、常见错误 → `references/editable-pptx.md`。

## 多轮编辑

- 改 outline 某项 → 同步重写出对应 `slide-XX.html`
- 加页 → outline + 新 `slide-NN.html` + 更新 `slide_order`
- 删页 → 从 `slide_order` 移除 id（文件可保留便于回滚）
- 单页指令 → 只动该页 HTML

## 参考路由

| 主题 | 文件 |
|------|------|
| 多文件/单文件架构、交付格式决策、showcase | `references/slide-decks.md` |
| 可编辑 PPTX 约束 | `references/editable-pptx.md` |
| 风格 DNA | `references/design-styles.md` |
| 风格预设（stylePreset）视觉规范 | `references/style-presets/<styleKey>.md` |
| 文案与排版 | `references/content-guidelines.md` |
| 场景版式（含技术方案/工程分析/架构汇报场景） | `references/scene-templates.md` |
| 数据可视化、信息可视化、图表与架构图/流程图实现 | `references/data-information-visualization.md` |

## 不在范围

- 视频/动画/配音/TTS、多模态生图、通用网站 SEO

---

**节奏**：先纲 →（大 deck 先 2 页定 grammar）→ 逐页 HTML → 快、稳、像设计过的幻灯片，不要长开场白。

