企业官网建设流程全解析

1. 电梯场景下的检测任务，难点到底在哪

先说结论：电梯内电瓶车检测这个项目，看着是个标准的目标检测任务，实际做起来却比很多人想象的复杂。我见过不少团队拿着通用检测模型直接上，测试视频里精度看着还行，一到真实电梯环境就各种误报漏报，最后被物业方三天两头投诉。

这个场景的特殊性在于三点。

第一，视角和空间。电梯监控通常是正对轿厢门的斜俯视角，或者装在轿厢顶部角落。电瓶车的形态在这样的视角下变化非常大——从侧面看过去是一辆完整的车，从前脸看过去基本只剩一个车把和踏板。很多通用目标检测模型是在街景、平视视角的数据上训练的，遇到这种自上而下的透视形变，特征提取会明显打折。

第二，光照条件。电梯轿厢的光照并不稳定，白天靠自然光和轿厢灯，晚上基本只有冷光灯，再加上反光地砖、不锈钢内壁的倒影，摄像头自动增益模式下整个画面的亮度会来回浮动。电瓶车外壳的塑料和金属材质在这种环境下会产生高光过曝区域，直接把部分特征细节吃掉。

第三，遮挡和干扰。电梯里经常是人和车混在一起，高峰期有人挡在车前，有人手里拎着东西碰到车身，外卖箱、快递箱堆在踏板上，都会造成不同程度的遮挡。另外轮椅、清洁车、大件行李箱、甚至婴儿车，在外形上和电瓶车存在局部相似度，容易引发误检。

所以这个项目真正要解决的核心问题，不是一个简单的"能不能检测出电瓶车"，而是"在电梯这个特定场景下，如何同时做到高召回和低误报"。召回率低了，电动车混进电梯的漏检没意义；误报率高了，系统不停弹警报，物业会疯掉，住户也会投诉。

我做的这版方案选型是 YOLOv8，中英文双版，完整训练推理链路都跑通了，还配了效果演示。下面把整个项目从数据、训练、部署到避坑，按实操顺序完整拆开来讲。

2. 数据准备：决定项目上限的苦功夫

训练一个电梯内电瓶车检测模型，数据质量比模型选型重要得多。YOLOv8本身足够强，但喂进去的数据不对，什么模型都白搭。

2.1 数据从哪里来：自采为主，开源为辅

电梯场景的公开数据集非常少，几乎找不到直接能用的、标注好的电梯内电瓶车数据集。网上有些通用的电瓶车/摩托车检测数据集，里面绝大多数是街景平视视角，在电梯场景里只能作为补充，不能当主力。

我最后的做法是：以自采电梯监控数据为主，通用数据为辅。

• 自采数据：从物业处的模拟项目X获取脱敏的电梯监控片段，覆盖不同时段（早中晚）、不同天气（晴天、阴天）、不同电梯品牌（轿厢尺寸和内部装修不同）、不同摄像头安装角度。大概攒了3000多段有效视频，抽帧后筛选出约8000张有效图片。
• 补充数据：从公开数据集中筛选出侧视、俯视角度接近电梯监控视角的电瓶车图片，以及各种可能造成干扰的负样本图片（轮椅、清洁车、大型行李箱、手推车等），大概2000张。

比例大约在8:2。这个比例不是随便定的，自采数据太少的话模型学到的还是通用特征，到真实电梯里泛化性不够；自采数据太多而负样本不够的话，误检率会压不下去。

2.2 标注规范：每个类目都有讲究

标注这块踩过不少坑，说几个关键点。

类别设置上，最终我只设了一个类别：电瓶车（electric_bicycle / e_bike）。没有单独设"摩托车"或者"电动车"，因为摩托车进电梯的场景本身很少，而且和电瓶车在视觉上高度相似，分成两个类目反而会引入标注不一致的问题。如果你要部署的项目在特殊区域（比如允许摩托车上楼的农居点），再考虑单独加类。

标注框要尽量贴合车身外轮廓。电瓶车的定义范围要统一：含车筐的车算不算？带外卖箱的车算不算？我的标注规范是，车身骨架（车把、踏板、坐垫、后轮、车筐）都在框内，外卖箱如果明显高出车身，可以不包含在框内，但车的主干必须标注完整。这样标注出来的框，模型学到的特征更集中，不容易被随行杂物带偏。

被遮挡超过70%的目标，统一不标注。道理很简单：一个几乎全被挡住的车，标注进去只会给模型传递噪声，让它在模糊的特征上也强行学出一个框来。目标是检测可拦截的电动车，不是检测幽灵。

