企业官网建设流程全解析

清研微视与公交客流计数的“最后一公里”：从算法演示到全天候实跑

做公交信息化这些年，我见过不少客流统计项目从立项时的“信心满满”走到验收时的“羞于启齿”。实验室里跑得好好的识别模型，一装上公交车就失灵：逆光、暴雨、人挤人的早晚高峰、司机偶尔伸个懒腰……每一项都能让计数数据瞬间变成笑话。正因如此，当我看到清研微视把公交客流计数系统往“实用化”三个字上较劲时，我特别认同这件事的难度和分量。

公交客流计数听起来是个小问题——不就是数上下车的人吗？但真正扎进去就会发现，它横跨了计算机视觉、嵌入式硬件、车辆工程、数据通信、公共交通运营调度好几个学科。过去二十年，红外对射、压敏踏板、公交IC卡、手机信令，各路方案都试过，却没一个能在“全天候、全场景、低成本”这九个字上同时交卷。这篇文章我想从一个长期做智能交通落地的工程视角，把客流计数为何难、视觉方案到底怎么做才能实用、以及清研微视这类厂商卡在了哪几个关键节点上，原原本本拆开来讲。

1. 客流数据是公交运营的“地基”，但传统手段始终差一口气

1.1 没有准确的客流数据，调度和线网规划就是盲人摸象

公交公司每天排班、配车、调整发车间隔，都依赖于对客流的准确判断。一条线路高峰期挤不上车、平峰期空车跑，背后一定是运力投放和真实需求对不上。要解决它，首先要知道各站上下多少人、什么时段人多、方向性如何。这不是靠线管员眼睛估一估能解决的，更不是靠司机到终点站报一句“今天人多”能解决的。

客流数据一旦能高精度、细粒度地被采集，公交公司能做的事会立刻多起来：按站点的实时需求动态调发车间隔、优化车辆周转、做长线网的分段客流分析、平衡运力资源，甚至为财政补贴核算提供最硬核的审计依据。在智慧公交体系里，客流计数设备是地面的“传感器层”，决策层再聪明，数据采集不准，整个系统就是空中楼阁。

1.2 红外、刷卡、扫码、手机信令，各有各的“盲区”

早期公交客流统计主要做的是“掐点估算”，下车门装一对红外对射或压敏踏板，车停开门时每过一个人就触发一次计数。这套东西最大的问题就是“见物不见人”：乘客拖着行李箱、背着大包，一人进出触发多次；两个人并排或紧贴着上下车，触发一次；司机或售票员在门区走动，也会被算进去。时间一长数据失真，多数公交公司对它只能睁一只眼闭一只眼。

后来智能卡和二维码支付普及了，大家以为能用刷卡数据替代客流数据。仔细一算还是不行：现金乘客、老年卡免费卡、残疾人卡、通勤定制票，各种免刷场景都会漏；而刷一次卡再换乘、或一人替多人刷卡，又会造成重复统计。更麻烦的是，IC卡数据只有“上车点”没有“下车点”，断面客流根本推不准。至于手机信令数据，精度在城市栅格里还行，到了车厢这个拥挤、高速移动、多人同机的环境里，统计误差大到只能做宏观趋势参考。

1.3 视觉方案有它的苦，却是唯一可能回答“全量、真实、连续”三个词的方向

为什么最后大家纷纷投向视觉？因为只有摄像头能在不依赖乘客配合的前提下，真实捕捉到车厢车门区域的场景全貌。你不需要乘客刷卡、不需要他们单独过闸机，只需要在车门上方装一个摄像头，就能“看到”上车和下车这两个物理行为。

但，视觉方案的痛苦也是肉眼可见的。公交车门区域是一个光照条件极度不稳定的环境：晴天逆光时，车外一片白亮；夜间进站时，车内灯亮车外漆黑；下雨天车窗有水痕，乘客伞面反光；高峰期人挤人，门区根本分不清谁是上车谁是下车。这些问题的叠加，让很多视觉厂商把“好使”停留在口号阶段，一直无法真正把精度稳定在运营可用的水平。清研微视这些年做的，本质上就是把这套系统从“能演示”打磨成“能天天用”。

