企业官网建设流程全解析

养猪场做视频 AI 监控这件事，听着像是把现成的安防方案搬进猪舍，真干过的人都知道完全不是一回事。安防只需要看清人和车，猪场要看清的是几十头挤在一起、颜色几乎一样、还不停拱来拱去的活物，摄像头三个月不擦就糊上一层粉尘和生物膜，夏天栏舍里水汽重得镜头起雾，冬天红外一切换，画面全变成黑白噪点。这套智慧养猪场视频AI智能监控与可视化管理方案，本质上是把"摄像头+边缘算力+算法模型+可视化平台"组装成一套能长期在恶劣环境里跑下去的生产工具，替代人工巡栏里那些重复、耗时、还容易漏看的环节：夜间压死仔猪、母猪难产、猪只长时间不吃不喝、栏内异常聚集、外来人员违规进入。适合谁看？如果你是养殖企业的信息化负责人、做农业物联网集成的工程商、或者刚接手这类项目的算法工程师，下面这些内容基本覆盖了从选型到落地的完整链路，里面有些数字是现场一点点试出来的，可以直接拿去当参考基线。

1. 先想清楚：猪场要的不是摄像头，是能自动报警的眼睛

1.1 三类真实痛点与对应的能力清单

我见过不少项目一上来就谈"AI 养猪"，方案书写得花团锦簇，落地时只剩一个能实时看画面的 App。问题出在需求没收敛。猪场愿意为视频监控掏钱，通常是被三件事逼的。

第一件是夜间和凌晨的无人时段。猪场夜班人手最少，而母猪分娩、仔猪压死、猪只互相挤压致伤恰恰高发在夜里。这类需求对应的是"异常行为检测+实时告警"，不是录像回放。录像回放只能事后追责，救不回损失。

第二件是人工巡栏的覆盖率不足。一个存栏几千头的场，饲养员一天巡几遍，每遍走马观花，靠肉眼判断哪头猪精神不好、哪栏采食量下降，经验依赖极强，人一换就断档。这类需求对应的是"行为统计+趋势对比"，要的是把"这栏猪今天活动量比过去七天均值低了 30%"这种话说出来。

第三件是生物安全与人员管理。谁进了哪个区、有没有按流程换装、有没有跨区串舍、外来车辆停在哪，这些靠门禁和自觉都不牢靠。这类需求对应的是"人员检测+区域入侵+轨迹回放"。

把这三件事拆开，能力清单就清楚了：目标检测（猪、人、车、异物）、多目标跟踪（给每头猪一个临时 ID）、行为分类（采食、饮水、躺卧、站立、走动、聚集、异常久卧）、事件规则引擎（时间窗口+区域+阈值）、可视化与推送。方案里没写清楚这几层的，基本可以判断是套模板。

1.2 能力边界：哪些能做，哪些先别指望

这一点我必须提前说透，否则验收时双方都难受。

能做得比较稳的：限定区域的人员入侵、非工作时间人员活动、猪只长时间不动、栏内猪只数量异常、大面积聚集堆叠、夜间活动量骤降、摄像头遮挡和画面异常。这些事件的共同点是"目标大、特征明显、容错空间大"，算法差一点也能用规则兜住。

能做但要接受误差的：跛行识别、咬尾识别、采食次数统计。这几类受遮挡、光照、拍摄角度影响极大，同一头猪在不同镜头下表现完全不同，实际准确率通常在 75% 到 88% 之间波动，必须配合人工复核。

现阶段别当刚需的：个体身份长期识别（猪不像人有稳定人脸，靠花纹和耳标，长膘之后外观会变）、疾病诊断（咳嗽声学分析可以做辅助，但不能替代兽医）、精确估重（误差能压到 8% 到 12% 已经不错，只能用于趋势判断和分栏参考，不能用于结算）。

注意：方案汇报时把边界讲清楚，比把准确率吹到 99% 更容易活得久。猪场老板真正在意的是"你报的警我信不信"，一次狼来了，后面所有告警都会被关掉。