负样本的标注同样重要。轮椅、婴儿车、清洁车在电梯里出现频率不低，这些图片要放进背景类（没有标注框），让模型学会"这些东西不是电瓶车"。负样本比例我控制在总样本的15%左右，太少压不住误检，太多会把模型的敏感性拉低。

2.3 数据增强：仿真电梯环境的差异

电瓶车检测最怕的是模型对光照和视角不鲁棒。为了缓解这个问题，我在训练时用了一套针对性的增强策略：

• 亮度和对比度扰动：模拟电梯内灯光自动增益，亮度随机偏移 ±25%，对比度随机缩放 0.8~1.2
• 轻微旋转和透视：电梯视角会有轻微抖动，旋转范围 ±15度，不做过大的旋转，否则电瓶车形变会失真
• 随机遮挡：模拟人流量大时的身体遮挡，随机擦除画面中的部分区域
• HSV色域扰动：模拟早晚色温变化，特别是傍晚的暖色光

这套增强策略不是越强越好。我最初把旋转角度放到±30度，结果模型在真实电梯里反而对正常角度的车识别不稳定，因为训练时见过的形变太多了，把特征分布拉散了。后来收敛到±15度，效果明显改善。

2.4 数据划分：按场景而不是按图片

这是一个很多人容易忽略的细节。如果按图片随机划分训练集和验证集，同一段电梯视频的相邻帧可能同时出现在两边，这样验证集分数虚高，真实场景表现会大幅缩水。

正确做法是按"视频场景"划分。也就是说，来自同一段监控的视频帧，要么全部进训练集，要么全部进验证集，不能跨集合。交叉验证时也按电梯编号分成多个fold。这样评测得到的mAP，才接近真实部署时的水平。

3. 从YOLOv8候选模型到训练配置的选型逻辑

模型选型这件事，我周围的开发者和算法工程师讨论得很多，最后选YOLOv8，是基于实际约束权衡的结果，而不是因为它最新。

3.1 为什么是YOLOv8而不是其他模型

电梯电瓶车检测部署的常见硬件是Jetson Orin Nano、RK3588盒子、或者老旧的NVR设备。这些设备的算力天花板决定了模型不能太大，同时电梯场景对延迟有要求——从发现电动车到输出告警，整个链路不能超过1秒，否则车已经进电梯了，告警才有反应，意义就打折了。

在这个前提下，拿几个主流方案实际测过：

最终选了YOLOv8，主要看中它在edge设备上的推理效率和社区工具链的完整度。YOLOv8的anchor-free设计让输出头更简单，减少了后处理工作量，对部署环节友好。另外它的s模型在640x640输入下，Orin Nano上跑TensorRT FP16能做到30ms上下，完全满足电梯场景的实时要求。

3.2 模型规格：从n到m的实际对比

YOLOv8按参数量分n/s/m/l/x五档。在电梯场景里我试了n、s、m三档，结论如下：

• YOLOv8n：速度快，但是小目标召回确实弱。电瓶车距离摄像头远时，车把、后视镜等关键特征在图像中只占几十个像素，n模型漏检明显。
• YOLOv8s：综合平衡点。速度可观，精度比n模型提升明显，特别是对中等距离电瓶车的识别，漏检率下降了一个量级。
• YOLOv8m：精度最高，但模型体积和延迟都上涨。在只有单路或两路推理的盒子上勉强可用，多路并发就紧张了。

最后的正式版本选的是YOLOv8s。如果你部署的算力足够（比如工控机带独立显卡），可以上m版本换取更低的误检率，否则s版本是性价比最优解。

3.3 训练配置和关键参数

训练配置文件是标准的YOLOv8格式，数据yaml长这样：

path: /data/elevator_ebike train: images/train val: images/val names: 0: e_bike

类别名我统一用英文的e_bike做训练，中文"电瓶车"的显示映射放到推理阶段处理。这样模型本身保持语言无关，中英文双版只需要改映射表和UI，不需要重新训练模型——这是做多语言版本的关键设计思路。

训练超参：

yolo detect train \ model=yolov8s.pt \ data=elevator_ebike.yaml \ epochs=200 \ imgsz=640 \ batch=16 \ device=0 \ patience=30 \ project=elevator_ebike_run

几个参数说下理由：

