用 AI 做 PPT 踩坑一个多月,我推翻了 3 个核心判断

这个系列写到第五篇了。前四篇分别讲了为什么选 HTML+SVG、为什么约束比自由发挥重要、《AI 生成 PPT 的 4 条路线，怎么选？》、《AI 做 PPT 的另一条路：用工作流换确定性》。5 月 20 日那篇《AI 做 PPT 不难，难的是生成后还能改得动》发出后，有不少网友收藏转发和留言，说明这个方向有人真的在用、在想。

越往后做，越发现有些判断需要修正。不是方向想错了，是做深了才看到更好的路。前四篇里写下的结论，有 3 个核心判断被我自己推翻了。

“能跑通”和“可以放心交给别人用”，中间差得很远。PPT 这种东西，第一眼像样不够，生成后能不能改、能不能稳定复用、能不能在真实演讲场景里接得住，才是真正的门槛。5 月那篇之后，我断断续续做了一个多月，越做越发现：如果只把一个能跑通的版本放出去，读者很可能复现我踩过的坑——生成看起来不错，一到修改、导出、复杂页稳定性就开始摇晃。

如果把 6 月几篇连起来看，线索已经很明显了：先是发现“生成不是问题，稳定才是”；然后把 AI PPT 拆成一键生成、模板约束、图像生成、可编辑工作流四条路线；最后用 Codex 跑了一次“用工作流换确定性”的实践。这些文章现在回头看，其实都指向同一个结论：SlideMind 不应该只做一个从主题自动生成 PPT 的工具，而应该优先解决“已有内容怎样稳定变成可编辑演示稿”这件事。

这篇不发布新工具，也不写教程。只做一件事：把认知变化的过程摊开——每一步是怎么想的，在哪里拐了弯，为什么。

对了的部分

先说没变的。这些判断到现在仍然成立：

可编辑性是刚需，不是锦上添花。 第一篇文章的核心论点——"AI 生成的 PPT 如果只能看、不能改，本质上是一张截图"。这个判断越做越确信。真实场景里没有"生成完直接上台"的 PPT，中间一定要改。

约束驱动优于自由发挥。 四层约束体系（CSS 变量 → 布局类型 → 组件 class → SVG 图表规则）的思路没有问题。稳定交付靠的是系统约束，不是模型灵光一现。

标准页模板化，复杂页才交给模型。 "能用确定性系统完成的事，不要交给概率系统"，这条越验证越对。

先试跑再批量。 先冻结视觉变量、再扩展内容变量，这个控制不确定性的方法是通用的。

错了的部分

错误一：中间态选错了

第一篇文章花了很大篇幅论证"放弃图片生成，改走 HTML+SVG"。方向是对的——应该选结构化表达而非图片。但具体选择错了：应该是纯 SVG，不是 HTML。

HTML 的布局模型（流式排版、CSS 盒模型）和 PowerPoint 的布局模型（绝对坐标、DrawingML）根本不同。我当时的解法是“双层映射”——文字提取为 textbox，SVG 块截图嵌入。简单页面还行，复杂布局下文字偏移、SVG 里的文字提不出来，最终很多页面退化成图片。“可编辑性”这个核心承诺打了折扣。

第一篇文章的判断方向对了——选结构化表达。但在结构化表达内部，选错了格式。

错误二：把主力放错了 pipeline

SlideMind 的 pipeline 把生成过程拆成 analyze → outline → trial → slide_gen → export 五步。每步有明确的输入输出，看起来很工程化。

但跑了 22 页真实 deck 后发现：Pipeline 效果不如直接给 Claude 整份内容稿一次性生成。

诊断出的根因是"pipeline 拆的是流程步骤，而非质量瓶颈"。这个诊断是对的。但我接下来做的事情——在 pipeline 里加 distill（内容蒸馏）和 plan（全局视觉规划）两个新步骤——本质上还是在旧框架里打补丁。

实现一轮后，三条接线全断了：

• distill 把 26 页打包成一次 YAML 输出，格式偏移导致解析失败，系统静默回退到原始大纲。Token 花了，效果为零。

• plan 定义的布局类型和代码里的类型完全对不上。Plan 输出的东西下游根本不认。

• plan 的密度和节奏字段存了但从未传给渲染模型。

这三个问题单独看都可以修。但修完之后，pipeline 本质上还是在用代码硬编排一个 Claude 自然就会做的事——读完整个大纲，先想全局再逐页执行。

这里最值得反省的是“静默失败”。从日志上看，流程还在继续跑，文件也在生成，但关键的 distill 和 plan 实际没有产生效果。也就是说，系统表面上更自动化了，真实质量却没有变好。

这类问题很容易骗过自己。因为工程上多了步骤，文档上多了字段，流程图上也更完整，但如果下游没有真正消费这些字段，或者失败后没有阻断，复杂度只是在给自己制造幻觉。

