字数 2417，阅读大约需 13 分钟
我开始相信：下一代演示文稿，不是做 PPT，而是“编排一场表达”
最近看到一个很有意思的 Skill：PPT as Code。
第一眼会以为，它只是把 PPT 换成 HTML 来做。
但仔细看完它的 README，我觉得它真正有价值的地方，不是“把演示做成网页”，而是它在试图回答一个更本质的问题：
为什么我们做演示文稿，总是把大量时间浪费在排版，而不是表达本身？
这也是我为什么觉得，这个项目很值得我们研究。
因为它代表的，不只是一个新工具，而是一种新工作方式：
把演示文稿从“手工排版”，升级为“可编排、可定制、可进化”的表达生产流程。
我们今天做 PPT，最大的问题不是不会设计
很多人以为，做不好 PPT，是因为自己没有审美、不会配色、不会排版。
但我越来越觉得，真正的问题不是这个。
而是传统 PPT 软件，把我们带进了一个很低效的工作模式：
你一打开软件，就开始改字体、调间距、挪图片、试动画。
结果看起来在“做演示”，实际上你是在跟页面搏斗。
最后经常会出现三种情况：
第一，内容还没想清楚，页面已经改了十几版。
第二，视觉看起来很花，但逻辑其实不成立。
第三，花了很多时间“美化”，结果整套东西还是没有节奏感。
PPT as Code 的切入点，恰恰就是先不急着“做页面”，而是先把演示逻辑锁住。README 明确写到，这套 workflow 的顺序是：先锁主题和结构，再锁风格和脚本，再处理图片和页面节奏，最后再落成 HTML。
这件事看似简单，其实非常重要。
因为演示文稿，本质上不是一组页面，而是一种连续表达。
你讲什么、先讲什么、哪一页该停顿、哪一页该用图、哪一页该给结论，这些才是决定演示质量的核心。
它真正聪明的地方，不是“生成”，而是“分阶段决策”
我看这类项目，最在意的一点不是它能不能生成，而是它有没有把高风险决策拆开。
PPT as Code 在这点上做得相当清楚。
它不是一上来就直接给你生成一套成品，而是把过程拆成多个阶段：
brief、主题拆解、风格选项、脚本、图片方案，最后才到 HTML 路线或静态结果。并且开源版默认是conversation-first，不会预设一定能往仓库里写文件。
这背后的思路很像产品设计，而不是模板套壳。
什么意思？
就是它承认：
演示文稿里最贵的，不是最后那份页面，而是中间那些关键判断。
比如：
- • 这套内容到底是说服型，还是汇报型？
- • 这页应该是文字主导，还是图表主导？
- • 整体应该走“科技感”，还是“咨询感”，还是“编辑感”？
- • 当前最该先锁的是视觉，还是叙事节奏？
这些问题如果没想清楚，你再漂亮的页面，也只是“好看的混乱”。
三档模式，背后其实是三种不同的工作心态
这个 Skill 提供了三档工作流：quick、basic、advanced。README 对它们的定位写得很清楚。
表面上看，这是“效率和自由度”的平衡。
但我觉得更有意思的是，它对应了三种很典型的现实场景。
1. Quick：先跑起来，再升级
quick适合最小可用版本、快速原型、先跑起来再升级。
这非常适合什么人？
适合你脑子里已经有点东西了，但还不想一开始就投入太重。
先把表达雏形跑出来，再决定值不值得继续打磨。
2. Basic：先把内容讲清楚
basic适合先确认主题拆解，再确认脚本，再确认图片方案，最后再落 HTML。
这其实最接近大多数职场场景。
因为很多汇报不是要“惊艳”，而是要清楚、稳妥、有说服力。
先确认你到底要讲什么，再去做视觉，这种顺序本身就比直接打开 PPT 瞎改更科学。
3. Advanced：更像一套真正的演示系统
advanced适合更强的视觉锁定、更完整的参考图流程、静态优先、后续可补动态。README 也明确写到，动态效果不是默认先做，而是在静态版确认后进入第二阶段。
这个设计特别好。
因为很多人做演示最容易犯的错误，就是动画先飞起来了，内容还没站稳。
这不是保守，而是专业。
这个项目最让我惊喜的一点：它在认真解决“AI 味”
现在很多 AI 生成的网页或演示，问题不是不能看，而是一眼就能看出是 AI 做的。
什么叫 AI 味？
就是布局很整齐，但没有取舍；
颜色很统一，但没气质；
元素很丰富，但没有真正的视觉判断。
PPT as Code 明确做了一件很对的事：
如果环境支持浏览，advanced可以先找真实的 PPT / slide design 参考图；README 还提到它新增了一个reference search pack，把 Behance、Dribbble、SlideShare、Pitch 以及中文 PPT 网站整理成可复用搜索集。
这件事为什么重要？
因为真实世界里的好设计，不是从“模板库”学出来的，而是从成熟作品的结构、节奏和克制感里学出来的。
你会发现，这已经不是“帮你找图”了，而是在帮你建立一种更接近真实设计师的参考机制。
它对图片的理解，也比很多 AI 工具更靠谱
大多数自动生成演示文稿的工具，搜图逻辑都很粗。
比如主题是“AI 转型”，它就开始全局搜“AI、科技、未来、数据”这种大词。
结果每一页都很像，但没有一页真的对。
PPT as Code 则明确提出：图片逻辑是按页走，不是按主题走。
它会先判断这一页到底想说什么，再提炼这一页自己的关键词，最后结合风格方向去搜图；basic每页 1 到 2 个关键词，advanced每页 3 到 4 个关键词。
这个机制看起来只是多了一层步骤，但效果会完全不一样。
因为演示里的图片，不是装饰品，而是论点的一部分。
好的配图，不是“相关”，而是“这张图就该出现在这里”。
它其实不是在替代 PPT，而是在替代“低价值劳动”
每次聊到这类工具，总有人会问：
“那以后是不是就不用 PPT 了？”
我觉得不是。
至少短期内，PPT 依然会存在。
很多组织协作、汇报归档、领导审阅，依然离不开 PowerPoint 这样的交付格式。
PPT as Code 自己也没有回避这一点。README 说明，这个开源版现在包含一条可选的PPTX export后处理路线：先锁定静态 HTML deck，再通过deck_manifest.json交给 companion skill 导出.pptx；并明确HTML 仍然是 source of truth，PPTX 是保真交付格式。
这说明它的目标不是“消灭 PPT”，而是更现实的一步：
先用更高效的方式把表达做对，再把它交付到传统系统里。
这比“推翻重来”要成熟得多。
为什么我觉得它值得公众号读者关注？
因为它代表的是一种越来越清晰的趋势：
未来很多内容生产，不会再是“直接做成品”，而是先把中间结构抽象出来。
写文章如此，做代码如此，做产品原型如此，做演示文稿也一样。
你会越来越少地从“空白画布”开始，
而是越来越多地从“结构化流程”开始。
这类工具真正改变的，不只是效率，还是人的注意力分配方式。
过去做 PPT，很多时间花在：
- • 调版式
- • 找图片
- • 改动画
- • 对齐元素
- • 修局部视觉
而未来更重要的，可能会变成：
- • 提炼主题
- • 设计表达顺序
- • 选择视觉语境
- • 判断哪些页该用图、哪些页该用图表
- • 把演示做成一套有节奏的叙事
换句话说，工具越强，人越要往“判断”和“编排”上走。
这也是我看完这个项目后最强烈的感受：
下一代演示文稿的核心能力，不再是“会不会做 PPT”，而是“会不会设计表达流程”。
最后
如果你经常要做汇报、做路演、做产品介绍，或者像我一样，经常要把一堆复杂内容讲给别人听，那我很建议你关注这类工具。
不一定是因为它今天就能完全替代你手头的软件。
而是因为它已经把一个很重要的方向讲明白了：
演示文稿不该再是手工排版劳动，而应该是一套可编排的表达系统。
这件事，一旦想明白，你以后再看 PPT，视角会完全
参考链接
- 1. PPT as Code 开源项目 README（中文）https://github.com/Russell-cell/PPT-as-code/blob/main/README-zh.md
