企业官网建设流程全解析

1. 存量空间节能这件事，为什么现在必须换一套打法

做暖通和楼宇自控这行十几年，我最大的感受是：增量市场的红利已经见顶，真正难啃的骨头全在存量空间里。什么叫存量空间？就是那些已经建成、正在运行、但当初设计时压根没把精细化节能当回事的既有建筑——老写字楼、老商场、老酒店、老厂房，甚至一些建成没几年的产业园区。这些空间的共同特点是：设备还在跑，能耗高得离谱，但你要动它，牵一发动全身。

传统节能改造的路子无非两条。一条是换设备，把老机组换成一级能效，把定频泵换成变频泵，把荧光灯换成LED。这条路效果立竿见影，但投入巨大，回收期动辄五到八年，很多业主算完账就摇头。另一条是上自控，装一堆传感器、DDC控制器、BA系统，做定时启停、做简单的PID调节。这条路投入小一些，但问题在于：大部分既有建筑的BA系统要么没联网，要么联了网也没人会用，最后沦为“能看不能控”的摆设。

我见过太多项目，BA系统屏幕上数据跳得挺欢，但冷站该几点开还是几点开，末端该冷该热全凭租户自己拧阀门。为什么？因为传统自控的逻辑是“人告诉它怎么做”，而不是“它自己知道该怎么做”。定时启停的本质是拿昨天的天气赌今天的负荷，PID调节的前提是有人把参数调对了。一旦天气突变、入驻率变化、设备老化，这套逻辑就崩了。

所以当我第一次接触到“拉孚”这套东西的时候，最吸引我的不是它用了什么大模型，而是它把问题重新定义了一遍：存量空间的节能，核心矛盾不是设备不够好，而是空间本身“不会思考”。一栋楼里，哪个区域有人、哪个区域没人、哪个区域人多、哪个区域人少，这些信息在传统自控里是缺失的。你连人在哪都不知道，凭什么谈按需供能？

拉孚的思路是用AIoT物联基座把空间里的“人、机、料、法、环”全部数字化，然后用暖通节能算法和空间认知智能体去接管决策。说白了，就是让建筑自己长出一个“大脑”，这个大脑能感知空间里发生了什么，能预测接下来会发生什么，然后自动调整暖通系统的运行策略。这套逻辑听起来不复杂，但落地的时候涉及的东西非常多：传感器怎么布、数据怎么采、模型怎么训、策略怎么下发、效果怎么验证，每一步都有坑。

这篇文章我打算把这套东西拆开揉碎讲清楚。不管你是做弱电集成的、做暖通运维的、做能源管理的，还是单纯想了解AI怎么在存量空间里落地，都能从里面找到能直接抄作业的东西。我会尽量少讲虚的，多讲我实际踩过的坑和验证过的参数。

2. 从AIoT基座到空间认知，这套架构到底怎么搭

2.1 为什么传统BA系统在存量空间里总是“水土不服”

先说说传统BA系统为什么在存量空间里玩不转。我总结下来有三个死结。

第一个死结是协议碎片化。存量建筑里的设备品牌五花八门，冷机可能是某品牌的，水泵是另一家的，空调箱又是第三家的。BA系统要控这些设备，就得支持各种协议：BACnet、Modbus、LonWorks、KNX，甚至还有一些私有协议。很多老项目的BA系统就是被协议卡死的——想接一个新设备，发现网关不支持，换网关又要动线，一动线就要停业，一停业业主就不干了。

第二个死结是数据孤岛。BA系统只管暖通，门禁系统只管进出，照明系统只管灯，电梯系统只管梯。这些系统之间不互通，导致一个很荒谬的现象：会议室里明明没人，空调还在全速制冷；办公区明明加着班，新风却按周末模式关掉了。数据不通，决策就是瞎猜。

