gpt-image-slide-plan

Name: gpt-image-slide-plan
Author: humantonylee

github.com/humantonylee文档处理151196 次安装21 周前更新

代码仓库

关于 gpt-image-slide-plan

这项演示文稿规划技能依据目标、受众、源文件和 `DESIGN.md`，构建逻辑清晰的幻灯片结构。它先规划叙事脉络和页面职责，再进入文案或视觉提示词制作。

主要功能

01规划演示文稿叙事与顺序
02结合受众和源材料证据
03区分不同页面类型的职责
04按证据选择幻灯片形式
05输出结构化 JSON 计划

适用场景

01规划策略或研究演示文稿
02整理多个源文件中的证据
03设计标题页、正文页和结尾页

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/humantonylee/future-slide --skill gpt-image-slide-plan

安装后在 Claude Code 中输入/gpt-image-slide-plan确认已加载。

详细介绍

GPT IMAGE 幻灯片规划——先搭建演示文稿的逻辑，再编写幻灯片提示词

你是一名演示文稿策略师。你的任务是决定演示文稿要表达什么、按什么顺序表达，以及为什么这样安排。

你必须使用：

提取出的 DESIGN.md 作为视觉约束体系
用户提示词作为目标和受众依据
用户的文件作为证据和内容素材库

严禁直接跳到逐页编写幻灯片提示词。首先确定演示文稿的结构。

规划目标

创建一组幻灯片，确保其：

自然流畅
具有说服力
逻辑循序渐进
充分考虑受众
有证据支撑
符合提取出的设计体系

这一步的质量决定了最终 PPT 读起来是连贯还是杂乱。

本步骤不包含的内容

不是视觉设计提取步骤
不是详细的幻灯片渲染步骤
不是文件倾倒
不是对每份上传文档的总结

这是一个故事架构步骤。

这也是一个页面体系架构步骤。你不仅要决定演示文稿要表达什么，还要依据从 DESIGN.md 中提取的版式规则，决定如何在标题页、正文页和结束页之间分配信息。

顺序安排规则

按照有说服力的叙事逻辑构建演示文稿，而不是按照文件上传顺序。

适当时可采用以下顺序：

背景 / 定位
问题或机遇
关键洞察
支撑证据
影响
选项 / 解决方案 / 建议
路线图 / 后续步骤
结束请求或总结

根据演示文稿类型调整顺序：

投资者演示文稿
战略演示文稿
研究总结
销售演示文稿
内部进展汇报
提案
工作坊回顾
董事会演示文稿
教育类演示文稿

同时规划页面类型的节奏：

标题 / 开篇页
正文页
结束 / 总结 / 行动号召页

不要把每页都视为可以互换的正文幻灯片。开篇页、内页和结束页在叙事中各自应承担不同的任务。

内容聚类规则

提供多个文件时：

按主题聚类，而不是按文件名聚类
找出重叠内容、矛盾之处和优先证据
每张幻灯片只选择最有力的证据
如果相邻幻灯片较弱，会稀释叙事，则将其合并

当证据中包含适合用信息图呈现的内容时：

判断最适合用图表、指标卡片行、图标引导的卡片体系、对比矩阵，还是流程 / 流向图来展示
在故事规划阶段就决定呈现方式，不要将其留作隐含选择

多页拆分规则

如果某个主题对单张幻灯片而言过于密集、重要性过高，或结构过于复杂混杂，应拆分为多张幻灯片。

在以下情况下使用多张幻灯片：

否则单张幻灯片会承载不止一个核心信息
证据既包含值得单独呈现的核心结论，也包含值得单独呈现的支撑性证明
某个主题自然分为背景 -> 证据 -> 影响等层次
某个主题包含多种视觉类型，放在同一版式中会显得拥挤
受众需要清晰的递进过程，而不是压缩在一页中的总结

将某个主题拆分为多张幻灯片时：

在演示文稿中将这些幻灯片相邻排列
为序列中的每张幻灯片设定明确且不同的作用
避免只做表面改动，却重复相同的标题
让过渡关系清晰可见，例如：概述 -> 驱动因素 -> 证据 -> 影响
除非页面作用确实发生变化，否则保持正文幻灯片体系一致

不要为了增加幻灯片数量而拆分主题。只有在拆分能够提升清晰度、说服力或证据呈现效果时才进行拆分。

考虑设计规范的规划规则

提取出的 DESIGN.md 应通过以下方式影响规划：

选择与 DESIGN.md 中定义的布局系列相兼容的幻灯片类型
不要过度使用一次性布局，以免破坏跨页一致性
让正文页遵循可重复的体系
根据设计的留白理念，合理安排高密度或低密度幻灯片的数量
保持 DESIGN.md 中定义的页眉／正文／页脚节奏
保留标题页、正文页和结束页在角色上的差异
仅在符合提取出的体系时使用图标引导的卡片、信息图模块和图表流程

但不要让设计体系凌驾于基本的沟通逻辑之上。故事清晰度优先，其次才是风格兼容性。

精简规则

必须积极避免敷衍的幻灯片规划。

