我见过太多猪场在这件事上栽同一个跟头：花几十万装了一圈摄像头，配上大屏，头两周领导来看、技术员也看，一个月之后屏幕落了灰，真正出问题的时候还是靠饲养员打电话。问起来原因都差不多——"看不过来"。一栋育肥舍十几二十路画面，一个夜班技术员盯着四五个栋，眼睛根本不够用；更别说猪舍里人员进出本身就有生物安全限制，巡栏频次上不去，很多异常等到发现已经晚了。这也是智慧养猪场视频AI智能监控与可视化管理这几年被反复提起来的真实动因：不是为了科技感，是要把"人盯画面"变成"机器盯画面、人盯告警"，把巡栏从"凭经验扫一眼"变成"有数据、有记录、能追溯"。

我做这套东西踩过的坑不少，从选型踩到施工，从算法踩到验收。下面按我实际落地的顺序拆开讲：方案整体怎么切、摄像头怎么布、算法能力到哪一步、边端平台怎么落地、验收和运维怎么不翻车。不管你是准备上第一套系统的养殖场技术负责人，还是被派来做方案集成的工程人员，都能照着往下捋。

1. 方案整体架构与选型逻辑拆解

1.1 先从猪场真实痛点倒推功能清单

做这类方案最容易犯的错，是先定硬件再想功能。我见过一份方案书，前二十页全是设备参数，翻到最后才发现核心功能只有"录像回放"。这属于把视频监控当成了目的，而它其实只是数据源之一。正确的顺序应该是反过来：先把猪场各环节的时间成本列出来，再判断哪些环节能被视频AI替代或半替代。

我一般会让场里的场长和技术员各列一份"每天最费时间、最容易漏的事"。以育肥和母猪两个典型场景为例，列出来的东西高度相似：夜间巡栏（每2小时一趟，一趟20分钟以上）、异常猪只发现（不吃料、躺卧异常、跛行）、打架咬尾干预、母猪发情观察、产房母猪压仔、栏内头数核对、外来车辆和人员进出管控。这些事项里，凡是"靠视觉判断+需要高频重复"的，都是视频AI的射程范围；凡是"需要上手摸、需要采血化验"的，视频做不了，别硬吹。

我通常会把功能压成三层，从稳到难排序。第一层是计数与在位检测，也就是栏内还有几头猪、某区域有没有猪，这层技术最成熟，误报也最好控制，建议所有项目都从这里起步。第二层是状态与事件，比如长时间静止、聚集堆叠、频繁打斗、采食区停留时长异常，这层依赖跟踪和时序判断，需要一定数据积累。第三层才是生理与体况推断，估重、体况评分、体温筛查、发情判断，这层不确定性最大，必须配合人工复核，不能单独作为决策依据。把这三层的边界提前跟场里说清楚，后面验收的时候争议会少一大半。

1.2 端、边、云三层怎么切分才不别扭

架构上我基本不用"全云"或"全端"的极端方案，标准做法是三段式：前端采集在端、智能分析在边、管理与多场汇聚在中心。

端侧的职责很单纯，就是出稳定、干净的码流。摄像机只负责曝光、宽动态、红外补光这些基本功，不承担任何智能分析。有些厂商喜欢推"AI摄像机"，把算法塞进枪机里，我不太推荐用于主分析点位，原因是算力被焊死在硬件上，模型版本跟着硬件走，换算法就得换机器，而且一台机器只能跑一种算法，一栋舍里想同时做计数和行为识别就得布两套点位，成本反而更高。当然它也有适用场景，比如门口的人车识别、洗消间的合规抓拍这类功能单一、位置分散的点，用AI摄像机省一根网线和一台盒子，是划算的。

边侧是整个方案的心脏。一个栋、一栏区或者一个片区放一台边缘计算盒，负责拉流、解码、抽帧、推理、跟踪、事件判定、本地存储和告警上报。分析必须在本地做完，只把结果（结构化事件、告警截图、短视频片段）往上送。中心侧则是一个轻量平台，负责设备管理、算法版本下发、告警工单、数据看板和多场对比，它不需要看原始视频流，只在有人点开回放的时候才去边缘侧拉流。

这么切的直接好处是：断网的时候边缘侧还能独立跑，告警存在本地，恢复后补传；网络带宽需求从"每路2兆持续上行"降到"每条告警几十KB加一段10秒片段"。这个差别在规模化猪场里是数量级的。

1.3 为什么算力必须压在边缘：一笔带宽账