• imgsz=640是速度和精度的折中。试过960输入，检测精度确实再涨一点，但推理耗时增加约70%，在边缘设备上不划算。
• epochs=200配合patience=30早停。电梯数据相对简单，200轮足够收敛，我训练到150轮左右mAP就基本平稳了。
• 预训练权重用yolov8s.pt而不是从头训练。迁移学习的收益非常大，尤其是对于自采集的小数据集，COCO预训练能帮模型提前具备通用物体表征能力。

3.4 训练过程监控的几个关键曲线

训练的时候很多人只看mAP，其实有三个曲线要盯牢：

第一个是box_loss和cls_loss。训练损失下降，验证损失也在下降，说明模型在正常学习；如果训练损失降但验证损失不降反升，就是过拟合了，这时要看是否需要加强数据增强或提高dropout。

第二个是验证集的recall曲线。电瓶车检测项目最重要的指标不是精确率，而是召回率——漏掉一辆电动车比误报一次的后果严重得多。我的目标是把recall压在95%以上，precision尽量高，后面通过告警策略来抑制误报。

第三个是混淆矩阵。训练结束后一定看一眼混淆矩阵，重点确认负样本（background）有没有大量预测成电瓶车。如果有，说明背景类别太复杂，需要补充更多负样本或者调整类别权重。

我这版训练结果大致是：mAP50接近0.96，mAP50-95在0.82左右。作为对比，拿没做过电梯增强的通用电瓶车数据训练，mAP50-95大概只有0.68。数据场景适配起了决定作用。

4. 部署落地：ONNX导出、TensorRT加速和边缘设备适配

训练完模型只是第一步，真正的工程难点在部署环节。这个环节踩过的坑比训练期还多，挑重点讲。

4.1 从PyTorch到ONNX再到TensorRT的转换链

标准导出流程：

# 从YOLOv8导出ONNX yolo export model=best.pt format=onnx opset=12 simplify=True # 从ONNX转TensorRT engine trtexec --onnx=best.onnx \ --saveEngine=best_fp16.engine \ --fp16 \ --workspace=2048

导出时的注意事项：

• opset=12是我测试后比较稳的版本。opset太高在部分old JetPack的TensorRT版本上会出现算子不支持的情况，opset太低又会丢失部分结构优化。
• simplify=True会把一些冗余的常量算子折叠起来，ONNX文件更小，转换成功率更高。
• FP16精度在这个任务里足够，不用走INT8量化。电瓶车检测不是对精度极敏感的细分任务，FP16在Orin Nano上就能达到很好的效果。INT8量化省的那点延迟，相对于它引入的精度损失和标定工作量，性价比不高。

4.2 推理链路里最容易出问题的后处理环节

YOLOv8输出的是(84, 8400)的特征矩阵——84代表4个框坐标+80个COCO类别置信度（因为用了COCO预训练权重），8400是三个尺度下anchor的总数。部署时要做两件事：筛选置信度和做NMS。

真实场景里最坑的一个点，是置信度阈值的设定。

在训练日志里mAP很高，不代表推理时随便设个0.5阈值就能直接用。我在真实电梯环境测试时发现，白天自然光充足时效果很好，到了夜间轿厢内灯光昏暗、摄像头自动增益导致画面发灰时，模型输出的置信度整体下降一截。如果固定阈值是0.5，夜间会出现大量漏检。

最后方案是置信度阈值设为0.35，但配合跟踪后的多帧确认。也就是说，单帧检测出电瓶车不算数，要连续N帧（比如3帧）同一个位置都检出电瓶车，才触发告警。这样既保住了夜间召回，又大幅降低了单帧噪声引起的误报。这个策略组合是整项目里最有价值的调优之一。

4.3 目标跟踪的引入：不只是为了去重

电瓶车进电梯是一个过程，不是一帧事件。引入简单跟踪（如ByteTrack或排序跟踪）有两点好处：

• 去重：同一辆电瓶车连续多帧被检测到，如果没有跟踪，会在每一帧都产生一次告警，把物业管理后台刷爆。有了跟踪ID，可以做到"同一辆车只告警一次，状态保持直到车辆离开"。
• 多帧确认：结合跟踪轨迹判断，目标ID稳定存在超过一定帧数才认为是真的电瓶车，随机噪声（比如光影变化导致的瞬时误检）基本被过滤掉。

跟踪器的实现我用的是封装好的ByteTrack，只需要把检测结果按帧顺序喂进去，维护目标ID和轨迹状态。它对遮挡有一定的容忍度，电瓶车被人短暂挡住一两帧，ID不会立刻丢失，告警状态可以维持住。

