施工图不能出错,但AI大模型有幻觉,怎么办!

过去两年，大语言模型在写作、编程、问答等领域进步飞快。但到了建筑设计领域，AI却始终“用不起来”——能聊天，却改不了一张图；能答规范，却判不了一条疏散距离。

同样是AI，为什么在语言领域一路突破，到了建筑设计领域就卡住了？

卡住的主要是三件事：

第一，图纸里的空间关系，AI对不上。平面图中的两条线，和立剖面里的两条线，指向的是同一片墙。AI能识别线段，却建立不了这种对应关系。

第二，规范里的隐性推理，AI推不出。规范写的是专有名词，AI读得懂字面语义，却关联不到空间，也就做不了判断。比如疏散距离是否满足——设计师结合规范、图集和经验很快能判断；AI却没法对着图纸上那几条线、那几个字，分辨出这一条走廊里哪一段算袋形走道、哪一段算“位于两个安全出口之间”。

第三，建筑元素的深层嵌套，AI遍历不准。以IFC为代表的建筑数据标准包含多层嵌套：构件隶属空间，空间隶属楼层，楼层隶属建筑。程序可逐层精确遍历，不漏也不重；但AI在自然语言体系里靠的是语义相似度，能猜个大概，却做不了这种精确遍历——差一层，结果就全错了。

广联达数维走的是三维技术路线，从源头避开“识图”这一最难障碍，把资源集中到后两项。而后两项看似独立，实则同源——建筑行业的数据与知识表达方式，并非为AI设计——数维给出的解法也很明确：把建筑行业现有的数据和知识表达方式，重构为AI可读取的形式。

数维即将发布的AI平台，包含知识库与AI助手两部分。

知识库要做两件事：一是让AI准确理解建筑行业知识，二是理解数维的每一个构件与接口。

AI助手则负责执行：以自然语言下达指令，AI依据知识库生成代码，输出结果。

落到具体流程上就是：用户用自然语言提需求，AI助手先去知识库查清楚这是什么意思，再把需求翻译成系统能懂的对象，然后让大模型生成C#插件代码，最后在数维里运行起来。

知识库里有什么？一句话总结就是：知识库用实体、属性、关系、操作将建筑行业知识完整结构化。它从上到下分五层：行业业务层（规范/行业经验）、数维使用层（业务概念，如封闭楼梯间）、数维系统层（软件层面可执行的对象，如房间、门及其属性、关系、操作）、API映射层（负责把系统层对象对应到具体API）、API层（提供API接口说明和示例代码）。

所以，知识库让AI不是“猜”，而是“查得到、推得出、算得准”。

知识库为AI提供可计算、可消歧、可遍历的工程语义底座

前面讲的是底座和方法，这部分我们以一个真实需求——“在指定疏散位置上方布置安全指示灯”——把整条链路串起来。

第一步：在AI助手中输入需求

用户在“AI助手”中输入一段自然语言，内容是关于安全指示灯布置位置的要求：

“在以下位置布置安全指示灯：1 应设置在敞开楼梯间、封闭楼梯间、防烟楼梯间、防烟楼梯间前室入口的上方；2 应设置在室外疏散楼梯出口的上方；3 应设置在直通室外疏散门的上方；4 在首层采用扩大的封闭楼梯间或防烟楼梯间时，应设置在通向楼梯间疏散门的上方；5 应设置在直通上人屋面、平台、天桥、连廊出口的上方；6 应设置在避难层、避难间、避难走道防烟前室、避难走道入口的上方；7 应设置在观众厅、展览厅、多功能厅和建筑面积大于400m²的营业厅、餐厅、演播厅等人员密集场所疏散门的上方。”

第二步：知识库如何“接住”这个需求

用户输入的不是关键词，而是一段完整的工程语义。

知识库要做的，是把这段话里的每一个业务术语，准确对应到系统层能理解的对象和操作上。

以“封闭楼梯间”这个业务术语为例：在知识库编辑器中，它会被归到系统层的“房间”。在它的“实体定义”中，会引用系统层的实体、属性和关系，比如房间、门、房间名称、防火属性等。这意味着，当用户输入“封闭楼梯间”时，知识库不是靠猜，而是沿着这套结构去匹配、映射，最终落到系统层的实体、属性、关系和操作上。

第三步：需求是如何被逐层翻译的

用户输入需求后，AI助手会调用知识库，把整段话逐词拆开，再逐层映射。

以“在指定疏散位置上方布置安全指示灯”为例：

