name: ppt-builder description: "Build high-quality presentation decks from scratch. Covers the full lifecycle from brainstorming through content writing, visual design, AI image generation, iterative QA, and final delivery. Uses OpenRouter + Nano Banana Pro for slide image generation. No external SaaS dependency."

PPT Builder

從一句話需求到高品質演示 PPT 的完整方法論。覆蓋內容策劃、文案撰寫、視覺設計、AI 生圖、QA 迭代、交付全流程。

When to Use

• 使用者想從零開始做一份演示 PPT（產品演示 / pitch deck / 培訓材料 / 報告）

  更多技能請訪問小蔥技能站7w4.net。

• 使用者有一個主題但還沒有具體內容
• 使用者已有內容文件但需要高品質視覺呈現
• 使用者想用可復現、可迭代、低成本的方式生成 PPT

核心理念

內容和形式分離。分三步走，每步獨立交付、獨立審批：

下游不反向改上游。如果 Step 3 生成時發現某頁內容裝不下，回 Step 1 改內容，不在 Step 3 裡"壓一壓"。

工作流總覽（7 個階段）

階段 1 Brainstorming → 收斂決策，形成定位 階段 2 Spec 文件 → 大綱 + 多輪自審 → 批准 階段 3 內容文件 → 每頁文案 階段 4 設計文件 → 視覺系統 + 模板 + 每頁指令 階段 5 PPT 生成 → Nano Banana 逐頁生圖 + 組裝 階段 6 QA 迭代 → 只修有問題的頁 階段 7 交付 → pptx + pdf

階段 1：Brainstorming

目標：把模糊的需求收斂為一份明確的決策清單。

推薦 Skill：如果已安裝 idea-to-design（頭腦風暴 · 從想法到設計），可以先呼叫它完成通用的 brainstorming 流程（探索上下文 → 逐一提問 → 提出方案 → 呈現設計 → Spec 自審）。本階段的 PPT 專屬決策項作為 brainstorming 的具體問題輸入。

方法

每次只問一個問題，給 3-5 個選項，標註你的推薦。等使用者回答後再問下一個。不要一次性拋多個問題。

必須收斂的決策

關鍵原則

• 接納使用者的重新定義。使用者可能打斷你的問法，提出更好的流程框架，接受它
• 不要在 brainstorming 階段寫任何內容。只做決策，不寫文案
• brainstorming 結束的標誌：所有決策項都有明確答案

階段 2：Spec 文件

目標：寫一份全域性定位 + 每頁大綱 + 視覺方向的 spec 文件。

文件結構

[Deck名稱] - 設計文件

1. 全域性定位（階段 1 所有決策的彙總表）

2. N 頁完整大綱

### Part X — [章節名]（M 頁） | # | 頁面 | 核心論點 | 必備內容 |

3. 生產流程（三步走 + 每步的驗收標準）

4. 視覺方向（色彩/字型/背景/關鍵視覺元素）

5. 風險和待補項

6. 不在範圍（Out of Scope）

必做：多輪自審

Spec 寫完後必須至少做兩輪自審，不審不進下一步。

第一輪：受眾視角審

站在目標受眾的角度讀一遍大綱，問自己： - 開場有沒有讓我繼續讀的理由？（鉤子） - 這份 deck 70% 在講我的世界還是在講產品？（應該是前者） - 讀完我能做什麼？（CTA 必須具體可行） - 有沒有讓我感覺"又是一個賣概念的"？ - 每一頁的標題是我會問的問題還是產品經理的術語？

詳細檢查清單見 references/spec-review-checklist.md

第二輪：文案質量審

grep 掃描停用詞（見 references/writing-principles.md），確保零正文命中。

如果自審發現問題

直接改。改完不需要重新審——修了就過。但嚴重問題（如結構性缺失）需要標註版本號（v1 → v2）並記錄變更原因。

階段 3：內容文件

目標：寫 content.md，覆蓋每一頁的完整文案。

粒度策略

