我以前也试过很多“一句话生成 PPT”的工具。
体验通常是这样：第一眼看过去还挺惊艳，真正要用的时候就想自己重做。
因为客户汇报材料不是海报。
你不能今天让 AI 做一套，明天想改第 5 页，它把整套风格又带跑了；也不能只是看起来像 PPT，结果打开 PowerPoint 以后全是截图，标题、卡片、表格、架构图都不能单独编辑。
所以我现在更愿意用一条更稳的流程：
先用 HTML 做草稿和视觉定稿。
确认后，再重建成高度可编辑的 PPTX。
这篇就用一个具体案例走一遍：以“知识工程平台建设方案”为主题，做一份面向政企客户的 ToB / ToG 售前汇报材料。
一、用HTML 打草稿
我现在不会直接让 AI 生成最终 PPTX。
原因很简单：PPTX 对 AI 不友好。
人在 PowerPoint 里看到的是一页页幻灯片，但底层其实是大量对象：文本框、矩形、线条、表格、图形、层级、字号、坐标、主题、母版。
你让 AI 直接改 PPTX，很容易出现这种问题：
第 3 页只想改一行标题，它顺手把版式也改了。
第 5 页只想调整架构图，它把颜色体系也换了。
这就是很多 AI PPT 像“开盲盒”的原因。
HTML 更适合Agent写PPT。
HTML 本质上是文本。哪一页在哪里，哪个标题在哪里，哪个卡片在哪里，CSS 怎么控制样式，AI 都能读、能定位、能改。
二、这条流程要用两个 Agent-Skill
第一个是 html-ppt-skill。
它负责生成 HTML 版演示稿。你可以理解成：让 AI 先做一份“网页形态的 PPT”。浏览器打开就能看，结构清楚，也方便反复修改。
第二个是 ppt-master / MasterPPT。
它负责把已经确认的页面，进一步还原或重建成 PPTX。
三、实战操作
这次示范的主题是：
《知识工程平台建设方案》
受众是政企客户、大型企业信息化部门、业务负责人、售前交流对象。
所以这份材料不能做成发布会风，也不能做成那种炫光渐变的 AI 科技模板。
我给它定的方向是：
政企风。
咨询报告感。
白底，黑白灰，单一蓝色强调。
少装饰，少动效，强网格，强边界感。
页面要像正式方案材料，而不是互联网官网。
内容上也要克制。
不讲“全面赋能”“重塑未来”“智能化闭环生态”这种空话，而是讲客户真正关心的东西：
知识从哪里来？
怎么接入？
怎么治理？
这一步非常重要。
如果你只说“帮我做一个知识工程 PPT”，AI 很容易生成一套通用科普材料，或者一套浮夸的科技风模板。
但售前材料不是这么写的。
售前材料首先要让客户觉得：你知道这事怎么落地，也知道哪些事不能乱承诺。
四、先做HTML版本的PPT
生成HTML的Prompt：
请生成一套 8 页 HTML PPT，主题是“知识工程平台建设方案”。
使用场景：面向 ToB / ToG 政企客户的售前汇报材料。
风格定位：Carbon Enterprise、咨询报告、政企售前、黑白灰主色、蓝色单一强调、低装饰、强网格、强边界感。
不要互联网发布会风，不要炫光，不要大渐变，不要浮夸科技风。
页面结构：
1. 封面：知识工程平台建设方案
2. 背景与痛点
3. 建设目标与边界
4. 建设方法论：理、接、管、用
5. 总体架构：来源—治理—资产—服务
6. 核心能力
7. 场景与实施路径
8. 运营机制与价值总结
HTML 实现要求：
- 单个 index.html，可直接浏览器打开。
- 16:9，内部画布 1920×1080。
- 支持键盘翻页。
- 每页保留 notes。
- 所有内容必须在一屏内完整显示，不允许溢出、遮挡、裁切。
效果：
五、HTML 阶段要反复看，不要急着转 PPT
HTML 生成后，我先看页面本身。
不是看它“有没有做出来”，而是看它能不能当售前材料。
我主要检查五件事。
第一，叙事顺不顺。
知识工程不能一上来就讲功能模块。客户还没接受“为什么要做”，你直接讲模块，材料就会变成产品说明书。
所以这套 8 页的顺序是：背景痛点 → 目标边界 → 方法论 → 架构 → 能力 → 场景实施 → 运营价值。
第二，风格像不像正式汇报。
如果页面看起来像互联网发布会、官网落地页、AI 海报，就要改。
这次最后采用的是 Carbon Enterprise 风格：白底、黑灰文字、IBM Blue 强调、无圆角、无阴影、细线分割。
第三，信息密度够不够。
一开始我做过更稀疏的版本，页面看起来空，内容都堆在上半屏。这种在真实汇报里不合适。
后来改成 8 页高密度版本，把背景和痛点合并，把场景和实施路径合并，把运营机制和价值总结合并。
第四，关键页能不能讲。
比如“理、接、管、用”那页，不能只是四个大字。每一步都要讲关键动作、平台支撑、输出结果。
比如架构页，也不能只是画一个漂亮分层图，而要讲清楚：来源、治理、资产、服务分别是什么，GraphRAG 在里面起什么工程作用。
第五，有没有溢出和遮挡。
HTML 阶段就要逐页渲染截图检查。尤其是第 8 页这种内容密度高的页面，很容易底部超出画布。
这一步在 HTML 里改，比进 PPTX 以后再改稳定得多。
六、用 MasterPPT 转成 PPTX
Prompt：
目标是：基于已经确认的 HTML 视觉稿，重建一份“高度可编辑”的 PPTX。
强制要求：
- 禁止把 HTML 页面截图作为整页图片嵌入 PPT。
- 标题、正文、标签、卡片文字必须是 PowerPoint 文本框。
- 卡片、色块、分割线、流程节点、架构层级必须是 PowerPoint 可编辑形状。
- 表格尽量使用 PPT 表格。
- 架构图、四步法、能力流、运营闭环必须由形状和文本组成。
- 导出后检查 slide 数、shape 数、text frame 数、media 图片数量。
你打开以后，标题可以点，卡片可以改，表格可以调，架构图里的模块也不是一整张死图。
当然，它和 HTML 视觉稿不会 100% 像素级一致。
这也正常。
HTML 和 PowerPoint 的排版机制不一样，字体渲染、行高、表格布局、边距都会有差异。
但正式工作里，我宁愿要一个 85% 视觉相似、但 95% 可编辑的 PPTX，也不要一个 100% 像截图、但完全不能改的 PPTX。
七、这条流程真正解决的是什么
这条流程不是为了证明 AI 能“一键生成 PPT”。
恰恰相反，我认为正式 PPT 不应该一键生成。
正式 PPT 本来就是改出来的。
这条流程解决的是三个问题。
第一个问题：前期怎么快速试风格。
用 HTML 很合适。风格、页数、叙事、布局都能快速改，浏览器就能预览。
第二个问题：中期怎么把修改过程沉淀下来。
所有 prompt、HTML、过程记录、截图、修改意见都能保存。别人接手时，不需要猜“当时为什么这么做”。
第三个问题：后期怎么交付可编辑文件。
PPTX 阶段不能偷懒截图，必须重建成文本框、形状、表格、线条这些 Office 能继续编辑的对象。
这才是它和普通 AI PPT 工具的区别。
普通 AI PPT 工具的问题，不是不会生成，而是你很难控制它后续怎么改。
这条流程把控制权拿回来了。
写在最后
我现在觉得 AI 做 PPT 终于开始靠谱，不是因为它能一次生成完美 PPT。
而是因为我们可以把它放进一个合理的工作流里。
先用 HTML 把草稿和视觉方向跑通。
再用 MasterPPT 或脚本把确认后的页面重建成可编辑 PPTX。
最后人工收尾。
每一步都有记录，每一步都能回退，每一步都知道自己在解决什么问题。
这比“一句话生成 PPT”慢一点。
但它更像真实工作。
也更接近正式材料真正需要的东西。
