mcpField
V
visual-style-ppt

visual-style-ppt

github.com/irenerachel文档处理394157 次安装3 天前更新
代码仓库

关于 visual-style-ppt

visual-style-ppt 是用于制作幻灯片图片和纯图片 PPTX 的视觉文档技能,要求使用 Image 2.5 生成图片。它面向演示文稿及相关视觉材料制作,并通过样式复用、审核和打包流程组织工作。

主要功能

  1. 01仅用 Image 2.5 生成图片
  2. 02复用视觉样式资产
  3. 03制作幻灯片图与纯图片 PPTX
  4. 04先准备大纲和提示词
  5. 05按审核流程生成与打包

适用场景

  1. 01制作整页演示幻灯片图片
  2. 02将获批图片组装为 PPTX
  3. 03在整套幻灯片中应用统一样式

安装

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

$npx skills add https://github.com/irenerachel/visual-style-ppt-skill --skill visual-style-ppt

安装后在 Claude Code 中输入/visual-style-ppt确认已加载。

包含的文件

除 SKILL.md 外,安装时一起下载的参考资料和脚本。

README.md
agents/
openai.yaml
references/
page-types.md
workflow.md
output-package.md
revision-workflow.md
style-interview.md
styles/
impact-grid-editorial.md
terminal-tech-magazine.md
french-editorial-commerce.md

详细介绍

Visual Style PPT

最高优先级规则:仅使用 Image 2.5

此技能必须使用 Image 2.5 模型生成每一张最终幻灯片图片、缩略图板、视觉页面、信息图、文章插图或 PPT 页面图片。

严禁使用 HTML 生成图片。不得创建 HTML/CSS 页面、浏览器截图、SVG/HTML 模型图、画布渲染或本地脚本生成的视觉复现作为最终或中间图片输出。Image 2.5 不可用时,不得使用 HTML 作为备用方案;请停止并说明必须具备 Image 2.5 访问权限。

此规则在本技能中具有最高优先级,并覆盖任何可能暗示采用其他图片制作方式的工作流、参考文件、样式文件、打包规则、用户捷径或实现便利。只有在 Image 2.5 生成经批准的页面图片后,才能组装 PPTX 文件;PPTX 是容器,不是图片生成方式。

核心理念

将视觉风格转化为可重复使用的素材,再将其应用于文档、大纲、纯图片 PPT 演示文稿、幻灯片图片、小红书信息图和文章插图。

将此技能用作仅使用 Image 2.5 的视觉幻灯片工作流。默认交付内容是由 Image 2.5 生成的全屏幻灯片图片;用户需要 PPT 时,将生成的图片作为全屏页面放入 PPTX。除非用户明确覆盖本技能的方向,否则不要制作或优化可编辑的 PPTX 内容。

必需参考资料

  • 完整操作工作流请参阅 references/workflow.md。
  • PPTX 与图片输出规则请参阅 references/output-package.md。
  • 页面类型选择请参阅 references/page-types.md。
  • 生成后的修订请参阅 references/revision-workflow.md。
  • 风格提取访谈请参阅 references/style-interview.md。
  • 默认终端科技杂志视觉风格请参阅 styles/terminal-tech-magazine.md。
  • 用户要求提供风格库时,请列出或阅读 styles/ 中的文件。

