这两年做城市管理信息化项目最多的需求不再是简单的视频监控上墙而是把摄像头拍到的东西自动变成工单。我参与过某地级市的智慧城管平台改造核心就是计算机视觉与智能分析。所谓智慧城管说白了就是让前端摄像机自动识别违法停车、占道经营、垃圾堆积、渣土车遗撒等事件然后推给处置部门。这篇文章想和你聊聊我在这个项目里踩过的坑、调过的参数、改过的算法逻辑。如果你也在做类似的环卫、执法或网格化项目或者正准备跟算法团队对接场景需求这篇内容应该能帮你少走不少弯路。1. 智慧城管视觉应用的整体设计思路1.1 需求拆解城市管理要的是“工单”不是“图片”很多项目刚启动的时候甲方提的需求是“帮我识别出哪条路有违停车”“我要能自动发现占道经营”。但真正做需求调研时才发现城市管理各科室和街道中队要的不是一张标注框的截图而是一条能直接下派、处置、结案的工单。两者之间差着一条很长的链路算法识别出事件后需要生成事件描述、截取现场图片或短视频、关联摄像机编号与地理位置、判断重复事件、分拨到对应网格责任人、处置后拍照反馈、再由算法或人工核验结案。如果只做一个“识别”模型项目最多算完成30%。我建议在一开始就把业务闭环画出来哪怕用最简单的流程图。某市项目里我们花了整整一周时间跟数字化城管指挥中心梳理事件类型最后归纳出高频、中频、低频三类高频事件违法停车、占道经营、垃圾箱满溢、道路不洁。这些需要5分钟内自动发现误报率可以放宽到30%以内因为有人复核。中频事件渣土车未密闭、工地出入口污染、违规户外广告。这些需要结合车牌或区域属性准确率要求更高否则投诉情况会激增。低频事件井盖缺失、道路破损、焚烧垃圾。这些用普通检测难度大需要结合多帧和上下文或者依赖人工视频巡逻辅助。把业务场景拆成这三类再决定算力投入、算法精度、预警阈值整个设计就有抓手了。1.2 场景选择与优先级评估计算机视觉算法不是万能的不同场景的成熟度差异非常大。做过几个项目后我给场景的可行性打了分场景识别难度光线敏感性处罚环节复杂度推荐优先级违法停车较低中夜间靠车灯低直接贴单移车高占道经营中高夜间摊贩打伞难辨中需要劝导高垃圾堆积低低低环卫清扫中渣土车未密闭高需要侧上方视角中高处罚争议多中井盖缺失高小目标高高安全责任大低为什么把违法停车放第一位因为车辆检测算法已经非常成熟公开数据集和预训练模型多且车体特征稳定不容易受季节影响。占道经营稍微麻烦一点但可以通过划定“电子围栏区域”在区域内检测人和摊位。垃圾堆积最容易做但真正做好需要分清“临时放置”和“长期堆积”否则环卫工人刚清完又报警特别容易烦。这里有个容易被忽视的点摄像头视角。同一个算法装在3米高的立杆上和装在6米高的横臂上效果天差地别。违法停车最好用球机自动巡检画面里车辆占整个图幅的1/4以上占道经营则需要俯视角度看到摊位和遮阳棚渣土车识别一般要正面和侧面两个机位配合。我们前期因为部分点位借用公安的杆子视角太低导致大量漏检后来专门跟市政协调把摄像机挑到4.5米以上事件检出率立刻提升了20%以上。1.3 算法基座与硬件选型逻辑视觉算法这块我们接触过两条路线一条是直接用厂商的“黑盒”一体机另一条是基于开源模型自研。一体机的好处是省事坏处是难定制比如想识别“摊位越线”这种行为厂商往往要收定制费而且迭代周期以月计。所以我们最终选择了半自研检测、分类、跟踪用开源框架训练通过标准接口接入现有的视频平台。目标检测框架我推荐的排序是YOLOv8、YOLOX、RT-DETR。YOLOv8生态好部署简单适合快速落地YOLOX在复杂场景下稳定性不错但是调参稍麻烦RT-DETR精度高但是推理速度慢边缘端跑不动。我们最终在边缘盒子用YOLOv8s在服务器上用YOLOv8m性价比最高。跟踪方面如果只是单个摄像机内判断事件DeepSORT就够用了但是算力紧张或者目标密集时ByteTrack更合适它不依赖外观特征对遮挡和短暂丢失更鲁棒。我们做过对比在农贸市场门口这种人流密集地方ByteTrack的ID切换率比DeepSORT低了将近一半而且代码实现更简洁。硬件选型上我们试过GPU服务器、边缘计算盒子、带算力的智能摄像机。结论是不要想着一台服务器跑所有摄像头的全部算法。一个摄像头同时跑检测跟踪分类1080P视频流大约需要1-2路并行占满一张普通GPU。摄像头数量超过100路时服务器成本会高到离谱。我们最终采用“前端盒子过滤中心服务器精算”的分布式架构普通摄像机只传视频流边缘盒子负责抓拍疑似事件并上传压缩后的ROI图片中心服务器再做二次确认。这样既保证实时性又让中心算力专注于复杂模型。2. 核心场景的算法实现与参数细读2.1 违法停车检测从“看见车”到“判断违停”违法停车绝对不是“检测到车停在禁停区就报警”这么简单。你想想路上堵车、上下客、临时靠边这些都会被识别成违停然后指挥中心收到一堆无效工单。我们踩过这个坑前期准确率只有62%主要原因就是没有时间维度。正确的做法是加一个状态机。对每个目标车辆持续跟踪它的位置和状态。当车辆进入禁停区域后开始计时如果车辆连续停留时间超过设定的阈值比如180秒才判定为违停并且生成一张带时间水印的图片作为证据。这个阈值是跟城管和交警反复确认过的。市区严管路段设成60秒普通路段120秒学校门口可以放宽到180秒因为接送孩子需要时间。具体算法流程分四步用检测模型找出车辆目标记录车辆中心点坐标。用ByteTrack跟踪车辆给每个目标一个唯一ID。判断目标中心点是否在禁停多边形内这个多边形就是电子围栏通过地图工具画。维护一个状态字典记录每个ID的首次进入时间一旦离开围栏就清除记录停留时间超过阈值触发报警。关键参数上检测置信度建议设0.45以上太低会有一堆误检比如把“车”广告牌当成车。NMS IoU阈值设0.5跟踪丢失容忍帧数设30帧这样车辆被短时间遮挡后不会立刻丢ID。另外车辆检测框用最小外接矩形还是带旋转角度的矩形如果是正对摄像头的画面普通矩形够用如果是斜视画面建议加一个角度回归分支否则违停车辆的框会框住大片路面影响中心点定位。我们后来用YOLOv8的obb模型漏检率又降了3个百分点。2.2 占道经营识别区域规则与时序逻辑配合占道经营比违停要“人情味”重一点。有些地方摆摊是允许的只是不能越过划定的线。所以算法不能只识别人和摊位还要识别“行为是否越界”。我们设计的方案是先用检测模型识别出“摊位”目标包括货架、三轮车、遮阳棚这类特征明显的物体然后用语义分割模型识别出“经营区域”和“禁止跨线”区域将两者叠加判断摊位的边缘是否越线。这里需要注意摊位目标经常被顾客遮挡所以最好用多帧投票连续10帧里有8帧检测到摊位越线才判定为“正向越线经营”避免路人经过造成的误判。难点在于“遮阳棚”这个类别变化很大。红蓝条纹棚、白色圆棚、黑色网布棚在不同光照下特征差异很大。我们最初只标注了红条纹棚结果夏天一到遍地都是白棚检测模型直接晕了。后来扩充了5000多张各类遮阳棚的图片并用数据增强模拟早晨、傍晚、阴天、雨天的光照才好一些。另外很多城管中队反馈他们要的是“预警”而不是“报警”。凌晨五点是菜市场周边占道经营的高峰期但是执法人员还没上班如果算法报得太早容易激化矛盾。我们最后在平台上加了“生效时段”配置晚上10点到凌晨6点只生成“预警”不生成工单早上7点后才自动转成待核查工单。这种看似简单的逻辑比任何算法优化都管用。2.3 垃圾堆积与渣土车识别细粒度分类与属性识别垃圾堆积检测最容易但也最容易被误报。绿化带里的树叶、路边施工堆放的石子、临时装卸货物都会被当成垃圾。我们的优化思路是给检测模型增加“垃圾面积”和“垃圾位置”两个条件。先检测出“疑似垃圾”的目标然后计算目标框对应的像素面积占整张图的百分比。小于一定阈值的比如图幅的0.1%直接忽略因为那么小的垃圾环卫工几秒钟就清走了没必要生成工单。另外如果垃圾目标位于十字路口、工地门口很可能是临时掉落需要等待多帧确认如果在人行道中间长期不变那基本就是堆积。渣土车未密闭识别稍微复杂因为车斗状态很小有时候连人眼都看不清。我们使用“车辆属性识别”模型先检测渣土车再对车斗区域做二分类空载/满载密闭/未密闭。这里的关键是数据采集我们专门在某工地门口架设了卡口摄像头连续采集了两个月才凑齐雨天、夜晚、逆光等条件下的图片。很多算法团队不重视数据采集觉得拿公开数据集微调就行结果到了现场发现车辆颜色和场景完全对不上。夜晚识别渣土车是个大坑。车灯反光、车身泥土、车斗阴影都会导致误判。我们试过几种方案最后用的是“红外补光低照度成像”但城市道路不允许亮红外灯所以退而求其次让摄像机自动切换成宽动态模式算法侧则对车斗区域单独做直方图均衡化。效果不能说百分之百但误报率从一天300多起降到了40多起勉强能用。3. 实操过程中的关键环节与踩坑记录3.1 标注样本质量比数量更重要很多算法工程师一上手就拉几百个G的图片让标注团队干活结果模型训练出来效果很差。问题大多出在标注一致性上。我们曾让两家标注公司标同一个项目他们对“占道经营”的理解完全不一样一家只标摊贩和货物另一家把顾客和路人也标进去了。后来我们开了三次标注意见会制定了详细的标注规范比如违停车只标车身不标地面阴影车被遮挡超过30%不标。摊位包括货架、桌板、悬挂商品但顾客拿在手里的商品不标。垃圾只标长时间停留且面积大于某阈值的垃圾堆不分大小件。标注规范定好后还用“双人标注抽检”的方式保证质量。每个人标注的图片另一个人随机抽20%复核两人不一致的地方就是问题多发区。另一个容易被忽略的点是标注框的边界要贴着物体边缘不要留太多白边否则训练时模型学到的特征混入背景导致框飘移。我们项目里还用了“半自动标注”提速先用第一版模型跑一遍所有历史图片生成预标注然后人工只需要调整错误框。这个操作能把标注效率提高3倍以上但前提是模型不能太烂否则标注员会疯掉。3.2 训练与调参精度和速度的平衡模型训练这块我强烈建议先跑一个“基线模型”再根据实际效果调参不要一上来就追求SOTA。我们的基线配置是YOLOv8m、输入尺寸1280x1280、batch size 16、SGD优化器、初始学习率0.01用CosineAnnealing调度。训练大概150轮早停条件设为验证集loss连续20轮不降。调参时最影响性能的四个点输入分辨率。1080P画面如果缩到512小目标基本就废了。我们违停项目用1280垃圾检测用960占道经营用1280分辨率上去之后小目标mAP提升了12%但推理速度慢了30%。如果你有边缘盒子这个取舍要提前想好。数据增强。Mosaic增强对小目标不友好尤其是车斗、垃圾等小物体。我们用Mosaic时把比例限制在0.5并加入AutoAugment效果比纯Mosaic稳定。正负样本比例。城市管理场景容易把“人”误检成“摊位”因为人也是直立的。给每个类别设置不同的损失权重摊位、货物权重高一些防止类别混淆。损失函数。分类损失使用BCE回归损失使用CIoU同时启用FocalLoss来处理难易样本不平衡。这样能把误报压下来。训练完一定要做“场景迁移测试”。我们训练集用的是普通枪机画面结果在球机上测试由于球机有畸变、且目标大小随焦距变化检测框抖动非常厉害。解决办法是在训练集里加入球机模拟视角的图片或者用畸变校正算法预处理。前者更有效。3.3 边缘端部署与视频流接入边缘端部署最大的坑是“同一套模型在不同硬件上跑出不同效果”。我们最初在某主流厂商的盒子上跑YOLOv8s转换到TensorRT之后精度掉了约2%后来通过“PTQ量化感知训练”找补回来一点。这里有几个经验用INT8量化前先准备一个小的校准集从训练集中均匀抽样500张一定要包含夜间、雨天、逆光的样本否则量化后白天的效果可能OK晚上直接失效。部署时不要用动态batch固定batch size为1减少显存碎片。视频流解码要与检测线程解耦用队列缓冲区。我们早期把解码和检测放在一个线程里结果网络抖动导致检测线程阻塞整个任务跟着卡死。视频流接入方面城市里的摄像机品牌很杂RTSP流格式五花八门。我们统一用GbE连接流媒体网关把RTSP转成YUV数据再送给算法。需要注意的是RTSP拉流重连机制一定要自己写。摄像机断网后恢复网关有时不会自动重新拉流导致算法一直处理黑帧还给你报“画面异常”。后来我们在网关层加了一个心跳检测每30秒检查一次帧间隔超过3秒没新帧就主动重新拉流。3.4 工单闭环与人工复核流程算法识别出来只是开始真正让城管同事用得起来是后续的闭环设计。我们的流程是算法生成事件推送至指挥中心中心坐席在弹窗里看两张图现场图和算法标注图点“受理”才会生成工单点“误报”则进入误报库每周统计误报原因并反馈算法团队。如果没有人工复核这一环节城管队员很可能被无效工单搞烦最后把系统关掉。人工复核界面也有讲究。图片上要显示抓拍时间、摄像机编号、坐标、置信度最好能叠加电子围栏的边界。另外一个体验细节是如果同一个位置半小时内连续报警前端要自动合并只显示一条“连续发生N次”的提示。我们曾经没有做去重某天一家水果店把货品摆到路沿算法每隔10分钟报一次一天报了40多次坐席差点崩溃。人工复核的数据我们还用起来做“强化反馈”把坐席标为误报的图片抽取出来加入训练集每周做一次增量训练。项目运行了三个月违停误报率从38%降到15%以下靠的全是这套数据闭环。4. 常见问题与排查技巧实录4.1 漏检多先看你的分辨率与标注框有段时间我们违停检测漏检率高排查完发现是分辨率问题。摄像机画面有透视关系远处的车只占几十个像素模型根本认不出来。这时候不要急着调模型先看可视范围。一般对策是把远端画面纳入“虚拟检测区”之外只检测中近景或者用球机自动巡航到远处再抓拍而不是在广角画面里硬扛。标注框也是一个因素。如果你标注时把“车头”和“车身”分开标模型学到的特征就会分裂。我们最后统一用车身整体框并且框的位于画面下方遮挡区域时只要可见面积超过70%就标。还有一点夜间标注时不要用过度增强的图片否则模型学到的全是噪点纹理。4.2 频繁闪报状态机比单帧判断靠谱不少开发第一版时是“每帧检测有目标就报”结果出现大量闪报车在路口等红灯被报违停、人被树挡住导致摊位检测又消失又出现。正确的做法是前面提的状态机。实现时一定注意时间戳要用视频帧的PTS而不是服务器系统时间否则视频缓冲延迟会导致状态切换异常。我们遇到过一个问题ByteTrack在目标短暂丢失后重新匹配ID会变成一个新ID于是状态机里出现“一个新ID刚进入围栏就停留很久”的怪象。解决办法是加一个“轨迹记忆”机制在栅栏区域附近保存最近2秒的目标特征当出现新ID时先做特征匹配再继承旧ID的状态。这个机制让违停漏报减少了15%。4.3 夜间效果差图像增强与双光融合城市管理的很多事件发生在夜间而夜间是视觉算法最脆弱的时候。我们试过很多图像增强方法比如Retinex、直方图均衡化、暗通道去雾但通用增强会把噪声一起放大反而误检更多。后来我们只对ROI区域比如车斗、摊棚、垃圾堆做局部增强效果稳定得多。有条件的地方用双光摄像机。一个可见光通道一个红外通道两个通道同时跑模型然后对检测框做IOU融合。只有两个通道都检测到的目标才输出置信度取两者平均值。我们项目里用这个方法把夜间垃圾堆积误报率从42%降到19%。不过双光摄像机价格偏高目前只在重点点位部署。4.4 验收指标怎么定准确率、召回率与响应时间项目验收时甲方一般会问“准确率多少”这时候要先把口径说清楚。我们用的指标是事件检出率真实发生的有效事件中算法正确生成告警的比例目标90%以上。准确率误报率算法生成的告警里有效事件所占比例目标70%以上。平均响应时间从事件发生到系统弹出告警的时间目标30秒内。工单闭合率最终处置完毕并确认有效的事件占生成工单的比例这个往往受执法流程影响不能全怪算法。我们在验收时专门设置了“场景测试集”把三个月历史录像按白天、黑夜、晴天、雨天、堵车、节假日等条件分层抽样一共2000条片段然后让算法批量回放统计上述指标。这样测试才能让双方信服而不是算法团队自己说“效果不错”。另外要提醒一点响应时间不是越短越好。如果检测太灵敏车辆刚停3秒就报警会产生大量无效工单。我们违章停车事件最终响应时间设置在45秒~90秒之间经过实际使用这个范围既能让坐席有时间抓图又能保证不会刷屏。作为收尾我个人的体会是智慧城管里的算法不是最难的难的是让算法符合业务习惯让数据闭环跑起来。代码和模型只是整个系统的一小部分真正花时间的反而是场景定义、数据标注、阈值调整和各个部门的扯皮。我们后来把处理经验沉淀成一份《场景特征与参数配置手册》新同事半天就能上手调算法不用每次从头试。如果你也准备做类似项目建议一开始就安排一个人专职收集误报和漏报案例每天反馈给算法团队不要等上线之后再来“优化”。这样越用越准项目才会真正被一线接受。