这不是一篇讲成功的文章。
这是一篇讲"问题是如何真实存在的"的文章。
2024年的春天来得比往年急。气温波动剧烈，几乎没有过渡期。对于大多数人来说，这不过是一个穿衣麻烦的季节；但对于某一家规模化猪场的管理者来说，这个春天意味着一场无法挽回的损失。
短时间内，大量猪只相继出现应激反应。原因是多方面的——温度骤变、通风不及时、异常行为未被察觉、处置窗口期一再错过。等到问题显现在账面上的时候，损失已经超过了一百万元。
这是我们团队最初接触到这件事时，留下的最深刻的印象。
畜牧业不是一个没有技术积累的行业。围绕猪的饲养，有数十年的学术研究、工程规范和操作经验。但这些知识大多服务于"知道猪应该怎么养"，而不是"知道猪现在发生了什么"。
我们花了很长时间来理解这个区别。
一个有经验的养殖场管理者，走进猪舍的时候，确实能凭直觉感受到猪群状态。行业里称之为"老师傅的眼睛"。但一个现代化的规模猪场，猪舍数量多，管理人员有限，没有人能做到持续观察。夜间无人值守；巡检是间歇性的；异常往往在两次巡检之间发生、发展、完成。
2024年春天那次损失，事后复盘发现：异常行为在猪只出现明显症状前的数小时，已经有可以识别的迹象。如果那个时间窗口内有人在场、有人看到、有人做出判断——结果可能完全不同。
问题不是技术落后，也不是人员失职。
问题是：这件事从结构上就不可能被看到。
我们当时意识到，这里有一个真实的、工程可以解决的缺口。
团队最初接触这个领域，带着的是工程师的视角——我们习惯于把问题拆解为可量化的模块，然后用技术去逼近解决方案。但当我们面对这个具体的损失事件时，我们意识到：这不是一个等待技术填坑的地方，而是一个需要重新定义问题的地方。
我们问自己：如果猪舍里存在一套能够持续观察猪群行为的系统，能够在异常出现的早期阶段发出信号——这件事有没有可能在工程上被实现？
这个问题，驱动了后来两年的工作。
在最初的讨论阶段，我们很快意识到一个边界条件：猪场的基础设施并不是为数据系统设计的。网络不稳定，电力供应时常中断，环境里充满了灰尘、氨气、潮湿和噪声。任何想在这里长期运行的系统，都必须能够在这种条件下真实存活——不是实验室里的存活，而是按月、按年地持续工作。
这个约束，在后来决定了我们几乎所有的技术选择。
真正的问题不是损失本身，而是——我们当时甚至不知道问题发生在"哪里"。
下一篇，我们从最原始的方式开始：在进入任何工程阶段之前，我们先去学了"养猪"。