企业官网建设流程全解析

港口船舶类型识别这件事，看着是个纯视觉问题，真正落地的时候，牵扯的东西比你想象的多得多。如果现场已经有了一套AI识别系统，却还在出现漏判，问题往往不在算法单点，而是从“采集端到推理端”整条链路的某个环节松了。我最近在某个港口项目上把这件事重新捋了一遍，从防爆摄像机的选型安装，到检测模型的场景适配，再到漏判样本的回收闭环，算是把“AI检测算法+防爆摄像机”这套组合怎么真正用好给摸透了。这篇就把整个调试过程和踩过的坑，从头到尾写清楚。

1. 港口环境下的漏判困局，到底卡在哪儿

先说结论：港口这类场景，船舶类型检测的漏判率，很少是某一个环节单独造成的。它是一个典型的“采集端埋雷、算法端踩雷、部署端被雷炸”的复合问题。前期做方案的时候，如果只盯着算法精度这一个指标，忽略了前端摄像机的成像质量和现场部署约束，那系统上线跑几个月，漏判和误判就会像潮水一样涌出来。

很多项目最初接到的需求都是“能不能用监控识别到港船舶的类型”，但真正到了现场你会发现，港口的工况比普通园区复杂太多：盐雾腐蚀、日照反光、船舶相互遮挡、不同吨位船只的视角差异，这些都会直接污染图像质量。更麻烦的是，港口有防爆区域划分，普通摄像机根本没有办法往里装，这就逼着你必须在防爆摄像机的型号、焦距、安装高度、角度上一次性做对，否则后面所有算法调优都是白费。

先看传统做法为什么漏判率高。普遍的旧方案是“人工盯屏幕+触发式抓拍”。调度员对着十几个分屏看，全靠肉眼和记忆力去判断一艘船是散货船、集装箱船还是油轮。漏判原因不外乎三个：一是人眼疲劳，夜班盯两个小时之后，注意力必然涣散；二是船舶姿态不固定，有的船侧面看像集装箱船，换个角度又像杂货船，人工判断本身就有主观性；三是部分船只靠泊时间极短，稍微一晃神，船已经开走了。后来有些码头想用纯图像规则去解决，比如通过轮廓长宽比或者颜色分布做分类，但在复杂海况和光照突变下，规则式判断几乎必崩。

AI检测算法能解决这些问题，根源在于它是在数据驱动下学习到的高层语义特征，而不是靠几个手工设计的阈值。港口船舶类型识别的主流做法是目标检测（检测框加分类），再加上一个后续的类别细分类分支。但光有一个检测模型还不够，漏判问题的本质是“模型没有见足够的样本”。如果只在晴天白天训练，那雾天、逆光、夜间的图片全都没见过，识别率自然跳崖。我在这个项目上反复确认过一件事：防爆摄像机的成像素质，决定了算法能“吃”到什么级别的信息。

另一个容易忽略的漏判源是推理侧。港口现场的网络工况并不稳定，如果采用纯中心化服务器推理，一旦传输链路抖动，帧率下降，就意味着视频抽帧变稀疏，移动中的小船很可能直接“跳帧漏检”。所以现在港口场景的主流做法是“前端摄像机+边缘计算盒子”的模式，摄像机负责原始画面采集，盒子内置加速后的检测模型，在本地完成识别后只把结果上传。这样可以保住识别时效，也能缓解中心服务器压力。但边缘部署对模型的体积和推理速度提出了硬约束，不能什么大模型都往上面塞，必须在精度和算力之间做取舍。

还有一个常被误判为算法问题、实际是设备安装问题的漏判原因：防爆摄像机的视野与识别目标不匹配。我之前遇到过一套系统，识别率始终上不去，现场一查发现摄像机装得太高，视野根本覆盖不住船舶的水线区域，导致图像里船身只露出一角，别说人了，算法自己也认不出来。所以防爆摄像机的选型和点位设计，必须与AI算法的识别距离、目标最小尺寸、视场角需求同步做设计，不能先装摄像头再调算法，这个顺序一倒，后期的返工成本就控制不住了。

2. AI检测算法与防爆摄像机的匹配逻辑

2.1 模型选型：精度、速度与场景的三角平衡

港口船舶类型检测这个任务，模型选择的核心约束不是“排行榜上的精度”，而是“在这个码头现场能跑起来且不会漏”。我个人的经验是，从实际项目倒推模型选型，比先定模型再适配场景靠谱得多。

