RFID 读写器并不「测量库存」。它观测的是无线电事件：每秒十到两百次地报告「某个标签对某根天线可见」，而它完全不知道这个标签是在货架上、在同事口袋里、在货车尾部，还是躺在隔壁通道的地板上。
ERP 需要的却是「断言」：这个 SKU、在这个库位、数量加一。观测与断言之间的落差，正是库存准确率成败的地方，而且无论怎么调读写器都填不平——它只能靠有意识的数据治理来填。
为什么 RFID 数据在 ERP 看到之前就已经坏了
五类机制制造了几乎所有的坏数据，没有一个是软件缺陷。
- 多次读取：读区内的标签每秒被上报几十次，不做抑制，一件衣服就会变成四十条移动。
- 读区重叠：两根天线覆盖同一个门口，同一个纸箱被归到两个库位。
- 漏读：在密集托盘里，单次通过有 10–20% 的标签不可见，而漏读与「物品不存在」在数据上无法区分。
- 陈旧标签：贴在废弃纸箱、退货筐或试衣间地板上的标签，会持续广播一个已经不成立的位置。
- 人为流程：标签贴错 SKU、贴错时间，或两个物品共用一个标签。
四类数据缺陷：重复、幽灵、漏读与状态错误
先分类再谈修复，因为每一类需要不同的控制手段。
- 重复：同一个物理物品在一个窗口内产生多条业务事件。
- 幽灵：事件指向的物品并不在那个库位——陈旧标签、相邻读区，或残留的标签。
- 漏读：物品确实在，但在盘点窗口内没有产生事件。
- 状态错误：单条事件都合法，但顺序不可能——未到先出，或两个库位同时声称拥有同一件物品。
重复与幽灵会抬高库存，漏读会压低库存，而状态错误污染的是历史——这更糟，因为错误会传导进之后每一次计算。
去重：能在多读写器重叠下存活的规则
在三个层级上去重，同时保留原始事件日志，保证任何时候都能重新推导。
- 时间窗口：同一 EPC 在同一读写器上 N 秒内只算一次。月台门取 3–10 秒，慢速输送线取 30–60 秒。
- 空间分组：覆盖同一物理区域的天线归为一个读写器组。组内三根天线看到同一标签，算一条事件，不是三条。
- 业务窗口：同一 EPC 在同一库位、滑动窗口内（常见 10–30 分钟）只算一次，跨读写器也成立。
原始读取必须存下来。去重后的事件投影到独立表里，并且当作「可重算」的产物。当某条去重规则被证明是错的，你改规则、重放即可，而不必去 ERP 里翻找被污染的历史。
边缘校验与核心校验怎么分工
按「哪一层能廉价地知道什么」来分工。
- 边缘校验：EPC 格式、校验和、公司前缀、TID 是否存在、读写器与天线标识、时间戳合理性。这些能在占用带宽之前就丢掉畸形读取。
- 核心校验：SKU 是否存在、库位是否有效、数量是否非负、该作业类型下这个状态迁移是否合法、操作人是否有权限。
- 绝不要在边缘做核心校验。边缘不知道产品目录，一旦它试图知道，就开始缓存过时的主数据。
一条好用的规则：边缘拒绝物理错误，核心拒绝业务错误。两者都不是的——一个真实标签在真实库位上的合理读取——必须被接受或被显式隔离，绝不静默丢弃。
异常处理：隔离区、SLA 与人工流程
异常不会因为没人看就消失，得给它一个归宿。
- 每条失败记录进入隔离表，带原因码、原始载荷和时间戳。
- 每天按原因码发布数量。某个原因码连续三天上涨，说明这是设计问题，不是操作员问题。
- 在 ERP 里定义评审状态：自动接受、待评审、已拒绝。只有中间那一档需要占用人工时间。
- SLA 用小时而不是天。超过 48 小时的异常，通常已经演变成实物差异。
- 每一次人工覆盖都要记录操作人、原因和原值，否则治理系统自己就会成为下一个坏数据来源。
能说明管道健康的指标
六个数字，每周复盘，基本能在月末之前抓住问题。
- 分区读取率：受控测试中成功读取数除以预期物品数。通道低于 95% 时，先修天线，别怪数据层。
- 重复比：原始读取数除以去重后事件数。比值上升意味着天线重叠或抑制规则失效。
- 未知标签率：找不到对应 SKU 的 EPC。这个数字直接反映贴标纪律与公司前缀配置。
- 从读取到 ERP 单据的 p95 时延。p95 一旦漂移，说明队列在积压，积压策略很快会开始丢事件。
- 调整率：人工库存调整占总移动的比例。这是「RFID 是否真的在替代人工纠错」最诚实的衡量。
- 异常滞留：异常平均开启小时数。这一项比任何指标都更能预测月末的痛苦。
运营模式：数据由谁负责
治理在「不是任何人的工作」时失败，在「是某一个具名的人的工作」时成功。
- 数据管家负责规则、原因码和每周复盘。不是 IT 团队——IT 负责管道，不负责语义。
- 运营负责贴标质量与读写器清洁。一扇脏了的天线窗造成的漏读，比任何软件参数都多。
- 财务负责调整政策，并签署容差阈值。
- 复盘会 30 分钟，每周一次，每次都看同样的六个指标。
结论
读写器产出事件，ERP 需要决策。中间那一层本身就是一件产品，值得和天线布局投入同样的设计精力。
- 先分类缺陷，再谈修复。
- 在时间、空间、业务三个层面去重，并保留原始日志。
- 边缘校验物理，核心校验业务。
- 给每条异常一个归宿、一个负责人和一个 SLA。
- 每周看六个指标，把上升的数字当成设计信号。
做到这些，库存准确率就会成为系统的一个属性，而不是每月一次的争论。