第三个死结是缺乏闭环。传统BA系统的控制逻辑是开环的——设定一个温度，冷机启停，至于实际效果怎么样、能耗是多少、有没有更优解，系统不关心。运维人员只能靠经验去调，调好了是运气，调不好是常态。

拉孚的AIoT物联基座就是冲着这三个死结去的。它的做法是：不管底层是什么协议、什么品牌，先用边缘网关把数据统一采上来，转成标准格式，再往上走。这个思路跟做数据中台是一个道理——先把数据打通，再谈智能。

2.2 AIoT基座的三个核心层：感知、连接、计算

我把拉孚的AIoT基座拆成三层来看，这样更容易理解。

感知层是基础。存量空间里要感知什么？温度、湿度、二氧化碳浓度、PM2.5、光照度、人体存在、门窗开关状态、设备运行状态、电流电压、冷热量。这些参数里，人体存在感知是最关键的，也是最难做的。传统红外传感器只能测“动没动”，人坐着不动它就以为没人。拉孚用的是毫米波雷达加红外双鉴，能测到呼吸级的存在，这个在办公场景里特别重要——程序员坐着写代码两小时不动，红外早就判定无人了，毫米波还能感知到。

连接层是骨架。拉孚用的是边缘计算网关加无线Mesh组网的方案。为什么不用纯有线？因为存量空间布线成本太高，尤其是老建筑，吊顶里全是管线，再穿线根本不现实。无线Mesh的好处是自组网、自修复，一个节点挂了其他节点自动补位。但无线也有坑，后面我会专门讲。

计算层是大脑。边缘网关负责实时性要求高的控制逻辑，比如根据CO2浓度调节新风阀开度，这个必须在本地做，不能等云端。云端负责模型训练、策略优化、跨空间协同。边缘和云端的分工原则是：控制在边缘，优化在云端。这个原则很重要，因为网络延迟是不可控的，但控制指令必须是毫秒级的。

2.3 暖通节能算法：从“定时启停”到“按需供能”

暖通节能算法是拉孚这套体系里最值钱的部分。我把它拆成三个子算法来看。

负荷预测算法解决的是“明天需要多少冷/热量”的问题。传统做法是看天气预报，但天气预报只告诉你室外温度，不告诉你室内负荷。拉孚的做法是融合历史能耗数据、天气预报、日历信息（工作日/周末/节假日）、入驻率数据，用时间序列模型做预测。我实测下来，提前4小时的负荷预测准确率能到85%以上，提前24小时能到75%左右。这个精度已经足够用来做冷机启停计划了。

设备群控算法解决的是“怎么开最省”的问题。一个冷站通常有多台冷机、多台水泵、多台冷却塔。传统做法是轮换运行，或者按固定顺序启停。拉孚的做法是根据预测负荷，用寻优算法找出最优的设备组合。举个例子：假设预测负荷是600冷吨，你有三台300冷吨的冷机，传统做法是开两台，每台负载50%。但寻优算法可能会告诉你：开一台满载加一台半载，或者开两台但调整冷却水温，总能耗更低。这个差异在部分负荷工况下特别明显，我见过一个项目，光是优化冷机组合这一项，冷站能耗就降了12%。

末端调节算法解决的是“每个房间怎么调”的问题。传统做法是每个房间一个温控器，各自为政。拉孚的做法是把末端和冷站联动起来——当多个房间同时要求制冷时，不是简单地把冷机开大，而是先看这些房间的CO2浓度和实际温度，判断是真需求还是传感器误报，然后再决定是调节水阀还是调节风阀。这个逻辑听起来简单，但实际做的时候需要处理很多边界情况，比如会议室突然涌入20个人，负荷瞬间飙升，这时候如果还按常规逻辑慢慢调，人早就热跑了。

2.4 空间认知智能体：让建筑“看懂”人在做什么

空间认知智能体是拉孚这套体系里最新颖的部分。它的核心任务是：通过多模态数据（雷达、摄像头、门禁、WiFi探针、用电数据），推断出空间的使用状态和人的行为模式。