先确认推理端算力。边缘盒子或者工控机用的是哪种加速卡？如果只有CPU，那参数量大的模型基本不要考虑，推理延迟会直接拖垮实时性。如果有一块消费级加速卡或者嵌入式专用NPU，那么需要在性能基准测试中对比几种主流算法的mAP和FPS，再结合防爆摄像机输入的分辨率，测一下端到端延迟。测试时候有个细节要注意：不要只看标准数据集上的指标，一定要拿现场实际抓取的港口场景图像去跑测，因为标准数据集的分布和港口的真实光照、雾霾、船舶外形差异很大，离线评测过不了，上线必翻车。

我这次采用的方案是“两阶段识别架构”：先用一个轻量级检测器在边缘端完成船舶目标定位与粗分类（比如“船/非船”或是大类的粗筛），再把检测到的目标区域按需上传至更高精度的细分类模型做二次确认。这套设计的核心逻辑是防漏判不能只看单一模型的置信度。初始检测模型如果漏掉一个目标，后面做得再好也无济于事，所以第一阶段的召回率必须优先保证，哪怕牺牲一些精度、多产生一些误检框也可以；真正决定最终输出类别的，是第二阶段对已锁定目标的高精度特征判别。

这样拆分下来，第一阶段模型可以比较激进，调低检测阈值让更多目标被框进来；第二阶段细分类模型只处理被裁剪出来的船舶目标区域，计算压力小，可以运行更强的骨干网络，类别判断也更有把握。港口船舶类型里，集装箱船、散货船、油轮、渔船、工程船这些类别之间，外形差异其实挺明显的，但依然存在“长得像”的情况。比如有些多用途货船和集装箱支线船在特定视角下轮廓相似，人眼都容易混淆，这种边缘情况单纯靠检测框分类器很难解决，需要细分类模型提取更多纹理与结构特征。

2.2 防爆摄像机在AI链路中的角色

先花点时间聊防爆摄像机。很多人会低估“防爆”这两个字的含金量，给港口做方案的时候，只是知道“得买防爆的”，但防爆等级、镜头选择、安装方式这些细节直接决定了成像质量，进而决定了AI算法能不能正常工作。

港口危险区域的防爆等级通常是按照防爆电气标准来划分的。不同的危险区域和气体组别对设备防爆型式的要求不一样，比如很多油品码头要求设备满足隔爆型、IIC级气体组别、T6温度组别。这些参数看起来繁琐，但一条都不能省，因为现场是实打实的危险环境，普通摄像机往外冒一个电火花就是安全事故。

具体到摄像机的成像选型，我一般认准几个硬指标：

• 传感器靶面尺寸。港口光照变化大，大靶面传感器的动态范围和低照度表现更好，对夜间识别帮助很大。首选1/1.8英寸或以上的传感器，底太小的夜视能力就是灾难。
• 镜头焦距。焦距是防爆摄像机适配算法识别距离的关键。如果摄像机要覆盖30米宽的海岸线，最小识别目标是一艘10米长的小渔船，那么焦距和视场角就要按照“目标在画面中至少占据规定像素”来反推。算法训练时对目标尺寸是有隐含要求的，太小的目标特征根本提不出来。
• 视窗的镀膜与除雾能力。港口盐雾大、湿气重，镜头视窗极易起雾起霜，直接影响图像清晰度。防爆摄像机自带视窗加热除雾功能应该列为必选项，不要省这个钱。某次项目里，一台不起雾的摄像机和另一台起雾的摄像机在同一天里，识别率差出了将近二十个百分点。

很多项目的痛点是：防爆摄像机的品牌与型号选择受制于合规，而不同厂家的成像ISP（图像信号处理器）调校风格差异极大。有的摄像机画面偏冷、偏亮，有的偏暖、偏暗，这会显著影响算法对色彩纹理特征的提取。在项目上要先做ISP风格摸底测试，如果某种摄像机的图像锐度过高导致摩尔纹，或色彩偏移严重，就得在部署阶段加入图像预处理矫正的环节，或者在选型阶段直接剔除掉这类设备。