● 左栏是用户原话，被拆成一个个词元；

● 中栏是每个词对应的非系统层概念；

● 右栏是这些概念最终展开成的系统层对象。

从左到右，就是一次完整的“自然语言 → 系统操作”的翻译。

比如“封闭楼梯间”这个词元，会先映射到使用层概念“封闭楼梯间（uutGnaEnEnclosedStairRoom）”，再沿着知识库展开为系统层的门、房间、房间名称、防火属性、耐火等级等。

“人员密集场所”同理，展开为门、房间、房间名称、面积等。

页面上的连线，就是这些映射的依据：橙色线表示词元到概念，紫色线表示概念到系统层对象。

翻译过程中，并不是每个词都能顺顺利利找到对应概念。这些情况如果直接忽略，翻译结果就会丢信息、埋歧义。

遇到这些情况，AI助手不会直接跳过，而是分别处理。

比如：“应设置在”“的上方”这类词，单独看并没有对应的系统概念，但它们不是被丢掉了，而是被合并进了“布置安全指示灯”这个操作的定义里；

“上方”最终也变成了一个具体操作：把灯放在门框顶部再往上10厘米的位置。

也就是说，这些未成功映射的词元，要么被吸收进操作定义，要么被已有条件覆盖，要么由默认值补全——没有一条语义被悄悄丢掉。

再比如：用户需求中输入“建筑面积大于400m²”。

这句话是直接原样丢给系统，还是要把单位换算一下？

最终AI助手选择换算成mm²单位，因为知识库有明确规定，系统里的面积单位只能是mm²。如果不换算，机器看不懂，所以必须翻译成机器能看懂的“400,000,000mm²”。

AI助手在面对每一个犹豫点时，都会写明备选方案、最终选择和依据。

所以在翻译过程中，哪些地方丢了语义、哪些地方做了判断，全部都有记录、有依据、可回溯。

第四步：生成代码并在数维中运行

需求被翻译、映射、补全之后，会形成完整的提示词，交给大语言模型生成C#插件代码。

代码中会调用数维API，完成诸如：

● 筛选符合条件的所有门；

● 对每扇门创建安全指示灯；

● 获取门外包围盒，计算灯的放置位置；

● 按100mm偏移布置灯...

最终代码在数维中运行，完成安全指示灯的布置。

整个流程总结成一句话：用户输入自然语音 → 知识库提供语义底座 → 翻译并映射成系统层对象 → LLM生成可执行代码 → 在数维中运行。

接下来，这套知识库能做的事，不会只停留在“布置安全指示灯”这一条规范上。它可以沿着三个方向慢慢长大。

第一，从单点操作变成场景包。

今天你让它布安全指示灯，明天它就可以布烟感、喷淋、插座、车位编号。你只要把规则说清楚，它就能在数维里批量执行。设计师不用再一个个点、一个个改，重复劳动会大幅减少。

第二，从内部助手变成开放生态。

知识库不仅能给数维自己的AI助手用，还能导出给第三方工具。导出内容不仅包含结构化的知识库，还会附带对应的skill（技能包）。把这些直接喂给Cursor、Claude、CodeBuddy这类第三方AI编程工具，就能非常快速地开发各种数维插件。以前做插件要懂C#、懂API；以后没有开发背景的设计师，也能自己把想法变成插件。知识库就成了插件生态的种子，数维的能力边界也会被更多用户一起拓宽。

第三，从个人经验变成企业能力。

设计师脑子里的做法、企业自己的设计规则，都可以沉淀进知识库。这些经验不再是散落在个人电脑和图纸里的零碎信息，而是被整理成可查、可调用的结构化数据。

从本体知识库到精确推理，数维AI平台要解决的，不是让模型“更会说话”，而是让工程语义可计算、让推理过程可追溯、让系统执行可信。

这套方法真正想做的，是让AI进入建筑设计的实际流程：它听得懂设计师的工程语言，查得到构件和空间关系，推得出专业判断，最后还能生成可以运行的工具。

对设计师来说，这意味着把重复、繁琐、易错的布置和校验交给AI，自己把精力留给方案判断和设计决策；

对行业来说，规范和经验不再只散落在文档和人脑里，而能沉淀成机器可读、可复用的知识底座。

数维的目标，是让AI从“会答”走向“会做”，从聊天工具变成靠得住的助手。

当知识库覆盖更多构件、规范和场景，AI在建筑行业的价值也会从单点提效，走向全流程的智能设计。

来源：数维房建产品线