摄像头这东西早就不是什么稀罕物件了。写字楼走廊、仓库月台、小区门口、车间产线抬头一看密密麻麻全是镜头。但你真去问一线的运维和管理人员十有八九会跟你说同一句话画面是有了可真出了事还是得靠人一帧一帧地倒回去看。这就是过去十几年安防系统的真实处境——看得见但看不懂。AI盒子之所以这两年冒出来得这么快本质上就是来解决看不懂这件事的。你可以把它理解成给摄像头外挂的一颗脑子摄像头继续干它擅长的活把画面拍清楚、把视频流吐出来AI盒子负责在本地把这些视频流接过来做解码、做推理、做规则判断最后只把有人翻越围栏了有车停在禁停区超过三分钟了安全帽没戴这类结构化结果往外送。它不需要你把现有摄像头全部换掉也不需要把所有视频都往云端推属于典型的存量改造、旁挂升级方案。这篇内容面向三类人一是手上有一批老摄像头、想做智能化但预算有限的实施人员二是负责选型和验收的技术负责人三是自己动手折腾过一段时间、被各种坑磨过一遍的爱好者。我把从方案设计、硬件选型、取流配置、规则调试到长期运维的完整链路捋一遍该给参数的地方给参数该说坑的地方直接点名尽量让你看完能直接上手。1. 项目整体设计与选型思路拆解1.1 为什么是加个盒子而不是把摄像头全换掉我见过太多方案第一页PPT就写着整体替换为智能摄像机然后报价单往桌上一拍甲方当场沉默。这里面有三层现实问题。第一层是存量规模。一个中型厂区动辄上百路园区级项目上千路是常态。这些设备大多还在服役周期内成像质量没问题坏就坏在它们只会输出裸视频流。全量替换意味着拆装、布线、调试全部重来一遍工期和成本都不在一个量级上。第二层是算力分布。把AI算法塞进摄像机里面看起来优雅实际很受限。一台枪机里面能塞的算力芯片受限于体积、散热和成本通常只够跑一路轻量模型。你想加一个新算法对不起得等厂家固件更新你想换个检测目标对不起硬件不支持。AI盒子不一样它是一个池化的算力中心一路盒子的算力可以分给八路、十六路摄像头轮着用算法升级也只是换模型文件的事。第三层是施工与运维。旁挂式改造你只需要在原有的接入交换机旁边多插一根网线盒子就能开始抓流。出问题的时候摄像头归摄像头排查盒子归盒子排查边界清清楚楚。全替换方案一旦出问题责任在谁那儿经常扯半天。提示如果你手上的项目摄像头已经严重老化、或者本身就是低分辨率的老模拟设备那先别急着上盒子。低画质喂给算法误报率会高到你怀疑人生。这种情况先把前端换掉再考虑加脑子。所以这个项目的核心思路就一句前端不动或尽量少动把智能部分解耦出来做成一个独立的、可迭代的、算力可共享的边缘节点。这个思路的优势是改造成本低、上线快、后续能持续加算法要避免的问题则是加密视频流取不到、多品牌混杂管理混乱、以及网络带宽被自己人打爆。1.2 算力、路数、码流这笔账必须先算清很多人选盒子只看一个数字——NPU算力多少TOPS。这个数字有用但单独看没什么意义因为它跟能带几路之间不是线性关系中间隔着分辨率、帧率、抽帧策略、模型复杂度四道关。先说抽帧。摄像头是25帧每秒往外吐的但绝大多数场景根本不需要逐帧推理。人走路的速度大概1.2米每秒一个仓库通道从画面这头走到那头要好几秒你每4帧抽1帧去算也就是6到7次每秒完全够用。抽帧策略直接决定了算力消耗这是性价比最高的一个优化点。再说分辨率。同样一个模型输入640×640和输入1920×1080后处理耗时差不多但前处理缩放和推理本身的耗时能差三四倍。工程上的常见做法是用高分辨率做目标检测的候选区域筛选用裁剪后的小图做分类确认也就是先粗后细。给你一个粗略的估算表这是我在多个项目里反复校准过的区间实际数值会因为模型和芯片差异有浮动但量级不会错场景配置单路推理帧率单路算力占用相对值一台中等算力盒子的实际带机路数1080p抽帧5fps轻量人形检测51.012 到 16 路1080p抽帧5fps人形车辆属性51.86 到 8 路1080p逐帧25fps人形检测254.53 到 4 路4K抽帧5fps人形检测53.24 到 5 路1080p抽帧5fps行为分析跌倒/攀爬52.64 到 6 路这张表最关键的一列不是最后那列而是单路算力占用的相对关系。它告诉你一件很朴素的事功能越重带机量掉得越快而且是非线性地掉。所以选型时不要拿标称带16路去套自己的需求先问清楚厂家这个16路是在什么模型、什么帧率、什么分辨率下测出来的。还有一笔账是带宽。一路1080p的主码流H.265编码下大概2到4 MbpsH.264大概4到6 Mbps。16路全取主码流峰值能到50到60 Mbps一台千兆交换机的一个口子理论上够但如果这个口子上还跑着别的业务就容易出问题。解法很简单盒子的分析通道优先取子码流。子码流一般是720p甚至D1码率只有主码流的四分之一到三分之一用来做检测完全够因为检测模型本来就要把图缩到640左右。注意子码流不是所有摄像头都默认开启的有的出厂默认关闭需要进摄像头后台手动打开并单独设置分辨率和码率。这一步没做你接通之后会发现盒子拿不到流然后开始怀疑人生。1.3 部署形态的三种走法各有各的脾气实际项目里AI盒子的接入方式基本就三种选哪种取决于你现场的网络结构和权限边界。第一种是交换机镜像口旁路。把盒子接到核心或汇聚交换机的一个镜像端口上把需要分析的摄像头流量镜像一份过来。好处是完全不碰原有业务链路盒子挂了也不影响摄像头和NVR正常工作安全性最高。坏处是镜像口带宽有限制而且你得有交换机管理权限。第二种是盒子主动向摄像头或NVR拉流。盒子作为一个客户端主动去RTSP地址上把流拉过来。这种方式最灵活不需要动交换机配置只要有网络可达和账号密码就行。缺点是会占用摄像头或NVR的并发连接数一些低端NVR同时只允许4到6个客户端拉流超了就连不上。第三种是摄像头直连盒子的第二网口。部分盒子带双网口一个口接管理网一个口专门接摄像头所在的PoE交换机。这种做法的好处是分析流量和业务流量物理隔离互不干扰特别适合那种不许动现有网络的甲方。缺点是布线多一根而且盒子成了单点一旦断电这一路分析就没了。接入方式对现有网络的影响需要的权限适合场景主要风险交换机镜像旁路极小交换机管理权限园区、写字楼、已有成熟网络镜像口带宽瓶颈主动拉流中等占并发摄像头/NVR账号小型项目、快速验证NVR并发连接数耗尽双网口直连无物理接线条件隔离要求高的工业现场盒子单点故障我自己在项目里最常用的是第一种加第二种的组合主干用镜像零散的、跨网段的几路用主动拉流补齐。这样既能保证主体链路的独立性又不用为了几路摄像头去改交换机配置。2. 核心细节解析硬件、算法与数据链路2.1 硬件选型别只盯着算力数字拿到一台盒子的规格书很多人第一眼找TOPS第二眼找接口数量然后就没了。实际用下来决定这台设备能不能在你现场活过三年的往往是几个不起眼的指标。散热结构。无风扇被动散热的盒子安静、无尘、故障点少但前提是它的散热面积和内部导热设计真的够。我见过一些紧凑型盒子标称功耗15W夏天装在弱电井里连续跑一周就开始降频推理帧率从5fps掉到2fps画面开始卡成PPT。判断方法很土但有效连续满载跑48小时摸外壳温度再登录看芯片温度。外壳超过55度、芯片结温超过85度就要考虑加装散热或者换位置了。解码能力。这点最容易被忽略。你算力再强如果硬解码单元只支持8路1080p那第9路进来就得走软解CPU瞬间被打满。规格书上一般会写支持X路1080p解码要看清楚这个数字是硬解还是硬解加软解的总和。网口与供电。双千兆网口是加分项能让你做网络隔离。PoE供电能力要看总功率预算如果你打算让盒子直接给几台小摄像头供电得算清楚峰值功率够不够别到时候一开机就跳保护。存储与看门狗。盒子本地一般需要一块硬盘或大容量存储卡用来存事件前后的短视频。工业级固态盘比消费级贵不少但连续写入场景下寿命差好几倍这笔钱别省。另外硬件看门狗必须有。边缘设备装在没人管的角落系统卡死没人重启看门狗是最后一道保险。宽温与防护。弱电井夏天能到45度冬天北方室外机柜能到零下20度。规格书上的工作温度范围要看清楚是整机还是芯片很多标-20到60度的是芯片结温不是环境温度这中间的差距能让你在冬天收获一批开不了机的设备。2.2 算法怎么验收演示效果不算数厂家来演示的时候画面永远是那段精心挑选的测试视频光线均匀、人员稀疏、背景干净检测框画得又稳又准。你把它拉到自己的现场一跑全乱套了。所以验收环节必须自己设计不能看演示。我一般会准备四段素材覆盖四种最难的情况第一段是逆光和大光比。正对着大门的摄像头早上和傍晚必然逆光人只剩一个黑轮廓。这时候模型能不能检出是能不能用的分水岭。第二段是夜间低照度加噪点。红外补光的画面噪点很多很多模型在白天测得挺好一到夜里全是误报因为把噪点当成了运动目标。第三段是目标密集。上下班高峰几十个人同时出现在画面里看模型会不会漏检以及同一目标会不会被反复计数。第四段是干扰物。树枝晃动、雨滴、飘落的塑料袋、地面上来回扫的光斑这些是误报的主要来源。验收指标我一般只看三个检出率、误报次数、重复告警次数。检出率不用追求99%实际场景里能做到90%以上并且误报可控就已经很好用了。误报次数按每路每天来统计一个24小时的场景单路每天误报控制在5次以内算合格超过10次基本就没法用了因为值班人员会直接把这个告警静音掉那这套系统就废了。提示验收一定要跑足时间至少连续72小时包含至少两个完整的昼夜循环。只跑半天的验收都是在自欺欺人。2.3 取流这件事坑比想象中多取流是整个链路里最枯燥但最容易翻车的一环。摄像头的视频流协议主要有三类标准RTSP、ONVIF、以及各家的私有SDK。优先用标准协议兼容性最好。RTSP地址的通用格式一般是这样的# 通用 RTSP 地址格式 rtsp://用户名:密码摄像头IP:554/路径?参数 # 主码流 / 子码流 的路径各家不同常见几种写法 rtsp://admin:pass%40123192.168.1.64:554/Streaming/Channels/101 # 主码流 rtsp://admin:pass%40123192.168.1.64:554/Streaming/Channels/102 # 子码流 rtsp://admin:pass%40123192.168.1.64:554/cam/realmonitor?channel1subtype1这里有个细节必须提密码里如果有特殊字符要做URL编码。比如密码是pass123地址里就得写成pass%40123否则解析会出错你会得到一个莫名其妙连不上的结果然后开始查网络、查防火墙浪费一晚上。取流连不通的排查顺序我总结成了一条固定路径# 第一步网络可达 ping 192.168.1.64 # 第二步端口开放554 为 RTSP nc -zv 192.168.1.64 554 # 第三步用 ffprobe 看流信息这一步能看到编码格式、分辨率、帧率 ffprobe -v error -rtsp_transport tcp \ -i rtsp://admin:pass%40123192.168.1.64:554/Streaming/Channels/102 \ -show_entries streamcodec_name,width,height,avg_frame_rate # 第四步抓10秒存成文件确认画面正常 ffmpeg -rtsp_transport tcp -i rtsp://admin:pass%40123192.168.1.64:554/Streaming/Channels/102 \ -t 10 -c copy test.mp4-rtsp_transport tcp这个参数建议默认加上。UDP方式延迟低但丢包之后画面会花而且很多盒子在UDP模式下对网络抖动的容忍度很低。TCP方式延迟略高一点但画面完整对检测来说画面完整比低延迟重要得多。2.4 存储与回放别把自己存爆全量录像这件事交给NVR去做。AI盒子负责的是事件录像——检测到目标后保存前后各若干秒的片段加一个结构化标签。假设你要存30天的事件录像每路每天产生100条事件每条事件前后各5秒、共10秒子码流2Mbps单条事件体积 2 Mbps ÷ 8 × 10 s ≈ 2.5 MB 单路每天体积 2.5 MB × 100 ≈ 250 MB 16路每天体积 250 MB × 16 4 GB 30天总量 4 GB × 30 120 GB所以一块1TB的盘存事件录像够用大半年冗余很充足。但如果有人图省事让盒子把16路主码流全量录下来16路 × 4 Mbps ÷ 8 × 86400 s ≈ 691 GB/天一天就干掉将近700GB一周就把1TB盘写满然后系统开始循环覆盖你精心保留的事件录像被冲掉了。这个坑非常常见本质是把盒子当NVR用了。正确的分工是NVR管全量、长时间、按通道回放盒子管事件、结构化、按标签检索。两者的定位完全不同。3. 实操过程从开箱到跑通一条完整告警链路3.1 上电、寻址与基础网络配置新盒子到手第一步不是急着接摄像头而是把它自己的网络弄明白。大多数设备出厂是DHCP你得先知道它拿到了什么地址。接入同一台交换机用笔记本扫一遍网段# 查看本机所在网段 ip addr show # 快速扫一遍同网段活跃主机 nmap -sn 192.168.1.0/24 # 如果已知设备厂商的 MAC 前缀可以更精确地找 arp -a | grep -i xx:xx找到地址后登录管理界面第一件事是改掉默认密码设成静态IP。边缘设备用DHCP有个隐患某天路由器重启或者租约到期盒子的IP变了你的告警推送地址、NVR的注册信息全部失效然后就是一堆为什么突然不报警了的电话。静态IP规划建议单独划一个管理网段比如摄像头一个段、盒子一个段、办公网一个段中间做最小化的路由放通。这样后面排查问题的时候你能一眼看出是哪一层出的问题。时间同步这一步千万别跳过# 校时边缘设备时间不准会导致录像时间戳错乱、事件排序混乱 timedatectl set-timezone Asia/Shanghai timedatectl set-ntp true timedatectl status我遇到过一起事故盒子的时间比实际快了11分钟结果事件录像检索出来的时间点和NVR对不上客户一度以为是系统漏录。查了半天才发现是NTP没配。3.2 摄像头接入与取流验证网络通了之后开始接摄像头。我习惯一次只加一路验证通过再加下一路而不是一口气全加进去然后面对满屏红色报错。单路验证的完整动作是这样的确认摄像头IP可达、554端口开放用ffprobe确认子码流的编码格式和分辨率在盒子里添加通道填入RTSP地址观察盒子的解码状态和推理帧率在画面里走一圈确认检测框能跟上拉一份实时日志看有没有持续的解码错误或丢帧警告。第6步特别重要。很多盒子的管理界面上显示在线但后台日志里全是decode error画面看着能动实际推理一直在丢帧检出率自然上不去。看日志这一步能提前把问题暴露出来。批量添加的时候用配置文件导入比一个个点快得多。大多数盒子支持CSV或JSON格式的通道导入格式大致长这样{ channels: [ { id: 1, name: 北门入口, url: rtsp://admin:pass%40123192.168.1.64:554/Streaming/Channels/102, transport: tcp, enabled: true, decode: hardware, analysis_fps: 5 }, { id: 2, name: 仓库月台, url: rtsp://admin:pass%40123192.168.1.65:554/Streaming/Channels/102, transport: tcp, enabled: true, decode: hardware, analysis_fps: 5 } ] }注意analysis_fps这个字段这就是前文说的抽帧。默认值不要设成摄像头的原始帧率设成5就够用了能省下大量算力。有个小技巧不同通道可以设不同的抽帧率。人流量大的主通道设8偏僻角落设3整体算力就腾出来了。3.3 画区域、划规则灵敏度是靠调出来的这是整个项目里最花时间、也最体现经验的一步。算法本身是通用的能不能用得舒服全看规则怎么划。先说ROI关注区域。很多新手直接把整个画面都设成检测区结果画面边缘的树影、天上的飞鸟、远处马路上的车全成了告警源。正确做法是手动圈出真正关心的区域通常是通道、门口、装卸位、设备区这些。圈得越精确误报越少这是投入产出比最高的一个动作。再说规则类型。常见的几种适用场景完全不同规则类型触发逻辑适合场景常见误报来源区域入侵目标进入指定多边形区域禁区、配电房、危险区域光照突变、影子移动越界检测目标跨过设定方向线单向通道、围墙目标在线上来回徘徊逗留检测目标在区域内停留超过阈值禁停区、月台阈值设太短离岗检测指定岗位区域内无人超过阈值值班室、门岗人员短暂离开倒水人流统计按方向线计数出入口、电梯厅双向并行通过漏计最后说灵敏度阈值。这个词在各家产品里叫法不同有的叫灵敏度有的叫置信度阈值本质都是模型多确定才认为是真目标。数值调低检出多但误报也多调高误报少但会漏。我的经验是分阶段调第一个星期把阈值设低一点宁可多报把现场所有可能的干扰源都暴露出来然后针对性地加ROI、改规则、加过滤条件第二个星期再把阈值往上收收到一个每天误报两三次的水平。这个流程比一开始就精调要快得多因为你不先把问题暴露出来根本不知道要防什么。3.4 告警联动从盒子到手机的那一跳检测出来之后得让人知道。联动链路一般是盒子 → 推送服务 → 接收端。最常用的协议是HTTP回调盒子在触发时往指定URL发一个JSON# 接收端的一个极简示例跑起来就能看到盒子推过来的内容 from http.server import BaseHTTPRequestHandler, HTTPServer import json class Handler(BaseHTTPRequestHandler): def do_POST(self): length int(self.headers.get(Content-Length, 0)) body self.rfile.read(length).decode(utf-8) try: data json.loads(body) except json.JSONDecodeError: self.send_response(400) self.end_headers() return # 关键字段打印出来方便调试 print(通道:, data.get(channel_name)) print(规则:, data.get(rule_type)) print(置信度:, data.get(confidence)) print(时间:, data.get(timestamp)) print(图片:, data.get(image_url)) self.send_response(200) self.send_header(Content-Type, application/json) self.end_headers() self.wfile.write(b{code:0}) if __name__ __main__: HTTPServer((0.0.0.0, 8080), Handler).serve_forever()调试这一跳的时候有三件事要提前确认第一盒子能不能访问到你的接收端。很多现场盒子在独立网段只能出不能进回调地址写内网IP根本不通。要么在盒子所在网段部署接收服务要么让盒子走可出网的上行通道。第二回调频率会不会打爆服务。16路同时触发一秒可能几十条。接收端一定要做限流和去重把同一通道、同一规则在短时间内重复触发的合并掉。去重窗口建议设30到60秒这个参数看起来小但能把告警量砍掉七成以上。第三图片怎么带。盒子一般会带一张抓拍图要么是URL要么是base64。base64会让请求体积膨胀三分之一以上量大时建议让盒子只推URL接收端自己去取。注意不要一上来就把告警推到全员群。先推到一个小范围测试群跑够三天把误报压下去之后再扩大范围。否则第一天的误报轰炸会让所有人对这套系统失去信任后面再推就没人看了。3.5 一份能直接抄的参数表把前面散落的内容收拢成一张表这是我现场常用的默认值可以作为起点再按实际情况微调。参数项建议默认值调整依据分析取流子码流720p检测模型缩图到640主码流无意义传输协议TCP画面完整优先于低延迟抽帧率5 fps人员/车辆运动速度决定的置信度阈值0.55先低后高跑一周再收ROI手动画只圈关键区域面积越小误报越少告警去重窗口30 到 60 秒按现场人流密度调事件录像前5秒后5秒足够看清全过程事件存储保留30 天常规追溯需求盒子温度告警阈值芯片 80 度超过会触发降频NTP 同步周期每小时时间错了全乱这张表里我个人觉得最值得强调的是抽帧率和去重窗口这两项。它们不涉及任何算法改动纯粹是配置层面的调整但对整体使用体验的影响比换个模型还大。抽帧从25降到5带机量能翻三倍去重窗口从0调到60秒告警量能砍掉一大半。4. 常见问题与排查技巧实录4.1 问题速查表现场问题看着千奇百怪归纳下来其实集中在几个点上。这张表我放在手机备忘录里随时能翻。现象最可能的原因排查动作处理方式通道显示在线但无画面路径写错或取了主码流超带宽ffprobe 单独验证流地址换子码流路径加 tcp 参数画面能看但检测框不动推理线程卡死或算力打满看推理帧率与芯片占用降低抽帧率或减通道数白天正常夜间全误报红外噪点被识别为运动对比白天与夜间日志提阈值、开降噪、缩ROI同一目标反复告警无去重逻辑查回调日志的时间间隔配置30到60秒去重窗口告警延迟超过10秒网络抖动或推送队列积压分段打时间戳定位改TCP、缩短录像切片盒子运行几天后变慢散热不足触发降频查芯片温度曲线改善通风或加散热片时间戳与实际差几分钟NTP未配置或同步失败timedatectl status配NTP校时区多路同时接入后NVR掉线NVR并发连接数被占满查NVR连接列表改用镜像方式取流事件录像检索不到存储写满在循环覆盖查磁盘占用改存事件流别存全量摄像头断电后不恢复盒子未重连查重连日志开自动重连设重试间隔4.2 几个看着不起眼、实际要命的坑第一个坑用主码流做分析。这是新手最常犯的错。理由通常是主码流清楚检测应该更准。听起来有道理实际完全相反。检测模型输入尺寸就640左右你喂1920的图进去它也要缩到640多出来的信息全浪费了还额外占了解码资源和带宽。更糟的是16路主码流同时解码盒子的硬解单元直接爆掉后面几路自动降级成软解CPU打满整个系统开始雪崩。记住一句话分析用子码流回放用主码流。第二个坑密码里的特殊字符没转义。前面提过一次这里再强调。RTSP地址里的、:、/、#这些字符在URL里都有特殊含义必须做百分号编码。这类问题最磨人因为网络是通的、端口是开的、密码你自己输的肯定没错就是连不上查半天查不出来。第三个坑交换机镜像口配错方向。镜像配置有入口镜像和出口镜像之分配反了就是一帧都抓不到。更隐蔽的是有些交换机的镜像口只镜像单方向流量你抓到的流是不完整的表现为画面能出但花屏、卡顿。这种情况用抓包工具看一眼就能确认比在盒子上瞎调参数快得多。第四个坑把盒子装在密闭弱电箱里。这个我吃过亏。一个项目盒子装在铁皮箱里箱子还上了锁。夏天跑了不到两周客户反馈经常不报警。跑过去一摸箱子烫手。芯片温度常年90度以上一直在降频运行推理帧率掉到1fps多人走过去根本抓不到。边缘设备的安装位置通风比什么都重要。第五个坑ROI画得太大或者太小。画太大误报多画太小该抓的抓不到。我见过一个把ROI画成一个细长条的项目结果人从旁边绕过去就完全不触发。画ROI的正确姿势是照着实际需要管控的物理边界画而不是照着画面里看起来顺眼的位置画。第六个坑忽视模型版本管理。盒子跑起来之后厂家隔三差五推新模型说精度提升了。有些项目直接点了升级结果新模型在老场景上表现反而变差。升级前一定要留旧模型并且在自己现场的固定测试素材上跑一遍对比。没有对比就升级等于拿生产环境做实验。4.3 长期运行要做的几件事盒子这类设备最大的特点是装上去就没人管了所以前期的自动化运维设计特别重要。温度与负载巡检。设一个定时任务每天采集一次芯片温度和推理帧率写进日志。如果发现温度持续走高或者帧率持续走低说明散热在退化积灰了或者算力已经接近上限。这种趋势性数据比事后排查有用得多。# 一个极简的每日巡检脚本配合定时任务跑 #!/bin/bash STAMP$(date %Y-%m-%d %H:%M:%S) TEMP$(cat /sys/class/thermal/thermal_zone0/temp 2/dev/null | awk {print $1/1000}) LOAD$(uptime | awk -Fload average: {print $2}) DISK$(df -h /data | tail -1 | awk {print $5}) echo $STAMP temp${TEMP}C load${LOAD} disk${DISK} /var/log/box_health.log存储水位监控。磁盘到85%就该告警了。事件录像的循环覆盖一旦开始最早的记录就被冲掉如果正好那时候出了事需要追溯就麻烦了。告警有效性复盘。这个动作很多项目都省了但它决定了这套系统能不能长期活下去。建议每月拉一次告警统计总告警数、确认有效的数量、误报数量、误报集中在哪个通道哪个时段。数据一摆出来该调哪个通道、该改哪条规则一目了然。我经手的一个项目第一周误报率62%按通道拆开看其中三个通道贡献了八成误报针对性调整ROI和阈值之后整体误报率降到9%。固件与模型升级的窗口管理。升级一定要选在业务低谷期并且提前准备好回滚方案。升级之后的第一天要重点盯因为新版本的问题往往在特定场景下才暴露。备用设备。这个建议听起来很朴素但真的有用。盒子的故障率不高但一旦坏了整片区域的智能化能力就归零。备一台同型号的机器配置模板提前导出来坏了直接换上去导入配置半小时恢复。比起临时采购等货两周这个投入太值了。我个人在这类项目上摸爬滚打下来最大的一个体会是AI盒子的价值八成在配置两成在算法。同一台设备ROI画得准不准、抽帧设得合不合理、去重窗口配没配最终呈现出来的效果能差出一个数量级。所以别把时间全花在比参数上多花点时间在现场蹲一蹲看看那些告警到底是怎么产生的比看十份规格书都管用。