汇报 PPT 的难点常常不是缺少模板，而是业务逻辑还没说清，材料和页面又被同时修改。对不常画图的运营或 PM，更稳妥的做法是先把事情讲清，再把内容分到页面，最后修复视觉问题。本篇用虚构的社区维修活动复盘说明三段工作：从文字生成流程图、组织整份汇报、检查并修复已有幻灯片。示例没有实际生成文件，也不承诺一键完成所有软件兼容。
先确定听众、结论和可用材料
假设活动负责人要向团队解释“为什么现场等待变长，以及下次怎样分流”。先给出报告用途、可用时长、听众对流程的熟悉程度和必须决定的问题。输入包包含已核对的预约记录摘要、现场观察、流程说明和改进建议。真实项目的姓名、联系方式和内部明细只在必要且授权范围内使用，给外部工具的副本应去除无关字段。
把事实、推断与提议分开：记录显示某时段到场集中是事实；人员安排不足是需要调查的解释；增加分流岗位是提议。图表与标题不能把提议写成既定结论。数据缺失时保留空项和待补清单，不让模型填上看似合理的绩效数字。先接受一页故事线，再展开整份幻灯片。
准备可检查的交付约定：页面比例、语言、品牌字体、必须保留的数据、图源格式、目标演示软件和是否需要逐元素编辑。可编辑 PPTX、展示图片与 PDF 是不同交付物，不能因为文件能打开就认定编辑能力、字体和动画都被保留。
场景一：把自然语言变成业务流程图
从四列开始整理：谁做、做什么、需要什么、产生什么。维修活动可以写成居民预约、接待核对、技师评估、确认处理、完成或转介。接着补足分支：未预约到场、缺少配件、用户取消、预计超时，以及谁负责告知下一步。不要先画一条顺畅主线后把所有失败都塞进“其他”。
让 Agent 先输出步骤与分支表，标明来源和待确认事项，再生成小图。用泳道区分居民、接待和技师的责任；箭头标交接内容，菱形问题须有明确出口。若需要展示系统组件，另画结构图，不把“登记完成”当作软件服务名称，避免把业务流程与技术架构混在一起。
不会写图形代码也可以先用自然语言校对节点表。若采用 Mermaid，保留源文本并在支持的渲染器中查看；若使用在线编辑平台，先核对账号权限、分享范围、服务条件及是否会上传业务材料。没有授权不把内部流程发到外部站点。图形工具返回预览或编辑链接以后，还要打开检查权限和可编辑性，不能只依据链接名称判断完成。
初稿验收可以让未参与制作的同事复述一次“缺配件的居民最后去了哪里”。如果图无法回答，就修分支与责任，不是换颜色。交付图源、步骤表、版本号和预览；渲染状态与业务复核状态分别记录。示例中的图只是待制作规格，不冒充本篇已经执行的结果。
场景二：从大纲生成整份汇报
先写六页结构：需要团队决定的事、活动概况、等待发生在哪一段、原因与未知项、改进方案比较、下一步负责人。每页给一句结论、最多几个支持点、证据来源和需要展示的图表。主页面保留决策所需信息，明细放附录；不能把所有段落直接挤进模板再期待自动排版解决内容过量。
生成前将 Markdown 大纲映射到页面：标题、正文、表格、图示、来源、备注分别放在哪里。对生成器的页数、要点数或文本长度限制，先用长中文标题、九个要点和跨页表格做小样。若工具会截断，必须显式报告并拆页，不能默默丢掉第九条再把输出称为完整。检查正文、讲稿与源大纲的对应关系，防止漏掉关键例外。
GitHub 的 PptxGenJS 是可参考的开源 JavaScript 演示文稿生成库，MIT 许可，支持创建文字、形状、图片、表格等页面对象。它适合有脚本维护能力的团队把已确定的大纲生成 PPTX；具体环境与版本应先核对。选择它是复用现有生成能力，而不是重新实现文件格式。本流程没有下载执行它，也不把它当作已经在 SkillPI 核验的专用 PPT 技能。
自动生成后先做内容验收：关键事实、数据单位、来源日期、人员责任和待决定事项是否保留；其次做对象验收：文字是否仍可编辑，流程图是独立形状还是整张图片，备注是否在目标软件中可见。文字可编辑不意味着导入图片内的节点也可编辑，整份 PPTX 与内部图源要分别保管。
实操：防止“排版成功但内容缺失”
假设第五页有两种方案、各自成本、依赖和失败情形，一共九条说明。工具只放入前八条，刚好把“新增岗位仍需培训”截断。验收时逐页对照内容清单，发现差异后拆为“方案比较”和“实施前提”两页，并在前者增加明确交叉引用，而不是删掉限制以维持固定页数。
让 Agent 的任务写成：“使用 outline.md 与已批准数据摘要，先返回页级计划。所有事实保留来源编号，未知项不得补写。生成文件时列出每页覆盖的输入段落；遇到超出布局容量先拆页并报告，不截断。流程图提供源文件，配图仅用已授权素材。不发布文件、不邀请外部人员、不声称未运行的兼容检查已通过。”
接受页级计划后先生成两张样页：最密的一页和包含图的一页。核对目标软件中的字体、图形和编辑行为后再扩展整套。这样把格式问题留在小范围内解决，也能区分内容错误、生成错误与目标软件差异。
场景三：修复现有文件，保留真实信息
已有 PPT 先备份，再逐页建立问题表：页码、对象、症状、影响和建议动作。常见问题包括文本溢出、相互遮挡、图例缺失、颜色语义不一致、截图模糊以及表格单位丢失。先改影响理解与事实的问题，再统一间距、字号和配色；不能为了整齐删掉来源和限制说明。
修复有两类产物：建议清单，或实际修改后的新文件。工具如果只给建议，就标“待实施”，不要说已经修好了。自动修改也要对照原稿核对数字、标签和图表数据。长文本优先重写或拆页，单纯缩字号容易让投影无法阅读。减少颜色数量时保留语义映射，并用线型、图标与文字补足区别，避免只靠红绿传达结论。
Canvas Design 可选用于本阶段制作原创静态视觉方向或一页 PNG/PDF 参考稿，帮助统一留白、层级与配色。它需要能生成并检查文件的 Agent、明确尺寸、用途和已批准素材，并检查字体与素材许可。其产物不是可编辑 PPTX，也不会自动修复现有幻灯片或验证业务数据；只在确实需要静态视觉参考时使用，再由演示文稿流程实施到页面。
兼容性验收：展示一致与可编辑分开
在最终要用的软件和机器中打开文件，检查字体替换、文本框、箭头、透明图片、表格分页和备注。正常放映尺寸看一遍，再检查导出 PDF；若需要在 WPS、Office 或 Keynote 之间使用，分别记录实际检查过的版本和结果，没有检查的环境留待验证。不要把某次打开正常扩大成所有软件都不会乱版。
图片化页面可减少某些布局变化，但会牺牲对象编辑、文字检索、无障碍阅读和动画行为。若采用兼容展示版，清楚标注其用途，同时保留可编辑母版、图源与数据来源。PDF 也有字体、裁切和链接检查，不能跳过。最终交付清单包含可编辑文件、必要的展示备份、原始大纲、图源与逐页问题处理记录。
技能选择与常见问题
不因为原文列出六个名字就自动装齐。专用绘图、整套生成与修复候选应各自核查来源、版本、许可证、账号要求、API Key、运行环境和输出范围，再用两页小样验证。当前仅关联已核验且适合静态视觉参考的技能，不为未核实名称猜造安装链接；技能开源许可也不保证第三方服务、模型或素材免费。
一句话能得到能用的图吗？能得到初稿，但还需补责任、分支和事实来源。生成后能继续改吗？取决于是否交付真正源文件及目标软件支持，实际重开修改一次才有证据。排版一键修复靠谱吗？先备份，逐页比较内容与对象变化，只将检查过的问题标完成。
为什么用了好模板仍不好讲？检查是否每页只有清楚的问题与结论，是否用图说明关系而不是装饰。时间紧该先做什么？先完成结论、证据和核心流程，再改视觉；省去的检查应写进待验收清单，不用“全自动”掩盖。技能目录更新后如何维护？固定用同一份小样复查新增候选的实际输入输出与来源，将适合的关联加到具体步骤，记录替换原因并撤除失效链接。