防爆摄像机的另一个关键在于供电与布线的稳定性。现场无论是采用光纤收发器还是工业交换机组网，都要保证链路传输延迟在可接受范围内。我当时遇到过多次边缘端设备掉线，导致视频流断流，算法不断地对前端恢复的连接状态做重连与缓冲，最严重时一套系统一天会遇到上十次断流。后来排查发现是供电源的防护等级不足、现场湿气太大导致漏电跳闸。把这个坑填平之后，系统整体稳定性一下就上来了，我深刻体会到：在港口这种恶劣环境下，设备稳定性远比算法创新占的权重更大。

3. 从选型到部署的完整实操流程

3.1 现场勘察与点位设计

有句话在项目里重复了多少次都不为过：做AI视觉项目，先花三成精力在勘察，后面能省七成返工。港口船舶识别的勘察重点不是看哪里有电、哪里有网，而是摸清靠泊位长度、潮汐变化对船舶停留位置的影响、现有杆塔位置、光线主要来向、可行安全区域边界。

点位设计时最关键的计算是焦距选型计算。假设目标是要覆盖整个泊位的宽度，识别目标最小要求是看到船名或者船头结构，这里的约束是“在算法设定检测帧中，目标宽度至少占多少像素”。一般我给自己定的线是：小目标检测的最低要求是目标短边不低于输入分辨率的1/50。也就是说如果输入图是1920x1080，那目标短边最好不要低于38个像素。用这个反推焦距，如果码头有50米宽的覆盖需求，用2.8mm短焦只能看到一大片画面，目标占比会很小，必须选用长焦镜头对准关键通道或者泊位前端的核心区域。更有效的办法是分区部署：一台短焦大视角负责大范围监控，若干台长焦防爆枪机精确盯住每个泊位的下船点，一宽一长配合使用。

常规安装高度我一般定在8到12米，这个高度既能避开船舶桅杆的遮挡，又能以俯视角度获取较好的目标轮廓信息。如果装太高，俯仰角过大会让船舶变形严重，检测模型没见过这种透视角度，大概率漏检；装太低又容易被集装箱臂架遮挡。点位确定后，必须在现场做一个“手持摄像机模拟试验”，在不同的安装预选点各拍一段视频，回放确认目标在画面中的尺寸占比是否达标。

3.2 数据准备：比模型结构更重要的是数据工程

港口船舶类型检测的训练数据有几个棘手点。一是类别不均衡，到港船舶中散货船、集装箱船数量多，工程船、危险品船样本稀缺；二是季节性光照变化大；三是不同码头的船舶涂装风格差异巨大。如果直接拿公开数据集训练然后部署，漏判几乎是必然的。

为了控制漏判率，我采用的数据策略是分三层：

• 第一层：基础公开数据集，用于预训练通用特征，让模型先学会什么是“船”，什么是“水”和“岸”。
• 第二层：现场采集数据。在安装好防爆摄像机并稳定运行两个星期后，每天持续抓取视频画面，按半小时一个片段存盘。这里有个小细节：不要只保存有船的片段，没有船的纯水面、纯岸线画面也必须保存，这些是降低误报的关键负样本。
• 第三层：样本难例挖掘。将已经上线的初版模型跑到现场录制视频上，把所有置信度低于阈值的检测结果和错误的分类结果全部导出，人工打标后再作为额外训练集。这一步是“对症下药”的循环，漏判率能压下去，靠的正是这种不断把错题重做一遍的方法。

标注层面，船舶类型分类的边界要提前定清楚。比如“渔船”和“小型工程船”在外观上经常接近，到底按船体材质分还是按用途分，会直接影响标注一致性。我的做法是建立一套标注规范文档，里面为每个类别配多张参考图，标注员遇到不确定类别时宁可标为“其他船舶”，也不能随便猜一个类别标上去。因为错误标注会给模型传递错误信号，噪声积累起来，模型最终会学到错误映射，比缺少样本更麻烦。

图像增强策略上，除了常规的翻转、缩放、颜色抖动，还要重点加入“模糊增强”和“雨雾模拟”。港口摄像机镜头常常因为水雾和盐雾导致画面模糊，模型如果只在清晰图像上训练，一遇到起雾天识别能力就断崖式下滑。用OpenCV的随机高斯模糊、运动模糊加上亮度变化去做数据增强，能让模型对恶劣天气更鲁棒。

3.3 模型训练与验证的关键细节