我给不少场算过这笔账，算完基本没人再坚持全上云。以某栋1200头育肥舍为例，布16路1080p摄像机，主码流按H.265编码、2Mbps算（这个码率在猪舍这种画面细节多、运动目标多的场景里属于下限，再低就糊了）。

16路 × 2Mbps = 32Mbps，这是单栋的持续上行需求。一个万头规模的场，育肥加母猪加保育加产房，二十几栋不算多，按20栋算，峰值上行就是640Mbps。这个数字意味着什么？意味着场里得拉一条千兆专线级别的链路，而且24小时跑满。多数猪场位置偏远，能拿到的上行带宽往往只有几十兆，中间还得经过无线回传，抖动和丢包是常态。真按全云方案做，结果一定是画面卡成幻灯片，AI分析全部失效。

反过来，边缘方案下，单台盒子只在本地局域网拉流，上行只需要走告警和心跳，平均几百Kbps就够，峰值也就几兆。这就是为什么我在方案里永远把"分析下沉"写成硬性约束，而不是可选项。

2. 视频采集与前端的硬骨头

2.1 点位设计与镜头选型的现场算法

摄像机布得好不好，直接决定算法上限。算法再强，也救不回一个逆光、糊成一片、只能拍到猪屁股的画面。我在现场总结了一套粗算方法，不敢说精确，但比拍脑袋强。

先定观察目标。栏内计数和躺卧状态，需要俯视或大角度斜俯视，镜头离地2.6到3.2米，太高会被人字架和管线挡住，太低会被猪拱到、被冲洗水冲到。育肥栏一般宽1.8到2.4米，一栏养15到25头，建议一个点位覆盖4到6个相邻栏位，既能看清单头猪的轮廓，又不至于让单栏占用太多画面。

关键参数是水平视角和像素密度。假设要看清一头80公斤育肥猪的躺卧姿态，猪体长约1.2米，我要求猪体在画面里至少占90到120像素长，这样姿态关键点才有意义。用像素密度反推：一个点位装6.0mm镜头、1/2.8英寸传感器、1920像素宽，水平视角大约55度，在3米高度斜俯视覆盖宽度约3.1米，那么每米约620像素，1.2米的猪就是740像素，非常充裕——但覆盖宽度只有3米，只够2个栏位。

反过来，装2.8mm广角镜头，水平视角约100度，3米高度覆盖宽度约7米，能盖4个栏，但每米只有274像素，猪体约330像素。这个数值用来做检测和计数完全够，用来做精细姿态和估重就偏紧。所以我的常规配置是：计数和区域事件用2.8mm广角，行为识别和估重用4mm到6mm的中焦，重要栏位单独加密点位。别想着一个点位通吃，那是给自己挖坑。

产房是另一套逻辑。产床排列密集，母猪躺卧、仔猪活动区域小，重点是"压仔"和"仔猪活动"，需要更低、更正的角度，通常装在产床上方2.2到2.5米，配4mm镜头，一个点位覆盖2到3个产床。保育舍猪只小、密度高，反而要拉高到3.5米以上做俯视，靠高机位减少遮挡。

2.2 猪舍环境对设备的真实杀伤力

这一节我认为是整篇最该抄下来的部分，因为几乎所有翻车都发生在这里。猪舍不是机房，它是高温、高湿、高粉尘、高氨气、定期高压冲洗的环境，对设备的破坏是持续性、慢性的。

粉尘是第一杀手。育肥舍和保育舍的空气里飘着大量饲料粉末和皮屑，摄像机的散热孔和镜头前盖一两个月就能糊上一层。糊了之后画面发雾、对比度下降，检测置信度整体往下掉，很多人以为是模型退化了，其实是镜头脏了。我的做法是：镜头前加装可拆卸防尘罩或亚克力保护片，两个月一换，成本几块钱，比擦镜头省事得多；同时在平台里加一条"画面质量巡检"，用拉普拉斯方差或图像清晰度指标做趋势监控，某一路连续三天指标下滑超过阈值就派工单清洗。

氨气和硫化氢对电路和接口的腐蚀是慢性的，最脆弱的是网口和尾线。我见过用了不到一年、网口铜片发绿的机器。选型上必须认准接口做防腐处理、整机防护等级不低于IP66、工作温度覆盖零下10度到零上50度的机型，机房侧交换机放在舍外的弱电箱里，箱体加防尘棉和温控风扇。