2. 整体架构：三层结构怎么落，钱花在哪一层

2.1 采集层、边缘层、平台层的职责划分

整套系统我习惯切成三层，每层的职责边界要划死，不然出了问题互相推。

采集层就是摄像头和网络。职责只有一个：稳定输出可用的视频流。这一层不承担任何智能，选型原则是"宁可多花两百块买宽动态好一点的机型，也别指望后期靠算法补救"。

边缘层是部署在场区机房的边缘计算盒子或小型服务器。职责是拉流、解码、推理、跟踪、事件判定、本地存储、按需上传。这一层是整套方案的成本大头，也是稳定性关键，因为场区网络一旦断掉，边缘层必须能独立跑下去。

平台层是部署在云端或集团机房的业务系统。职责是设备管理、算法版本管理、多场区数据汇聚、可视化大屏、告警推送、报表。平台层不参与实时推理，它挂了不影响现场告警，这是架构设计上必须保住的底线。

三层之间的数据流是这样的：摄像头 RTSP 推流到边缘盒子，盒子上跑模型，输出结构化结果（时间、相机编号、事件类型、目标框、置信度、截图 URL），结构化数据走 MQTT 或 HTTP 上报平台，视频原始流只在触发事件时上传前后各 10 到 15 秒的片段。这个设计直接把上行带宽压下来一个数量级。

2.2 推理为什么必须放在场区本地

有人算过账，觉得集中式云端推理更省钱，GPU 利用率高。这账在猪场算不通，原因有三个。

网络不稳定。很多规模场位置偏，专线月租贵，4G 备份链路带宽有限且抖动大。32 路 1080p 视频全往上推，按每路 4Mbps 算就是 128Mbps 的持续上行，任何一条民用或商用宽带都扛不住长时间跑。

时延要求。压死仔猪这类事件，从发生到造成损失可能就几分钟，告警延迟超过 30 秒，处置价值就打对折。本地推理链路能把端到端延迟控制在 3 秒以内。

数据敏感与成本。连续视频全量上云，存储费用是按 TB 级别滚的，一个中等规模场一年下来能顶掉半套硬件钱。本地存 30 天，云端只存事件片段和缩略图，成本结构完全不同。

所以我的一般建议是：边缘盒子按"每 8 到 16 路一路盒子"配置，盒子上做全量推理，只上传结构化结果和事件片段。云端做的是管理和二次分析，不是实时推理。

2.3 与环控、饲喂、称重系统的数据缝合

视频单独看，价值有限。真正的价值在多源数据交叉验证。

举个最简单的例子：系统检测到某栏猪只日间活动量下降，同时环控系统显示该栏温度比设定值高了 4 度、氨气浓度上升，饲喂系统显示采食次数下降。三条线同时指向异常，这个告警的可信度就完全不一样了。

对接方式上，我通常走两条路：如果对方的环控、饲喂系统有开放接口，用 Modbus TCP 或 HTTP 拉数据，5 分钟一次入库；如果没有接口，就在现场加装采集网关，从 RS485 总线上旁路读取。时间戳一定要统一，所有设备对 NTP 服务器校时，误差控制在 1 秒以内，否则后面的关联分析全是错位的。

3. 摄像头选型与布点：效果的天花板在这里定死

3.1 采购参数逐项拆解

这部分是最容易被低价中标坑掉的地方。同样标"400 万像素"，差价能到三倍，差别全在参数细节里。

还要特别提醒一件事：镜头防污。猪舍的空气里飘的是粉尘、皮屑和水汽混合物，一个月就能在镜头上结一层膜。选型时优先考虑带疏水镀膜、外罩可拆卸的结构，后期维护成本差别巨大。

3.2 布点高度、角度与覆盖面积的计算

布点这件事，我习惯用"反算"的方法：先确定要识别的目标最小像素尺寸，再倒推安装距离。