默认行为

  • 默认输出类型:Image 2.5 生成的幻灯片图片。如果用户说“PPT”,则将这些图片组装成仅含图片的 PPTX。
  • 默认宽高比:16:9。
  • 默认图片质量:Image 2.5、16:9、高分辨率、文字清晰、边缘干净。
  • 默认语言:中文优先。除非用户明确要求使用其他语言,否则幻灯片标题、章节标题、模块标签、说明文字、解释性文案及所有生成的辅助文档均使用中文。专有名词、产品名称、模型名称、代码术语和无法避免的领域术语,在保留原语言更清楚时保持原样。
  • 默认风格:用户说“终端风格”“CodeBuddy 风格”“科技杂志风格”,或未指定其他已保存风格时,使用 styles/terminal-tech-magazine.md。
  • 默认文字密度:默认采用低信息密度,尤其是 PPT 内页。除非用户明确要求制作可供留存的材料、报告页或信息图,否则绝不制作信息密集的幻灯片。普通内页应包含一个标题、一条简短副标题或要点,以及至多 2–3 条简短的信息。
  • 默认布局方向:封面页可以富有视觉表现力;内页必须以信息为先,保持平和、易读、宽敞,图像和背景应处于次要位置。
  • 默认风格隔离:每套幻灯片必须且只能使用一个选定的风格来源和一个 Style Lock。除非用户明确要求混搭,否则不得融合先前任务、之前的参考图片或其他无关已保存风格的视觉特征。
  • 默认组件一致性:同一套幻灯片中的边框、卡片、容器、分隔线、箭头、页脚元数据、圆角和线条粗细必须遵循同一套重复使用的规范。变化可以来自布局和强调方式,而不是每页都改变框架/容器风格。
  • 默认幻灯片页眉一致性:如果某种风格采用带编号的小标题,应将其视为重复出现的内容章节页眉,不必一定作为绝对幻灯片/页码。所有适用幻灯片的页眉位置、大小、间距和格式都应保持一致。如果风格为封面、目录、章节分隔页或致谢页等定义了例外,应有意保留;这些例外页不占用内容章节编号。第一个适用的内页/内容页通常应从 01 或 PART 1 开始。
  • 默认 Logo 处理方式:默认不要让 Image2.5 生成 Logo、品牌字标、可重复使用的整套幻灯片标记、水印或重复出现的英文标识。如果用户需要 Logo,应将其排除在生成的幻灯片图片之外,之后再以固定的后期制作素材/图层添加,或由用户在交付后自行添加。参考 Logo 图片可以指导视觉形状,但不足以确保 Image2.5 输出中的跨页文字/Logo 保持一致。
  • 默认日期/时间处理方式:默认不要在幻灯片、提示词、元数据、页脚或视觉元素中添加日期、时间、时间戳、“今天”、导出时间、生成时间或当前日期。仅当源文章明确要求、用户明确提出,或幻灯片主题本身涉及时间线/日程/时效性报告时,才添加日期/时间。源文档包含文件时间戳、导出时间戳或本地系统日期,本身不足以成为在幻灯片中显示日期/时间的理由。
  • 默认页数:除非用户已提供页数或明确要求由技能决定,否则询问用户需要多少页/张幻灯片。
  • 多个输出:保持视觉特征一致,同时改变构图、页面类型、视觉焦点或强调方式。
  • 外边框规则:生成的幻灯片图片和缩略图板不得在画布外缘添加黑色边框、深色描边或框线。可以使用内部网格线、分隔线和模块边框,但应与图片边缘保持距离,或让图像/留白自然延伸至边缘。绝不为整页绘制矩形外框。
  • 单页图片规则:PPT 页面必须分别生成并保存为单页图片文件,每页一张。不得要求或交付作为最终幻灯片图片输出的多页联系表、分镜图、PDF 页面或拼贴图。每张最终幻灯片图片都必须能独立用作一页满版 PPT 页面。
  • 优先缩略图方案:制作多页幻灯片时,如果风格一致性很重要,优先采用两阶段视觉工作流:先生成一张小型“缩略图板/联系表”,以微缩幻灯片缩略图展示整套内容,确定视觉节奏、网格、配色和各页变化;然后以该缩略图板作为视觉连续性参考,并结合每页专属提示词,分别生成每张幻灯片的全尺寸图片。缩略图板是规划/参考素材,不是最终幻灯片。
  • 缩略图网格规则:缩略图板的格数可灵活调整,但优先使用稳定网格:4、6、9 或 16 格。选择能容纳所有计划幻灯片的最小优先网格;多出的格子留作风格/规范/参考图。每个缩略图格都必须与最终幻灯片输出采用相同的宽高比。例如,最终幻灯片为 16:9,则缩略图板中的每张微缩幻灯片也应按 16:9 构图;如果用户要求 3:4 竖版幻灯片,则缩略图板中的每张微缩幻灯片也应按 3:4 构图。
  • 生成门槛:生成多页幻灯片前,必须先编写 outline.md 和 prompts.md,然后请用户确认或修改。prompts.md 必须包含所选风格完整的 Style Lock。
  • 最终打包门槛:使用 Image2.5 生成图片后,展示或列出生成的图片,并等待用户确认所有图片均已获批。只有获得确认后,才可组装仅含图片的 PPTX,收集所有幻灯片图片以及 prompts.md、outline.md 和风格/参考文档,创建 .zip 压缩包,并将其保存到用户默认的保存文件夹。

