PPT Design Skill：AI 做完幻灯片后，谁来负责验收？

把一份材料交给 AI，几分钟后得到一个能打开的 .pptx，通常只是最容易的一步。标题可能挤到边缘，数据页在投影上看不清，企业模板也可能只剩相近的颜色。等人真正打开 PowerPoint 逐页检查，生成阶段省下的时间很快又花在返工上。

PPT Design Skill 把完成标准往后推了一段：先确认受众、页面目标和视觉方向，再选择生成模式；文件生成后继续导出 PDF 和逐页 PNG，检查整体效果、文字溢出、需求遗漏与可编辑性。发现问题后返回页面计划、视觉方向或构建脚本，而不是直接修补最终图片。

这套流程适合正式汇报、客户提案和品牌模板等需要持续编辑与明确验收的任务。只想快速得到内容草稿，或没有可用的 PPTX 渲染环境时，完整流程可能显得过重。

一份演示文稿怎样走到可交付

仓库把正式任务拆成一条可回退的流程。开始构建前，Agent 先把需求整理成验收合同和页面计划；生成后，结构检查与视觉检查分别回答“文件内部是否合理”和“最终画面是否可用”。

正式工作流要求每条需求标明优先级，并写出最终页面中应该观察到什么。例如“使用企业蓝”很难验收，“封面、章节页和数据强调色使用品牌蓝，正文保持高对比度”就能在 PNG 中逐项核对。

复核分成两道门。第一道看视觉重心、构图、密度、节奏和留白；第二道检查溢出、裁切、不可读文字、需求遗漏、来源和可编辑性。这样可以区分方向错误和局部缺陷：一整套页面风格不适合管理汇报时，流程返回视觉方向；只有某页标题越界时，才修改构建脚本的局部位置。

三种模式，解决三种控制需求

三种模式共享需求确认与最终复核，区别在于 Agent 对页面布局掌握多少控制权。

模式	什么时候选	Agent 如何生成	需要接受的代价
Build Mode	正式交付、复杂图示、逐元素布局	编写可复现 Python 脚本，显式控制坐标、颜色、字体和组件	时间更长，需要设计判断和公开 API 知识
FreeStyle Mode	快速探索、主题草稿、内容结构已明确	向 generate_ppt 提供 query 或结构化 content	无法逐元素控制，仍需视觉复核
VI Build Mode	已有企业模板或明确品牌规范	提取模板的字体、颜色、间距和框架页，再新增内容	无法承诺保留所有母版、SmartArt、动画和底层文件行为

Build Mode 使用 pptx-designer 公开 API控制页面元素。FreeStyle 的 query 与 content 是同一生成函数的两种输入，不代表两个渲染引擎。VI Build Mode 会提取“设计 DNA”，也就是模板中的颜色、字体、边距和重复视觉规则；模板约束明确提醒，PowerPoint 底层 XML 文件结构（OOXML）中的复杂母版和动画不一定能够完整保留。

选择模式时可以先问一个实际问题：这次任务最怕什么出错？最怕版式失控时选 Build，最怕品牌走样时选 VI Build，只需要迅速探索结构时再考虑 FreeStyle。

第一次试用，做一份六页真实材料

判断这套 Skill 是否适合团队，最有效的方式是选一份六页左右、要求明确的真实材料。保留一个品牌硬约束，再加入一页容易拥挤的数据内容，才能看出流程是否真的帮助了交付。

准备条件

• Python 3.10 或更高版本；
• 一个测试项目目录，不在正式项目中直接试装；
• Windows PowerPoint COM，或 LibreOffice 与 Poppler 组成的后备渲染链；
• 允许 Agent 在测试项目中创建任务目录和本地输出文件；
• 图片生成不是必需项；涉及图库、网络或付费 API 时另行授权。

先检查，再安装

下面的命令来自仓库安装器，本次文章优化没有执行。工作目录是克隆后的仓库根目录，/path/to/test-project 要替换成真实测试项目。

git clone https://github.com/sunchaokun/PPT-Design-Skill.git
cd PPT-Design-Skill
git checkout --detach 94766b8ca9b0097a222b3118f2da67d2d9d436ae

# 只读检查 Python 包与渲染依赖
python installer/install.py --check

# 安装到指定 Codex 测试项目
python installer/install.py \
  --platform codex \
  --project \
  --target /path/to/test-project

python skill/scripts/check_runtime.py

