从二维库存到三维空间智能：无感定位、三维重构与空间计算落地指南

先讲一个在仓库现场发生过很多次的场景。盘点到A区02-03库位，系统显示有35件货，人走到库位跟前，却看到空荡荡的地面。折腾了十几分钟才发现，货被临时挪到了旁边通道的托盘上，而系统里根本没有这个临时库位的记录。这类事以前通常被归结为“现场执行力不够”，但拆开来看，真正的根源是一个结构性问题：物理空间的状态从来没有被系统实时感知。所以我们做仓储信息化的人现在讨论无感定位、三维重构和空间计算，并不仅仅是为了追概念，而是要给仓库补上这条物理感知链路，实现真正的仓库透明化管理——让系统像长了一双眼睛那样，随时知道货在哪、空间能不能用、路径怎么走。这篇文章我不会去罗列厂商的白皮书，而是想从方案拆解和落地取舍的角度，把从二维库存管理走向三维空间智能的过程讲清楚。

1. 为什么库存系统“数据全对”，仓库却仍然是黑盒

1.1 账实相符不等于空间相符

先厘清一个容易混淆的地方。很多管理者理解的精细化，是库存准确率从99%做到99.9%，这当然重要，但它解决的是“账”的问题。传统WMS里记录的库位、数量、批次，属于逻辑空间；而仓库里的货怎么堆、托盘有没有歪、通道口有没有被纸箱堵住，这些属于物理空间。逻辑空间和物理空间不是一回事，账实相符只证明了账本和贴码一致，不能证明物理现场和账本一致。

我见过的典型事故都是这样发生的：二维系统说A库位还有余量，实际上库位上堆着一个外扩的托盘，货根本塞不进去；系统说某巷道可通行，结果退货暂存把巷口堵了一半，叉车到了跟前才知道要绕路。问题不在数据维护的人，而在系统从一开始就没有把物理空间当成数据的一部分。当库存准确率做到足够高之后，再往下抠效率，真正卡的瓶颈已经不是账面，而是空间状态。

这也是为什么二维库存管理会封顶。二维系统从出生那天起就是围绕“记录”设计的，它的数据模型里只有库位编码、库存数量、批次属性，没有长宽高、没有体积、没有空余空间、没有通道状态。而仓库作业本质上是三维空间里的物理移动，一个只记账不感知空间的系统，天花板是明确的。

1.2 信息流断点藏在“人做完事”和“系统记完账”之间

再看信息流。从收货、上架、拣选到盘点，每个环节都是人先动手、再扫码确认，系统按最后一次确认更新账本。只要动作完成和确认动作之间存在时间窗口，账就和现场脱节。更麻烦的是异常作业，比如退货暂存、应急移库、临时拼盘，通常靠口头交代，系统完全不知情。再叠加交接班和夜班，问题只会被放大。

所以从二维库存管理到三维空间智能，本质上是把物理空间的实时状态纳入系统，让账本不再靠一次性确认来保证，而靠持续感知来校正。实现这个目标，正好对应三项技术：无感定位解决“人车货现在在哪”，三维重构解决“仓库这个空间长什么样、哪些区域客观存在”，空间计算解决“面对这些空间占用状态，系统该给什么指令”。三者缺一不可，理解了这个逻辑，再看方案细节会顺很多。

2. 无感定位的选型与部署：把“人车货”变成坐标，但不打扰现场作业

2.1 “无感”为什么是项目成败的第一个分水岭

无感定位这四个字，重点不在定位，在无感。过去仓库里做感知，最常用的手段是扫码和RFID。扫码要求人把枪对准条码扫一下，RFID要求托盘必须经过固定读写通道，本质上都依赖人配合动作。员工一旦忙起来，扫码动作会省略，托盘会图省事绕开通道，只要有一个动作没到位，系统就会漏判。

无感的意思是：工人正常走路、叉车正常干活，系统通过佩戴式标签、车载终端持续采集坐标，全程不需要任何额外动作。第一次给仓库主管演示时，他问得最多的不是精度，而是“这个要不要工人去按什么键”。得到否定答案后，他才愿意往下聊，可见谁都知道作业动作是系统数据质量的最大敌人。