以育肥舍为例，目标是识别单头猪的躺卧姿态，经验上单头猪在画面里至少要有 60×60 像素才能稳定判断姿态。一头育肥猪体长约 1.2 米，如果希望它在画面中占 240 像素宽（留 4 倍余量给跟踪和姿态），水平视场覆盖宽度 W 与画面宽度的关系是：猪体像素 = 画面宽度像素 × (1.2 / W)。

400 万像素水平分辨率 2560，代入得 240 = 2560 × 1.2 / W，解得 W ≈ 12.8 米。也就是说，一个镜头水平覆盖 12 到 13 米宽比较合适，超了目标就太小。

4mm 镜头在 1/1.8 英寸传感器上水平视场角约 90 度，安装高度 h 与覆盖宽度关系近似 W = 2h·tan(45°)，得 h ≈ 6.4 米。这个高度在栏舍里不现实，所以实际做法是降到 3 米左右、把镜头俯角压到 60 到 75 度，用斜俯视覆盖 8 到 10 米宽，接受边缘区域像素略降。

实际布点我一般这样安排：

• 育肥舍：沿走廊侧墙安装，高度 2.8 到 3.2 米，俯角 60 到 70 度，单机覆盖 2 到 3 个栏位，约 40 到 60 平方米。
• 产房：这是重点区域，密度高、事件多。高度降到 2.2 到 2.5 米，单机只覆盖 4 到 6 个产床，俯角接近垂直（75 到 85 度），确保能看清仔猪在母猪身边的位置。
• 保育舍：猪小、密度大，单机覆盖面积减半，控制在 20 到 30 平方米，否则小猪在画面里只剩二十几个像素。
• 通道与出入口：用 2.8mm 广角，安装高度 2.5 米，正对通行方向，用于人员识别和轨迹串联。

3.3 现场施工的六条硬规矩

这几条是纯粹靠返工换来的经验，写进施工规范能省很多事。

1. 走线必须独立桥架。视频线和环控的动力线分开走，至少间隔 30 厘米。猪舍里风机、刮粪机启停频繁，电磁干扰强，共管走线会出现规律性花屏，排查起来能耗掉一整天。
2. 摄像头支架不固定在吊顶上。吊顶会随风机振动，画面持续轻微抖动，跟踪算法会误判为运动。支架要打到结构梁或墙体。
3. 网线用室外级、带防水接头。普通网线在消毒水汽环境下一年就氧化，接触电阻上升导致丢包，表现为画面卡顿但设备在线。
4. 每路预留 20% 带宽余量。交换机选型按满配码流 × 1.2 计算，PoE 供电功率按峰值 × 1.3 计算，别按标称值卡着买。
5. 镜头前 30 厘米内不能有遮挡物。料管、灯具、喷淋头都要避开，否则夜间补光会在画面里形成大面积过曝区。
6. 每台设备贴双标签。一个是物理位置标签（几栋几栏），一个是系统内编号，两者对应关系写进台账。后期告警定位全靠这个，标签掉了就是灾难。

提示：施工完成后先做 72 小时连续录像回看，重点看夜间 0 点到 5 点的画面质量。白天的画面都很漂亮，问题全在夜里暴露。

4. 算法组合拳：检测、跟踪、行为、估重

4.1 从"看到猪"到"认出这头猪"

单帧检测只能告诉你"画面里有 18 头猪"，这没什么用。要产生业务价值，必须做到"第 3 号栏位东侧有一头猪持续躺卧超过 4 小时没有变换姿势"。

技术路径是检测加跟踪。检测用 YOLO 系列，输入 640×640 或 960×960，输出猪、人、车的边界框；跟踪用 ByteTrack 或 BoT-SORT，靠运动预测和外观特征把跨帧的同一个目标关联起来，给一个临时轨迹 ID。

这里有个细节：猪群密集时遮挡极其严重，检测框会互相重叠，跟踪 ID 频繁跳变。工程上的处理办法是降低检测置信度阈值（从 0.5 降到 0.3）、提高跟踪的最大丢失帧数（从 30 帧提到 60 帧），宁可多留一些低置信度候选，也不要让轨迹断掉。轨迹断了，后面的时长统计全是错的。