冲洗是最容易被忽略的。很多场为了防疫，栏舍清空后要高压水枪冲洗加消毒液喷洒，摄像机如果只是普通支架，水柱一扫就进水。所以点位设计时要么选用可整体罩住的防护罩，要么在冲洗流程里加一步"罩袋"动作，把这条写进作业规程，比事后赔设备便宜得多。

还有一个特别实际的坑：冬季舍内外温差大，镜头起雾结露。解决办法不是提高整机防护等级，而是让设备在舍内通电常开、保持微微高于环境温度，或者直接选带加热除霜的防护罩。这一点在北方场是刚需，南方场遇到寒潮也会中招。

2.3 网络、供电与断电断网策略

网络这块，我的基本主张是能走有线就不走无线。猪舍是钢结构加混凝土，无线信号衰减严重，加上栏位金属件、料线、风机，2.4G频段基本是灾难现场。真要用无线，只建议用在辅助点位或临时点位，主分析点位全部走网线。

布线走PoE是最省心的方案，一根网线搞定供电和数据，前端不用在舍内布220V，减少漏电和水汽侵入的风险。但要注意PoE的功率预算：带加热除霜的枪机启动功率可能到15到20瓦，一台24口PoE交换机总功率预算必须留足余量，我一般按"端口数 × 单口峰值 × 1.3"来配。网线选超五类以上，单段长度控制在90米以内，超过就上光纤收发器或者就近加一台小交换机。

供电稳定性比很多人想的更重要。猪场常见的问题是风机启停造成的电压波动、雷击浪涌、以及临时停电。边缘计算盒和交换机必须挂在小容量UPS上，至少撑住15到30分钟，这不是为了不停机，而是为了完成"断电前保存状态、恢复后自动重启"。我见过太多设备断电后卡在开机自检、需要人到现场按电源键的情况，一次跑现场就是半天。

断网策略要在方案里写成明文条款：边缘侧本地缓存不少于7天的告警事件和截图，网络恢复后按时间戳补传，重复事件去重；平台侧收到补传数据后不重复生成工单。这几条不写清楚，后面数据对不上，运维会疯。

3. AI算法能力拆解：从检测到行为理解

3.1 目标检测与计数：密集栏位的真实误差

检测是地基。目前主流做法是单阶段检测网络，输入640×640，输出猪只的边界框。训练数据来自现场实拍，标注要求每头可见猪只都打框，被遮挡超过70%的可以标为忽略区域，不参与损失计算。

真正难的不是检测本身，是密集和遮挡。保育栏里几十头小猪挤在一起睡觉，检测框大面积重叠，非极大值抑制一压，数量就少报了。我实测下来，白天活动状态下计数准确率能到95%以上，夜间密集躺卧状态下可能掉到80%出头。这个数字拿去汇报很难看，但它是事实。

所以我在方案里不承诺"精确点数"，而是把计数改造成异常检测：栏位在系统里预先录入存栏头数，AI只判断"当前检测数量与该栏基线偏差是否超过阈值"。比如一栏20头，检测到持续低于16头超过10分钟，才推"疑似缺栏/死亡/逃逸"告警。这样一来，即使绝对误差有10%，只要误差是稳定的，就不会天天误报；而真有猪只丢失、卡在缝隙里，偏差会明显超过噪声。这个思路上的转变，是我在项目里最能减少无效告警的一招。

另外补一句实操：固定机位 + 固定栏位标定是精度的前提。每路视频在配置时都要在画面上画一次多边形，标注每个栏位的区域，这个标定数据要跟点位编号绑定存档。换机位、调角度之后必须重新标定，否则区域就错位了，事件会全部串位。

3.2 多目标跟踪与身份延续的工程取舍

只做检测不做跟踪，等于每次抽帧都从零开始，没法计算"停留时长""移动轨迹""是否同一头猪"。所以跟踪是必须的，主流用的是"检测 + 运动预测 + 外观特征匹配"的组合。

猪场的跟踪难点有三个。第一是外观高度相似，同一栏的育肥猪在俯视视角下几乎是复制粘贴，外观特征基本失效，只能靠运动连续性。第二是频繁交叉和遮挡，猪只走动时会互相穿过，ID跳变很常见。第三是长时间静止，躺卧的猪几小时不动，跟踪器容易把它判为消失再重新分配新ID。

