尧图网页设计 
有的团队一个月要改十几次流程图每次改完逻辑图形位置就全乱有的开发者想把流程图画进技术方案文档却发现导出、嵌入、协作每一个环节都在额外造轮子。最近免费开源流程图工具的关注度明显升温尤其是“拖拽组件 AI 自动生成 代码插入 动态线条”这几个能力组合到一起之后画流程图这件事的摩擦已经被大幅压缩。这篇文章想说的核心判断是流程图工具之争已经不是“谁的组件库更全”而是“从想法到图形成品的工作流谁更顺畅”。免费开源方案的价值不只是省钱而是把流程图从一个孤立的图形文件变成可以进 Git、可以自动生成、可以嵌入文档、可以随时再编辑的工程资产。如果你正在做技术方案、项目文档、需求梳理或者想给团队选一款不需要采购审批的绘图工具这篇文章会从选型逻辑、环境准备、拖拽实操、代码化 DSL、AI 生成、动态线条到团队协作完整走一遍。1. 免费开源流程图工具的定位与选型逻辑在具体动手之前先把“免费开源流程图工具”这一类方案的特点说清楚。它不是某一个软件而是一条完整的技术路线。和传统商业绘图软件相比开源方案的差异体现在三个层面。第一层是成本层面。商业绘图软件通常按席位收费团队一多授权费就是一笔不小的开支。开源方案没有授权成本可以把预算省下来投入到更重要的环节。第二层是工程层面。商业软件的图形文件通常是私有格式很难直接做版本对比也很难用脚本批量修改。而开源方案普遍支持 XML、Markdown、DSL 等文本化保存方式这意味着流程图可以像代码一样走 Git 分支、PR 评审、自动构建。第三层是能力扩展层面。因为代码是开放的你可以把流程图编辑器嵌入自己的系统可以给渲染引擎写插件也可以对接内部的大模型服务实现私有化的 AI 生成能力。这一点在后文会详细展开。主流的免费开源方案各有侧重我整理了一个选型对照表方便快速理解差异方案交互方式图形保存格式适合场景上手难度Draw.iodiagrams.net拖拽为主支持 XMLXML日常文档配图、产品原型图、架构图低Mermaid代码编写自动渲染Markdown 文本技术文档、Wiki、自动化生成低PlantUML代码编写DSL 描述纯文本规范化的时序图、活动图、用例图中LogicFlow / AntV X6拖拽 前端框架JSON/JS 配置自研业务系统内嵌流程图编辑器高需要注意的是这些方案并不是互斥的。实际项目中最常见的是“混用”文档里用 Mermaid 嵌入复杂交互图用 Draw.io 拖拽系统内嵌编辑器用 LogicFlow 这一类前端框架。如果你的需求只是“偶尔画几张图发给同事”那直接选 Draw.io 就够了。如果你的流程图需要频繁被修改、需要跟着代码一起发版那代码化方案会更合适。如果团队未来要做流程自动化、审批流系统那考虑前端框架级别的方案更长远。2. 拖拽组件与代码化 DSL两条工作路线的对比很多人第一次接触开源流程图工具时最先问的问题是到底应该用拖拽式的工具还是用写代码的方式画图这两个方向看起来只是操作习惯不同实际上对应了完全不同的使用场景。拖拽组件的核心优势是直觉化。你不需要学习任何语法打开画布把图形拖进去连上线加几个文字备注一张图就出来了。对于产品经理、运营人员、非技术同事来说这是门槛最低的方式。Draw.io 就是这类方案的代表。代码化 DSL 的核心优势是可维护性和可自动化。所谓 DSL简单说就是一套专门用来描述某种图形的文本语法。你用普通文本写下节点和连线关系然后交给渲染引擎它能自动帮你生成对应的图形。Mermaid 是一种 DSLPlantUML 是另一种 DSL。这里有一个很关键的对比点。拖拽画图时你手动调整的是“图形的位置”而代码画图时你描述的是“节点之间的关系”。后者的抽象层级更高也更接近软件开发思维。举个例子// 文件路径docs/order-flow.mmd // 这是一段 Mermaid 语法描述不是 JS 脚本 flowchart TD A[用户发起下单] -- B{库存校验} B -- 有货 -- C[扣减库存] C -- D[生成订单] B -- 无货 -- E[返回提示]上面这段文本只描述了流程结构没有定义任何一个图形坐标。渲染引擎会自动计算布局。这意味着你只需要维护文本本身不用关心排版而且文本可以进 Git 做 diff。那么实际项目中怎么选这里给出一个比较实用的决策逻辑如果是给运营、市场、产品同学协作使用场景是一次性沟通选拖拽式。如果是技术方案、SDK 文档、API 文档里的流程图选代码化方案方便随代码版本迭代。如果流程图会频繁在多个文档里复用选代码化方案复制粘贴成本极低。如果需要在自研系统里给用户提供流程图编辑能力那选择方向是 LogicFlow 这类前端框架而不是 Draw.io 或 Mermaid。两种路线并不是非此即彼。更省力的姿势是用 AI 生成 DSL 代码然后用拖拽工具做微调最后再以文本形式存回仓库。这套组合拳能覆盖绝大多数场景。3. 环境准备开源流程图工具的安装与部署下面进入实操部分。先说明环境。这里以常见的三个方向为例桌面拖拽工具、代码化 CLI 工具、服务端自托管工具。版本号建议以官方仓库当前发布为准本文重点演示通用流程。3.1 Draw.io 桌面版Draw.io 的桌面版支持 Windows、macOS 和 Linux。最简单的方式是到官方 GitHub Release 页面下载对应平台的安装包。安装完成之后打开即用不需要额外配置。如果你习惯用 VS Code也可以直接在扩展市场搜索 “Draw.io Integration”安装后就能在 VS Code 里直接编辑.drawio和.dio文件。这个方案的好处是图形文件直接跟着项目仓库走不需要切换软件窗口。安装完成后建议先做两件事第一把默认语言改成中文在 Extra 菜单或者 Language 选项里切换第二确认导出格式一般建议使用 PNG 或 SVGSVG 适合插入网页和文档缩放不失真。3.2 Mermaid CLIMermaid 最常用的运行方式有三种一是在支持 Mermaid 的 Markdown 编辑器里直接渲染二是通过 mermaid.js 在网页里渲染三是用官方 CLI 把.mmd文件转换成图片。安装 Mermaid CLI 的命令如下# 安装 mermaid-cli提供 mmdc 命令 npm install -g mermaid-js/mermaid-cli # 检查是否安装成功 mmdc --version如果你的 Node.js 环境已经安装好这步几分钟就能完成。转换一张图的命令如下# 把 input.mmd 转成 SVG mmdc -i input.mmd -o output.svg # 如果希望背景为白色并放大两倍导出可以加参数 mmdc -i input.mmd -o output.png -b white -s 2Mermaid 的.mmd文件是纯文本可以放进代码仓库。它的渲染结果和代码文件是分离的所以需要修改时直接改文本重新生成图片即可。3.3 PlantUML 服务端PlantUML 有点特殊它有两种运行方式。本地方式是通过 Java 执行 jar 包但依赖 Graphviz 来布局。还有一种方式是直接使用它的服务端镜像由服务端处理渲染客户端只需要提供一个文本地址。下面用 Docker 启动一个本地 PlantUML 服务# 拉取并启动 PlantUML Server docker run -d --name plantuml \ -p 8080:8080 \ plantuml/plantuml-server:jetty启动完成后浏览器访问http://localhost:8080就可以看到一个在线编辑页面。你把 PlantUML 语法粘贴进去它会自动渲染图表。这里有一个常见的部署选择。如果团队在内网或国产化环境工作不方便使用公网云服务那么用 Docker 把 Draw.io 或 PlantUML 部署到内网服务器是一个稳妥方案。这样图形数据不经过外部服务更符合数据合规和私有化要求。国内也有越来越多团队把流程图工具和本地 AI 服务放在一起部署形成一个完整的内网生产力工具链。4. 拖拽组件实操从空白画布到订单流程理解了选型和环境之后开始动手画一张真实的图。以一个常见的“创建订单”流程为例目标是在 Draw.io 中画出以下流程开始 - 用户发起下单 - 库存校验 - 判断是否有货 - 有货则扣减库存并生成订单无货则返回提示。第一步打开 Draw.io创建一个空白图表。左侧面板是图形库软件内置了很多分组包括矩形、菱形、椭圆、泳道、图标等。你要用到的核心图形是开始/结束圆角矩形、流程矩形、判断菱形、箭头连线。第二步拖出第一个节点。在左侧“General”分类下把“Rectangle”拖到画布上双击节点输入“用户发起下单”。再把“Diamond”拖到下方输入“库存校验”。第三步连线。把鼠标悬停在“用户发起下单”节点边缘会出现连接锚点。按住锚点拖到“库存校验”节点Draw.io 会自动创建一条带箭头的连线。默认情况下连线上可以双击输入文字比如“发起请求”。第四步处理分支。从“库存校验”菱形引出一条线到“扣减库存”再引出一条到“返回提示”。在菱形上右键可以编辑连接标签分别填上“有货”和“无货”。这就是流程分支。第五步调整布局。选中多个节点在右侧 Format 面板可以设置对齐方式、间距、配色。保持网格对齐是一个好习惯Draw.io 默认开启网格吸附拖拽时会自动贴近网格。这里要提醒一个新手容易踩的坑如果你直接把节点拖到另一个节点上Draw.io 可能会创建父子关系而不是连接线。判断标准是看节点的边框是否出现子节点标记。要避免这个问题一定从连接锚点开始拖线而不是从节点中心拖。画完之后保存图。Draw.io 默认保存为.drawio后缀的 XML 文件。这个文件很小可以直接提交到 Git 仓库。导出一份 PNG/SVG 用于文档贴图。上面是拖拽操作的完整路径。你可能已经发现一张图的核心不是怎么拖动而是你脑海中是否想清楚了流程结构。这也是为什么后面两种能力更重要代码插入和 AI 生成。5. 代码插入用 Mermaid 和 PlantUML 让流程图进入工程体系在日常开发中流程图往往不是一个孤立需求而是文档、代码、自动化流程的一部分。这时“代码插入”就变得很关键。这里的“代码插入”包含两层含义第一层是把 DSL 代码插入到技术文档中让文档自动渲染流程图第二层是把图形文件变成代码文件参与版本管理。Mermaid 最典型的应用场景是 Markdown 文档。在 GitHub、GitLab 或者支持 Mermaid 的博客系统中你只需要在 Markdown 里写入 Mermaid 语法页面就会自动渲染出图形。下面是一个完整的 Mermaid 订单流程代码示例。为了兼容不同编辑器的渲染方式这里用普通文本块展示// 保存为 order-flow.mmd flowchart TD A[用户发起下单] -- B{库存校验} B -- 有货 -- C[扣减库存] B -- 无货 -- E[返回提示] C -- D[生成订单] D -- F[订单创建完成]渲染出来的结果是一张清晰的上下流程图A 节点为开始B 节点为判断分支。如果团队用的是 GitLab把这行代码放进.md文件里MR 页面就能直接看到流程图。PlantUML 的语法略有不同但逻辑类似。它支持更丰富的图形类型比如活动图、用例图、时序图。下面是一个活动图的例子startuml start :用户发起下单; if (库存校验?) then (有货) :扣减库存; :生成订单; else (无货) :返回提示; endif stop enduml这段代码可以通过 PlantUML Server 渲染也可以放在支持 PlantUML 插件的编辑器中。如果团队内部有 PlantUML Server只要把这段文本编码后拼接到服务地址上就能得到一个图片链接非常适合嵌入到接口文档中。代码插入还有一个更进阶的用法用脚本批量渲染。如果项目里有一堆.mmd文件每次修改之后都要手动去导出图片效率很低。可以在 CI/CD 脚本里自动执行 Mermaid CLI把图表生成纳入构建流程# 遍历 docs/ 下所有 .mmd 文件并导出 SVG for f in docs/*.mmd; do mmdc -i $f -o ${f%.mmd}.svg -b white done这样文档更新之后图片会自动重新生成不会出现“文档改了但图没更新”的问题。6. AI 自动生成流程图提示词模板与落地套路这一节是文章的重点也是很多开发者真正感兴趣的部分。免费开源流程图工具加上 AI 自动生成意味着什么呢就是你把一段业务描述丢给大模型它直接返回 Mermaid 或 PlantUML 代码你粘贴到编辑器里一张基本合格的流程图就出来了。这个流程给开发带来的变化很大。以前画图要手动拖拽现在只要“描述清楚业务逻辑”剩下的事情交给 AI。关键是现在的开源大模型大多支持在本地或内网部署对于有数据隐私要求的企业可以在私有化环境完成整个生成链路。先看一个最小可用的提示词模板。不要把需求直接丢给 AI 说“帮我画个流程图”信息太少AI 只能生成一个很泛的模板。更有效的做法是给出明确的角色、输出格式和业务条件。下面是一段可以参考的提示词框架你是一名资深业务流程分析师。 请根据下面的业务描述生成 Mermaid flowchart 代码。 要求 1. 使用中文字符节点名称清晰。 2. 用 flowchart TD 结构。 3. 必须包含正常流程和异常分支。 4. 如果描述中有判断条件用菱形节点表示。 5. 只输出 Mermaid 代码不要额外解释。 业务描述 用户在小程序点击下单先检查登录状态未登录则跳转登录页。 登录后校验商品库存库存不足则显示缺货提示。 库存充足则创建订单进入支付流程支付成功后发送通知。这段提示词里最关键的其实是最后三行业务描述。AI 真正需要的是流程节点之间的逻辑关系。如果你自己能清晰列出“开始 - 检查 - 分支 - 结果”AI 生成的质量会高很多。生成代码后建议经过“三步走”验证第一步把代码粘贴到 GitLab Wiki 或本地 Markdown 编辑器里渲染快速扫一眼结构是否完整。 第二步检查分支条件是否准确。AI 经常会漏掉“未登录”这种前置判断或者把“有货”和“无货”分支画反。 第三步把 AI 生成的代码整理进项目仓库命名规范一点比如docs/flows/order-create.mmd。这里要特别提醒一点不要让 AI 直接生成几百个节点的巨型流程图。大模型在处理长流程时容易出现节点丢失、连线错乱的问题。更稳妥的做法是分模块生成每个模块控制在 10 到 20 个节点以内最后手动拼接成一张总图。如果团队在内网环境部署了本地大模型服务比如基于开源模型搭建的问答服务那么可以把提示词模板内置到内部工具里让同事通过简单的页面描述生成流程图。这样既保证了数据不出内网也降低了团队协作的认知门槛。AI 生成这件事真正改变的不只是你画图的速度而是团队里任何人都可以成为流程表达者。以前需要专门的人把口头需求画成图现在只需要一句准确的描述。7. 动态线条让静态流程图变成可视化演示动态线条是什么简单说就是流程图中的连接线可以按照一定节奏流动或者节点在展示时依次高亮。这个效果在做方案评审、视频录屏、教学演示时非常有用。静态图看完就完了动态线条能让观众的注意力跟着流程走。在免费开源方案里Mermaid 配合 CSS 可以实现比较合适的动态效果。渲染出来的 SVG 图形里每条连线是一个路径通过 CSS 动画控制线条的虚线和偏移实现类似“电流从 A 流向 B”的效果。下面是一个完整的 CSS 示例把 Mermaid 渲染结果中的连接线变成流动虚线/* 这段样式适用于 Mermaid 渲染后的 SVG 页面 */ keyframes dash-flow { to { stroke-dashoffset: -20; } } .edgePaths path { stroke-dasharray: 8 6; stroke-linecap: round; animation: dash-flow 1.2s linear infinite; }使用方式很简单。先把 Mermaid 代码渲染成 HTML 页面然后在页面中引入这段 CSS。刷新页面所有连接线都会呈现流动效果非常直观。如果你用的是 Draw.io动态线条没有内置的一键开关。但它的导出能力很强你可以把多个状态的图依次导出再在录屏软件里做成时间轴动画。不过相比之下代码化方案的可控性更高。有一点需要说明CSDN 等部分博客平台对 Mermaid 代码块有渲染限制。动态线条效果更适合在本地文档、内部 Wiki 或自建博客中使用。如果你在自己的网站里集成了 Mermaid.js通过自定义 CSS 就能实现这类效果这是最可控的路径。动态线条不是必须的但它是一个很好的“包装层”能力。同样的流程图静态贴在文档里和动态展示在评审会上给听众的感受完全不同。8. 常见问题与排查思路在实际使用免费开源流程图工具时经常会遇到一些共性问题。下面整理成表格方便快速定位。问题现象可能原因排查方式解决方案中文显示为方块或乱码渲染环境缺少中文字体检查字体列表导出时查看字体警告安装中文字体或在 CLI 导出时指定字体Mermaid 代码本地正常平台不渲染平台默认关闭 Mermaid查看文档说明或站点配置本地渲染后导出图片再插入文档PlantUML 报 Graphviz 相关错误本地 jar 缺少 graphviz 依赖执行dot -V查看是否安装安装 graphviz或改用 Docker Server 方式大图导出卡死或内存溢出节点与连线过多拆分模块逐步导出使用子图分区分批渲染Draw.io 保存后同事打开排版错乱版本不一致或字体缺失检查双方安装版本统一版本使用内嵌字体AI 生成的 Mermaid 代码无法渲染语法错误或引号不配对用 Mermaid Live 在线校验人工修正节点 ID 和连接符号其中两个问题值得展开。第一个是中文乱码。Mermaid 在部分 Linux 服务器上导出图片时如果系统没有安装中文字体就会出现方块。解决办法是在服务器上安装fonts-wqy-microhei这类中文字体包。使用 Mermaid CLI 时可以在配置文件中指定字体。对于 PlantUML则建议直接用 Docker Server 版本因为镜像内置了常用字体。第二个是“本地正常发布到平台后不渲染”。这个问题非常常见。很多技术社区的 Markdown 编辑器默认不启用 Mermaid 渲染。遇到这种情况不要跟平台较劲直接本地用mmdc导出 SVG 或 PNG把图片插入文档。虽然少了一点实时性但展示效果完全一致而且更通用。9. 团队协作与工程化最佳实践最后聊一聊落地层面的经验。免费开源流程图工具真正改变团队协作是在你把流程图当作代码资产来管理时实现的。9.1 源文件入库图片只是产物这是第一个原则。凡是直接用图形界面保存的.drawio文件或代码化的.mmd、.puml文件都应该进入 Git 仓库而不是只提交 PNG/JPG 图片。图形文件容易被反复导出覆盖源文件才能完整保留编辑信息。文本化的流程图设计非常适合 Git 的 diff 机制因为.mmd、.puml本质上是可以逐行对比的文本。团队 review 时可以直接看到逻辑是否变化而不用打开图慢慢找差异。9.2 命名规范与文件夹划分建议按照“模块 流程类型”组织文件结构。示例docs/ ├── flows/ │ ├── order/ │ │ ├── order-create.mmd │ │ └── order-refund.puml │ └── user/ │ └── user-login.mmd └── diagrams/ ├── system-architecture.drawio └── network-topology.drawio核心流程文件放在/flows下架构类大图放在/diagrams下。命名用英文小写加中划线避免中文文件名在某些平台出现编码问题。9.3 与 API 文档、接口设计保持同步技术方案评审时最怕的是流程图画了一套代码实现又是另一套。建议在 MR/PR 描述中直接引用流程文件的内容。如果改动涉及核心流程要求提交者同步更新对应.mmd或.drawio文件。这可以作为一种团队规范固定下来。9.4 本地模型与私有化部署的边界很多企业已经把流程图生成对接到了内部大模型服务。这里要提醒的是即使是本地模型也要注意权限边界。不是所有业务人员都应该有权把系统内部流程描述发给同一个模型更不要在生产环境的敏感流程图上附加多余的业务数据。建议将流程描述和业务数据脱敏后输入模型并且对生成结果做二次校对。9.5 自动化脚本辅助如果团队已经部署了本地 AI 服务可以把流程图生成做成一个内部小工具。只需要一个简单的页面输入业务描述调用本地模型生成 Mermaid 代码再调用mmdc渲染图片。这样从描述到图片可以控制在几十秒内而且不依赖外部网络。总的来说这套开源工具链的核心价值不是某一个软件而是一套“描述 - 生成 - 渲染 - 入库 - 协作”的完整工作流。画图不再是一个孤立的环节而是真正嵌入了研发流程。对开发者来说下一步最值得做的不是把市面上所有工具都装一遍而是选一个最贴合自己团队的组合需要拖拽就先上手 Draw.io需要文档嵌入就掌握 Mermaid需要规范建模就研究 PlantUML。再加上 AI 生成能力和动态展示技巧流程图绘制这件事完全可以变成一个高效的工程习惯。 免费开源流程图工具实战：从拖拽到AI生成与代码化协作
有的团队一个月要改十几次流程图每次改完逻辑图形位置就全乱有的开发者想把流程图画进技术方案文档却发现导出、嵌入、协作每一个环节都在额外造轮子。最近免费开源流程图工具的关注度明显升温尤其是“拖拽组件 AI 自动生成 代码插入 动态线条”这几个能力组合到一起之后画流程图这件事的摩擦已经被大幅压缩。这篇文章想说的核心判断是流程图工具之争已经不是“谁的组件库更全”而是“从想法到图形成品的工作流谁更顺畅”。免费开源方案的价值不只是省钱而是把流程图从一个孤立的图形文件变成可以进 Git、可以自动生成、可以嵌入文档、可以随时再编辑的工程资产。如果你正在做技术方案、项目文档、需求梳理或者想给团队选一款不需要采购审批的绘图工具这篇文章会从选型逻辑、环境准备、拖拽实操、代码化 DSL、AI 生成、动态线条到团队协作完整走一遍。1. 免费开源流程图工具的定位与选型逻辑在具体动手之前先把“免费开源流程图工具”这一类方案的特点说清楚。它不是某一个软件而是一条完整的技术路线。和传统商业绘图软件相比开源方案的差异体现在三个层面。第一层是成本层面。商业绘图软件通常按席位收费团队一多授权费就是一笔不小的开支。开源方案没有授权成本可以把预算省下来投入到更重要的环节。第二层是工程层面。商业软件的图形文件通常是私有格式很难直接做版本对比也很难用脚本批量修改。而开源方案普遍支持 XML、Markdown、DSL 等文本化保存方式这意味着流程图可以像代码一样走 Git 分支、PR 评审、自动构建。第三层是能力扩展层面。因为代码是开放的你可以把流程图编辑器嵌入自己的系统可以给渲染引擎写插件也可以对接内部的大模型服务实现私有化的 AI 生成能力。这一点在后文会详细展开。主流的免费开源方案各有侧重我整理了一个选型对照表方便快速理解差异方案交互方式图形保存格式适合场景上手难度Draw.iodiagrams.net拖拽为主支持 XMLXML日常文档配图、产品原型图、架构图低Mermaid代码编写自动渲染Markdown 文本技术文档、Wiki、自动化生成低PlantUML代码编写DSL 描述纯文本规范化的时序图、活动图、用例图中LogicFlow / AntV X6拖拽 前端框架JSON/JS 配置自研业务系统内嵌流程图编辑器高需要注意的是这些方案并不是互斥的。实际项目中最常见的是“混用”文档里用 Mermaid 嵌入复杂交互图用 Draw.io 拖拽系统内嵌编辑器用 LogicFlow 这一类前端框架。如果你的需求只是“偶尔画几张图发给同事”那直接选 Draw.io 就够了。如果你的流程图需要频繁被修改、需要跟着代码一起发版那代码化方案会更合适。如果团队未来要做流程自动化、审批流系统那考虑前端框架级别的方案更长远。2. 拖拽组件与代码化 DSL两条工作路线的对比很多人第一次接触开源流程图工具时最先问的问题是到底应该用拖拽式的工具还是用写代码的方式画图这两个方向看起来只是操作习惯不同实际上对应了完全不同的使用场景。拖拽组件的核心优势是直觉化。你不需要学习任何语法打开画布把图形拖进去连上线加几个文字备注一张图就出来了。对于产品经理、运营人员、非技术同事来说这是门槛最低的方式。Draw.io 就是这类方案的代表。代码化 DSL 的核心优势是可维护性和可自动化。所谓 DSL简单说就是一套专门用来描述某种图形的文本语法。你用普通文本写下节点和连线关系然后交给渲染引擎它能自动帮你生成对应的图形。Mermaid 是一种 DSLPlantUML 是另一种 DSL。这里有一个很关键的对比点。拖拽画图时你手动调整的是“图形的位置”而代码画图时你描述的是“节点之间的关系”。后者的抽象层级更高也更接近软件开发思维。举个例子// 文件路径docs/order-flow.mmd // 这是一段 Mermaid 语法描述不是 JS 脚本 flowchart TD A[用户发起下单] -- B{库存校验} B -- 有货 -- C[扣减库存] C -- D[生成订单] B -- 无货 -- E[返回提示]上面这段文本只描述了流程结构没有定义任何一个图形坐标。渲染引擎会自动计算布局。这意味着你只需要维护文本本身不用关心排版而且文本可以进 Git 做 diff。那么实际项目中怎么选这里给出一个比较实用的决策逻辑如果是给运营、市场、产品同学协作使用场景是一次性沟通选拖拽式。如果是技术方案、SDK 文档、API 文档里的流程图选代码化方案方便随代码版本迭代。如果流程图会频繁在多个文档里复用选代码化方案复制粘贴成本极低。如果需要在自研系统里给用户提供流程图编辑能力那选择方向是 LogicFlow 这类前端框架而不是 Draw.io 或 Mermaid。两种路线并不是非此即彼。更省力的姿势是用 AI 生成 DSL 代码然后用拖拽工具做微调最后再以文本形式存回仓库。这套组合拳能覆盖绝大多数场景。3. 环境准备开源流程图工具的安装与部署下面进入实操部分。先说明环境。这里以常见的三个方向为例桌面拖拽工具、代码化 CLI 工具、服务端自托管工具。版本号建议以官方仓库当前发布为准本文重点演示通用流程。3.1 Draw.io 桌面版Draw.io 的桌面版支持 Windows、macOS 和 Linux。最简单的方式是到官方 GitHub Release 页面下载对应平台的安装包。安装完成之后打开即用不需要额外配置。如果你习惯用 VS Code也可以直接在扩展市场搜索 “Draw.io Integration”安装后就能在 VS Code 里直接编辑.drawio和.dio文件。这个方案的好处是图形文件直接跟着项目仓库走不需要切换软件窗口。安装完成后建议先做两件事第一把默认语言改成中文在 Extra 菜单或者 Language 选项里切换第二确认导出格式一般建议使用 PNG 或 SVGSVG 适合插入网页和文档缩放不失真。3.2 Mermaid CLIMermaid 最常用的运行方式有三种一是在支持 Mermaid 的 Markdown 编辑器里直接渲染二是通过 mermaid.js 在网页里渲染三是用官方 CLI 把.mmd文件转换成图片。安装 Mermaid CLI 的命令如下# 安装 mermaid-cli提供 mmdc 命令 npm install -g mermaid-js/mermaid-cli # 检查是否安装成功 mmdc --version如果你的 Node.js 环境已经安装好这步几分钟就能完成。转换一张图的命令如下# 把 input.mmd 转成 SVG mmdc -i input.mmd -o output.svg # 如果希望背景为白色并放大两倍导出可以加参数 mmdc -i input.mmd -o output.png -b white -s 2Mermaid 的.mmd文件是纯文本可以放进代码仓库。它的渲染结果和代码文件是分离的所以需要修改时直接改文本重新生成图片即可。3.3 PlantUML 服务端PlantUML 有点特殊它有两种运行方式。本地方式是通过 Java 执行 jar 包但依赖 Graphviz 来布局。还有一种方式是直接使用它的服务端镜像由服务端处理渲染客户端只需要提供一个文本地址。下面用 Docker 启动一个本地 PlantUML 服务# 拉取并启动 PlantUML Server docker run -d --name plantuml \ -p 8080:8080 \ plantuml/plantuml-server:jetty启动完成后浏览器访问http://localhost:8080就可以看到一个在线编辑页面。你把 PlantUML 语法粘贴进去它会自动渲染图表。这里有一个常见的部署选择。如果团队在内网或国产化环境工作不方便使用公网云服务那么用 Docker 把 Draw.io 或 PlantUML 部署到内网服务器是一个稳妥方案。这样图形数据不经过外部服务更符合数据合规和私有化要求。国内也有越来越多团队把流程图工具和本地 AI 服务放在一起部署形成一个完整的内网生产力工具链。4. 拖拽组件实操从空白画布到订单流程理解了选型和环境之后开始动手画一张真实的图。以一个常见的“创建订单”流程为例目标是在 Draw.io 中画出以下流程开始 - 用户发起下单 - 库存校验 - 判断是否有货 - 有货则扣减库存并生成订单无货则返回提示。第一步打开 Draw.io创建一个空白图表。左侧面板是图形库软件内置了很多分组包括矩形、菱形、椭圆、泳道、图标等。你要用到的核心图形是开始/结束圆角矩形、流程矩形、判断菱形、箭头连线。第二步拖出第一个节点。在左侧“General”分类下把“Rectangle”拖到画布上双击节点输入“用户发起下单”。再把“Diamond”拖到下方输入“库存校验”。第三步连线。把鼠标悬停在“用户发起下单”节点边缘会出现连接锚点。按住锚点拖到“库存校验”节点Draw.io 会自动创建一条带箭头的连线。默认情况下连线上可以双击输入文字比如“发起请求”。第四步处理分支。从“库存校验”菱形引出一条线到“扣减库存”再引出一条到“返回提示”。在菱形上右键可以编辑连接标签分别填上“有货”和“无货”。这就是流程分支。第五步调整布局。选中多个节点在右侧 Format 面板可以设置对齐方式、间距、配色。保持网格对齐是一个好习惯Draw.io 默认开启网格吸附拖拽时会自动贴近网格。这里要提醒一个新手容易踩的坑如果你直接把节点拖到另一个节点上Draw.io 可能会创建父子关系而不是连接线。判断标准是看节点的边框是否出现子节点标记。要避免这个问题一定从连接锚点开始拖线而不是从节点中心拖。画完之后保存图。Draw.io 默认保存为.drawio后缀的 XML 文件。这个文件很小可以直接提交到 Git 仓库。导出一份 PNG/SVG 用于文档贴图。上面是拖拽操作的完整路径。你可能已经发现一张图的核心不是怎么拖动而是你脑海中是否想清楚了流程结构。这也是为什么后面两种能力更重要代码插入和 AI 生成。5. 代码插入用 Mermaid 和 PlantUML 让流程图进入工程体系在日常开发中流程图往往不是一个孤立需求而是文档、代码、自动化流程的一部分。这时“代码插入”就变得很关键。这里的“代码插入”包含两层含义第一层是把 DSL 代码插入到技术文档中让文档自动渲染流程图第二层是把图形文件变成代码文件参与版本管理。Mermaid 最典型的应用场景是 Markdown 文档。在 GitHub、GitLab 或者支持 Mermaid 的博客系统中你只需要在 Markdown 里写入 Mermaid 语法页面就会自动渲染出图形。下面是一个完整的 Mermaid 订单流程代码示例。为了兼容不同编辑器的渲染方式这里用普通文本块展示// 保存为 order-flow.mmd flowchart TD A[用户发起下单] -- B{库存校验} B -- 有货 -- C[扣减库存] B -- 无货 -- E[返回提示] C -- D[生成订单] D -- F[订单创建完成]渲染出来的结果是一张清晰的上下流程图A 节点为开始B 节点为判断分支。如果团队用的是 GitLab把这行代码放进.md文件里MR 页面就能直接看到流程图。PlantUML 的语法略有不同但逻辑类似。它支持更丰富的图形类型比如活动图、用例图、时序图。下面是一个活动图的例子startuml start :用户发起下单; if (库存校验?) then (有货) :扣减库存; :生成订单; else (无货) :返回提示; endif stop enduml这段代码可以通过 PlantUML Server 渲染也可以放在支持 PlantUML 插件的编辑器中。如果团队内部有 PlantUML Server只要把这段文本编码后拼接到服务地址上就能得到一个图片链接非常适合嵌入到接口文档中。代码插入还有一个更进阶的用法用脚本批量渲染。如果项目里有一堆.mmd文件每次修改之后都要手动去导出图片效率很低。可以在 CI/CD 脚本里自动执行 Mermaid CLI把图表生成纳入构建流程# 遍历 docs/ 下所有 .mmd 文件并导出 SVG for f in docs/*.mmd; do mmdc -i $f -o ${f%.mmd}.svg -b white done这样文档更新之后图片会自动重新生成不会出现“文档改了但图没更新”的问题。6. AI 自动生成流程图提示词模板与落地套路这一节是文章的重点也是很多开发者真正感兴趣的部分。免费开源流程图工具加上 AI 自动生成意味着什么呢就是你把一段业务描述丢给大模型它直接返回 Mermaid 或 PlantUML 代码你粘贴到编辑器里一张基本合格的流程图就出来了。这个流程给开发带来的变化很大。以前画图要手动拖拽现在只要“描述清楚业务逻辑”剩下的事情交给 AI。关键是现在的开源大模型大多支持在本地或内网部署对于有数据隐私要求的企业可以在私有化环境完成整个生成链路。先看一个最小可用的提示词模板。不要把需求直接丢给 AI 说“帮我画个流程图”信息太少AI 只能生成一个很泛的模板。更有效的做法是给出明确的角色、输出格式和业务条件。下面是一段可以参考的提示词框架你是一名资深业务流程分析师。 请根据下面的业务描述生成 Mermaid flowchart 代码。 要求 1. 使用中文字符节点名称清晰。 2. 用 flowchart TD 结构。 3. 必须包含正常流程和异常分支。 4. 如果描述中有判断条件用菱形节点表示。 5. 只输出 Mermaid 代码不要额外解释。 业务描述 用户在小程序点击下单先检查登录状态未登录则跳转登录页。 登录后校验商品库存库存不足则显示缺货提示。 库存充足则创建订单进入支付流程支付成功后发送通知。这段提示词里最关键的其实是最后三行业务描述。AI 真正需要的是流程节点之间的逻辑关系。如果你自己能清晰列出“开始 - 检查 - 分支 - 结果”AI 生成的质量会高很多。生成代码后建议经过“三步走”验证第一步把代码粘贴到 GitLab Wiki 或本地 Markdown 编辑器里渲染快速扫一眼结构是否完整。 第二步检查分支条件是否准确。AI 经常会漏掉“未登录”这种前置判断或者把“有货”和“无货”分支画反。 第三步把 AI 生成的代码整理进项目仓库命名规范一点比如docs/flows/order-create.mmd。这里要特别提醒一点不要让 AI 直接生成几百个节点的巨型流程图。大模型在处理长流程时容易出现节点丢失、连线错乱的问题。更稳妥的做法是分模块生成每个模块控制在 10 到 20 个节点以内最后手动拼接成一张总图。如果团队在内网环境部署了本地大模型服务比如基于开源模型搭建的问答服务那么可以把提示词模板内置到内部工具里让同事通过简单的页面描述生成流程图。这样既保证了数据不出内网也降低了团队协作的认知门槛。AI 生成这件事真正改变的不只是你画图的速度而是团队里任何人都可以成为流程表达者。以前需要专门的人把口头需求画成图现在只需要一句准确的描述。7. 动态线条让静态流程图变成可视化演示动态线条是什么简单说就是流程图中的连接线可以按照一定节奏流动或者节点在展示时依次高亮。这个效果在做方案评审、视频录屏、教学演示时非常有用。静态图看完就完了动态线条能让观众的注意力跟着流程走。在免费开源方案里Mermaid 配合 CSS 可以实现比较合适的动态效果。渲染出来的 SVG 图形里每条连线是一个路径通过 CSS 动画控制线条的虚线和偏移实现类似“电流从 A 流向 B”的效果。下面是一个完整的 CSS 示例把 Mermaid 渲染结果中的连接线变成流动虚线/* 这段样式适用于 Mermaid 渲染后的 SVG 页面 */ keyframes dash-flow { to { stroke-dashoffset: -20; } } .edgePaths path { stroke-dasharray: 8 6; stroke-linecap: round; animation: dash-flow 1.2s linear infinite; }使用方式很简单。先把 Mermaid 代码渲染成 HTML 页面然后在页面中引入这段 CSS。刷新页面所有连接线都会呈现流动效果非常直观。如果你用的是 Draw.io动态线条没有内置的一键开关。但它的导出能力很强你可以把多个状态的图依次导出再在录屏软件里做成时间轴动画。不过相比之下代码化方案的可控性更高。有一点需要说明CSDN 等部分博客平台对 Mermaid 代码块有渲染限制。动态线条效果更适合在本地文档、内部 Wiki 或自建博客中使用。如果你在自己的网站里集成了 Mermaid.js通过自定义 CSS 就能实现这类效果这是最可控的路径。动态线条不是必须的但它是一个很好的“包装层”能力。同样的流程图静态贴在文档里和动态展示在评审会上给听众的感受完全不同。8. 常见问题与排查思路在实际使用免费开源流程图工具时经常会遇到一些共性问题。下面整理成表格方便快速定位。问题现象可能原因排查方式解决方案中文显示为方块或乱码渲染环境缺少中文字体检查字体列表导出时查看字体警告安装中文字体或在 CLI 导出时指定字体Mermaid 代码本地正常平台不渲染平台默认关闭 Mermaid查看文档说明或站点配置本地渲染后导出图片再插入文档PlantUML 报 Graphviz 相关错误本地 jar 缺少 graphviz 依赖执行dot -V查看是否安装安装 graphviz或改用 Docker Server 方式大图导出卡死或内存溢出节点与连线过多拆分模块逐步导出使用子图分区分批渲染Draw.io 保存后同事打开排版错乱版本不一致或字体缺失检查双方安装版本统一版本使用内嵌字体AI 生成的 Mermaid 代码无法渲染语法错误或引号不配对用 Mermaid Live 在线校验人工修正节点 ID 和连接符号其中两个问题值得展开。第一个是中文乱码。Mermaid 在部分 Linux 服务器上导出图片时如果系统没有安装中文字体就会出现方块。解决办法是在服务器上安装fonts-wqy-microhei这类中文字体包。使用 Mermaid CLI 时可以在配置文件中指定字体。对于 PlantUML则建议直接用 Docker Server 版本因为镜像内置了常用字体。第二个是“本地正常发布到平台后不渲染”。这个问题非常常见。很多技术社区的 Markdown 编辑器默认不启用 Mermaid 渲染。遇到这种情况不要跟平台较劲直接本地用mmdc导出 SVG 或 PNG把图片插入文档。虽然少了一点实时性但展示效果完全一致而且更通用。9. 团队协作与工程化最佳实践最后聊一聊落地层面的经验。免费开源流程图工具真正改变团队协作是在你把流程图当作代码资产来管理时实现的。9.1 源文件入库图片只是产物这是第一个原则。凡是直接用图形界面保存的.drawio文件或代码化的.mmd、.puml文件都应该进入 Git 仓库而不是只提交 PNG/JPG 图片。图形文件容易被反复导出覆盖源文件才能完整保留编辑信息。文本化的流程图设计非常适合 Git 的 diff 机制因为.mmd、.puml本质上是可以逐行对比的文本。团队 review 时可以直接看到逻辑是否变化而不用打开图慢慢找差异。9.2 命名规范与文件夹划分建议按照“模块 流程类型”组织文件结构。示例docs/ ├── flows/ │ ├── order/ │ │ ├── order-create.mmd │ │ └── order-refund.puml │ └── user/ │ └── user-login.mmd └── diagrams/ ├── system-architecture.drawio └── network-topology.drawio核心流程文件放在/flows下架构类大图放在/diagrams下。命名用英文小写加中划线避免中文文件名在某些平台出现编码问题。9.3 与 API 文档、接口设计保持同步技术方案评审时最怕的是流程图画了一套代码实现又是另一套。建议在 MR/PR 描述中直接引用流程文件的内容。如果改动涉及核心流程要求提交者同步更新对应.mmd或.drawio文件。这可以作为一种团队规范固定下来。9.4 本地模型与私有化部署的边界很多企业已经把流程图生成对接到了内部大模型服务。这里要提醒的是即使是本地模型也要注意权限边界。不是所有业务人员都应该有权把系统内部流程描述发给同一个模型更不要在生产环境的敏感流程图上附加多余的业务数据。建议将流程描述和业务数据脱敏后输入模型并且对生成结果做二次校对。9.5 自动化脚本辅助如果团队已经部署了本地 AI 服务可以把流程图生成做成一个内部小工具。只需要一个简单的页面输入业务描述调用本地模型生成 Mermaid 代码再调用mmdc渲染图片。这样从描述到图片可以控制在几十秒内而且不依赖外部网络。总的来说这套开源工具链的核心价值不是某一个软件而是一套“描述 - 生成 - 渲染 - 入库 - 协作”的完整工作流。画图不再是一个孤立的环节而是真正嵌入了研发流程。对开发者来说下一步最值得做的不是把市面上所有工具都装一遍而是选一个最贴合自己团队的组合需要拖拽就先上手 Draw.io需要文档嵌入就掌握 Mermaid需要规范建模就研究 PlantUML。再加上 AI 生成能力和动态展示技巧流程图绘制这件事完全可以变成一个高效的工程习惯。