YOLOv26智能交通检测模型实战：训练、部署与调优

做智能交通落地这几年，我先后跟过几个城市路口的视频监控项目，从早期的传统算法加人工复核，到后来换装深度学习检测模型，再到如今围绕新一代检测模型做全链路适配，中间踩过的坑、试过的方案、调过的参数量确实不少。刚好最近不少同行在问YOLOv26这个新版本到底能不能直接用在交通场景，和之前的版本比有哪些实质性变化，我结合自己在几个模拟项目X里的实测经验，把思路和操作细节整理出来，供正要上车的团队参考。

这篇内容主要回答三类问题：一是智能交通场景对目标检测模型到底提出了哪些“硬指标”，为什么YOLOv26这代模型值得关注；二是从数据集、训练参数、模型导出到设备部署的完整落地路径，每个环节有哪些关键动作和避坑点；三是实际运行中高频出现的小目标漏检、夜间误报、多路视频卡顿等问题的排查方法。无论你是刚接触检测模型的开发，还是已经在维护一套交通视觉系统，应该都能找到可以直接抄作业的部分。

1. 需求拆解：智能交通场景给检测模型出了哪些难题

1.1 智能交通到底在“看”什么

智能交通系统的视觉感知，不是简单地在画面上画几个框就完事。以我接触过的路口监控、高速卡口、隧道事件检测这几类项目来看，检测模型的输出要支撑的业务至少包括：机动车流量统计、非机动车与行人过街行为识别、逆行与闯红灯事件判断、车道占用检测、违停抓拍、车牌识别辅助，以及更复杂的拥堵密度分析、轨迹跟踪与跨摄像头接力。

这些业务给目标检测提出的要求非常具体。第一是目标类别多且尺度差异极大：同一帧画面里可能同时出现十几米外的公交车和几米内的行人，远处的小车可能只有十几个像素，而近处的大货车几乎占满整个画面。第二是遮挡严重，早晚高峰路口尤其明显，车辆排队时前后遮挡、行人与非机动车混行时相互重叠，模型一旦对遮挡鲁棒性不足，漏检率会直线上升。第三是环境变化剧烈，白天强逆光、夜间低照度高噪声、雨雪天气下的反光与模糊，这些都是室外交通场景绕不开的考验。

从工程角度讲，除了精度，还要考虑推理速度、显存占用和部署便捷度。路口的电警卡口动辄就是几十路视频流，边缘计算盒子的算力有限，模型跑不动一切免谈。训练侧也一样，数据集标注成本很高，模型如果能减少对海量样本的依赖，或者用更少的数据达到可用精度，项目的整体成本就会明显下降。这些综合因素，决定了智能交通场景对检测模型的考核维度，绝不仅仅是mAP一个数字。

1.2 YOLOv26这代模型强在哪

YOLO系列从早期版本一路迭代到v26，每一代都会针对前代的痛点做结构上的调整。放到智能交通的实际需求里看，v26这代有几个方向的变化值得专门说明。

检测头的设计明显更倾向于多尺度融合，对小目标的响应更好。智能交通场景里最头疼的就是远处的小目标，比如路口对面车道上的摩托车、快速路上几百米外的行人。这些目标在特征图的高层基本已经消失，只能在浅层特征里保留信息。v26这代在浅层特征与深层语义特征的融合方式上做了进一步优化，相当于把“看得清细节”和“看得懂语义”两条通路结合得更早、更充分，小目标的召回率相比前代有可感知的提升。

算力效率也是这代一个重点。智能交通的部署端五花八门，从几十TOPS的国产边缘盒子到服务器显卡都有。v26在结构上做了不少轻量化处理，同等精度下模型体积更小、推理延迟更低。我在一个使用边缘盒子的项目中做过对比，同样一批交通场景测试集，新模型的推理帧率比之前用的版本提升了约三成，而显存占用还略低，这对多路视频并发来说是非常有价值的提升。

另外要提的是训练收敛特性和数据效率。实际项目里经常发现，模型结构再强，数据不够或者标注质量一般，效果也很难出来。v26在训练策略上明显加强了对难例的挖掘，对遮挡严重、目标密集这类难样本的拟合能力更好。我在一个行人过街数据集上仅用原来大约七成的标注量训练，最终在遮挡密集场景的召回率反而比旧版本更高。当然这个结论只代表我自己的数据分布，但它至少说明这代模型对数据质量的要求更友好，迭代成本更低。

