这是我们第一次真正走向技术实现。
也是第一次，判断错了。
2024年，在完成对养猪行业的初步认知积累之后，团队开始进入技术选型阶段。这是从"理解问题"到"如何解决问题"的跨越，也是第一次真正面对工程层面的约束和取舍。
最初的思路很直觉：猪舍里已经有摄像头，或者可以安装摄像头。把摄像头的视频数据送入识别模型，让模型判断猪只行为是否异常。这个路径，在逻辑上完全说得通。
最初的设想是：在猪舍的关键位置安装固定摄像头，通过对画面的持续分析来识别异常行为。这套方案的吸引力在于它的简洁性——硬件成本低，逻辑链条短，技术上不存在明显障碍。
但当我们把这个方案放到真实猪舍环境里去想象时，问题开始出现。
猪舍的空间结构复杂，单个固定摄像头的视野有限，大型猪舍存在大量遮挡死角。猪群本身是动态分布的，异常个体不一定出现在摄像头的最佳视角范围内。更关键的是：真实猪场的光照条件变化剧烈——从正午的强直射光，到夜间的几乎全黑——这对识别模型的稳定性要求极高。
我们发现：在实验室构建的测试环境里，识别准确率看起来不错。
但当我们认真模拟真实猪舍的光线、角度和遮挡条件，数字就开始变得难看。
问题不是模型不够好，而是我们对"真实环境"的理解还停留在图片里。
既然固定摄像头视野有限，一个自然的改进思路是：让摄像头动起来。滑轨方案可以让摄像头沿着猪舍纵向移动，覆盖更大范围，理论上可以弥补固定视野的死角问题。
这个方案在纸面上很合理。但它引入了一个新的复杂性：运动的摄像头增加了机械维护需求；在氨气浓度高、粉尘多的猪舍环境里，轨道和驱动机构的寿命是一个真实的工程挑战；此外，滑轨覆盖的是线性路径，而猪群问题往往是局部聚集或分散的面积性现象——移动摄像头在巡检到某个位置时，可能正好错过了另一端刚刚出现的异常。
这两个方案的失败，促使我们做了一次重要的认知调整。
我们重新问了自己一个问题：猪场里已经有摄像头了，问题是什么？问题是：这些摄像头产生的数据，没有人能持续处理。不是没有算法，而是这些算法需要运行在某个地方，以某种架构持续工作，而不是偶尔被调用一次。
更好的摄像头 + 更准的识别 = 解决方案
问题在于感知端——只要能"看清楚"，问题就解决了。
利用现有摄像头基础设施 + 边缘计算持续运行 = 可行路径
问题在于计算端——"持续处理"比"识别精度"更关键。
这个判断的转变，把整个技术路线从"如何让摄像头更强"转向了"如何让现有摄像头的数据被持续处理"。这直接导向了边缘计算方案——在猪场本地部署一套能够长期运行、自主处理数据的系统，而不是依赖云端或间歇性的计算资源。
整个选型过程中，最有价值的不是找到了"正确答案"。
而是把"错误假设"暴露出来了。
每一次方案被否定，都让我们对问题的真实结构理解得更清楚一点。
问题并不在摄像头，也不在识别精度。真正的核心是：系统必须能在真实猪场环境下持续运行。
下一篇，我们进入边缘计算选型——这是整个项目最核心也最漫长的工程阶段的起点。