我举几个实际场景。场景一：办公区。智能体通过雷达和WiFi探针发现，某个工位区域连续30分钟只有2个人在，但空调还在按20人的模式运行。智能体就会把这个区域标记为“低 occupancy”，自动调高温度设定值，同时降低新风量。场景二：会议室。智能体通过门禁和雷达发现，会议室预定系统显示“已预定”，但实际没人进入。智能体就会在预定开始15分钟后自动释放空调，避免空吹。场景三：商场。智能体通过WiFi探针和摄像头（做脱敏处理）发现，某个楼层的人流量在下午2点到4点达到峰值，智能体就会提前30分钟预冷，而不是等人多了再降温。

这些场景听起来很美好，但落地的时候有一个关键问题：隐私。用摄像头做人流统计，业主和租户都会有顾虑。拉孚的做法是优先用雷达和WiFi探针，摄像头只做辅助，而且数据在边缘侧就做脱敏处理，不上传原始图像。这个设计在实际推广中非常重要，我见过好几个项目因为隐私问题被租户投诉，最后不得不把摄像头拆了。

2.5 三层架构的协同逻辑：数据往上走，指令往下走

把AIoT基座、暖通算法、空间认知智能体串起来看，整个系统的协同逻辑是这样的：

• 感知层采集数据，通过连接层上传到边缘计算节点。
• 边缘节点做实时预处理，把高频数据降采样，把异常数据剔除，把关键特征提取出来。
• 预处理后的数据上传到云端，云端跑负荷预测和空间认知模型。
• 云端把预测结果和认知结果下发给边缘节点。
• 边缘节点结合本地实时数据，生成具体的控制指令，下发给执行器。
• 执行器动作后，效果数据再次被采集，形成闭环。

这个闭环的周期，实时控制是秒级，策略优化是小时级，模型迭代是周级。不同周期的事情在不同层级做，这样既保证了实时性，又保证了优化效果。

3. 落地实操：从现场勘查到策略下发的完整流程

3.1 现场勘查：别急着上设备，先把这五件事摸清楚

我见过太多项目，方案还没做就先采购设备，结果设备到了现场发现装不了，或者装了没用。存量空间的节能改造，现场勘查至少要做五件事。

第一件：摸清设备台账。冷机是什么品牌、什么型号、哪一年的、有没有变频、有没有通信接口、接口协议是什么。水泵是定频还是变频、有没有备用泵、控制柜里有没有变频器。空调箱是几排管、风机功率多大、有没有变频、水阀和风阀是电动还是手动。这些信息必须一个一个抄下来，不能靠猜。

第二件：摸清管路走向。冷冻水供回水管怎么走的、有没有旁通、有没有平衡阀、分集水器在哪、末端怎么接的。这个决定了你后面能不能做分区控制。如果管路是串联的，你控一个房间会影响另一个房间，那就得先改管路。

第三件：摸清电气管路。控制柜在哪、有没有预留空间、电源容量够不够、通信线怎么走。存量空间最头疼的就是没地方放网关和传感器，吊顶里全是管线，有时候连个下手的地方都没有。

第四件：摸清使用模式。这栋楼几点上班几点下班、周末加不加班、节假日怎么安排、有没有特殊区域（比如数据中心、实验室）需要24小时供冷。这些信息决定了你的控制策略怎么写。

第五件：摸清业主和租户的诉求。业主关心的是能耗降多少、投资回收期多长。租户关心的是舒适度会不会下降、会不会被频繁打扰。这两者的诉求有时候是矛盾的，你得提前找到平衡点。

注意：现场勘查一定要拍照、录像、做笔记，最好用表格把每个设备的信息都记录下来。我吃过亏，勘查的时候觉得记住了，回去写方案的时候发现细节全忘了，又得跑一趟。

3.2 传感器布点：少而精，别为了数据而数据

