很多问题在实验室里不存在，
只在真实世界里出现。
这条路线的选择，是被现实逼出来的。
当我们放弃了"让摄像头更强"的思路之后，问题变成了：计算在哪里发生？
这不是一个抽象的架构问题，而是一个非常具体的现实问题：在一个猪场里，数据处理到底在哪台机器上完成？它如何持续运行？当网络断开的时候，系统还能工作吗？
最直觉的方案是：把摄像头数据传到云端，云端做分析，结果发回来。这是目前大多数"AI+摄像头"产品的基本架构，在很多场景下运行良好。
但猪场不是"很多场景"之一。
这五条约束，每一条单独看都可以被"技术上解决"，但放在一起，它们共同指向一个结论：在猪场里，云端不是计算基础设施的可靠主体。
边缘计算的核心思路是：把计算能力放到数据产生的地方，而不是让数据去找计算。对于猪场，这意味着：在猪场本地部署一台能够运行模型的设备，它接入摄像头网络，持续处理视频数据，在本地完成分析，必要时再把结构化结果上传。
当我们把"长期部署稳定性"作为首要约束条件时，技术选型的优先级就变了。不再是"哪个方案性能最好"，而是"哪个方案在最差的环境条件下能活得最久"。
边缘计算路线确定之后，我们对具体的硬件和软件架构进行了评估。这个过程我们不会展开讲——不是因为有什么秘密，而是因为具体的参数和选型结论对于理解"为什么这么做"并不重要。重要的是约束条件：
环境耐受性：设备必须长期工作在粉尘、氨气和温湿度剧烈波动的真实猪舍里，而不是实验室或普通工业环境。
热稳定性：猪舍夏季工况对设备的热设计提出了远高于常规办公或服务器机房的要求。
持续运行能力：系统不能依赖人工干预来维持运转，必须自主应对猪场各类运维扰动。
有效算力：在猪场可接受的部署成本内，支持持续的多路视频分析。
这些约束把选型方向大幅收窄。具体选型过程——包括我们经历的弯路——将在下一篇中讲述。
选择边缘计算不只是一个架构决策，它也是一个对"这个行业真正需要什么"的判断。
我们认为，规模化养殖行业的数字化，不会走一条需要大规模改造基础设施的路。它必须是轻量的，能够接入已有摄像头网络，在不依赖稳定网络的情况下独立运行，对场主的IT能力没有额外要求。这个判断，把"能活在真实猪场里"定义为系统的核心设计目标，而不是"在演示环境里表现出色"。
方向确定了，接下来是真正的工程阶段——我们从最入门的边缘设备开始，第一版系统跑起来了，但它并不成功。