每頁標準格式

Slide N - [標題]

核心論點：[一句話，這頁要讓讀者記住什麼] 詳細文案：[終稿文字 或 3-5 個 bullet 要點] 圖片意圖：[需要什麼視覺素材——只講意圖不講樣式] 關鍵資料（可選）：[數字和引用來源，佔位用 [待補]]

寫作鐵律

1. 用事實和資料製造張力，不用形容詞
2. 具體 > 抽象——每句話要麼是事實、要麼是具體動作
3. 先演示後下定義——核心 claim 放在故事講完之後
4. 資料剋制——沒有真實資料就用 [待補]，別編
5. 每個 CTA 必須此刻能兌現——不承諾不存在的產物
6. 佔位符統一格式——全部用 [待補]，不用 TBD / TODO

詳細寫作原則見 references/writing-principles.md

驗收

• 停用詞 grep 零正文命中
• 核心 claim 只在指定頁出現（如有）
• 人物 / 數字 / 名稱全 deck 一致
• 每頁都有"核心論點"（沒有空殼頁）

階段 4：設計文件

目標：寫 design.md，定義視覺系統和每頁的具體版式。

文件結構

§1 視覺系統

色彩（hex 值 + 用途）/ 字型（字號層級）/ 背景 / 標誌性元素 / 間距

§2 頁面模板庫（6-10 種）

每種模板：用途 / Wireframe / 元素清單 / 尺寸 / 變體 / 禁止事項

§3 每頁設計指令

每頁：模板 / 文案來源 / 影像清單 / 版式要點

§4 AI 插圖 Prompt 清單

概念插畫（需要 AI 生成的）/ 示意圖（指令碼生成的）/ 圖示

§5 降級版規範（可選）

投影儀 / 列印 / 移動端 的適配規則

模板設計原則

• 模板數量 6-10 種（太少擠進不合適的模板，太多視覺碎片化）
• 最複雜的模板優先設計——它的質量決定全 deck 品質上限
• 每個模板的"禁止事項"和"允許的變體"必須明確

每頁設計指令格式

Slide N - [標題]

模板：[模板名或變體] 文案來源：content.md Slide N 影像清單： - [ILL-N / SCR-N / DGM-N / ICO-N：描述] 版式要點： - [2-3 條具體指令]

階段 5：PPT 生成

目標：用 Nano Banana Pro 逐頁生成幻燈片圖片，組裝成 pptx。

技術棧

• 模型：Nano Banana Pro（Gemini 影像生成模型）
• API 閘道器：Ofox（無需 VPN）或 OpenRouter
• 組裝工具：python-pptx（將每頁 JPG 塞進空白 slide）
• 成本：約 ¥0.1-0.3 / 頁

生成指令碼

安裝後執行：

# 1. 複製 slides.example.json 為 slides.json，填入你的 prompt
cp scripts/slides.example.json scripts/slides.json

# 2. 生成全部頁
python3 scripts/generate_deck.py

# 3. 只生成第 1-5 頁
python3 scripts/generate_deck.py --start 1 --end 5

# 4. 重跑某頁（刪舊圖再跑）
rm scripts/output/slide_03.jpg && python3 scripts/generate_deck.py --start 3 --end 3

# 5. 生成完自動組裝 PPTX
python3 scripts/generate_deck.py --assemble

slides.json 格式：style（全域性風格字首）+ slides 陣列（每頁一個 num + prompt）。 見 scripts/slides.example.json 示例。

依賴：pip install python-pptx（僅組裝 PPTX 時需要）

全域性風格 Prompt

每頁 prompt = 全域性風格字首 + 頁面具體內容。

全域性字首應包含：角色設定（"你是一名頂級 PPT 設計師"）、輸出格式（"16:9 比例的幻燈片圖片"）、設計風格要求（從 design.md 提取的背景、色彩、字型）、中文渲染強制要求、"只生成一張圖片"。

每頁 Prompt 寫作規則