4.4 边缘设备的资源占用和并发评估

以YOLOv8s模型在Orin Nano上为例，实测数据给大家参考：

这个延迟水平对于电梯告警场景完全够用。一个Orin Nano盒子可以同时跑4路电梯摄像头的实时检测，每路300ms内完成一轮检测周期，还有余量做告警日志的存储和上报。

如果部署在更老的设备（比如某些只有CPU的NVR），YOLOv8s可能带不动，那就得换YOLOv8n，或者降低推理分辨率到416x416，用部分精度换实时性。

5. 误报与漏报的实战调优：血泪教训集中分享

这一节是全文最想讲的部分。训练和部署跑通只是开始，真正让系统在真实电梯里"能用"，是在一轮又一轮的误报投诉和漏检质疑中磨出来的。

5.1 场景一：轮椅被反复识别成电瓶车

第一次现场测试就翻车了。一位坐轮椅的住户进电梯，系统马上告警"电瓶车入梯"，物业人员跑过去一看是轮椅，场面很尴尬。

分析原因：轮椅的侧面轮廓——两个大轮子、一个坐垫、竖起的靠背——和电瓶车的侧面轮廓在局部特征上高度相似，特别是在低分辨率、背光条件下，靠背容易和电瓶车后座混淆，大轮子和大轮毂特征也很像。

解决办法分三步：

• 补充大量轮椅正样本并标注为负样本，让模型看到"这个东西不是电瓶车"。
• 增大类别区分度：把电瓶车的标注重点放在车把、踏脚板、前挡板等特有结构上，这些部件轮椅没有。标注时框位不准的话，模型就会模糊这两类特征的边界。
• 告警侧加目标尺寸过滤：轮椅比电瓶车整体矮一截，检测框的宽高比有明显差异。根据实际场景统计电瓶车检测框的宽高比范围，超出范围的检测结果直接丢弃。

三步做完，轮椅误报基本清零。

5.2 场景二：地砖反光把影子识别成车

某个电梯的轿厢地面是镜面不锈钢，白天光线好的时候，电瓶车在地面上形成非常清晰的倒影。有几天监控画面里频繁出现两个重叠的检测框——一个是车身本身，另一个是倒影。

NMS理论上可以抑制重叠框，但倒影和车身之间有一定偏移，IoU不够高，NMS没把它们合并掉。

对策是加了基于位置的逻辑过滤：检测框之间距离过近（中心点距离小于框宽的一半）且置信度差异不大时，只保留置信度更高的一帧框。更彻底的方案是在预处理阶段对图像下半部分做弱化处理，但这样会影响对车身低矮部分的检测，不推荐。

5.3 场景三：外卖箱被当成电瓶车本体

有一类误报特别有意思：外卖小哥推着电瓶车进电梯时，车停在角落，人站在车前面，外卖箱被摄像头拍到，箱体的反光材质和轮廓在模糊条件下会触发检测。

这个问题的根源在于，我把标注规范设为"外卖箱可以不包含在框内"，导致模型没有充分学习"外卖箱是电瓶车的一部分"这个关联。后期调整标注策略，外卖箱明显高出车身的，整体框选包含；模型学习到箱体与车身的关系后，孤立箱体的误报就消失了。

经验是，规范标注的覆盖范围尽可能贴合真实使用场景中的整体观感，不要为了框的"干净"而把所有附属物都排除掉。

5.4 场景四：夜间低照度下漏检率飙升

夜间漏检是另一个大坑。电梯轿厢夜间环境光只有几瓦的LED灯，摄像头为了保持画面亮度会自动拉高增益，结果图像噪声非常大。模型在这种图像上输出的特征置信度全面走低，0.5的阈值下一大半电瓶车都检不出来。

处理手段有几个层次：

• 夜间专用预处理：对低照度帧做自适应直方图均衡化（CLAHE），把暗部细节拉出来。实测mAP在夜间验证集上提高约6个点。
• 阈值自适应：检测置信度跟随帧质量动态调整。帧质量评估可以用简单的灰度方差，画面灰度方差低时认为是低照度帧，置信度阈值自动从0.5降到0.3。
• 数据层面拍摄夜间样本：在训练数据中把夜间电梯监控视频的比例提到25%。这是最根本的解法，预处理和阈值都是兜底。

5.5 误报率评估：别被训练指标骗了

模型在验证集上的mAP不能代表现场误报率。我在模拟项目X的8部电梯上做了连续两周的现场统计：

