这两年做城市管理信息化项目，最多的需求不再是简单的视频监控上墙，而是把摄像头拍到的东西自动变成工单。我参与过某地级市的智慧城管平台改造，核心就是计算机视觉与智能分析。所谓智慧城管，说白了就是让前端摄像机自动识别违法停车、占道经营、垃圾堆积、渣土车遗撒等事件，然后推给处置部门。这篇文章想和你聊聊我在这个项目里踩过的坑、调过的参数、改过的算法逻辑。如果你也在做类似的环卫、执法或网格化项目，或者正准备跟算法团队对接场景需求，这篇内容应该能帮你少走不少弯路。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秒之间，经过实际使用，这个范围既能让坐席有时间抓图，又能保证不会刷屏。作为收尾，我个人的体会是：智慧城管里的算法不是最难的，难的是让算法符合业务习惯，让数据闭环跑起来。代码和模型只是整个系统的一小部分，真正花时间的反而是场景定义、数据标注、阈值调整和各个部门的扯皮。我们后来把处理经验沉淀成一份《场景特征与参数配置手册》，新同事半天就能上手调算法，不用每次从头试。如果你也准备做类似项目，建议一开始就安排一个人专职收集误报和漏报案例，每天反馈给算法团队，不要等上线之后再来“优化”。这样，越用越准，项目才会真正被一线接受。
这两年做城市管理信息化项目，最多的需求不再是简单的视频监控上墙，而是把摄像头拍到的东西自动变成工单。我参与过某地级市的智慧城管平台改造，核心就是计算机视觉与智能分析。所谓智慧城管，说白了就是让前端摄像机自动识别违法停车、占道经营、垃圾堆积、渣土车遗撒等事件，然后推给处置部门。这篇文章想和你聊聊我在这个项目里踩过的坑、调过的参数、改过的算法逻辑。如果你也在做类似的环卫、执法或网格化项目，或者正准备跟算法团队对接场景需求，这篇内容应该能帮你少走不少弯路。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秒之间，经过实际使用，这个范围既能让坐席有时间抓图，又能保证不会刷屏。作为收尾，我个人的体会是：智慧城管里的算法不是最难的，难的是让算法符合业务习惯，让数据闭环跑起来。代码和模型只是整个系统的一小部分，真正花时间的反而是场景定义、数据标注、阈值调整和各个部门的扯皮。我们后来把处理经验沉淀成一份《场景特征与参数配置手册》，新同事半天就能上手调算法，不用每次从头试。如果你也准备做类似项目，建议一开始就安排一个人专职收集误报和漏报案例，每天反馈给算法团队，不要等上线之后再来“优化”。这样，越用越准，项目才会真正被一线接受。