一年积累了 200 多份设计文档，最初想法是直接拿这些文档去讲。结果发现这些东西不适合讲。设计文档是给人写的，演示文稿是给人听的，形式完全不同。
解决这个问题的思路不是"写个通用 PPT 编辑器"，而是"从结构化文档一键生成演示"。本质差异在这里——编辑器要处理用户的任意编辑行为，演示工具只要转换已有的结构。
为什么选单向转换而不是编辑器
设计文档有稳定的模板：背景、方案、架构、取舍、参考。这个顺序不是随意的，恰好就是讲一个设计时的叙述顺序。
用户不需要"先生成再改"，需要的是"文档秒变幻灯片"。一旦你改，就回到编辑器的坑里去了——要支持拖拽、删除、排版，工作量爆炸，而且多数用户不会调，生成好的东西就是定版。
这个判断来自实际数据。我的工具做两个决策：
- 产物是自包含 HTML，不是 Office 文件（
.pptx需要可编辑格式，门槛高；HTML 在浏览器里就能放映，自包含意味着内联了所有 CSS、JS、图片）。 - 内容由 LLM 生成，不开放编辑面板（用一个"预览挑选"的两阶段流程，让用户在 3 种风格的封面里选一个，然后生成整份）。
这两个约束听起来很严格，实际上契合了需求的本质：文档的目的是记录决策，演示的目的是讲述决策。不需要演示过程中再改决策，改了就回到文档去改。
什么样的结构能转、什么样的不能
设计文档要是能一键转成演示，必须满足几个条件。
架构图可以直接映射。我的演示工具支持 AI 生图，也支持用户指定图片 URL。当文档里写了架构设计时，LLM 看到这个描述会生成对应的图，然后内联到演示文稿里。舞台是固定的 1920×1080，所有图片容器有最小尺寸约束（GSAP 时间轴动画要能在任意时间点求值，不能靠动态布局）。
关键数据用表格记录最不容易犯错。表格这种结构容易转化——待补：具体表格如何转成演示页的实现规则。如果文档里的数据以段落文字形式写，转成演示时就卡住了，LLM 要从自然语言反推结构。
取舍（trade-off）部分：待补：设计文档中的取舍说明如何映射成演示内容的规则
一个更深的观察：文档转不出来好演示，通常不是演示工具的问题，是文档本身没讲清楚。
我见过一类项目文档，有 20 多份模板文件，但只要换个配色其他全一样。这说明什么？说明那些"模板"实际上没有结构差异，只有视觉差异。结构不清，自然转不出演示。或者反过来说，如果要证明自己的文档结构是清晰的，试试能不能一键转成演示——转不出来就是信号，说明需要先梳理文档本身。
工具的硬约束
演示不同于其他产物，有独特的硬约束。我的工具选择了 1920×1080 的固定舞台，所有动画用 GSAP 时间轴。这些看起来像限制，实际上是为了保证可靠性。
固定舞台尺寸意味着设计者写风格预设时要算好留白和排版，不能寄希望于"容器自适应就行了"。GSAP 时间轴的特点是能在任意时间点求值（渲染管线会 seek 到任意帧截图），不能用 CSS animation 这种依赖真实时间流逝的东西。这限制了动效，但换来的是确定性——动效一定会在预期时间点发生，不会因为网络卡而错位。
生成流程分两个阶段，有个细节很实用。第一阶段只生成 3 个风格的封面单页，第二阶段才生成整份演示文稿。这个设计看似多一步，实际上优雅地解决了两个问题。一是给用户选择风格的机会（不是非此即彼的"生成或不生成"）；二是掩盖异步生图的等待时间（生图 1-2 分钟，正好被用户在选择封面时吸收了）。
从文档能否转演示看结构清晰度
最后回到起点。为什么要做这个工具？
表面原因是 200 多份文档用演讲方式讲会更有力。深层原因是这个过程本身就是对文档质量的检验。
一份设计文档如果结构清晰——背景交代得清，方案对比得充分，架构图画得明确，取舍理由说得透彻——那转成演示就是平移内容，不费劲。转不出来、或者转出来很别扭，就是信号，说明某个环节讲得不够好。
这个反馈机制比任何 review 注释都直白。"这个表述为什么转不成幻灯片？"往往能逼出真实的问题——"哦，因为我其实还没想清楚这个方案为什么比另一个好"。
■