2.2 UWB、蓝牙AOA、视觉定位不是单选而是组合

定位方案目前市场上主流是三类。UWB（超宽带）的精度在10到30厘米，对金属遮挡有一定穿透力，适合叉车和托盘这类移动载体，但基站成本和工程部署复杂度高。蓝牙AOA精度在30厘米到1米，部署比UWB轻很多，适合人员工牌，但多径干扰要花力气处理。视觉定位用摄像头加算法，不需要额外标签，可是对光照和遮挡敏感，且摄像头全天候对着作业区，一线工人普遍有隐私顾虑，需要在方案阶段就评估好。

实际项目里很少只用一种。我的建议是UWB做底座，覆盖高位货架区和叉车作业面，蓝牙或视觉做人员工牌和关键节点复核，RFID保留在出入口做离场确认。别迷信单一技术“一统天下”，仓库环境太复杂，金属货架、钢卷、满托盘货物都会改变信号传播，融合才是常态。

2.3 部署与动作识别：从坐标原料到业务事件

部署有几个容易被忽略的细节。基站高度要超过货架顶部，如果贴着墙根布，高位货架中间就是定位死角；我踩过的坑是在通道两端只放一台，结果巷道中部信号衰减很明显。常规做法是每10到15米网格布点，高位货架区在巷道两端和中部都布置，不要省中间那一个。标签的佩戴位置也要统一，工牌挂胸前比挂在腰侧更可靠，车载标签装在车顶比装在驾驶室效果好一个量级。

定位数据到了系统里，还要做两层加工。第一层是位置融合，把UWB和车载IMU数据用扩展卡尔曼滤波融合，轨迹更平滑，进入柱子阴影区域时靠惯导外推一段时间。第二层是动作识别，用速度阈值判断叉车是移动还是作业状态，用停留时长判断人员是否在做盘点或拣选，用举升传感器判断货叉是否托起或放下。这一层很关键：不要把坐标直接当业务事件用，坐标只是原料，动作才是业务。

定位数据怎么和业务动作挂钩，是很多项目失败的地方。比如上架任务是否完成，不能看标签是否在库位旁边闪了一下——这个信号用来做轨迹追踪可以，用来确认业务动作就会出现大量误判。我的做法是定义一个状态机：任务下发后，叉车位置连续进入目标库位范围、速度持续低于阈值、举升传感器有下降动作，三个条件按顺序满足才算完成。只有位置、速度、动作三要素对齐，事件才会被记到账本上。

3. 三维重构：从激光点云到一块能计算的空间画布

3.1 静态重建与动态感知要分开做

三维重构容易让人误解为所见即所得的数字孪生，实际恰恰相反。仓库场景里，建筑结构和货架布局是静态的，你不需要每秒钟重新扫描一遍；真正需要实时更新的，是这些静态容器里装了什么、剩了多少空间。所以工程上要把三维重构拆成静态重建和动态感知两层，静态重建负责搭骨架，动态感知负责填内容。这样成本可控，数据也更可靠。

静态重建我用激光SLAM扫一遍现场：推着扫描设备从主通道走一圈，单侧巷道按需补充扫描，过程大约需要几个小时。扫描结果是一份点云，刚开始看就是几千万个三维点组成的“烟雾”，颜色和形状都有，但没有语义。要让这份点云能用于计算，必须做语义分割，这一步是整个三维底座的技术含量所在。

3.2 点云语义分割做到什么程度才算“能算”

第一步是地面分割，算法上常用RANSAC平面拟合，把地面和墙壁提取出来，这是去除大量噪点最有效的手段。第二步是立柱、横梁、托盘背靠背这类细长结构的识别，通常用点云聚类加主成分分析，判断对象的朝向和长宽尺寸。第三步是把托盘和货物垛按体素网格聚合成独立对象。这三步做完，货架、隔位、通道、托盘这些对象都带上了自己的边界框，再和业务库位编码做标定。

