企业官网建设流程全解析

出餐口AI视觉质检做下来，我最大的感受是：大多数人第一次听这个项目，脑子里想的都是“识别菜品”“判断颜色”“分析摆盘”，但真正在门店里把系统跑稳之后，才发现最大的敌人根本不是算法，而是蒸汽、灯光、人走来走去，还有那张永远擦不干净的台面。

这篇文章把我从立项、选型、建模到门店实测的完整过程拆开讲。不是给你看一个demo视频那种“技术展示”，而是把我在真实出餐口场景里踩过的坑、推翻过的方案、最后留下来的那套配置，全部摊开。如果你正准备做类似的方向——不管是为了课程项目、毕业设计，还是真的想在小餐饮店落地一套视觉质检——这篇能帮你省掉至少一个月的试错时间。

1. 传感器思维的误区：出餐口质检为什么和工业质检完全不同

很多人一开始做这个项目，会下意识地把流水线上的工业视觉方案搬过来——固定工位、固定光源、固定角度，相机垂直往下拍，背景是纯色传送带，产品匀速经过。这套逻辑在手机壳划痕检测、PCB板缺陷检测上非常成熟，但搬到出餐口，几乎从头到尾都是错的。

1.1 出餐口是一个半开放、高干扰的物理环境

先别急着想“我要检测什么缺陷”，先想想相机放在哪、拍什么、什么条件拍。这是出餐口项目和其他计算机视觉项目最大的分水岭。

我在第一家测试门店踩的第一个坑：相机正对出餐台，想拍厨师递出来的盘子。结果实际画面里全是厨师的手、传菜阿姨的胳膊、从后厨飘出来的蒸汽，以及高峰期排队顾客的头顶。画面根本不存在“干净背景”这回事。工业视觉里那种“产品进入视野，触发拍照，背景稳定”的假设，在出餐口完全站不住脚。

所以第一件事是接受一个现实：出餐口视觉质检是开放环境下的近似受控检测，而不是封闭环境下的精确检测。你要检测的“菜品质量”，必须在大量无关视觉噪声中完成。这决定了后面所有技术选型。

1.2 质检目标清单：什么东西真正值得上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版单帧约15ms，m版直接翻倍到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相机，720p@30fps，固定焦距镜头。选工业相机而不是普通网络摄像头，核心原因有两个：一是工业相机可以手动关掉自动白平衡、自动曝光，把画面完全锁死；二是工业相机的色彩还原更稳定，不会像消费级摄像头那样自动“优化”画面。

具体参数配置，我直接贴出来供参考：

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%的精力要花在视觉之外的工程问题和管理问题上。

如果你也在做出餐口或者类似门店场景的视觉质检项目，遇到的具体坑可能跟我不同，但解决问题的方法论大概率相同：不要先问“模型怎么设计”，先问“我要系统在什么条件下、用什么标准、为谁判断什么”。想清楚这四件事，再差的模型也能跑出价值；想不清楚，再好的模型也救不了红绿灯一样的误报。