为什么轨迹会"幽灵跳层"——楼层判定状态机、置信度与跨层防抖的工程设计

一、开篇：一个 0.5 秒的跳变，毁掉一份考勤报表

监控大屏上，一名运维人员上一秒还在 3 楼配电间，下一秒就被标到了 5 楼，两秒后又跳回 3 楼。轨迹回放里，这个人的"层"像抽风一样抖动。把原始数据拉出来看，底层定位并没有出错——蓝牙信标精度 3~5 米这个量级没有崩，气压曲线也在合理范围。问题出在最后一环：楼层判定把带噪声的原始观测直接当成了输出，没有做任何状态管理。

这不是某个厂商的 bug，而是几乎所有楼层定位系统在联调阶段都会撞上的问题。这一篇不聊信标怎么布、气压怎么校，专门聊楼层判定的最后一公里：怎么把一份毛刺丛生的原始楼层序列，治理成一份敢于进报表、进报警、进考勤核算的稳定楼层序列。

二、问题定义：平面是连续的，楼层是离散的

楼层定位和平面定位有一个本质区别：平面坐标是连续量，报偏两米，地图上的点挪两米，视觉上几乎无感；楼层是离散量，只有"对"和"错"两种结果。3 楼判成 5 楼，不是"偏了两层"，而是整个后续逻辑全错——楼层停留统计错了、按楼层配置的签到任务错了、楼内的电子围栏判定也错了。

原始楼层观测从哪来？常见来源有蓝牙信标 RSSI 判层、气压差分判层、Wi-Fi 扫描判层，几类证据各有各的噪声：

• RSSI 判层：人体遮挡让信号强度瞬时下跌十几个 dB 是常态，信标布设在楼梯口附近时，人在楼梯上走，两层的信标轮流"最强"，输出就来回横跳；
• 气压判层：空调启停、开关门的风压、天气变化，都能让气压基准漂出几十帕，折算成高度差就是好几米，恰好卡在楼板高度附近；
• 多源切换：室内外交界处定位方式切换（比如从信标定位切回卫星），切换瞬间楼层数据可能出现短暂空窗或错误值。

如果系统把每次原始观测都直接写入楼层字段，得到的序列就是"3、3、5、3、3、5、5、3"这种毛刺序列。下游每个消费方——轨迹显示、楼层停留统计、围栏引擎——都要各自处理一遍毛刺，口径还不统一。正确做法是在数据管线上设一个统一的楼层判定层：原始观测进来，稳定楼层出去。

还有一个容易被低估的放大效应：毛刺不仅难看，还会在业务侧沉淀成错误的持久化数据。楼层停留统计是按时间段累加的，一次三秒的假跳层，会把这三秒计进错误楼层的停留时长，日积月累，统计报表里就会出现"有人在 5 楼累计停留了四十七分钟，但查轨迹谁也想不起来他什么时候去过"这类说不清的数据。更麻烦的是报警类消费方：如果按楼层触发的告警逻辑直接吃原始序列，一次误跳就是一条误报，误报的清理成本远高于它在定位侧被拦下来的成本。所以说楼层判定层的投入产出比极高——在一处治理，四处受益。

三、技术原理：把楼层当状态，而不是当数值

楼层判定的工程化做法，是把楼层建模成一个有限状态机（FSM）。类比很简单：路口的红绿灯不会因为有一辆车抢行就变色，它只看累计的等待时间是否过阈。楼层状态机同理——单次观测不足以改变楼层，只有证据积累到阈值才切换。

一张拓扑图说清这条链路：原始楼层观测（信标判层、气压判层、签到点证据）先进入滑窗滤波器做去毛刺，再进入置信度累加器，由状态机裁决当前楼层是保持还是切换，最终输出唯一一份带时间戳的稳定楼层序列，供轨迹、统计、围栏、报警共用。

状态机内部通常有三个状态：

• 稳定层（STABLE）：当前楼层可信，输出该楼层；
• 候选层（CANDIDATE）：出现了另一个楼层的观测证据，正在累计置信度；
• 切换中（SWITCHING）：乘电梯、走楼梯过程中，允许短时间内频繁变化，但不落库为"居住楼层"。

三个关键参数控制状态迁移：

1. 连续观测计数 N：候选层需要连续 N 次观测、或滑窗内多数投票支持，才允许迁移。比如滑窗取最近 5 次观测，其中 4 次指向 5 楼，才算有效候选；
2. 驻留时间 T：候选层证据必须持续超过 T 秒。防止人只是路过楼梯口、信号瞬时被 4 楼信标盖过；
3. 滞回区间 H：气压判层时，高度恰好卡在两层楼板之间的过渡带内不切换，必须越过滞回带才判层。滞回带宽度要覆盖气压噪声的典型幅度。

置信度的积累和衰减要成对设计：候选层每获得一次支持证据，置信度加一档；连续若干次观测不再支持，置信度按指数衰减归零。只加不减的状态机会在人员回到原楼层后迟迟不肯切换，表现为"人下楼了，系统说人还在楼上"。

四、方案对比：四种防抖路线怎么选

四条路线不是互斥的。生产系统最常见的组合是：气压和 RSSI 各自先做滑窗滤波，再交给置信度状态机做统一裁决。投票法和滞回法适合作为状态机内部的子模块，而不是替代品。直接输出只应该在调试窗口里出现——如果生产系统还在用它，前面所有定位硬件的投入都会被这最后一环的毛刺抵消。

