一键平面系统图自动生成：数据模型、工作流与拓扑推导实践

居造标注这次上架的一键平面系统图模块，把图纸标注工作流里最靠后的出图环节直接变成了自动操作。熟悉家装水电、建筑机电或室内深化设计的人应该都有体会：平面图上的设备、管线和文字标注都做完之后，还要再手工整理一张系统图。平面图表达的是物体在空间里的位置，系统图表达的却是设备之间的连接关系。只要平面图改过一版，系统图往往要整张重排，错一处就连带错一串。

这里说的“工作流”，不是 Flowable、Camunda 那类审批流程引擎，而是指从底图、平面标注、系统图到审图出图的整条生产链路。一键平面系统图模块的价值，不只在于把线画得整齐，而在于把原本依赖人工经验的整理过程，变成有规律、可校验、可复现的拓扑推导。下面不展开产品界面，而是从工程角度拆解这类模块背后的数据模型、工作流链路、核心算法和排查方法，并给出一套可以本地运行的最小示例。

1. 先理解“一键平面系统图”要解决什么问题

1.1 一个完整的图纸标注工作流，最后一步往往最耗时

先看普通住宅水电图纸的工作流：拿到建筑底图，布置洁具、灯具、插座、空调末端，绘制给水管、排水管、强电回路、弱电线路，然后做文字标注、编号标注、尺寸标注。这些步骤完成之后，还要整理一张给排水系统图或电气系统图，用来表达各设备之间的逻辑关系。

在这个工作流里，平面标注阶段做完，信息实际上已经齐全：哪个设备接哪根管、哪个回路带哪几个插座，平面图上都有。问题在于这些信息散落在坐标和线段里，没有形成结构化的连接关系。过去只能靠人重新读图、归类、画框、连线。图纸一旦修改，设备位置变了、管线改了，系统图就要重新整理。

一键平面系统图模块解决的正是这个环节：把已经存在于标注数据里的信息自动提取、建图、布局并输出。它没有增加新的设计信息，而是把信息从“几何表达”转换成“逻辑表达”。

1.2 平面图和系统图，一个是空间表达，一个是逻辑表达

平面图和系统图的差别可以这样理解：

平面图强调“在哪”，系统图强调“怎么连”。系统图不关心洗手盆距离墙多少毫米，只关心它接的冷热水管从哪里来。这个差异决定了一键生成模块不能靠简单复制平面图再美化，必须有独立的图数据模型。

1.3 一键生成的本质：把几何数据转成图数据，再完成自动布局

从用户视角看是“一键”，从工程视角看其实是四步：解析标注数据、构建拓扑图、自动布局、渲染输出。

• 解析：从图纸文件中读出设备符号、管线线段和文字标注。
• 建图：把设备作为节点，把管线作为边，形成图结构。
• 布局：根据系统类型和连接关系，自动排列节点位置。
• 渲染：按图层、线型、颜色输出为可读的系统图。

整个链路本身就是一条工作流。任何一个环节失败，结果都会表现在最终图纸上。这也是为什么排查问题不能只看渲染结果，要看数据解析和拓扑构建环节是否已经出错。

2. 模块落地前的数据基础：标注对象怎么设计

2.1 设备、管线和连接点，三类对象缺一不可

要支撑自动生成系统图，标注数据至少要能回答三个问题：有什么设备、设备之间怎么连、系统从哪里接入。对应三类核心对象：

• 设备对象：代表洁具、灯具、插座、空调末端、阀门等，是系统图中的节点。
• 管线对象：代表冷热水管、排水管、电回路、弱电线，是系统图中的边。
• 连接点对象：代表给水立管、排水立管、电箱、系统接入口，是系统的边界。

如果一张图纸只标了图块和线，但没有类型、编号、规格这些属性，算法就无法判断这条线是冷水管还是排水管。所以数据模型设计是整个模块能否成立的前提。

2.2 一个可运行的标注数据 JSON 示例

下面用 JSON 描述一层住宅的部分给水标注数据。这个结构不是某款产品的固定格式，而是这类模块通常需要的最小子集，实际项目要按自己的图纸规范扩展。