我自己这段时间的演示很多都做 HTML 了，好久没体验主流 Agent 产品的 PPT 功能了。
但 PPT 仍然是主流。开会要 PPT、汇报要 PPT、路演要 PPT。AI 已经迈过了那个临界点，能帮你做 PPT 了，但到底哪个最好用？
近期有好几个家里的亲戚让我帮忙用 AI 跑 PPT。说真的，我本来以为随便挑一个就行，结果试了一圈下来，发现差异比我想象的大得多。我个人觉得，近期用下来 Qoder Work > Kimi > 豆包 > 其他。
核心原因你可能想不到，不是谁生成得更好看，也不是谁模板更多，而是管线稳定性。这个维度，一般用户不太会关注，但它恰恰是决定 AI PPT 能不能真正进入工作流的关键。
先说明几件事。
第一，这不是那种把市面上所有能做 PPT 的 Agent 全部拉出来跑一遍的标准评测，就是我自己这段时间的真实使用体验。像天工、讯飞智文、小浣熊这些，有的是没来得及试，有的是试了但觉得不太有代表性，就没放进来。Qoder Work、Kimi、豆包这三款已经够有代表性了。
第二，WorkBuddy 我其实也挺想试的，但它本身没有预置的 PPT 模式，PPT 能力完全依赖 Skill 市场里的第三方 Skill。用过 Skill 做演示材料的朋友应该知道，Skill 目前还是更适合做 HTML 格式的演示，视觉效果好，交互灵活。而 PPTX 是一条更重的管线，Skill 在这个场景下还不够稳定。所以这次没有把它纳入对比。
第三，MiniMax Code 我买了 token plan，但 PC 端登录一直不太顺利，可能是我的网络环境或者防火墙的问题，下次换个网络环境再试试。
好了，说回正文。
01一个多数人不会注意的事实：PPTX 不是文件，是一个搬家箱
先把 .pptx 文件后缀改成 .zip，解压。
你会看到一堆 XML 文件：slide1.xml、presentation.xml、theme.xml。这就是 Open XML 标准，微软 Office 2007 之后的基础格式。一个 PPTX，说到底，是几十个 XML 文件通过关系链串联起来的结构化文档。
用搬家来类比。PPTX 不是一张画布，而是一个打包好的搬家箱，里面每个物品都有编号、位置说明和相互关系。PowerPoint 打开它时，就像一个严格的搬家工人，必须按清单核对每个物品的编号和位置，对不上就打不开。
所以AI 做 PPT 不是在「画图」，而是在操作一个文件系统。 这就是为什么 AI 直接生成 PPTX 这么难。
02HTML 路线：这条管线为什么这么难跑稳
说到这个，得先交代一下技术背景。
Qoder Work 和 Kimi，其实走的是同一条技术路线。系统预置 HTML 模板，AI 生成内容填充到模板里，工程化实现 HTML 的展示预览和导出，最终转换成 PPTX。本质上，都相当于构建了一条「HTML 生成→预览→修订→导出 PPTX」的管线。
坦率的讲，这条管线真的很长。我把它拆成 5 个工位来看。
第一个工位，接单，AI 理解你的需求，规划 PPT 结构。第二个工位，打包，AI 生成 HTML/CSS 代码，每页一个 HTML 片段。第三个工位，扫描，浏览器渲染，提取每个元素的精确位置、字体、颜色、大小。第四个工位，贴标签，CSS 属性映射到 DrawingML，PPTX 的内部图形语言。第五个工位，装车，输出 PPTX 文件。
五个环节，环环相扣。哪一个掉了链子，最终文件就可能打不开或排版错乱。
而且这里有个技术细节。CSS 里的 SVG 滤镜、复杂 mask，在 DrawingML 里压根没有对应实体。也就是说，即使你生成了一页完美的 HTML 幻灯片，转换到 PPTX 时，某些视觉效果一定会丢失。
所以你会发现，很多开发者都在干一件事，用 HTML 生成幻灯片，然后写 Python 脚本手动转 PPTX，修修补补。这就是为什么我说「需要一个稳定的网页生成、修订、转化的管线」，因为目前这条管线，大部分产品都没跑稳。
03Qoder Work：细节见真章
既然路线一样，那 Qoder Work 到底好在哪？
我觉得是几个小细节，不大，但加起来就很说明问题。
第一个，强制质检。 我亲眼看着它第一次生成 HTML 卡片的时候，有几个元素溢出了容器。然后它自己检测到了，自动修了一轮，再输出的时候版式就正常了。这个行为不是 AI 魔法，而是工程意识，它知道 HTML 渲染后的结果必须经过质检才能进转换管线，溢出的元素到了 DrawingML 里就是灾难。
第二个，模板可沉淀，而且是 HTML + MD 双控。 模板沉淀这个功能很多 AI PPT 产品都有，但 Qoder Work 的做法不太一样。它用了类似于 awesome-md-design 那套理念，模板由 HTML 和一份 Markdown 设计描述共同控制，不是简单的「套个壳」。配合它自己的管线，HTML 负责结构、MD 负责设计约束，两边一起保证最终输出的稳定性。这个思路在同类产品里我还没见到过。
第三个，预览、修订、导出的工作台。 这是我觉得最舒服的一点。Qoder Work 针对 PPT 和网页设计做了有针对性的预览设计，不是通用浏览器那种粗糙的预览。你在工作台里看到的，基本就是导出后的样子。修订的时候也能实时看到效果，不像有些产品，预览是一回事，导出是另一回事，中间差了十万八千里。
说到底，这些都不是什么惊天动地的功能，别家想追也能追。但合在一起，能感觉到这个产品团队对「管线」这件事有比较深的理解——不是只把 PPT 生成当成一个功能点来做，而是当成一条需要精心维护的工程管线来对待。
04Kimi：同一条路，慢了半拍
Kimi 走的是和 Qoder Work 一样的路线，HTML 模板 + 工程化管线。2026 年 4 月的 K2.6 更新加了一些东西，像视觉参考上传、可编辑 SmartArt，Kimi 在图表解析上也有独门绝活——上传一张含图表的截图，能提取数据并重建为可编辑的 PPT 图表对象。
但说实话，这半年 Kimi 的 PPT 功能没怎么大更新。一些新的理念，比如强制质检、模板沉淀这套东西，还没用进去。不是说它做得差，就是节奏上慢了半拍。
我的感觉是，Kimi 的 PPT 功能目前处在一个「能用但不够好用」的阶段。如果你做的是学术汇报、需要长文本解析，Kimi 可能还是最好的选择。但如果你需要反复修改、精确控制，它就不太够用了。
05豆包：路线不同，但也能理解
豆包的情况不太一样。
从体感上看，豆包走的应该不是 HTML 管线，更像是直接操作 PPT 元素来生成——有点像 OOXML 直出的思路，但做了一层工程封装。这能解释为什么它经常出现版式错乱的小问题，对图片的支持也不太友好。
如果硬要打分，我给个 60 分吧。能用，但细节上确实粗糙。
不过话说回来，豆包本身是个 Chatbot，拿来跟 Qoder Work 这种 Agent 比其实不太公平。Chatbot 的定位是「回答问题」，Agent 的定位是「完成工作」。 要求一个 Chatbot 在 PPT 管线这种复杂工程任务上做到 Agent 的水平，确实强人所难。从它的产品定位出发，能做到这个程度，我觉得也能接受。
06临界点已过，但真正的竞争才刚刚开始
WPS AI 在 2026 年转向了 HTML 专业引擎，官方说法是「传统 AI PPT 一做表格、数据图表就排版崩盘」。行业共识正在形成，HTML 路线才能处理复杂 PPT。
AI PPT 已经过了那个「能不能做」的阶段，进入了「能不能稳定地做」的阶段。
管线稳定性，不是生成速度，不是模板数量，不是风格准确度，将成为决定产品排名的核心变量。它取决于四个维度：模型代码生成质量、渲染提取鲁棒性、样式映射完整性、错误恢复机制。这些能力不是一朝一夕能建成的。
Qoder Work 目前在这个维度领先，是因为它把管线作为核心能力来建设，而且确实沉淀了一些别家还没用上的细节理念。Kimi 路线一样，但节奏慢了，豆包路线不同，且本身定位就不在同一赛道。
07最后一句话
回到开头那个搬家箱的类比。
AI PPT 的未来，不是让箱子变得更花哨，而是让打包流程更可靠。 Qoder Work 目前在这条路上走得最远，不是因为它生成的 PPT 最好看，而是因为它最像一个知道怎么打包箱子、还知道打包完要检查一遍的工人。
我的判断是：AI PPT 已经过了临界点，但真正的竞争才刚刚开始。管线的稳定性，决定谁能从「AI 实习生」变成「AI 正式员工」。