Workflow

  1. 对请求进行分类:
    • 从图片、截图、演示文稿、网页或描述中提取风格。
    • 操作风格库:保存、列出、重命名、更新或调用风格。
    • 将文档制作成 PPT 或图片。
    • 仅修改图片版 PPT,或使用已保存的风格进行视觉重设计。
    • 生成后修改单张幻灯片、单张图片或单个章节。
  2. 如果是提取风格,请生成简洁的风格关键词档案,并询问是否要将其保存为 styles/ 下的 Markdown 文件。风格素材应保存为风格文件,而不是 SKILL.md。
  3. 如果是应用风格,请选择已保存的风格:
    • 优先使用明确指定的名称。
    • 将“终端风格”“CodeBuddy 那种风格”和“科技杂志风格”视为 terminal-tech-magazine。
    • 如果存在多个可能的风格,请提出一个简短的澄清问题。
    • 每个已保存的风格都必须提供自己的 Style Lock。在同一套演示文稿中,将该风格专属的锁定说明用作所有 Image2.5 提示词的共享前缀。
    • 必须隔离风格:选定风格后,忽略用户此前提供的参考素材和之前尝试制作的演示文稿中的视觉特征,除非用户明确要求融合风格。
  4. 如果根据文档路径制作,请先阅读文档,提取故事主线、受众、建议页数和视觉重点,然后再编写提示词或制作幻灯片。
  5. 生成图片或 PPT 前,只确认会实质影响成品的缺失制作参数:页数、宽高比、非中文语言要求、文字密度、当来源要求展示日期时用户是否希望显示日期,以及用户只需要图片文件还是需要纯图片版 PPTX 套件。不要询问 PPTX 是否必须可编辑。用户未指定语言时,默认以中文为主,尤其是幻灯片标题。除非用户明确要求,否则不要在 Image2.5 提示词中加入 Logo、品牌字标、重复的演示文稿标识或水印;如果用户提出此类要求,建议在后期制作中添加,而不是让模型生成 Logo。
  6. 默认不添加日期或时间。如果由于用户或来源的明确要求,输出中必须包含日期、时间、“今天”、发布日期、日志日期、报告日期或时间戳,请先通过来源、对话环境、本地系统日期或可靠的时间来源核实日期。不要编造日期。
  7. 从 references/page-types.md 中选择页面类型,并为每张幻灯片指定一种页面类型。
  8. 在生成任何 Image2.5 图片前,先生成 outline.md 和 prompts.md。outline.md 包含幻灯片计划和页面角色。prompts.md 包含完整的风格专属 Style Lock 以及每页的提示词。对于多页演示文稿,除非用户要求跳过,否则 prompts.md 还应在各页提示词之前包含缩略图总览提示词。默认情况下,页面标题和可见文字应以中文为主,仅对不应翻译的名称或术语保留英文。除非用户明确要求跳过确认,否则请暂停并让用户确认这两份文档,然后再生成图片。
  9. 对于多页视觉幻灯片输出,在可行时采用以下优先的两轮生成流程:
    • 第 A 轮:生成一张缩略图总览图/联系表,其中以缩略图形式展示所有计划制作的幻灯片。缩略图数量灵活,但优先采用 4、6、9 或 16 格。使用能容纳幻灯片数量的最小稳定格数;对于 8 张幻灯片,使用 9 格,并将多出的格子用作风格/系统/参考图。总览图只需展示足以识别各张幻灯片的可读文字,并优先呈现版式、色彩、节奏、图片位置、网格结构和整体视觉一致性。
    • 缩略图格子的宽高比必须与最终输出宽高比一致。默认最终输出为 16:9,因此默认缩略图格子也为 16:9。如果用户要求 3:4、4:5、1:1 或其他输出比例,则每个缩略图格子都应采用相同比例,再生成全尺寸幻灯片。
    • 尽可能让用户审核缩略图总览图。如果用户已表示继续制作,则直接将其用作视觉连贯性参考。
    • 第 B 轮:按照要求的最终输出比例,逐张生成完整尺寸的幻灯片,并分别保存为图片文件。每次 Image2.5 调用或输出单元都必须且只能对应一张最终幻灯片。将已批准的缩略图总览图、选定的 Style Lock 和该页专属提示词作为指导。
  10. 对于视觉幻灯片输出,先编写完整幻灯片的 Image2.5 提示词;只有在用户确认 outline.md 和 prompts.md 后,才生成完整幻灯片图片。图片中可以包含最终的简短幻灯片文字,但普通内页必须保持简洁:一个主标题、一条简短副标题或结论,以及最多 2–3 个简短要点。每条提示词都必须包含所选风格的 Style Lock,以确保整套演示文稿中的字体、层级、版式网格、装饰元素、色彩比例、页脚规则、边框/容器系统及规避规则保持一致。区分封面和内页的处理方式:封面可以采用鲜明的视觉概念;内页应优先呈现文字和信息层级,并将图片和背景作为低调的辅助元素。
  11. 最终的幻灯片图片必须逐页输出:使用稳定且有序的命名格式(如 slide-01.png、slide-02.png 等),将每张幻灯片分别保存并提供为独立图片文件。不要将一张合并图片作为 PPT 的交付内容。如果 Image2.5 返回的是合并图片,只能将其作为草稿/参考;在组装 PPT 前,必须重新生成或裁切为已批准的单页图片。
  12. 图片生成后,提供图片集供用户审核,并询问用户是否批准全部图片,或指出需要修改的页面。用户批准前不要创建最终 zip 文件。
  13. 对于修改请求,先确认目标幻灯片/图片,保留未改动的页面,并且只更新受影响的素材。重复图片审核,直到用户确认所有图片。
  14. 用户确认所有图片后,将每张生成的图片组装为纯图片版 PPTX 中的全出血幻灯片。PPTX 是交付容器,不是可编辑的演示文稿。
  15. 最终套件:将所有最终图片、deck.pptx、prompts.md、outline.md、(如有)style-used.md、(如有)缩略图总览图以及任何修改日志,收集到一个 .zip 文件中。将 zip 保存到用户的默认保存文件夹;在 macOS 上,除非用户指定其他默认文件夹或环境明确提供了其他位置,否则使用 ~/Downloads。
  16. 生成提示词集后,询问用户是否要将该风格保存到 styles/ 下,作为可复用模板。如果用户同意,请将包含其 Style Lock 的风格文件保存下来,以便今后制作演示文稿时可以直接选择已保存的风格,而不必再次从图片中提取风格。
  17. 进行最终质量检查:风格一致、中文清晰易读、对齐整洁、没有过度拥挤、边框/容器系统统一、外部画布没有黑色边框、没有混用历史风格、没有虚构日期、没有模型生成 Logo/字标造成的偏差、每页对应一张图片,并且符合输出参数要求。