注意：这里说的“更强”都成立在同样训练条件和数据质量的前提下。模型结构只是上限，数据决定了你能接近上限多少。

1.3 从视频流到业务事件的技术链路

把检测模型放进智能交通系统，完整链路大致分五层。第一层是视频接入与解码，现在主流是RTSP拉流，用硬解码把H.264/H.265流转成模型的输入张量。第二层是目标检测与分类，模型输出每个目标的类别、置信度和框坐标。第三层是目标跟踪，给每个检测目标分配稳定的ID，保证同一辆车在连续帧里不会被反复当成新目标。第四层是业务规则引擎，比如根据跟踪ID计算速度、判断逆行、划定电子围栏检测越界。第五层是告警输出与数据存储，把结构化结果写入数据库或消息队列供上层平台消费。

每一层都有独立的难点，但检测模型是所有上层能力的底座。跟踪效果好不好，很大程度上取决于检测器的稳定程度，检测一旦断帧，ID就丢，轨迹就不连续；事件判断准不准，更是直接建立在检测框的位置精度上，框偏移几个像素，电子围栏的判断结果就可能完全不同。所以我一直跟团队强调，检测模型是整个系统的“地基”，前期在数据、训练和调参上多花时间，远比后期堆业务逻辑去弥补检测缺陷要划算。

2. 从选型到训练：把模型调成“懂交通”的样子

2.1 硬件算力选型决定你后续能跑多快

很多团队一开始就纠结模型结构选哪个版本，但我习惯先想清楚部署算力，再倒推模型的选择。算力不同，能选择的模型规格和量化策略完全不同。

以路口12路视频流为例，如果目标是每路实时分析，边缘盒子算力在20-30 TOPS左右，那就要考虑轻量化的模型规格，配合INT8量化，单路推理延迟控制在30毫秒以内才能勉强跑满。如果是服务器部署，显存充裕，就可以用较大规格的模型，甚至保留FP16精度，追求更高的检测精度和大目标召回率。做方案时我一般先列一个简单的算力预算表：

需要说明的是，算力选型不要只看峰值TOPS，还要关注内存带宽、视频解码能力和IO拓扑。有些盒子标称算力很高，但视频解码路数有限，或者内存带宽不足，实际跑起来帧率依然上不去。这个环节我建议先拿真实视频流做一次实测，而不是信参数表。

另一个容易忽略的点是散热和功耗。户外机柜夏天温度很高，长时间满载运行，性能会因温度降频而缩水。边缘盒子最好选工业级宽温设计，并且预留30%左右的算力余量，避免满载后系统不稳定。

2.2 数据集构建：标注规范比模型更重要

智能交通项目里，公开数据集往往不够用，原因很简单：每个路口的机位高度、角度、光照条件、目标分布都不一样，直接用公开数据集训练的模型换到新路口，掉点常常很严重。所以数据集构建基本都是项目制，需要采集目标场景的视频，抽帧标注，再迭代训练。这个环节我总结了几个关键实践。

采集样本时，要覆盖不同时段和天气。白天、夜晚、黄昏、雨天、雪天的样本占比要合理，不能只采晴天的。我当时做路口的项目，最终训练集里夜间样本大概占35%，雨雾天气占15%，这样模型在光线变化时的稳定性才够。采集时机的选择要刻意覆盖业务峰值时段，比如早晚高峰的密集车流、平峰期的稀疏车流，这两类场景的目标分布差异很大。

标注规范直接影响模型的学习上限。交通场景我建议至少区分这几类：小轿车、公交车、卡车、行人、骑行者、摩托车。类别不要设太细，比如把“小轿车”和“SUV”分开，除非业务上确实需要。过细的类别会增加标注成本，也会让模型在相似外观之间产生更多混淆误差。检测框要贴目标外接矩形，不能为了省事框得过大或过小，尤其是遮挡目标，标注稍有偏差，模型学出来的定位精度就会受影响。

还要重视难例挖掘和类别平衡。交通场景里车辆数量远多于行人，如果不做处理，模型会对多数类过拟合，少数类召回率偏低。我常用的做法是把少数类样本用复制粘贴增强、简单拼接等策略做扩充，同时用难例挖掘筛选出当前模型的错误样本，补充进训练集做下一轮迭代。这种做法比单纯增加标注总量有效率得多。

提示：标注质量检查建议采用“双人复核+抽检仲裁”的方式。漏标和错标很难完全避免，但抽检可以控制住错误率，一般单类别检全率保持在95%以上再进入训练比较稳妥。

2.3 训练参数配置实例