行为分类走的是另一条路：把每个轨迹在过去 N 帧（比如 3 秒）的图像块裁出来，做时序分类。轻量方案是用检测框的宽高比变化 + 中心点位移做规则判断（宽高比大于 1.8 且位移小于阈值判为躺卧），这个方案准确率能到 85% 左右，算力几乎为零；重一点的方案是接一个轻量时序模型，把连续 16 帧缩到 112×112 送进去，能区分采食、饮水、站立、走动、异常久卧，准确率提升到 90% 上下，代价是每路多出约 0.5 TOPS 算力。

我的建议是：规则先上，跑一个月收集 badcase，再决定要不要上模型。很多场景规则就够用了。

4.2 事件定义表：什么才算异常

这是整套系统里最需要和养殖方一起确认的部分。算法不知道什么叫"异常"，得人把规则写出来。

规则里那个"持续时间窗口"是关键参数，它直接决定了误报率。窗口太短，猪翻个身就报警；窗口太长，真出事了报不出来。我的经验值是：从 30 秒起步试，按现场误报情况以 1.5 倍为步长往上调，一般调到 2 到 5 分钟能取得比较好的平衡。

4.3 体重估算的可行做法与误差控制

估重是很多场特别想要的功能，因为卖猪的时候称重环节费时费力。但必须说清楚：视频估重是"看体型猜体重"，不是"称重"。

可行的方法是俯视投影面积回归。用摄像头拍到的俯视图，分割出猪只轮廓，计算背部投影面积 S、体长 L（首尾方向）、体宽 W（背腹方向），然后拟合成体重。经验公式形如：

体重 ≈ a × S^1.5 + b × L × W^2 + c

其中 a、b、c 是用同一批次、同品种、已知体重（地磅称过）的样本拟合出来的系数，每换一个品种或品系都要重新标定。

误差来源主要有四个：拍摄角度不垂直导致的投影畸变、猪只蜷缩躺卧时轮廓失真、采食后腹部膨大、不同肥瘦程度密度不同。控制手段是对应做四件事：只对站立或平躺姿态的样本估重、按姿态分类分别建模、固定在固定时间段（比如早晨空腹）采样、按批次每周用 10 到 20 头地磅数据做校准。

实际误差能做到 8% 到 12%，一头 120 公斤的育肥猪，误差在 10 到 15 公斤。这个精度用在"评估这批猪能不能出栏"够用，用在"按重量结算"绝对不行，合同里千万别这么写。

4.4 数据标注与样本治理

模型效果好不好，八成看数据。标注这块有几个坑必须提前绕开。

标注规范要统一。同一头猪，A 标成"躺卧"、B 标成"侧卧"，模型就学废了。开工前先出标注手册，定义清楚每个类别、每个类别的边界情况怎么处理，比如"半躺半站"归到哪一类。

数据要覆盖全时段。白天样本容易采，夜里样本最珍贵。我通常要求每路摄像头至少采集 24 小时完整周期的视频，抽帧按白天 60%、夜间 40% 的比例分配，否则模型在夜间的性能会断崖式下跌。

要做难例挖掘。跑一个月之后，把误报和漏报的片段全部截出来，人工复核后加入训练集。这一轮迭代带来的提升，往往比换更大模型更大。

样本量参考：单场景单类别，起步 3000 到 5000 个标注框能跑出可用效果；要覆盖多场景（育肥、保育、产房、不同栋舍），总量准备 2 万到 5 万框比较稳妥。

注意：摄像头位置一旦变动，模型需要重新验证。俯角从 65 度改成 80 度，画面里猪的形态变化非常大，原模型精度会掉 10 个百分点以上。施工前把位置定死。

4.5 误报抑制的四道工程手段

误报是这类系统上线后最致命的敌人。技术手段上我一般叠四层。