传感器布点是AIoT基座落地最关键的一步。布多了浪费钱，布少了数据不够用。我的原则是：每个传感器都要有明确的用途，没有用途的传感器一个都不装。

温度传感器：每个空调箱的回风口装一个，每个典型房间装一个。典型房间的选择标准是：朝向不同、楼层不同、使用功能不同。比如东向办公室、西向办公室、南向会议室、北向机房，各选一个。不要每个房间都装，浪费。

CO2传感器：每个会议室装一个，每个开放办公区按每50平米装一个。CO2是判断新风需求最直接的指标，比人数统计还准。

人体存在传感器：每个独立办公室装一个，每个开放办公区按每30平米装一个。用毫米波雷达，不用红外。安装位置要避开金属遮挡，否则雷达波反射会出问题。

冷热量表：冷站总管装一个，每个分区支路装一个。这是算能耗和验证节能效果的基础，不能省。

电表：冷机、水泵、冷却塔、空调箱各装一个。如果预算有限，至少冷站总电表要装。

水阀和风阀执行器：这个不是传感器，但必须和传感器一起考虑。如果原有执行器是手动的，要换成电动的。如果原有执行器是电动的但不支持模拟量控制，也要换。

布点的时候有一个坑：无线信号覆盖。存量空间里钢筋混凝土墙对无线信号衰减很大，尤其是地下室和设备层。我的做法是先用信号测试仪测一遍，把网关和路由器的位置定下来，再布传感器。如果某个区域信号弱，要么加节点，要么改有线。

3.3 边缘网关配置：参数怎么设，逻辑怎么写

边缘网关是本地控制的核心，配置得好不好直接决定系统稳不稳。我以常见的冷站控制为例，讲讲关键参数怎么设。

冷机启停逻辑：不要用固定时间表，要用负荷预测加实际负荷双条件。具体来说，当预测负荷超过当前运行冷机总制冷量的70%时，提前30分钟启动下一台冷机。当实际负荷低于当前运行冷机总制冷量的40%时，延迟30分钟关停一台冷机。这两个阈值是根据冷机部分负荷性能曲线定的，70%左右是效率拐点，40%以下效率下降明显。

水泵变频逻辑：压差控制还是温差控制？我的经验是：一次泵系统用压差控制，二次泵系统用温差控制。压差设定值不要设固定值，要根据末端阀门开度动态调整。当最不利末端阀门开度小于80%时，逐步降低压差设定值，直到阀门开度回到80%以上。这个逻辑叫“变压差控制”，比固定压差节能15%到20%。

冷却塔控制逻辑：冷却塔风机不要一直全速转，要根据冷却水回水温度调。回水温度高于32度时全速，低于28度时停一半风机，中间线性调节。同时要联动冷却水阀，避免冷却水温度过低导致冷机喘振。

新风阀控制逻辑：根据CO2浓度调。CO2低于600ppm时新风阀关到最小（通常20%），600到800ppm时线性开到50%，800到1000ppm时开到80%，超过1000ppm时全开。同时要联动排风机，保持微正压。

这些逻辑写在边缘网关里，用梯形图或者结构化文本都可以。关键是要有手动模式，万一自动逻辑出问题，运维人员能马上切手动，不至于影响使用。

3.4 云端模型训练：数据要多少，特征怎么选

云端模型主要是负荷预测和空间认知。负荷预测模型我一般用LightGBM或者LSTM，空间认知模型用规则引擎加聚类。

数据量要求：负荷预测至少需要一年的历史数据，覆盖春夏秋冬四季和不同使用模式。如果历史数据不足一年，可以用相似建筑的数据做迁移学习，但效果会打折扣。空间认知模型需要至少一个月的雷达和WiFi数据，用来学习正常的使用模式。