我的处理方式是分场景配置跟踪策略。活动区域（采食区、饮水区、通道）用较短的最大丢失帧数，允许ID快速重建，因为这里关心的是"有没有猪在活动"；躺卧区用较长的丢失容忍，配合位置约束，把ID尽量稳住。同时在业务层做兜底：不追求全局唯一ID，只追求"事件级别的连续性"。比如判断"某头猪持续躺卧超过4小时"，只需要在区域级别累计"存在躺卧目标且位置基本不变"的时长，不需要知道它是哪一头。这个降级思路牺牲了单猪级别的健康档案，但换来了稳定可用，我觉得在现阶段是划算的。

如果确实要做个体级管理（比如母猪），那就得上耳标或电子耳标配合，视频只做辅助验证，别指望纯视觉在群体栏里给每头猪建终身档案，这是目前技术边界之外的事。

3.3 行为识别：打架、咬尾、堆叠怎么判

行为识别我的做法是不直接上三维卷积端到端模型，而是在跟踪结果之上做时序特征工程，可解释、好调参、算力省。具体是把每个区域内的目标数量、目标间距离、运动速度、光流强度、停留时长这些量按秒聚合成时间序列，再用简单规则加轻量分类器判断。

打架的判定：区域内至少两个目标，目标间距在短时间内反复小于体长的一半，且双方运动速度都高于基线，持续超过8到15秒（这个阈值按猪只体重调，小猪打得快、时间短，大猪对抗时间长）。为避免把"同时起身抢食"误判成打架，我会把采食时段（比如早晚喂料后20分钟）设为抑制窗口，这个时段不报打架。

咬尾的判定更难，因为在俯视画面里咬尾的动作幅度小。我用的替代指标是"局部聚集度"：某小区域内目标密度显著高于该栏基线，且伴随局部光流活跃，持续超过30秒才报。这个指标本身不精确，所以定位是"提示技术员去看一眼"，不是确诊。实际用下来，有经验的饲养员看一眼截图就能判断，价值在于帮他省了巡栏时间。

堆叠的判定要特别小心，因为保温灯区域小猪扎堆是正常行为。我的做法是把保温区在标定阶段单独圈出来，堆叠判定只在非保温区生效；同时区分时间段，夜间低温时段和非低温时段用不同阈值。这一条如果没做，冬天一晚上能给你推几百条误报，系统信誉直接归零。

跛行的判定我只做到"疑似"级别，靠步态周期不对称和移动速度下降的组合指标，且只对通道区域生效，因为那里猪只必须走动。这个能力我一般不写进合同指标里，写进去容易验收不过。

3.4 估重与体况评分：从像素到公斤的换算

估重是场里最感兴趣、也最容易吹过头的功能。原理不复杂：固定俯视机位下，猪体的投影面积与体重高度相关，用轮廓分割拿到像素面积，再用标定系数换算成实际面积，代入回归模型出体重。

关键在标定。画面里必须有一个已知尺寸的参照物，比如栏门的宽度、料槽的长度，或者干脆在标定阶段放一块已知边长的标定板。没有这个，像素到厘米的换算就是猜。标定完成后，每头猪的像素面积可以反推实际投影面积，再结合体长宽比修正姿态影响。

误差方面，我实测的经验值是：同一栏、同一机位、光照稳定条件下，单头误差在正负5%到8%，栏均重误差能压到正负3%以内。听起来不错，但要注意这个数字的前提——猪只必须站立或舒展躺卧、不能被遮挡、不能挤在一起。密集躺卧时，分割轮廓会粘连成一片，这时候只能算栏均，算不了单头。

所以我在方案里把估重定位成"出栏节奏辅助工具"：每周出一次栏均重曲线，判断增重是否达标、是否该调整饲喂策略，而不是拿去给每头猪称重卖猪。真要精确到单头，得上通道式称重或者深度相机，那是另一套成本和另一套方案。

体况评分类似，靠背部轮廓的曲率特征做分级，我一般只做三档（偏瘦、适中、偏肥），档位之间留足缓冲带，避免在边界上反复跳变。这个功能对母猪场价值更大，育肥场用不太上。

3.5 红外测温与发情监测的边界在哪里

红外测温几乎每个方案书里都会写，实际能落地的少。原因在于精度。热成像模块测的是画面表观温度，受环境温度、风速、猪毛表面状态、镜头污染影响极大。要做到正负0.5度以内，必须有黑体做实时校准，而且测温区域要稳定落在耳根或眼周这种血管丰富、毛发少的部位，这要求猪只头部朝向相对固定。

我的实际做法是把它定位成"群体筛查"：对通道或采食位的猪只做批量测温，输出栏内温度分布，只报"存在明显偏离群体均值的目标"，然后由人工用兽用体温计复核。这样用，误报率可以接受，也确实能提前发现发热个体。想直接用它替代体温计做诊断，现阶段不现实，别给场里这个预期。