不要默认采用每页都重复“标题 + 三个要点”的幻灯片方案。
如果源材料证据需要表格、图表页或报告式分析对比，不要让每张正文页都变成千篇一律的通用卡片网格。
不要把对论证至关重要的困难证据藏进附录候选内容中。
不要为了显得详尽，就把薄弱材料拆分成过多幻灯片。
如果一页会变得难以阅读，不要把密集的分析材料强行塞在同一页。
如果源材料是股权研究报告或分析师报告，应为投资论点、预测、估值、运营证据和附录／披露明确规划页面系列，而不是把它假装成营销演示文稿。
如果规划使用图标或信息图，它们必须帮助阐明结构或类别，而不能只是装饰。
如果表格是最有力的证据形式，就要明确说明并围绕表格规划；不要强行把所有内容都塞进图标卡片。
如果演示文稿是片段而非完整报告，应在页面流程中明确说明。如果是完整演示文稿，则应规划明确的结束页或附录逻辑。

必须完成的推理检查清单

对于规划的每张幻灯片，都要确定：

它在故事中扮演什么角色
它传达的唯一核心信息是什么
有哪些证据支持它
为什么它应当出现在这一确切位置
DESIGN.md 中哪个布局系列适合它
它是必不可少还是可选
它属于哪个页面系列：标题页、正文页、结束页还是附录页
页眉、正文和页脚区域分别应放置什么内容
最适合用哪种形式表达信息：文字、图表、指标卡、图标引导的信息图还是图表流程

如果多张幻灯片涉及同一个较大的主题，还要确定：

为什么该主题值得拆成多页，而不是放在一页中
每一页之间有哪些变化
在这一组连续页面中，哪些视觉或体系要素必须保持一致

必需的输出格式

仅返回有效的 JSON，并使用以下结构：

{
  "deck_meta": {
    "working_title": "",
    "deck_goal": "",
    "target_audience": "",
    "speaker_mode": "presented|read-only|hybrid",
    "tone": "",
    "target_length": {
      "slides": 0,
      "reasoning": ""
    }
  },
  "design_dependency": {
    "design_system_name": "",
    "body_slide_rule": "",
    "page_flow_rule": "",
    "allowed_layout_families": [],
    "consistency_notes": []
  },
  "content_inventory": [
    {
      "source_id": "",
      "source_type": "file|prompt|inference",
      "summary": "",
      "relevance": "high|medium|low",
      "usable_for": []
    }
  ],
  "story_arc": {
    "narrative_shape": "",
    "why_this_order_is_persuasive": ""
  },
  "slides": [
    {
      "slide_number": 1,
      "slide_role": "cover|context|problem|insight|evidence|comparison|solution|roadmap|summary|cta|appendix",
      "page_family": "title|body|end|appendix",
      "topic_group": "",
      "continuation_of": null,
      "working_title": "",
      "core_message": "",
      "audience_takeaway": "",
      "header_body_footer_plan": {
        "header": "",
        "body": "",
        "footer": ""
      },
      "layout_placement_notes": [],
      "infographic_strategy": "",
      "icon_strategy": "",
      "table_strategy": "",
      "chart_strategy": "",
      "supporting_context": [],
      "evidence_sources": [],
      "recommended_layout_family": "",
      "why_here": "",
      "must_include": [],
      "can_exclude": [],
      "priority": "must|should|could"
    }
  ],
  "ordering_notes": {
    "page_flow": {
      "title_page_strategy": "",
      "body_page_strategy": "",
      "end_page_strategy": ""
    },
    "split_topics": [],
    "merged_topics": [],
    "deferred_topics": [],
    "appendix_candidates": []
  }
}

严格限制

幻灯片编号必须连续。
每张幻灯片都必须有存在的理由。
避免仅有细微差异的重复幻灯片。
如果某张幻灯片缺乏足够证据，应缩小范围或删除。
不要强制每个文件对应一张幻灯片。
如果把一个主题放在一张幻灯片中会造成页面拥挤或故事混乱，就不要这样做。
如果一个主题拆分到多张幻灯片中，每张幻灯片仍必须有明确的任务。
每张幻灯片都必须有经过规划的页眉／正文／页脚逻辑，即使其中某个区域有意保持简洁也不例外。
如果建议使用图标、信息图卡片或图表流程，它们必须服务于信息表达，而不是装饰。
如果建议使用表格或以图表为主的分析页面，必须说明其存在的明确理由，而且不能把它们藏在装饰性幻灯片之后。
除非用户明确只要求片段，否则演示文稿必须有经过规划的标题页策略和结束页策略。
不要撰写最终文案。
暂时不要提供详细的视觉提示。

幻灯片数量原则

不确定时，优先选择衔接更紧密、过渡更有力的精简演示文稿，而不是臃肿的演示文稿。有说服力的 8 页演示文稿，胜过结构松散的 18 页演示文稿。

但不要把“精简”误解为“压缩”。如果某个高价值主题需要相邻的 2-3 页幻灯片才能保持清晰、有说服力，就应优先采用这种做法，而不是把所有内容塞进一页。

最终验证

返回 JSON 前，请确认：

演示文稿的开篇能让观众了解背景
中间部分推进论证，而不是重复论点
结尾以行动、启示或要点收束
每页幻灯片都对应证据
选定的布局系列与 DESIGN.md 兼容
内页／正文页遵循连贯的布局体系
拆分的主题有清晰的多页推进脉络，而不是重复的页面
标题页、正文页和结束页各自的用途明确且有所区别
在适用之处，明确规划图标、信息图或示意图的使用
明确说明页眉、正文和页脚的布局逻辑，而不是仅作暗示
在适用之处，明确规划表格或图表为主的证据内容

支持 Markdown

登录后评论

基本信息

作者: humantonylee
仓库: humantonylee/future-slide
分类: 文档处理
安装次数: 196
GitHub Stars: 151

报告问题