Claude 直接生成 deck 时不需要"先调一次 distill API 再调一次 plan API"，它在一个 context 里自然完成这些判断。Pipeline 硬编排这个过程，反而切断了 context，制造了格式解析、字段对齐、静默失败等一系列问题。

更准确地说，不是所有 pipeline 都错了，而是把 LLM 的全局思考强行拆成固定 API 步骤，这件事不适合当主线。

旧的 topic → analyze → outline → generate 路径仍然有价值。它适合用户只有一个想法，想从 0 到 1 快速起一份 PPTX 初稿。未来如果把 SlideMind 分享出来，这个入口也会有人喜欢。

但对我自己的主要场景来说，我通常会先把逐页文字稿准备好，确保逻辑完整。这个时候，SlideMind 最该做的不是替我写大纲，而是把已经想清楚的内容稳定视觉化。

错误三：两条路线不该"各走各的"

第四篇文章里，我同时在跑两条路线：SlideMind 产品化（独立 CLI pipeline）和 Codex+Skill（Agent 动态执行）。当时明确说了"两条路线各走各的"。

现在回头看，这句话也需要修正。

不是说两条入口必须合成一个按钮，而是底层能力不应该分裂成两套资产。

SlideMind 的确定性组件——模板引擎、SVG 校验器、PPTX 导出——不应该被绑在一个独立 pipeline 里，而应该作为 Agent 可调用的 tool。Agent 负责理解内容和做视觉决策，确定性代码负责校验和转换。

第四篇文章的 Codex 实践其实已经验证了这个模式：Agent 读取原稿、按 Skill 流程执行、调用工具生成 PPTX、渲染检查、发现问题修改。这就是 Harness 架构的雏形——Agent 做判断、确定性组件做保障。

但当时我把它理解为"另一条路"，而不是"SlideMind 高质量主线应该走的路"。

现在更清楚的拆法是：

• 旧入口保留：从主题或粗略想法出发，快速生成初稿，适合低门槛体验和从 0 到 1。

• 新主线加强：从逐页文字稿或完整大纲出发，Agent 做视觉规划，确定性组件负责模板、校验和导出，适合高质量技术演讲和正式交付。

这不是放弃旧方式，而是把它放回正确的位置。

这个判断也是这一个多月最重要的变化之一：我不再试图让一个固定 pipeline 解决所有场景。一个只有主题的用户，和一个已经写好逐页文字稿、只需要高质量视觉化的用户，本来就不是同一个需求。

以前我有点想把它们塞进同一条主线里。现在看，应该承认它们是两个入口：一个负责低门槛起稿，一个负责高质量交付。

三个判断的变化

修正后的方向

推翻了这三个判断之后，新的架构方向是：

SlideMind 变成 Claude Code / Codex 的 Skill，确定性工程组件暴露为 Agent 的 tool。

同时，输入假设也要改：主线不再是“给一个主题，让 LLM 从零写完整大纲”，而是“用户已经准备好逐页文字稿 / PPT 大纲，SlideMind 负责视觉结构、跨页一致性和可编辑导出”。

具体来说：

• 宿主 Agent 负责判断 — 读完整大纲，全局视觉规划，逐页决定用模板还是生成 SVG，处理用户修改请求。不需要 SlideMind 自己编排 LLM 调用。

• 确定性组件负责保障 — SVG 校验器检查每页输出、SVG → DrawingML 转换器导出原生可编辑 PPTX、模板引擎处理标准版式（cover/bullets/stats 这些不需要 LLM 生成）。

• deck_spec 替代链式传递 — 生成前先产出一份完整的视觉合约（色板、字体、版式分布、密度节奏），每页生成前重新读取这份文件，确保第 1 页和第 20 页风格一致。不再依赖"把前一页的 HTML 传给下一页"的链式传递。

• SVG 替代 HTML 做中间态 — Agent 直接输出 SVG，确定性代码转换为 DrawingML，PPTX 里每个元素都是原生可编辑对象。

这个方向保留了一个独有优势：大纲优先的工作流。用户已经把大纲做好了，Agent 不改写内容，只做视觉决策。加上模板引擎对标准版式的零 LLM 处理，比"每页都让模型生成"更经济。

但现在也要承认：新链路只是骨架跑通，还不够强。真正要补的不是再写更长 prompt，而是三层基础能力：

• 视觉合约要更硬：deck_spec 不能只是色板和字段骨架，还要约束每页的构图、信息预算、密度节奏和视觉角色。

• 模板库要更厚：cover / bullets / stats 不够，two-column、compare、timeline、matrix、process、quote 等常见页都应该确定性生成。

• 验收要更深：不能只检查 SVG 合法、颜色合规、文字可编辑，还要检查重叠、越界、文本密度、视觉层级和跨页一致性。

