AI辅助PPT与架构图：用Slidev、Mermaid和Diagrams实现可维护成果

先说个我在实际工作中的体会以前一提到“用 AI 做 PPT 和画架构图”大家的第一反应往往是让大模型直接吐一个.pptx文件或者自动生成一张高大上的架构图。我试过几种方案结果大同小异——排版乱、结构呆板、改起来极其痛苦尤其是架构图AI 生成的图只能看个大概想改细节还不如自己画。后来换了条路让 AI 生成结构化文本再用开源工具渲染成产线级成果。这思路才是真正能落地的。今天分享的这 3 个开源项目是我近期在工作流里反复用过的组合Slidev做 AI 辅助 PPTMermaid做 AI 辅助架构图DiagramsPython 那个做云原生架构图。它们不是同一类东西但组合在一起基本覆盖了我日常“讲方案、画系统、出文档”的大部分场景而且全是开源、可自部署、可脚本化的。下面我把每个项目的用法、关键参数、踩坑经验和配套的 AI 提示词都拆开讲清楚。1. 选这 3 个项目而不是其他同类工具的真正原因在做选择之前先说你最常遇到的一个需求手里只有一句话比如“给我做一个关于微服务架构介绍的 PPT顺便画一张架构图”。如果你把这句直接扔给大模型让它输出 PPT常见结果是要么给你一个需要在线打开链接的网页版文件要么给你一个极其难看的模板化幻灯片离可用差得远。原因很简单PPT 的排版是强结构化的大模型对“精确到每一页的位置、字号、图片布局”这件事并不擅长它更像是一个内容策划而不是排版工程师。Slidev的思路是把你所有的 PPT 内容写成 Markdown用代码控制排版逻辑。这样 AI 只需要生成结构清晰、内容准确的 Markdown 文本而渲染交给工具本身。AI 擅长的文字组织在这里发挥作用工具的强项也得到保留。架构图同理。大模型直接输出 PNG 图片不现实咱们真正想要的是一个“能改、能复用、能进代码仓库”的图源文件。Mermaid用类似代码的语法描述图形Diagrams则直接把架构图画成 Python 代码。两者都是“文本即图表”所以大模型可以非常可靠地生成结构正确的图表代码渲染由本地工具完成。这也是我反复实验后锁定的三个组合逻辑上很顺内容归 AI 管排版和渲染归工具管。1.1 为什么不用所见即所得的工具直接画很多人的习惯是用 XMind、Draw.io、ProcessOn 这类拖拽工具。这类工具适合短时间内快速画一张图但如果你的业务流程经常变动或者需要在一个团队里多人协作维护就会发现图的源文件难以做代码评审、难以 diff、难以版本管理。我一直强调一个观点架构图和代码一样应该能被 review 和追踪。用代码或文本描述架构图能让“画图”这件事纳入研发流程。1.2 为什么强调“可脚本化”我见过太多团队用在线 PPT 工具或者桌面画图软件导出都是二进制文件。这类文件没法放在 CI 里跑、没法通过 API 生成、更没法让大模型直接改。而Slidev的源码就是 MarkdownMermaid的源码是文本Diagrams的源码是 Python这三样都有天然的可脚本化优势。你可以轻松地写脚本批量修改目录结构、批量生成多张架构图甚至在不同方案之间做排列组合对比这在日常做技术方案时非常实用。2. Slidev给开发者和 AI 用的“程序员式 PPT”Slidev是一个基于 Web 的幻灯片工具它的核心特点就是“用 Markdown 写 PPT”。这不是什么新概念但Slidev把整个生态做得很完整包括主题、布局、代码高亮、动画、甚至内嵌组件完全面向开发者。对我这种习惯写文档的人来说用起来比 PowerPoint 顺手太多。2.1 最小环境配置与安装首先你需要一个 Node.js 环境版本建议 18 以上。装好后执行npm init slidevlatest它会引导你选择主题模板然后自动创建一个项目启动服务靠以下命令npm run dev这个命令会启动一个本地 Web 服务默认端口是 3030。你把 Markdown 文件写好保存后浏览器里会自动刷新体验非常流畅。这里需要注意一点Slidev的 Markdown 文件默认叫slides.md文件名可以改但你必须在文件中配置首页头部的 layout 信息。比如最简单的文件内容--- theme: seriph title: 微服务架构演进 info: 内部技术分享 class: text-center --- # 微服务架构演进 从单体到微服务我们经历了什么实际上即使你不写复杂的 frontmatter默认 theme 也能跑但为了最终演示效果我还是建议在最开始就规划好主题和页面布局。Slidev的页面分隔符是三个短横线---每一段之间就代表一页非常好理解。2.2 用 AI 生成 Slidev 内容的提示词模板它的核心价值在于你完全可以把自己的需求告诉给大模型让它生成结构化的slides.md内容。我给一个我一直在用、实测效果很稳定的提示词模板你是一位资深架构师和演讲者。请以 markdown 格式输出一份 Slidev 幻灯片源码主题是“微服务架构的演进”。 要求 1. 每页标题简洁有力。 2. 每页正文不要超过 5 个要点。 3. 涉及技术概念时每一页至少包含一句通俗的生活化类比。 4. 在第五页加入一个用 mermaid 语言描述的微服务调用关系图。 5. 最后加一页总结但不要把总结写成“综上所述”。 格式标题用 # 表示要点用 - 表示文件开头使用 --- 分隔。你会发现这个提示词里关键的信息是“以 Slidev 格式输出”这很重要。如果只是说“帮我做一个 PPT 大纲”得到的内容往往是一堆目录而不是可渲染的文件。你越明确输出格式的限制大模型的输出越接近可直接使用的状态。2.3 把架构图直接嵌进幻灯片Slidev支持在 Markdown 文件里直接写 Mermaid 代码块。你只需要在代码块的语言标记里写mermaid它就会自动渲染成图。比如mermaid graph LR A[网关] -- B[用户服务] A -- C[订单服务] A -- D[库存服务] D -- E[(MySQL)] 我第一次用这个功能时最直观的感受是“能直接在文档里管理架构图”实在太爽了。改图只需要调整文字描述不用在 PPT 和画图工具之间切来切去。这一点在方案评审时尤其高效——评审意见出来后我直接改代码块重新渲染就是一版新图。2.4 导出和部署的一点点经验Slidev支持导出为 PDF 或 PNG我常用的命令是npx slidev export这个命令会生成 PDF但导出时会依赖本机浏览器所以如果你用的是无头浏览器环境可能要多配一步 Playwright 的依赖。若只是给自己看直接在浏览器里演讲就很好因为Slidev自带的演讲者模式可以显示备注、下一帧预览比在线会议里共享屏幕还方便。我觉得Slidev最容易被忽略的功能是docker运行方式。在团队内部你可以直接用一个 Docker 镜像启动一个 Web 服务其他人只需要访问一个地址就能看到最新版的 PPT这比每个人本地装一套环境省事得多。这也是为什么我始终强调“选工具要看是否适合团队协作而不只是个人是否顺手”。3. Mermaid把架构图彻底变成一段可维护的文本Mermaid是一个基于文本的图表渲染工具语法非常接近自然语言。它能画流程图、时序图、状态图、甘特图甚至实体关系图基本覆盖了我日常画架构图的需求。虽然名字听起来像是个小众工具但在 GitHub 上早就火得不成样子是很多文档站、知识库默认内置的图表方案。3.1 为什么 Mermaid 对 AI 特别友好关键在于它的语法足够简单大模型完全不需要特殊训练就能生成基本正确的 Mermaid 代码。举个例子你想画一个简单的应用架构graph LR User[用户] -- API[API 网关] API -- ServiceA[认证服务] API -- ServiceB[业务服务] ServiceB -- DB[(数据库)]是不是很像在写一句带箭头的自然语言大模型读这种东西远比读 SVG 或者二进制格式容易。这意味着你完全可以把一张复杂架构图的需求描述成自然语言丢给 AI让它生成 Mermaid 源码再人工调整命名和组件关系效率比从零开始拖拽高太多了。3.2 一个有代表性的实操绘制电商系统架构图举个我最近做过的例子。需求是“画一张电商系统的部署架构包含 Nginx、前端、后端、Redis、MySQL 和消息队列”。我让 AI 生成的代码大致长这样graph TD Client[客户端] -- LB[Nginx 负载均衡] LB -- FE[前端静态资源] LB -- API[后端接口服务] API -- Redis[(Redis 缓存)] API -- MQ[消息队列] API -- MySQL[(MySQL 主库)] API -- ES[(Elasticsearch)]这段代码渲染出来就是非常直观的一张图线条清晰、节点分组明确。实际工作中我还会在此基础上加subgraph来划分不同模块比如把所有后端服务包在一个“后端集群”的虚框里再加不同颜色区分状态这让评审会上的图特别有说服力。3.3 选择合适的渲染方式Mermaid的渲染方式有很多常用有三种官方在线编辑器mermaid.live适合快速查看效果。Markdown 文档内置渲染适合写技术方案、README、知识库。mermaid-cli命令行工具适合批量渲染和集成到 CI。我建议团队里至少引入 CLI 的方式因为可以在自动构建时把.mmd文件统一渲染成 PNG 或 SVG然后嵌入到文档里。命令行安装方式一般是先装 Node 环境然后执行npm install -g mermaid-js/mermaid-cli渲染单张图mmdc -i architecture.mmd -o architecture.png -w 1024这个命令的-w参数可以设置输出图片宽度。我在实际使用中遇到过一个问题图片中文变成乱码特别是 Linux 服务器上这是因为缺少中文字体。解决办法是安装中文字体包比如fonts-noto-cjk同时可以在mmdc命令里指定 puppeteer 配置的字体路径细节比较琐碎但踩过一次之后就顺畅了。3.4 Mermaid 架构图在 AI 对话中的迭代方式用 AI 画架构图有个很好用的技巧不是一次生成就完事而是通过“对话式拆解”逐步完善。比如第一轮你只要求 AI 画三个核心服务第二轮说“把每个服务下的存储组件也加上”第三轮说“用 subgraph 按业务域分组”。每次只提一条增量需求AI 的产出质量会稳定得多。我经常在对话里加一句“请只输出 Mermaid 代码不要解释。”这样做的好处是能直接复制不用在一大段文字里挑代码。这属于提示词工程里很基础但极其有用的约束。4. Diagrams用 Python 代码绘制云原生架构图第三个项目严格来说不是传统意义的“画图工具”而是一个 Python 库名字就叫diagrams。它的核心概念是利用代码来描述节点和连线最终渲染出一张云架构图。它对各大云厂商如 AWS、Azure、阿里云、Kubernetes 等都内置了现成的节点图标做方案图特别合适。4.1 安装和系统依赖安装库本身很简单pip install diagrams但它依赖系统中的 Graphviz你在安装前必须确保本机已经装好 Graphviz。macOS 下用 Homebrew 装brew install graphvizUbuntu 系直接apt install graphviz如果不装 GraphvizPython 运行时会卡在渲染阶段报的错误信息往往不直观我第一次踩到这里时还以为是代码的问题。所以这里专门强调一下。4.2 一段最基础但能说明问题的代码先用一个最小的例子说明它的写法from diagrams import Diagram from diagrams.aws.compute import EC2 from diagrams.aws.database import RDS with Diagram(Web 服务架构, showFalse, directionTB): web EC2(Web 服务器) db RDS(用户数据库) web dbshowFalse表示生成图片后不自动打开预览文件如果用脚本批量生成通常都会关掉这个选项。directionTB代表从上到下排列如果架构的交互方向是从左到右可以改成directionLR。这段代码运行后会在当前目录生成web_service_architecture.png清晰度很不错适合放到 PPT 或技术方案里。4.3 实战画一个包含 K8s 的微服务架构工作中更多是画这种中等的微服务架构图。举个例子from diagrams import Diagram from diagrams.k8s.group import Namespace from diagrams.k8s.compute import Deployment, Pod from diagrams.k8s.network import Service, Ingress from diagrams.programming.language import Python with Diagram(订单服务 K8s 部署结构, showFalse): ingress Ingress(ingress) ns Namespace(订单域) with ns: svc Service(order-svc) dep Deployment(order-deployment) pod Pod(order-pod) code Python(Flask 服务) ingress svc dep pod pod code用这种方式画图最大的好处是代码本身就是一次架构评审记录改了代码就等于改了图。你可以把.py文件放进 Git 仓库Review 的时候看代码差异非常直观。这一点是拖拽画图软件永远做不到的。4.4 让 AI 生成 Diagrams 代码的实际经验AI 对该库的了解程度高低不一在常见模型里准确率还不错但如果你用的是通用模型建议先把该库某一个节点的官方命名给它看免得它瞎编类名。我在提示词里通常附这么一句“请基于 Python diagrams 库生成代码。节点类型可以从这些方向里选k8s.compute.Deployment、k8s.network.Service、aws.compute.EC2、aws.database.RDS、aws.network.ALB。注意:代码里 from diagrams import Diagram 必须保留。”因为多数 AI 对库的命名习惯能猜个大概但偶尔会把Deployment写成K8sDeployment这种错误可能只有在运行时报错才能发现。给模型限定命名范围后准确率能大幅提升。5. 三件套联动从一句需求到一张 PPT 完整流水线把三个工具串起来用体验才是真正的顺畅。我现在的通用流程是先有一个模糊需求比如“给新来的同事讲一下我们系统的核心架构”接着我会让大模型经过以下步骤产出 PPT 内容大纲结构按 Slidev 的 Markdown 格式写。从大纲中抽取关键架构关系生成 Mermaid 代码或 Diagrams 代码。联合渲染Slidev 页面中内嵌 Mermaid 图同时把 Diagrams 生成的 PNG 作为静态图片插入。这个流程最重要的价值是最终产出物全部是文本或代码你可以把它们全部提交到 Git 仓库。以后任何人更新架构只需要改代码再跑一遍渲染脚本就能同步更新 PPT、架构图和技术文档。5.1 一个可以直接复制使用的提示词模板如果你也想要类似的输出效果可以试一下下面这个综合提示词目标生成一份关于系统架构介绍的技术分享 PPT。 请按以下节奏输出 1. 先输出 Slidev 格式的 slides.md 内容使用 --- 分隔每一页。 2. 在“总体架构”那一页用 mermaid 代码块描述服务调用关系。 3. 然后在代码块之后用自然语言把架构要点总结成不超过三句话。 4. 最后用 Python diagrams 库的代码输出一张等价结构的基础设施图。 5. 保持内容通俗面向刚入职的开发同学。这份提示词虽然长但每一阶段都有限制产出的结果可以直接二次加工。我实际操作过几次觉得比“帮我一键生成 PPT”这种模糊要求靠谱得多。5.2 让渲染进入自动化管线如果团队有 CI/CD 环境可以把渲染自动化这件事做得更深。举个例子你在仓库里专门创建一个docs/目录存放slides.md和所有的.mmd或.py架构图源文件。提交代码后CI 里依次执行npx slidev export mmdc -i architecture.mmd -o architecture.png python architecture.py然后把生成的文件打包发布到内部文档站或者对象存储。这样每次技术方案更新只要代码合并最新的 PPT 和架构图就自动出现在团队页面上。5.3 什么时候不建议用这套流程不是所有场景都适合这个组合。比如你要做一个对外发布的、设计感极强的营销 PPT那用更适合盲涉的Slidev生态也能做但整体需要额外时间调试视觉效果。又比如你画的图要求精确到像素级的位置调整、带各种渐变和手绘风格那么Mermaid和Diagrams就不是最佳选择它们更适合“结构清晰、逻辑正确、可维护性优先”的工程化场景。拿捏住这个边界就不会误入“开源万能论”。6. 常见问题与排查方法速查表最后把这些工具踩过的坑集中整理一遍省得你再花时间走弯路。问题现象可能原因解决方案Slidev 启动端口被占用默认 3030 被其他服务占用修改端口启动npm run dev -- --port 4000Slidev 导出 PDF 时卡住没有安装 Playwright 浏览器内核先执行npx playwright install再导出Mermaid 渲染中文乱码系统缺少中文字体安装 Noto CJK 字体并在 puppeteer 配置里指定字体路径Mermaid CLI 找不到 Chrome安装了 CLI 但浏览器环境缺失安装 chromium 或使用--no-sandbox配置CI 中常见diagrams 运行报 Graphviz 相关错误Python 库已装但系统 Graphviz 没装安装 Graphviz 后重启终端/进程diagrams 生成的图片没有图标网络原因导致图标下载失败首次运行时保持网络通畅之后会有本地缓存AI 生成的 Mermaid 多方括号不配对模型对边语法理解偏差让 AI 只输出代码运行前先在官方 Live Editor 里校一次AI 生成的 Diagrams 类名不存在模型对库的命名记忆不准确限定节点类型或直接查看官方文档列表再生成我在维护这一整套流程的过程中最大的心得是工具越简单越适合 AI越容易被 AI 生成的越值得投进自动化流程。Slidev的 Markdown 简单所以 AI 能把科技结构写得很规整Mermaid语法简单所以 AI 能直接把需求变成图表Diagrams的逻辑简单所以它能让架构知识有生命周期。如果让我给一个最省事的起步建议我会说先别贪多从Mermaid开始。你在任何支持 Markdown 的环境里都能用最少的学习成本把第一张架构图画出来感受到“写代码画图”的爽点之后自然就想试试Slidev做演示并用Diagrams演进出一整套技术资产管理方案。这个循序渐进的路径比一次性扑向三个工具要踏实得多。