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

发布日期：2025-12-16 09:01:30 浏览次数： 2685

作者：AI大模型应用实践

微信搜一搜，关注“AI大模型应用实践”

在之前的文章中，我们尝试用纯代码复刻 Google 爆款应用 NotebookLM 中较复杂的视频概览功能（《解密谷歌 NotebookLM 技术幕后【下】：如何用 AI 制作“带讲解的 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（Github 搜索BISHENG）。一个国产开源的、面向企业级 LLM 应用开发的低代码平台。其最大特点是独有的面向企业级场景的Workflow编排能力，后面我们会看到它如何在工作流的“复杂管线”里“大展拳脚”。

启动平台最省事的方式是 Docker。步骤如下：

确保本机有 Docker 和 GitHub CLI
依次执行以下命令，拉取并启动所有容器：

> 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的“输入”节点非常适合这里的场景：支持多文件源上传，切片、嵌入、建库这些“累活脏活”，让平台帮你搞定。临时知识库将在后续节点中引用。

② 意图识别：识别用户想干什么

在知识源准备好后，为了与知识对话或者生成指定形态的笔记（PPT），需借助LLM识别意图并路由到不同分支；

当知识库准备就绪，下一步便是让 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 Bananna Pro

对文本内容的理解能力较强，无需传统的“视觉设计提示词”。只要准确表达每一页的内容，它就会基于语义自动完成视觉设计，并生成自洽的图片。

其他模型（seedream-4.5）

经过反复测试，我们采用字节最新的Seedream-4.5模型。

这类模型更依赖明确的视觉提示词，例如布局、色彩、风格等，如果描述不够清晰，生成质量容易偏离预期，甚至出现理解错误。

下面两张图展示了两种模型直接理解文本内容后的生成能力差异：

Nano Banana Pro生成

Seedream-4.5生成

很显然，对于Seedream-4.5不能采用这种出图模式。

基于此，我们采用以下策略：

让 LLM 根据每页内容自动生成针对性的视觉提示词，再将这些提示词交给生图模型。为提升成功率，我们在提示词生成后再增加了一个“审核优化”节点，对提示词进行一次校正，使其表达更准确、结构更自洽。

【工作流配置】

图片的循环生成

为了更好的控制图片生成，我们采用逐页生成的方式。BISHENG支持以更自然的方式设计循环工作流，这也是我们采用BISHENG的另一个主要原因：

这里为了控制循环，并在最后输出所有图片，有一些特别的处理技巧，具体请参考我们的工作流详细配置。

图片模型的调用

由于BISHENG 尚未内置图片模型节点，需要通过两种方法之一来调实现：

使用“代码节点”：编写 Python 请求逻辑，通过REST API调用图片模型
通过 MCP 工具节点，调用外部 Server 执行图片生成任务

本次实现采用第一种方式，直接调用 Seedream-4.5 的 API 获得图片 URL。

合成最终 PPT（PDF）

图片生成完成后，需要将它们合成为一个可下载的 PDF 文件。编写一个简单的 MCP 工具，用来完成如下动作：下载多张图片 -> 合成 PDF -> 上传至阿里云 OSS -> 返回最终下载链接。

在本机启动这个MCP Server，然后在BISHENG中添加这个自定义工具：

最后，在工作流中调用这个工具，并输出最终的PDF下载链接：

PART 04

PART03: HITL- 让图片生成更可控

图片模型的不稳定性是绕不过去的问题。即便提示词经过反复调试，也很难保证所有页面都能“一次成型”。除了继续优化提示词、选择更稳定的模型之外，一个更为实际的补救方式是加入 “边生成、边调整” 的机制：

每生成一张页面图片，让用户决定是继续下一页，还是重新生成；若选择重新生成，用户还可以先对提示词进行修改。

把上述的流程调整如下：

这里的关键实现要点有：

【HITL（人类参与流程）的实现】

无论使用低代码还是纯代码，HITL（Human-in-the-Loop）都是一个既重要又容易带来工程复杂度的环节。由于LLM的生成结果天然具有不确定性，人工介入往往是保证质量的最直接方法。然而，HITL 的特点是流程必然会在中途暂停并等待用户反馈，而这恰恰是一些低代码平台难以处理的地方——它们通常把流程视为“一次触发、一次执行”，不擅长在运行过程中接受人类输入。

所以这是采用BISHENG工作流的第三个重要原因：

工作流在运行中可随时插入用户交互，并将反馈结果自然地传递给后续节点

具体来说有两种方式：输入节点或者输出节点。

输入节点

前文提到过，输入节点可以出现在流程的任意位置。

无论是通过表单还是对话输入，都可以在流程执行途中获得用户的反馈，并直接作为变量继续参与后续逻辑。

输出节点

输出节点是展示给前端用户的消息，而 BISHENG 允许在输出消息中嵌入交互控件。用户在前端做出的选择或输入，会作为该节点的输出值继续流入流程。

在我们的场景中，输出节点被用来询问用户是否接受当前图片。如果用户选择“继续”，流程进入下一页；如果选择“重新生成”，流程再进入一个二次交互节点，允许用户修改提示词：

选择“重新生成”，将进入一个二次交互节点：

在这个二次交互节点（输出节点）中，将上一轮的提示词作为默认内容展示出来。用户修改之后，该节点的输出会作为新的提示词被传回图片生成节点。

这部分涉及多个节点间参数的传递与分支判断，细节参考工作流配置文件

通过这种方式，整个 PPT 生成过程在每一页都会暂停并等待用户确认，用户可根据需要对提示词进行局部微调，从而显著提高生成成功率：

虽然这里只在图片环节演示了 HITL 的使用，但在其他步骤（例如大纲生成、结构调整）中也完全可以加入类似的人工审核机制。

此外，这里使用的是低代码平台自带的前端交互界面。借助平台提供的 API，你可以在自己的前端应用中实现更适配业务场景的交互 — 更友好的提示词编辑界面、可视化预览等流程，使“人类参与”成为整个系统的重要能力。

PART 05

最终效果测试

至此，基于 BISHENG + Seedream + LLM + MCP 的组合，我们已经完成了整个 Demo 工作流的搭建。

为了便于调试，将流程中许多中间LLM输出设置为可见，便于观察每一步的行为。完整效果让我们看视频：

整体上看：

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）、监控与运维等。这使其不仅是一个“工作流工具”，而是覆盖从数据到模型到应用的完整链路，作为一个在开源协议上基本没有限制的低代码平台，我们也期待它越来越完善。

53AI，企业落地大模型首选服务商

产品：场景落地咨询+大模型应用平台+行业解决方案

承诺：免费POC验证，效果达标后再合作。零风险落地应用大模型，已交付160+中大型企业