AI 做 PPT 最容易翻车的地方，往往不是它不会排版。第一页像海报，第二页像报告，第三页突然塞进一张流程图，单看每页都不算丑，可人一旦站到屏幕前，就会发现话接不上。

更麻烦的是，模板库很擅长把一个概念铺开。一个本来三分钟能讲清楚的点，被扩成十几页漂亮页面；标题、配图、动效都齐了，真正的讲述路线反而被稀释。演讲者翻到下一页时，不知道观众到底应该多懂一点什么。

这类问题很难靠换模板解决。换一套视觉风格，页面可能更精致，但观众状态没有往前走，现场还是会卡。讲 PPT 不是把资料摊开，而是让听的人从一个理解状态走到另一个理解状态。

Humanize PPT 切进去的位置就在这里：它不抢下游渲染器的活，不急着把页面画出来，而是先问这套 deck 能不能被讲完。它真正管的是每一页要推动什么理解、该不该上真图或视频、渲染完以后有没有页面只是“看着完成”。

这件事对 AI PPT 很关键。因为模型最容易给出的是信息顺序，而不是演讲顺序；最容易补的是页面内容，而不是观众从 A 到 B 的那条线。Humanize PPT 把这条线先拎出来，再把视觉工作交给真正擅长渲染的工具。

它先把 PPT 从信息堆里拉回演讲现场

仓库里反复出现的 AST，指的是 Audience-State-Transfer，也就是观众状态转移。这个词听起来有点学术，但落到 PPT 上很朴素：一页翻过去，观众应该从什么状态进入，又带着什么新理解离开。

所以 Humanize PPT 的第一步不是替你挑模板，而是整理 audience、goal、tension、success criteria，再把材料拆成 ast_outline 和 slide_plan。slide_plan 不是普通目录，它给每页写清 role、message、speaker_intent 和 media 决策。换句话说，页面还没开始画，讲述责任已经先落到了每一页上。

这比“帮我做一套 PPT”多了一层刹车。它会先产出 deck_brief.md、ast_outline.md、slide_plan.json、speaker_intent.md、asset_manifest.md、style_brief.md 这类工作底稿。文件名本身不重要，重要的是它们把一个模糊任务拆成了可交接的东西：谁在听、为什么听、每页要让人发生什么变化、哪一页需要图片、哪一页需要视频。

它把素材需求写成槽位，而不是让图片随缘出现

很多 AI PPT 的图片像临时贴上去的装饰。标题旁边空了，就来一张概念图；内容页显得干，就加个图标。Humanize PPT 的处理方式更克制：每页 media 里分 image、diagram、video，决定 needed、kind、purpose、asset_path 和 prompt_hint。

这个设计很实用。配图可以交给 baoyu-image-gen，视频可以交给 Remotion，图表可以走确定性 SVG；下游看到的不是一句“加点视觉效果”，而是这一页为什么需要素材、素材应该写到哪个路径、它服务哪一个讲述动作。

这不是把流程变复杂，而是在减少返工。真正复杂的是渲染完才发现：封面很好看，但内容页没有证据；某页放了视频，却和演讲节奏无关；图表占了半屏，却没有推动观众理解。Humanize PPT 把这些决定提前写进计划，后面的工具才不至于自由发挥过头。

好看的页面，仍然让下游原生去画

这个仓库最容易被误读成又一个 PPT 渲染器。实际相反，它反复强调自己不打开下游模板，不往渲染后的 HTML 或 PPTX 里塞东西，也不后处理成品。它只写 production prompt 和交接文件，然后让 guizang-ppt-skill、frontend-slides、beautiful-html-templates 或 PPT Master 走自己的原生路线。

这件事听起来像克制，其实很聪明。PPT Master 负责原生可编辑 PPTX、notes、转场和 DrawingML；guizang 负责中文 HTML deck 的视觉；英文路线交给 frontend-slides 或 beautiful-html-templates。Humanize PPT 只保留自己最该管的那部分：讲述意图、页面任务、素材槽位和体检返修。

体检不是看美不美，而是看这页能不能讲

Humanize PPT 的演讲体检很有意思。它不把美观当第一指标，而是拿渲染结果逐页对照大纲，找那些只能看、不能讲的页面。比如页面只有几个字，没有把意思说完；或者这页承诺要完成一个观众状态转移，最后却没有让听众多得到任何东西。

它的检查对象也比较具体。HTML 路线会看占位符残留、动画降级、WebGL 画布缺失、布局数量不匹配、英文横向溢出、低对比、图片 alt 缺失；PPTX 路线会看包完整性、页数、占位符、空页、是否被拍平成图片、speaker notes 是否缺失、转场和关系是否断掉。扫出来的问题会写成 qa_report 和 fix_prompt，让下游按原路线返修。

这也解释了它为什么不直接改成品。页面出问题时，最稳的方式不是在成品 HTML 里补一刀，而是回到下游的源头重渲。否则今天修掉一个遮挡，明天换主题又坏。Humanize PPT 把错误说清楚，把修复指令送回去，保持分工干净。

真正的价值在那条能上台的线

如果只想要一页漂亮模板，Humanize PPT 反而不是最短路径。它的价值出现在另一种场景：材料已经有了，AI 也能生成页面，但你担心这套 deck 漂亮归漂亮，讲到第七页就散了。

它会让 Agent 先停一下，先把观众、状态、转移、每页意图和素材任务写清楚，再交给真正的渲染工具。等页面出来，再用演讲体检把“只能看不能讲”的地方揪出来。这条路线不追求一步到位的神奇感，却更接近真实交付：能讲、能改、能交接，也能知道哪里该返修。

所以看 Humanize PPT，不必把它当成又一个万能 PPT 生成器。它更像站在模板库前面的导演：先确认这场演讲要把人带到哪里，再让灯光、画面、PPTX 和视频各自做好自己的那一段。对于 AI 做 PPT，这个顺序比多一个模板更重要。