1. 这次交流的缘起AI公司与建设企业的对话动因1.1 建筑行业的AI应用需求比想象中更具体范式智能和中建方程坐到一张桌子前主题就四个字AI赋能。但真正聊起来才发现双方对“赋能”两个字的理解从一开始就不在一个频道上。AI公司习惯谈模型能力、Agent架构、推理成本建设企业关心的是图纸审查怎么少漏一条强条、会议纪要谁整理、能耗异常什么时候能被发现。这种错位恰恰是行业交流最有价值的地方——技术语言翻译成业务语言之后问题清单变得异常清晰。中建方程这类做城市综合开发和绿色建筑运营的企业业务链条覆盖了规划设计、施工建设、园区运营、资产管理的全生命周期。全链条跑下来数字化系统其实已经建了不少OA审批、项目管理系统、BIM平台、物联网能耗监测一个都不缺。但系统之间数据是断的数据质量参差不齐大量需要专业判断的工作仍然完全依赖人工。设计院出图之后审图工程师要逐条对照几百页规范项目经理开完周会纪要整理、任务派发、跟踪闭环全靠助理手工处理运营团队每天面对能耗大屏上跳动的数字异常是否该处理、从哪开始排查还是靠老师傅经验。这些场景都有一个共同特征工作量大、重复性高、依赖专业经验但又不至于复杂到必须由人来全流程决策。放在两年前这类需求只能靠规则引擎和人工写死流程来解决效果有限维护成本还高。大模型出现之后自然语言理解、长文档解析、多模态识别这些能力直接把门槛拉低了一个量级。建设行业的信息化部门大多已经在观望真正缺的是有人把“大模型能干什么”翻译成“我们这条业务线该怎么用”。1.2 双方卡位的差异与合作共识范式智能这家公司的技术栈放在当下算是比较完整的大模型底座训练与微调、检索增强生成RAG、AI Agent编排、私有化部署都有成熟的工程经验。中建方程在行业侧的优势则是场景明确、数据真实、业务专家充足。双方合作探讨的基础本质上是把“AI公司缺行业know-how”和“建设企业缺AI工程化能力”这两个问题一次性对齐。交流中有一个共识来得很快先别谈宏大叙事直接拿两三个业务场景做试点把数据、模型、流程跑通再决定是否扩大范围。这个共识背后其实是教训换来的。前几年建筑行业上过一批“智慧工地”“AI安全识别”项目PPT阶段说得天花乱坠真上线之后发现算法准确率撑不起现场使用摄像头装了上千路真正能自动告警、且告警有人跟进的寥寥无几。行业对技术供应商的信任度被打折过所以这次交流刻意避开了画饼式的展望把讨论重心放在“哪些场景在3个月内能见到效果”上。技术方和业务方面对面交流还有一个好处AI公司能直接听到一线业务专家的质疑而不是通过售前调研问卷间接获取信息。比如业务侧提到“AI生成的会议纪要能不能直接进OA系统”的时候技术侧的直觉是关注接口格式和权限控制业务侧问“能耗异常报告里的建议能不能带参考依据”的时候技术侧意识到RAG的引用溯源在这个行业不是加分项而是底线要求。这种碰撞是坐在办公室看需求文档永远无法替代的。2. 交流中浮出的三个高价值业务场景2.1 设计阶段规范审查与方案知识检索设计阶段的规范符合性审查是整个建设行业公认的痛中之痛。一个中型项目的施工图随便就是几百上千张涉及建筑、结构、给排水、电气、暖通多个专业。审图工程师需要对照《建筑设计防火规范》《民用建筑设计统一标准》等一堆国标、行标、地标逐条核查劳动强度极大而且强条漏审的后果谁都担不起。传统软件在这个环节帮不上太多忙市面上的审图工具大多基于规则引擎只覆盖部分可结构化表达的条款面对“楼梯间自然通风面积是否满足要求”“疏散门开启方向是否正确”这类需要综合判断的条文规则引擎基本无能为力。大模型的优势在于可以把规范条文、图示、历史审查意见统一转化为可检索的知识库审图人员用自然语言描述一个场景系统直接返回相关条文和相似案例。交流中技术团队明确说了可以做到什么程度规范化文本解析、条文间逻辑关联、基于语义的检索都能在现有大模型能力之上实现但完全自动的强条审查短期内不现实。图纸是多模态信息DWG矢量图形里的构件关系、标注尺寸要精准识别需要专门的视觉模型配合不是通用大模型直接能解决的。双方比较务实的共识是分两步走先做面向审图人员的“规范智能问答条文定位”把查规范的时间压缩掉大部分再看图纸识别模型的成熟度逐步切入半自动审查。这个场景里还有一个隐性的价值知识沉淀。设计院和建设单位的资深工程师脑子里装着大量经验人走了经验就带走了。把规范、图纸、审查意见、变更记录组织成大模型可检索的企业知识库本身就是一种资产化。聊到这里业务侧的人明显眼睛亮了技术交流一旦触碰到组织痛点推进意愿自然就上来了。2.2 施工阶段会议纪要、隐患流转与进度预警施工阶段的场景是交流中讨论最热烈的一块因为痛点足够普遍、足够高频。每个施工项目每周都有例会、专题会、监理会一场两小时会议下来纪要整理要花半天重点事项的跟踪落实又没有闭环工具经常是会上说得好好的下次会对进度才发现没人跟进。会议纪要这个场景对AI来说是典型的舒适区。语音转写、说话人分离、要点提取、任务识别这几项技术已经相当成熟。项目方提了一个很实际的诉求纪要不能只是文本摘要还要能自动识别出“责任人”“截止时间”“事项类型”直接结构化输出到项目管理系统里生成待办任务。这就要求大模型不止做生成还要做信息抽取和字段映射同时要和现有OA系统打通接口。范式智能这边给的方案是用Agent编排来完成整个流程录音文件上传触发转写转写文本进入信息抽取模型抽取结果经过规则校验后生成结构化任务再通过API写入项目管理系统。这套流程技术含量不在单个模型而在于把多个模型和外部系统串成一条可靠的流水线。安全隐患整改是另一个讨论得很细的点。现场安全员发现隐患之后要拍照、填写隐患单、判定等级、指派整改责任人、复查销项。整个流程如果能在移动端实现“拍一张照AI自动识别隐患类型、生成整改建议、匹配责任人”现场的配合意愿会大幅提高。技术侧也坦诚说明了边界隐患类型自动分类的准确率依赖训练数据的覆盖度早期需要人工确认后再积累反馈数据属于“越用越准”的渐进式落地。进度预警这个方向上双方都保持了谨慎。建设项目工期延误的原因高度复杂天气、资金、分包队伍、材料到场、设计变更多种因素交织大模型基于历史数据的预测精度短期内很难达到可以完全信任的程度。更适合的定位是“异常识别风险提醒”让模型学习项目计划与实际情况的匹配度当实际进度与计划偏差超过阈值时自动关联可能的致因比如连续雨天、材料到场延迟生成风险提示供项目经理参考。这类半自动决策支持系统不需要极高的绝对准确率只要能帮助管理者早点发现问题价值就成立了。2.3 运营阶段能耗分析与碳数据管理绿色建筑运营是这家企业比较核心的板块之一商业办公楼、产业园区、保障房社区哪个业态都绕不开能耗。运营团队的日常工作之一就是盯能耗数据、写分析报表、做节能诊断听起来不复杂实际干起来非常琐碎。一栋楼的能耗数据按小时采集一个月几千上万条记录异常波动要靠人眼去看曲线月度能耗分析报告几百页模板固定但每段都需要结合天气、入住率、设备运行策略做解释写起来相当耗时。大模型在能耗场景里的角色不是计算引擎而是数据分析助手。计算结果还是由传统算法和规则引擎来保证精度大模型负责解读把结构化数据变成自然语言结论把异常波动关联到可能的原因把月度报告从“数据罗列”升级成“结论依据建议”。实测下来这类任务的输出质量和数据工程的精细程度直接挂钩只要数据治理做得干净报告结构化程度高大模型的生成效果会明显好过通用场景。碳排放管理近期在行业里越来越受重视企业要编碳排放报告、要做配额履约分析数据口径多、计算规则复杂。范式智能这边提出一个很实际的做法把碳核算方法和排放因子等知识库里沉淀下来用RAG方案做一个碳管理问答助手。业务人员报一个活动数据系统直接关联到对应排放因子、自动计算隐含碳排放并给出计算依据来源。这个方案的好处是落地周期短、不依赖大量历史数据既有直接的生产力价值又能作为AI能力的展示窗口。运营场景还有一个容易被忽略的加分项用户体验极佳。相比设计、施工环节的使用者需要适应新工作流运营侧的月报自动生成、异常原因主动推送属于“做了就比不做好”的体验业务人员几乎没有学习成本。这类quick win项目不会给团队带来任何阻力很适合作为整个合作的破冰试点。3. 技术侧讨论模型、Agent与工程化落地3.1 大模型底座怎么选私有化部署是行业底线交流进入技术环节之后第一个被抛上台面的问题是“模型底座用什么”。这个问题的背后是建筑类企业对数据安全和合规性的高度敏感。设计图纸、合同文本、人员信息、能耗数据这些数据一旦出域风险完全是企业无法承受的。办公室里的讨论没有悬念地收敛到同一个结论数据不出域是前提私有化部署是底线不能在这个问题上留任何模糊空间。当前主流的技术路线里可供选择的方案大致分三类各有各的适用条件方案类型优势劣势适用场景公有云API调用模型能力最强、迭代最快、接入简单数据出域合规风险高非敏感数据的内部探索开源模型私有化部署数据完全自主可控、可深度定制需要算力投入、模型能力弱于顶级闭源企业和行业合作的主流选择混合架构任务分流敏感数据走本地非敏感走云架构复杂、链路跨域难维护数据分级明确的成熟体系从算力资源角度算一笔账一个企业内部知识库问答类应用7B到14B参数规模的量化模型配合一张24G显存的消费级显卡就能跑起来如果要做长文档深度解析、复杂Agent推理32G~80G显存的服务器级别配置会更稳妥。模型推理本身不是成本大头真正吃算力的是微调和向量化检索。所以在落地初期把模型规模控制在够用水平、把资源投入到数据治理和检索效果优化上往往是ROI最高的选择。关于模型能力交流中也实事求是地做了预期管理。开源底座在通用知识问答、文本摘要、信息抽取上的表现已经相当可用但在处理建筑设计规范这类专业内容时直接依赖模型内置知识是不够的必须叠加检索增强RAG来补充领域知识。建筑行业的标准条款表述严谨、关联复杂同一个“防火分区”概念在不同规范里会有不同定义和计算口径RAG结合规则引擎做约束才能保证答案的质量。3.2 为什么聊到Agent架构单点工具解决不了闭环问题交流会进行到一半双方话题自然转向了“Agent”这个词。原因很简单甲方真实的工作流从来不是单点问答而是一串连续动作。运营人员遇到能耗异常要查历史数据、对比同类型楼宇、定位可能故障设备、生成报告、派发工单五个步骤跨了三个系统工程师要查一条规范查完还要看历史审查意见、找类似项目做法、确认适用范围最后写进审查意见。这种多步骤、跨系统、需要决策的任务恰好多智能体协作能接得住的活。Agent架构的核心不复杂本质上是让大模型扮演一个“调度大脑”接到用户请求后拆解成子任务清单按依赖顺序调用不同工具数据库查询、文档检索、API调用、代码执行等结果返回后汇总推理、生成最终输出。相比单模型应用Agent的优势在于任务边界清晰、每一步可审计、效果可定位。出了问题能查到是哪一步的工具调用失败还是哪一步的推理逻辑出错而不是丢给用户一个不可解释的错误答案。交流中技术团队给了一个多AI协作的具体设计示例。以能耗异常分析为例系统内置了三个Agent数据查询Agent负责从时序数据库取数分析Agent负责比对基线和判定异常报告Agent负责把结果组织成自然语言报告。三个Agent共享上下文状态由调度模块统一编排业务用户全程无感只看到最终报告。这个架构里最要紧的是把“分析Agent”的判定规则写清楚不能完全交给模型自发挥否则同样的数据今天说是异常、明天说正常业务侧就不可能信任系统。说到Agent的可控性工程实现里有几个坑值得记录。第一是拆解任务时不能让模型凭空编造工具名称工具列表必须从注册中心动态加载模型只能在可选范围里做选择第二是每一步工具调用都要有超时和重试机制某一步调用失败不应让整个流程卡死而是应该降级到人工介入第三是上下文管理多步骤任务会产生大量中间结果不做剪枝的话提示词很快会超出窗口限制导致推理质量下降。这些细节听着琐碎但项目上线之后真正决定稳定性的恰恰是这些不起眼的工程处理。3.3 数据工程与权限安全决定AI项目生死的地基讨论技术方案时范式智能这边反复强调了一个观点模型只决定效果上限数据工程决定效果下限。建筑企业的数据现状不会太乐观图纸躺在CAD里、文档散落在个人电脑和OA里、能耗数据堆在物联网平台里字段口径不统一、质量参差不齐。这类数据直接拿去喂模型效果必然是灾难性的。RAG系统的效果很大程度上取决于知识库的切分策略和索引质量。规范条文切得太碎语义断裂检索结果缺乏上下文切得太粗向量相似度区分度下降命中精度变差。实操中通常会用“标题层级条款编号语义段落”的混合切分策略再对关键实体做标注生成高质量的embedding。这个过程在项目里占用的时间往往超过模型调优本身但这是躲不掉的功课。权限问题是建设行业特别在意的点。合同文件、内部成本数据、项目能耗数据不同角色能看到的数据范围完全不一样。AI系统如果只做统一知识库不做权限隔离上线当天就会被安全部门叫停。实现方式上可以在索引层做权限标记——每个知识块带上可见角色列表检索时用角色信息过滤候选集也可以在模型层控制输入输出——敏感字段脱敏后再进模型。两层同时做效果最好检索层保证数据不出错模型层保证生成内容本身不泄露敏感信息。幻觉问题在工程行业是绝对红线。大模型生成的答案哪怕偶尔出错在工程建设这种容错率极低的环境里也是不可接受的。实操层面的解决方案就是强制引用溯源系统只允许基于检索到的原文生成答案模型生成时必须携带来源片段编号用户点击编号就能回溯到原始规范条文或报告原文。这种做法牺牲了一部分流畅度但换来了可复核性恰恰是工程场景最需要的。4. 现场碰撞出的问题与落地思考4.1 甲方最关心的问题投入产出怎么算业务侧在交流中问了一个很尖锐也很实际的问题这套AI系统到底能省多少钱、省多少人力技术公司在台上讲部署方案的时候甲方财务和项目负责人脑子里同步在算的都是账。这个问题绕不开越早面对越好。我的看法是第一波AI试点项目不应该选动辄影响生产安全的大场景而要选人工成本最重、效果最容易量化的重复性工作。以会议纪要场景举例一个大型施工项目每周产生3~5场会议录音每场录音整理纪要需要助理半天时间。引入AI纪要系统之后整理时间压缩到半小时以内且结构化程度更高这个效率提升是立刻看得见的。按一个项目组一年几百场会议计算省下来的工时完全可以直接换算成人力成本节约。能耗分析报告的自动化同理。运营人员花一周时间写一份月度报告AI辅助之后一天能出初稿人工只需要做复核和补充。这类场景的ROI不是算出来的是实测出来的。交流会现场的氛围变化很有意思当技术方案落到“你原来花三个小时查规范现在三分钟得到答案且附出处”这种具体表述时业务侧的信任感明显增强。所以对AI公司来说真正要讲的不是算法榜单上的数字而是业务人员每天多出来的时间能用在哪里。4.2 可能先落的三个试点项目结合双方的能力基础和数据现状交流后半段基本收敛到三个可以快速启动的试点方向。第一个是内部知识库智能问答。把企业多年积累的制度文件、标准规范、项目经验整理成知识库内部人员通过对话即可获取答案。这个试点见效最快不依赖复杂系统集成1个月左右能上线最大的价值在于让企业上下直观感受到AI带来的基础体验提升相当于一个面向全员的“技术启蒙”。第二个是施工项目会议纪要与任务结构化。选1~2个在建项目作为试点打通录音转写、纪要生成、任务抽取到项目管理系统闭环目标是把项目周会从“开会2小时整理半天”压缩成“开会2小时整理半小时”。这个试点对系统集成能力有要求但技术成熟度已经很高效果可量化适合作为第二个里程碑。第三个是能耗异常分析与数字化报告。对接一个园区或楼宇的能耗监测系统用AI辅助生成能耗周报、月报并对异常指标给出原因排查建议。试点的核心产出是“AI生成报告人工复核”的协同工作流通过实际运行验证报告质量和业务侧的认可度。三个试点放在一起覆盖了从“通用能力体验”到“业务流程改造”再到“行业专业场景”的三个层级递进关系清楚风险和投入都能控制在可接受范围内。交流中双方也约定试点不追求模型参数的大而全先把每个场景做成业务侧愿意每天打开的项目再做复制推广。4.3 落地节奏与组织保障真正的难点不在技术探讨到最后所有人的共识都是AI项目的成败技术只占三成剩下七成在数据、组织和流程。很多企业技术选型选得很好、模型效果也不错最后死在没人推、数据不通、业务不配合这“三座大山”上。组织保障方面成立联合工作组是必须的。AI公司出模型专家和工程实施企业方出业务专家和数据接口负责人每周固定对齐一次。业务专家的核心任务不是给技术团队提需求而是在试点过程中持续验证输出质量指出哪些答案是实际业务中不能用的、哪些表达方式和行业习惯不一致。只有业务专家深度参与AI系统才能从“技术演示品”长成“生产力工具”。数据治理工作要前置。试点启动前就要盘点数据源文档在哪、格式是什么、权限归谁、有没有电子化。建筑行业很多流程性文档的电子化程度其实不高该补的补、该清的清、该归集的归集这是绕不过去的工作量。验收标准也要一开始就定清楚。不要用“效果不错”“感觉挺好”这种模糊标准建议直接拆解成可量化指标会议纪要的信息完整率、任务识别的准确率、人工复核通过率、报告生成的耗时对比。定清楚指标还有一个好处双方在合作过程中把精力放在指标优化上而不是反复讨论观感上的好坏扯皮成本会低很多。写在最后一点现场的体会交流会结束收拾投影设备的时候我脑子里跳出一个很直白的感受建筑行业的AI落地本质上是一个翻译问题。AI公司的工程师需要把“Agent编排”“意图识别”“RAG召回精度”翻译成“会议纪要多快能出”“规范查得准不准”“报告的结论有没有依据”企业的业务骨干也需要把“审图工作量”“能耗排查逻辑”“变更管理痛点”说成技术听得懂、能转成方案的清晰需求。哪一方的翻译能力强合作的推进速度就会快一些。另外一点体会是这类行业共探式的交流最忌讳的就是谈战略、谈愿景、谈“AI将彻底改变行业”。这种话对前台演讲有用对决定下一步合作方向没有意义。真正有效的沟通方式是现场把痛点列在桌面上拿数据说话拿场景说事能用几个月内看到的成效来验证的才值得双方投入资源。对未来合作的推进来说与其铺开一大堆可能性不如稳稳扎下第一个桩——让AI在建筑行业里的第一个应用真正被业务人员高频使用起来这种实实在在的牵引力会比任何规划都有说服力。