2. 车门方寸之间的视觉难题：为什么双目标定和深度感知缺一不可

2.1 先还原一个真实的下车门场景，再谈算法

我经常跟刚入行的算法同学说一句话：“你没蹲过公交车的下车门，你就写不出能用的客流算法。”

在真实场景里，下车门区域同时存在几种干扰目标：站台上的行人、路边停靠的电瓶车、靠近车门聊天的人、司机回头瞥一眼、乘客手里拎着的菜篮和行李箱、车外跑过去的小孩。你如果直接用2D图像做目标检测，会发现网络能框出一堆“人形物体”，但你根本分不清哪个在车上、哪个在车下、哪个已经下去了一半。

这时候必须引入“空间深度”这个维度，而不是只靠颜色和纹理。清研微视的方案里最核心的，恰恰就是双目视觉测距带来的三维空间理解能力。两个摄像头装在车门正上方、以固定基线向下俯拍，同一时刻采集的两幅图像可以通过视差计算出场景的深度图。有了深度，系统就能知道门区里每一个物体距离相机多远、占多大体积、是在车内还是车外。

2.2 单目视觉的先天缺陷：光线一变，置信度就跳水

单目摄像头方案在客流领域用过一段时间，靠的是目标检测+跟踪。它的做法是先用神经网络识别画面里的“人”，再根据人头或人肩的包围框位置，判断是否跨过了预设的车门线。听起来很简单，可单目图像天然缺失深度信息，一旦遇到逆光和阴影，很容易把地面上的人影识别成一个“人”，把站台上等车的人硬算成上车客流，一下雨地面积水反光，误检率更是奇高。

更根本的问题是，单目方案无法建立一个可信的“三维检测空间”。你告诉算法“车门线以下、车门框以内算计数区”，但它不知道乘客的头顶离图像上那条线到底多远，看到一半身子进了门框，就无法确定这个人究竟在哪个空间里。光线、角度、遮挡只要出现一点变化，结果就剧烈波动，这也是为什么很多单目客流设备在演示时90%以上精度，一到真实线路就崩。

2.3 双目测距和3D RoI：实际上是在画一道隐形围栏

双目方案最大的价值，在于它把问题从“识别一个像素块是不是人”变成了“测量一个三维空间里有没有物体进入”。

清研微视在这套体系里会用双目视差构建深度图，再结合事先标定好的安装位置，在车门口建立一块三维的感兴趣区域（通常称作3D RoI）。这个RoI可以精确到厘米级：从车门踏板到车内地板，从门框左沿到门框右沿，高度上再设一个阈值，比如超过1.1米的目标才计数。这样一来，乘客弯腰提行李、小孩跑过、司机的手臂伸进去，这些对2D算法来说很致命的干扰，在三维空间层面就被直接过滤掉了。

这也是我理解的“实用化”第一层含义：它不是在追求认得更准，而是在追求不需要“认出”那么多东西也能数得准。把物理围栏画好，依靠深度信息做出判断，比单纯堆AI模型的鲁棒性更可靠。

2.4 光有人头识别还不够，跟踪链路才是计数稳定的关键

有了深度图和RoI，是不是就能直接数人了？还不行。公交车门是连续开合的过程，乘客不是一个个排队进出的，通常是三五个一涌而入。如果只是逐帧做检测并在某一帧输出一个数，那同一拨乘客会被重复计数好几次。因此一个成熟的客流计数器必须带有完整的多目标跟踪链路，在连续的图像帧之间给每个目标分配ID，记录它的运动轨迹，判断它的起始位置和终止位置，是“从车内走向车外”还是“从车外走向车内”，最后再输出一个带方向的上车数或下车数。

这一套跟踪逻辑说起来容易，但工程实现上有大量细节：目标短暂被遮挡后如何恢复，人贴人走路时ID怎样避免串扰，头肩特征在视角变化下如何匹配。清研微视这类头部厂商花大力气打磨的，正是这些细节。因为这些环节每出一个问题，反映到报表上就是几十上百次的误差，公交公司很快就能发现“这东西不准”，从而不再信任整个系统。