特征选择：负荷预测的特征包括室外温度、室外湿度、太阳辐射、风速、星期几、是否节假日、前一天的负荷、前两小时的负荷。空间认知的特征包括雷达点云数量、WiFi连接数、门禁刷卡次数、用电功率。

训练频率：负荷预测模型每周重新训练一次，用最近三个月的数据。空间认知模型每月更新一次规则。

验证方法：用留出法，把最近一个月的数据作为测试集，看预测值和实际值的MAPE（平均绝对百分比误差）。MAPE低于10%算合格，低于5%算优秀。

3.5 策略下发与效果验证：怎么证明真的省了

策略下发不是一劳永逸的，要持续调优。我的做法是：先跑一周基线，记录不控制时的能耗。然后下发策略，再跑一周，对比能耗。如果节能率低于预期，就分析原因，调整参数，再跑一周。

效果验证要注意排除干扰因素。比如天气变化、入驻率变化、设备故障，这些都会影响能耗。我的做法是用“相似日对比法”：找天气条件和使用模式相似的两天，一天有控制一天没控制，对比能耗。如果找不到相似日，就用回归分析，把天气和入驻率作为协变量，看控制策略的净效应。

提示：效果验证至少要做一个月，因为暖通系统的热惯性很大，今天调了参数可能明天才见效。不要看一天的数据就下结论。

4. 踩过的坑和对应的解法

4.1 无线Mesh组网在存量空间里的三个坑

坑一：信号反射导致误报。毫米波雷达在金属吊顶和玻璃幕墙的环境里，信号会多次反射，导致传感器误判有人。我遇到过一个项目，会议室明明没人，雷达一直报有人，空调一直开着。后来把雷达安装位置从吊顶正中央移到角落，并且调整了雷达的探测角度，问题才解决。

坑二：Mesh节点跳数太多导致延迟。无线Mesh每跳一次延迟增加10到20毫秒，如果跳数超过5跳，控制指令的延迟就超过100毫秒，对于实时控制来说太慢了。我的做法是：控制类设备（执行器、网关）尽量用有线或者控制在3跳以内，监测类设备（传感器）可以放宽到5跳。

坑三：2.4G频段拥堵。存量空间里WiFi、蓝牙、ZigBee都在2.4G频段，互相干扰严重。我的做法是：网关和路由器用5G频段回传，传感器用Sub-1G频段（比如LoRa）或者有线。如果只能用2.4G，就要做信道规划，避开拥堵信道。

4.2 冷机群控策略在部分负荷下的震荡问题

冷机群控最容易出的问题是震荡：负荷稍微一波动，冷机就频繁启停。我遇到过一个项目，冷机一小时启停了6次，把业主吓坏了。

原因分析下来有两个：一是负荷预测不准，导致启停阈值设得太敏感。二是冷机启停没有加延时，一达到阈值就动作。

解法是：加死区加延时。具体来说，启动阈值和停止阈值之间要有10%到15%的死区，避免在阈值附近反复触发。同时，冷机启动后至少运行30分钟才能停，停机后至少15分钟才能再启。这两个时间是根据冷机的最小运行时间和最小停机时间定的，不同品牌不一样，要查手册。

4.3 空间认知智能体的误判与人工接管

空间认知智能体最怕的是误判。我遇到过一个案例：智能体通过WiFi探针发现某个区域人很少，就把空调调高了。但实际上那个区域的人用的是有线网络，WiFi探针没探到。结果人热得受不了，投诉到业主那里。

解法是：多源融合加人工确认。不要只依赖一种数据源，雷达、WiFi、门禁、用电数据要综合判断。同时，在系统上线初期，所有自动决策都要经过人工确认才能执行。等模型稳定了，再逐步放开自动执行。

还有一个技巧：设置置信度阈值。当智能体对某个判断的置信度低于80%时，不执行自动控制，而是推送给运维人员确认。这样既避免了误判，又不会让运维人员太累。

4.4 常见问题速查表

4.5 几个我踩过的独家坑

