项目讨论到土壤墒情时，很容易先盯着一张曲线，再顺手提出“低于多少就提醒”。页面这样设计并不难，真正难的是：这个数来自哪块田、哪个深度，传感器当时是否正常，前面有没有浇水或下雨，当前作物又处在什么生育阶段。

这些问题没说清，一条低值既可能是缺水，也可能是探头松动、通信中断后补传，甚至只是局部土层短时变化。告警做得越早、发得越勤，现场人员越容易把它当成背景消息。

红数科技在这类农业物联网项目里更倾向于把首期范围定成两件并行的事：一边把墒情数据做可信，一边把会改变墒情的现场作业记下来。阈值告警不是不做，而是先小范围试运行，等数据和责任人都稳定后再正式启用。

土壤墒情监测与灌溉管理

先把“这个数是什么”说清楚

墒情页面不能只显示一个百分比。至少要保留地块、测点、传感器、土层深度、采集时间、原始值、换算值、单位、数据来源和设备状态。体积含水率、质量含水率、土壤相对含水量不是同一个指标，页面和接口里不能都写成一个含糊的“湿度”。

地块资料也不能只留一个名称。种植作物、播种或定植时间、当前生育阶段、土壤质地、灌溉方式和测点位置，都会影响同一个数该怎样理解。一个固定阈值复制到所有地块，表面上配置省事，到了生产现场往往最不省事。

土壤传感器分层测量

首期还要把数据质量单独做出来。设备离线、数据超出量程、数值长时间不变、短时间突然跳变、缺测和补传，应当与真实的墒情偏低分开显示。看不见质量状态，用户只能对着曲线猜；更糟的是，系统可能把“没有数据”误报成“土壤干旱”。

自动监测也不能替代田间核对。系统上线初期，应安排人工取样或便携设备比测，记录测点周围的土壤质地、埋设情况和地表条件。灌溉或降雨以后，再看不同深度的曲线是否按合理顺序变化。曲线与现场长期对不上时，先查安装、标定和数据换算，不急着调告警阈值。

这部分并非额外的“高级功能”。2026年5月1日起实施的农业行业标准《农田土壤墒情监测技术规范》已经更新为 NY/T 1782-2025，替代2009版；现行的 NY/T 3180-2018 则专门规范土壤墒情监测数据采集。2025年发布的甘肃地方标准 DB62/T 5151-2025，也把站点布设、设备、参数采集、运维校验、墒情等级划分以及数据传输共享放在同一套技术要求里。对产品来说，这意味着测点资料、设备状态、校验和数据口径都属于底座，不是后期有空再补的备注。

作业记录为什么不能等到第二期

有些方案把作业记录理解成给种植人员增加的一张填报表，于是准备等监测和告警上线后再做。这个顺序会留下一个很现实的空白：曲线发生变化时，系统不知道现场做过什么。

一条灌溉记录至少应说明哪块地、哪个灌溉分区、何时开始和结束、用了什么设备、实际运行多久或用了多少水、由谁执行。施肥、排水、覆膜、松土等会影响水分变化或传感器读数的作业，也应按项目需要记录。遇到设备故障、临时停水、作业未完成，保留实际结果，不能仍按计划任务记成完成。

首期不必先做复杂的农事管理系统。手机端能快速选地块、选作业类型、填实际时间和结果，必要时附一张现场照片，已经能解决大部分追溯问题。水泵、阀门或灌溉控制器有可靠接口时，可以自动带入启停时间和运行数据，再由现场人员确认异常。自动数据和人工补录要标明来源，不能混成一条看似精确、实际没人说得清的记录。

作业记录一旦和墒情曲线放在同一条时间线上，很多判断才有依据。灌溉后浅层数值上升、随后向根区变化，至少说明水分变化与这次作业在时间上能够对应；若设备显示已经灌溉，多个土层却没有合理响应，就该查阀门、流量、传感器或作业记录，而不是继续把阈值调低。

告警要晚一步，但不能只做一个开关

数据跑稳之后，可以从少量关键地块和关键生育阶段开始试告警。阈值应按作物、生育阶段、土壤条件、土层和灌溉方式分别确认。已有农艺规程、用水定额或当地农技部门建议的，优先采用这些依据；没有现成数值时，应由种植和农技人员结合田间测定确定，软件服务方不能替现场随手给出一个通用百分比。

真正可用的规则通常不止“低于X就告警”。还需要连续低于阈值多长时间、恢复到什么值才解除、一天内是否重复通知、灌溉后是否暂缓判断，以及多深层数据之间出现什么关系才值得提醒。设置触发值与恢复值之间的回差，可以避免数值在临界点上下波动时反复开关告警。

墒情告警处置

设备离线和墒情偏低也应分成两类事件。前者由运维人员查供电、通信和传感器，后者由种植或灌溉负责人核实地块情况。系统如果只会发通知、不知道发给谁，现场最后仍要靠人四处转消息。

一条正式告警需要留下触发时间、触发规则、当时数值和设备状态。之后是谁接收、有没有到现场确认、采取了什么措施、何时复核，也要接着记下去。数值恢复正常可以作为参考，不能默认等于“问题已经处理”。例如传感器断电后重新上线，读数恢复了，并不代表地块真的完成了灌溉。

告警第一版也不宜直接联动自动灌溉。先让试运行覆盖当地关键生育阶段和几种典型灌溉场景，确认传感器稳定、规则适用于这块田、异常有人复核，控制设备也具备权限和安全保护，再评估自动执行。土壤墒情只是灌溉判断的一部分，近期降雨、天气预报、水源、作物阶段和现场作业同样可能改变决定。

首期做到什么程度才算能用

项目验收时，不能只检查页面有没有曲线、按钮能不能点击。更有用的办法，是拿一块真实地、一台真实设备和一次真实灌溉来走完整过程。

开始作业前，系统能看到各土层当前数值及设备是否在线；灌溉发生后，作业时间、灌溉分区、实际结果能够留下来，曲线变化可以与这条记录对照；若数值持续越过已经确认的阈值，系统只生成一条可追踪的告警，明确交给责任人；处理后还能回看当时发生了什么。

田间灌溉作业记录

还应专门测几种不顺利的情况：传感器离线时会不会被误判为缺水，短时跳值会不会连续刷屏，网络恢复后的补传数据会不会触发过期告警，作业取消后会不会仍显示已完成，阈值修改后旧告警能不能保留当时采用的规则版本。

这些情况走得通，首期就有了继续扩展的基础。接下来再增加分区对比、墒情等级图、用水统计、天气联动、灌溉建议和自动控制，数据才不会越算越乱。

所以，三类功能的优先级不能简单写成“一、墒情；二、告警；三、记录”。更准确的做法是：首期先上线墒情采集、数据质量和基础作业记录；选少量地块试跑阈值，但默认保留人工核实；等规则、人员和处置过程都稳定后，再把告警纳入正式生产。作业记录从第一天就要有，因为以后每一次调阈值、查异常和评估灌溉效果，都要回到这些记录里找依据。

资料依据