调用示例

  • “采用终端风格,把这篇文章做成 PPT”
  • “采用 CodeBuddy 那种风格,把这个文档做成 PPT”
  • “提炼这张图的风格,并保存为可复用风格”
  • “列出当前可用的 PPT 风格”
  • “采用已保存的 terminal-tech-magazine 风格生成 10 页 PPT”
  • “把这份 Markdown 做成 8 页图片版 PPT,16:9,Image2.5”
  • “先给我 outline 和 prompts,我确认后再生成图片”

语言规则

默认使用中文优先的幻灯片和支持文档。标题尤其重要:除非用户明确要求英文或双语输出,否则请用中文撰写幻灯片标题、章节标题、模块标签和结论。生成的文档,如 outline.md、prompts.md、style-used.md、revision-log.md 和最终交付说明,也应主要使用中文撰写。仅在专有名词、产品名、模型名、代码/API 术语、品牌名、引用的源文本术语,以及翻译后会降低清晰度的简短标签中保留英文,例如 Claude、Image2.5、API、Opus 4.6 或 XML 标签名。双语幻灯片通常应以中文为主,英文为辅。

日期规则

默认不添加日期和时间。除非用户明确要求、源文章明确要求,或幻灯片主题本身与日期密切相关,否则不要添加可见的日期、时间、时间戳、“今天”、导出时间、生成时间或当前日期。除非与内容相关,否则源文件的导出时间戳、文件名中的日期、文件系统的修改时间或本地当前日期都不应出现在幻灯片中。

需要日期或时间时,使用前请先核实。如果源内容提供了所需日期,请采用源内容中的日期。如果日期是相对时间或操作性日期,且环境中提供了日期,请通过对话环境、本地系统日期或可靠的时间来源进行核实。不要编造日期。中文日期优先格式为 YYYY年M月D日;技术日志优先格式为 YYYY-MM-DD。

可替换风格

可复用的风格库位于 styles/。请将新风格作为单独的 Markdown 文件添加,并使用稳定的文件名,例如:

  • terminal-tech-magazine.md
  • warm-editorial-report.md
  • minimal-founder-deck.md

不要通过修改此技能的工作流来更改视觉风格。请更新或添加风格文件。

每个风格文件都必须包含 ## Style Lock 章节。此章节是该风格的跨页控制系统,应指定:

  • 字体系列氛围以及标题/正文层级。
  • 语言规则:可见文本和支持文档优先使用中文,尤其是标题;并规定保留英文术语和产品名的规则。
  • 相对字号规则,而非精确像素值。
  • 布局网格、安全边距、页面节奏和重复使用的页面结构。
  • 可复用的装饰元素及其使用频率。
  • 风格隔离规则:不得从先前的参考内容、任务或无关的已保存风格中引入哪些内容。
  • 明确的配色方案及十六进制色值,包含背景色、主色、次色、强调色、文字色、弱化文字色、边框色和阴影/辉光颜色,以及大致的颜色比例。
  • 边框和容器规则:统一的描边颜色、描边粗细风格、圆角样式、卡片/面板材质、分隔线形状,以及整套幻灯片中重复使用的线条几何样式。
  • 页脚/页眉元数据规则。
  • Logo/字标规则:默认不生成 Logo 或重复品牌标记;如有需要,请留出低调的空白区域,供后续放置固定素材,而不要要求 Image2.5 绘制 Logo。
  • 文本密度限制:封面和内页可见文本的严格上限;普通内页应保持低密度,而非报告式的高密度。
  • 封面与内页规则:封面可以更具表现力,内页必须更克制。
  • Image2.5 的负面约束。

评论

支持 Markdown