坑一：CO2传感器被空调出风直吹。出风口的CO2浓度接近室外，传感器读数会偏低，导致新风阀开度不足。安装位置要避开出风口，最好在回风口或者房间中部。

坑二：冷热量表装反了。冷热量表有方向性，装反了读数会是负的。安装前一定要确认水流方向，表体上的箭头要和实际水流方向一致。

坑三：边缘网关的时钟没同步。边缘网关如果时钟不准，数据时间戳会乱，云端模型训练会出问题。上线前一定要配置NTP同步，并且定期检查。

坑四：策略下发后没做回归测试。每次调整策略后，要跑至少三天的回归测试，确认没有引入新的问题。我见过一个项目，调了冷机启停阈值后，冷机是不震荡了，但冷却塔风机开始频繁启停，因为冷却水温度波动变大了。

5. 这套东西到底能省多少，以及适合谁用

5.1 节能效果的实测数据

我参与过的几个存量空间改造项目，节能效果大致是这样的：

• 冷站能耗降低15%到25%，具体取决于原有系统的运行水平。如果原来就是粗放式运行，降25%不难。如果原来已经调得不错，降15%就是极限了。
• 末端能耗降低10%到20%，主要来自按需供能和减少空吹。
• 整体暖通能耗降低15%到22%，综合了冷站和末端的节能效果。
• 投资回收期通常在2到4年，取决于项目规模和原有能耗水平。

这些数据是实测的，不是理论值。但我要提醒一句：节能效果和运维水平强相关。如果运维人员不配合，再好的系统也白搭。我见过一个项目，系统装好了，运维人员嫌麻烦，把自动模式关了，全用手动，结果能耗一点没降。

5.2 适合什么类型的存量空间

这套方案最适合的是：

• 办公建筑：使用模式规律， occupancy 变化明显，节能潜力大。
• 商业综合体：人流量大，暖通能耗占比高，按需供能效果明显。
• 酒店：客房 occupancy 变化大，公共区域能耗浪费严重。
• 产业园区：多栋建筑，可以做跨建筑协同优化。

不太适合的是：

• 数据中心：需要24小时恒温恒湿，节能空间有限。
• 医院：有洁净度和压力梯度要求，控制逻辑复杂。
• 工业厂房：工艺用冷用热占主导，暖通节能占比小。

5.3 给不同角色的建议

如果你是业主：先做能源审计，搞清楚能耗花在哪。不要一上来就上系统，先把运行数据摸清楚。找集成商的时候，不要只看报价，要看他们有没有类似项目的落地经验。

如果你是集成商：现场勘查一定要做细，不要凭经验估。传感器布点宁少勿滥，每个点都要有明确用途。边缘网关的逻辑要写清楚，并且留手动接口。

如果你是运维人员：系统上线后，前三个月要密切跟踪，发现问题及时反馈。不要觉得自动模式就万事大吉，定期巡检还是必要的。

如果你是算法工程师：不要迷信大模型，暖通领域的负荷预测用传统机器学习就够了。关键是特征工程和数据质量，模型本身反而没那么重要。

5.4 后续可以扩展的方向

这套体系跑通之后，可以往几个方向扩展。一是需求响应：当电网发出削峰信号时，自动调整暖通负荷，参与需求响应市场。二是碳管理：把能耗数据转换成碳排放数据，做碳盘查和碳交易。三是预测性维护：通过设备运行数据预测故障，提前安排维修。

我个人最看好的是需求响应，因为这是政策驱动加市场驱动双重利好的方向。但前提是暖通系统要有足够的调节灵活性，而这正是拉孚这套体系能提供的。

最后分享一个小技巧：系统上线初期，不要追求全自动。先跑半自动，让运维人员参与决策，等他们信任系统了，再逐步放开。我见过太多项目，一上来就全自动，结果出了几次误判，运维人员直接把系统关了，再也不用了。信任是一点一点建立的，急不得。