环境检查脚本会报告 Python、pptx-designer、python-pptx、Pillow、LibreOffice 和 Poppler 状态。看到 MISSING 或 INFO 时，应先逐项处理或记录提示，再决定是否开始验收；安装器的主进程也可能在 pip 失败后继续结束，所以不能只看退出码。

给 Agent 一个可验收的请求

请使用 PPT Design Skill 为产品季度复盘制作 6 页中文演示文稿。
受众是管理层，使用 Build Mode。
必须保留公司 Logo 和品牌蓝；数据页在会议室投影上可读。
先给出页面计划与视觉方向，确认后再生成。
完成后导出逐页 PNG，检查文字溢出、需求遗漏和可编辑性。

固定提交中的 Skill 描述和模式路由应该把这类请求引向 Build Mode，但本次静态核对没有在真实 Agent 中验证自动触发。试用时应观察以下结果：

1. 项目内出现独立任务目录、任务清单和七份过程模板，已有同名目录没有被覆盖。
2. 构建前可以查看并确认页面计划、验收合同和视觉方向。
3. 生成结果同时包含 PPTX、结构报告、PDF 与逐页 PNG，PNG 数量和页数一致。
4. 复核记录能指出问题属于整体方向还是局部页面，并返回正确阶段修改。
5. 最终 PPTX 的重要文字、形状和图表仍可编辑，用户确认只覆盖本地交付。

一个复杂 Skill 包怎样分工

核心 skill/ 包共有 23 个文件。分层的重点不在数量，而在每类资源承担不同职责。

资源	负责什么	对 Agent 的帮助
SKILL.md	识别任务、选择模式、设置确认门和禁止行为	决定何时停下来询问、何时继续执行
references/	工作流、领域范式、公开 API、品牌模板、运行环境和交付规则	只在对应阶段加载详细知识
scripts/	初始化任务、检查依赖、检查 PPTX 结构和渲染	把可重复的机械步骤固定下来
templates/task-init/	保存 brief、研究、验收合同、页面计划、视觉方向和复核记录	让一次任务的决策过程可以检查和继续
assets/ 与 prompts/	核心包没有内置这两类目录	图片、模板和生成素材由具体任务或用户提供

任务初始化脚本要求输出目录位于项目内，并在目录已存在时停止，避免覆盖已有任务。任务模板把过程状态从通用指令移出，Agent 下次继续工作时不必只依赖对话记忆。

安装器声明了 14 个目标平台，并区分全局与项目级 Skill 目录。这里的“支持”主要表示安装器知道相应的目录位置，不代表所有平台都经过同样深度的端到端触发与渲染测试；具体平台名称和路径应以固定提交中的安装器配置为准。

两条代表性执行路径

从空白画布制作正式汇报

用户明确要求正式演示、逐元素布局，并且没有必须保留的模板时，Skill 路由到 Build Mode。

1. Agent 收集受众、场景、语言、页数、素材、数据来源和可编辑性要求。
2. 初始化独立任务目录，填写验收合同、研究材料、页面计划和视觉方向。
3. 用户确认结构与方向后，Agent 使用公开 pptx_designer API 编写构建脚本。
4. 结构检查脚本统计页数、尺寸、形状和文本；渲染链生成 PDF 与逐页 PNG。
5. 视觉方向不合格时返回页面计划，局部溢出时返回构建脚本；复核通过后由用户确认本地文件。

沿用企业模板新增页面

用户提供 template.pptx 或明确要求遵循品牌规范时，Skill 路由到 VI Build Mode。

1. Agent 确认允许修改的页面，以及必须保留的 Logo、页脚、法律文本和品牌约束。
2. 读取模板的页面尺寸、字体、颜色、间距和重复装饰，整理成可确认的设计规则。
3. 用户确认品牌规则与页面计划后，Agent 保留框架页并新增内容页。
4. 继承页面和新增页面一起进入结构检查与逐页渲染。
5. 品牌方向失真时返回设计规则，局部缺陷返回构建脚本；公共 API 无法保留复杂母版行为时标记阻断，由用户决定是否接受近似结果。

两条路径都从用户触发走到最终验证，也都把方向问题和局部缺陷送回不同阶段。这个回退规则比“不断缩小字号直到不溢出”更值得借鉴。

安装和图片能力有哪些副作用

安装入口包含几项需要提前知道的行为：