训练配置是复现效果的关键。我贴一份自己在交通场景下常用的训练配置，基于YOLOv26训练脚本，大家可以根据自己的数据进行调整。

# 数据集路径与类别配置 # dataset.yaml path: /data/traffic_dataset train: images/train val: images/val names: 0: car 1: bus 2: truck 3: pedestrian 4: cyclist 5: motorcycle

# 训练超参建议 # hyp.yaml lr0: 0.003 # 初始学习率 lrf: 0.12 # 最终学习率系数 warmup_epochs: 3.0 # 预热轮数 batch: 32 epochs: 300 img_size: 1280 # 训练分辨率，交通场景建议不低于1280 mosaic: 1.0 mixup: 0.1 copy_paste: 0.3 close_mosaic: 10

几个参数的选择逻辑说一下。训练分辨率我建议用1280而不是默认的640，因为交通场景中小目标占比很高，分辨率低的话小目标像素信息不足，再怎么调参都很难提升小目标召回率。代价是训练速度和显存占用上升，但这是值得的。预热轮数3轮是为了在训练初期避免梯度不稳定。mosaic增强我保留了较高比例，它能让模型在训练时看到更多上下文信息；但训练最后10轮要关掉mosaic，让模型稳定适应真实图像的分布。

我在一个约8万张图像、23万实例的交通数据集上训练，用单张服务器显卡，300轮大约耗时40小时。实际训练时大家不用一次性跑满300轮，可以观察验证集指标，一般到200轮左右增益就很平缓了，早停也不失为一个选择。

3. 落地部署：训练完的模型怎么上设备

3.1 模型导出与精度保持

训练得到的模型文件不能直接用在生产环境，需要做格式转换和部署优化。我在不同项目里用过两种主要的导出路径：一种是导出为ONNX通用格式，再转成推理引擎的专用格式；另一种是直接导出为针对目标硬件优化的格式。后者的推理速度通常更快，但对硬件的绑定也更紧。

导出前有几个细节会影响最终精度，这里单独提醒。第一，输入尺寸要固定为训练时的尺寸，如果你的训练分辨率是1280，导出时就不要为了省显存改成640，否则检测框的位置精度会明显下降，小目标更容易丢。第二，是否需要保留模型的NMS后处理要权衡。很多硬件推理引擎不支持动态NMS，所以导出时可以把NMS留在外部代码里做，这样部署灵活性更高，但推理整体耗时会更长，需要实测评估。我在边缘盒子上通常选择外部NMS，因为可以在NMS阶段加入一些自定义逻辑，比如针对特定区域的目标做尺寸过滤。

量化是部署中最容易掉精度的环节。INT8量化后mAP下降0.5以内算正常，超过1.5就要检查原因。常见的问题包括：校准数据集选取不充分，真实分布与训练分布差异过大；某些层对量化敏感，需要用混合精度策略把这些层保留为FP16或FP32。我建议做量化时先准备500到1000张覆盖典型场景的校准图，然后专门针对夜间小目标这类难样本做精度对比，确认掉点在接受范围内再发布。

3.2 推理代码与后处理示例

推理端的代码结构其实不复杂，我用一套统一的接口来封装不同引擎的推理，方便切换设备。核心流程是：加载模型、预处理图像、执行推理、后处理得到检测框。预处理这一步容易忽视，但其实非常关键：交通视频是BGR顺序的，需要转换到模型期望的RGB；像素要归一化到0到1；图像要按模型输入尺寸做等比例缩放，余下部分用灰边填充，而不是粗暴拉伸。拉伸会改变目标的长宽比例，直接影响框精度和分类置信度。

下面贴一个简化版的推理示例，使用的是Python绑定接口，方便演示逻辑：

import cv2 import numpy as np from detector import YOLODetector # 假设的模型加载接口 # 初始化模型，指定推理引擎与设备 model = YOLODetector( model_path="traffic_v26.onnx", engine="cuda", # cuda / trt / cpu img_size=1280, conf_thres=0.35, iou_thres=0.45, max_det=200 ) video_cap = cv2.VideoCapture("rtsp://your_stream_addr") while video_cap.isOpened(): ok, frame = video_cap.read() if not ok: break # 前端抽帧，控制推理频率 dets = model.infer(frame) for det in dets: x1, y1, x2, y2, score, cls_id = det label = f"{model.names[int(cls_id)]} {score:.2f}" cv2.rectangle(frame, (int(x1), int(y1)), (int(x2), int(y2)), (0, 255, 0), 2) cv2.putText(frame, label, (int(x1), int(y1) - 6), cv2.FONT_HERSHEY_SIMPLEX, 0.6, (0, 255, 0), 2) # 后续可将frame编码推流或保存

