地下车库渗漏多入口事件归并：同一件事别再拆开

这个案例来自 房地产与物业 场景。

地下车库最难缠的一类问题，
就是渗漏。
不是因为没人发现，
而是因为发现它的人太多、入口太散，
最后反而没人把这些信号当成同一件事收起来看。

典型入口通常有：

工程巡检记录
保洁发现地面积水
车主投诉车位顶部滴水
安防夜巡拍到墙面返潮

每条都像一个小问题。
但如果它们其实都指向同一处伸缩缝、同一条排水沟或同一片顶板区域，
那就不是几张零散工单，
而是一件正在扩大的事件。

为什么地库渗漏特别容易被多个入口拆散

这家物业管理的是大型地下车库项目。
车库面积大、分区多、班次多，
渗漏问题会以不同形式被不同角色先看到。

保洁更早感知的是：

地面积水
警示桶频繁摆放

工程看到的是：

管线附近滴水
顶板潮痕

车主感知到的则是：

车位上方滴落
车身受潮

如果这些信息只是各自进各自的入口，
现场就很难意识到：

这些其实可能是同一处问题在不同位置上的表现

原来的处理方式为什么会让问题越修越散

1. 每个入口都只处理自己看到的表象

保洁提清理，
工程提维修，
客服回复投诉。
动作都在做，
但没人把它们收成一条事件链。

2. 位置描述不统一

有人写“B2 北区 12 柱附近”，
有人写“靠 216 车位上方”，
还有人只写“出口转弯处滴水”。
这让同一事件更难被识别。

3. 轻微渗漏容易被当成局部问题

在真正积累到明显影响之前，
系统不会天然提示它在扩大。

改造前的旧流程

flowchart TB
    A[巡检 保洁和车主分别上报渗漏信号] --> B[各入口生成独立记录]
    B --> C[现场分别处理表面现象]
    C --> D[同一根因未被持续归并]
    D --> E[渗漏范围逐步扩大]

派宝怎么把多条“小单”收成一条持续事件

派宝做的不是替工程做防水方案，
而是把多入口里可能属于同一渗漏事件的记录先归并起来。

1. 先对齐对象和位置关系

系统会拉齐：

车位编号
柱位和分区
顶板位置
相邻排水与管线关系

2. 再对齐症状和时间演化

派宝会继续识别：

滴水积水返潮是否属于同一演化链
是否在短期内持续出现
是否在相邻区域重复冒头

3. 让现场从“清一处”转向“看一条线”

真正关键的是，
主管看到的不再只是散落的小问题，
而是一条需要整体判断的事件链。

改造后的流程

flowchart TB
    A[巡检记录 保洁反馈和车主投诉进入系统] --> B[事件归并能力<br/>识别是否属于同一渗漏事件链]
    B --> C[映射关系维护能力<br/>维护位置描述与实际区域对象的对应关系]
    C --> D[风险预警能力<br/>提示渗漏范围扩大或复发趋势]
    D --> E[任务提醒能力<br/>推动工程主管做整体验证]
    E --> F[地库渗漏治理更聚焦]

上线后的变化

连续运行 6 周后，
工程主管最明显的感受是，
一些过去总像“这里一点、那里一点”的地库问题，
终于能被看成同一件持续事件。

以前团队经常忙着：

擦水
摆桶
补一点表层处理

却很难在前期就看见问题是在扩还是在串。
现在归并链一出来，
很多本该更早升级处理的点位会被更早看到。

上线前后对比

对比项	改造前	改造后
同一渗漏问题被拆成多张小单	较多	明显下降
主管人工串联位置和历史记录耗时	很长	缩短约 52%
渗漏扩大后才被整体识别	较多	明显减少
地库渗漏问题连续性可见度	偏弱	明显提升