这也是我现在还不敢说“可以放心分享出来”的原因。方向比以前清楚了，但它还没有稳定到我愿意让别人少踩坑的程度。与其急着发布一个半成品，不如先把这些硬约束补上。

为什么会走弯路

回头看最大的弯路——在 pipeline 里加步骤而不是直接走 Harness——原因很明确：

我把"自建 LLM 编排"当成了默认选项，而不是一个需要被质疑的假设。

做技术的人容易有一个思维惯性：问题出在系统里，就在系统里加模块解决。Pipeline 不够好？加 distill 步骤。跨页不一致？加 plan 步骤。步骤之间信息丢失？加更多字段。

但真正的问题不是步骤不够多，而是不应该由代码来硬编排 LLM 的思考流程。Claude 在一个完整的 context 里自然就会做全局规划再逐页执行，不需要我用代码帮它拆成"先调一次 plan 再调 N 次 distill"。

第二个原因是研究不够深入。PPT Master 在学习评测文章里只是四个方案之一，我当时更多关注的是 prompt 层技巧（Bento Grid、封闭色板），没有认真拆它在可编辑导出和视觉合约上的架构思路。SVG → DrawingML 和 spec_lock 是更底层的差异，表面上看不出来。

如果更早认真研究这些成熟方案背后的工程取舍，可能会更早意识到中间态和编排方式都需要改。

还有一个更朴素的原因：我太想把它做成一个“完整产品流程”了。

做产品流程会自然倾向于把步骤固定下来，把每个环节都包装成模块。但 AI 生成类任务里，有些判断并不适合过早固化。内容密度、视觉节奏、哪些页该模板化、哪些页该单独生成，这些更像 Agent 在完整上下文里的判断，而不是几个孤立字段能完全承载的东西。

这不是说工程化不重要，恰恰相反，是工程化应该放在更确定的部分：模板、校验、转换、验收，而不是去硬拆模型的思考过程。

哪些判断在什么条件下成立

走了弯路不代表之前的判断全错了。更准确地说，是有些判断的适用条件变了。

"HTML+SVG 优于图片生成"——方向对，格式选择需要修正。选结构化表达是对的，但 HTML 不是最好的结构化表达，SVG 才是。

"Pipeline 拆步是工程化的做法"——对 0→1 快速起稿有效，对高质量 LLM 编排容易变成反模式。传统软件的 pipeline 有效是因为每步是确定性代码，输入输出精确可控。LLM 步骤的输入输出是概率性的，中间加解析/格式化层只会增加脆弱性。

"约束系统是核心竞争力"——仍然成立，但约束的执行层级需要提升。从 prompt 里写规则（模型可能不遵守）→ 代码层校验（svg_validator，不合格就打回）→ Agent 的 tool 自检（生成后自动调用校验）。约束的思路没变，执行越来越硬。

"先试跑再批量"——在 pipeline 模式下重要，在 Harness 模式下要升级成更硬的视觉合约。Pipeline 需要一个专门的 trial 步骤来冻结视觉方向；Agent 模式下，deck_spec 就是全局视觉合约，但它必须足够具体，不能只停留在几个描述性字段。

给同样在做 AI 工程的人

如果你也在做"AI 生成 → 人类接手修改"类的产品，这段时间我最大的教训是：

不要急着在 LLM 外面套编排框架。 先看 LLM 自己是怎么完成这个任务的，然后让你的系统模拟那个自然流程，而不是用代码重新定义流程。Agent 的 context window 和 tool calling 能力在快速进步，自建编排框架很可能是你最大的技术债。

先确认中间态，再确认编排方式。 中间态的选择（HTML vs SVG vs 图片）决定了最终产出的质量上限。我在中间态上的错误选择，比编排方式上的所有优化加起来影响都大。

约束系统是真正值得投入的护城河。 模型会越来越强，编排框架会被 Agent 平台取代，但"什么样的 PPT 算好"的判断——色板约束、密度节奏、图表结构规则——这些是领域知识，不会因为模型升级而过时。把精力放在沉淀这些约束上，而不是优化调用链路。

接下来

5 月那篇之后，我本来可以把当时能跑通的版本放出来。但现在看，demo 能证明思路，却还不够稳。

接下来先补三层硬约束——视觉合约、模板库、验收——等链路稳定到我自己愿意反复用，再分享出来。这次的标准很朴素：不是"能不能生成一份看起来不错的 PPT"，而是"我能不能连续几次用它做真实内容，并且生成后愿意继续在 PowerPoint 里接着改"。

如果新方向也有问题，我会继续修正。这个系列的价值不在于"我找到了最终答案"，而在于：把一个 AI 工程问题从粗到细、从错到对的过程完整记录下来。

模型负责生成，Agent 负责执行，约束系统负责收敛，认知迭代负责进步。