AI 技能人工智能【免费下载链接】codex-ppt-skillGPT-Image-2 PPT Generator Skill for Creating Image-Based PowerPoint Presentations in Codex and Other Skill-Compatible Agents项目地址https://gitcode.com/gh_mirrors/co/codex-ppt-skill点击查看免费下载导读本文基于 docs/en/workflow.md 系统讲解 codex-ppt-skill 的标准工作流Standard Workflow它以分阶段确认为核心将 PPT 生成拆解为资料审阅、大纲确认、视觉风格确认、图像后端确认、样张确认、批量生成、质检修复、讲稿与装配、风格存档九个阶段避免一次性生成整份演示文稿带来的返工成本。读完本文你将掌握 codex-ppt 每一步的产出物、审批门禁approval gate、关键脚本调用链以及如何与源码中的 SKILL.md、workflow-gates-and-progress.md、slide-generation-and-subagents.md 等文档配合完成一套可控、可追踪、可复用的图像式 PPT生产流程。一、工作流设计理念为什么必须分阶段确认workflow.md 开篇即点明核心原则强调分阶段确认staged confirmation。与一键生成 20 页 PPT的体验相反codex-ppt 要求在正式产出前依次确认大纲、风格、图像后端与样张从而大幅降低返工成本。这一理念在 docs/en/design.md 中得到了更完整的阐释AI 生成 PPT 最重要的不是速度而是一个可控、能产出可用结果的过程。因此设计者刻意将流程拆成若干步骤——读资料、出大纲、定风格、出样张、确认后批量生成、装配 PPTX——并且主张图像式 PPT与可编辑 PPT解耦为两个独立 Skill先生成高质量的整页图像式演示待内容和视觉方向都确认无误后再按需决定是否做可编辑转换。从 SKILL.md 的 Hard Constraints 可以看到这套理念如何被强制化为纪律尊重审批门禁在 workflow-gates-and-progress.md 规定的审批通过之前不得创建最终的deck_spec.json、speech.md、prompt 任务、幻灯片图像或.pptx文件样张是唯一的风格契约样张获批后必须记录sample_generation_method并传给每个 slide 子代理禁止子代理擅自切换后端本地绘制不是回退方案Pillow、SVG、HTML/CSS/canvas 截图、python-pptx/PptxGenJS 排版、手动叠加等全部属于失败模式failure modes不能当作图片生成的备胎。可见分阶段确认不是简单的流程建议而是由 Skill 文档与状态脚本共同执行的硬约束。二、九阶段全景每个阶段做什么、产出什么2.1 阶段总览标准工作流共九步其中阶段 1–5 是确认期只出文档与单张样张阶段 6–8 是生产期批量出图、质检、装配阶段 9 是可选的沉淀期存档风格阶段名称核心产出关键审批门1审阅源材料主题/受众/目标/页数/必备内容清单—2确认大纲outline.md大纲获批前禁止任何下游产物3确认视觉风格2–3 个风格方向 1 个推荐风格获批4确认图像后端内置 image 工具 或scripts/image_gen.py后端获批后全篇不得中途切换5生成并确认样张origin_image/slide_XX.png单张样张获批前禁止整篇生产6批量生成origin_image/slide_XX.png全部样张获批 子代理并行派发7质检与修复修复后的最终图像装配前逐页检查8讲稿与装配speech.md{deck_name}.pptx状态文件全部recorded/accepted9可选存档风格个人风格库中的*.md用户同意保存其中阶段 2–5 的审批顺序与不得提前生成最终产物的红线在 workflow-gates-and-progress.md 中被固化为 Mandatory Phase Gates在前一阶段被用户批准之前不得进入下一阶段除非用户明确要求跳过确认。2.2 阶段 1审阅源材料代理首先要对输入材料文章、报告、论文、笔记或大纲做信息抽取明确五类信息主题与中心论点topic and central argument目标受众target audience演示目标presentation objective所需页数required slide count必须包含/必须排除的内容以及是否需要图像资产。对应源码侧SKILL.md 给出了同样的清单并补充了一个务实细节若用户未指定页数代理应自行选择实用页数典型演讲为 8–12 页。这一阶段不产出任何文件只形成决策上下文供后续大纲撰写使用。2.3 阶段 2确认大纲outline.md代理生成outline.md通常包含幻灯片编号与标题每页 3–5 个关键点每页的角色role封面、目录、概念解释、流程、对比、数据佐证或总结可选的视觉创意必需的图像资产及其用法。大纲获批前不得生成任何最终幻灯片图像、speech.md或.pptx文件——这是全流程第一条硬门禁。关于大纲的写法outline-style-and-sample.md 提供了更细的规范每页需要定义布局角色与意图如 cover、agenda、section divider、concept、process、comparison、timeline、data evidence、architecture、case study、summary、QA并且当幻灯片依赖本地源图时直接在Required images列表中使用 Markdown 图片语法内嵌资产让用户在大纲评审阶段就能可视化核对哪张图配哪一页。推荐的大纲骨架是Slide 1: Cover Slide 2: Context / problem Slide 3-7: Main argument or sections Slide 8: Summary / recommendation / closing大纲写完后代理应停在原地向用户汇报outline.md路径、页数、必需图像及映射关系并说明尚未生成任何图片或 PPTX等待用户批准。2.4 阶段 3确认视觉风格代理提出2–3 个风格方向并推荐其一。候选风格来自12 种内置风格见 docs/en/styles.md清爽专业风、科研答辩风、手绘技术解释风、麦肯锡风格、党政红风格、教学课件风等用户的个人风格库~/.codex-ppt-skill/references/可用CODEX_PPT_HOME环境变量重定向位于 Skill 安装目录之外升级/重装 Skill 不会丢失从用户提供的截图、PDF 或演示文稿中复刻风格。完整风格预览见 样式与个人风格库。源码侧outline-style-and-sample.md 补充了风格确认的三条实操规则用户已指定风格或提供了参考物时不要强行走 2–3 选 1直接抽取风格规则并复述确认即可PDF/PPT/PPTX 风格参考必须先渲染成真实页面图像再观察不能仅从文档结构、XML、元数据或对象层级推断视觉系统默认只复刻风格、不复刻内容除非用户明确要求沿用参考材料中的文字与数据。风格一旦选定整份演示应保持一致的视觉语言但各页布局可随内容角色变化——即同一套视觉系统每页不同构图而不是复制同一模板。2.5 阶段 4确认图像生成后端图像后端只有两类规则由 backend-selection.md 明确内置图像工具首选例如 Codex 的image_gen、OpenClaw 的image_generate本地 API/CLI fallbackscripts/image_gen.py仅在内置工具不可用、用户明确要求 API/CLI 模式、或当前能力无法满足请求时启用。选择后端有两条红线不要仅凭环境名或订阅上下文推断内置工具可用必须先实际探测工具是否可调用后端确认后全篇必须固定使用同一后端中途不得切换。后端确定后代理需要用确认话术向用户汇报检查结果并征求同意内置模式与 fallback 模式各有标准话术模板见 backend-selection.md。若走 fallback 模式image_gen.py会自动加载~/.codex-ppt-skill/.env中的OPENAI_API_KEY、OPENAI_BASE_URL、CODEX_PPT_IMAGE_MODEL配置从 image_gen.py 源码可见其默认模型为gpt-image-2.5-flare、默认尺寸为2560x1440、默认质量为medium、默认输出格式为png并内置了对gpt-image-*系列的像素总量、边缘长度、宽高比上限的校验逻辑。2.6 阶段 5生成并确认一张样张样张是控制质量的核心手段。代理只先生成一张代表性样张优先选内容页而非封面然后检查五项指标文字是否清晰文本清晰度风格是否符合预期信息密度是否合适颜色与布局是否稳定该设计能否扩展到整份演示。样张必须直接保存为最终页文件名如origin_image/slide_08.png获批后即作为该页的最终图不得另建sample_slide.png因为装配脚本只识别slide_XX.png命名见 outline-style-and-sample.md。样张获批后代理要把sample_generation_method写入deck_spec.json至少记录backend_used、tool_name、modegenerate/edit、prompt_source、size/quality/模型配置、approved_sample_path、input_context_preparation、handoff_rule——这是传给子代理的同路径生产契约。只有样张获批后才允许进入整篇生产。2.7 阶段 6批量生成支持子代理并行样张获批后代理逐页生成origin_image/slide_XX.png。在支持子代理的环境中每页由一个子代理并行生成加速多页生产每一页都遵循样张确认的风格与图像后端。从 slide-generation-and-subagents.md 看批量阶段有一套严格的状态机协议先用prepare_slide_prompts.py生成每页的 JSON 任务prompts/slide_XX.json与状态文件slide_jobs.json、slide_run_state.json用slide_job_status.py查看可派发的槽位dispatch_slots_available与待处理页每个子代理只领取一个slide_XX.json任务随后主代理立即用record_slide_dispatch.py --slide slide_XX --agent-id id记录派发子代理返回后主代理视觉检查输出再用record_slide_result.py --backend-used built-in image tool --selected-source path将选中图复制进origin_image/slide_XX.png并记录后端溯源子代理无法使用所选后端或无法访问必需输入图时用record_slide_blocker.py记录阻塞而不是生产低质量替代品。关键命令示例# 查看可派发槽位与待处理页 ~/.codex-ppt-skill/.venv/bin/python {skill_root}/scripts/slide_job_status.py {base_dir}/{deck_name} # 记录派发 ~/.codex-ppt-skill/.venv/bin/python {skill_root}/scripts/record_slide_dispatch.py \ {base_dir}/{deck_name} --slide slide_02 --agent-id agent id \ --prompt-file prompts/slide_02.json # 记录结果并复制进 origin_image/ ~/.codex-ppt-skill/.venv/bin/python {skill_root}/scripts/record_slide_result.py \ {base_dir}/{deck_name} --slide slide_02 --agent-id agent id \ --backend-used built-in image tool --selected-source /absolute/path/to/slide_02.png \ --qa-note Text readable; style matches the approved sample.派发阶段的核心原则是是否已派发/是否已完成只能以脚本记录为准聊天消息不算数Chat messages alone do not make a slide dispatched or complete。若运行环境无法生成子代理代理应在派发步骤停下并上报 blocker而不是退化成串行低质生产。为了让子代理任务自包含slide-generation-and-subagents.md 要求主代理在派发前把跨页语义写进deck_spec.jsondeck 级deck_context多页共用的规范概念如源文摘要、核心论点、术语表、人物、定义、时间线、必需命名页级local_context该页工人必须看到的页面专属事实如总结这六条特征对比这两种方法把上述框架前文结论这些示例这类隐式指代展开成显式清单避免子代理去猜上下文。每页任务使用结构化视觉简报structured visual brief将画布、风格、布局、文本、视觉元素、约束分层描述而不是依赖一段冗长的风格段落。一个典型的slide_XX.json结构包含type16:9 全页 PPT 图像、canvas纵横比、禁用页码、style风格名、视觉方向、配色、字体、质感、deck 一致性、deck_context、layoutrole/intent/composition/content_zones/variation_rule、text标题、关键点、中文渲染质量要求、local_context、visual_elements、constraints无水印、无无关 logo、无额外页码。完整的 JSON 模板可直接在 slide-generation-and-subagents.md 中取用。2.8 阶段 7质量审查与修复装配之前代理必须逐页检查文字清晰度无乱码与大纲的一致性内容是否被截断标题、要点是否完整跨页视觉一致性是否出现多余页码除非用户要求元素是否重叠。修复策略分两档详见 project-assembly-and-reporting.md严重问题用更严格、更约束化的 prompt 整页重新生成局部小问题优先用所选后端的图像编辑能力定点修复fallback 模式下用scripts/image_gen.py edit --image {slide_path} --prompt ... --out {new_slide_path}且验证编辑结果后才允许替换最终页。2.9 阶段 8讲稿与装配代理先生成speech.md再用assemble_ppt.py装配为.pptx讲稿会自动写入每页的备注区notes section。speech.md的写作规范见 project-assembly-and-reporting.md值得特别注意写的是可朗读的演讲逐字稿而不是对页面文字的简要概括按演讲语言书写中文 deck 用中文讲稿每页用## Slide N: {Title}标题装配脚本据此把讲稿映射进对应 PPT 备注全篇保持一个交付风格技术讲解型 / 论文研读型 / 产品 Pitch 型 / 培训工作坊型 / 高管汇报型再按页面角色微调语气长度参考封面/目录/章节分隔页 1–2 段普通内容页 2–5 段中文约 150–400 字密集的概念/架构/数据页可更长从演讲者视角写作如这里我想强调的是…我们先看左边这个结构…避免 AI 腔与综上所述式空话且不要提及讲稿由 AI 生成。装配命令如下{base_dir}是{deck_name}/的父目录{deck_name}.pptx必须与项目文件夹同名# 若共享运行环境缺失先执行 bootstrap内部步骤通常由代理代为完成 python3 {skill_root}/scripts/codex_ppt_runtime.py bootstrap # 装配 ~/.codex-ppt-skill/.venv/bin/python {skill_root}/scripts/assemble_ppt.py \ {base_dir} {deck_name}.pptx --aspect-ratio 16:9装配前必须核验状态slide_jobs.json中所有已生成页为recorded、样张页为accepted只要存在pending、dispatched或blocked状态就应停止并上报不能装配。assemble_ppt.py支持16:9与4:3两种纵横比默认 16:9只读取slide_01.png、slide_02.png这类最终命名图草稿与样张变体会被忽略。2.10 阶段 9可选保存风格如果本次演示使用了自定义风格或经过调整的风格代理应在最终报告中提示可将该风格存入个人风格库今后按名字直接复用。存储位置为${CODEX_PPT_HOME:-~/.codex-ppt-skill}/references/位于 Skill 安装目录之外升级不会丢失个人风格与内置风格同名时个人风格优先因此也可以利用同名覆盖来定制某个内置风格详见 docs/en/styles.md。若用户同意保存代理再读取 style-library.md 执行存档。三、审批门禁与可见进度状态即证据3.1 七阶段强制门禁workflow-gates-and-progress.md 将九个阶段压缩为七道强制门禁明确顺序为源材料阅读与资产抽取 → 大纲确认 → 视觉风格确认 → 图像后端确认 → 单张样张批准 → 整篇生成 → 质检/讲稿定稿/PPT 装配。硬性规则包括大纲获批前不得创建最终的deck_spec.json、speech.md、prompt 任务文件、幻灯片图像或.pptx确需内部规划文件时使用.draft.前缀命名如deck_spec.draft.json、speech.draft.md并明确标注非最终若 deck 依赖必需源图在大纲确认时停下请用户核对页 ↔ 图映射后再进入风格与图像阶段。3.2 用户可见的进度清单对于非平凡 deck代理应维护一个用户可见的检查清单且同一时刻只亮一个活动步骤准备源材料、大纲、风格与后端决策生成并批准一张样张准备幻灯片任务与状态派发幻灯片子代理记录生成的幻灯片结果质检、修复、讲稿与 PPT 装配。每一步都有对应的完成证据completion evidence例如派发子代理的完成证据是slide_job_status.py显示存在可派发页、且每个已派发的工人都被record_slide_dispatch.py记录记录结果的完成证据是record_slide_result.py已将选中图复制进origin_image/slide_XX.png并写入后端溯源。核心纪律是不能仅凭聊天对话标记步骤完成必须依据真实文件或脚本记录的状态。四、标准项目结构与最终交付物一个完整的项目目录结构如下见 project-assembly-and-reporting.md{base_dir}/{deck_name}/ ├── origin_image/ │ ├── slide_01.png │ ├── slide_02.png │ └── ... ├── prompts/ │ ├── slide_01.json │ └── ... ├── slide_jobs.json ├── slide_run_state.json ├── deck_spec.json ├── outline.md ├── speech.md └── {deck_name}.pptx对应 docs/en/quickstart.md 中的用户可见交付物用户通常收到outline.md大纲、origin_image/slide_XX.png每页最终图、speech.md每页讲稿以及{presentation-name}.pptx最终 PowerPoint 文件。最终报告应包含项目目录、PPT 文件路径、图像目录、outline.md/speech.md/slide_jobs.json路径、页数、所用后端及每页结果的记录确认、讲稿是否写入 PPT、以及任何被重新生成/阻塞/存在已知限制的页面见 project-assembly-and-reporting.md。若使用自定义或明显调整过的风格报告末尾应附一句可保存到个人风格库的提示。五、工作流的验收标准与常见误区SKILL.md 给出了成文的 Acceptance Criteria可作为一次完整流程是否真正闭环的检验清单输出为合法的.pptx每张预期最终图都存在于origin_image/slide_XX.png每张最终图都由确认过的后端生成并经record_slide_result.py记录样张页由运行状态标记为 accepted 除外outline.md反映已批准的大纲需要讲稿时speech.md存在且装配时写入 PPT 备注slide_jobs.json与slide_run_state.json反映最终状态必需源图在页面上可见呈现否则上报 blocker若被阻塞最终回复须指明阶段、slide id、证据路径与未完成原因不得宣称 deck 已完成。实践中容易踩的误区包括凭聊天消息标记派发/完成、让子代理切换后端、在样张获批前就生成全篇、用本地绘制替代真实图像后端、把草稿文件留在origin_image/导致装配读到多余图、以及跳过讲稿写作直接装配。这些都与工作流文档和状态脚本的设计意图相悖规避它们即可稳定复现大纲 → 风格 → 样张 → 批量 → 质检 → 装配的完整闭环。六、与其他文档的衔接标准工作流是 codex-ppt 的主流程说明书与 Skill 内其他文档构成完整的操作手册体系可按需查阅工作流门禁与进度审批门禁、进度清单与完成证据大纲、风格与样张规范outline 写法、风格确认话术、样张要求与sample_generation_method记录后端选择内置工具与 API/CLI fallback 的决策规则与确认话术幻灯片生成与子代理任务 JSON、派发循环、结果/阻塞记录与溯源项目装配与报告目录结构、讲稿规范、装配命令与最终报告样式与个人风格库 与 style-library.md12 种内置风格与个人风格存档安装与配置、快速开始、示例提示词 与 FAQ 覆盖从安装到疑难排查的完整旅程。一句话总结这套工作流的设计价值它不是追求最快的 PPT而是追求每一步都可确认、每个产物都有记录、每次失败都可追踪的确定性流程——大纲、风格、后端、样张四道关卡把关在前状态脚本全程留痕最终装配前逐页质检从而让 AI 生成演示文稿从开盲盒变成可控的工业化生产。赞分享AI 技能人工智能【免费下载链接】codex-ppt-skillGPT-Image-2 PPT Generator Skill for Creating Image-Based PowerPoint Presentations in Codex and Other Skill-Compatible Agents项目地址https://gitcode.com/gh_mirrors/co/codex-ppt-skill点击查看免费下载相关推荐Higress PPT 生成 MCP Server 详解从 appCode 认证到异步 PPT 生成的完整工作流Higress PPT 生成 MCP Server 详解从 appCode 认证到异步 PPT 生成的完整工作流 本文围绕 Higress 仓库中的 MCPAPI网关后端云原生LLM 网关人工智能MCP 服务GoReleaser 工作原理解析从 .goreleaser.yaml 到发布完成的四阶段流水线GoReleaser 工作原理解析从 .goreleaser.yaml 到发布完成的四阶段流水线 本文以 GoReleaser 官方文档 How it wor开发工具CI/CD构建工具Lightdash QueryBuilder 架构解析从 MetricQuery 到 SQL 的两阶段生成管线Lightdash QueryBuilder 架构解析从 MetricQuery 到 SQL 的两阶段生成管线 导读 本文以 Lightdash 后端 SQL后端前端数据分析数据可视化人工智能AI Agent上一篇mergekit 模型合并方法完全指南Linear、球面插值、任务向量与专用算法全解析下一篇FluxDown新手入门10个必知功能让你快速玩转这款下载神器创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考