第一层，置信度分级。不是所有检测都要报警。置信度高于 0.8 的直接进入事件判定，0.5 到 0.8 的进入待定队列，需要连续多帧命中才升级。

第二层，多帧投票。单帧命中不算数，要求连续 N 帧（比如 15 帧，约 1 秒）中有 70% 以上命中，才认为事件成立。这一层能过滤掉绝大部分瞬时误检。

第三层，区域掩膜。把门口、料线、饮水器反光区、风机叶片这些天然会产生干扰的区域从检测范围里抠掉。风机叶片是最典型的干扰源，旋转时看起来像一团运动目标，必须在掩膜里排除。

第四层，告警去抖与合并。同一个相机、同一个事件类型，60 秒内只推送一次；连续 5 分钟内反复触发的事件合并成一条，标注"持续发生"。这一层主要保护使用者的注意力，别让手机被轰炸到关机。

5. 算力、带宽、存储的量化账

5.1 算力估算与盒子选型

估算是这样的逻辑：单路视频、15fps 抽帧、YOLO 中等规模模型（约 1100 万参数级别）、640×640 输入，在 INT8 量化下大约需要 0.8 到 1.2 TOPS。加上跟踪、行为分类、事件规则，按 1.8 到 2.5 TOPS 每路估算比较稳妥。

那么 16 路就是 30 到 40 TOPS 的有效需求。选边缘盒子时不能卡着这个数买，要按1.5 到 2 倍留余量，因为算法会升级、会加新功能、会偶尔跑批处理任务。所以 16 路场景建议选标称 64 TOPS 以上的设备。

这里还有个容易忽略的点：解码能力。很多盒子算力标称很漂亮，但硬解码路数只有 8 路 1080p，16 路视频根本喂不进去。采购时一定要问清楚 H.265 硬解路数，这个参数比 TOPS 更能决定能不能用。

5.2 带宽与存储的计算

码率按 1080p、H.265、25fps、中等运动场景估，单路 3 到 4Mbps，取 4Mbps 做保守计算。

单路日存储量 = 4Mbps × 86400 秒 ÷ 8 ÷ 1024 ≈ 42.2 GB/天。

32 路存 30 天 = 42.2 × 32 × 30 ≈ 40.5 TB。加上 RAID5 冗余和 20% 余量，实际配置 56 TB 左右比较合适。

上行带宽这块，边缘本地存储之后，只有事件片段和结构化数据要上传。按每路每天触发 20 次事件、每次上传 15 秒 4Mbps 片段算，单路日均上传约 150MB，32 路约 4.8GB/天，折合平均上行 0.45Mbps。峰值按 10 路同时上传算约 40Mbps，配一条 100Mbps 上行链路就够，而且完全不紧张。

5.3 一份可直接抄的配置清单

6. 可视化平台：大屏好看不算本事，闭环才算

6.1 看板分层设计

可视化最容易做成"给领导看的幻灯片"。真正有用的看板要分三层，服务三类人。

场长层看的是场区总览：今日告警数、未处置告警、各栋舍活动量热力图、异常栏位排名。这一层不要超过 6 个指标块，多了就没人看。

技术员层看的是栏位详情：单栏 24 小时活动曲线、采食区和躺卧区的时间分布、历史告警列表、事件截图和短视频。这一层要支持快速下钻，从场区点到栋舍点到栏位，三次点击内到达。

运维层看的是设备健康度：在线率、丢包率、码流异常、存储剩余、盒子温度和负载。这一层最不显眼，但它决定了系统能不能长期跑下去。

热力图这个功能值得单独说一下。把每栏的猪只活动像素密度按时间累积成一张热度图，颜色深浅直接反映"这栏猪今天爱不爱动"。这个图对饲养员的直观性远超任何数字报表，我见过的场里，饲养员用起来最顺手的就是这个。

6.2 告警分级与推送策略