詳見 references/prompt-writing-guide.md，核心要點：

1. 文案從 content.md 原文複製——不讓 AI "發揮"
2. 顏色用 hex 不用名字——精確色值，不是"深綠色"
3. UI mockup 要詳細描述——不說"一個聊天截圖"，要描述每個氣泡的內容
4. 中文名加 CRITICAL 指令——AI 生圖經常亂碼
5. 表格逐行列出——不說"一個7行表格"
6. 避免 prompt 洩漏——第一句不要寫樣式指令，寫"這是一張什麼頁"

斷點續跑

已生成的頁自動跳過（檢查檔案是否存在且大於 10KB）。要重跑某頁時手動刪掉該 JPG 再跑。

組裝

使用 python-pptx 建立 16:9 空白簡報，逐頁將 JPG 以全屏尺寸新增到空白 slide 上，最後儲存為 pptx。

階段 6：QA 迭代

目標：審查所有頁面，只修有問題的頁，不動通過的頁。

QA 協議

1. 逐頁審——開啟 pptx 或檢視每頁 JPG
2. 分級——Critical（內容錯誤）> Important（版式/渲染）> Minor（微調）
3. 只重跑受影響的頁——rm slide_NN.jpg → 修 prompt → 重跑 → 重組裝
4. 永遠不碰已通過的頁

常見問題修復

詳見 references/qa-fix-patterns.md，涵蓋：

• 標題被加了字首（"Slide N:"）
• Prompt 指令被渲染為可見文字
• 中文名亂碼
• 字號標註洩漏到標題
• 時間軸節點數量錯誤
• 表格或資料缺失
• 風格不一致（頁間跳躍）
• 數字被 AI 篡改

參考鏈模式（提升風格一致性）

生成每頁時把上一頁的 JPG 作為 visual reference 傳入 API。減少頁間風格跳躍。

首次全量生成可不用（獨立出圖速度更快），QA 修復特定頁時建議啟用。

階段 7：交付

產出物

output/ ├── slide_01.jpg ~ slide_NN.jpg ├── deck-v1.pptx └── deck-v1.pdf (可選)

交付前 Checklist

• [ ] 全部頁面生成成功（0 失敗）
• [ ] QA 修復後的頁面已替換並重組裝
• [ ] pptx 在 PowerPoint / Keynote 能正常開啟
• [ ] 核心論點在每一頁都站得住
• [ ] 停用詞零命中
• [ ] 數字全 deck 一致（同一個數字不出現兩個版本）
• [ ] 人物/品牌名稱全程一致
• [ ] CTA 頁的每個行動都能此刻兌現

迭代和定製

改 content.md 裡的內容 → 只重跑受影響的頁 → 重組裝。

不需要全量重跑。改一頁成本 ¥0.1-0.3 + 30 秒。

成本參考

大部分時間花在內容和設計上（階段 1-4）。PPT 生成本身只需 15 分鐘 + ¥5。

內容質量 > 視覺效果——PPT 的說服力 80% 來自內容，20% 來自視覺。

Key Pitfalls

• Never paraphrase user content — use exact text from content.md
• Never add "Slide N:" prefixes to titles
• Never add English subtitles unless the spec says so
• Never include meta-notes (like "Final CTA" or "重點頁") in visible content
• Never use font size notation like "(36pt)" in visible title text
• Never fabricate data — only use numbers from the spec, or mark as [待補]
• Never skip self-review — at least two rounds before proceeding
• Never regenerate approved slides during QA rounds
• Never let AI "improve" the copy — it always makes it worse
• Never promise deliverables that don't exist yet in CTA pages

質量中上，方法論成熟且可操作性強。優點是流程清晰、文件規範、工具可用，QA 修復指南實用。不足是文件深度不夠一致，缺少完整的例項演示，新手理解起來可能有些吃力。如果你是 PPT 製作新手，建議先通讀 SKILL.md 再動手；有一定經驗的使用者可以直接參照工作流執行，效果會更好。