条码优先的转向

运单识别一直卡在 OCR 的字符混淆上——0/O、1/I，这类经典的、怎么调都赢不了的情况。真正的修法不是去死磕识别器的准确率，而是换掉被识别的对象本身：运单号在条码里同样存在，而条码是机器原生的——于是流水线翻转为条码优先、OCR 作兜底（2025-08-08，issue #50）。

后续的数据印证了这个判断：OCR 作为兜底时，单次尝试成功率是 94%，扫描可靠性不再是漏斗的问题所在（route-to-first-scan-cliff——那道断崖出现在扫描的上游，而不在扫描本身）。

这次调整的形状是：当一个组件的失败模式是内在的（字形本身就视觉混淆），不要去调这个组件——换一条不存在这种失败模式的通道。 同一时期、同一种做事纪律：#52 在路由之下加了运输公司这一层；#47 改善了 load-car 的可发现性——独立开发期间，issue 编号一路连贯。

后记（2026-09）。 第二段没有经受住实地检验。当 AUTO 门有了见证事件、见证事件又学会了带上检测器的判定之后，断崖被移回了扫描器内部：大多数门超时根本没有解出过任何条码，因为 Android 的分析帧默认一直是 640×480。转向的逻辑（换通道）依然成立；"扫描可靠性已解决"这个前提在 the-cliff-was-in-the-scanner 里被修正。

面试原型问题："说一个你没能解决的问题"——我没有解决它；我让它不再是问题。