发情监测的逻辑相对靠谱，因为它靠的是行为而不是温度。母猪发情期的典型表现是静立反射——其他猪爬跨时它保持不动。算法上就是跟踪"爬跨事件"：两目标在垂直方向重叠、上方目标有前后运动、下方目标位置基本不变，且持续时间超过阈值（一般单次超过3到5秒，一天累计出现多次），就推发情候选。这个能力在限位栏改成大栏群养之后价值明显上升，因为群养下人工观察发情更费劲。但要提醒的是，它只能提高发现率，不能替代公猪试情，把它当辅助排产工具用。

4. 边缘算力、存储与平台工程实现

4.1 算力与码流预算怎么算，给你一套能直接套的算法

这是方案里最容易被厂商牵着走的部分。厂商说"一台盒子带32路"，你得问清楚是"接入32路"还是"分析32路"，这两个差一个数量级。

先算分析需求。假设一路视频我们并不需要每帧都推理，抽帧率取5帧每秒就足够判断行为（猪的动作不快）。单路需要的推理吞吐就是5次每秒。16路就是80次每秒。轻量检测网络在主流边缘AI盒子上，640×640输入、半精度推理，单卡吞吐大概在120到200次每秒之间（不同硬件差异大，这个数要实测）。加上跟踪、解码、编码开销，实际可用算力打个六折。

按这个算，一台中等算力的盒子带16到24路是合理的，再多就要降抽帧率或者换更小的输入尺寸。我的配置习惯是按栋配盒子、留30%余量，一栋育肥舍16路配一台，后续加两路也不用换机器。

再算带宽和解码。16路1080p同时解码，靠CPU软解是撑不住的，必须用硬件解码。这一条在选型时要明确问：支持多少路1080p硬件解码？很多低价盒子标称支持，实测8路就开始掉帧。

存储这块给一个直接能用的计算：单路1080p、2Mbps码流，一天的存储量 = 2 Mbps × 86400 秒 ÷ 8 = 21600 MB，约21.1 GB。30天是633 GB，加上索引和冗余，按0.7 TB算。16路30天全量存储约11 TB。

但我不建议全量存30天。实际策略是全量存7天 + 告警事件片段存90天。7天全量16路约2.4 TB，用4块4TB硬盘做RAID5或直接两块做镜像都够；告警片段每天可能只有几百条，每条10到30秒，一年也就几百GB。这个组合性价比最高，也满足追溯需求——真出事的时候你要看的是那一段，不是30天前的全部画面。

4.2 边缘侧的软件栈怎么搭

边缘盒子里跑的软件我一般拆成五个进程，互相隔离，一个挂了不影响全局：

拉流与解码进程，负责按RTSP地址拉流，断流自动重连，输出解码后的帧队列。这个进程最需要健壮性，因为猪场网络抖动是常态，重连逻辑要写成指数退避，不能死循环把CPU打满。

抽帧与预处理进程，按配置的帧率采样，做缩放、归一化、ROI裁剪。ROI裁剪很关键，只把栏位区域送进推理，能省30%到50%算力。

推理与跟踪进程，加载模型、跑推理、维护跟踪状态、做事件判定。模型和配置都从本地文件读，支持热更新。

事件与存储进程，把事件写本地数据库、截图落盘、生成短视频片段、按优先级推送。

通信进程，负责心跳、配置拉取、事件上报、远程回放代理。

配置示例我习惯用YAML，一眼能看懂，改参数不用改代码：

camera: id: "B2-03" house: "育肥2栋" rtsp: "rtsp://user:pass@10.20.3.31:554/Streaming/Channels/101" decode: "hardware" reconnect: base_delay_ms: 2000 max_delay_ms: 60000 factor: 2 analysis: sample_fps: 5 input_size: [640, 640] roi: - name: "栏位A01-A06" points: [[120, 210], [1780, 210], [1780, 960], [120, 960]] tasks: - type: "count" interval_s: 60 baseline: 20 deviation_threshold: 4 duration_s: 600 - type: "fighting" min_duration_s: 10 suppress_windows: [["06:30", "07:10"], ["17:30", "18:10"]] - type: "immobile" duration_s: 14400 posture: "lateral" - type: "weight_estimate" schedule: "0 3 * * *" calibration_ref_m: 1.20 storage: full_record_days: 7 event_record_days: 90 clip_seconds: 20

