ARTICLE · 1159656
一款开源免费工具,涵盖AI识图、算量、项目管理等192项功能
发布时间:2026-10-12 02:06:44 最近访问:2026-10-12 02:06:45
一款开源免费工具,涵盖AI识图、算量、项目管理等192项功能
做工程的人,对下面这个场景应该不陌生:图纸在一个文件夹,工程量在一张表,报价又是一张表,进度计划放在另一套软件里。现场发生了变化,几份资料都要跟着改,最后还要确认大家用的是不是同一个版本。前天,我把一款叫OpenConstructionERP的开源软件下载安装到电脑上。打开之后,最直观的感受是:它想装进去的工程工作,范围相当大。从工程量清单、造价数据库,到 BIM、进度、采购、合同、施工日志,再到质量、安全、交付和 AI 智能体,都能找到对应入口。我们先弄清楚这套软件的整体思路,再通过一个很小的例子,看看它实际怎么工作。一、打开软件,先看到一张工程业务地图
OpenConstructionERP 是一个开源的工程 ERP 项目。可以先把 ERP 理解为:围绕一个项目,把不同岗位需要的业务记录放进同一套系统。项目源码和介绍可在其官方仓库查看:https://github.com/datadrivenconstruction/OpenConstructionERP本机首页显示193 个模块、295 个引导案例,已经加载简体中文和中国建筑数据包。首页还准备了从建立项目、编制估算,到招标、采购、进度和移交的案例入口。这些数字说明它覆盖的范围很广。不过,真正值得看的是:每一个入口对应什么工作,它们之间准备怎么连接。图 1:模块数量按首页显示记录,不代表本期逐一验收了 193 个模块。我把界面入口和官方目录整理成下面这张速览表。完整清单见https://github.com/datadrivenconstruction/OpenConstructionERP/blob/main/MODULES.md。业务板块 | 大致能做什么 | 本期体验程度 |
项目与业务总览 | 建项目、看项目状态,汇集不同业务入口 | 已新建测试项目 |
算量与图纸 | PDF 测量、DWG 算量、工程量记录 | 方向介绍 |
BIM 与模型协同 | 模型查看、构件筛选、数量关联;还设有碰撞、点云、地理信息入口 | 已查看并筛选示例模型 |
造价与资源库 | 检索价格条目、资源目录、组合单价和造价匹配 | 已做中文关键词检索 |
估算与工程量清单 | 清单编辑、数量和价格计算、校验、导入导出;另有概算及估算依据等模块 | 三条清单实测 |
招标、采购与合同 | 招标包、报价比较、采购和分包合同管理 | 已查看招标页面;其余方向介绍 |
进度与资源计划 | 甘特图、施工活动、资源安排和完成进度 | 已查看示例甘特图 |
成本、财务与风险 | 预算、承诺成本、实际支出和预测,配合现金流与风险管理 | 已查看示例 5D 看板 |
变更与索赔 | 记录变更、现场计量、审批及相关证据 | 方向介绍 |
现场管理 | 施工日志、人员工时、设备、材料库存和现场表单 | 已查看示例日志 |
质量与安全 | 检查、整改、缺陷、质量记录和安全事项 | 方向介绍 |
文档与协作 | 文件版本、审批、收发文、会议、技术问询和报审 | 方向介绍 |
报表与分析 | 汇总项目指标、生成报告和管理看板 | 已查看部分看板 |
AI 与搜索 | 清单起草、造价建议、文档分析、项目问答和检索 | 已查看智能体列表,尚未运行 |
碳排放、交付与运维 | 碳与 ESG、移交、资产维护、保修,以及预制、物业等扩展业务 | 方向介绍 |
客户与平台配置 | 客户关系和门户、区域包、权限、模块配置与扩展 | 方向介绍 |
如果从工程工作顺序去理解,它试图组织的是这样一条链:图纸与模型 → 工程量 → 清单与价格 → 招采与合同 → 进度与现场记录 → 成本分析与交付。这条链是理解产品设计的线索。本期实际跑通的是其中的清单部分,跨模块的数据联动还需要逐段验证。二、几个让我想继续往下试的模块
1. BIM:模型旁边,已经摆好了工程量和清单的入口
我打开了软件自带的住宅参考项目,在 BIM 页面加载已有 IFC 示例模型。界面显示71 个构件、2 个楼层、3 个专业;选择 Wall 类别后,可见构件缩小到 3 个。模型能显示,类别筛选也能生效。旁边还放着关联工程量清单、规则和汇总等入口。这种布局让人很自然地继续追问:选中的构件,怎样对应到清单?模型里的数量,能否按项目要求使用?图 2:本次打开的是已经存在的示例模型,完成了显示和类别筛选,尚未验证新模型导入及算量准确性。本地安装包中还显示 RVT、DWG/DXF、DGN 的转换组件未安装,IFC 页面提供备用解析路径。本次没有做测试2. 造价库:数据量可观,关键是找到适合项目的那条数据
进入造价数据库,本地安装包中显示china 标签下显示55,718 条。输入“混凝土”,可以检索到中文条目,列表展示单位、价格以及资源或价格变体信息。图 3:实际操作。列表中的价格未做市场核价,本次三条测试清单也没有套用这些价格。这里值得关注的是条目的组织方式:描述、单位、资源和价格放在一起,后续可以围绕同一条记录继续组价。官方数据说明区分了不同来源,其中ZH_SHANGHAI属于全球基础库翻译并按市场重新定价的目录;目录另列ZH_CHINA为另一来源。两者不能混为一谈,更不能把屏幕上的中文人民币价格直接称为项目所在地的现行定额或信息价。具体来源见https://github.com/datadrivenconstruction/OpenConstructionERP/blob/main/data/catalog/README.md。真正用于项目时,仍然要把工作内容、计量单位、价格时间、地域和费用范围对上。3. 进度与成本:从“多少钱”往“什么时候花、实际花多少”延伸
在住宅示例项目里,我打开了一份已有进度计划。甘特图包含土方、基础、主体、围护和装修等 5 个施工活动,能看到时间安排和完成情况。图 4:示例甘特图,本期没有修改工期、计算关键路径或验证 4D 模型联动。5D 成本页面则把预算、已承诺金额、实际支出和预测放到了一起。施工日志中还能看到按日期组织的天气、人员和设备记录。招标页也给出了从清单组织招标包、收集报价到比较报价的工作路径。这些页面共同提出了一个有价值的问题:前期清单里的计划,能否和后期现场发生的事情持续对照?如果这些关联能在真实项目里稳定工作,少重复录入、少人工拼表,才是这套系统核心中的核心。本次看到了入口和示例,尚未验证完整业务闭环。三、实战:用三条清单跑一个小流程
功能范围看过之后,我们把操作收回来,做一个能检查结果的小实验。我让 Codex 新建了“清单验证演示”项目,选择 China、GB/T (China) 和 CNY,再建立一份清单:001|三条清单的计算与校验。数据刻意保持简单,并给钢筋留一个零单价,观察系统能否发现。清单项 | 单位 | 初始工程量 | 初始单价(元) | 初始合价(元) |
C30 混凝土基础(演示) | m³ | 100 | 500 | 50,000 |
基础模板(演示) | m² | 200 | 80 | 16,000 |
HRB400 钢筋(演示,待补价) | t | 2 | 0 | 0 |
合计 | | | | 66,000 |
数量和单价均为虚构测试值,仅验证操作与算术;未设置税费、管理费等附加费用,也未拆分人工、材料和机械。
清单工具栏有“从 Excel 粘贴”。这次使用制表符分隔的三行数据,先带上“描述、单位、工程量、单价”这些中文表头试了一次。预览出现了一个小问题:表头被当成了第四条清单数据,还提示两个数字单元格无法读取,采用默认值。于是我们在导入前去掉表头,确认预览只剩三条,再执行导入。清单总额显示 66,000 元。这个细节很实用。第一次用导入功能,先拿几行数据检查列顺序、单位和小数,能更早发现格式问题。本次只验证了这种粘贴方式,没有测试整份 Excel 文件导入。进入独立校验页面,选择这份清单,运行“工程量清单质量”规则集。首次结果显示 33 项检查结果,30 项通过、3 项警告、0 项错误。其中一条明确指出:第 03 项需要设置单价。这正是我们留给钢筋的缺口。图 5:首次校验抓到了零单价。页面显示的 94% 是本次规则检查的质量分数,不能解释为“造价准确率 94%”。还需要留意规则的范围:虽然创建项目时选择了 GB/T (China),本次页面实际列出的规则集是通用的“工程量清单质量”。我们验证的是数据检查行为,尚未验证国内计量计价标准的完整适配。
先将钢筋单价从 0 改成 4,000 元/t,钢筋合价变成 8,000 元,总价变为74,000 元。再把混凝土数量从 100 m³ 改为 120 m³,混凝土合价从 50,000 元变成 60,000 元,总价变为84,000 元。图 6:最终结果为 60,000+16,000+8,000=84,000 元。钢筋名称中的“待补价”是测试时写入的描述,补价后没有自动改名。修改完成后,我们再次运行同一校验入口。结果变为 34 项检查结果、32 项通过、2 项警告、0 项错误,缺少单价的提示消失了。成本集中和单价异常提示仍在,需要结合具体工作内容判断。这里没有为了追求满分去改数字。三条虚构清单本来就不足以验证价格是否合理;软件发现异常线索,工程人员再判断其原因,这个分工更有用。最后导出 CSV,核对三行明细以及 Direct Cost、Grand Total 两个汇总行。导出文件中的数量、单价、合价与界面一致,直接费和总额都是84,000 元。这样,这个小流程就完成了:粘贴三条数据 → 发现缺价 → 补齐价格 → 修改数量 → 重新校验 → 导出核对。这一轮证明了我们实际操作的这些步骤能够完成。大批量清单、复杂取费、修订审批和多人同时编辑,还不在本次验证范围内。四、AI 模块值得关注,但这次还没有跑起来
这套软件的 AI 页面,已经把任务分成了不同角色:起草清单、整理清单结构、检查估算、比较单价、分析文档、整理项目情况等。部分智能体卡片还列出了可调用的工具,例如搜索造价库、建议组合单价、起草清单项。图 7:本安装包中明确显示“AI 提供商未配置”,没有运行记录。本期没有配置密钥,也没有执行这些智能体。本次能介绍的是它的任务设计,还不能评价模型输出质量、中文理解能力或实际节省的时间。前面的清单计算和规则校验,也不能写成软件内部 AI 自动完成的成果。不过,这个方向值得继续做实验:如果 AI 能读取项目清单、查询明确来源的价格,再把建议送回可核查的业务记录,工程人员就有机会沿着证据检查它的结果。下一步最值得验证的是:给它一个范围很小、答案可以人工核对的任务,看看它用了哪些数据、改了什么、哪些地方还要人补充。五、体验之后,我怎么看它?
它值得作为工程业务数字化和 AI 应用的实操样本继续研究。一方面,覆盖范围确实很大。造价人员可以从清单和资源库切入,项目管理人员可以从进度、现场和成本切入,做工程 AI 应用的人则可以观察智能体如何嵌入具体业务。另一方面,正式应用还取决于那些很具体的事情:导入自己的图纸能不能成功,数量和价格依据能不能对上,项目要求的标准和输出格式是否适配,跨模块更新是否一致。本次已经遇到了中文表头识别问题,也看到一些中文界面中的英文名称和提示。模型转换组件、AI 服务配置同样需要按实际任务补齐。软件覆盖得广,为我们提供了很多入口;每一个入口能做到什么程度,需要通过具体样本逐步确认。选择三条清单,就是想建立这种写法:讲清软件的整体能力,也留下读者能够复现和核对的小结果。六、后面会沿着这份清单继续走
下一次:从图纸或模型到工程量清单。选一个有人工核对结果的小样本,先验证导入和数量,再尝试关联清单;把格式、转换条件和误差说清楚。再一次:让 AI 参与一次清单检查。在完成必要配置后,围绕缺项、描述或价格依据做一项可复核的任务,记录它引用的数据、提出的建议和人工修改。同时顺着这份清单,进一步观察招采、进度与成本怎样连接。三次的主线很简单:第一期看全景、跑基础;第二次解决数量从哪里来;第三此看 AI 如何参与,以及业务数据怎样往后流转。工程 AI 到底能帮到哪里,就从这些小而具体的工作里,一步一步看。以上,既然看到这里了,如果觉得不错,随手点个赞、在看、转发三连吧,如果想第一时间收到推送,也可以给我个星标⭐~谢谢你看我的文章,我们,下次再见。
我是孟祥和,深耕建筑行业的 AI 创业者,也是建筑数字化、AI 落地一线实践者。目前已推动60 余家建筑企业AI转型落地,后续也会持续输出建筑 AI、Agent、Skill、工程数字化相关落地实操干货。
免费加入建筑行业AI与数字化实践交流群共同交流。