模型训练阶段，我习惯把数据集按照“时间段”而不是“随机比例”来划分训练集和验证集。什么意思？比如用第1到第15天的数据训练，用第16到第18天的数据验证，这样能更真实地模拟新一天的泛化效果。如果随机划分，白天和夜间的图像会同时出现在训练和验证集里，模型实际上见过相似分布但没见过的具体图片，验证指标会虚高。

训练损失函数与置信度阈值的设定对漏判影响巨大。分类类别比较均衡时可以以交叉熵损失作为主要分类损失，但如果现场数据不均衡严重，我会引入焦点损失或者给稀疏类别加权重，学习信号在低频类别上得到足够强化，否则模型倾向于把所有船都预测成高频类别，也就是“漏判了不少，误报也不少”的局面。

置信度阈值也是一个需要反复权衡的参数。阈值调高，检测框少、误检少，但漏检也会增多；阈值调低，漏检减少，但误检框会增多。对港口船舶识别这种业务来说，误检一个框还好，漏判才是灾难，所以我一般会把置信度阈值调得略低，宁可多出一些不确定框，也要确保不遗漏。之后在输出层再接一个业务规则来过滤：比如连续多帧稳定出现同一目标才上报，单帧偶然的检测结果直接丢掉。这样的时序平滑规则能大幅压低偶发误检。

推理端我用的是边缘盒子。模型转换时需要注意量化带来的精度损失问题。在港口这类场景下，如果边缘盒子的算力允许，我倾向直接用半精度推理，必要时再降为整型量化并用代表性的港口视频片段做精度对比测试。如果量化后在苛刻的光线条件下出现精度崩坏，宁愿把输入分辨率稍微降低一点来换取全精度推理，也别盲目追求高量化。

另外一个常被忽略的是推理帧率与检测频率的匹配。不同类型的靠泊船运动速度不太一样，大型远洋船舶入泊慢，但小型快艇、拖轮的移动速度相当快。如果推理频率只有每秒一帧，小型船只可能在两帧之间就从画面边缘划过。解决方式是允许前端根据画面运动状态动态调节推理频率。有运动目标时提高帧率，无运动目标时下降帧率，这样既省算力也保证小型快速目标能被捕捉到。

3.4 现场部署与系统联调

部署阶段的顺序很重要，我的建议是先做设备的单点测试，再做算法烟囱式联调。每一台防爆摄像机通电后，先直接在本地工程机上用离线视频测试算法表现，确认该点位图像质量合格后再接入中心平台。不要在点位还没验证的情况下就直接把几台摄像机同时接入算法服务，否则出了问题根本不知道是图像源的问题还是后端服务的问题。

断电接线规范要格外谨慎。防爆摄像机在危险区域的安装必须断电操作，接线时保证腔体密封到位。摄像头安装好之后，先用万用表量供电是否正常稳定，再检查视频流能否正常拉取。这个流程听着啰嗦，但能省掉后面一大半的隐蔽故障排查。网络层面，我给每台摄像机分配固定IP，禁止用动态获取，方便后续每个点位对应一个唯一标识。命名规范上直接融入点位信息，这样日志里一看到设备名称就知道是哪台摄像机出的问题。

算法服务的部署上，项目里用的是这套流程：每个边缘盒子单独部署一个识别服务实例，识别结果统一发送至中心消息队列，再由后端的业务系统做告警、统计、展示。边缘端和中心端的职责边界要划清楚，边缘端只做识别和事件上报，业务逻辑全部留在中心，避免边缘端单点故障导致全链路不可用。

联调阶段必须验证的几件事包括：夜间识别效果、白天强逆光表现、大雾天气表现、船舶被遮挡时的行为走向、同一艘船连续多帧是否会产生重复上报，以及不同类别之间的切换响应速度。联调最好分三个时段做：白天，夜间，以及清晨/黄昏这种光线剧烈变化的临界时辰，每个时段至少跑一轮完整测试。实际经验是，光线剧烈变化的临界时刻，识别准确率是最低的，因为模型训练的亮度分布在这些区间往往是稀疏的。

4. 常见问题与排查技巧实录

4.1 船舶类型漏判高发问题速查表

我在港口项目上整理了一套高频典型问题及处理思路，这里以表格形式完整列出，便于大家在实际调试中比对：