需要注意的一点是，这一层工作目前还离不开人工抽查，尤其是库位边框和隔位边缘，初期必须人工核对，否则后面空间计算全是错的。供应商不会告诉你这份标定要花多少人力，但做过的都知道，这是整个三维底座的成本大头。

3.3 三维模型能回答哪些二维表格答不了的问题

语义化之后的三维模型才能回答二维表格答不了的问题。我用一个表列出差异：

举个例子，高位货架顶层有一个库位显示“空置率20%”，二维系统会把它纳入可分配空间。但三维模型一看，这个库位顶部是消防管道，距离货架横梁不足70厘米，货物放进去就会顶到管道。这类“看不见的约束”，只有空间建模后才能发现。三维重构做出来之后应该被称为一块能计算的空间画布，而不是一张漂亮的三维截图。

4. 空间计算引擎：让三维空间回答“货在哪、能不能放、怎么走”

4.1 空间计算的本质是空间资源调度

空间计算这个词听起来玄，落到仓库管理其实就是三个问题：当前什么是空、东西该放哪、路该怎么走。三维模型解决“空间长什么样”，无感定位解决“空间里谁在哪”，空间计算则负责把这两类数据变成库存调度和路径决策。

空间计算不是三维可视化。可视化只是把数据渲染出来给人看，而空间计算是要在计算机内部做搜索、做匹配、做约束求解。把仓库里的每个货架、每个库位、每个巷道当作带占用状态的资源，再用算法去分配这些资源，这才叫“算”空间。很多项目挂在“假三维”上，模型做得华丽，但没有一个决策由模型产生，这不算空间智能。

4.2 上架推荐从“看余量”升级到“看匹配”

传统WMS的上架推荐，主要按商品属性、批次、库位余量做静态匹配，执行过程中仍需人员现场复核，因为库里“空”和现场“能放”很可能不一致。三维空间计算加入的关键变量是物理匹配：先把待上架货物在三维空间里用包围盒表达，再去目标库位里检测空余空间是否容纳得下。这里的空余空间不再是百分比，而是实实在在的长宽高体积。

还需要考虑的可选条件有：货物是否超出层高、所在巷道当前有没有临时堆物、叉车是否能完成转向。实现上，库位空余空间和货物包围盒都简化成AABB（轴对齐包围盒），做三层相交检测即可，这个做法简洁高效，工程上很可靠。

我自己还会加一条动态维度：如果接下来两小时有大批入库计划，会把大体积货物往通道口附近的库位预排一下，而不是从入口开始顺序塞满。这一条不是算法复杂度多高，而是空间意识问题，做调度的老师傅都有，系统要把它数据化。

4.3 路径规划与巷道预约：从“凭经验”到“算出来”

路径规划同样用空间计算。传统的拣货路径按库位编号顺序优化，但在中大型仓库里，同一巷道可能同时有多台叉车，临时堆物也会改变通行状态。把三维模型和定位状态叠在一起之后，系统把每种占用状态都变成通行成本，实时计算最优路径，遇到拥堵就自动绕行。我们试点里保留了对讲机，但调度员明显更相信系统的路径建议，因为系统能看到谁在哪个巷道口、哪里被暂存货物挡了一半。

在窄巷道和高位货架库，还可以做空间预约：系统给一个任务分配了巷道时段，同一时段内不再派其他大设备进入。这项功能单独看不大，却解决了叉车对头堵巷最头疼的问题。这一层能跑通，才算真正实现标题里说的“控得住”。

5. 多源数据时空对齐：空间ID与业务账本拼接的关键工程

5.1 先建空间ID体系，再谈坐标转换

三项技术单独看都能跑，真正让项目变复杂的是工程集成。定位输出的是以基站为原点建立的物理坐标，三维模型有自己的建模坐标系，WMS里则是业务库位编码。这三套体系如果不打通，系统就会变成三个各说各话的黑盒。

我的做法是先建立一套空间ID字典。给每个货架、每个库位、每条巷道分配一个全局唯一的空间ID，记录它的几何边界、类型、关联的WMS库位编码。定位数据和三维模型都通过空间ID挂接，业务系统只认WMS编码。空间ID表可以简单理解成一张翻译映射表，示例结构如下：

