出餐口AI视觉质检做下来我最大的感受是大多数人第一次听这个项目脑子里想的都是“识别菜品”“判断颜色”“分析摆盘”但真正在门店里把系统跑稳之后才发现最大的敌人根本不是算法而是蒸汽、灯光、人走来走去还有那张永远擦不干净的台面。这篇文章把我从立项、选型、建模到门店实测的完整过程拆开讲。不是给你看一个demo视频那种“技术展示”而是把我在真实出餐口场景里踩过的坑、推翻过的方案、最后留下来的那套配置全部摊开。如果你正准备做类似的方向——不管是为了课程项目、毕业设计还是真的想在小餐饮店落地一套视觉质检——这篇能帮你省掉至少一个月的试错时间。1. 传感器思维的误区出餐口质检为什么和工业质检完全不同很多人一开始做这个项目会下意识地把流水线上的工业视觉方案搬过来——固定工位、固定光源、固定角度相机垂直往下拍背景是纯色传送带产品匀速经过。这套逻辑在手机壳划痕检测、PCB板缺陷检测上非常成熟但搬到出餐口几乎从头到尾都是错的。1.1 出餐口是一个半开放、高干扰的物理环境先别急着想“我要检测什么缺陷”先想想相机放在哪、拍什么、什么条件拍。这是出餐口项目和其他计算机视觉项目最大的分水岭。我在第一家测试门店踩的第一个坑相机正对出餐台想拍厨师递出来的盘子。结果实际画面里全是厨师的手、传菜阿姨的胳膊、从后厨飘出来的蒸汽以及高峰期排队顾客的头顶。画面根本不存在“干净背景”这回事。工业视觉里那种“产品进入视野触发拍照背景稳定”的假设在出餐口完全站不住脚。所以第一件事是接受一个现实出餐口视觉质检是开放环境下的近似受控检测而不是封闭环境下的精确检测。你要检测的“菜品质量”必须在大量无关视觉噪声中完成。这决定了后面所有技术选型。1.2 质检目标清单什么东西真正值得上AI去过几次门店、蹲了几轮出餐高峰之后我把“菜品质量检测”这件事拆成了下面这张表检测项传统人工判断的做法AI视觉实际可做的程度优先级餐盘边缘油污/汤汁溢出看一眼就能发现可检测难度中等容易被蒸汽干扰高主菜明显量不足凭经验厨师心里有数可检测需要同一菜品的历史尺度基准高异物头发、纸巾、包装碎片肉眼扫视不可靠“小目标随时变化”是噩梦组合低配菜缺失/错配对照订单出餐可靠本质是分类问题高酱料泼洒、摆盘混乱主观判断标准不一部分可测只能做“明显混乱”的阈值中这张表做完之后我自己先冷静了一下所谓的“菜品质量自动检测”真正能落地、能产生价值的场景并不是帮厨师判断“这道菜好不好吃”而是抓那些“肉眼一眼就能看出来不对”的情况——油污洒了、配菜给错了、量明显少了。换句话说AI质检在出餐口的定位不是一个美食评论家而是一个眼睛很毒的传菜员。这个定位决定了错误容忍度只要系统能把“明显有问题”的餐品拦截下来把人从机械盯盘子的劳动里解放出来就已经值回票价了。1.3 为什么不能用纯图像分类的思路做这是我早期犯的另一个方向性错误。一开始我的想法很简单拍一张照扔给分类模型判断“合格/不合格”。但实际跑下来发现出餐口质检的问题根本不是“这张图是好是坏”而是“这份菜品相对于它应该长什么样有没有偏差”。同样是红烧肉不同师傅做出来的颜色深浅、汤汁多少、配菜摆法都不一样同一个师傅不同批次也可能差很多。一个纯分类模型会被“菜品种类”这个变量搞得晕头转向——它可能学会了分辨“红烧肉”和“清蒸鱼”但根本学不会“这碗红烧肉的汤汁溢到盘子外面了”。所以从第一天起我采用的思路就不是“分类”而是“目标检测区域判定”先检测出餐盘区域再检测盘中主要菜品的位置然后再针对特定区域比如盘沿、台面、配菜位置做专项判断。这个思路看起来“多了一步”但实际精度和可解释性比单模型硬分类高一个量级。2. 出餐口的三大视觉天敌灯光、蒸汽、人影如果只看模型层面的论文和开源项目你很难意识到这些问题有多致命。我在门店里蹲了两周才把这三大干扰源彻底搞明白。2.1 灯光第一个见面就给我下马威的变量去之前我想当然地觉得门店里灯都挺亮的画面能差到哪里去。结果第一天采集的数据直接把我看懵了——同一道菜中午12点和下午2点拍出来完全像两个菜。问题出在出餐口头顶那盏射灯上。很多餐饮店出餐口上方会装暖色调射灯为了让菜看起来更好看、更有食欲。这盏灯直接把“色温”干到了极不稳定的状态晴天时阳光从门口斜进来射灯的暖光和你混在一起阴天时几乎只剩射灯整张图偏黄偏暗到了晚上后厨的日光灯透过来又是另一个白平衡。更别提高峰期传菜阿姨走来走去灯在盘子上扫来扫去亮度忽高忽低。这直接击穿了那些“标准环境下99%准确率”的模型神话。我后来专门做了个实验同一个菜同一个位置只改变灯光条件用当时跑得最好的YOLOv8模型做推理置信度从0.93掉到0.71。模型的判断直接动摇了。实际上后来真正帮我稳住画面的不是更复杂的模型而是相机侧的处理开启固定白平衡、固定曝光、固定增益把相机所有自动调节功能全部关掉。很多人做视觉项目从来不碰相机参数默认“摄像头装上去就能用”但在出餐口这种光环境里这是致命的。相机的自动白平衡会自己“纠正”画面颜色结果就是同一个菜品在不同时段被拍出不同色调后面所有算法都在跟光线打架。具体配置我后面会贴。但这一节的结论先放在这出餐口质检的第一优先级不是调模型而是先把画面“焊死”在一个稳定状态。2.2 蒸汽比想象中难缠一百倍的噪声源热菜出餐口一定有蒸汽这事谁都知道但只有真正处理过图像的人才知道蒸汽有多讨厌。它不是均匀的雾而是局部、随机、动态的白色/半透明团块从画面底部升上来然后在盘子上方飘散。一组连续帧里同一道菜可能某一帧的左上角被蒸汽糊住下一帧蒸汽又飘到右边了。这带来两个问题蒸汽区域会造成局部对比度下降边缘模糊目标检测框在原处抖动蒸汽的颜色接近白色/浅灰在某些光照条件下会被模型误识别成“餐盘”“纸巾”或者“异物”。我有一版模型在测试集上跑得好好的一到门店里就开始疯狂误报“异物”把蒸汽团当成检测目标了。后来我把蒸汽帧单独抽出来做了一轮分析才算弄明白怎么回事。方案是在数据层面解决采集训练数据时我专门挑出餐高峰时段去门店补拍把蒸汽场景单独做成一个数据集类别同时在检测模型的后处理逻辑里加了一个“低置信度区域抑制”——如果检测出来的目标是半透明的、边缘模糊的就先不立刻报警而是结合前后帧的检测结果做确认。换句话说我让系统学会了对蒸汽“视而不见”而不是试图在算法层面完美分割蒸汽。如果你做这个项目我强烈建议你从一开始就采集带蒸汽的数据而不是在干净环境里拍完就训练。否则模型在你的测试集上再漂亮上线第一天就会被蒸汽打回原形。2.3 人影和遮挡问题不在检测而在触发出餐口最不缺的就是人。传菜员、厨师、服务员、顾客全部会从相机前经过。我早期用运动检测定时抓拍的方式采集数据结果一多半的图片里都有人挡着要么是半个胳膊要么是厨师的后脑勺。后来我意识到出餐口质检系统真正要处理的不是“人来了怎么识别”而是“什么时候才值得拍照”。与其用定时器疯狂拍摄然后靠模型硬扛遮挡不如把拍照触发逻辑做好检测到出餐台上出现稳定的餐盘区域且持续一定帧数餐盘区域前景相对稳定没有大幅度运动遮挡触发拍照并进入质检流程。这里我用了一个轻量级的前景检测器做预过滤只有满足“有盘子、盘子区域稳定”这两个条件才把画面送入检测模型做质检。这个方法直接把无效帧的比例从60%以上降到了不到10%连带误报率也掉了一大截。3. 模型选型的真实心路为什么最终留在了单阶段检测器这一节可能是学生项目里最容易被“大模型崇拜”带偏的地方。我见过不少做类似项目的人上来就要上实例分割Mask R-CNN、YOLOv8-seg理由是“要精确到像素级才能判断菜品质量”。听起来很专业但实质上是用一台跑不动的大炮去打一只苍蝇。3.1 在出餐口场景里框就够用了出餐口质检需要的判定归根结底是两类“这盘菜的配菜有没有缺失” —— 需要知道盘中有什么、大致在哪个位置“汤汁/油污有没有溢出到盘沿” —— 需要知道盘子的边缘区域和菜品主体区域是否重叠。这两件事用目标检测框bounding box都能完成。一个框把盘子框住一个框把菜品主体框住然后计算两者之间的交并比和边缘距离——如果有大片菜品区域超出盘子框的范围大概率就是洒出来了。如果配菜类别缺失那直接看框的数量就知道。实例分割当然能有更精细的像素级信息但它的代价是训练成本高、推理速度慢、对边缘模糊的蒸汽场景更敏感而且标注成本直接翻倍。在门店那种一台普通工控机就要带四路相机出检测结果的场景里单阶段检测器是性价比上限。3.2 我在YOLOv8和更轻量方案之间的摇摆最终选的方案是YOLOv8n——nano版本。不是它有多厉害而是它在出餐口这个具体约束下最合适。在相同训练数据下我对比了YOLOv8n和YOLOv8m推理速度同样跑在Jetson Orin Nano上n版单帧约15msm版直接翻倍到30ms以上精度差距在我的自建测试集1200张门店实拍图上m版的mAP只比n版高了不到2个点。为什么差距这么小因为出餐口质检的核心难点根本不在模型容量上——菜品、餐盘、配菜都是再常见不过的目标特征明确、结构稳定一个轻量模型完全学得会。真正拖垮精度的变量是光线、蒸汽、遮挡这些环境因素而这些东西加再大的模型也补不回来。所以如果你在网上搜“计算机视觉大作业”“计算机视觉学习路线”看到一堆人说“用YOLOv8做检测”就把模型容量拉满我要劝一句先把环境变量收敛住再谈模型大小。出餐口场景里相机端和采集端的优化带来的精度收益远大于换一个更大模型的收益。3.3 后处理逻辑才是质检的核心而不是模型本身模型输出一堆检测框之后真正的工作才开始。我常跟朋友说模型只是个“眼睛”把看到的东西报出来真正做质检决策的是眼睛后面那个“大脑”——也就是后处理逻辑。我最终的质检判定流程大致分成几段# 伪代码示意质检判定核心逻辑 detections model.predict(frame) # 只保留置信度高于阈值的检测 valid_dets [d for d in detections if d.conf 0.5] # 定位餐盘和菜品主体 plate_box find_plate(valid_dets) dish_boxes [d for d in valid_dets if d.class in dish_classes] # 判断汤汁溢出菜品框是否明显超出餐盘框 for dish in dish_boxes: if iou(dish.box, plate_box) 0.15: alert(汤汁溢出或菜品洒落) # 判断配菜缺失对应配菜类别是否缺失 if garnish not in [d.class for d in valid_dets]: alert(配菜缺失) # 判断主菜量不足菜品面积是否明显小于历史均值的80% dish_area_ratio area(dish_box) / area(plate_box) if dish_area_ratio 0.8 * dish_avg_ratio[menu_item]: alert(主菜量可能不足请人工确认)这三个判断看起来简单但每个都对应一种真实运营场景。汤汁溢出、配菜缺失、主菜量不足这三类恰恰是门店投诉和差评里最常见的“菜品质量问题”。模型负责“看见”后处理负责“理解”两者缺一不可。4. 让模型看见真相出餐口数据采集与标注的那些坑模型选型定下来之后真正耗时、耗力、耗心血的环节其实是数据。4.1 我在采集数据时犯过的错只拍“合格照片”最早我图省事在门店不忙的时候去拍——画面干净、光线稳定、没有蒸汽、没有人走动。拍了一千多张开开心心送去标注训练出来的模型在测试集上表现也不错。但等到中午高峰一试直接翻车。后来我才想明白问题出在哪模型从未见过真实的出餐高峰长什么样你只能在真实场景里测试时一夜之间把所有没见过的情况全部补上。正确的采集策略是这样的连续一周每天中午11点到1点、晚上5点到7点固定机位持续录制视频流把视频流切帧按场景多样性挑选亮暗变化、蒸汽浓度变化、人手遮挡变化同时收集一些“坏样本”故意洒出来的汤汁、缺配菜的餐、摆盘明显乱掉的餐。坏样本尤其重要。模型训练里非常核心的一个问题是“合格品太多了不合格品太少”。我给自己定的目标是正负样本比例控制在6:4到7:3之间。如果全是合格餐品的照片模型学到的是“看到餐盘就输出合格”完全失去了质检的意义。4.2 标注工作的细节不要只标框要标区域属性我用LabelImg做了两轮标注第一轮就是常规的“框类别”很快发现不够用。比如汤汁溢出标注出来的框和菜品框大量重叠但模型根本不知道“这里有个框超出去了”意味着什么。第二轮我加了一个“区域状态”属性给每个检测框打了额外的标签菜品位置是否居中居中/偏移是否有菜品区域超出餐盘底框无/轻微/严重配菜是否存在有/无。这些标签不做进模型的分类头里而是作为后处理逻辑的辅助信息。比如“菜品区域是否超出餐盘底框”这个标签我直接用来设计溢出判断的阈值标准。这比让模型直接输出“溢出/不溢出”稳定得多——因为溢出的定义在门店里本来就有主观性交给规则比交给模型更可控。4.3 数据增强不是所有增强都适合出餐口常见的数据增强方案旋转、翻转、裁剪、颜色抖动、马赛克增强。在出餐口数据上我做了两个否定实验强颜色抖动不能用。出餐口的颜色信息非常关键——菜品的“新鲜感”“色泽”都通过颜色体现你一通随机调色板把菜拍成紫色模型直接就乱了。我最终只用了极轻微的色相、饱和度扰动不超过5%的幅度。马赛克增强慎用。YOLO系列训练标配的马赛克增强把四张图拼一起虽然能提升模型通用性但在出餐口场景里它会把“蒸汽”“餐盘边缘”“遮挡”这些关键特征搞混。后来我把马赛克增强关掉改成更温和的mixup精度反而稳了一些。另外两个提升很大的增强是随机亮度和随机噪声。随机亮度模拟一天中自然光的变化随机噪声模拟低光环境下的传感器噪点这两个和出餐口的真实环境匹配度极高。5. 出餐口专用点位设计把相机架在离菜品30厘米的地方模型和数据的坑聊完说回硬件。很多人做视觉项目注意力死死盯在算法上觉得硬件就是“买个摄像头插上”。但在出餐口这种场景相机怎么架角度对不对甚至比模型选型还影响最终效果。5.1 为什么垂直俯拍不是最佳角度我最初想当然地用了垂直俯拍——相机挂在出餐台正上方镜头直直朝下。这是工业视觉的标准做法能最大程度避免遮挡。但在餐饮门店里垂直俯拍会遇到一个很尴尬的问题出餐口上方通常有射灯、排烟管、装饰吊顶根本没有干净的位置装相机。而且垂直视角下厨师出餐端盘子的那一瞬间完全被厨师自己的身体挡住什么都看不到。后来我把方案改成了斜向俯拍相机装在出餐口侧上方45度左右的位置。这样一来厨师出餐时手臂的运动不会完全遮挡画面能看到餐盘侧面汤汁溢出的特征更明显汤汁是往外流的侧面视角能看到盘沿的挂壁安装位置避开照明灯具和排烟管道。斜向视角的代价是检测框会有一些透视变形但对“菜品区域是否超出餐盘”这种判断影响不大。这个改动可以说是整个项目里性价比最高的一个决定。5.2 相机选型和参数固化出餐口场景不需要超高分辨率。太高的分辨率会增加传输带宽、存储成本和推理耗时但画面里的关键信息——菜品种类、餐盘位置、溢出区域——在720p到1080p之间已经完全足够。我用的是普通工业USB相机720p30fps固定焦距镜头。选工业相机而不是普通网络摄像头核心原因有两个一是工业相机可以手动关掉自动白平衡、自动曝光把画面完全锁死二是工业相机的色彩还原更稳定不会像消费级摄像头那样自动“优化”画面。具体参数配置我直接贴出来供参考参数设定值说明分辨率1280x720平衡清晰度与推理速度帧率15fps实际跑检测30fps用于采集15fps用于推理白平衡手动固定5600K避免自动白平衡导致色彩漂移曝光固定约1/250s固定快门避免动态模糊增益固定最低档减少传感器噪点对焦手动固定在对角距离约40cm处自动对焦会导致焦点跳动5.3 一台小盒子就够了Jetson上的部署实测模型推理平台我试过两套纯云端API和边缘端推理盒子。最终留下的边缘端方案。门店的网络环境不稳定——路由器重启、Wi-Fi信号波动、外网带宽被POS机占用都是常态。如果质检逻辑放在云端遇到网络抖动质检就变成“薛定谔的质检”。于是我干脆把推理放在一台Jetson Orin Nano上本地出结果云端只负责收结果和告警消息。实测数据YOLOv8n 720p输入 TensorRT加速单路推理延迟基本稳定在20ms以内四路相机并发跑到40-50ms完全满足出餐口“端出餐到台面上”这个时间窗口。整机功耗不到15W挂在出餐台下面不占地方也不会发热到影响门店环境。6. 质检不是终点如何把“检测结果”变成门店的管理动作很多技术项目做到“能检出问题”就戛然而止但出餐口质检真正的价值在于把检测结果接进门店的运营动作里。6.1 联动订单系统按菜品做质检对齐这里有一个90%的人第一次都会忽略的问题出餐口质检如果不结合订单质检就无从谈起。同一个出餐台上可能同时摆了宫保鸡丁和鱼香肉丝。如果系统只知道“检测到餐盘”但不知道“这盘是什么菜”那“配菜缺失”“主菜量不足”之类的判断就根本没有参照标准。所以我做了第二步接订单号。门店的点餐系统在厨师完成出餐时会在订单里标记“出餐完成”。我就在出餐口旁边放一个扫码枪/读卡器实际上是一个简易单板机对接收银系统厨师出餐前扫一下订单号系统就知道接下来端上来的这道菜是哪个菜品质检模型就可以按菜品的标准来判断。这一步是在门店运营同事的强烈要求下加的。他们的原话是“你不能只告诉我这盘有问题你得告诉我是哪桌的哪个菜有问题不然厨师根本不知道该返工哪盘菜。” 确实如此检测结果只有和订单绑定才能真正形成闭环。6.2 告警分三级不该打扰人的情况绝不打扰我早期做的告警系统是这样的只要检测到异常立刻响铃同一时间大屏弹红色告警框。结果第一天上线就被门店骂回来了——高峰期蒸汽引起的误报一中午响了三十多次后厨的人已经完全不管那个警报了变成“狼来了”。后来我把告警分成了三级一级轻微检测到疑似溢出但置信度中等只在后台记录不推送给任何人二级较明确置信度较高推送一条消息给对应档口负责人附带截图由人工判断三级非常明确置信度极高且连续多帧保持一致才触发声音大屏弹窗的强提醒。这个分级把“机器报警可信度”这件事做了用户教育——后厨现在看到三级警报基本都会回头看一眼因为误报率已经降到非常低的水平。做质检系统最忌讳的把所有“疑似”都当成“确诊”往外推特别是在一个本来就高度嘈杂的厨房环境里。6.3 用数据反向驱动出餐标准最后一点可能是这个项目最有长期价值的部分。质检系统跑了两周之后我开始每天汇总所有检测结果——哪些菜品在什么时间段最容易出现“汤汁溢出”哪个档口的“配菜缺失”次数最多哪一类菜品在雨天/光线不佳时更容易触发量不足的提醒我把这些数据汇总成日报、周报发给门店负责人。以前这些信息全靠店长个人感觉现在变成了数据报表。有一家店看到“某档口周五晚市配菜缺失次数是平日的3倍”之后去查了一下发现是那个档口周五临时多了一个帮厨完全不熟悉该菜品的配菜标准——这种人效问题以前根本不可能被及时抓出来。这才是质检系统真正的价值它不只是判断“这盘菜合不合格”而是通过长期数据的积累帮门店找到“为什么经常不合格”的管理原因。7. 实战踩坑实录五件事把我从“实验室状态”打到真实场景最后这部分是我最想写的也是这个项目最有借鉴价值的部分。如果你只打算把项目当课程作业做可以掠过但如果你真要把它装进一家店请逐条看完。7.1 自动曝光导致的“菜品颜色漂移”我早期用消费级摄像头做采集画面里也会带一个参数——自动曝光。结果训练出来的模型在阴天和晴天表现判若两人我一度以为是模型泛化能力太差。后来灵机一动把同一天不同时段的图片放到一起对比才发现是相机自己在那儿调参数。出餐口射灯一亮相机曝光降下来画面整体变暗菜的饱和度全变了。这是一个极其低级但极其常见的坑你以为你在调模型其实你在给相机擦屁股。7.2 蒸汽识别成了“纸巾误报”前面提过蒸汽被误识别成异物的问题这里展开讲一下排查过程。最早模型开始疯狂报警“发现异物”截图上全是白色团块。我一开始以为是标注问题后来把置信度阈值拉高到0.7还是拦不住。最后把蒸汽帧单独抽了200张做成负样本训练集同时在后处理里加了“连续帧确认”逻辑才把误报真正压下去。这事的教训是在真实环境的数据里有些“背景噪声”在图片上长得和你要检测的目标非常像光靠阈值根本不解决必须把它当成一个“负类样本”喂回模型。7.3 亮面餐盘的反光模型把天花板灯识别成了“异物”门店用的不锈钢餐盘一旦反光会在盘面上映出一块高亮区域。训练初期模型学到的“高亮区域异物”逻辑导致它把不锈钢盘子的高光块当成了纸巾或油污。这个问题最后是用材质视角解决的——我特意给模型标注了一批“不锈钢盘”的样本把高光区域和盘身纹理一起作为盘子的特征喂进去让模型明白“高光是盘子的一部分”。有时候不光是模型的事物性知识也得掺进来。7.4 高峰期人手遮挡导致漏检一个现实情况高峰期传菜阿姨经常在出餐台前面弯一下腰或者直接端着盘子从相机和餐盘之间路过。有几秒钟画面里的目标被大面积遮挡检测框直接消失。我当时一个很头痛的问题是系统会不会在该抓拍的时候抓到一堆人手照片然后判断“未检测到餐盘”就跳过这会造成漏检。解决办法是把质检测试窗口放宽不要求某一帧“完美拍到餐盘”而是在餐盘出现的前后5秒内持续做检测投票——只要这段窗口内有超过3帧清楚地拍到餐盘就进入质检流程如果5秒内始终没有拍到清晰餐盘就记录为“未能质检”并在后台标记人工复核。不做“一帧定生死”。7.5 网络摄像头断电/掉线后的静默失效设备挂在后厨后厨的清洁天天用水冲洗地面电源插头接触不好、网线被推车压断都是家常便饭。我之前没有设计异常监控有一路相机掉了三天QA报告里“质检正常率100%”看起来一切正常——因为完全没有数据进来没有数据就没有异常。后来我加了一个心跳检测每路相机每秒上报一次状态如果连续30秒没有帧系统直接给负责人发一条“XX相机离线”的告警。并且每天凌晨自动汇总各路相机的有效检测数量低于某个阈值也告警。设备不在线算法再准都没用这是所有视觉项目中“隐形的一课”。8. 一点收尾经验出餐口质检项目的可复制路径如果把这个项目重新做一遍我会把执行路径压缩成四步第一步物理收敛固定相机、固定光照把画面的变量控制在最小范围内在源头消灭环境干扰。这一步不管多少人觉得“土”都值得投入时间。第二步数据对齐业务先明确要解决哪几类质检问题再反向设计标注方案和数据采集计划。不是先拍一堆图再想能检测什么而是先定质检规则再按规则去采数据。第三步模型轻量够用不追求最先进的模型用单阶段检测器合理后处理把精度和速度控制在门店能承受的范围。模型永远只是系统的一部分不是全部。第四步告警与管理闭环检测结果必须流转到人必须绑定业务动作否则检测得再准也只是个电子摆设。说句实在话出餐口质检这个项目技术门槛不算极高但它的复杂性和琐碎程度远超过那些在干净数据集上刷成绩的项目。真正做完一轮之后我最大的收获不是“模型精度到了多少”而是理解了计算机视觉项目落地时80%的精力要花在视觉之外的工程问题和管理问题上。如果你也在做出餐口或者类似门店场景的视觉质检项目遇到的具体坑可能跟我不同但解决问题的方法论大概率相同不要先问“模型怎么设计”先问“我要系统在什么条件下、用什么标准、为谁判断什么”。想清楚这四件事再差的模型也能跑出价值想不清楚再好的模型也救不了红绿灯一样的误报。