告警规则用JSON描述，平台侧直接下发，方便批量改：

{ "rule_id": "R_IMMOBILE_01", "name": "疑似长时间不动", "scope": {"house": "育肥2栋", "camera": "B2-03"}, "condition": { "type": "immobile", "duration_s": 14400, "exclude_zones": ["饮水区", "保温区"] }, "level": "warning", "actions": [ {"type": "snapshot"}, {"type": "clip", "seconds": 20}, {"type": "notify", "channel": "shift_leader", "cooldown_s": 3600} ] }

冷却时间这个字段特别重要，同类告警在同一区域必须设冷却，否则一条持续存在的异常会每分钟推一次，运维第一天就会把通知关掉。

4.3 可视化管理界面到底该放什么

"可视化管理"这个词被用烂了，很多项目最后做出来的就是一块大屏加几个数字。我做下来的体会是：可视化不是为了好看，是为了缩短从事件发生到有人处理的时间。所以界面的第一优先级是"现在有什么需要人管"，而不是"一共装了多少路摄像头"。

我的界面结构一般分四块。顶部是待处理告警条，按严重程度排序，每条带截图、时间、位置、建议动作，点进去直接跳到对应视频的对应时刻。中间是猪舍平面热力图，把每个栏位的状态用颜色表达，绿色正常、黄色待观察、红色待处理，一眼看清哪个栋有问题。左边是栏位列表，支持按栋、按栏筛选，点开看单栏详情：存栏数、今日活动量、采食区停留时长、最近告警。底部是环境数据叠加，温度、湿度、氨气浓度、二氧化碳，和视频事件对齐在同一时间轴上。

这个时间轴对齐是我认为最有价值的设计。很多"猪不吃料"的问题，单看视频看不出原因，但把温度和采食行为叠在一起，就能看出是那天夜里温度掉了4度。视频AI的最大价值不是单独成立，而是和环控数据、饲喂数据交叉验证。所以在方案里我会明确要求：视频平台必须提供标准接口，能把事件数据推给场里已有的饲喂系统和环控系统，或者反向拉取它们的数据做关联。

告警闭环也得设计。每条告警要有状态机：待确认、处理中、已关闭、误报。误报必须允许标注，并且标注数据要能回流，这是模型迭代的燃料。我见过不少系统上线后误报一直降不下来，就是因为没有误报反馈入口，算法团队拿不到现场数据。

4.4 边缘与中心的通信和离线设计

通信协议我一般选轻量的消息方式，事件用小JSON包，截图和视频片段走对象存储或者文件传输，分开通道，避免大文件把事件通道堵住。

离线是必须设计的场景。猪场断网的原因五花八门：施工挖断、运营商故障、雷击、欠费。边缘侧要能独立运行至少7天，本地存储满了之后按"低等级事件先淘汰、高等级事件保留"的策略清理。恢复联网后按时间戳顺序补传，平台侧做幂等去重，用事件ID做唯一键。

远程回放我建议做成代理模式：平台不存原始视频，用户点开回放时，平台向边缘侧请求该时间段的流，边缘侧转成标准流协议回传给平台。这样中心侧不用买大存储，代价是回放依赖边缘在线。为了保证可用，边缘侧要保留"最近7天任意时刻可回放"的能力。

5. 数据标注、模型迭代与验收

5.1 数据采集与标注规范怎么定

模型的水平，七成取决于数据。我接手过几个"算法不行"的项目，翻开训练集一看，全是网图加少量白天晴天素材，难怪一上现场就崩。现场数据必须自己采，而且要覆盖足够的变化维度。

采集清单我一般这么定：每个栋至少采3个时段（早、中、夜），每个时段覆盖晴天、阴天、开灯、关灯四种光照，每种光照下采至少200帧有效画面，另外单独采一批冲洗后、镜头有雾、有蜘蛛网、有飞虫的异常样本。异常样本别嫌脏，这些恰恰是现场误报的主要来源，训练集里带上，模型才不会把一团雾气当成一头猪。

标注规范要写成文档，不能靠口头。核心几条：可见猪只全部标注；遮挡超过70%的标为忽略；小猪仔猪单独一个类别；人、料车、风机、水管这些常见误检目标单独建类，让模型学会区分；画面里固定的结构件（栏杆、料槽）用多边形标出来做背景抑制。标注一致性要靠抽检，我一般抽10%做双人复核，一致率低于90%就重新培训标注员。