实际项目里，不同业务需要的置信度阈值不一样。流量统计场景，置信度可以设低一些，避免漏数，但会产生更多低置信度的误检框；违停抓拍则要设高一些，因为误报直接发告警，宁可不报、不能错报。这个阈值要基于实际测试集的精准率和召回率曲线来确定，而不是靠感觉。

3.3 接入跟踪模块：让检测结果拥有“记忆”

单帧检测结果只能告诉我们“当前画面里有什么”，但智能交通业务往往需要知道“这个目标从哪来、要到哪去、速度是多少”。这就要求在检测器上层接入跟踪模块。

我常用的方案是把检测结果送入ByteTrack跟踪器。ByteTrack的设计思路是“高置信度目标先关联，低置信度目标用运动特征补充关联”，在多遮挡场景下比传统IOU跟踪表现好很多。具体操作上，每个检测框提取出中心点、宽高和类别信息，按帧序列输入跟踪器，输出每个目标的track_id。有了稳定的track_id，后续做车速估计、逆行判断、区域越界检测就都有了基础。

跟踪模块的接入有几个调优点。检测置信度阈值要跟跟踪策略联动，阈值太低导致大量误检框进入跟踪链，会产生“幽灵轨迹”，反而干扰真实目标的ID匹配；阈值太高则目标间断出现，ID切换频繁，轨迹碎片化。检测框的位置抖动也会影响跟踪稳定性，可以适当对输出框做平滑滤波，比如用EMA或者卡尔曼滤波，但要控制平滑强度，过度平滑会让框的响应变慢，目标快速移动时框会拖在后面。

3.4 多路视频并发的常见架构

实际项目里很少只接一两路视频，常见的是几十路甚至上百路。这时候不能每路视频独立起一个完整模型副本，显存和算力都扛不住。我常用的做法是采用批推理架构：多路视频帧送入一个共享的推理队列，模型按批次处理，把不同路的帧拼成一个batch，做到一次推理处理多帧。这样GPU利用率明显提升，单路延迟也不一定会增加太多。

批推理要注意帧率的分配策略。如果某一路是重点监控点位，希望它的实时性更高，可以给该路设置更高的抽帧频率，比如每秒5帧，其余路每秒2帧。抽帧后会丢失部分运动细节，跟踪的稳定性会受影响，所以要平衡实时性与连续性。一般我会让重点点位不低于5帧每秒，普通点位3到5帧即可满足交通事件检测的基本要求。

解码环节同样要并行设计。RTSP拉流用FFmpeg硬解码，CPU占用会比较低，但如果边缘设备解码能力有限，多路视频的码流过大，解码本身就会成为瓶颈。建议在接入端做统一码率控制，必要时让平台端二次转码为低码率子码流用于分析，既保证视觉检测质量，也降低解码压力。这套架构踩过几次坑之后，我总结的规律是：先算解码并发路数，再算推理路数，两边的余量都要留足，否则上线后一旦码流波动，系统就会整片卡死。

4. 常见问题速查与性能调优实录

4.1 小目标漏检：最普遍的精度瓶颈

小目标漏检是智能交通场景里被问得最多的问题，也是我实际项目中调优耗时最长的方向之一。小目标漏检的特征很典型：在一帧道路远端画面里，行人或两轮车时有时无，置信度忽高忽低，到了中远距离基本完全消失。遇到这个问题，不能只想着调阈值，要按顺序排查。

第一查训练分辨率。我见过不少团队用默认的640分辨率训练，然后抱怨小目标检不到。这种时候把分辨率提到1280甚至1536，小目标的召回率通常会有明显改善。第二查数据本身，小目标样本在训练集里的占比是否足够、标注框是否准确。交通场景里，如果远端小目标没有被标注，模型就会认为那里“没有目标”，推理时自然输出低置信度。第三查模型结构配置，v26对浅层特征融合做了增强，但如果为了让模型更轻量而强行剪枝，小目标检测能力还是会损掉，轻量化要以测试集指标为代价来衡量。第四考虑给模型增加专门的小目标检测头配置，虽然推理耗时会有小幅增加，但对远端小目标的改善立竿见影。

