想低成本用AI做漂亮PPT？这篇拆穿了HTML方案的坑：别光看便宜，调试CSS的时间可能让你崩溃，不如试试更直接的格式。
对比了三种AI生成PPT的方式：直接操作PPTX难看、AI出图无法编辑、HTML折中但会出错。实测12页麦肯锡风格HTML-PPT平均每页0.5刀，比remio贵1.5倍，生成时间超11分钟比remio慢一倍，且有4页出现文字丢失或元素位置错误。调试CSS花费大量精力，例如圆点不可见定位过程耗时47秒经过5步排查，最终根因是<span>默认display:inline导致宽高不生效。总结HTML的CSS机制因“幽灵般的远程作用”导致调试困难，建议中间格式应描述对象和状态而非过程。
AI 生成 PPT 是不是 HTML 格式最合适这个话题很有意思，感谢 @wangyuanzju 认真的测试。 首先我承认 HTML 肯定是不够完美的，会出这样格式错误的问题，可能需要人工二次纠正。...
AI 生成 PPT 是不是 HTML 格式最合适这个话题很有意思，感谢 @wangyuanzju 认真的测试。 首先我承认 HTML 肯定是不够完美的，会出这样格式错误的问题，可能需要人工二次纠正。 然后得说清楚咱们定位不一样，我这是给个人用的 Skill 你是做通用产品，那么对成本的敏感度会不一样。 接着我就要说一下我思考的维度： 1. 用户在乎的是好看，或许还要能编辑 Codex 有一个很强的直接操作原生 PPTX 的插件，但是我不爱用，因为做出来的太难看了，拿不出手！ 然后直接 AI 出图，那做出来的 PPT 是最好看的，但是没法编辑，只能修改提示词重新抽卡，偶尔还会有些文字错误 折中下来 HTML 做出来就好最好的，还能编辑。 2. 选 AI 最熟悉训练最多的方式 发明一个格式让 AI 生成中间格式，再把中间格式翻译成 PPTX 本身是没问题的，但是这个格式一定要 AI 最熟悉的训练最多的，做出来好看的。 如果你用一种 AI 没训练过的 JSON 格式、XML 格式，加上 lint 脚本，当然能做出来完美的转换，但是它会有 HTML 好看吗？是不是只能有有限的几种模板可以选择？ 比如我最近在做字幕和视频剪辑相关，所需要的数据格式我也一样是优先考虑 HTML + React 组件这种 AI 很熟悉并且能做出来好看效果的格式。最终把这种中间格式变成视频。 WY @wangyuanzju 因为宝玉说HTML/CSS就是最佳的做PPT的IR，试用了一把baoyu-design，那我们经典的12页麦肯锡风格脚本。结果：成本比guizang低将近一半，12页PPT，平均每页0.5刀，但比remio还是高1.5倍；时间超过11分钟，比remio慢一倍。 关键是最后还有4个页面有严重的问题没搞定（如图，有三页是很多文字都没了，将近空白，有一些架构屋明显太小）。这些问题，Claude Code又查了好久才知道怎么回事。 用HTML/CSS做PPT，感觉先得烧个香，因为你就指望它一次过。如果一次过的话，说实话生成效果还是蛮漂亮的，但问题是它很难一次过，而它没有一次过的时候，AI查问题就折腾了，因为CSS的机制太灵活，很多机制是不直观的，比如这次的问题，AI最后给出的解释是： 确认了，这就是 bug 本身：<section data-label="Cover"> 标签上没有 on-navy class，on-navy 只加在了内层的 <div class="frame cover on-navy"> 上。 但 CSS 规则是： section[data-label].on-navy { background: var(--navy); color: var(--paper-ink); } 这条选择器要求 on-navy 加在 <section> 元素本身上才会生效。由于实际写在了子元素 .frame 上，<section> 保持默认浅色背景 var(--paper)，而 .cover-title 等文字颜色却因为在 .on-navy 后代作用域内被设置成了浅色（.on-navy .kicker { color: var(--gold); }、.on-navy .page-title { color: var(--paper-ink); } 这类后代选择器，只要祖先链上任意元素有 on-navy 就能命中）——于是造成了浅色文字画在浅色背景上，视觉上完全隐形。 你能看明白吗？ 上次试用guizang skill的时候，也是花大量时间在调问题上，比如有个过程是这样的： 第 10 页的时间线圆点在渲染后不可见。完整定位过程耗时约 47 秒，经过 5 步排查： 视觉发现"看不见圆点，只有虚线" 猜测是动效 data-anim 状态问题 排除动效，发现 .tl-node 本身没被 [data-anim] 选中 才真正定位根因：.dot 是 <span>，默认 display:inline，width/height 在 inline 元素上不生效 还要再检查另一处同模式的元素会不会也中招——靠对比另一页截图"渲染正常"，反推出那处恰好因为父容器是 flex 才侥幸没坏 修复动作本身只用了几秒（加一个 display:block），定位用了近一分钟。 这就是CSS这套机制的设计问题。CSS的为了让工程师能够少写代码，很多机制不是看一眼就知道效果的，要做很多运算。 我们的经验，给LLM的DSL，要尽可能的做到信息的局部性，尽量不要有“幽灵般的远程作用”，要尽量的做到所见即所得，要描述对象和状态而非过程。这里面有很多门道，我们也是刚入门。 🔗 View Quoted Tweet 💬 5 🔄 0 ❤️ 2 👀 2630 📊 5 ⚡