这个误报水平勉强可接受。要把误报压到更低，单纯靠模型已经很难了，需要结合业务逻辑：告警后如果五秒内检测框消失且未持续跟踪，就自动撤回告警；物业确认误报后，可以把该截图回传作为新的负样本，进入下一轮迭代训练，形成数据闭环。这也是我在结尾部分建议的第一个扩展方向。

6. 中英文双版、源码组织与效果演示呈现

标题里提到"中英文双版"，这里分享一下我实际处理多语言和演示展示的思路，这部分容易被当作小事忽略，却是项目能不能被更多人真正用起来的关键。

6.1 为什么模型本身不做中文标签

很多项目犯过一个错误：直接把中文"电瓶车"作为训练的类别名。这在单语言环境没问题，但一旦要出国际版、或者部署在境外项目上，重新训练成本很高。

正确做法是训练时类别名保持英文（例如e_bike），推理输出的只是一个类别编号（比如0）。具体显示成"电瓶车"还是"Electric Bicycle"，由后处理层的标签映射表决定。改一行配置文件就能切换语言，不需要动模型。

LANG_MAP = { "zh": {0: "电瓶车"}, "en": {0: "Electric Bicycle"}, } def get_label(lang: str, class_id: int) -> str: return LANG_MAP.get(lang, LANG_MAP["zh"])[class_id]

另外UI层的所有提示、告警模板、统计报表字段，都需要做语言抽离。如果项目方后续要出多语言版本，这一步不做的话后期改起来很痛苦。

6.2 源码目录怎么组织才不劝退

一个完整的检测项目源码，至少包含这几个模块：

elevator_ebike_detection/ ├── configs/ │ ├── data.yaml # 数据集配置 │ └── deploy.yaml # 推理部署参数 ├── data_preprocess/ │ ├── extract_frames.py # 视频抽帧 │ └── split_dataset.py # 按场景划分数据 ├── train/ │ ├── train.sh # 训练脚本 │ └── val_metrics.py # 验证指标统计 ├── inference/ │ ├── onnx_infer.py # ONNX推理 │ ├── tensorrt_infer.py # TensorRT推理 │ └── tracker.py # 跟踪逻辑 ├── alarm/ │ ├── alarm_manager.py # 告警状态机 │ └── notifier.py # 告警通知（webhook/微信/钉钉） ├── webui/ │ ├── app.py # 实时监控界面 │ └── templates/ # 页面模板 └── README.md

源码清楚的关键不在于命名多漂亮，而在于每个文件只有一个职责。我在项目初期把训练、预处理、可视化全部塞在一个脚本里，后来自己看都费劲，重构之后才敢往外发。

6.3 效果演示的视频要怎么剪

效果演示是很多人印象分的关键。真实录制时不要只录检测成功的片段，我建议三段式：

• 正常检测段：电瓶车从进梯到出梯全程的检测框跟踪，展示框的稳定性和ID持续。
• 干扰测试段：轮椅进电梯、婴儿车进电梯、手持大件物品进电梯，展示不误报。
• 夜间低照度段：夜间光线下的检测效果，证明系统不是只有白天能用。

剪辑时保留检测置信度和帧号信息，增加可信度。演示视频里不要做人工标注叠加——一旦观众发现框不是模型真实输出的，整个项目的信任度就崩了。

6.4 展示Demo的实时预览

除了录制视频，我做了一个简单的WebUI实时预览。用Flask起一个轻量服务，读取本地视频流或USB摄像头，把YOLOv8的检测结果实时渲染到网页上，支持中英文切换按钮。

# app.py 核心逻辑（简化） from flask import Flask, Response import cv2 app = Flask(__name__) def generate_frames(): cap = cv2.VideoCapture("demo_video.mp4") while True: success, frame = cap.read() if not success: break detections = detect(frame) # TensorRT/ONNX推理 frame = draw_boxes(frame, detections) ret, buffer = cv2.imencode(".jpg", frame) yield (b"--frame\r\n" b"Content-Type: image/jpeg\r\n\r\n" + buffer.tobytes()) @app.route("/video_feed") def video_feed(): return Response(generate_frames(), mimetype="multipart/x-mixed-replace; boundary=frame")

这样一个接口，浏览器直接访问就能看到实时检测效果，比让人下载视频文件友好太多。中英文切换通过URL参数或前端下拉框实现，后端按语言返回对应的标签文字。

7. 模型优化的进阶思路：蒸馏、剪枝与持续迭代