还有一条经验：负样本比正样本更重要。猪场里大量画面是"什么都没有"的正常状态，如果负样本不足，模型会到处找东西，产生大量误检。我一般按正负样本1比2的比例配，让模型见过足够多的"正常"。

5.2 训练、压缩与部署的完整链路

训练本身不复杂，用开源的检测框架，主干选轻量级的，输入640×640，数据增强重点做亮度扰动、雾气模拟、遮挡模拟、运动模糊，这几样最贴近猪舍实际。

训练配置的关键参数我一般这么设：批量大小按显存给，学习率用余弦退火，初始值1e-3，训练100到150轮，前5轮做 warmup。验证集按栋划分，不能用同一栋的数据同时训练和验证，否则指标虚高。

train: epochs: 120 batch_size: 32 input_size: [640, 640] optimizer: "sgd" lr0: 0.001 lrf: 0.01 warmup_epochs: 5 augment: hsv_h: 0.015 hsv_s: 0.6 hsv_v: 0.5 mosaic: 0.8 blur: 0.1 brightness: 0.3 val_split: "by_house"

训练完不能直接上盒子，要做量化压缩。半精度量化基本不掉精度，速度提升明显；INT8量化能再快一截，但需要一批代表性数据做校准，校准集一定要包含夜间和脏镜头样本，否则量化后夜间精度会明显下滑。压缩完必须回现场复测，实验室指标和现场表现经常差一截。

部署我建议做灰度：新模型先在1到2路点位上跑一周，和旧模型并行，比对误报率和漏报率，确认没退化再全量下发。这一步看起来慢，但比重训一次模型的成本低得多。

5.3 验收指标：别只盯着mAP

这是我最想强调的一点。合同里如果只写"检测准确率不低于95%"，验收时一定扯皮，因为双方对"准确率"的定义不一样。

我建议把验收拆成三层指标。技术层：检测mAP、跟踪ID保持率、单帧推理耗时，这些是给算法团队看的，用来定位问题。业务层：这是给场里看的，比如栏内计数偏差超过阈值的误报每天不超过N条、打架事件平均发现时延不超过2分钟、长时间不动事件的漏报率不高于10%、单栋日均有效告警不超过20条。运营层：告警响应率、平均处理时长、误报标注率。

其中"单栋日均有效告警不超过20条"这条我认为最关键，因为它直接决定了系统会不会被弃用。人一天能认真处理的告警就那么点，超过这个量，告警就变成了噪音，所有人都会选择性忽略。为了守住这条线，宁可把灵敏度调低、漏一点，也不能让误报泛滥。宁可少报，不可滥报，这是我在所有项目里坚持的原则。

验收还要设观察期，至少连续跑30天，覆盖一次完整的生产周期和一个天气变化过程，用真实数据算指标，而不是验收当天的演示效果。演示时挑最好的一路给你看，那是没意义的。

6. 常见问题与排查实录

6.1 误报漏报的速查表和定位思路

现场问题八成集中在误报和漏报上。我整理了一张速查表，基本覆盖我遇到的情况。

定位思路我总结成一句话：先看画面，再看时间分布，最后看模型。太多人一上来就怀疑算法，实际上70%的问题在画面质量和标定上。养成习惯，出问题第一件事是把那一路的原始画面调出来看一眼，脏不脏、偏没偏、亮不亮，三秒钟就能排除一半可能。

6.2 施工和运维阶段最容易踩的坑

排名第一的坑是标定数据没存档。机位调了、摄像头换了，没人记得原来的区域坐标，事件全部错位，而现场又说不清是哪天动的。解决办法很土但有效：每路点位交付时截图存档，标注区域坐标，设备编号和物理位置一一对应，贴标签，写入台账。

排名第二是施工顺序错了。有的项目是先装摄像头，再刷墙、再装风机、再改栏位，等全部弄完，一半点位的角度全废了。正确顺序是土建和栏位改造完成、设备布局定稿之后再上摄像机，而且要在正式投产前留出一段空栏期做调试，那时候可以进人、可以摆标定板、可以反复调角度。等到猪进栏了，你想进舍调一次机位都得走生物安全流程，成本翻几倍。

排名第三是没人接手运维。系统交付的时候热热闹闹，三个月后摄像头歪了没人扶、镜头脏了没人擦、告警没人看。我的做法是在交付阶段就把运维动作写进场的日常规程：每天早班看一眼待处理告警、每周做一次画面质量巡检、每月清洗一次镜头、每季度校一次标定。这些动作要落到具体的人和具体的表格上，不是写在方案里就完事。