3. 车端硬件的工程门槛：计数器必须先是一台“耐造”的车载设备

3.1 终端算力选择：功耗、体积和环境适应性是硬约束

客流计数系统说到底不是一个实验室设备，而是一个要装在大巴车上、每天在太阳底下暴晒、在雨水里冲刷、在颠簸路上震个不停的工业设备。

先说算力。公交车的电气环境相对紧张，12V/24V双电压系统、点火瞬间的电压跌落、车内空调电机的电磁干扰，都要求计算模组具备极强的电源适应性和电磁兼容能力。现在的主流方案通常会用一颗内置NPU的边缘AI芯片，比如瑞芯微RK3588、地平线旭日系列这类级别的SoC，在几瓦到十几瓦的功耗内跑起双路视频流的实时推理。选型时大家通常会纠结：GPU性能强的板子AI跑得快，但功耗和散热扛不住，而太省电的芯片又跑不动大模型。

我个人的经验是：不要把算力堆在“力气大”上，而要堆在“会挑活”上。双目相机的深度解算本身需要大量并行计算，这部分尽量放到DSP或专用加速单元里；目标检测和跟踪则放到NPU上，模型剪枝压缩到能在端侧稳定实时运行即可。设备运行时内存占用要非常克制，因为公交车没有机房运维，设备一旦因内存泄漏或算力耗尽而卡顿，往往要等到月底保养时才会被发现，中间一个多月的数据全部废掉。

3.2 安装位置、结构件设计和EMC，直接决定设备的“生死”

摄像头的安装位置是第一个影响识别效果的变量。理论和实践中最优的位置，是车门正上方、斜向下俯拍，这样可以同时看到车门踏板、车内地板和站台边缘。但实际操作中，这个位置经常遮挡逃生锤、安全提示标识、售票箱，还要避开司机后视镜的视线范围，于是就要做各种结构件的适配设计。

硬件的公差控制也同样重要。很多公司把实验室样机做得很漂亮，一到批量交付就发现相机支架装上去松垮垮的，车辆行驶的震动让光轴慢慢偏掉，原本标定好的双目外参发生漂移，深度图产生重影，计数精度直线下降。清研微视在这个问题上花心思的方式，是把整个模组做成一体化结构，镜头、图像传感器、算力板、接口和散热设计统一在一个紧凑的壳体内，减少现场逐个组装的误差来源。同时，整个设备要通过严格的车规级EMC测试，否则装上车之后，司机报站器一响、车载电视一开，数据就乱跳，这种问题在实车试用时几乎每批都会碰到。

3.3 标定与出厂一致性：每一台设备的“出厂手感”都必须相同

双目视觉设备出厂时，两个相机的内外参、基线距离、光轴夹角都会存在微小差异，这些差异如果不校准，深度图精度就会不一致，导致A车计数正常、B车误差翻倍。

成熟的产线流程是：每台设备在出厂前做一次亮度校正+畸变校正+双目外参标定，生成独立标定文件写入设备存储，并在产线里用一套固定的测试视频跑完一轮精度验证，精度不达标直接返工。这个“出厂一致性”听起来是管理问题，其实直接影响实用化口碑。公交公司通常一次采购上百台设备，分给十几条线路，如果每台设备精度差异很大，运营方很快会对整套系统失去信任。清研微视这类面向规模交付的厂商，在产线标定上下的功夫，往往不比写算法的功夫少。

3.4 实车标定与线路适配：不能拿着“通用参数”就上路

还有一个容易被忽略的环节是“实车标定”。同一款公交车，门的高度、踏板高度、地板上是否有台阶、门区两侧是否有扶手，都会影响3D RoI的设置。系统装上车之后，必须有专门的标定流程，用实际尺寸把门区的三维空间框画清楚。有的线路车门是内摆门，有的是塞拉门，有的是折叠门，门型不同，传感器看到的遮挡情况完全不同。