这六类问题基本覆盖了港口船舶识别项目上线初期绝大多数漏报，处理优先级上建议先解决“目标太小”和“夜视差”两个物理层问题，因为它们直接影响底层图像信息量，算法再怎么调都很难绕开，其他问题可以后续在模型迭代中逐步消解。

4.2 排查漏判时必须盯住的几个隐蔽陷阱

有些漏判问题排查起来特别迷惑，因为现象看起来是偶发的，很难稳定复现。我后来总结出几条查漏判问题的硬经验，遇到疑难杂症时按顺序逐一排查，能少走很多弯路。

摄像机的时间与算法服务的时间必须校准到一致。时区不同、NTP同步失效都会导致识别时间戳错乱，非常影响触发条件和规则的验证判断，排查时容易被误判为识别漏判。我见过一个项目，调试日志里发现明明识别到了目标，但业务系统里就是没有记录，最后追查发现是中心数据库的时区与边缘盒子的时区差了8个小时，事件时间全部落到记录窗口之外，系统层面就漏了。

防爆摄像机自身的智能编码模式有时也会干扰图像质量。有些摄像机会默认开启ROI增强或区域裁剪以适应带宽限制，结果传输到算法侧的图像已经被裁剪或压缩得不完整，目标可能刚好在裁剪区域之外。解决方法是统一在算法侧直接拉取原始视频流，并在摄像机上关闭多余的数字增强。这个细节在部署点位多的项目尤其重要，因为每一台摄像机的配置偏好可能都不一样。

模型识别结果中的类别置信度，要作为一条独立可查的日志记录下来。很多时候后端排障时根本看不清是哪一步出了问题，因为只记录了最终决策。如果把每个检测框的类别概率、置信度、坐标、目标宽高、摄像机ID、时间戳一并记录，再对照原始视频帧回放，就能很快定位是“目标没被检测出来”还是“检测出来了但被后续规则过滤掉了”。这种可追溯性是港口现场排查漏判的重要武器，上线运维阶段一定要坚持。

4.3 基于现场反馈的迭代闭环机制

模型上线不是终点，而是数据循环的起点。我在项目里的固定做法是每天夜里自动把当天的识别结果与原始视频做一次抽帧对比，把所有置信度低于自定义阈值的检测框都导出到一个待复核队列中。第二天由算法维护人员花半小时快速浏览这些图片，确认哪些是真正的漏判或误报，然后每周把标注好的难例整理为一个增量训练集，以在线学习的节奏定期更新模型。

这个机制的持续运行有个前提：需要一个好用的数据标注和版本管理工具。样本的元信息必须是结构化的，比如“摄像机点位、天气、时间段、船舶类别、检测置信度、人工复核标签”，这样才能在训练时快速筛选出特定条件下的难例。所有模型的版本都要有对应的数据训练量和评估指标记录，方便回滚和对比。如果模型更新后某类别的识别率不升反降，可以马上回溯是训练集变动导致的还是超参数调整导致的，然后把模型回滚到稳定版本。

港口的运营节奏有淡旺季差别，不同季节的海况、光照、到的船型都不太一样。这个更新闭环要长期坚持，因为数据分布总是会变的。夏天和冬天的船只吃水线、装载状态差别很大，连续性收集数据和定期更新，不是可做可不做的优化，而是保证漏判率持续处于低位的必经之路。

5. 几个值得单独说一说的智能化扩展方向

港口船舶识别做扎实以后，顺水推舟可以延展的能力其实不少。这部分的思路不是简单堆功能，而是依托已经部署的防爆摄像机和已有的检测识别能力，把单点识别升级成业务闭环。我在这个项目上踩完坑之后，觉得下面几个方向最值得在后续落地时同步考虑。

靠泊行为分析是第一个自然延伸方向。船舶检测框有了，类别标签有了，如果再加一个跟踪模块，就能在同一摄像机视野内持续关联同一艘船舶。这样不仅能实现“哪类船在哪个时间段靠了哪个泊位”，还能自动计算靠泊时长、靠泊次数、离泊时间等业务统计指标。对码头运营方来说，这些数据的价值远高于单纯的“这艘船叫什么类型”。但要注意跟踪模块在海雾天气下的ID切换问题，为了防止同一个目标被切分成多个ID，可以在跟踪模型中加入外观特征匹配，不只是依赖位置关联。

