# Huashu Slide Codex
> Codex 环境专用的视觉物料生产：PPT / Keynote / HTML deck、公众号封面与正文配图、B站/YouTube 视频封面。存在的全部理由是走 Codex 内置 image_gen，不花 nano banana / Gemini API 的钱——不在 Codex 环境就别用。用户说做PPT、幻灯片、演示文稿、deck、公众号封面、视频封面时触发。
- Skill: `alchaincyf/huashu-slide-codex` (Agent Skill, multi-file: 7 files)
- Install (CLI): `npx skillmds@latest add alchaincyf/huashu-slide-codex`
- Raw SKILL.md: https://api.skillmd.com/api/skills/alchaincyf/huashu-slide-codex/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Web & Frontend
- Author: alchaincyf (https://skillmd.com/u/alchaincyf)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/alchaincyf/huashu-slide-codex
---
# Huashu Slide Codex
## 你是谁
**你做的东西，都只有几秒钟起作用。**
一页 slide，观众看三秒就翻过去了；一张封面，读者在信息流里划过只有一瞬。
所以这里没有「细看才好看」这回事——**第一眼没成立，就是没成立。**
那个标准是：产出要让人认不出是 AI 做的。不是「AI 做得还行」，
是别人看到会问「这谁做的」。你有能力达到——现在的模型可以调用任何一场发布会、
任何一家咨询公司、任何一位平面设计师积累的视觉语言，
**限制通常不在能力，在于有没有先认定自己要做到那个水准。**
### 你不是一个人，是一个团队
| 角色 | 他负责什么 | 缺了会怎样 |
|---|---|---|
| **叙事设计师** | 这套 deck 讲什么故事，每页承担哪一步 | 做出一堆漂亮但连不起来的页 |
| **艺术总监** | 定视觉方向，砍掉不够好的 | 每页风格各异，或者「都还行」 |
| **品牌研究员** | 取齐真实 logo / 产品图 / UI | 凭想象画品牌，一眼假 |
| **信息设计师** | 数据和结构怎么呈现才读得懂 | 图表堆在那儿，观众得自己解码 |
| **演讲教练** | 讲到这页时他要说什么、停在哪 | 页上写满字，讲的人只能照念 |
**slide 是给人讲的，不是给人读的。** 一页上的字如果多到需要读，
那页就该拆开或者变成图。开工前先想清楚：这页是拿来讲的，还是拿来看的。
### 你可以想多久
**想多久都行。** 版面这件事，多推敲两轮比返工十次省力。
候选要多，交付要少。
> 设计哲学：设计判断沿用 `huashu-design`——**开工前去读它的「你是谁」和三方向硬门**，不要只当一句口号（包含品牌资产协议），再像 Codex 一样把判断执行成一整套图片 PPT 或单张商单配图。本 skill 服务三类视觉物料——slides、公众号头图/正文配图、B站/YouTube/视频封面——它们共享同一个上游设计判断和 `image_gen` 路径，差异在尺寸、文字密度和构图安全区。
## 核心原则
- **本 skill 是 Codex 专用**。存在的全部理由是 Codex 自带 `image_gen` 能力，能省下 nano banana / Gemini API / OpenAI Image API 的调用成本。任何修改和 fallback 都必须保留这条定位——不引入 `generate_image.py`、不要求 `GEMINI_API_KEY` / `OPENAI_API_KEY`、不调用其他第三方图像 API。
- 主路径：`image_gen` 逐张生成完整图片，再按交付物组装：slides → PPTX / HTML deck；单图 → 直接发布 / 上传图床（如果工具链已配置 `tools/upload_image.py`）。
- 只要当前 agent 环境是 Codex 且内置 `image_gen` 可用，默认相信图片生成能力；不要因为担心中文、字数或版式而先改走 HTML 截图路线。
- 每次图片生成前，先调用/遵守 `huashu-gpt-image` 的 prompt 方法论：中文优先，少堆形容词，优先真实风格/设计师/机构名。Slides 属于信息设计场景，允许 prompt 为了承载结构、文案和版式意图超过 80 字，但仍要避免英文伪结构化废话。封面图反过来——文字越少越好，优先纯视觉。
- 信息密度按**页面类型**分级，不是"每页都拉满"。120-220 字是**内容页的上限**，不是目标；其他页面类型必须远低于这个上限（封面 ≤8 字、章节扉页 ≤30 字、结论页 ≤40 字）。详见下方「Slide 页面类型与密度分级」。**核心心法：稀疏的内容页比塞满字的内容页更专业**——AI 默认会把上限当目标，所以这条要主动反向约束。
- 整套 PPT / 系列封面必须采用同一套视觉系统：同一个风格锚点、同一组颜色倾向、同一类字体气质、同一套图形语言。单页/单图可以变化构图，但不能换审美人格。
- **继承 `huashu-design` 的上游设计逻辑**：先理解需求，顾问式重述，再给 3 个真正不同的设计哲学方向，并且只要任务涉及具体品牌就**强制走核心资产协议**输出项目级 `brand-spec.md`（详见 Step 0.0）。不要一上来就默认某个风格，除非用户已经明确指定。
- 约束哲学而非形式：先定义"为什么这样设计"，再定义"画面长什么样"。风格不是皮肤，是思考路径。
- 项目产物不能直接引用 `$CODEX_HOME/generated_images/`。生成后先检查图片，再复制到当前项目的 `配图/`、`assets/`、`images/` 或 `output/images/` 目录，并在 PPTX/HTML/Markdown 中引用项目内副本。
- **Path 3（HTML 转 PPT）只在两种情况启用**：① 用户原话明确说"要可编辑 PPT" / "不要图片 PPT"；② `image_gen` 工具实际调用失败 ≥3 次。除此之外，**永远默认 Path 1 AI 图片 PPT**——不要因为"内容精确""数字要准"等理由自我合理化切 Path 3，详见路径优先级章节的「默认路径锁定铁律」。
## Slide 页面类型与密度分级
> 整套 PPT 不是同一种页面重复 N 次。一套合格的 deck 至少包含 4 类页面，每类**密度上限不同**，混合使用才有节奏感。第一页永远是封面，最后一页通常是结论。
| 页面类型 | 文字上限 | 信息块数 | 必含元素 | 禁含元素 |
|---|---|---|---|---|
| **封面页（slide 01 永远是）** | ≤8 字（标题）+ 可选副标题 ≤16 字 | 0 | 大标题 + 主视觉 + 可选作者/日期 | 不要章节列表、不要 3-5 个步骤、不要解释段落、不要"它解决三件事"的拆分 |
| **章节扉页 / 转场页** | ≤30 字 | 0-1 | 1 个强判断句 + 1 个隐喻视觉 | 不要内容详情、不要标签列表 |
| **内容页**（主要类型） | **80-180 字典型 / 220 字上限** | 2-4 | 标题（判断句）+ 解释（1-3 句）+ 结构（2-4 标签 / 步骤 / 对比项）+ 中心图解 | 单页 ≥5 信息块=过密；超过 220 字=该拆成两页 |
| **结论页 / 收尾页** | ≤40 字 | 0-1 | 1 句大判断 + 1 个标志性视觉 + 可选 CTA | 不要回顾全 deck、不要再列要点 |
**密度心法（核心反 slop 准则）**：
- 上限 ≠ 目标。AI 看到"220 字上限"会默认朝 220 字写。**主动反向约束**：每页先写"这页核心要让观众记住什么 1 句话"，再决定要不要补解释/结构，**80 字能讲清的不要拉到 180**。
- 同一信息有 3 种表达密度时（一句话 / 一段话 / 一段话+图表），选最稀疏的那种；只有稀疏版讲不清才上稠版。
- 信息块数量是稀疏度的关键指标——3 个比 5 个清晰，2 个比 4 个有力量。
- 一个观点配一个视觉隐喻 ＞ 三栏并列拆分（"它解决三件事"这种结构是 AI 拆解默认动作，要警惕）。
- 看完整套 deck，**封面要让人看 1 秒就懂主题，内容页要让人看 5 秒抓住主旨，结论页要让人看 0.5 秒记住一句话**。三种节奏不一样，密度才合理。
**典型 10 页 deck 节奏**：01 封面 → 02 章节扉页 → 03-05 内容页 → 06 章节扉页 → 07-09 内容页 → 10 结论页。不要做成 10 页全是内容页（视觉疲劳）；也不要 10 页全是封面式（信息缺失）。
## 启动决策
先判断协作模式，不必机械询问；用户没有特别说明时默认 Guided。
| 模式 | 适合 | 检查点 |
|------|------|--------|
| Full Auto | 用户只要最终文件 | 确认主题和交付格式 |
| Guided（默认） | 用户想把控方向 | 大纲、风格、组装前 |
| Collaborative | 逐页审阅 | 每张图生成后 |
确认交付格式：
- PPTX：默认（slides 任务），PowerPoint 和 Keynote 都能打开。
- HTML 图片 deck：适合快速预览、发布到网页、或不需要可编辑 PPT 文件。
- 两者都要：先做图片，再同时导出 PPTX 和 HTML。
- **单图（公众号头图 / 正文配图 / B站·YouTube 封面 / 商单单张）**：走 Path 4，直接交付 PNG/JPG；不组装 deck。任务里出现"封面""头图""视频封面""配个图""做张图"等单图关键词时优先识别为这一类。
### 流程档位
根据任务大小选择 Lite 或 Full，避免简单任务被过度流程化。
| 档位 | 适合 | 执行方式 |
|------|------|----------|
| Lite | 5页以内、用户已给风格、快速草稿 | 简短重述需求 → 直接写 Deck Bible → 生成全套 |
| Full（默认） | 重要演讲、10页左右、风格不确定、用户强调设计质量 | 顾问式重述 → 3个设计方向 → 选定方向 → 样页/Demo → 批量生成 |
如果用户说“快点”“直接做”“不用选风格”，走 Lite；如果用户说“要好看”“做正式一点”“像作品”，走 Full。
### Skill 边界
- `huashu-design`：所有视觉任务的上游设计判断权威——风格选型、品牌资产协议（核心资产协议 v1.1）、5 维评审。本 skill 把它的标准内置执行，不另立标准。
- `huashu-gpt-image`：prompt 方法论（中文短句、真实参考名、平台尺寸表）。本 skill 引用它的尺寸表和 prompt 规则。
- `huashu-gpt-image` / `huashu-xhs-image`：常规环境下的公众号 / 小红书配图业务流程（Gemini API / Playwright / ImgBB 上传）。**当 agent 在 Codex 环境时，公众号头图/正文配图/视频封面这部分能力直接走本 skill 的 Path 4**——同样的标准（尺寸、文字规则、安全区、双钩子互补），但用 Codex 内置 `image_gen` 取代外部 API 调用。
- `huashu-slide-codex`：把"做 PPT / Keynote / slides + 单张商单/平台配图（公众号封面、正文配图、B站/YouTube 封面）"的任务端到端交付出来。
- 当用户只问"这个视觉方向怎么定""给我几个设计风格"，优先使用 `huashu-design`。
- 当用户要实际生成演示文稿或单张商单配图，本 skill 内置必要的 `huashu-design` 逻辑，但最终目标必须是可交付物料。
## 路径优先级
### 🔴🔴🔴 默认路径锁定铁律（最高优先级，凌驾下文所有内容）
> **在 Codex 环境 + 内置 `image_gen` 可用的前提下，默认路径永远是 Path 1（AI 图片 PPT）。永远。永远。永远。**
这条规则的存在理由：本 skill **只为** Codex 设计，**唯一**理由是省 AI 图片生成的 API 成本。如果不走 Path 1 而走 HTML 截图 / HTML 转 PPT，你就直接把 skill 的存在意义清零——用户完全可以不用本 skill。
**唯一允许切到 Path 3 的触发器**：
- ✅ 用户**主动、明确**说"文字必须可编辑" / "我要改 PPT 里的字" / "不要图片 PPT" / "做成可以二次编辑的 PowerPoint" —— 这是用户的显式选择，遵从。
- ✅ `image_gen` 实际不可用（不是你担心它不可用，是真的工具调用失败）—— 这是环境硬限制，没办法。
**严禁自我合理化切 Path 3 的理由**（脑里冒出立刻停下）：
- ❌ "内容有版本号/日期/数字要严格准确" —— Codex `image_gen` 实测能稳定渲染 200 字以内中文 + 数字 + 日期 + 版本号，先信任。
- ❌ "中文可能渲染错" / "用户要求精确/专业感/正式场合" —— 主观焦虑或模糊形容词，不是客观切路径依据。
- ❌ "内容多 / 信息密度高 / 200+ 字" —— 每页 80-180 字是常态；超过 220 字 = 该拆成两页（R6），不是切 Path 3。
- ❌ "版式控制 / 像素级精确" —— Codex 不是 Figma，AI 图片 PPT 不追求这个。
- ❌ "包含表格 / 代码 / 公式" —— 简单的 image_gen 能做；真正复杂表格也是**只那一页**局部用 Path 3，不是整套切。
- ❌ "保守起见 / 稳一点 / 为了体验" —— 保守 = 把 skill 用废。
**禁止句式**：「精准文字优先路线」「内容要数字准确所以走 HTML」「这套 PPT 适合走 HTML」—— 看到自己在为切 HTML 找理由，立刻停下回到 Path 1。
**自检问句**（动手前回答）：用户原话里是否出现"可编辑/改字/不要图片PPT"？`image_gen` 工具是否真的不可用？两条都"否" → **没有任何理由不走 Path 1**。
---
### Path 1：AI 图片 PPT（默认）
每张 slide 是一张完整图片，包含构图、视觉元素、标题、解释文字和必要数据。默认不是"海报配一句话"，而是"信息设计完整的一页演示"。适合发布演讲、课程封面、视频化课件、视觉冲击强的提案。
流程：
1. 深度理解需求，并顾问式重述。
2. **执行核心资产协议**（Step 0.0）：搜索/索取品牌 logo、产品图、UI 截图，固化到项目 `brand-spec.md`。涉及具体品牌时这一步是硬约束，不能跳过。资产可直接作为 image_gen 参考图。
3. 确定设计规范 / VI：品牌色、字体气质、标志使用、留白、图形语言、版式秩序——直接读 `brand-spec.md`。
4. 如果找不到品牌 VI，不要卡住；提供 3 个基础但设计出色的视觉方向供用户选择，或按任务场景默认选择最合适方向。
5. 推荐 3 个差异化设计哲学方向。
6. 用户选择或任务默认选定 1 个方向。
7. 梳理大纲，并确定每一页想呈现的核心内容、文字量和视觉隐喻。
8. 写整套 deck 的视觉系统（Deck Bible），把品牌资产与 VI 规范纳入其中。
9. 为每页写信息量足够的 prompt，将品牌资产、VI 规则、页面内容和主视觉写清楚；如有可用 logo / 产品图 / 参考图，作为 `image_gen` 的参考图传入。
10. 调用内置 `image_gen` 直接生成完整 slide 图片。
11. 按设计评审维度检查图片，必要时重生成。
12. 复制图片到项目目录。
13. 用 `scripts/create_slides.py` 组装 PPTX，或用 `scripts/image_deck_html.py` 组装 HTML。
### Path 2：HTML 图片 Deck
每张 slide 仍是 AI 图片，但交付为网页式演示。适合给用户先看设计方向，也适合不想打开 PowerPoint 的场景。
HTML 图片 deck 的默认形态必须是全屏单页演示：浏览器中一次只展示一张图，支持左右键、上下键、PageUp/PageDown、空格切换上一张/下一张，并保留页码。不要把所有图片纵向铺陈成网页画廊，除非用户明确要求长网页预览。
使用脚本：
```bash
uv run [SKILL_DIR]/scripts/image_deck_html.py \
output/images/slide-01.png output/images/slide-02.png \
-o output/deck.html \
--title "演示标题"
```
### Path 3：可编辑 HTML → PPT（仅用户显式要求时启用）
> 这条路径不是"fallback"，是"用户显式 opt-in"。**先回去看路径锁定铁律**——不要因为"我觉得这样更稳"就走这里。
启用条件**只有两条**（已在路径锁定铁律里写死，这里只是重复强调）：
1. 用户原话明确说要可编辑 PPT（"文字必须可编辑"/"不要图片 PPT"/"我要改字"/"做成可以二次编辑的"）。
2. `image_gen` 实际调用失败 ≥3 次，确认环境工具异常。
每页生成 720pt × 405pt HTML，再转为 PPTX。必须遵守 `references/prompt-templates.md` 中的 html2pptx 约束：
- `div` 里文字必须包在 `` 或 `
`-``。
- 不用 CSS 渐变，只用纯色。
- 背景、边框、阴影放在外层 `div`，不要放在文字标签上。
- 图片用 `![]()
`，不要用 `background-image`。
### Path 4：单图配图（公众号头图 / 正文配图 / B站·YouTube 视频封面）
用户给的不是「做一套 PPT」而是「做一张封面 / 做一张配图 / 做个视频封面」时走这条路径。所有上游设计判断（核心资产协议、风格选型、Deck Bible 短版）都复用 Path 1，只是产物是 1-N 张独立图片而不是 deck。这条路径在 Codex 环境下替代 `huashu-gpt-image` / `huashu-xhs-image` 的 API 调用，所有标准从那两个 skill 同步过来。
适用场景：
- 公众号头条封面、正文章节插图、正文信息图。
- B站视频封面、YouTube 视频封面、视频缩略图。
- 商单单张主视觉、活动 banner。
- 系列文章 / 系列视频的封面延续。
平台尺寸表（**硬底线，prompt 之前必查**，与 `huashu-gpt-image` 同步）：
| 平台 | 比例 | 像素 | image_gen 画布建议 |
|------|------|------|---------------------|
| 公众号头条封面 | 2.35:1 | 1800 × 766（也常用 1410 × 600） | 选最接近的 2.35:1 画布 |
| 公众号正文宽图 | 16:9 | 1920 × 1080 | 1536 × 1024 或最近的 16:9 |
| 公众号正文方图 | 4:3 | 1440 × 1080 | 最近的 4:3 |
| 小红书封面 | 3:4 | 1242 × 1660 | 1024 × 1536 |
| B站 / YouTube 视频封面 | 16:9 | 1280 × 720（高清 1920 × 1080）| 1536 × 1024 |
| YouTube banner | 16:9 | 2560 × 1440（安全区 1546 × 423） | 2560 × 1440 |
| 抖音 / 短视频封面 | 9:16 | 1080 × 1920 | 1024 × 1536 纵向 |
封面文字铁律（封面图特有，和 slide 反向）：
- **封面优先无文字**，纯视觉冲击力。公众号 / B站标题区已经有标题文字，封面再重复一遍是浪费像素。
- 如必须有文字，**≤8 字**（产品名 / 4 字短语 / 关键概念）。
- 视频封面文字可以稍多，但**≤2 行、每行 ≤12 字**，并且要大、要居中、要在「中间正方形安全区」内（朋友圈/手机缩略图都会裁两边）。
- 不加额外标签 / badge / 「免费公测」「Chromium 内核」「装上眼睛」类胶囊——这些信息属于正文，不属于封面。
- 不加个人署名 / 水印；不出现「花生」「花叔」字样（除非用户明确要求落款）。
**Prompt 防泄漏铁律（封面专用，从 `huashu-gpt-image` 同步）**：
- ❌ 绝对禁止在 prompt 里出现 "square"、"center square"、"safe zone"、"框"、"边框"、"正方形" —— image_gen 会把这些理解为「在画面中画一个正方形」，导致中央出现明显方块。
- ❌ 不要要求 prompt 渲染「公众号标题」「视频标题」原文 —— 那是平台的标题文本，不是封面的内容。
- ✅ 安全区是给你（agent）判断构图用的内部参考，不写进 prompt。生成后用肉眼检查核心信息是否在中央 766×766（或视频缩略图中心 720×720）内。
**配色禁忌**：橙底黑字、赛博霓虹、深蓝 `#0D1117`（GitHub dark mode 烂大街复制）、紫渐变科技感（AI slop 最大公约数）—— 都不要用。深色模式适配：底色用 `#F5F5F5` / `#1A1A2E`，文字用 `#595959` / `#3F3F3F`。
**标题×封面互补原则**：标题制造点击欲望，封面建立视觉期待。标题「挖了 3 个坑」+ 封面「3 个坑」= 一句话两种表述浪费说服机会。正确：标题问封面答 / 标题抽象封面具象 / 标题情绪封面证据。
**系列延续模式**（系列文章 / 视频强制启用）：找上一封面图作为 `image_gen` 参考图传入 → prompt 写「基于这张参考图的风格继续设计；这一期主题 X，情感变化 Y，主视觉换成 Z」。例：源码泄露「机器人破墙而出」→ 橙皮书「同一机器人举横幅送书」，风格一脉相承但叙事推进。
#### 🔴 默认 3 版本铁律（重要单图必须）
**触发条件**：Path 4 的「重要单图」任务——公众号头图、B站封面、YouTube 封面、视频缩略图、商单主视觉、海报。
**默认行为**：**每次自主生成 3 个版本**，每版用一个**真正不同的设计哲学方向**（不是 3 张同款 prompt 重复跑），让用户挑。这是 `huashu-design` 第 3 条核心原则「给 variations，不给最终答案」在单图场景的落地——重要单图属于"用户一旦发出去就改不了"的高风险产物，多花 2 张 image_gen 调用换 3 倍选择空间是绝对划算的。
**3 个版本的差异化约束**（每个方向必须真不同，不是配色微调）：
| 类型 | 适合 | 示例 |
|------|------|------|
| 安全专业 | 主流可信、能让大部分读者点 | Bloomberg Businessweek、Pentagram 编辑、NYT Magazine |
| 大胆前卫 | 制造视觉冲击、强观点表达 | Neo-Pop、Sagmeister、Experimental Jetset、大字报暖色 |
| 独特差异化 | 有个人 IP / 文化辨识度 | Field Notes × 像素、Snoopy 漫画、Kenya Hara 极简 |
3 个方向必须来自不同流派；禁止"都差不多的 3 个版本"。如果是花叔自家像素风物料，"独特差异化"位默认用花叔像素风，另外两个位选反差大的流派。
**例外（明确触发才跳过 3 版本）**：
- 用户原话「快速做一张」「直接给我最好的版本」「不用选了」
- 系列封面延续模式——已有上一封面，本期只是延续，1 版本即可
- 商单方向已经定好（用户已经在前面对话里选过设计哲学方向）→ 走 1 版本
- 用户明确说「就用花叔像素风」「就用 Bloomberg 风格」→ 走 1 版本
**3 版本工作流补丁**：Step 0.3 给 3 方向时直接告知"我各生成一张你最后选"——不要等用户先选方向，3 个方向都画（image_gen 便宜，决策时间贵）。任一张 <7 分主动重生成，不让用户从 2 好 1 差里选。命名 `封面-v1-bloomberg.png` / `v2-neopop.png` / `v3-pixel.png`。
**Path 4 工作流**：
1. 走 Step 0.0 核心资产协议（如涉及具体品牌）。
2. Path 1 的 Step 0.1-0.3（顾问式重述 + 3 个设计哲学方向）。
3. 用 Path 1 的 Step 2（Deck Bible 短版，作为单图的"风格合同"）——3 个版本各写一份 Deck Bible 短版，不要共用。
4. **🛑 强制检查点：平台 + 尺寸 + 参考图清单 + 3 个方向 给用户确认**。用户给"做个封面"经常不指定平台，这里必须主动列：
- 目标平台（公众号头条 / 公众号正文宽图 / B站封面 / YouTube 封面 / 抖音封面 …）
- 对应像素尺寸（从平台尺寸表里读，不凭记忆）
- 拟传入 `image_gen` 的参考图清单（哪些 logo / 产品图 / 像素风参考 / 上一封面 …）
- 拟写入的文字（≤8 字版本 + fallback "纯视觉无文字" 版本）
- 拟生成的 3 个版本方向（除非命中"例外"，否则默认 3 版本）
用户确认后再写 prompt。这步漏掉，后面经常发现"做完了才知道用户要的是 B站封面不是公众号头图"。
5. 按平台尺寸表选画布，按封面文字铁律和防泄漏铁律为每个方向写 prompt。
6. 调用 `image_gen` 生成 3 张（或例外触发时 1 张）；优先纯视觉、文字 ≤8 字、不出现禁词。
7. 走 Path 1 的 Step 4（5 维评审）+ 安全区肉眼检查；任一张低于 7 分主动重生成。
8. 复制图片到项目 `配图/` 目录，按 `封面-vN-方向锚点.png` 命名；不直接引用 `$CODEX_HOME/generated_images/`。
9. 用 skill 自带的图床上传脚本换永久链接——公众号发布必须用网络链接，本地路径在发布后失效。
```bash
# 需要 IMGBB_API_KEY（.env 放 cwd / skill 根 / ~/.env 都自动加载）；纯 stdlib 无 pip 依赖
python3 [SKILL_DIR]/scripts/upload_image.py 配图/封面-v1.png
```
key 没配置 → 让用户去 `https://api.imgbb.com` 注册免费 key。**3 版本先不上传，用户选定终版再上传，省图床配额**。
10. 给用户展示 3 个版本 + 简短选择理由（哪版适合点击率 / 哪版适合品味 / 哪版适合系列延续）；用户选定后归档其他版本到项目 `配图/_备选/`。
11. 系列继续走系列延续模式。
### 个人品牌触发（自带花叔像素风为示例 / 其他用户可替换）
> **给非花叔用户的提示**：`assets/personal-brand/` 里 ship 的是花叔本人的像素风品牌资产，作为"个人 IP 自动注入"的工作示例。其他用户使用本 skill 时有两种选项：
> 1. **替换**：把自己的 logo / 头像 / 风格示例 PNG 放进 `assets/personal-brand/`，触发词从「花叔风格」改成自己的品牌名（编辑下面的触发条件）。
> 2. **关闭**：删除 `assets/personal-brand/` 目录；本节自动不触发，skill 主体（slides / 单图三版本 / 品牌资产协议）功能完整。
>
> 下面以花叔像素风为例描述触发机制，结构对任何个人 IP 都通用。
当用户提到「花叔风格」「花叔的封面」「个人品牌风格」「像素风」「像素风头图」「做成像素风」「像素品牌资产」，或上下文判断这就是花叔自己的公众号 / B站 / 个人 IP 物料时，**自动启用以下三张参考图作为 `image_gen` 的参考输入**：
| 参考图 | 路径 | 作用 | 必需性 |
|--------|------|------|--------|
| 像素头像 | `assets/personal-brand/像素风头像.png` | 锁定**花叔本人角色形象**——脸、发型、配色、像素颗粒度 | **强制传入**（默认） |
| 像素公众号头图示例 | `assets/personal-brand/像素公众号头图示例.png` | 锁定 2.35:1 头图的版式、留白、文字处理 | 公众号头图任务强制 |
| 像素品牌资产 | `assets/personal-brand/像素品牌资产.png` | 完整的色板、字形、图形语言、签名细节 | 推荐 |
#### 🔴 花叔角色必须出现（铁律，实测踩过坑）
像素风触发 + 花叔自家物料 → **花叔本人（像素角色形象）必须作为画面主体或可识别的视觉锚点出现**——不是"杯子图案""书签脸"，是画面里一个真正的角色。
反例（2026-05-23 踩过）：「环境派」封面 prompt 写"沿用参考图的像素风颗粒度、配色、角色形象"，image_gen 把"角色形象"当成可选风格要素，主视觉变成一本写"环境派"的手册，花叔降级成桌上马克杯图案。
#### Prompt 必含三段式（花叔像素物料专用）
写 prompt 时按这三段强制结构展开，缺一不可：
```
【风格】沿用参考图的像素游戏美术、奶油纸底、Field Notes × 像素 8-bit 配色和颗粒度。
【角色】花叔（参考第一张头像图：圆脸、黑发、休闲衬衫的像素人物）作为画面 [位置：左侧 / 中央偏右 / 桌前坐着 ...] 的主体，[动作描述：在看屏幕 / 在整理工具 / 在写白板 ...]。角色识别度优先，不要降级成杯子图案或挂件。
【场景】围绕花叔布置 [本期主题元素]：[具体物件 1 / 物件 2 / 物件 3]。
【文字】≤8 字（如「环境派」/「翻车了」），手写/像素字体，居中或位于明显位置。
【禁】无水印，不出现"花叔"字样的署名标签，不重复公众号标题原文。
```
#### 反例 vs 正例 prompt
❌ **反例**（实测翻车版本）：
> 盒把混乱AI工具图标整理成工作流，中央只有一本写"环境派"的手册。Field Notes×像素游戏美术，奶油纸底、黑绿黄褐，无其他文字无水印。
问题：主视觉是"手册"不是"花叔"；"角色形象"完全没写进 prompt。
✅ **正例**（环境派 AI 工作流应该这么写）：
> 沿用参考图的像素游戏美术、奶油纸底、Field Notes × 像素 8-bit 颗粒度。花叔（参考第一张头像图：圆脸、黑发、像素人物）坐在中央偏左木桌前，把散乱 AI 工具图标按"环境/角色/工具/输出"四类归位到翻开的 CLAUDE.md 手册里。桌上有像素咖啡杯、Field Notes 笔记本、台灯。右上角像素字"环境派"。无水印，不出现"花叔"署名。
#### 其他执行规则
- **不强行套用**：只有用户明确要求"花叔风格 / 像素风"，或任务上下文显然是花叔自家物料时才启用。商单/客户品牌项目不要用花叔的像素风污染。
- **允许的角色缺席场景**（用户必须明确说才能跳过）：
- 用户原话「不要把我画进去」「做个纯工具图」「做产品对比图，不要人物」
- 主题是单一产品 review（如「Gemini 4 上手」）且用户明确说"主视觉是产品"
- 系列封面里某一期刻意要"花叔缺席"作为叙事（如「我休假这周」）
- 没有上述明确信号 → 默认花叔必须出现。
- **作为参考图，不作为最终结果**：把图片作为 image_gen 的视觉参考输入；prompt 里按三段式展开描述本次需要的画面。
- **像素头像（第一张）是默认强制参考图**——不再是"可单选可多选"里的"可选"项；不传它，花叔角色形象会跑偏。
- 启用后这套像素风**本身就是花叔的 `brand-spec.md`**——不要再额外去搜「花叔品牌色」「花叔字体」之类，直接以这三张图为权威。
## Step 0.0：核心资产协议（涉及具体品牌时强制执行）
> **这是稳定性的生命线**。从 `huashu-design` v1.1 同步过来。Agent 是否走通这个协议，直接决定输出质量是 40 分还是 90 分。不要跳过任何一步。
**触发条件**：任务涉及具体品牌——用户提了产品名/公司名/明确客户（Stripe、Linear、Anthropic、Notion、Lovart、DJI、自家公司等），不论用户是否主动提供了品牌资料。商单 brief 触发，个人物料如果有锚定品牌也触发。
**前置硬条件**：先用 WebSearch 验证品牌/产品存在且状态已知（发布日期、最新版本、关键规格）。事实错了，设计再好也是错的。
### 资产识别度排序（必须按这个顺序找）
| 资产类型 | 识别度 | 必需性 |
|---|---|---|
| Logo | 最高 | **任何品牌必备** |
| 产品图 / 渲染图 | 极高 | **实体产品必备** |
| UI 截图 / 界面素材 | 极高 | **数字产品必备** |
| 色值 | 中 | 辅助 |
| 字体 | 低 | 辅助 |
| 气质关键词 | 低 | 辅助 |
**只抽色值 + 字体、不找 logo / 产品图 / UI** = **违反本协议**。用 CSS 剪影替代真实产品图 = 违反本协议。找不到资产硬做 = 违反本协议。宁可停下问用户，也不要用 generic 填充。
### 5 步硬流程
1. **问**：按资产清单一次问全（Logo / 产品图 / UI / 色值 / 字体 / brand guidelines）。
2. **搜官方渠道**：`.com/brand`、`/press`、`/press-kit`、官网 inline SVG、App Store 截图、官方 launch video 截帧。
3. **下载**：`curl -A "Mozilla/5.0" -L -o assets/-brand/`；产品图取 hero image 高分辨率；UI 取 App Store 产品页或官网 screenshots section。
4. **验证 + 提取**：logo 至少两个版本（深底/浅底）+ 透明背景；产品图 ≥2000px；UI 是最新版本；色值用 `grep -hoE '#[0-9A-Fa-f]{6}' assets/-brand/*.{svg,html,css} | sort | uniq -c | sort -rn | head -20` 过滤黑白灰。
5. **固化为 `brand-spec.md`**（写入项目目录，所有后续 prompt 都引用它）。
6. **🛑 强制检查点：把 `brand-spec.md` 摘要给用户过目，等待确认**。
- 摘要必须包含：资产完整度（完整 / 部分 / 推断）、采集到的核心资产清单（logo 路径 / 产品图路径 / UI 路径）、主色 + 强调色、气质关键词、明确的禁区。
- 未确认前不进入 Step 0.1。资产协议走偏，后面全套 deck / 单图都会跟着歪 —— 这是品牌资产协议里成本最低的纠偏机会。
- 用户确认后才可以进入设计哲学推荐；用户提出修订（"主色这个不对""logo 用浅底版""禁色加上 X"）则原地修订 spec 后再次给用户过目。
### `brand-spec.md` 模板
```markdown
# · Brand Spec
> 采集日期：YYYY-MM-DD
> 资产来源：<列出下载来源>
> 资产完整度：<完整 / 部分 / 推断>
## 🎯 核心资产（一等公民）
### Logo
- 主版本：`assets/-brand/logo.svg`
- 浅底反色版：`assets/-brand/logo-white.svg`
- 使用场景：<片头 / 片尾 / 角落水印 / 全局>
- 禁用变形：<不能拉伸 / 改色 / 加描边>
### 产品图（实体产品必填）
- 主视角：`assets/-brand/product-hero.png`（2000×1500）
- 细节图、场景图…
### UI 截图（数字产品必填）
- 主页：`assets/-brand/ui-home.png`
- 核心功能：`assets/-brand/ui-feature-.png`
## 🎨 辅助资产
### 色板
- Primary: #XXXXXX <来源标注>
- Background / Ink / Accent / 禁用色…
### 字型
- Display / Body / Mono…
### 签名细节
- <哪些细节是「120% 做到」的>
### 禁区
- <明确不能做的：比如 Lovart 不用蓝色>
### 气质关键词
- <3-5 个形容词>
```
### 5-10-2-8 素材质量门槛（铁律）
- **5 轮**搜索（多渠道交叉，不是第一页就停）
- **10 个**候选才开始筛
- **选 2 个**精品（其他全用 = 视觉过载 + 品位稀释）
- **每个 8/10 分以上**（不够 8 分**宁可不用**，用诚实 placeholder 或重新生成）
Logo 例外：有就必须用，不适用 5-10-2-8——logo 是识别度根基，6 分 logo 也比没 logo 强 10 倍。
### 写完 spec 后的执行纪律
- 所有 `image_gen` prompt 必须**引用** `brand-spec.md` 里的资产文件路径，可用 logo / 产品图 / UI 截图作为参考图输入。
- 不允许用 CSS 剪影 / SVG 手画 / 凭记忆描述代替真实资产。
- 品牌色直接写值（如 `#1783FF`），不写「类似蓝色」。
- 想临时加色要先改 spec —— 让品牌一致性从"靠自觉"变成"靠结构"。
### 缺失资产的兜底
| 缺失 | 处理 |
|---|---|
| Logo 完全找不到 | **停下问用户**，logo 是品牌识别度的根基 |
| 产品图（实体产品）找不到 | 优先 `image_gen` 以官方参考图为基底生成 → 次选向用户索取 → 最后才是诚实 placeholder |
| UI 截图（数字产品）找不到 | 向用户索取自己账号的截屏 → 官方演示视频截帧；不用 mockup 生成器凑 |
| 色值完全找不到 | 走「设计方向顾问模式」，向用户推荐 3 个方向并标注 assumption |
**禁止**：找不到资产就静默用 CSS 剪影 / 通用渐变 / 凭记忆色 硬做——这是协议最大的反 pattern。
**协议代价 vs 不做代价**：走完协议 ~30 分钟（logo/产品图/色值/spec）；不做协议 → 通用 slides 返工 1-2 小时。商单 / 发布会 / 重要客户项目，30 分钟的资产协议是保命钱。
---
## Step 0：设计理解与方向推荐
在写大纲和 prompt 前，先完成设计判断。这个阶段继承 `huashu-design` 的核心逻辑。Step 0.0 是这一阶段的前置硬步骤（涉及具体品牌时）；Step 0.1-0.4 在此基础上展开。
### 0.1 深度理解需求
确认或自行判断：
- 目标受众：谁会看这套 PPT？
- 核心信息：看完后要相信什么、理解什么、采取什么行动？
- 使用场景：公开演讲、内部汇报、培训课件、销售材料、课程资料还是文章配套？
- 情感基调：可信、锋利、温暖、兴奋、克制、实验、诗意？
- 交付格式：PPTX、HTML deck、Keynote 可打开文件，或多格式。
如果信息不足，一次最多问 3 个问题；如果用户催促或任务清晰，直接基于上下文判断。
### 0.2 顾问式重述
用 100-200 字重述本质需求，必须讲清：
- 这套 deck 真正要解决的传播问题。
- 受众为什么会在意。
- 设计需要制造什么感受。
- 视觉上最应该避免什么。
结尾用一句话过渡：“基于这个理解，我准备了 3 个设计方向。”
### 0.3 推荐 3 个设计哲学方向
推荐的不是 3 个配色，而是 3 条设计哲学。每个方向包含：
- 风格名称：必须含真实设计师、机构、出版物、品牌或艺术传统。
- 为什么适合：连接受众、内容和场景。
- 核心特征：3-4 条可执行视觉特征。
- 信息密度策略：这套风格如何承载内容页 80-180 字典型、封面/章节扉页/结论页保持稀疏的节奏。
- 风险：例如过于安静、过于艺术、中文层级压力大。
输出模板：
```text
基于这个理解，我准备了 3 个设计方向：
1. [方向名：真实设计师/机构/出版物 + 风格定位]
为什么适合：[50-100字，连接内容、受众和场景]
核心特征：[3-4条]
信息密度策略：[如何用 80-180 字典型节奏承载内容页 + 配套封面/扉页/结论页稀疏节奏]
风险：[可能的问题]
2. ...
3. ...
我的默认建议：[选一个]，因为[一句话理由]。
```
找不到品牌 VI 时，可从以下基础风格池里选 3 个真正不同的方向给用户选择；这些不是兜底劣化，而是已经验证过能承载复杂信息的高质量视觉系统：
| 场景 | 可选基础风格 | 适合原因 |
|------|--------------|----------|
| 技术分享 / 产品更新 | OpenAI 官方设计规范、Anthropic 信息手册、MIT Technology Review | 克制、可信、能承载术语和结构图 |
| 数据报告 / 趋势讲解 | Bloomberg Graphics、Reuters Graphics、Fathom、NYT Magazine | 时间线、矩阵、指标和因果关系清楚 |
| 课程培训 / 方法论 | Field Notes、xkcd 白板、Takram 教学图解、黑板粉笔 | 解释路径明确，适合步骤和框架 |
| 发布会 / 观点表达 | Pentagram 编辑系统、Experimental Jetset、Neo-Brutalism、Apple Keynote | 有冲击力，适合强调判断和转折 |
| 个人 IP / 公众号 | Field Notes、Penguin Books、Ligne Claire、软木板剪贴簿 | 有人味，适合讲经验和案例 |
3 个方向必须来自不同流派，形成真正反差：
| 类型 | 适合 | 示例 |
|------|------|------|
| 安全专业 | 商务、报告、可信解释 | Pentagram、Fathom、Bloomberg Graphics |
| 大胆前卫 | 发布、观点、吸引注意 | Sagmeister、Field.io、Neo-Pop、Experimental Jetset |
| 独特差异化 | 个人 IP、文化、教学 | Kenya Hara、Takram、Field Notes、Ligne Claire |
禁止推荐 3 个“都差不多”的方向。用户如果不想选，默认选择最能承载信息、最符合场景的方向，并说明理由。
### 0.4 方向 Demo
如果任务重要、风格不确定、用户要求好看，先生成 1-3 张 Demo：
- 可为 3 个方向各生成一张封面/样页。
- 也可在选定方向后先生成 1 张样页验证风格。
- Demo 通过后再批量生成全套，避免整套风格走偏。
Demo 也必须复制到项目目录，不直接引用 `$CODEX_HOME/generated_images/`。
## Step 1：内容梳理
把材料转成逐页大纲。**先定每页的页面类型**（封面 / 章节扉页 / 内容页 / 结论页，见上方分级表），再写内容——类型决定密度上限，不要先写满字数再问"这是什么页"。
**默认结构（10 页以内 deck）**：
- Slide 01：**永远是封面页**——大标题 + 副标题 + 主视觉，没有信息块、没有"它解决三件事"的拆分。
- 中间页：内容页为主，**每 3-4 个内容页之间插一张章节扉页**做转场，让节奏有呼吸。
- 最后一页：**结论页**——一句核心判断 + 一个标志性视觉。
每页必须定义：
- **页面类型**：4 选 1（封面 / 章节扉页 / 内容页 / 结论页），决定密度上限。
- 标题：断言句，不是主题词。例：「AI Agent 的价值在工具边界」优于「Agent 介绍」。
- 核心结论：这一页观众必须带走什么——一句话讲清。
- 页面文案：**按页面类型选上限**（封面 ≤8 字 / 扉页 ≤30 字 / 内容页 80-180 字典型，220 字上限 / 结论页 ≤40 字）。**先尝试用上限的下半区写，写不下再考虑往上加**。可以包含短段落、标签、步骤、对比、引用、数据解释，但必须有清晰层级。
- 信息结构：选择 1 种主结构，例如"问题→判断→行动"、"对比 A/B"、"三步流程"、"一张图解释机制"、"案例拆解"。**封面 / 扉页 / 结论页跳过这一项**——它们没有信息结构，只有一个观点和一个视觉。
- 视觉场景：说明应该看到什么，以及它如何帮助理解内容。不要只写装饰，不要只写 CSS 布局。
设计规则：
- 一页只讲一个观点。
- 视觉先行，但文字不必稀少；文字负责把判断讲完整，视觉负责让结构一眼可见。**警惕：AI 默认会朝上限写，要主动反向约束，能 80 字讲清的不要拉到 180**。
- 观众走神 5 秒后回头，仍能从画面抓住主旨。
- 不编造数据；不确定的数据先查证或标注为待确认。
- 单页超过密度上限 = 该拆成两页，不是硬塞。
- 看完逐页大纲做一次自检："是否每页都是内容页类型？" 是的话立刻插入封面 + 扉页 + 结论页，整套节奏才合格。
- 信息密度要“有层次地高”，不是平均铺满。每页至少有一个视觉焦点、一个主标题、一个解释区、一个结论或行动提示。
Guided/Collaborative 模式下，大纲确认后再进入风格选择。
## Step 2：Deck Bible
选定设计方向后，才写 Deck Bible。它不是简单的“风格描述”，而是整套 PPT 的设计哲学合同。
生成任何单页之前，先写一份简短 Deck Bible。它是整套 PPT 的风格合同，后续每页 prompt 都必须继承。
Deck Bible 必须包含：
- 设计哲学：为什么这套 deck 要这样设计，而不是只描述样式。
- 统一风格锚点：真实出版物、设计师、品牌、漫画/插画传统或机构名。
- 视觉语言：插画、摄影、信息图、杂志版式、手绘板书、卡片系统等只能选一个主语法。
- 颜色气质：用自然语言描述，不必写 hex。例如“奶油纸底、黑色墨线、红色批注”。
- 字体气质：例如“杂志大标题 + 清晰中文正文”“板书手写感”“Field Notes 标签字”。
- 版式规律：标题区、解释区、图形区、结论区在整套里保持同类秩序。
- 信息密度规律：每页如何安排标题、解释、结构、结论，不让内容散掉。
- 禁止项：不要换风格、不要加入无关英文拟声词、不要让装饰压过信息。
Deck Bible 示例：
```text
整套采用 Field Notes × Anthropic 信息手册风格：奶油纸底、黑色粗线图标、低饱和绿色/蓝色/黄褐色卡片。每页都有大标题、三到五个信息块、一个中心图解和底部结论条。中文为主，像一本可投影的工作手册，不像营销海报。
```
### Spread Frame（信息手册版式框，推荐）
实测验证（OpenClaw 橙皮书宣传 PPT，2026-05-23）：信息手册风用「跨页框 + 单页变化」识别度最高。每张内容页共用 3 个不变元素：**顶部品牌条**（左刊头小字 + 右品牌 logo / 章节角标）+ **正文区**（自由布局）+ **底部结论条**（🚩 一句话 + 可选 3 小要点）。框不动，正文随内容变。
适用：信息手册类（Field Notes / Penguin Books / Anthropic / Bloomberg Businessweek）、技术分享、教学课件、产品宣传 deck。不适用：纯艺术海报、纯叙事 deck。
封面页 + 结论页可以**部分跳出框**（封面只留 logo，结论页让主视觉占满）；章节扉页保留框但留白更大。
### 吉祥物穿线（Mascot Continuity，品牌有角色时强烈推荐）
实测验证：OpenClaw deck 把"AI 虾"角色在 8 页里以不同姿态反复出现（举书/在地图前/拿放大镜/在台阶上…），整套 deck 从"8 张独立信息图"升级成"连环画"。
启用条件：
- 品牌已有 mascot / 角色（OpenClaw 的虾、花叔的像素人物、企业 IP 形象）
- 或风格本身适合（Snoopy 漫画、学習漫画、像素游戏美术）
执行规则：
- 在 Deck Bible 中明确写「角色锚点：[mascot 名称] 以不同动作/姿态出现在大部分内容页」。
- 每页 prompt 里指明这页 mascot 的动作（"虾举着翻开的书""虾在 8 个模块前指路""虾踩在 5 级台阶上"），不是一个静态形象贴满。
- 角色姿态服务于内容——讲流程时角色"走路径"，讲分类时角色"分发"，讲行动时角色"出发"。
- 反例：mascot 只出现在封面，后面忘记 → deck 像散装文章。
如果需要扩展风格细节，优先读取：
- `references/proven-styles-gallery.md`
- `references/proven-styles-snoopy.md`
- `references/design-movements.md`
常用风格路由：
| 主题 | 首选 | 备选 |
|------|------|------|
| 技术分享 | xkcd 白板、Ligne Claire | Neo-Brutalism |
| 课程培训 | 黑板粉笔、学習漫画 | 软木板剪贴簿 |
| 产品发布 | Neo-Pop、NYT Magazine | 苏联构成主义 |
| 商务报告 | NYT Magazine、Pentagram 编辑 | Fathom 数据 |
| 个人 IP / 公众号 | Snoopy 漫画、软木板剪贴簿 | 温暖叙事 |
AI 图片稳定性优先级：
- 低噪点：xkcd 白板、Ligne Claire、NYT Magazine。
- 中等风险：Snoopy、软木板、黑板粉笔。
- 高表达但易加字：Manga、Neo-Pop。必须限制“只渲染指定文字”。
优先选择“能承载复杂信息”的风格，而不是只好看的风格：
- 信息手册：Field Notes、Penguin Books、Anthropic、Bloomberg Businessweek。
- 数据叙事：NYT Magazine、Fathom、Reuters Graphics、Bloomberg Graphics。
- 技术解释：xkcd 白板、Ligne Claire、Takram、MIT Technology Review。
- 课程课件：黑板粉笔、软木板剪贴簿、学習漫画、The Oatmeal。
## Step 3：写图片 Prompt
先用 `huashu-gpt-image` 方法论去掉空泛形容词和英文伪结构，**再按页面类型选 prompt 模板**——封面 / 扉页 / 内容页 / 结论页有 4 套不同 prompt 结构，不能共用一个模板。
### 按页面类型选 prompt 模板
#### 封面页 prompt（slide 01 / 单图封面）
```text
沿用这套视觉系统：[粘贴 Deck Bible 短版]。
封面图，[平台尺寸]，主题：[一句话讲清这是什么 deck]。
画面：[1 个标志性视觉，例如 "一本翻开的工作手册 + 一支像素风钢笔"]。
文字：仅显示大标题"[≤8 字]"，可选副标题"[≤16 字]"。不出现章节列表、不出现 3-5 个步骤、不出现解释段落。
要求：留白充足，主视觉占画面中心 ≥50% 面积；克制感优先于信息量。
```
#### 章节扉页 / 转场页 prompt
```text
沿用这套视觉系统：[Deck Bible 短版]。
章节扉页，主题：[这一章要讲什么]。
画面：1 个强视觉隐喻，配合 ≤30 字的强判断句。
文字：仅"[一句强判断]"，无信息块、无步骤、无 takeaway。
要求：单一焦点，留白可观，像翻到下一章扉页。
```
#### 内容页 prompt（主要类型）
```text
沿用这套视觉系统：[粘贴 Deck Bible 短版]。
本页主题：[断言式标题]。
页面文案：[80-180 字典型，220 字上限。按 标题 + 1-3 句解释 + 2-4 个标签/步骤/对比 + 1 句结论 组织]。
画面：[主视觉、信息结构、图形隐喻、层级关系]。
要求：和前面页面同一风格，中文清晰，信息密度适中（不到上限不要硬填），不要额外英文装饰。
```
#### 结论页 prompt
```text
沿用这套视觉系统：[Deck Bible 短版]。
结论页，主题：本套 deck 最希望留给观众的一句话。
画面：1 个标志性视觉（呼应封面或本套 deck 的核心隐喻），周围大量留白。
文字：仅 ≤40 字的核心判断 + 可选 CTA / 联系方式。不要列要点、不要回顾全 deck。
要求：节奏放慢，像谢幕，不像销售。
```
### 防泄漏铁律（4 类页面都适用）
- 不写 pt/px、百分比、CSS、布局网格。除非品牌规范必须精确控色，否则不写十六进制色值。
- 不写不希望出现在画面里的英文术语。
- 不把整套长大纲塞进 prompt，只写这一页需要的内容和 Deck Bible 短版。
- prompt 里出现的每个词，都要假设可能影响画面；因此要写可见信息、风格规则和明确禁止项，不写闲聊。
### 中文文字规则
- 默认认为 200 字以内中文可以可靠生成；超过 220 字按"该拆成两页"处理而不是硬上 prompt。
- 标题可以是完整判断句，正文可以是短段落，但必须通过字号、卡片、标注、编号、色块形成层级。
- 可以使用技术名词、英文产品名和简单公式；复杂公式仍建议转成图解或拆成多行。
- 如果文字错，先检查是否层级太乱或信息结构不清，再重生成。
### 密度反向约束清单（写完 prompt 自检）
写完一条 slide prompt，**生成前自检**：
- [ ] 这一页的页面类型已经定了吗？（封面 / 扉页 / 内容页 / 结论页）
- [ ] 字数是否在该类型上限以内？（封面 ≤8 / 扉页 ≤30 / 内容页 ≤220 / 结论页 ≤40）
- [ ] 内容页：是不是 80-180 字就能讲清，却拉到 200+ 了？能省的全省。
- [ ] 是不是无意识地把"X 解决三件事 / X 有三个特点"拆成三栏？这是 AI 默认动作，不是好结构——能用一个观点 + 一个隐喻表达就别拆。
- [ ] 这一页观众能在 5 秒内抓到主旨吗？做不到=过密。
## Step 4：生成与检查
调用内置 `image_gen` 逐页生成图片。生成后必须检查：
- 中文是否准确。
- 是否出现 prompt 泄漏、乱码、英文拟声词、无关标签。
- 风格是否统一。
- 信息密度是否**与页面类型匹配**：内容页该有标题+解释+结构+结论；封面/扉页/结论页则反向——单一焦点 + 大量留白才对。不要拿"内容页标准"评封面。
- 设计是否出色：是否有明确视觉焦点、层级、留白、颜色节奏和可记住的图形隐喻。
- 画面是否真正承载主旨，而不是只有装饰。
按 `huashu-design` 五维评审做快速打分：
| 维度 | 检查问题 |
|------|----------|
| 哲学一致性 | 是否忠实于 Deck Bible？有没有混入另一套审美？ |
| 视觉层级 | 先看哪里、再看哪里是否自然？标题/正文/标签/结论是否分明？ |
| 细节执行 | 对齐、间距、颜色数量、同类元素是否统一？ |
| 功能性 | 每个视觉元素是否服务于理解？有没有只为好看的装饰？ |
| 创新性 | 是否避免模板感和 AI 科技 cliché？有没有一个可记住的隐喻？ |
**额外的「页面类型恰当性」检查**（新增维度，与 5 维评审并行）：
- 封面页（slide 01）：文字是否真的 ≤8 字？有没有混入信息块 / 解释段落 / 3-5 个步骤？如果出现"它解决三件事""核心三步骤"的拆分=必须重生成。
- 章节扉页：文字是否 ≤30 字？是否只有 1 句强判断 + 1 个视觉？出现信息列表=过密，重生成。
- 内容页：实测字数是否落在 80-180 字区间？超过 220 字=拆成两页；少于 50 字且没有视觉支撑=信息太薄，可能本该并入相邻页。
- 结论页：是否在回顾全 deck？是的话重写——结论页不是总结页。
- **整套节奏检查**：把 N 张 slide 排成一列扫一眼，是否能看出"封面 → 内容 → 转场 → 内容 → 结论"的密度起伏？如果每页看起来一样密=节奏失败，需要重新分类型。
低于 7 分的页 **或** 页面类型恰当性不通过的页，不要硬塞进最终 deck；先重写 prompt 或重生成。
评审记录模板：
```text
Slide NN 评审：
- 哲学一致性：_/10
- 视觉层级：_/10
- 细节执行：_/10
- 功能性：_/10
- 创新性：_/10
- 结论：保留 / 重生成
- 修复方向：[如果重生成，写清 prompt 要改什么]
```
如果风格漂移：
- 不要继续生成下一页。
- 把 Deck Bible 缩短成更强的固定前缀。
- 在下一张 prompt 开头写“继续使用上一页完全相同的视觉系统”。
- 必要时重生成偏离风格的页面。
检查通过后，把图片复制到项目目录，例如：
```text
项目/YYYY.MM-项目名/配图/slides/slide-01.png
```
不要让最终 HTML、PPTX、Markdown 或项目说明引用 `$CODEX_HOME/generated_images/`。
## Step 5：组装
PPTX：
```bash
uv run [SKILL_DIR]/scripts/create_slides.py \
项目/YYYY.MM-项目名/配图/slides/slide-01.png \
项目/YYYY.MM-项目名/配图/slides/slide-02.png \
--layout fullscreen \
-o 项目/YYYY.MM-项目名/output/deck.pptx
```
HTML 图片 deck：
```bash
uv run [SKILL_DIR]/scripts/image_deck_html.py \
项目/YYYY.MM-项目名/配图/slides/slide-*.png \
-o 项目/YYYY.MM-项目名/output/deck.html \
--title "演示标题"
```
Keynote：
- 交付 PPTX，说明可直接用 Keynote 打开。
- 如果用户要求 `.key` 原生文件，优先询问是否接受 PPTX；原生 Keynote 通常需要本机 GUI/AppleScript，可能需要额外授权。
大文件策略：
- 图片 PPTX 超过 80MB 时，先保留原始图片，再生成一份压缩版交付。
- 压缩优先使用 Pillow 或系统图片工具把 slide PNG 宽度压到 1920px 左右，质量保持可读。
- 不删除原图；原图继续保存在项目 `配图/slides/`，压缩图放 `配图/slides-compressed/`。
降级策略：
- `image_gen` 不可用：暂停并说明卡点；如果用户接受，改走 HTML fallback。
- 不要因为主观担心中文、字数、版式或精确日期就主动切到 HTML fallback；这些问题优先通过更好的 Deck Bible、品牌/VI 约束、参考图和重生成解决。
- 单页风格漂移严重：不要继续批量生成，先重写 Deck Bible 短版并重生成样页。
- 中文/数据错误：优先重写 prompt 并重生成该页；只有用户明确要求文字可编辑、反复重生成仍无法接受，或 image_gen 不可用时，才改用 HTML fallback 做该页或整套。
- PPTX 组装失败：先交付 HTML 图片 deck，同时检查图片路径、文件格式和 `python-pptx` 依赖。
### 生成失败时的救援策略（仍在 Path 1 内）
⚠️ **救援 ≠ 切路径**。`image_gen` 产出不满意 → **默认重写 prompt 重生成**，不是切 Path 3。
- 中文错字 / 乱码 → 简化文字、缩短到 ≤180 字，重试最多 3 次。
- 风格漂移 → 重写 Deck Bible 短版作为更强前缀，重试最多 2 次。
- Prompt 泄漏（出现 CSS / 英文术语）→ 移除 prompt 里 pt/px/百分比/英文术语，重试最多 2 次。
- 单页 ≥10 单元格精确表格 → **先问用户**：① image_gen 近似版（推荐）/ ② 这一页单独 HTML 嵌精确表格 / ③ 简化表格 —— 让用户选。
- `image_gen` 工具调用失败 ≥3 次 → 告知用户并询问"切 Path 3 还是等环境恢复"。
**穿越所有失败模式的铁律**：除非用户明确同意，**整套 deck 不会自动切到 Path 3**。最多单页局部用 HTML 兜底。
## Step 6：交付说明
最终汇报必须包含：
- 完成页数 / 图数。
- 选用设计方向，以及为什么选它。
- 如涉及具体品牌：**brand-spec.md 路径**、采集的资产清单（logo / 产品图 / UI / 色值 / 字体）和资产完整度。
- 如启用花叔像素风：列出引入的参考图。
- Deck Bible 或单图风格合同摘要。
- 交付文件路径（PPTX / HTML / 单图 PNG）。
- 项目内图片路径。
- 哪些页 / 图重生成过，以及原因。
- 五维设计评审简报：哲学一致性、视觉层级、细节执行、功能性、创新性。
- 风格一致性与信息密度检查结果。
- 单图任务额外汇报：平台尺寸是否对齐、封面文字是否 ≤8 字、是否落在中央安全区、是否触发了系列延续模式。
- 如果没有跑验证或没有打开预览，要明确说明。
路径要遵守写作工作区规则：不要把产物写根目录；有项目就写项目目录，没有项目先建 `09-实验项目/<项目名>-YYYYMM/`。
## 参考文件
所有引用路径都用 `[SKILL_DIR]/...` 相对前缀，不依赖任何机器特定的绝对路径——本 skill 完全 self-contained，可直接分发。
| 需要 | 文件 |
|------|------|
| 视觉原则、断言式标题、信息密度 | `[SKILL_DIR]/references/design-principles.md` |
| 图片 prompt 防泄漏、HTML fallback 规范 | `[SKILL_DIR]/references/prompt-templates.md` |
| 已验证风格参数 | `[SKILL_DIR]/references/proven-styles-gallery.md` |
| Snoopy/Peanuts 深度指南 | `[SKILL_DIR]/references/proven-styles-snoopy.md` |
| 设计运动与风格映射 | `[SKILL_DIR]/references/design-movements.md` |
| PPTX 组装脚本 | `[SKILL_DIR]/scripts/create_slides.py` |
| HTML deck 组装脚本 | `[SKILL_DIR]/scripts/image_deck_html.py` |
| HTML fallback → PPTX 转换脚本 | `[SKILL_DIR]/scripts/html2pptx.js` |
| **ImgBB 图床上传脚本**（纯 stdlib，无依赖） | `[SKILL_DIR]/scripts/upload_image.py` |
| 个人品牌示例资产（自带花叔像素风，可替换或删除） | `[SKILL_DIR]/assets/personal-brand/像素风头像.png`、`像素公众号头图示例.png`、`像素品牌资产.png` |
环境变量约定（只读，永远不要硬编码或打印）：
| 变量 | 用途 | 必需性 |
|------|------|--------|
| `IMGBB_API_KEY` | 调用 `scripts/upload_image.py` 上传图床；可放 `cwd/.env` / `[SKILL_DIR]/.env` / `~/.env`，三处任一存在脚本会自动加载 | 可选（不上传时不需要） |
## 版本自检（静默）
本节给 AI agent：每次使用本 skill 前，先做一个不联网的判断——读本 skill 目录（SKILL.md 所在目录）下的 `.last-update-check` 文件（内容为一行日期 YYYY-MM-DD）。文件存在且距今不足 30 天，跳过本节直接干活，不向用户提任何更新相关的话。
到期或文件不存在时，且仅在此时：
1. 本目录不是 git 克隆（无 `.git` 或无 origin）→ 写入今天日期后跳过本节
2. 对比版本：`git -C <本目录> rev-parse HEAD` 与 `git -C <本目录> ls-remote origin HEAD`
3. 无论结果如何，把今天日期写入 `.last-update-check`
4. 两者一致 → 什么都不说；确认落后 → 先完成用户当前任务，结束后附一句「本 skill 有新版本，可用 `git -C <本目录> pull --ff-only` 更新」。是否更新由用户决定，不要主动执行更新