最近Nano Banana Pro（NBP）非常火。我们看到了各种应用：给漫画上色、生成海报、甚至直接生成以假乱真的演示文稿PPT。看起来像一张PPT，但其实只是一张图像。 但另一方面，在真正的演讲工作流课里，大家还都是把它当一个素材生成器来用。比如让它生成一张背景图，插入标题页；或者生成几个图标，放到幻灯片里，然后像以前一样手动排版。 我一开始也是这么用的。但在强迫自己试了一下用NBP生成了整套PPT几十页幻灯片（而不是生成幻灯片的素材然后在PPT里排版）之后，突然理解了这种做PPT的新方法有一个巨大的好处。但同时它也有很多非常明显的弱点和挑战。这种巨大的割裂让我花了很多时间去做了一个完整的工作流出来，实现了实用级别的用NBP生成PPT的工作流（Generative Kernel），让它又可控、又方便、质量又高，并且开源了相关的工具和工作流。 这篇文章就想首先分享一下，我为什么觉得使用NBP一下生成整张幻灯片是一个非常重要的革新。然后介绍但如果真的这么做会遇到哪些挑战，最后介绍解决方法。 ## 范式转移：从拼凑到渲染 我因为对演讲一直很感兴趣，所以一直在关注我们普通人做的PPT和高手们比如乔布斯做的PPT/Keynote有什么不同。 大道理且不说，一个很明显的第一印象是，高手们的PPT有很强的设计感，它的每一个视觉元素都有自己的目的，看上去也非常和谐统一。但反观我们普通人的PPT，做得好的还知道套个模板，大多数人无非就是方框、箭头加项目列表。千篇一律之余，也充斥着视觉上的割裂感，整个幻灯片看起来是独立的元素硬拼凑在一起的。 这个区别背后的原因除了时间投入不同之外，更重要的是流程和方法的不同。我们做PPT的过程更像是搭积木，不论是PowerPoint还是Keynote，我们会找一些图标、打一段字、画几个形状，然后把它们像积木一样自底向上地堆在一起。因此这些来自不同地方的素材很难在视觉风格上达成统一。但是设计师们设计PPT更多的是用自顶向下的方法，逐渐细化。他们会首先考虑整体的视觉语言，然后思考为了达成这种设计语言和目标，需要用哪些元素，最后把这些元素用统一的风格设计出来。对他们来说，一个箭头不是从形状库里随便拉出来的，而是在构图、光影、层次之内要起作用的一部分。从一开始，视觉效果和统一性就是很重要的目标。 NBP生成的幻灯片，给我一个明显的感觉就是这种设计感。它一看就像是花了大价钱设计出来的，风格统一专业。里面的很多视觉效果我们在ppt里面不是调不出来，而是需要花大量的时间在Photoshop/Illustrator/Powerpoint等等专业软件里面作图，可能几个小时才能做一张。同时就算我们有这些技术能力和时间，也未必有这个审美。举个例子，如果我们要把这段话做成一个PPT，普通人风格可能会有两个框框，表示以前的老方法和现在的新方法，中间用个箭头连起来。下面这张图是NBP生成的，框架是一样的，但视觉效果完全是天壤之别。 ![NBP generated slide](https://yage.ai/images/nano-banana-pro-slide.jpg) 这是为什么我这么兴奋的原因。用NBP生成整个PPT（而不是单纯地生成里面的图标）是个根本性的变化：它直接把我们从拼凑素材拉到了整体渲染的境界。这给了我们普通人一个以前完全无法企及的武器——设计感。我们终于可以用极低的成本，获得以往只有顶级设计团队花费数周才能打磨出的发布会级别的质感。但这里的代价也很明显：如果我想要把字体改小一号，应该怎么改？如果想要把机枪图标左移5cm，除了重新渲染还有没有其他方法？更重要的是，我在试着用它去生成一个严肃的商业演讲PPT的时候，立刻就遇到了几个令人绝望的障碍。 ## 现实的冷水：此路不通 如果你直接照着上面的想法，让 NBP 帮我生一整套 PPT，很快就能体会到那种此路不通的障碍：单张图都很惊艳，类似上面的贴的图，但放到一起就完全不可用。具体地说，有下面几种不同的问题： 第一是视觉风格杂糅混乱。上一页是白底极简风，下一页突然变成黑底赛博风，再下一页多了很多写实细节。单独看每一张都很厉害，但连起来完全不像是一场演讲，更像是从不同演讲里面随手摘抄了几张大佬的PPT拼在一起的缝合怪。别说什么品牌感、主题感，这种PPT给人的印象甚至还不如自己老老实实做。 第二是内容不可靠。二维码是最典型的例子。你给它一个大致的描述，它会画出一个看上去很像二维码的东西，但扫不出来。就算你把 URL 文本给它也一样。Logo 也是同样的问题：如果你只用文字描述比如Cursor的Logo，它经常会发挥想象力，给你画出一个想象的 Logo比如一个鼠标指针。这个也要花很多精力去纠正，甚至如果有暗坑藏在里面，实际演讲的时候才发现就糗大了。 第三是成本问题。因为是整张图一起渲染，每次修改都意味着一次完整的重新生成。无论是从 API 费用的角度（$0.24一张图），还是从等待时间的角度，都很昂贵。尤其是在内容还经常变动的早期阶段，很容易陷入改一行字要重画一整张图的尴尬状态。 第四种是我原来以为是问题、后来发现不太是问题的那种。比如像素级的微调。一开始我也很在意这些细节，觉得不能精确控制字号、间距，会非常难受。但实际做完几十页之后，一个很直观的感受是：NBP 实在是太强了，它出的PPT完全不用纠结这些，我真正想要调细节的次数非常少。大多数时候，输出就已经远好于我自己排版的水平了。这里真正需要改的，可能是我们的预期和习惯：像一个老板一样抓内容和大体视觉框架，而把具体排版之类的任务完全交给它。 最后一类，是单靠图片几乎解决不了的问题。幻灯片不只是视觉背景，它还需要可选中的文字、演讲备注等等。这些都不是静态位图能表达的。单纯用 NBP 生成图片，虽然能把看起来像一张 PPT这件事做好，但离真正能拿去讲的演示文稿，中间还有一条很长的路。 所以，一开始我对这套思路的直观印象是：它的优势和劣势都一样突出。但因为这种设计感实在是太降维打击了，这激励着我花了很多精力去分析为什么它有这些问题，以及我们能不能设计一套工作流或者工作机制去解决这些问题。 ## 破局：构建不确定性的容器 面对这些挑战，我们首先要思考，这到底是模型能力问题，还是我们给他的信息不够？一种思考的方法就是，如果我的老板把这个任务交给了我，我能不能完成？我的答案是否。因为AI是没有记忆的。它所有信息的来源都是这次的prompt。换言之，第一张幻灯片和第二张幻灯片是完全独立的，因此出来的视觉风格不同是非常正常的。 因此，就算下一代NBP更聪明10倍，它也没办法解决我们的问题。相反，我们需要更好的工程架构，通过Context Engineering来约束AI的行为。换言之，我们需要把 NBP 这种生成式 AI 看作一个充满创造力但极不稳定的概率工具，然后通过软件工程的手段，构建一个确定性的容器来约束它。这也是我们提出[Generative Kernel](https://yage.ai/ai-software-engineering.html)的一大原因：把不可控的艺术渲染，封装在可控的代码逻辑里。 这里我首先解决的是功能缺失和交互问题。既然静态图片做不了演讲者备注，我们就不应该强行让它做。在这个工作流里，我[继续沿用](https://github.com/grapeot/cursor_slides)了 reveal.js 这种基于 Web 的演示框架作为骨架。它负责承载所有的确定逻辑：幻灯片的结构、可点击的链接、演讲者备注等等。NBP 生成的图像，不再是幻灯片本身，而是退后一步，成为了底层的视觉材质（技术上就是每个网页的背景图像）。这样，我们把功能和审美这两个关注点分离了：代码负责确定的交互，AI 负责灵活的艺术。而且这样生成的PDF，我不知道为什么，在浏览器和Mac的Preview里面还可以正常选中文字。可能是系统后台自动做了OCR。 其次是那个最让人头疼的视觉一致性问题。和我们在[这篇文章](https://yage.ai/gpt-image.html)中介绍的技巧一样，语言在描述视觉风格时是非常苍白无力的。要约束 AI 的视觉输出，最高效的手段不是更长的提示词，而是直接给一个图片当例子。因此我们采用了一种以图生图的策略：先花一些精力做一张基础图，这个可以用AI写网页渲染，可以NBP生成，甚至手绘一张都可以，然后把它作为后续生成的素材喂给 AI。 这种方式对AI的约束比语言强很多。比如在给我们的[AI能力阶梯图](https://www.superlinear.academy/c/share-your-insights/competency)做ppt时，我需要在不同的幻灯片的右上角画出来这个阶梯，高亮不同的层次（讲L3的时候高亮L3）。这里如果单纯地说“画五个台阶，风格要统一”是完全没用的，哪怕详细描述这个风格是什么，AI也有很大的自由发挥的空间。我后来直接用NBP生成了一张图像，然后作为输入给这几张幻灯片的生成素材。通过这种方式，我们在保持 AI 渲染能力的同时，强行锁定了视觉的一致性。 对于 Logo 和二维码这种绝对不能出错的元素，逻辑也是一样的。不要让 AI 去画一个 Logo，而是把正确的 Logo 图片作为图像资产注入进去。这时候，AI 的任务从无中生有的创作变成了基于素材的合成。它会自动分析环境光，给你的 Logo 加上合理的阴影和质感，把它完美地融合进背景里，但绝不会篡改 Logo 的形状。这种 Context Curation 的技巧，彻底解决了幻觉问题。 最后是成本控制。既然全图渲染很贵且慢，解决思路就是用软件工程的技巧：延迟渲染（Delayed Rendering）。在我们的工作流中，绝大部分时间我们是在跟纯文本打交道。我们在 Markdown 里用AI写好所有的内容、逻辑架构，我们审阅通过。直到所有内容都敲定拍板之后，再启动 NBP 进行批量的低分辨率视觉渲染。等满意以后再进行高分辨率扩图。这不仅把试错成本降到了最低，也让我们在创作时能更专注于内容本身，而不是被还没生成的图片打断思路。 通过这套组合拳——用代码做骨架，用资产做约束，用流程控成本——我们实际上构建了一个可以复用的生成内核。它让那个疯狂的想法，终于变成了一个可落地的工程方案。比如这篇文章的PPT可以在[这里](https://yage.ai/nbp_slides/)浏览。注意按s键可以呼出演讲者备注和控制面板。 ## 结论：交付的是生成能力 回顾整个过程，我们其实已经远远超出了做一个 PPT的范畴。 在[之前的文章](https://yage.ai/ai-software-engineering.html)里我们提到过，在 AI 原生软件工程的时代，我们交付的不再是一个静态的成品，而是一个能够持续产出成品的内核（Generative Kernel）。这个NBP做PPT的项目，就是一个标准的Generative Kernel。 这个Kernel已经在github上[开源](https://github.com/grapeot/nbp_slides)了。注意这个开源指的不仅仅是最后生成的那些 HTML 文件和漂亮的玻璃质感图片。那些只是这次运行的结果。我们真正交付的是一套可复用的生成能力。 一个完整的 Generative Kernel 包含三个核心部分，缺一不可： 1. 确定性的骨架：这是 Repo 里的代码部分。它规定了演示文稿在物理层面上长什么样：哪些区域是可点击的，演讲者备注在哪里显示，幻灯片如何切换。这一层的目标只有一个：确定性控制。我们要尽量用代码锁死交互逻辑，不给 AI 留任何犯错的空间。 2. 自动化的管线：这是 Repo 里的 `tools/` 目录。我们编写了 `generate_slides.py` 和 `gemini_generate_image.py` 等命令行工具。它们负责把图片、Markdown 内容和 HTML 结构串联成一个稳定的流水线。比如，我们在 Markdown 里标记 `Asset: imgs/qr_code.png`，脚本就会自动处理渲染、挂载和路径映射。这保证了流程是可重现的，而不是每次都在 Chat 界面里碰运气。 3. 写给 AI 的说明书 (SOP)：这是最关键、也是最容易被忽视的部分——`AI-instructions.md`。它本质上是一份提示词。我们把Glass Garden的视觉隐喻、Visual Anchoring 的操作流程、以及先改 Markdown 再渲染的原则，全部固化在了这份文档里。 这就带来了一个观念上的转换：我们不再假设人类是主力，AI 偶尔帮忙，而是假设AI 是主要的执行者，人类负责设计规则和表达意图。这份文档就是 AI 的岗前培训手册，让它在接手任务的第一秒，就达到了 L5 级别的工程师水平。 如果把这件事放回更大的背景下看，它展示了 AI 时代软件交付物的变化。在传统模式下，我们交付一个.pptx文件，用户拿到的是一条鱼。但在 Generative Kernel 的模式下，只要这三个模块（骨架、管线、说明书）在手，具体的内容、主题、风格都可以随意替换。 * 今天是讲Nano Banana Pro，用的是玻璃花园风格； * 明天要讲季度 OKR，可以在prompt里把视觉隐喻改成极简主义混凝土，把 Logo 资产换成部门图标； * 后天要生成一套 workshop 讲义，只需要改改 Markdown 大纲。 用户不需要每次都从零设计工作流，也不需要每次都重新去踩一遍二维码扫不出来，风格不稳定的坑。因为解决这些问题的智慧，已经被封装在这个 Kernel 里了。 对我来说，这个实验证明了我们可以完全用 NBP生成PPT。这固然让人欣喜，但背后对Generative Kernel这个思路和工作流的验证更让人兴奋。因为哪怕是听上去这么疯狂的想法——完全放弃排版软件，用一堆静态图片来代替 PPT——只要我们愿意从工程的角度去拆解它，把不确定性（艺术渲染）和确定性（交互逻辑）剥离开，再用一套 SOP 把它们粘合起来，我们就能构建出一套可靠的生产系统。 如果你也在用大模型做内容、做工具，不妨从这个角度审视一下你的工作流：你现在交付的，是一次性的结果，还是一套可以被 AI 和人类重复使用的生成内核？前者会让你每次都从头开始，而后者，才是属于你的、可以随着时间不断复利的资产。