第二个方向是船舶身份与违规行为联动。类型识别可以与船名OCR、电子围栏逻辑做联动，例如某些区域的接驳船只能在规定时间进入，一旦类型识别判定为不符合规定的船舶，则在几秒内触发声光告警或调度中心弹窗。这种场景下，把“识别”和“行动”连接起来的价值才算闭环。实现上要注意告警输出的防误报机制，必须引入多帧确认和人工复核按钮，否则误报太多会直接导致告警疲劳，一线工作人员反而开始无视所有报警。

第三个方向是风险区域的人员与船舶协同监测。港口的危险区域内，船舶靠近和人员违规闯入是两个最高频的安全隐患，如果摄像机的布局能够同时覆盖水面和岸线，那在算法架构上可以做成多任务识别，在同一份图像输入中同时执行船舶类型识别、船只跟踪和人员检测。但这样的多任务模型在嵌入式设备上推理资源和内存占用会急剧上升，需要提前做充分的压力测试，确保在高峰时段多个任务并发推理时不会有明显卡顿或帧率下降。设备选型时最好把这一层扩展的算力余量也预先留出来，免得后期想加功能又得重新换盒子。

6. 项目交付阶段容易被忽视的那些细节

项目真正跑起来之后，让人头疼的往往不是算法本身，而是交付和运维层面的细枝末节。港口这类工业场景对稳定性和可维护性的要求，比算法指标还要难伺候。这里挑几个我印象最深、最能影响项目成败的细节聊一聊。

防爆摄像机在港口环境下是一个长期暴露于盐雾、雨水、阳光直射和振动中的设备，它的维护周期和普通摄像机完全不同。我在项目里和现场运维团队确认了一套定期巡检制度：摄像头视窗每两周要用专用工具做一次清洁检查，检查视窗是否有盐渍结晶或者水垢残留。这个看起来很不起眼的工作，直接决定图像质量是否稳定。几次漏判率飙升的排查最后都落到了视窗脏污上，清洁完之后识别率立刻回到正常水平。清洁防爆视窗时必须使用合规的防静电软布和专用清洁剂，不能用普通抹布硬擦，否则在视窗上留下划痕，后期所有夜间的图像都会出现杂散光斑。

供电系统的冗余设计也是必须提的一环。港口现场经常有大型机械作业、电网负荷波动，这会导致摄像机和边缘盒子的供电出现瞬时跌落或浪涌。我在部署时坚持所有设备走独立稳压电源回路，关键节点配备不间断电源。曾经有一台边缘盒子因为供电问题频繁掉线，重启后模型加载需要几秒，期间该点位直接变成“瞎子”，漏掉了几条快速进出港的拖轮。这种问题在系统日志里非常隐蔽，很难直接联想到电源，但不解决它，稳定性指标永远很难看。

网络架构的容灾能力在交付阶段也要实测。港口的临时施工经常导致光纤被挖断，如果所有摄像机都汇聚到一个中心交换机，链路一断就是全线瘫痪。建议核心点位至少用不同的物理路径布两条光纤，交换机侧启用环网协议，保证出现单点链路故障时业务能在秒级自动切换到备份链路。这些网络侧的工作在项目初期的清单里容易被认为是“干杂活的”，但那恰恰是最后保证可用性的关键手段。

模型和数据资产的交接文档，我一直认为要当作项目验收的重要资产来对待。港口用户的技术团队换人很频繁，如果模型验收、训练数据来源、标注规范、推理参数调优记录没有成体系的项目文档，几个月之后新接手的人面对一个黑盒系统，根本无从维护。我习惯交付一套“识别运行指南”，内容包括每台摄像机的识别范围与局限性、模型的已知短板、不同天气条件下的预期表现、以及遇到异常时应当按什么顺序排查。这份文档看起来不耀眼，但能帮用户真正把AI识别当作日常营运工具用起来，而不是一直要依赖外部供应商驻场。

回看整个项目，我对“AI检测算法+防爆摄像机”这套组合的体会就是：算法是灵魂，但摄像机、供电、网络、运维这些“肉身”任何一个不健康，灵魂都发挥不出来。港口环境对稳定性的要求苛刻，大模型再强大也怕前端掉线和图像模糊。先踏踏实实把硬件、链路、数据闭环的基础打牢，再把识别模型放到这个稳定的底座上去迭代，漏判率才能被一点一点压下去。这个顺序，我没有见过例外。