json复制{
  "space_id": "A-02-03",
  "geometry_type": "slot",
  "boundary_points": [],
  "wms_code": "SHELF-A-02-LAYER-3"
}

注意不要让业务系统直接存坐标，这很重要。三维模型重新扫描、坐标系微调后，空间ID的几何描述可以更新，业务编码不需要动。如果业务系统里存的是十年前那套坐标，三维模型一更新就全乱套了。

5.2 用事件状态机替代单帧判断

时间对齐方面，定位数据通常是高频流，每秒十来个坐标点，而业务事件是低频离散的。最直接的做法就是写事件状态机。比如一个上架任务从下发到完成，至少要经过：任务下发、设备到达目标库位、货叉举升、货叉下降、离开库位范围五个状态。每个状态的切换都需要连续多帧数据验证。我给团队定的硬性要求是，任何状态切换不能由单帧坐标触发，否则一个漂移点就能把账记到隔壁库位。这条规则帮我们挡住过不少看起来很离奇的异常。

5.3 三个影响整体成败的小坑

坑一：感知数据不能直接判“空”。高位货架下层被上层货物遮挡，点云和定位都可能看不见它，系统经常把它当空库位。解决的办法也很简单：逻辑空必须由任务完成事件来确认，感知数据只能更新“未确认占用”。

坑二：定位漂移导致跨库位记账。叉车标签在目标库位边缘抖动了一下，系统就认为任务完成。解决方法是连续停留加动作特征双重确认，比如必须连续两秒以上停在目标库位范围且货叉有下降动作。

坑三：模型更新后忘记全局配准。仓库改造后重扫部分区域，如果只替换局部模型而没有把扫描坐标系配准到原全局坐标系，会出现两段模型对不上，整个空间ID字典失效。重扫之后的第一件事，是抽查重要库位边框的坐标偏移，确认之后再发布给业务系统使用。

6. 透明化之后仓库多了什么：试点观察与入场路径

6.1 试点分区看到的实际变化

这套体系到底值不值，得看试点。我在某配送中心挑了一个高位货架分区做透明化改造。选这个区的原因很简单：它是每轮盘点耗时最多、找货投诉最多、复核工作量最大的地方。

没有做全仓铺开。我观察到一个有意思的变化：一线作业人员从“被系统监控”的不安，逐渐变成“用系统省事”的主动，因为他们发现系统能把找货位置标出来，省掉了反复跑空路。仓库管理者的变化更直接——以前开会对库存问题靠争辩，现在打开三维视图，每个库位的物理状态和账本状态摆在那里，讨论的是怎么处理，而不是是不是真的。

6.2 落地路径：先打空间底座，再走单点切入

给准备做的同行三点建议。第一，先选一个单点场景切入，把“盘点前找货”或者“上架前库位复核”这种高频痛点做透，不要一上来就铺一个巨大的系统。第二，在投入定位硬件之前，先把空间ID字典和三维模型建好，模型是底座，底座歪了上层全白做。第三，第一版一定要保留人工确认按钮，系统给出推荐，人授权通过，既降低一线对系统的抗拒，也顺便积累标注数据，用来校准后续算法。

6.3 两个容易“翻车”的认知

还有两个认知要纠偏。透明化不是仓库大屏上的动画模型，如果没有空间计算在后面做调度决策，那张三维图就只是一个装饰。定位精度不是越高越好，真正重要的是覆盖连续性，以及在不那么理想的环境下能不能平滑外推。有些供应商跟我们对比参数，我反而更关心它们把标签装到叉车后、走过一整排金属货架时会不会丢点。

按我这几年的体会，从二维库存管理到三维空间智能，最难的不是买设备、也不是写算法，而是让原来靠老师傅脑子的空间经验，变成一套可查询、可校验、可复用的数据资产。这套体系跑顺畅之后，最大的收益倒不是少招几个人，而是仓库里不再有“系统说有的货找不到”、“明明还能放的库位却装不下”这类让人头皮发麻的现场纠纷。如果让我再选一次切入点，我还是会先把空间ID打好底——这个东西一开始不显眼，后面几乎所有有用的功能都会长在它上面。