还有一个细节坑：UPS只挂了盒子没挂交换机。断电瞬间交换机先挂，盒子还在跑但拉不到流，日志里全是断流重连，恢复后要等好几分钟才能自愈。这种问题很难查，因为表现是"偶尔卡顿"，实际上就是供电设计漏了一环。

6.3 成本构成与投入产出怎么粗算

成本我一般拆成四块：前端（摄像机、支架、防护罩、线材、PoE交换机）、边缘（计算盒、UPS、弱电箱）、平台（软件授权、服务器或云资源）、实施与服务（布线施工、标定调试、标注训练、运维）。

按一栋1200头育肥舍、16路点位粗算，前端加布线大概在几万元量级，边缘一台盒子加配件也是万元级，软件按点位或按栋授权，实施费用视现场条件浮动较大。整体下来单栋投入在十万以内是比较常见的区间，规模化之后单栋摊薄会明显下降，因为平台侧是一次性投入。

产出这块不好精确算，但可以从三个方向估。一是减少死淘：及时发现病弱猪、及时干预，育肥阶段死淘率下降一点几个百分点，按一头猪的市值算，一栋一年就是可观的数字。二是减少人工巡栏时间：夜班巡栏从每两小时一趟改成按告警出动，一个夜班技术员能多管几个栋。三是减少异常损失：咬尾、打架造成的胴体损伤降级，以及母猪压仔的及时干预。

不过我得说实话，ROI 高度依赖场的执行水平。同样一套系统，有的场用得风生水起，有的场三个月就荒废。差别不在技术，在于有没有人真的把告警当回事、有没有把处置结果录进系统、有没有拿数据去复盘。所以在做投入测算的时候，我一般会把"人员培训和流程改造"单列一项预算，这一项省不得。

6.4 分阶段落地的推进节奏

我不建议一次性把所有功能全铺开。比较稳的节奏是三步走。

第一步，只做视频接入和基础可视化，让场里先习惯"有画面可查、有回放可调"。这一步不涉及AI，风险最低，但能解决"出了事找不到录像"这个最基础的问题，也能让技术员熟悉界面。

第二步，上计数和区域事件，也就是缺栏、聚集、长时间静止这几类。这几类算法成熟、误报可控，能在两三周内让场里感受到价值——最典型的是夜里不用起床巡栏，手机上收到一条"某栏长时间不动"的推送，起来看一眼就行。

第三步，上行为识别和体况推断，同时打通和饲喂、环控系统的数据关联。这一步需要前期积累的标注数据，也需要场里配合做误报标注，节奏上要慢，宁可从一两个栋试点，跑顺了再复制。

每一步之间留出至少一个月的观察期，用真实数据判断要不要往下走。走得太快，问题堆在一起，分不清是算法问题、施工问题还是流程问题，最后项目就烂尾了。

7. 我在实际项目里沉淀的几条经验

先说一条我觉得最值钱的：把AI的定位从"替代人"改成"提醒人"。凡是承诺"全自动判断、无需人工"的功能，最后都会在现场崩掉，因为猪场的情况太复杂，算法只能处理见过的模式。而"提醒人去看一眼"这个定位，容错率高得多，技术员看一眼截图就能确认，错了也只是多走一趟，不会造成损失。预期管理做好了，系统的口碑反而更好。

第二条是关于产品形态的。我发现很多场真正高频使用的不是大屏，是手机。大屏装在办公室，场长一周看两次；手机揣在兜里，告警一响就掏出来。所以方案里我把移动端的优先级排在网页端前面，告警推送必须带截图，点开必须能直接看那段视频，两步之内完成判断。这个细节决定了系统是"活的"还是"摆设"。

第三条是关于数据的。视频AI产生的数据本身价值有限，和环控、饲喂、生产记录对齐之后才有价值。我做过一个对比，单看"采食区停留时长下降"，技术员会觉得是算法不准；加上"当天夜间温度低了4度"这条信息，结论立刻清晰。所以我现在的方案里，数据打通不是可选项，是必选项，接口对不上就先不做这一路分析。

最后一个小技巧，关于镜头清洗周期的。别按固定周期，按画面清晰度趋势来派工。我在平台里加了一个简单的清晰度指标日统计，连续三天下降超过阈值就自动生成一条清洗工单，指派给对应栋的负责人。这比"每月一号擦一次"合理得多，因为有的栋粉尘大、有的栋干净，一刀切要么浪费人力，要么漏掉该擦的。这个小功能上线之后，因画面模糊导致的误报下降了一大截，成本几乎为零。