我如何用低代码平台复刻NotebookLM体验：从文档到可控PPT生成，全流程实战。

### 用低代码平台复刻NotebookLM核心功能，实现文档到PPT的智能转换，还能加入人工干预提升质量 先说一个核心判断：用低代码平台来做这件事，其实比纯代码更贴合实际开发场景。纯代码固然强大，但带来的工程复杂度和维护成本，说实话不低。这次我们换了个方向——尝试用国产开源的低代码平台去复刻NotebookLM最新的PPT生成功能。整个过程下来，体验感比预期好不少。 **核心技术栈如下：** * **低代码平台**：国产开源BISHENG（可视化工作流） * **LLM**：字节的Seed-1.6推理模型 + gpt-4o-mini普通模型 * **文生图**：字节最新的Seedream-4.5模型 * **外部工具**：自编写MCP Server 至于为什么最终选了这套组合，答案就在后面的实践过程中。本文源代码与工作流配置文件见文末。 #### PART 01：准备工作 相信很多小伙伴都玩过Google NotebookLM，这次要复刻的核心能力其实很明确： * **上传文档（Sources）形成临时知识库** * **基于文档做概要或事实性问答（Agentic RAG）** * **把文档内容自动转成PPT演示稿** 不过，既然是自己动手，那就顺带加点料：在生成PPT的过程中加入HITL（Human in the Loop，人类参与）环节，让最终内容更可控、更符合预期。 对应NotebookLM中的目标功能： 需要提前说明一点：本文主要演示的是“后台工作流”如何把这些能力串起来。如果想做成真正可用的产品，还需要补上前端UI，并通过API与工作流进行协同。 **启动低代码平台BISHENG** 本次使用的低代码平台是BISHENG，一个国产开源的、面向企业级LLM应用开发的低代码平台。它的最大特色就是拥有专门为企业级场景设计的工作流编排能力。后面你会看到，它在处理复杂管线时的表现，确实让人眼前一亮。 启动这个平台最省事的方式是Docker。具体步骤如下： 1. **确保你本机安装了Docker和GitHub CLI** 2. **依次执行以下命令，拉取并启动所有容器：** ```bash > git clone https://github.com/dataelement/bisheng.git > cd bisheng/docker > docker compose -f docker-compose.yml -p bisheng up -d ``` 启动完成后，在浏览器打开 `http://localhost:3001/`，你会看到登录界面： 注册一个账号（会自动成为管理员），然后登录。首次进入的页面是一个内置的、开箱即用的前端对话式UI应用。BISHENG的开源协议允许你自定义个性化的LOGO与Slogan： 点击左下方的个人头像，选择切换到后台管理——我们的主战场在后台： 进入后台后，可以先根据自己计划使用的模型，在“模型”菜单中先把**LLM / Embedding**配置好。后续的工作流会马上用到它们。 #### PART 02：文档上传、RAG管道、多轮对话 点击左侧菜单的**「构建」**，在弹出的抽屉式界面里选择**「自定义工作流」**，就能进入工作流画板，正式开始上手流程编排。我们要实现的工作流大致如下： **第一步：上传文档 → 自动解析 → 临时知识库** 第一个环节自然是让用户上传知识源。BISHENG的工作流支持在同一个“输入”节点中上传多份文档，并且会自动完成格式解析和切片，然后构建一个**临时向量知识库**。节点的配置非常直观： BISHENG的“输入”节点非常适合这个场景：支持多文件源上传，切片、嵌入、建库这些“累活脏活”，平台都帮你一并搞定。这个临时知识库将在后续节点中被引用。 **第二步：意图识别：识别用户想干什么** 知识源准备好之后，下一步就是让LLM来判断用户到底想做什么——是基于文档进行问答，还是生成一份结构化的笔记（例如PPT）。LLM完全可以胜任这种意图识别任务。只需要一个简单的提示词，就能输出我们期望的路由结果（使用“大模型”节点）： **第三步：针对不同意图，分支处理** 识别出意图后，就要“各做各的事”了。这一步可以借助“条件分支”节点来完成。 **✔ 事实性问题：走RAG管道** 常规的事实类提问（比如“文档中某个定义是什么？”）直接走RAG就行。BISHENG工作流里提供了现成的**“文档知识库问答”节点**，只需把前面自动生成的临时向量库接进来即可： **✔ 概要性问题：基于文件原始内容回答** 对于“给我总结一下全文内容”这类概括型提问，传统RAG并不是最优选择。在低层LLM框架开发中，可以借助堆叠树状摘要（Tree Summarization）、GraphRAG或者一些特殊的RAG范式（如RAPTOR）来实现。但随着LLM上下文窗口的不断扩展，对大部分文档而言，直接把全文供给模型反而更稳也更简单。直接用“大模型”节点，把文档内容输入进去即可： **第四步：多轮对话：超越简单的“问答”** 当上面的基本问答能力跑通后，再加上多轮对话其实非常轻松：只需要把回答节点的输出，再连回输入节点就行： **这一点是我采用BISHENG工作流的主要原因之一。** 一些低代码平台会把“用户输入”固定为整条工作流的触发入口，导致每一轮对话都要从头开始触发一次工作流。但BISHENG的做法是：“用户输入只是普通节点，而非一定是工作流入口。” 这意味着： * 工作流运行中可以随时“插入”用户的新输入 * 每次输出之后可以自然地衔接下一轮输入 * 整体更贴近真实的通用工作流场景：对话与节点任务可能交叉进行 当然，这种设计在某些场景下也会带来一点小麻烦（后面会说），但从构建工作流的体验来看，它更自然，也更符合开发者的直觉。 完成上面的配置，一个基本的文档总结与问答流就完成了。坦白说，这只是本文最简单的部分。 #### PART 03：LLM + 生图模型 + MCP = PPT生成 要实现的意图中，PPT生成功能无疑是最复杂的一类。我们的做法是：先生成大纲，再将大纲转化为图片式页面，最后合成为可下载的文件。基本流程如下： 这里仅对关键实现要点作解释（详细配置请参考本文附件）： **【从文档到PPT：采用“图片式页面”的策略】** 在实际实现中，我们参考了NotebookLM的思路，直接生成PPT页面图片，而不是构建可编辑的PPT元素树。这种方式的优势在于实现路径短、视觉表现更灵活，页面设计感也更容易体现出来。但同时也带来一个天然限制——生成的PPT是“纯图片”，没有可编辑文本。如果需要后期修改，可以借助工具（比如WPS）将PDF转回PPT，再对文字内容进行适当修复。当前文生图模型在文字绘制方面依旧存在局限，即便是Nano Banana Pro也无法做到绝对完美，因此这类“善后处理”仍是必要环节。 **【由LLM生成结构化PPT大纲】** 整个流程的基础是让LLM将原始知识转化为结构化的逐页大纲。大纲通常包括页面标题、要点、说明等内容。这一步的关键在于提示词的清晰度与约束性，它直接影响到后续图片生成的稳定性。 大纲确定后，才能进入页面设计阶段。 **【从PPT大纲到页面图片：不同模型的差异】** 针对不同的生图模型，需要采用不同的生成策略： * **Nano Banana Pro**：对文本内容的理解能力较强，不需要传统的“视觉设计提示词”。只要准确表达每一页的内容，它就会基于语义自动完成视觉设计，并生成自洽的图片。 * **其他模型（Seedream-4.5）**：经过反复测试，我们最终采用了字节最新的Seedream-4.5模型。这类模型更依赖明确的视觉提示词，例如布局、色彩、风格等。如果描述不够清晰，生成质量容易偏离预期，甚至出现理解错误。 下面两张图展示了两种模型直接理解文本内容后的生成能力差异： Nano Banana Pro生成 Seedream-4.5生成 很明显，Seedream-4.5不能采用这种出图模式。基于此，我们采用的策略是：让LLM根据每页内容自动生成针对性的视觉提示词，再将这些提示词交给生图模型。为了提升成功率，我们在提示词生成后又增加了一个“审核优化”节点，对提示词进行一次校正，使其表达更准确、结构更自洽。 **【工作流配置】** * **图片的循环生成** 为了更好地控制图片生成，我们采用了逐页生成的方式。BISHENG支持以更自然的方式设计循环工作流，这也是我们采用BISHENG的另一个主要原因： 这里为了控制循环，并在最后输出所有图片，有一些特别的处理技巧，具体可以参考我们的工作流详细配置。 * **图片模型的调用** 由于BISHENG尚未内置图片模型节点，需要通过两种方法之一来调用： 1. **使用“代码节点”**：编写Python请求逻辑，通过REST API调用图片模型 2. **通过MCP工具节点**：调用外部Server执行图片生成任务 本次实现采用了第一种方式，直接调用Seedream-4.5的API获得图片URL。 * **合成最终PPT（PDF）** 图片生成完成后，需要将它们合成为一个可下载的PDF文件。我们编写了一个简单的MCP工具来完成以下动作：下载多张图片 -> 合成PDF -> 上传至阿里云OSS -> 返回最终下载链接。在本机启动这个MCP Server，然后在BISHENG中添加这个自定义工具： 最后，在工作流中调用这个工具，并输出最终的PDF下载链接。 #### PART 04：HITL - 让图片生成更可控 图片模型的不稳定性是一个绕不开的问题。即便提示词经过反复调试，也很难保证所有页面都能“一次成型”。除了持续优化提示词、选择更稳定的模型之外，一个更实际的补救方式是加入**“边生成、边调整”**的机制：每生成一张页面图片，让用户决定是继续下一页，还是重新生成；如果选择重新生成，用户还可以先对提示词进行修改。 把上述流程调整如下。这里有几个关键实现要点： **【HITL（人类参与流程）的实现】** 无论使用低代码还是纯代码，HITL都是一个既重要又容易带来工程复杂度的环节。由于LLM的生成结果天然具有不确定性，人工介入往往是保证质量的最直接方法。然而，HITL的特点是流程必然会在中途暂停并等待用户反馈，而这一点恰恰是一些低代码平台难以处理的地方——它们通常把流程视为“一次触发、一次执行”，不擅长在运行过程中接受人类输入。 **这就是采用BISHENG工作流的第三个重要原因：** 工作流在运行中可随时插入用户交互，并将反馈结果自然地传递给后续节点。 具体来说，有两种方式：输入节点或输出节点。 * **输入节点**：前文提到过，输入节点可以出现在流程的任意位置。无论是通过表单还是对话输入，都可以在流程执行途中获得用户的反馈，并直接作为变量继续参与后续逻辑。 * **输出节点**：输出节点是展示给前端用户的消息，而BISHENG允许在输出消息中嵌入交互控件。用户在前端做出的选择或输入，会作为该节点的输出值继续流入流程。 在我们的场景中，输出节点被用来询问用户是否接受当前图片。如果用户选择“继续”，流程进入下一页；如果选择“重新生成”，流程则进入一个二次交互节点，允许用户修改提示词。 选择“重新生成”，将进入一个二次交互节点：在这个二次交互节点（输出节点）中，将上一轮的提示词作为默认内容展示出来。用户修改之后，该节点的输出会作为新的提示词被传回图片生成节点。 这部分涉及多个节点间参数的传递与分支判断，具体细节可以参考工作流配置文件。 通过这种方式，整个PPT生成过程在每一页都会暂停并等待用户确认。用户可以根据需要对提示词进行局部微调，从而显著提高生成成功率。 需要说明的是，这里只在图片环节演示了HITL的使用，但在其他步骤（例如大纲生成、结构调整）中也完全可以加入类似的人工审核机制。此外，这里使用的是低代码平台自带的前端交互界面。借助平台提供的API，你完全可以在自己的前端应用中实现更适配业务场景的交互——比如更友好的提示词编辑界面、可视化预览等流程，使“人类参与”成为整个系统的重要能力。 #### PART 05：最终效果测试 至此，基于BISHENG + Seedream + LLM + MCP的组合，我们已经完成了整个Demo工作流的搭建。为了便于调试，我们将流程中许多中间LLM的输出设置为可见，方便观察每一步的行为。完整效果让我们看视频： <iframe src="https://mp.weixin.qq.com/mp/readtemplate?t=pages/video_player_tmpl&action=mpvideo&auto=0&vid=wxv_4292914872477925381"></iframe> 整体上看：Seedream-4.5在生成带有大量精细文本的PPT（适合个人直接阅读）方面，能力距离nano-banana-pro还有一定差距；它更适合生成用于演示的简洁风格PPT。当然，这也取决于生成视觉提示词的LLM。 另外，在一次测试中的某个细节也体现了HITL的必要性：LLM为某一页生成的提示词触发了Seedream的敏感词规则，导致模型无法出图。如果没有HITL，流程会直接报错；而现在，流程会暂停并允许人工调整提示词，修改后即可顺利继续生成。 #### PART 06：总结：低代码平台的能力进化 本文尝试用低代码方式复刻NotebookLM的部分核心体验，包括文档解析、RAG、PPT生成以及人类参与（HITL）。整体上它只是一个原型，用于验证工作流层面的可行性，与真正的可用产品之间仍有距离。基于本文的Demo，你还可以进一步完善异常处理、优化生成逻辑、扩展更多应用场景（如思维导图、讲解视频等），并开发专属前端以获得更完整的交互体验。 在整个构建过程中，有几个体验感受值得总结。 **一、低代码平台的能力边界也在快速扩展** 过去低代码常被质疑缺乏灵活性，而本次体验中，BISHENG的工作流表现出了较高的可塑性。特别是它的工作流没有采用“用户输入 = 流程入口”的传统模式，而是允许在流程运行中随时插入人工交互。这是我们采用BISHENG来实现的最重要的原因之一，对企业应用来说也非常重要。例如这些场景： * 多轮收集信息 * 审批确认与HITL * 合规要求下的敏感操作许可 通过这些能力，工作流不再只是自动化的执行链路，而是真正能承载复杂业务的“交互式流程”。 **二、扩展性显著增强：代码节点与MCP的加持** 可插拔的代码模块与MCP让低代码平台的灵活性与扩展性有了较大的飞跃。早期低代码平台对非标准化需求支持不足的问题得到了明显改善。这使得： * 任意API调用 * 与已有系统（数据库、云存储、业务接口等）集成 * 复杂逻辑与状态控制 都能自然地融入可视化工作流之中。某种意义上讲，MCP抹平了不同低代码平台在工具/插件上的差异。就像BISHENG这个平台，尽管官方的标准节点数量不算多，但扩展能力却也能覆盖绝大多数企业场景。这也让开发者在很多时候有了更多更务实的选择。 **三、低代码平台在可观察性与调试体验上有优势** 低代码的另一个优势，是提供了类似“Agent调试IDE”的体验。在构建基于LLM的应用时，多步骤推理、工具调用链路和对话式状态往往难以在纯代码环境中逐层观察（依赖print或专门的工程平台）。而在工作流界面中，你可以轻松查看： * 每个节点的输入输出 * 工具调用的参数与错误 * 决策节点的具体分支 * 前端交互的效果模拟 这使得调试变得更直观，开发速度也显著提升。 **四、需要进一步完善的地方** 最后说说本次体验中BISHENG这个平台还可以打磨的点： * **不支持自定义全局变量**：某些状态与逻辑控制不得不借助代码节点完成 * **暂不支持工作流互调**：对大型流程的模块化复用有所限制 * **默认工具生态偏少**：虽然可以通过MCP扩展，但仍需投入一定封装成本 未支持工作流互调可能和其特点有关——支持任意点的暂停与人工交互，而非简单的“可嵌套的工作流黑盒”（这也让BISHENG的工作流在前端集成时略显复杂）。某种意义上，这也是一种“Tradeoff”。 不过瑕不掩瑜，在官方的介绍与Demo中，可以看到平台也提供了许多其他面向企业级的能力：文档解析、模型管理、数据集与微调管理、安全体系（SSO/LDAP）、监控与运维等。这使其不仅是一个“工作流工具”，而是覆盖从数据到模型到应用的完整链路。作为一个在开源协议上基本没有限制的低代码平台，我们也期待它越来越完善。