IATA 753 号决议并没有要求航空公司去买阅读器，它要求的是：在四个明确时刻知道行李在哪，并且能够向合作伙伴证明这一点。这个区别，决定了一个 RFID 项目究竟是合规动作，还是运营改善。
决议到底要求什么
753 是一项数据义务，而且带一套明确的计量模型。
- 航司必须在收运、交付至分拣区、中转与到达四个节点追踪每一件行李。
- 数据必须可由航司取得，并能与联运及地面代理伙伴共享。
- RFID 不是强制技术，它只是唯一能让四点追踪变得廉价且自动的手段。
- 合规看的是能否拿出记录，而不是装了多少台阅读器。
- 而运营上的回报恰恰来自同一份记录：更少的行李差错、更快的对账、更干净的索赔。
条码、RFID 还是两者并用
多数机场走混合路线，这不是折衷，而是过渡。
- 条码行李牌通用且便宜，但需要视线，而且一件一件扫。
- UHF RFID 内嵌天线每秒可读数十件，能穿透部分遮挡，也无需对准。
- 双模行李牌——印刷条码加内嵌天线——既保留兼容性，又增加了自动读取。
- 内嵌天线必须落在标准行李牌格式之内，否则地面代理无法处理。
- 值机打印机、耗材与员工培训必须一起改，否则推广会卡在柜台。
四个读取点与各自的物理条件
每个点的几何都不同，在一个点测出的读取率，对另一个点毫无意义。
- 收运读取发生在柜台，行李静止，标签朝向任意。
- 分拣读取发生在运动皮带上，行李翻滚，标签有时被遮挡。
- 中转读取发生在狭窄滑槽与容器里，金属拖车与堆叠都会伤害读取。
- 到达读取发生在行李转盘，行李分散，角度常常很别扭。
- 每个点单独设计：自己的天线布局、功率与验收阈值。
把读取变成伙伴愿意接收的报文
读取只是一个本地事件，报文才是契约层面的陈述。
- 把收运读取映射为开启该行李旅程的行李源报文。
- 把后续每个读取映射为伙伴在该节点期待的流程报文。
- 全程以十位行李牌号作为跨系统主键。
- 把读取插入既有报文流，而不是另建一条平行链路。
- 时间戳用 UTC，并带上地点代码，否则伙伴会拒收记录。
是对账，不只是采集
价值来自把「应有」与「实有」逐分钟比对。
- 依据值机与中转数据，维护航班级的应有行李清单。
- 把实读结果与该清单比对，暴露缺失与多出的行李。
- 多出的行李要当作紧急事件，它通常正是即将被差错处理的那一件。
- 告警前留出明确的宽限期，否则正常的皮带延迟会制造噪声。
- 把对账结果回灌到员工本来就在看的离港与行李系统里。
异常处理决定最终结果
漏读是正常的；漏读之后没能对账才是事故。
- 为完全无法读取的标签设置人工补录工位。
- 保持最后已知节点可见，让员工能采取行动，而不是翻遍整个大厅。
- 把未知标签、重复读取、错航班与错集装箱区分为不同情形。
- 记录每个异常由谁、何时解决，规律才会浮现。
- 衡量异常闭环时间，而不只是异常数量。
跨链条的数据共享
753 在设计上就是联运的；封闭的机场系统只能在纸面上合规。
- 与每个伙伴约定：接收哪些事件、多长延迟、什么格式。
- 明确每个事件的权威来源，中转点尤其如此。
- 显式处理伙伴数据缺失，而不是把沉默当成成功。
- 记录与旅客关联的行李数据的留存与访问规则。
- 在旺季之前用真实航班测试伙伴接口，而不是旺季当中。
与既有系统的集成方式
RFID 是行李处理系统与离港系统的邻居，不是它们之上的替代品。
- 分拣系统控制路由；RFID 读取应当提供信息，而不是直接驱动分流器。
- 离港系统持有旅客与行李记录；不要复制它。
- 采用带缓冲的事件总线或中间件，阅读器故障不应让皮带停摆。
- 阅读器配置要版本化，因为改过的功率就是改过的结果。
- 演练失效路径：阅读器正常但消息代理宕机时会怎样。
说明它有没有用的指标
覆盖率与结果必须一起报，否则数字会误导。
- 追踪覆盖率：在四个点都取得有效读取的行李占比。
- 读取质量：各点一次通过率与重复读取率。
- 每千名旅客的行李差错率，与项目前基线相比。
- 找到一件行李所需时间，这才是旅客与搬运工真正感受到的。
- 异常闭环时间，以及无需人工翻找即解决的比例。
做到稳定四点覆盖的项目，通常报告行李差错下降约四分之一，而中转航班的收益最大。
不让柜台排队的推广顺序
按「价值先出现」的顺序安排部署。
- 先做一个航站楼、一家航司，从单条值机线开始使用双模行李牌。
- 先证明收运与分拣，因为这两个点由机场掌控。
- 只有在伙伴报文谈妥并测试通过后，才加入中转读取。
- 每个点都保留条码兜底，并明确告诉员工这是兜底。
- 发布一页纸的异常流程，再用第一个月的数据调整阈值。
