AI weed and pest control advice听起来是农业数字化最直接的入口拍张照识别虫害输入地块信息AI 就给出防治建议。但最近看到一个案例一个农民按照 AI 给出的除草和害虫防治建议执行结果 25 英亩作物大面积受损。这个事出来之后很多人第一反应是“AI 不可信”。我的判断不一样问题不在模型本身而在整个落地流程里少了一道校验层。农业 AI 不是不能做而是不能把 AI 输出直接当成执行指令。如果不把校验、人工复核、安全限制和日志审计做在前面类似的事故一定还会发生。这篇文章不打算复述新闻细节而是想从工程和落地角度拆解AI 农事建议到底该怎么设计才不会让一个建议毁掉一整片地。1. 这个案例暴露的不是 AI 智商问题而是流程里缺了一道“校验层”1.1 AI 建议从生成到执行中间应该有几个节点很多做 AI 应用的人习惯性认为模型输出结果用户拿到结果任务就结束了。但在农业场景里从 AI 建议生成到真正执行中间至少隔着四个节点理解建议、判断适用性、确认参数、执行验证。一个典型的 AI 农事助手收到虫情照片和地块信息后可能会输出这样一段内容识别到某种叶部害虫建议在 48 小时内施药推荐用药剂量和兑水浓度建议喷洒区域。这些内容看起来是完整的。但如果缺少一个环节问题就开始了这个建议是基于哪些数据算出来的剂量有没有超过安全上限当地作物品种是否在被推荐药剂的安全范围内天气窗口是否真的适合施药农民不是农艺师看到 AI 给出了具体答案信任度会很高。他可能直接按建议操作。结果剂量偏大、品种敏感、土壤干旱、喷药时间又赶上高温作物大面积受损。所以这个案例的第一教训不是“AI 错了”而是流程里没有校验层。建议生成后至少要有人或者规则引擎去检查一遍。没有校验层AI 错一个数落到地里就是几十亩地的问题。1.2 农业决策里错误成本的延迟会让风险被低估工业场景里AI 控制参数出错机器可能马上报警产线瞬间停掉。农业不一样。作物受损不是执行当天就能看出来的可能要等 3 到 7 天才开始显现。等发现叶片发黄、生长停滞、根系受损已经错过了干预窗口。这种“延迟出错”会带来一个心理问题AI 建议执行后短时间内看起来一切正常于是第二次、第三次会更信任 AI面积也越来越大。一次小范围的试点如果没看到问题不代表没有问题可能只是问题还没长出来。在我接触过的农业数字化项目里我一般会提醒团队不要把“执行后没有立即出问题”当成成功标准。正确做法是设定观察周期小面积试点至少观察一个完整生长阶段再判断这个 AI 建议是否可靠。25 英亩不是小数目如果是一次性大面积执行一旦判断错误恢复成本很高。2. AI 农事建议的边界哪些环节可以信哪些环节不能直接执行2.1 AI 在农业里真正稳定输出的能力先说结论AI 不是不能用而是要分清它能干什么不能干什么。以现有技术成熟度来看下面这些事 AI 做得相对稳定图像识别类任务识别病斑、害虫形态、叶片颜色异常、果实成熟度。数据整理类任务汇总土壤检测报告、气象预报、历史产量数据并生成简明解读。知识检索类任务回答“某种作物常见的虫害有哪些”“某个病害用什么成分的药剂防治”这类偏通用的问题。提醒和告警类任务根据气象数据提醒近期降雨概率、风速、温度变化。这些任务的共同点是输入相对标准输出边界相对清晰。病虫害识别模型只要训练数据够准确率能做到可用水平。但要注意这里的“可用”不是 100%而是“在置信度较高时可以给农艺师作为参考”。AI 真正不稳定的是把多个来源的数据组合成一个可执行的操作方案。比如虫害识别没问题天气预测也没问题但把“病虫害种类 药剂库 剂量 天气窗口 作物品种 生育期”组合成一份喷洒方案时任何一个字段出错整个方案都可能出问题。2.2 容易翻车的四个环节我在实际项目中会重点盯四个环节因为它们最容易让 AI 建议出错。第一个是剂量计算。AI 输出的原始值可能是“每亩 80 克”但如果模型训练数据用的是公顷输出转换时漏了单位农民按“80 克每亩”执行实际浓度可能翻好几倍。这是非常典型的工程错误不是模型理解不了作物而是单位换算和字段映射错了。第二个是天气窗口。AI 可能根据一个区域的通用气象预报给出“明早 6 点到 10 点适合施药”但目标地块可能在山谷、河边小气候和区域预报差别很大。风速、露水、降雨概率都可能是局部值不能只看通用接口。第三个是作物品种和生育期。同一种作物不同品种对药剂的耐受度不一样。苗期和灌浆期的敏感度也不一样。AI 如果没有把地块的品种、播期、生长阶段字段接进来给出的剂量就可能超出安全范围。第四个是当地法规和合规要求。某些药剂在特定地区可能禁用或限用某些施药方式可能有距离水源、村庄的间隔要求。大模型训练数据未必覆盖这些地方性规则模型不知道但执行的人要负责。所以我的建议是AI 输出内容必须分级不能所有建议都一视同仁地展示成“可执行方案”。2.3 将 AI 输出分成三个级别级别典型内容是否可执行是否需要人工复核参考级病虫害识别结果、植物缺素判断、知识科普否必须结合现场检查操作级施药方案、灌溉建议、施肥建议有条件执行必须农艺师或负责人确认自动执行级直接控制无人机、自动灌溉设备、变量喷洒设备强烈不建议默认开启必须有安全锁、审批和日志很多 AI 项目失败是因为把参考级内容直接包装成操作级建议又默认用户会自己判断。真实的农业用户不一定有这个判断力所以系统必须在设计上拦住风险而不是指望用户自律。3. 落地一套 AI 农事助手我会先做“小范围闭环”3.1 最小闭环五步如果你想在农业场景里接一个 AI 农事助手不管用的是大模型 API还是自己训练的小模型我建议先跑通下面这个最小闭环数据接入把地块编号、作物类型、播种日期、最近虫情照片、天气数据接进来。模型推理AI 基于这些输入生成建议初稿。人工审单农艺师或熟悉本地情况的人检查建议修改剂量、面积、时间等字段。小地块执行先选一小块地执行面积控制在总种植面积的 5% 到 10% 以内。结果评估执行后隔天、第三天、第七天分别观察记录作物状态。这个闭环看起来简单但很多人会跳步。最常见的是跳掉“人工审单”直接让 AI 建议进入执行端。另一个常见问题是“小地块执行”没有做第一轮就直接铺开大面积作业。我一般会强调最小闭环的目的不是跑通功能而是建立一套**“AI 出错时代价可承受”**的机制。只有小地块试点才能用比较低的成本暴露问题。3.2 建议输出里的字段设计AI 输出的建议不能只是一段自然语言。如果要做工程化必须用结构化格式输出。下面是我常用的一种建议卡片格式{ advice_id: FLD20250612-001, crop: 玉米, growth_stage: 拔节期, field_id: F-08, problem_type: 叶部害虫, pest_name: 玉米螟, recommendation: { action: 叶面施药, agent_type: 高效低毒杀虫剂, dosage_kg_per_ha: 0.8, water_volume_l_per_ha: 300, application_area_ha: 2.5, weather_window: 2025-06-13 06:00-10:00, confidence: 0.76 }, status: PENDING_REVIEW, required_checks: [ 农艺师复核, 土壤墒情确认, 未来6小时风速确认 ] }这套结构里status很关键。默认应该是PENDING_REVIEW不是AUTO_EXECUTED。只要有“待审核”状态AI 建议就被强制推到人工环节而不是直接执行。还要单独给出confidence字段。但要注意置信度只能作为参考条件不能当作安全阀。AI 对病虫害识别置信度高不代表它对剂量计算、天气窗口、品种安全的综合判断也置信度高。所以不能只看置信度决定是否放行。3.3 为什么默认必须“人工确认”而不是“自动执行”有人会问如果 AI 准确率已经很高了还强行加人工确认会不会降低效率这个问题的关键是要算风险账。假设模型在建议生成这件事上的准确率是 99%1% 的出错率看起来不高。但如果一次出错影响 25 英亩作物那损失可能超过几万元甚至几十万元。而人工确认一次方案成本可能只有几分钟。用几分钟的成本去覆盖低概率但高损失的尾部风险对于农业场景来说非常值得。更重要的是人工确认不等于完全否定 AI。农艺师可以只做减量判断比如看到 AI 建议剂量偏高改低一点看到天气窗口偏紧改到第二天早上。这个过程中人的经验是在给 AI 输出兜底。如果人工确认环节只是走形式点了“同意”却不看参数那这个环节就失去了意义。真正要做的是让审核者看到 AI 建议时能快速理解“为什么这么建议”以及“哪些参数需要重点检查”。4. 用工程方式给 AI 建议加三道安全锁4.1 剂量和面积上限锁系统里必须有一套独立于 AI 模型的安全限制规则。所谓“独立”意思是即使 AI 模型本身出了问题规则引擎也能拦住风险。第一道锁是剂量上限。AI 输出的dosage_kg_per_ha必须乘以面积后和本地历史用量比较。如果超过历史最大值的 1.2 倍直接进入拒绝或人工复核流程。不需要让 AI 解释为什么超量规则直接拦截。第二道锁是单次执行面积。无论 AI 建议有多完整单次自动生成的可执行面积必须设置上限。比如默认最多 5 公顷。超过 5 公顷系统不允许直接生成执行工单必须添加额外审批节点。下面的伪配置可以做个参考safety_limits: max_dose_ratio: 1.2 max_single_exec_area_ha: 5 require_human_review: true allowed_fields: - F-01 - F-02 - F-08 allowed_crops: - 玉米 - 小麦 weather_constraints: wind_speed_max_kmh: 12 rain_probability_max: 30 temperature_min_c: 8 temperature_max_c: 30 emergency_stop: true这段配置说明的是默认情况下AI 建议在剂量、面积、地块、作物、气象条件全部满足约束后才有可能进入执行队列而且仍然需要人工复核。emergency_stop表示系统提供紧急停止开关执行过程中发现问题可以随时中断。4.2 地块和作物白名单不是所有地块都适合用 AI 建议做自动化决策。我建议每个 AI 农事系统都维护一份白名单。白名单里包含已核实边界的地块编号已录入的作物类型和品种最近一次的土壤检测时间该地块过去 3 年的种植记录。只有白名单里的地块AI 建议才能进入操作级流程。新地块上线时先人工录入必要信息再用小面积试运行验证一轮。这个做法看起来保守但能避免很多因为地块信息缺失导致的误判。白名单很像访问控制里的权限列表。AI 模型就像一个大模型用户它有权限生成建议但不应该有权限对任意地块直接执行。白名单就是给模型权限划定边界。4.3 时间窗口和异常天气锁施药、灌溉、施肥都和时间高度相关。AI 建议里写的“未来 48 小时内适合施药”不能直接作为执行依据。在实际系统里我会接入实时气象接口检查执行时段的风速、温度、降雨概率。风速超过 12 公里/小时不适合喷洒作业未来 6 小时降雨概率超过 30%需要推迟温度低于 8 度或高于 30 度需要特别小心。这些判断可以写死在规则引擎里不依赖大模型。因为气象数据是动态变化的模型训练时不可能覆盖所有实时情况。规则引擎直接查实时数据比让模型去推理更可靠。如果 AI 建议中的时间窗口和气象数据冲突系统应该自动标记为“需要人工调整窗口”而不是直接按 AI 建议执行。宁可让作业推迟一天也不要冒险在错误窗口执行。4.4 自动执行和人工确认的边界很多 AI Agent 项目会做“自动执行”听起来很酷但在农业里非常危险。我的建议是第一版系统不要做任何自动执行功能全部走人工确认。等系统稳定运行一个完整种植季之后再考虑在小面积地块、单一任务类型上开放半自动执行。半自动执行也不是完全没有人工。可以做成这样AI 建议直接填入执行工单工单在经过规则引擎校验后推送给指定的农艺师农艺师只需要修改不合适的字段或直接确认不在规定时间内确认的工单自动取消。这种方式既保留了效率也没有完全去掉人的判断。它不是一个人工屏障而是最后一道护栏。5. 一次 AI 农业事故的排查顺序先别急着骂模型5.1 先看输入数据是否干净遇到“AI 建议导致作物受损”这类事故排查顺序很重要。很多人第一反应是怪模型但实际操作中大量问题出在输入数据和参数转换上。第一步检查输入数据虫情照片是什么时候拍的对焦是否清晰是否拍到了非目标害虫地块面积是哪个来源手绘边界、卫星边界、还是实测边界土壤数据是什么时候检测的是否已经过期气象数据覆盖的位置是否和目标地块一致输入数据如果有一项是脏的AI 再准也白搭。比如照片里同时有虫害和机械损伤模型可能误判严重度面积字段给了错误数值剂量乘出来就全错了。5.2 再看模型推理是否越界输入数据没问题之后再检查 AI 模型本身。要看三个点模型版本是什么时候发布的该版本是否经过本地区数据验证输入特征是否在模型训练范围内比如训练时只用过玉米、小麦结果部署后却输入了高粱、大豆。置信度是多少如果置信度低于阈值系统是否把它拦截下来还要特别关注一个问题如果用的是大语言模型 APIAI 在生成建议时是否有“幻觉”风险大模型擅长生成通顺文本但它可能编造一个不存在的药剂配方或者把相似作物的防治方案张冠李戴。这也是为什么我坚持不让大模型直接输出最终方案。大模型可以参与信息整理、方案解释、对话问答但最终的操作级建议必须由专门的规则引擎或农艺数据库来约束和校验。5.3 然后查单位和面积换算农业场景里单位换算是隐藏事故重灾区。常见坑有亩和公顷混用1 公顷等于 15 亩如果系统内部用公顷展示给用户时用亩换算错一次就是 15 倍误差。克和千克混用药剂剂量可能用克/亩也可能用克/公顷展示时如果不统一执行人容易配错浓度。平方米和亩混用地块面积如果来自遥感影像常以平方米计算但农机作业常用亩。除法多写一个零或少写一个零结果完全不同。浓度和纯度混用推荐剂量是基于有效成分而实际商品药有不同的含量和剂型换算时要把有效成分含量算进去。排查时不要只看 AI 输出的数字要拿“原始输入 - 推荐剂量 - 兑水浓度 - 实际用量”全链路核对一遍。很多时候问题不是 AI 不能识别虫害而是中间某一步换算错了。5.4 最后查执行设备AI 建议就算完全正确执行端也可能出问题。执行设备需要检查喷洒设备的流量标定是否准确是否做过定期校准无人机或喷雾机的喷幅设置是否和地块宽度匹配GPS 边界是否偏了导致同一个区域重复喷洒执行人员是否按照 AI 建议的兑水浓度配药设备在作业过程中是否有部分喷头堵塞造成局部浓度异常。这一层的排查更像农机管理问题。但它经常被算到 AI 头上。所以事故复盘时一定要把数据、模型、规则、人工、设备五条线都查完才能定位真正原因。5.5 排查顺序表排查环节优先检查项常见表现输入数据照片、土壤、气象、面积来源识别错误、剂量算错模型推理版本、特征范围、置信度建议越界、生成幻觉规则校验安全锁、白名单、阈值拦截失效、放行异常单位换算亩/公顷、克/千克、有效成分剂量差 10 倍以上人工复核审核记录、修改内容走形式、未修改异常执行设备流量、喷幅、GPS、配药重复施药、局部过重如果每个环节都有日志排查会非常快。如果没有任何日志那就只能靠猜了。6. 从工程实践看AI 建议的可观测性比初始准确率更早要做6.1 记录每一步决策日志我始终认为AI 农业项目最应该先建设的能力不是模型准确率而是可观测性。给农民一个 AI 建议很容易但要回答“这个建议为什么这么出”“当时输入了什么”“谁确认的”就很考验系统设计。建议系统的每一次推理都应该生成一份决策日志包含输入数据快照照片、传感器数据、气象数据模型信息模型版本、推理时间、置信度提示词或特征输入如果用了大模型要记录 prompt 和 raw response规则引擎判断结果命中了哪些安全规则放行还是拦截人工审核记录谁看的改了哪些字段确认时间执行记录设备编号、作业时间、实际作业面积。有了这些日志25 英亩作物受损的事故就能被拆解成具体原因究竟是模型识别错了还是面积换算错了还是人工审核没注意还是设备重复喷洒。日志不用很花哨但格式要统一、时间要对齐、关键字段不能缺失。我一般建议把日志存成 JSON Lines 格式每条决策一条记录方便事后分析。下面是一个简化示例# 伪代码AI 建议审核日志 { event_type: ai_advice_created, time: 2025-06-12T06:30:00Z, advice_id: FLD20250612-001, input: { field_id: F-08, crop: corn, pest_photo: s3://bucket/field_F08/20250612_0540.jpg, weather: { wind_kmh: 6, rain_prob: 10 } }, model: { name: crop-advisor-v2, version: 2.3.1, confidence: 0.76 }, rule_engine: { passed: true, risk_flags: [area_above_5ha_require_review] }, human_review: { reviewer: agronomist_01, action: approved_with_changes, modifications: { dosage_kg_per_ha: 0.8 - 0.6 } } }这个日志一旦完整问题定位只是数据检索的事。6.2 监控数据漂移和模型退化农业场景里有很强的季节性。春季病虫害和秋季病虫害差别大不同年份气候差异也大。一个模型去年效果好今年不一定好。所以必须做持续监控。我常用几个指标建议驳回率同一个农艺师或农户连续拒绝 AI 建议的比例升高说明模型输出可能不符合本地情况。人工修改率如果审核者每次都要改剂量或时间说明建议不够准。执行后异常比例执行 AI 建议后作物状态异常的比例升高要立刻暂停并排查。输入数据分布变化照片拍摄时间、地块大小、天气条件的分布发生变化都可能影响模型。设置告警时不要只看日均值。我一般会看滑动窗口比如最近 7 天内的建议数据。连续 3 天某项指标异常就要触发人工评估。不要等一个种植季结束再复盘那就晚了。6.3 用离线评估集持续回归除了在线监控还要维护一份离线评估集。评估集里应该包含历史虫害照片和人工标注结果AI 建议正确、但人工修改后更合理的样本曾经导致事故或差点导致事故的样本当前作物季的典型场景样本。每次更新模型版本都要先跑一遍离线评估集。只跑几条简单样例远远不够至少要用几十到上百条覆盖不同场景的样本回归一遍。否则很容易出现“换新模型后常见问题改善但之前没见过的边界问题突然恶化”。离线评估集不是一次性建的要持续维护。每季度根据新数据做一次补充把真实遇到的错误和纠偏案例加进去。6.4 日志和事故事后复盘当“AI 建议导致 25 英亩受损”这类事件发生时正确的动作不是马上删掉模型而是立即暂停相关功能停止继续执行拉出全部决策日志还原事件链条找出第一个异常节点修复规则或模型用离线评估集回归验证重新小面积试点再逐步放开。这套流程和软件开发里面的故障复盘很像。AI Agent 项目尤其要这样做。因为你面对的不只是一个模型而是一个“模型 工具 数据 人”的完整系统。任何一个部分出错责任都不该全部算在模型头上。7. 新手团队落地 AI 农业建议的保守启动方案7.1 三个先不要做什么如果你现在刚开始做农业 AI 项目我的建议很明确有的事情不要急着做。第一个不要不要把大模型 API 的输出直接接到农机控制端。哪怕 API 返回的描述非常完整也不要直接生成作业指令。先让它输出“建议卡”后续再加控制系统。第二个不要不要在所有地块同时推广。先选一块边界清晰、面积小、作物单一的试验地块跑完一个完整流程再说。别一上来就覆盖几十块地那样就算出了问题排查成本也会高到让人崩溃。第三个不要不要只信模型的置信度。置信度高不一定代表安全。尤其当 AI 输出的字段很多时某个字段的小误差可能带来很大损失。要单独设置规则校验每个关键字段。7.2 分阶段灰度策略我比较推荐四阶段推进。第一阶段AI 只做信息整理和初稿建议。它把病虫害识别结果、天气信息、历史用药记录整理成报告真正的决策由人来做。这个阶段风险很低主要是验证数据链路能不能跑通。第二阶段AI 输出结构化建议卡但必须经过农艺师审核严格限制在 5 公顷以内的小地块执行。这个阶段重点观察审核效率、人工修改率和执行效果。第三阶段在小地块运行稳定后逐步扩展到更多地块。但涉及施药、施肥等操作时全部保留人工确认并设置安全上限。系统的自动执行开关继续保持关闭状态。第四阶段只有当天梯队的监控能力、日志审计能力、应急开关都完备之后才考虑对部分低风险场景开放半自动执行。比如常规灌溉、非药剂的叶面肥喷洒可以走自动填充 人工确认。每个阶段至少跑一个完整生长周期再决定是否进入下一阶段。农业不像互联网可以一周发十几个版本节奏要慢但每一步都要稳。7.3 人和 AI 的分工底线最后说说人机分工。AI 在农业里最适合干的是“快活”快速识别、快速整理、快速生成初稿、快速判断风险。人要干的是“准活”根据本地经验判断是否适用、调整参数、在边缘场景做决定。AI 可以告诉农户“这块地有叶部害虫建议在早晨施药推荐低毒药剂”。但 AI 不一定知道这个品种正好处于开花期对某种药剂特别敏感也不一定知道东边那块地土壤偏砂质药剂易淋溶。这些本地化的知识是数据模型很难完全学到的。所以分工底线是AI 只做建议不做最终决策。涉及用量、面积、作物安全、合规要求时必须有人守着。这样即使 AI 出错也只是给了一个参考不会直接造成大面积损失。我看到这个案例的时候第一反应不是“AI 不能用于农业”而是“农业 AI 该从能跑通走向能兜底”。如果你现在刚好在搭这类系统我建议把最基础的三件事先做好建议卡结构化、安全锁规则、决策日志审计。这三件事不复杂但能在关键时刻拦住 25 英亩的损失。