模型能跑起来之后，后面还有很长一段路可以优化。如果你不满足于当前的精度和性能，下面几个方向值得研究。

7.1 知识蒸馏：让小模型学大模型

YOLOv8s的精度虽然够用，但某些极端遮挡场景下还是不如YOLOv8m稳健。如果部署硬件性能捉急，没法上大模型，可以尝试知识蒸馏的思路：先用同结构的YOLOv8m训练一个Teacher模型，再用Student模型（s或n）去学习Teacher的输出分布，包括软标签和中间特征。

实际操作中，最简单有效的蒸馏方式是在损失函数里加一项Teacher和Student输出特征之间的L2距离。训练脚本我用的是YOLOv8官方提供的蒸馏接口，配置里指定teacher模型路径即可。实测下来，蒸馏后的s模型在夜间数据上mAP提升了1.5到2个点，而推理速度和未蒸馏版本完全一样。这对于受限算力的项目是一个纯赚的优化。

7.2 稀疏化训练与剪枝

YOLOv8的卷积层存在大量冗余通道。通过稀疏化训练（在损失里加上BN层缩放因子的L1正则），大部分通道的缩放因子会趋向于0，然后就可以安全地剪掉这些通道。

剪枝后的模型需要微调几个epoch，精度会有小幅回弹。我在一次尝试中把s模型的推理延迟从35ms压到了22ms，精度损失控制在0.5个点以内。代价是剪枝率需要反复试验，剪太狠精度崩了很难恢复。这个方向适合对延迟有极端要求的场景，否则不建议冒这个险。

7.3 数据闭环：让系统越用越准

系统部署之后，把现场的误报截图和漏检视频持续回流到训练集，定期增量训练，这是一套"数据闭环"机制。

我建了一个简单的回传接口：物业后台一键标记"误报"，该帧图像自动存到负样本库；每到周末自动统计本周新增样本，触发增量训练任务，训练完成后自动验证并推送新模型到设备。整个过程不需要算法工程师参与，运维同学就能操作。

这个机制带来的提升很可观。第一轮增量训练后，误报率下降了约40%，因为系统每天都在看到更多维度的真实电梯环境。模型不是一次性交付的产品，而是会随着数据积累越来越贴合现场的系统。

7.4 多场景迁移的注意事项

电梯电瓶车检测这个方案，大概率会被拿去适配其他场景——比如楼道、单元门、地下车库入口。迁移到新场景要注意：

• 摄像头视角发生大变化时，验证一下mAP和误报率再决定是否需要补充数据，不要直接沿用老模型。
• 光照条件不同的场景（户外比轿厢内复杂得多），户外强光、逆光、阴影交替的情况，现有模型需要额外训练适配。
• 告警策略也要跟着变。楼道场景的目标是"阻止电瓶车进入"，和电梯的"发现电瓶车在轿厢内"逻辑不同，阈值和跟踪确认逻辑都要微调。

8. 项目收尾的经验总结

做到这个程度，整个项目从数据采集到现场部署的完整链路算是打通了。最后再分享几点逼坑心得。

数据标注永远值得花最多时间。模型训练、调参、部署优化加起来花的时间，和标注之前的数据清洗、规范对齐相比，后者对最终精度的影响大得多。宁可前期多花一周把标注规范理清楚，也不要训到一半发现数据有大量脏标签，返工成本极高。

告警逻辑和模型同等重要。没有后处理的裸模型，在真实电梯里根本没法用。多帧确认、目标跟踪、状态机——这些工程侧的逻辑，决定了系统是给物业帮忙还是添乱。很多人调了半天模型精度，精度上去了误报反而更严重，漏检却没怎么改善，就是因为忽略了后处理层的设计。

中英文双版的实现方式，强烈建议从一开始就按语言无关的思路来设计。即便当前没有国际化需求，类别名用英文、UI语言走配置文件，这个习惯在后续任何需要多语言扩展的项目里都会省很多事。

效果演示不是包装，是验收的一部分。如果演示视频里出现5个检测框有2个是误报，说明系统还没到能交付的状态，不要心存侥幸推上线。让系统在真实环境多跑两周，统计出真实的检出率和误报率，再考虑对外展示。

这个项目后续要扩展的方向也很多：接入电梯制动控制（识别后阻止关门）、统计电瓶车进梯的高发时段和楼栋分布、和门禁系统联动等等。如果有机会做二期，我可能会优先把数据闭环和告警联动做深，这两部分带来的实际价值比单纯优化模型更大。