一、项目背景与需求分析：零售业的那些“看不见的”痛点
大家好，我是老张。做计算机视觉落地也有七八年了，今天咱们聊聊货架标签识别这个项目。
说实话，刚接触这个需求时，我第一反应是：“不就是拍个照，识别一下价格标签吗？”后来真正深入进去才发现，这里面的坑，比想象中多得多。
1.1 零售业的“隐形杀手”：价格管理混乱
你想想看，一家中型超市，SKU（单品数量）少说三五千，大型卖场动辄上万。每个商品对应一个价格标签，而这些标签，每天都在变。
促销活动、临期降价、新品上架、供应商调价……任何一个环节出错，都可能引发连锁反应。
我亲身经历的一个案例：
某连锁便利店，因为店员漏换了一张促销标签，导致顾客结账时发现价格不符。顾客投诉、店长罚款、区域经理被约谈。最后查出来，就是一张2块钱的酸奶标签没更新。嗯，一张标签引发的“血案”。
零售业的痛点，说白了就三个字：不一致。
- 线上线下价格不一致：电商平台改价了，门店标签还是旧的
- 标签与实物不一致：A货架放了B商品的标签，顾客拿错、收银错
- 标签状态不一致：有的标签卷边、褪色、被遮挡，根本看不清
1.2 货架标签管理现状：人工巡检的“三座大山”
目前大多数零售企业，还在用最原始的方式管理标签——人工巡检。
我调研过不少客户，总结下来，人工巡检有三大痛点：
| 痛点 | 具体表现 | 后果 |
|---|---|---|
| 效率低 | 一个店员每天花2-3小时核对标签，大型卖场需要4-5人专职巡检 | 人力成本高，且无法覆盖所有时段 |
| 准确率差 | 肉眼核对容易疲劳，漏检率高达15%-20% | 价格纠纷频发，影响顾客体验 |
| 数据滞后 | 发现问题→上报→修改，平均需要2-3天 | 促销活动期间，价格更新严重滞后 |
我的一个小建议：
如果你正在做类似项目，先去实地跟拍一次店员巡检的全过程。你会发现，很多“合理”的流程设计，在实际操作中根本跑不通。比如，店员为了省事，会跳过那些“看起来没问题”的货架——而这恰恰是问题高发区。
1.3 项目目标：我们要解决什么问题？
这个项目的核心目标，其实就一句话：用计算机视觉替代人工巡检，实现货架标签的自动化识别与数据采集。
具体来说，我们定了三个子目标：
- 识别准确率 ≥ 98%：包括标签内容识别、位置定位、状态判断
- 单张图片处理时间 ≤ 500ms：满足实时巡检需求
- 支持多场景适配：不同光照、不同角度、不同标签样式
为什么会定98%这个数字？
我记得当时和产品经理吵了一架。他觉得99.9%才够用，我说你想想看，一个超市每天产生几千张标签图片，0.1%的误差意味着每天至少漏掉几张。但98%意味着什么？意味着人工只需要复核2%的异常情况，效率已经提升了50倍。
嗯，这里要注意：技术指标不是越高越好，而是要和业务场景匹配。
1.4 项目范围：我们做什么，不做什么
很多项目失败，就是因为范围没划清楚。我见过太多团队，一开始说“做个标签识别”，做着做着变成了“做个智能零售中台”。
所以，这个项目的范围，我明确划了三条线：
项目边界（我们做）：
- 货架标签的拍照采集（手机/PDA/固定摄像头）
- 标签内容的OCR识别（商品名、价格、促销信息）
- 标签状态的异常检测（缺失、遮挡、卷边、褪色）
- 识别结果与后台数据库的比对校验
- 异常标签的自动告警与工单生成
项目边界（我们不做）：
- 电子价签的硬件开发（那是另一条赛道）
- 零售ERP系统的重构（只做接口对接）
- 商品陈列合规性分析（那是另一个项目）
我曾经吃过一次亏。有个客户说“顺便帮我们看看货架缺不缺货”，结果我们花了两个月做商品检测，最后发现标签识别和商品检测是两个完全不同的技术栈。从那以后，我学乖了——项目范围，写在合同里，刻在脑子里。
1.5 技术选型的初步思考
基于上面的目标和范围，我初步定了技术方向：
- 图像采集：优先使用手机摄像头（普及率高），固定摄像头作为补充
- OCR引擎：PaddleOCR（中文场景表现优秀，且开源免费）
- 异常检测：基于YOLO的目标检测模型，专门训练标签状态分类
- 后端架构：Flask/FastAPI + PostgreSQL，轻量级但够用
当然，这只是初版方案。后面几章，我会详细讲每个环节的踩坑经历和优化技巧。
好了，背景和需求就聊到这儿。下一章，咱们开始动手——从数据采集开始，一步步搭建这个系统。
公众号:蓝海资料掘金营，微信deep3321