告警分三级：紧急（人员违规进入、仔猪压死风险、大面积聚集）走电话或强提醒，5 分钟内必须有人响应；重要（长时间不动、采食异常）走应用内推送，30 分钟内响应；提示（设备异常、统计偏差）只进列表，日终汇总。

推送对象要按事件类型分派，不要全推给一个人。人员违规推给场长和安全负责人，猪只行为异常推给对应栋舍的饲养员和技术员。推错人的告警等于没告警。

还有一个细节：告警必须带处置按钮。已处理、误报、转人工复核，三个选项，点完之后记录处置人和处置时长。没有这个闭环，系统永远不知道自己报得准不准，也没法做后续的模型迭代。

6.3 事件处置闭环与数据留存

从告警产生到处置完成，这条链路要记录完整：触发时间、触发规则、置信度、截图/视频 URL、推送对象、响应时间、处置结果。这些数据积累三个月，就能算出来每个规则的准确率，反过来优化阈值。

数据留存策略上，我的建议是：原始视频本地存 30 天（涉及生物安全的区域存 60 天），事件片段存 1 年，结构化事件记录长期保存。事件片段的价值远高于原始视频，一年后要复盘某次异常，看的就是这些片段。

7. 上线节奏与问题排查实录

7.1 分四期推进，别想着一次到位

我见过的失败项目，八成是想三个月上线全功能。合理的节奏是这样：

第一期（3 到 4 周）：只做视频接入和实时预览，把 32 路视频稳定跑起来，网络、存储、供电全部调通。这一期不碰算法，目标是"画面不卡、录像能回放"。

第二期（4 到 6 周）：上人员检测和区域入侵。这两类目标特征明显，最容易出效果，用来建立使用方信心。

第三期（6 到 8 周）：上猪只行为检测和异常事件，同时开始收集 badcase 做迭代。这一期是最磨人的，误报会集中爆发，需要现场驻点调参。

第四期（持续）：上估重、活动量分析、多源数据关联，做数据看板和报表。

每一期结束都要做验收，验收标准写具体数字，比如"人员入侵事件召回率 ≥95%，单路日均误报 ≤3 次"。没有量化标准的验收，最后都会变成扯皮。

7.2 常见问题速查表

7.3 几条踩坑换来的经验

第一条，别在演示阶段用最好的光照和最好的角度。演示时选一个光线均匀、猪只稀疏的栏位，效果当然漂亮。上线后真实的栏舍又挤又暗，落差会让人怀疑整套系统。演示就该用最差的场景，把预期先压下来。

第二条，阈值一定要做成可配置的，而且要让场里的人自己能改。同一个"长时间不动"规则，育肥舍 4 小时合适，产房母猪 2 小时就够，断奶仔猪 1 小时就要报。写死在代码里，后期每次调整都要找开发，运维成本会失控。

第三条，给饲养员做培训时，重点讲"误报怎么标记"，而不是"系统多厉害"。标记误报这个动作，直接决定模型能不能持续优化。我见过的场里，凡是把误报标记纳入日常考核的，三个月后准确率都能提升 10 个点以上。

第四条，留一路"对照摄像头"不接入算法。这一路只录像不分析，用来在出争议时回看原始画面，验证算法判断是否可靠。这路摄像头的成本，比起扯皮的代价，几乎可以忽略。

第五条，估算类功能一定要在界面上标注误差范围。写"预估体重 118 公斤（±12 公斤）"，比写"体重 118 公斤"专业得多，也少掉很多麻烦。使用者看到误差范围，心里有数，就不会拿它去较真。

最后分享一个我在实际部署里觉得最值钱的小技巧：把每路摄像头的画面做一张"每日首帧缩略图墙"，一屏 32 宫格，按时间排列。镜头被遮挡、起雾、偏移、被猪拱歪，这些问题在缩略图墙上会一眼看出来，比任何自动检测都直观。运维人员每天早上扫一眼，能省掉大量被动排查。这套东西不复杂，但真正让它长期跑下去的，往往就是这类不起眼的运维设计。