所以实用化部署一定不是“装完就完”，而是要有一套完整的标定工具和现场作业流程。清研微视的现场技术服务人员背着标定垫、拿着标定软件跑线路，把每台车门的空间参数采集回来，再同步到设备端运行配置里。这一步做得越细，后续长期运营越稳。

4. 难缠的实景工况：光照、遮挡、拥挤时的确定性输出才是真功夫

4.1 光照场景库：你不能只在“阳光明媚”的时候准

以前很多算法团队测试时用的是自己挑的美丽视频，一到现场就翻车。公交场景一天之内会经历无数种光照条件：清晨太阳低角度斜照进车门、中午强光把人的影子拉得老长、傍晚夕阳直射镜头、夜间站台灯光不足但车厢内白炽灯刺眼，还有雨天、雪天、隧道内灯光闪烁的情况。

要让计数器在所有这些场景下都能稳定输出，必须建一个足够大的光照场景测试库，把每一种组合都在真实的设备上跑过、调过。我所了解到的主流做法是：从实车采集的样本中抽帧，按“逆光/顺光/夜间/雨雪/阴影/强曝”分类标注，再针对失败的case反推算法策略。比如逆光环境要调整曝光策略和宽动态范围设置，不能让高光区过曝、暗区死黑；夜间要把车内的补光和车外的暗背景做动态均衡；雨天还要处理车门玻璃和地面的水渍反光。这套工程打磨，没法靠一个模型解决，必须建立“多场景策略库+自动切换”的机制。

4.2 高峰期的人流墙，靠“跟踪+空间过滤”共同扛住

早晚高峰是公交客流计数最怕的画面：车门口挤着一坨人，前面的人还没下完，后面的人已经往上涌。在2D图像上，人跟人几乎完全重叠，头部、肩膀全都混在一起，目标检测网络在这时候基本“数不清谁是谁”。

在这种情况下，双目深度图反而成了救命稻草。因为即便人贴人，三维空间里每个人头相对于相机的距离还是不完全相同的，可以从深度维度上把拥挤的人群切分成立体单元。再结合头部检测和轨迹跟踪，即使目标在某一帧完全被遮挡了，上一帧的运动状态和空间位置也能帮助恢复当前帧的位置。通过“深度聚类+多帧跟踪”，系统才能在极度拥堵的场景里仍然给出一个相对可信的数字。

当然，极端情况下的精度仍然会下降，所以成熟的评估体系不应该只看“平均准确率”，还要看“满载率条件下”这种分场景的准确率。如果厂商敢向公交公司承诺满载情况下的误差范围，那才是真正有点底气。

4.3 乘客与物品的区分：高度、体积、运动规律三个特征叠加判断

再来说一个特别容易被忽视的干扰项：人带的随身物品。一辆公交车门区，什么都会出现：买菜大妈手里拖着的小拉车、学生背的双肩包、农民工提的蛇皮袋、婴儿车、轮椅、大号行李箱。这些物品在图像上和人的轮廓很容易混在一起，怎么判断它们是“人”还是“人的附属品”，还是“单独的物品”？

清研微视这类方案的思路是建立一个多维度的判断逻辑。首先是高度和体积：人的头肩高度和宽度有典型的尺寸范围，比它矮或小的目标大概率是物品。其次是运动模式：物品通常跟随主人同步运动，和乘客的运动轨迹高度耦合。第三是利用深度信息做面积估算，一个超过正常人体占地面积的目标往往是被推行的轮椅或婴儿车，而其上方的“人形目标”仍然是计数主体。

通过这些规则组合，系统才能做到“跟着人走，不跟着东西走”。这些规则在算法论文里往往不值一提，但在实际运营中，可能占误差来源的相当大比例。

4.4 设备断电、网络中断、车辆剧烈颠簸的兜底策略

实用化系统还要考虑一种永远避免不了的工况：故障。公交车上的设备经常遇到车辆熄火断电、司机误拔插头、网络信号断连、存储卡损坏、车辆长期停放导致电池馈电等状况。客流计数器必须在这种恶劣条件下仍然能自恢复，不能死机一次就一直掉线。