我做过的另一个有效手段是TTA多尺度推理，推理时将图像缩放为0.8和1.2倍，分别推理后合并结果，对中等尺寸目标有稳定增益。代价是推理耗时翻倍，所以只建议在部分对延迟不敏感的离线分析任务里使用，实时链路不建议开。

4.2 夜间与雨雾场景：误报、漏报一起出现怎么办

夜间和雨雾天气是智能交通模型最容易“翻车”的环境。夜间画面亮度低、噪声高，车灯会产生明显的光晕和眩光，行人穿着深色衣服时几乎与背景融为一体；雨雾天气则会让画面变模糊，前景对比度下降。

针对夜间场景，首要手段是数据层面补足夜间样本，这是最直接有效的方式。有些团队会用图像增强算法把白天图像“伪装”成夜间效果，比如降低亮度、加噪声、模拟光晕，但生成图像的分布和真实夜间差异仍然很大，只能作为辅助。更可靠的做法是采集真实夜间视频，同时把夜晚各个时段的样本都覆盖到：傍晚蓝调时刻、深夜低照度、凌晨车少时段，光照条件各不相同。

模型层面，我建议针对夜间样本单独评估，看看漏检集中在哪些类别。如果主要是行人漏检，那就要提高行人类别在夜间难例中的权重，或者采用类别平衡采样。后处理规则也要调整，夜间车灯反光会在路面形成大面积高亮区域，容易造成误检框，常见的处理方式是结合目标所在的图像区域做置信度修正，比如车道区域内的框可以适当放宽，路肩区域则收紧。

雨雾天气的常规做法是先去雾增强作为前处理，但要注意增强后的图像不能改变目标的视觉信息结构，否则反而引入新的干扰。我实测下来，轻度去雾对检测精度的提升有限，更重要的是训练数据里有足够的雨雾样例，让模型自己学会在低对比度下提取目标特征。

注意：不要为了夜间效果盲目提高图像亮度。过度增强会让噪声同步放大，目标边缘被破坏，结果往往是误检率上升、漏检率不降反升。增强幅度要以小目标可辨识度为标准来调整。

4.3 推理帧率上不去：先查瓶颈再谈优化

帧率不达标是部署后最常被现场反馈的问题，但不少人一上来就急着给模型减层降精度，这其实是错误思路。帧率瓶颈往往不在模型本身，而在数据链路的前后环节。我一般按下面的顺序做排查。

第一步看解码是不是瓶颈。查看CPU占用和硬解码器负载，如果解码占用过高，优先优化拉流策略和码率。第二步看预处理耗时。图像缩放、颜色转换这些操作如果用CPU做，耗时会很高，最好放到GPU上做或优化为算子融合。第三步看推理耗时。用推理引擎的profiling工具统计每层的耗时，确认瓶颈在哪个子模块，再考虑是否需要更换模型规格或者做量化。第四步看后处理和业务逻辑，有些团队把业务规则写在主循环里，对每一帧执行复杂的区域计算，这部分会大量占用CPU时间。合理的架构应该把检测结果先写入队列，业务规则异步处理，避免阻塞视频推理主链路。

我遇到过一次很典型的案例，某项目的边缘盒子单路推理明明只要20毫秒，但整体帧率却达不到15帧，排查发现是业务逻辑里对每一帧都做了全画面的电子围栏像素级判断，把CPU占满了。把耗时逻辑移出主循环后，帧率直接翻了一倍多，模型本身一行没动。这类经验说明，优化前一定要先用profiling数据说话。

4.4 误报与规则联动：一次完整的业务联调案例

最后分享一个比较完整的联调案例，它反映了模型与业务规则是怎样配合的。某模拟项目X需要检测高速路上的逆行车辆，方案是检测车辆目标，跟踪轨迹，再根据轨迹和车道方向判断是否逆行。初版系统上线后误报率很高，问题不在检测本身，而在于规则层用了单帧方向判断，车辆在画面中轻微来回摆动就会被判为逆行。

排查后我做了三项调整：一是跟踪轨迹平滑，把方向判断改为基于连续多帧的位移矢量计算，而不是逐帧判断；二是置信度分级，低置信度检测结果只参与流量统计，不触发逆行告警；三是给逆行事件增加二次确认逻辑，目标连续三帧满足逆行条件才发出告警，并且告警后保留视频切片供人工复核。三项调整后，误报率大幅下降，而真实逆行事件的召回率没有明显牺牲。

这个案例说明，在智能交通这类高误报成本场景，检测模型只是其中一环，规则层是否合理、是否跟跟踪结果正确联动，往往比模型本身更能决定系统可用性。落地时我习惯把置信度、跟踪置信度、规则触发条件一起做成可配置项，方便现场根据实际误报率做快速调节，而不是每次都重新训练模型。