• 默认执行 pip install --upgrade pptx-designer，会联网并修改当前 Python 环境；
• --force 会完整替换目标 ppt-design-skill 目录；
• --all 会尝试写入所有平台的全局 Skill 目录；
• --render-deps 可能触发 Windows 渲染依赖安装；执行前应阅读固定提交中的安装器分支并确认系统变更范围；
• pip 安装失败只会打印警告，后续仍需运行环境检查脚本。

AI 图片属于可选能力。运行与安装说明要求把凭据放在具体演示项目的 .env 中。核心 Skill 不定义浏览器自动化；如果具体任务另行使用图库搜索、网络或图片服务，可能涉及账号和费用，调用前应单独取得授权。

核心 Skill 没有定义外部上传、消息发送、Git 提交或发布流程。用户确认页面方向或本地 PPTX，不等于同意把文件上传到第三方、发送给外部收件人或发布到站点。

最值得带走的四个设计思路

把主观要求改写成可观察结果

“专业”“高级”“科研感”很难直接验收。PPT Design Skill 要求补上受众、页面角色、视觉锚点和最终 PNG 中应该看到什么。相同方法也适用于网页、报告和图片生成任务。

先判断问题属于哪一层

整体方向错误时返回视觉方向，页面结构错误时返回页面计划，局部元素越界时才修改构建脚本。问题回到产生决策的地方，避免在错误方案上反复调整坐标。

让脚本承担确定性工作

目录初始化、依赖检查、PPTX 结构检查和渲染由脚本完成。Agent 把注意力留给内容、设计与判断，用户也能单独复现机械步骤。

按需加载领域知识

科研、医疗和政府内容不应该默认套用商业路演结构。仓库把领域范式放入 references，需要时再读取，主 Skill 只保留路由和共同约束。

哪些地方不适合直接照搬

• skill/SKILL.md 与 README、workflow、设计原则仍有较多重复，继续增长会削弱渐进式加载的收益。
• 固定提交中的 references/content-schema.md 是空文件，但其他文档已经使用结构化 content，公开契约存在缺口。
• docs/usage-guide.md 声明 1.1，skill.json、安装器和任务初始化脚本声明 1.2；仓库又没有 GitHub Release，升级依据不够集中。
• installer/detect.py 与实际安装入口使用的 installer/platforms.py 重复维护平台路径，部分值不同，长期存在漂移风险。
• “40,000+ styles”来自仓库描述和平台元数据，固定材料没有提供同等强度的可重复质量评估，数量不能直接代表设计效果。
• 三组评估案例记录了修改原因和 LLM 对 PNG 的复核，但固定提交的 CI 没有重跑完整 PPTX→PDF→PNG 视觉链，最终质量仍要在自己的字体、模板和渲染器上复验。

谁会喜欢，谁应该选轻一点的工具

当前需求	采用判断
正式、可编辑、需要逐页验收的演示文稿	值得用真实材料完成一次 Build Mode 试验
已有企业模板，愿意接受复杂母版的保真边界	先用 VI Build Mode 测试框架页和品牌规则
只需要快速内容草稿	选择更轻的文本转幻灯片工具，减少确认与渲染成本
依赖复杂动画、SmartArt 或像素级母版复刻	保留人工 PowerPoint 流程，Agent 负责内容和辅助页面
服务端批量生成但没有可靠渲染链	先解决字体、LibreOffice/PowerPoint 和 PNG 验收环境

仓库的价值集中在交付流程，而不是某一张案例封面。用六页真实材料记录首次结果、修改次数、字体替换和最终可编辑性，比浏览样例图库更能说明是否适合团队。

版本与继续验证

本文基于固定提交 94766b8。核心 Skill 与安装器声明版本 1.2；核对时 pptx-designer 在 PyPI 上是 1.0.0b7，要求 Python 3.10 或更高版本。仓库采用 MIT 许可证，没有 GitHub Release。

本次核对完整阅读了 skill/ 包、安装器、平台配置、测试、CI 和三组评估记录；没有执行安装器、生成 PPTX、调用图片 API 或渲染页面，也没有验证安装后的 Agent 自动触发效果。静态材料足以解释设计与使用边界，不能证明实际成片质量和跨平台兼容性。

试用前应重新核对 仓库主页、运行引擎版本和目标 Agent 当前的 Skill 目录规范。完成六页试验后，把真实运行环境、渲染器、字体替换和失败回退记录下来，再决定是否扩大到正式交付。