五、技术细节：三个普通用户看不出来、但决定成败的设计点

第一，强证据直通通道。 状态机防的是弱证据噪声，但有些证据本身就是强判定：NFC 触碰签到点、按楼层配置的签到任务完成记录，都是"人确实在这一层"的硬证据。状态机要为强证据开直通口——一次命中即完成切换，并且反向覆盖正在积累的候选层置信度。没有这条通道，员工刷卡进机房十分钟后，系统可能还报他"切换中"。

第二，电梯例外通道。 电梯是楼层判定最刁钻的场景：轿厢在十几秒内穿越多个楼层，中间楼层根本没人下去，但信标判层会在穿越途中短暂指向 4 楼、5 楼、6 楼。如果状态机老老实实按"连续 N 次观测"处理，轨迹里会出现"人去了 4 楼待了 3 秒又走了"的假停留。处理办法是识别电梯运动模式（加速度计能明显分辨出启动-匀速-制动的三段式特征），进入电梯模式后放宽迁移约束、抑制中间楼层落库，只保留起止两层。这一机制与垂直运动识别（另文详述）配合使用。

第三，跨两层跳变保护。 正常人垂直移动一层需要几十秒到几分钟，如果状态机观测到楼层从 3 楼直接跳到 7 楼且没有任何过渡证据，大概率是信标数据异常或气压基准漂移，而不是人真的瞬移了。这类"物理上不可能的迁移"应该挂起不落库，标记为待核实数据，等下一个稳定证据到达后再回溯裁决。这条规则救过不少现场：某厂区一个信标的楼层号录错了层，靠跨两层跳变保护加报警审计，半天就定位到了问题信标。

踩坑记录：窗长是最大的坑。滑窗取 5 次观测、上报周期 30 秒时，窗长覆盖两分半钟，人在楼层间真实切换后，系统要等两分半才更新——超过这个延迟，按楼层触发的围栏和任务都会"慢半拍"。窗长、上报周期、切换响应需求三者要一起算，而不是拍脑袋定。另一个坑是状态机无持久化：服务重启后状态机从零开始积累置信度，过渡期输出的楼层序列与重启前不衔接，报表上出现一段"层归属不明"的空洞。状态机的当前状态（稳定层、候选层、各自置信度）必须随数据持久化。

参数怎么标，靠现场回放而不是靠公式。 状态机的三组参数（N、T、H）没有解析解可算，靠谱的标定方法是拿历史轨迹回放：挑出包含真实跨层的轨迹段和已知误跳的轨迹段，构成一个回放测试集，然后扫参数——把 N 从 2 扫到 8、T 从 10 秒扫到 120 秒，统计两个指标：误跳拦截率和切换延迟。这两个指标天然互相牵制，参数往严了调拦截率升、延迟涨，往松了调反之。标定的目标不是两个指标同时最优，而是按业务定优先级：考勤统计类场景延迟容忍度高、拦截率优先；按楼层触发任务的场景则要把延迟压住。测试集要覆盖工作日早高峰的电梯密集段和午间的楼梯慢速段，只拿平峰期数据标出来的参数，高峰期一定翻车。

显示层与数据层要共用同一份楼层序列。 现场见过一种荒诞局面：监控大屏显示的楼层经过一套滤波规则，考勤核算走的另一套，两边同一个人同时刻差一层，业务方拿着两份"都对不上"的数据来找定位系统对质。治理规则只应存在一份：状态机输出唯一序列，所有消费方从这里取数。确实有业务需要更激进的实时性（比如秒级的大屏刷新），也应该从状态机的"切换中"状态里取带标注的过渡值，而不是另起炉灶吃原始观测。口径统一这件事，技术上是数据管线设计问题，管理上是责任问题——谁输出楼层字段，谁对它的稳定性负责。

六、局限与边界

状态机只能治抖动，不能治系统性偏差。如果信标楼层号录错、气压基准站搬了位置，状态机会非常"忠实"地把错误楼层稳定地输出出来——治理毛刺的前提是原始证据大体正确，这要求部署期就把信标台账、气压基准、层高配置核清楚。

纯概率的方法在楼梯口两侧天然吃力：人站在 3 楼楼梯口，身体一半暴露在楼梯间，两层的信标证据本来就五五开。这不是状态机能解决的，靠的是部署时把信标避开楼梯口的临界位置，或者干脆把楼梯口当作"切换中"区域单独建模。

另外要明确：状态机增加的是判定的一致性，不提升任何定位精度。信标 3~5 米、Wi-Fi 扫描 5~10 米的量级不会因为状态机而变好，它只是让这个精度水平下的楼层输出"像一个人做出来的判断"，而不是像掷硬币。

七、结论

楼层判定不是一道分类题，而是一个状态管理问题。原始观测带噪声是物理事实，工程的任务是用滑窗、置信度和状态迁移把噪声挡在报表之外，同时为强证据和电梯这类特殊场景留出直通和例外通道。

给读者一个可执行的判断标准：评审任何一套楼层定位方案时，直接问一个问题——"楼层字段是原始观测直出的，还是经过状态机治理的？切换延迟多少秒？" 如果对方答不出切换延迟，或者报表里能看到秒级跳层，说明最后一公里还没做，后面按楼层展开的所有应用都要先打个问号。