这块我看到业界比较可靠的做法是三层兜底：第一层，看门狗自动重启，程序卡死或跑飞时几分钟内自动恢复并续传数据；第二层，本地存储兜底，网络中断期间数据先落盘，信号恢复后补传；第三层，设备断电时通过检测车辆电源状态，提前做数据的完整性校验和优雅关机，避免存储数据损坏。清研微视这一类经过大量路测的厂商，普遍在这块投入了相当多精力，因为对公交运营方来说，数据稳定性比偶尔多一个少一个人重要得多。

5. 数据走出去：客流计数不只是一台“数人机器”，更是调度体系的输入

5.1 与调度平台对接：数据格式、传输链路和实时性要求

客流计数器真正发挥价值，必需与公交公司现有的调度系统、公交大脑平台完成对接。每一台车上报的数据，至少要包含公交线路ID、车辆编号、当前经纬度、车辆方向、进入站点的站点序号、上客数、下客数、车内实时总人数和满载率等结构化字段。

这些数据在上报时间上也有讲究。调度系统的实时性要求通常比较高，车辆到站后在一定时间窗口内就要把客流数据发给中心平台，用于计算站台滞留情况、判断是否需要降速跳站或放加班车。如果设备端只做离线统计、每天导一次表，那这套系统的价值就小了一半。

现在业界标准的做法是设备端通过4G/5G物联网卡接入公交公司的数据总线，用MQTT或TCP长连接上传，中心平台再做清洗和入库。各种接口协议看似繁琐，却是决定设备能否融入整个公交数字化体系的关键所在。

5.2 满载率和断面客流：数据如何反过来优化线路

采集上来的客流数据，最直接的应用就是算满载率和断面客流。

满载率是单车车内人数与额定载客数的比值，超过合理阈值，调度中心就能判断这条线路的高峰拥挤程度，为缩短发车间隔、增加配车数提供依据。断面客流则是某条线路在两个连续站点之间最大同时段通过的总人数，它直接反映客流在空间上的不均匀分布，是线路增设大站快车、区间车、调整站点配设的核心依据。

过去这些数据靠人工调查统计，一搞就是两三个月，样本又少，延后性极强。有了全车自动采集的数据，公交公司每个月的线网分析可以直接从系统导出来，而且可以按分钟、按站点、按天气、按节假日做颗粒度到极细的切片分析。这种能力，在传统的“人海统计法”下是完全无法实现的。

5.3 OTA升级与远程运维：同一批设备怎么持续保持最佳状态

公交公司往往一次采购上百台设备，用上三到五年。这期间，线路调整、车型调配、算法更新、相机固件修复、新站点启用都是常态。如果每次都要派人一台一台去车场刷机，那运维成本会压垮项目。

所以实用化系统的另一个关键指标是OTA升级和远程运维能力。设备要能接收中心下发的配置更新，比如站点列表、RoI参数微调、算法模型版本、曝光策略参数等，同时能上报设备的在线状态、硬件温度、CPU负载、内存占用、断线次数等健康指标。有些厂商甚至提供远程抓拍能力，运维人员在中心就能看到某台设备当前的实景画面，直接判断它是否被异物遮挡、角度是否偏移。这些运维功能平时不起眼，可真到了项目长期运营阶段，谁家运维轻松，谁才能真正站稳脚跟。

5.4 数据质量评估体系：怎么证明这套设备“可信”

最后一个往往比算法本身更重要的环节，是建设一套面向运营方的数据质量评估体系。

很常见的场景是：设备装上去了，公交公司也会拿人工计数去比，发现某天误差大就打电话投诉厂商。问题的根源在于，误差可能来自设备本身，可能来自车辆停靠不正导致视角偏移，也可能来自人工计数本身不准，但公交公司不会区分这些，他们只会看一个结果。

因此，成熟的厂商会主动建设一套评估机制：定期用视频抽帧回放，由专业人员标注真值，再和设备输出做比对，得出不同线路、不同时段、不同工况下的准确率报告。清研微视在不少城市推行的就是这种“数据可信运营”模式——不是设备装完就不管，而是长期用真值标注和对比报告来证明系统有效。这种做法，才真正把客流计数从“一次性硬件销售”变成“长效数据服务”，也让运营方真正敢在日常管理里依赖这些数据。