5. 影响范围与扩展方向：检测模型之外的更多可能

5.1 从单帧检测到全局轨迹：模型能力外溢

当检测和跟踪的底座打好之后，你会发现很多原本要单独开发的业务，都可以在同一个底座上生长出来。车辆计数只是最基础的功能，基于轨迹可以进一步计算平均车速、排队长度、路口通行效率，基于目标分类可以统计不同车型的占比，辅助交通信号配时决策。一些高级事件检测，比如行人闯红灯、非机动车逆行、高速路上异常停车，本质上都是检测加轨迹加规则组合出来的结果。

这意味着检测模型的改进会带来整个系统能力的升级，而不仅仅是单帧指标变好。我在集成测试中发现，YOLOv26对小目标的召回提升，直接让远端车辆的速度估计误差明显缩小，因为轨迹连续了、断点少了，速度计算的抖动自然减少。这种从底层改善到业务层受益的传导，比单独去调上层算法要高效得多。

5.2 成本与效益的平衡思考

引入新的检测模型，不能只看精度的提升，也要算清升级成本。模型结构升级带来的训练成本、标注成本、硬件适配成本，以及现场设备是否需要更换，都要纳入评估。我倾向的评估方式是先做一次小规模试点：选一个画面最复杂、业务最敏感的点位，用新模型灰度运行一段时间，对比误报率、漏报率和事件响应延迟，再决定是否全量升级。这个过程通常只需要一到两周，但能避免大规模替换后的系统性风险。

硬件层面也要评估。并不是所有现场设备都能直接运行新模型，如果现有设备算力不足，升级模型的同时可能还要考虑更换边缘盒子，或者把部分视频流改接中心服务器处理。这些都会增加整体预算，但换来的通常是误报率的下降和运维人力成本的节省。算总账的时候，不要只盯着单点成本，要看整个系统的综合持有成本。

5.3 后续可以往哪些方向继续做

检测模型本身做到一定阶段后，我建议把精力转向更上层的能力延伸。一个方向是长时序的目标行为分析，现有检测加跟踪只能覆盖几秒到几十秒的行为，如果再结合跨摄像头接力跟踪，就能还原车辆在全路网的运动轨迹，这对重点车辆追踪和路线溯源很有价值。另一个方向是细粒度车型识别，在基础分类之上引入车型子分类，可以为交通统计提供更丰富的数据维度。还有一个值得关注的是视频压缩域检测，某些场景下不需要对每一帧都做完整检测，帧间差分和运动信息可以先过滤掉无变化区域，只在变化区域执行检测，能大幅降低算力消耗。

这些方向都不需要推翻现有系统，而是在已有检测、跟踪的底座上叠加模块。对团队来说，把当前这套底座打磨稳定，数据积累和标注体系建好，后续扩展的空间就会很大。

6. 实操总结：从项目里提炼的几条经验

技术在迭代，落地的方法论却相对稳定。我在多个交通项目里反复验证过几条经验，这里按优先级整理出来。

数据始终是第一优先级。新模型结构带来的增益，如果数据没有跟上，效果很难体现。多花时间在采集和标注质量上，比反复调整超参数更值得。夜间、雨雾、遮挡、密集场景的样本，宁可多标注一些，也不要等项目上线后才被现场“教育”一遍，那时候补救成本要高得多。

训练与部署的配置要一致。训练分辨率、归一化方式、颜色通道顺序，部署时都要一一对应。很多精度问题不是模型不够好，而是训练和部署之间某个细节不一致造成的。建立一份配置对照清单，每次发布模型前逐项核对，能省掉大量排查时间。

端到端的性能测试要前置。不要等到设备进场才做联调。在开发阶段就要用目标设备或者同等算力的环境跑通整个链路，确认推理延迟、跟踪稳定性、规则反压在真实条件下都可接受。换个设备重新验证，这个习惯能避免一大类现场问题。

规则层一定要可配置。置信度阈值、跟踪参数、事件触发条件，都要做成可以远程调整的配置项。上线后的模型表现和测试集会有差异，现场需要快速调节，而不是每次修改都走一轮重新训练和发布流程。

说到底，智能交通系统是一个复杂工程，检测模型是其中关键但远非全部的一个环节。能在底层模型上持续获得增益，同时把上层链路打磨稳定，项目的整体交付质量才会真正上一个台阶。