6. 实用化的最后一课：我经历过的坑和这类项目真正的分水岭

6.1 算法指标好看，不代表设备能用 —— 现场验收必须盯住“独立真值”

做了这么多项目，我最大的一个教训是：永远不要相信厂商提供的“测试精度99%”。这个99%是在什么场景、什么时间段、什么天气条件下测出来的，差别天壤之别。

正确的验收方式是：公交公司自己组织人工真值采集，在实车、真实运营状态下，按早高峰、晚高峰、平峰、夜间各采集若干车次，并且由第三方的运营人员而非厂商技术员来做人工计数。没有独立真值的验收，本质上和让运动员自己给自己打分没什么区别。清研微视愿意配合做独立真值验收，这在我接触的厂商里属于比较难得的务实姿态，也是他们能被多个城市公交集团接受的重要原因。

6.2 试运行期要拉长，故障记录要和精度数据一起看

客流计数设备最怕的不是单次误差，而是间歇性失控。设备可能连续三周都表现很好，第四周因为一场暴雨、一次硬件温度过热、一次车辆电瓶馈电，突然开始疯狂误报。这时候如果试运行期太短，这些问题根本暴露不出来。

我建议公交公司和设备厂商把试运行期拉到至少一个完整月以上，并且要求每个月提交一份包含“故障时间线”的运营报告：什么时间、哪台车、什么现象、持续多久、恢复情况如何。故障记录和精度数据放在一起看，才能真正判断设备有没有“起码的可靠性”。

6.3 别把数据“裸奔”给调度员，业务语义转换才能让数据创造价值

我见过很多客流数据系统，平台界面上全是些数字表格，调度员根本看不懂也不愿意用。技术人总觉得“我数据准了就行”，但业务侧需要的不是“今天7路车第4站上客27人”这种离散点，而是“当前这班车拥挤程度高，建议后车乘客分流”“该线路高峰时段满载率超过120%，需要加密班次”这种可以直接辅助判断的语义化信息。

这里我要点出一个很重要的趋势：清研微视这类厂商正在做的，是把客流计数从“传感器的角色”升级成“业务智能的入口”，将车端采集的客流数据通过后台模型，输出满载率、班次推荐、线路健康度等面向调度场景的决策指标。谁能把技术数据翻译成业务语言，谁才能真正让公交公司把它当成运营工具，而不是一个摆在那里的记录仪。

6.4 我对公交客流计数行业走向的几点判断

第一，单目和所谓“纯AI大模型”很难在公交场景里完全替代“双目+深度+物理空间约束”的方案。公交乘客计数是一个需要确定性、可解释性、可在恶劣环境稳定工作的弱AI任务，物理感知约束（深度信息）不可或缺，这一点短期内不会有根本改变。

第二，公交客流计数的竞争已经从“算法精度”转移到了“工程能力+数据服务”。谁的硬件抗造、谁的标定稳定、谁的运维体系完善、谁的数据能直接为调度产生价值，谁才能在城市级的长期项目里持续产出。

第三，未来的客流数据不会单独存在。它一定会和车载GPS、刷卡数据、充电数据、站台监控数据融合，形成一个完整的城市公交运行数字孪生。到那时候，客流计数设备就不再是孤立的传感器，而是整个城市公共交通神经系统的“感觉末梢”。

最后分享一个我自己的判断标准：看一家客流计数厂商是不是真“实用化”，不要看他们展会上的PPT，也不要看算法跑分的榜单，就去看它有没有勇气接受独立真值验收、愿不愿意把试运行期拉长到一个月、敢不敢把故障时间线公开写进运营月报。清研微视这些年能在国内公交市场里逐步打开局面，靠的正是这几个别人不愿意做、不敢做的环节。技术会迭代，方案会更新，但这种对工程底线和数据可信度的认真，才是公交客流计数真正走向实用化的基石。