去年夏天出差一周回家推开门先看见阳台那几盆番茄叶子卷成一条一条土面裂得能塞进手指。那会儿我就下了决心做一个能自己判断该不该浇水的ESP32 智能花园自动灌溉系统。真正动手才发现难的不是水泵接个继电器这种电工活难的是把需求拆清楚、把代码写健壮。后来我换了个思路——把需求整理成结构化描述丢给AI 生成代码的工具我用的是快马平台那套对话式生成流程让它先吐出一个完整项目骨架我再逐段改造。这套流程跑通之后我从零到能稳定运行的整机只花了两个周末。下面这份内容是我把这套AI 生成 人工改造的完整链路掰开揉碎写下来的。它适合三类人看手上有一块 ESP32 开发板、想给阳台/小院做自动浇水的动手党想学怎么把零散需求写成高质量提示词、让 AI 吐出可编译代码的开发者以及已经跑通 Demo、但系统一到夏天就重启、读数乱飘、水泵时不时自己启动的踩坑选手。我会把每一步为什么这么设计讲清楚也会把那些文档里不会写、只有真跑过一个完整夏天才会遇到的坑原原本本摊开。1. 动手之前先把硬件清单钉死别指望 AI 帮你选型1.1 灌溉系统在物理上到底由哪几个环节组成很多人拿到开发板第一反应是打开平台开始让 AI 生成代码这个顺序其实是反的。AI 擅长的是把你已经想清楚的结构翻译成代码它不擅长替你做物理世界的取舍。灌溉系统在物理层面拆开其实就四个环节感知土壤湿度多少、判断现在该不该浇、执行水泵转多久、供电谁给水泵和主控供电。这四件事里只有判断是纯软件逻辑其余三个都是硬件决定软件。所以我在提示词里最先写的不是帮我写一个自动灌溉程序而是先把硬件拓扑描述清楚一颗 ESP32 主控一路模拟输入接电容式土壤湿度探头一路数字输出经驱动电路控制直流隔膜泵供电是 12V 适配器给水泵、经降压模块给 ESP32。把这段写进去之后AI 生成的代码里 GPIO 分配、ADC 读取方式、继电器控制逻辑才对得上不会给你生成一个用 PWM 调速控制水泵但硬件上根本没接调速模块的代码。这里有个容易被忽略的点湿度传感器接在哪个引脚不是随便挑的。ESP32 有两组 ADCADC2 在 WiFi 开启时会被射频模块占用读出来全是无效值。所以湿度探头必须接 ADC1 的引脚GPIO32 到 GPIO39 这一段。这一条我在第一版提示词里没写AI 默认给了我 GPIO4编译通过、烧录成功、串口打印出来的湿度永远是一个不动的数字我盯着屏幕看了半小时才想起来 ADC2 的坑。1.2 电容式探头和电阻式探头差的不是价格而是寿命新手最容易踩的坑就是买了那种几块钱的电阻式叉形裸露电极湿度探头。它便宜、读数直观但它工作在直流偏置下两块电极插在潮湿土壤里相当于一个电解池阳极会持续被腐蚀。我第一版用的就是这种装进花盆二十天电极表面一层绿色氧化物读数从干了 20%漂到干了 60%系统开始疯狂浇水把一盆薄荷浇死了。换成电容式探头之后情况完全不一样。电容式探头本质是一块覆铜板当极板中间是阻焊层土壤含水量改变介电常数从而改变电容值前端电路把它转成 0 到 3V 的模拟电压。它没有裸露金属和土壤直接接触不存在电解腐蚀问题长期稳定性好得多。代价是它对供电电压比较敏感最好用 3.3V 单独给它供别和继电器、水泵共用一路纹波很大的 5V。还有一点必须实测不同批次的电容式探头输出极性可能是反的。有的模块土越湿电压越高有的越湿电压越低。我买的第二批和第一批就是反的直接套用第一批的映射公式系统逻辑整个颠倒——土越干越不浇水。所以代码里我把干点电压和湿点电压做成了两个常数第一次上电必须做一次标定这个后面细说。1.3 水泵绝对不能让 GPIO 直接驱动驱动电路的三个关键件ESP32 的 GPIO 最大输出电流大概 40mA 量级而一个 12V 微型隔膜泵启动瞬间的电流可以到 1A 以上稳态也有三四百毫安。直接接上去轻则带不动重则把 IO 口烧掉。中间必须有一级驱动。常见方案有两个继电器模块和 MOSFET 低边开关。我两个都试过最后选了 MOSFET。原因很实际——机械继电器在吸合和断开的瞬间线圈会产生反向电动势那一下的干扰足以让旁边的 ESP32 抖一下甚至复位。我早期用继电器时每次水泵启动串口就打印一串乱码然后重启折腾了很久才定位到是继电器线圈没加续流二极管。如果你手头只有继电器模块务必确认它是带光耦隔离和续流二极管的成品模块而且控制信号最好经一级三极管或光耦别让 ESP32 的 IO 直接吃线圈的反峰。我最终的驱动电路是这样GPIO26 输出高电平经 1k 电阻到 N 沟道 MOSFET 的栅极栅极对地并一个 10k 下拉电阻这个下拉极其重要它保证 ESP32 复位、深睡眠或程序跑飞时MOSFET 栅极被拉到低电平水泵不会自己启动MOSFET 源极接地漏极接水泵负极水泵正极接 12V同时在泵两端反并联一只肖特基续流二极管。外加在 12V 输入端并一个 1000uF 电解电容吸收水泵启动瞬间的电压跌落。那个 10k 下拉电阻是我付出了半个阳台被淹的代价换来的。早期版本没有它ESP32 进入深睡眠后 GPIO 处于高阻态MOSFET 栅极悬空被环境噪声耦合出电压水泵就那么不紧不慢地转了二十分钟等我发现时托盘里的水已经漫到地砖上了。2. 提示词怎么组织AI 才会吐出能直接烧录的项目骨架2.1 一次把约束说全比来回追问十次有效我用快马平台生成代码的第一个版本提示词就一句话用 ESP32 写一个自动浇水的程序。它给我的代码能编译但完全不能用引脚是随机的、没有 WiFi、主循环里delay(60000)阻塞了六十分钟、没有任何异常保护。这不是 AI 不行是我给的信息量不够它做决策。后来我改成一次把四类信息写全效果立刻不一样第一类是硬件清单主控型号、每个外设接在哪个 GPIO、传感器类型模拟量还是数字量、驱动方式高电平有效还是低电平有效。这一块写得越死越好别写接一个湿度传感器要写接一个电容式模拟湿度传感器输出 0-3V接 GPIO32。第二类是运行约束采样周期多少秒、单次浇水最长多少分钟、两次浇水最小间隔多少小时、阈值多少。这些参数决定了代码里所有的定时逻辑。第三类是联网需求要不要上报、上报到哪里、断网了怎么办、配置能不能远程改。第四类是工程约束用 Arduino 框架还是 ESP-IDF、要不要用 FreeRTOS 多任务、电源是不是电池供电决定要不要深睡眠、代码要拆成几个文件。我把这四类写成一段结构化的中文描述丢进去生成的代码质量提升非常明显——它主动给我加了Preferences做配置持久化还加了看门狗。这些我没提但因为我写了要求长期无人值守运行它把这些当成隐含需求补上了。2.2 三版提示词的生成结果对比差在哪我把三版提示词的实际产出列个表这个对比比我讲一百句提示词要写详细都有用版本提示词要点生成结果主要问题第一版一句话ESP32 自动浇水单文件delay()阻塞主循环无状态机、无保护、引脚随机第二版补了引脚表和阈值参数单文件带阈值判断仍阻塞、无滞回、无最长运行保护第三版四类约束全给指明非阻塞多文件状态机 配置持久化 看门狗需人工替换传感器校准值第二版到第三版之间的差别其实就三个字非阻塞。我在提示词里明确写了主循环不得使用大于 100ms 的 delay所有定时基于 millis() 时间戳生成的代码才从浇完水睡一小时变成每秒轮询、状态机推进。这两种写法的差别在实际使用中是致命的——阻塞版本在浇水的那几分钟里完全不响应任何输入你想临时手动停泵都做不到只能拔电源。2.3 让 AI 输出可维护的骨架而不是一坨 loop 函数第三版生成的结果我做了两处关键改造。第一处是把loop()里的逻辑抽成一个显式的状态机。AI 原始版本是用布尔变量isPumping加一堆 if 拼出来的能跑但没法扩展。我改成三个状态IDLE空闲监测、WATERING浇水中、COOLDOWN间隔冷却每个状态只做自己该做的事状态切换有明确条件。第二处是我手动把配置参数从代码里挪出来放进config.h里集中管理同时在 NVS 里存一份可运行时修改的副本。这样做的好处是我后来想调阈值不用重新烧录固件用手机连上就知道当前值改完写回 NVS 立即生效。这个改造思路我也会建议你写进提示词让 AI 一开始就按常量默认值 NVS 覆盖的双层结构生成省得后面返工。3. 拿到代码先别急着烧逐段读懂 ADC 采样与判断逻辑3.1 湿度读数为什么要滤波和标定两次校准的具体做法AI 生成的原始采样函数大概是这样analogRead(PIN_SOIL)读一次直接map()成百分比。这个写法有两个问题。一是 ESP32 的 ADC 本身噪声不小单次采样跳动能有几十个 LSB映射成百分比可能上下抖 5%。二是map()用的是线性假设而电容式探头的电压-含水量曲线在中段比较线性、两端明显弯曲直接线性映射会导致干区和湿区判断都不准。我的改法是两点滤波用多次采样取中位数再平均标定用两点法。滤波部分我采 15 次间隔 5ms先排序取中间 7 个求平均这样能同时压掉随机噪声和偶发的脉冲干扰。标定部分我在探头完全埋进干燥的盆土放置 24 小时时记下电压V_DRY在探头插进一杯清水时记下V_WET然后把这两个值写死成常数。这里有个细节ESP32 Arduino 核心提供了analogReadMilliVolts()它内部带出厂校准读出来直接是毫伏比裸analogRead的 0-4095 准得多也不用自己算衰减档位。我一开始用裸 ADC 值换一块板子读数整体偏移折腾半天换成毫伏读数之后两块板子之间的一致性好了很多。标定还有一个隐藏坑不要把探头插在水里当100% 湿来标定。清水里的介电常数和饱和含水土壤并不相同用水标出来的湿点电压会偏导致实际土壤明明已经很湿了系统还认为没到停止阈值一直浇。我的做法是用一盆浇透水、静置两小时、盆底不再滴水的土来标湿点这样更接近真实饱和状态。3.2 阈值判断里的滞回不加就是灾难假设你把启动阈值设成 35%停止阈值也设成 35%会发生什么湿度掉到 34.9% 的时候水泵启动浇了几秒钟湿度升到 35.1%水泵停再过十几秒土壤水分扩散均匀读数又掉回 34.8%水泵又启动。如此反复一天之内水泵启停上百次不光吵泵的寿命也扛不住。解决办法就是滞回启动和停止用两个不同的阈值中间留一个死区。我设的是湿度低于 32% 启动浇到 55% 停。中间这 23% 的区间里系统什么都不做。这个死区宽度不是随便定的取决于你的盆大小和土壤类型——大盆水分扩散慢死区可以小一点小盆浇水后湿度上升快死区要给足否则浇过头。除了阈值滞回我还加了一个连续确认机制只有当连续 5 次采样每次间隔 1 分钟都低于启动阈值才认为真的该浇水了。这是为了防止一次偶发的异常读数比如探头被挪动、接触不良触发误浇。这个技巧很好用我已经靠它挡掉过好几次莫名其妙的误启动。3.3 水泵的三重保护超时、间隔、干转这是我最看重的部分也是 AI 第一版完全没给的东西。水泵如果失控持续运转后果不是浪费水是水漫金山——水管脱落、花盆溢出、托盘漫出来。所以我给水泵加了三重锁。第一重是单次最长运行时间。我在常量里写死MAX_PUMP_MS 5 * 60 * 1000也就是五分钟。不管湿度读数怎么说只要泵连续转了五分钟强制停机并进入故障态同时把状态上报出去。这个值按你的泵流量和盆大小调我的 3L/min 小泵配 30cm 花盆两分钟足够了设五分钟是留了很大余量。第二重是两次浇水的最小间隔。我设的是 30 分钟代码里记lastPumpStopMs任何一次启动前先检查距离上次停机是否超过这个间隔。这一条主要是防着探头位置不当导致读数一直低这种硬件层面的持续误判。第三重是干转保护。严格来说真正的干转保护需要加流量计或者电流检测但那成本上去了。我用的是一种软件近似如果一次浇水跑满了两分钟但湿度读数几乎没变化上升小于 3%就判定为异常可能是水箱空了、管路堵了、探头掉了把泵停掉并进入告警。这三重锁写成代码之后运行一整个夏天再没有出现过意外溢水。我个人觉得灌溉类项目里防止它做错事的优先级远高于让它做得更聪明。4. 联网、断网与掉电恢复无人值守系统的真实考题4.1 WiFi 和 MQTT 的健壮写法别在 loop 里死等AI 生成的联网代码最常见的毛病是在loop()里写while (WiFi.status() ! WL_CONNECTED) { delay(500); }。这段代码在路由器重启、信号短暂中断的时候会把整个主循环卡死水泵控制逻辑全部停摆。更糟的是如果用的是delay()看门狗可能直接触发复位。我的写法是全非阻塞每轮循环检查一次连接状态断开就记录一个时间戳尝试重连但重连动作本身不阻塞用WiFi.begin()之后直接返回下一轮再看状态。这样即使网络断了十分钟灌溉逻辑照常运行只是数据上报暂停。MQTT 也是同样的道理。我用的是带重连节流的版本每次mqtt.loop()之后检查连接断了就每 5 秒尝试一次重连重连成功立刻发一条上线消息和当前状态。这里有个小心思重连间隔不能太短否则连不上时会疯狂刷日志、占满 CPU反过来影响采样。4.2 断网时系统怎么活本地优先的设计原则我一开始的设计是云端判断——ESP32 把湿度上报服务器算完下发指令。这个方案我很快就放弃了。原因很朴素我家阳台的路由器一个夏天重启了七八次每次重启期间如果正好该浇水那这盆花就只能干等着。改成本地优先之后一切顺畅所有判断逻辑都在 ESP32 本地跑云端只做两件事——接收数据做记录和可视化以及下发临时覆盖指令比如我在外面看到要下雨手动下发一个暂停 24 小时。断网时本地逻辑完全不受影响网络恢复后补发缓存的数据。为了实现这一点我在代码里加了一个小的环形缓冲区存最近 50 条状态记录时间戳、湿度、动作发不出去就先存在内存里连上之后批量补发。50 条大概够撑几个小时再多就得考虑写 flash 了但我评估了一下没必要——真断网一整天那些数据意义也不大了。4.3 配置持久化与 OTA不用每次搬着笔记本去阳台调阈值这件事如果你每次都要拔板子、插 USB、打开电脑、编译、烧录那这个系统你调三次就不想动了。所以配置持久化是刚需。我用的是 ESP32 自带的Preferences库本质是操作 NVS 分区。启动时先读 NVS 里的配置如果读不到第一次上电就用代码里的默认值然后把默认值写进去。运行时如果收到新的配置比如通过 MQTT 下发先校验范围防止填个 999% 把逻辑搞崩再写入 NVS同时更新内存里的变量。OTA 是第二个刚需。我把ArduinoOTA加进去之后改代码只需要在同一个局域网下点一下上传特别是我在阳台调试水泵时长的时候省了大量来回跑的时间。OTA 有几个注意点一是ArduinoOTA.handle()必须放在loop()里频繁调用不能有长阻塞二是 OTA 过程中如果水泵正在转升级重启会让泵停掉所以我在 OTA 开始前主动把泵停掉并进入安全态三是 OTA 密码别用默认值虽然只是局域网但邻居连上你家 WiFi 的概率也不是零。5. 一个完整夏天的踩坑记录与排查链路5.1 水泵一启动 ESP32 就重启从电源查到地线这个现象最早出现在系统装好后的第三天。每次水泵启动的瞬间串口打印一行乱码然后板子重启日志里能看到Brownout detector was triggered。一开始我以为是代码问题在提示词里让 AI 帮我加了各种异常处理没用。后来才想明白这是电压跌落纯硬件问题软件层面再怎么加保护都挡不住。排查链路是这样的第一步用万用表量 12V 输入端水泵启动瞬间从 12.1V 掉到 10.8V说明电源本身扛不住启动电流。第二步量 ESP32 的 3.3V启动瞬间掉到 2.6V低于欠压检测阈值所以复位。第三步定位原因——我的降压模块是从 12V 取电的水泵启动拉低 12V 母线降压模块输入跟着掉输出自然稳不住。修复方案分三层。第一层加大电源余量把 12V 适配器从 1A 换成 2A母线跌落从 1.3V 降到 0.4V。第二层在降压模块输入端并 1000uF 电容给瞬时跌落做缓冲。第三层也是最有效的一层给 ESP32 单独一路供电——用一个小 5V 适配器专门喂主控和水泵完全不共电源只共地。改成三路供电之后12V 给泵、5V 给主控、3.3V 传感器从主控取这个问题彻底消失。提示水泵和主控共地是必须的MOSFET 的开关参考地要和 ESP32 的 GND 连在一起否则栅极电压没有参考MOSFET 会工作异常。但共地不等于共电源这两件事一定要分清。5.2 湿度读数缓慢漂移探头位置和盆土结构的锅系统稳定运行了一个多月之后我发现一个怪现象同一盆花刚浇完水读数 58%过两天掉到 40%再过三天还在 40% 附近晃直到第四天突然掉到 30%然后触发浇水。按理说土壤水分应该是连续下降的曲线不该有平台期。我挖开土看了一次才明白探头插在盆边缘靠盆壁的位置那一小块土和盆中心的土水分交换很慢边缘土干了中心还是湿的探头读的是边缘局部。而且盆壁温度变化大对电容式探头也有影响。解决办法是把探头往盆中心挪深度插到根系主要分布区大概土面下 5-8cm并且斜着插而不是垂直插让探头的感测面有更大的接触面积。另外我加了一条单点读数不代表整盆的校正逻辑不在读数上做假而是在策略上接受不确定性把启动阈值从 32% 放宽到 28%把停止阈值从 55% 提到 60%用更宽的区间来吸收局部测量误差。5.3 灌溉策略的边界条件雨天、夜间、水压纯阈值控制在实际环境里会遇到几个尴尬场景。第一个是雨天空气湿度高、蒸发慢但盆土读数可能还处在阈值边缘系统照浇不误等于白浇。我的处理是加一路环境湿度参考——不一定非要装雨滴传感器用一个便宜的 DHT22 测空气湿度就够了当空气湿度长期高于 85% 时把启动阈值临时下调 5%相当于下雨天宽松一点。第二个是夜间浇水。傍晚浇水水分在土里停留一整夜根系泡得久有些植物容易烂根而且夜间蒸发慢浇同样的量效果过盛。我在代码里加了一条时间窗口限制只在早上 6 点到 10 点之间允许启动浇水其余时间只记录不动作。这个时间窗如果需要可以用 NTP 校时我一开始懒得加 NTP靠millis()计时结果断电重启之后时间归零窗口判断全乱浇了两次半夜的水后来老老实实加了 NTP 同步。如果 NTP 失败比如断网就用上电后经过时间估算宁可放过一次浇水也不要半夜开泵。第三个是水压。我用的是水箱加自吸泵的方案水箱水位低的时候泵的负载变轻、流量变大同样的运行时间浇的水更多。这个我没做闭环补偿需要流量计但我在水箱里加了个最简单的浮球开关当缺水信号接了一个 GPIO缺水时直接禁止启动——这比任何软件判断都可靠。5.4 用表格把常见故障和排查顺序固定下来跑了大半年我把遇到过的问题整理成一张排查表现在再出问题我基本照着走一遍就能定位省了很多时间现象最可能原因排查顺序处理方式水泵启动时主控重启电源跌落或共地不良量母线电压 → 量 3.3V → 查地线加大电源余量、并电容、分开供电湿度读数长期不动接了 ADC2 引脚或探头断了查引脚号 → 手动短路测试换到 ADC132-39、换探头湿度读数乱跳采样未滤波或供电纹波大看原始毫伏值波动幅度加中位数滤波、传感器单独稳压水泵自己启动栅极悬空或复位期间电平不定断电测栅极电压加 10k 下拉电阻频繁启停阈值无滞回看日志启停间隔启动/停止双阈值 最小间隔联网后数据不更新主循环被阻塞或 MQTT 未重连看是否有 delay 长阻塞全非阻塞 重连节流注意这张表里水泵自己启动那一项如果你用的是继电器模块而不是 MOSFET还要额外检查继电器模块是不是低电平触发。市面上很多模块是低有效你按高有效写代码一上电 IO 拉低泵就转了。这个坑我踩过第一次上电差点把桌面淹了。6. 从能跑到能过冬外壳、供电与长期维护的收尾活代码跑稳之后剩下的事情其实是让它活得久。我把整机装进一个 IP65 的防水接线盒盒子上开了三个孔一个是传感器线出线孔用防水接头别用热熔胶夏天一晒就化一个是水管出线孔还有一个是电源进线孔。盒子里放了一小包干燥剂每季度换一次。ESP32 板子用尼龙柱架空不要直接贴盒底夏天盒内温度能到五十多度。供电这块我给电源加了独立的空气开关和一个保险丝。这个不是危言耸听——水泵堵转时的电流能到额定值的三四倍没有保险丝的话线材发热是真有隐患。保险丝选额定电流的 1.5 倍左右我用的 1A 慢熔。维护上我做了两件小事都很便宜但很有用。第一件是在代码里加了一个运行统计累计浇水次数、累计运行秒数、累计故障次数存在 NVS 里每次连上就上报一次。靠这个我能看出泵的累计工作时长大概两百小时左右就该检查一下泵头和管路了。第二件是给探头做了个快拆结构用防水航插连接需要清洗探头或者换盆的时候拔下来就行不用拆整个盒子。如果你也想照着做一套我的建议是先别追求功能全。先把读湿度、判断、开关泵这条最干的链路跑通跑一个星期看日志确认读数稳定、不误浇再往上加联网、加远程配置。我见过太多人一上来就把 MQTT、可视化面板、手机 App 全堆上结果底层读数都没校准上层做得再漂亮也是错的。这套系统真正的价值不在代码有多复杂而在于你对那盆土的理解有多细——AI 能帮你把代码写快但土壤的脾气还是得你自己蹲下来摸一摸。 
长河君 · 2026/10/29 15:48:35 · 阅读 1.2k ESP32智能花园自动灌溉系统：AI生成代码与工程化改造
去年夏天出差一周回家推开门先看见阳台那几盆番茄叶子卷成一条一条土面裂得能塞进手指。那会儿我就下了决心做一个能自己判断该不该浇水的ESP32 智能花园自动灌溉系统。真正动手才发现难的不是水泵接个继电器这种电工活难的是把需求拆清楚、把代码写健壮。后来我换了个思路——把需求整理成结构化描述丢给AI 生成代码的工具我用的是快马平台那套对话式生成流程让它先吐出一个完整项目骨架我再逐段改造。这套流程跑通之后我从零到能稳定运行的整机只花了两个周末。下面这份内容是我把这套AI 生成 人工改造的完整链路掰开揉碎写下来的。它适合三类人看手上有一块 ESP32 开发板、想给阳台/小院做自动浇水的动手党想学怎么把零散需求写成高质量提示词、让 AI 吐出可编译代码的开发者以及已经跑通 Demo、但系统一到夏天就重启、读数乱飘、水泵时不时自己启动的踩坑选手。我会把每一步为什么这么设计讲清楚也会把那些文档里不会写、只有真跑过一个完整夏天才会遇到的坑原原本本摊开。1. 动手之前先把硬件清单钉死别指望 AI 帮你选型1.1 灌溉系统在物理上到底由哪几个环节组成很多人拿到开发板第一反应是打开平台开始让 AI 生成代码这个顺序其实是反的。AI 擅长的是把你已经想清楚的结构翻译成代码它不擅长替你做物理世界的取舍。灌溉系统在物理层面拆开其实就四个环节感知土壤湿度多少、判断现在该不该浇、执行水泵转多久、供电谁给水泵和主控供电。这四件事里只有判断是纯软件逻辑其余三个都是硬件决定软件。所以我在提示词里最先写的不是帮我写一个自动灌溉程序而是先把硬件拓扑描述清楚一颗 ESP32 主控一路模拟输入接电容式土壤湿度探头一路数字输出经驱动电路控制直流隔膜泵供电是 12V 适配器给水泵、经降压模块给 ESP32。把这段写进去之后AI 生成的代码里 GPIO 分配、ADC 读取方式、继电器控制逻辑才对得上不会给你生成一个用 PWM 调速控制水泵但硬件上根本没接调速模块的代码。这里有个容易被忽略的点湿度传感器接在哪个引脚不是随便挑的。ESP32 有两组 ADCADC2 在 WiFi 开启时会被射频模块占用读出来全是无效值。所以湿度探头必须接 ADC1 的引脚GPIO32 到 GPIO39 这一段。这一条我在第一版提示词里没写AI 默认给了我 GPIO4编译通过、烧录成功、串口打印出来的湿度永远是一个不动的数字我盯着屏幕看了半小时才想起来 ADC2 的坑。1.2 电容式探头和电阻式探头差的不是价格而是寿命新手最容易踩的坑就是买了那种几块钱的电阻式叉形裸露电极湿度探头。它便宜、读数直观但它工作在直流偏置下两块电极插在潮湿土壤里相当于一个电解池阳极会持续被腐蚀。我第一版用的就是这种装进花盆二十天电极表面一层绿色氧化物读数从干了 20%漂到干了 60%系统开始疯狂浇水把一盆薄荷浇死了。换成电容式探头之后情况完全不一样。电容式探头本质是一块覆铜板当极板中间是阻焊层土壤含水量改变介电常数从而改变电容值前端电路把它转成 0 到 3V 的模拟电压。它没有裸露金属和土壤直接接触不存在电解腐蚀问题长期稳定性好得多。代价是它对供电电压比较敏感最好用 3.3V 单独给它供别和继电器、水泵共用一路纹波很大的 5V。还有一点必须实测不同批次的电容式探头输出极性可能是反的。有的模块土越湿电压越高有的越湿电压越低。我买的第二批和第一批就是反的直接套用第一批的映射公式系统逻辑整个颠倒——土越干越不浇水。所以代码里我把干点电压和湿点电压做成了两个常数第一次上电必须做一次标定这个后面细说。1.3 水泵绝对不能让 GPIO 直接驱动驱动电路的三个关键件ESP32 的 GPIO 最大输出电流大概 40mA 量级而一个 12V 微型隔膜泵启动瞬间的电流可以到 1A 以上稳态也有三四百毫安。直接接上去轻则带不动重则把 IO 口烧掉。中间必须有一级驱动。常见方案有两个继电器模块和 MOSFET 低边开关。我两个都试过最后选了 MOSFET。原因很实际——机械继电器在吸合和断开的瞬间线圈会产生反向电动势那一下的干扰足以让旁边的 ESP32 抖一下甚至复位。我早期用继电器时每次水泵启动串口就打印一串乱码然后重启折腾了很久才定位到是继电器线圈没加续流二极管。如果你手头只有继电器模块务必确认它是带光耦隔离和续流二极管的成品模块而且控制信号最好经一级三极管或光耦别让 ESP32 的 IO 直接吃线圈的反峰。我最终的驱动电路是这样GPIO26 输出高电平经 1k 电阻到 N 沟道 MOSFET 的栅极栅极对地并一个 10k 下拉电阻这个下拉极其重要它保证 ESP32 复位、深睡眠或程序跑飞时MOSFET 栅极被拉到低电平水泵不会自己启动MOSFET 源极接地漏极接水泵负极水泵正极接 12V同时在泵两端反并联一只肖特基续流二极管。外加在 12V 输入端并一个 1000uF 电解电容吸收水泵启动瞬间的电压跌落。那个 10k 下拉电阻是我付出了半个阳台被淹的代价换来的。早期版本没有它ESP32 进入深睡眠后 GPIO 处于高阻态MOSFET 栅极悬空被环境噪声耦合出电压水泵就那么不紧不慢地转了二十分钟等我发现时托盘里的水已经漫到地砖上了。2. 提示词怎么组织AI 才会吐出能直接烧录的项目骨架2.1 一次把约束说全比来回追问十次有效我用快马平台生成代码的第一个版本提示词就一句话用 ESP32 写一个自动浇水的程序。它给我的代码能编译但完全不能用引脚是随机的、没有 WiFi、主循环里delay(60000)阻塞了六十分钟、没有任何异常保护。这不是 AI 不行是我给的信息量不够它做决策。后来我改成一次把四类信息写全效果立刻不一样第一类是硬件清单主控型号、每个外设接在哪个 GPIO、传感器类型模拟量还是数字量、驱动方式高电平有效还是低电平有效。这一块写得越死越好别写接一个湿度传感器要写接一个电容式模拟湿度传感器输出 0-3V接 GPIO32。第二类是运行约束采样周期多少秒、单次浇水最长多少分钟、两次浇水最小间隔多少小时、阈值多少。这些参数决定了代码里所有的定时逻辑。第三类是联网需求要不要上报、上报到哪里、断网了怎么办、配置能不能远程改。第四类是工程约束用 Arduino 框架还是 ESP-IDF、要不要用 FreeRTOS 多任务、电源是不是电池供电决定要不要深睡眠、代码要拆成几个文件。我把这四类写成一段结构化的中文描述丢进去生成的代码质量提升非常明显——它主动给我加了Preferences做配置持久化还加了看门狗。这些我没提但因为我写了要求长期无人值守运行它把这些当成隐含需求补上了。2.2 三版提示词的生成结果对比差在哪我把三版提示词的实际产出列个表这个对比比我讲一百句提示词要写详细都有用版本提示词要点生成结果主要问题第一版一句话ESP32 自动浇水单文件delay()阻塞主循环无状态机、无保护、引脚随机第二版补了引脚表和阈值参数单文件带阈值判断仍阻塞、无滞回、无最长运行保护第三版四类约束全给指明非阻塞多文件状态机 配置持久化 看门狗需人工替换传感器校准值第二版到第三版之间的差别其实就三个字非阻塞。我在提示词里明确写了主循环不得使用大于 100ms 的 delay所有定时基于 millis() 时间戳生成的代码才从浇完水睡一小时变成每秒轮询、状态机推进。这两种写法的差别在实际使用中是致命的——阻塞版本在浇水的那几分钟里完全不响应任何输入你想临时手动停泵都做不到只能拔电源。2.3 让 AI 输出可维护的骨架而不是一坨 loop 函数第三版生成的结果我做了两处关键改造。第一处是把loop()里的逻辑抽成一个显式的状态机。AI 原始版本是用布尔变量isPumping加一堆 if 拼出来的能跑但没法扩展。我改成三个状态IDLE空闲监测、WATERING浇水中、COOLDOWN间隔冷却每个状态只做自己该做的事状态切换有明确条件。第二处是我手动把配置参数从代码里挪出来放进config.h里集中管理同时在 NVS 里存一份可运行时修改的副本。这样做的好处是我后来想调阈值不用重新烧录固件用手机连上就知道当前值改完写回 NVS 立即生效。这个改造思路我也会建议你写进提示词让 AI 一开始就按常量默认值 NVS 覆盖的双层结构生成省得后面返工。3. 拿到代码先别急着烧逐段读懂 ADC 采样与判断逻辑3.1 湿度读数为什么要滤波和标定两次校准的具体做法AI 生成的原始采样函数大概是这样analogRead(PIN_SOIL)读一次直接map()成百分比。这个写法有两个问题。一是 ESP32 的 ADC 本身噪声不小单次采样跳动能有几十个 LSB映射成百分比可能上下抖 5%。二是map()用的是线性假设而电容式探头的电压-含水量曲线在中段比较线性、两端明显弯曲直接线性映射会导致干区和湿区判断都不准。我的改法是两点滤波用多次采样取中位数再平均标定用两点法。滤波部分我采 15 次间隔 5ms先排序取中间 7 个求平均这样能同时压掉随机噪声和偶发的脉冲干扰。标定部分我在探头完全埋进干燥的盆土放置 24 小时时记下电压V_DRY在探头插进一杯清水时记下V_WET然后把这两个值写死成常数。这里有个细节ESP32 Arduino 核心提供了analogReadMilliVolts()它内部带出厂校准读出来直接是毫伏比裸analogRead的 0-4095 准得多也不用自己算衰减档位。我一开始用裸 ADC 值换一块板子读数整体偏移折腾半天换成毫伏读数之后两块板子之间的一致性好了很多。标定还有一个隐藏坑不要把探头插在水里当100% 湿来标定。清水里的介电常数和饱和含水土壤并不相同用水标出来的湿点电压会偏导致实际土壤明明已经很湿了系统还认为没到停止阈值一直浇。我的做法是用一盆浇透水、静置两小时、盆底不再滴水的土来标湿点这样更接近真实饱和状态。3.2 阈值判断里的滞回不加就是灾难假设你把启动阈值设成 35%停止阈值也设成 35%会发生什么湿度掉到 34.9% 的时候水泵启动浇了几秒钟湿度升到 35.1%水泵停再过十几秒土壤水分扩散均匀读数又掉回 34.8%水泵又启动。如此反复一天之内水泵启停上百次不光吵泵的寿命也扛不住。解决办法就是滞回启动和停止用两个不同的阈值中间留一个死区。我设的是湿度低于 32% 启动浇到 55% 停。中间这 23% 的区间里系统什么都不做。这个死区宽度不是随便定的取决于你的盆大小和土壤类型——大盆水分扩散慢死区可以小一点小盆浇水后湿度上升快死区要给足否则浇过头。除了阈值滞回我还加了一个连续确认机制只有当连续 5 次采样每次间隔 1 分钟都低于启动阈值才认为真的该浇水了。这是为了防止一次偶发的异常读数比如探头被挪动、接触不良触发误浇。这个技巧很好用我已经靠它挡掉过好几次莫名其妙的误启动。3.3 水泵的三重保护超时、间隔、干转这是我最看重的部分也是 AI 第一版完全没给的东西。水泵如果失控持续运转后果不是浪费水是水漫金山——水管脱落、花盆溢出、托盘漫出来。所以我给水泵加了三重锁。第一重是单次最长运行时间。我在常量里写死MAX_PUMP_MS 5 * 60 * 1000也就是五分钟。不管湿度读数怎么说只要泵连续转了五分钟强制停机并进入故障态同时把状态上报出去。这个值按你的泵流量和盆大小调我的 3L/min 小泵配 30cm 花盆两分钟足够了设五分钟是留了很大余量。第二重是两次浇水的最小间隔。我设的是 30 分钟代码里记lastPumpStopMs任何一次启动前先检查距离上次停机是否超过这个间隔。这一条主要是防着探头位置不当导致读数一直低这种硬件层面的持续误判。第三重是干转保护。严格来说真正的干转保护需要加流量计或者电流检测但那成本上去了。我用的是一种软件近似如果一次浇水跑满了两分钟但湿度读数几乎没变化上升小于 3%就判定为异常可能是水箱空了、管路堵了、探头掉了把泵停掉并进入告警。这三重锁写成代码之后运行一整个夏天再没有出现过意外溢水。我个人觉得灌溉类项目里防止它做错事的优先级远高于让它做得更聪明。4. 联网、断网与掉电恢复无人值守系统的真实考题4.1 WiFi 和 MQTT 的健壮写法别在 loop 里死等AI 生成的联网代码最常见的毛病是在loop()里写while (WiFi.status() ! WL_CONNECTED) { delay(500); }。这段代码在路由器重启、信号短暂中断的时候会把整个主循环卡死水泵控制逻辑全部停摆。更糟的是如果用的是delay()看门狗可能直接触发复位。我的写法是全非阻塞每轮循环检查一次连接状态断开就记录一个时间戳尝试重连但重连动作本身不阻塞用WiFi.begin()之后直接返回下一轮再看状态。这样即使网络断了十分钟灌溉逻辑照常运行只是数据上报暂停。MQTT 也是同样的道理。我用的是带重连节流的版本每次mqtt.loop()之后检查连接断了就每 5 秒尝试一次重连重连成功立刻发一条上线消息和当前状态。这里有个小心思重连间隔不能太短否则连不上时会疯狂刷日志、占满 CPU反过来影响采样。4.2 断网时系统怎么活本地优先的设计原则我一开始的设计是云端判断——ESP32 把湿度上报服务器算完下发指令。这个方案我很快就放弃了。原因很朴素我家阳台的路由器一个夏天重启了七八次每次重启期间如果正好该浇水那这盆花就只能干等着。改成本地优先之后一切顺畅所有判断逻辑都在 ESP32 本地跑云端只做两件事——接收数据做记录和可视化以及下发临时覆盖指令比如我在外面看到要下雨手动下发一个暂停 24 小时。断网时本地逻辑完全不受影响网络恢复后补发缓存的数据。为了实现这一点我在代码里加了一个小的环形缓冲区存最近 50 条状态记录时间戳、湿度、动作发不出去就先存在内存里连上之后批量补发。50 条大概够撑几个小时再多就得考虑写 flash 了但我评估了一下没必要——真断网一整天那些数据意义也不大了。4.3 配置持久化与 OTA不用每次搬着笔记本去阳台调阈值这件事如果你每次都要拔板子、插 USB、打开电脑、编译、烧录那这个系统你调三次就不想动了。所以配置持久化是刚需。我用的是 ESP32 自带的Preferences库本质是操作 NVS 分区。启动时先读 NVS 里的配置如果读不到第一次上电就用代码里的默认值然后把默认值写进去。运行时如果收到新的配置比如通过 MQTT 下发先校验范围防止填个 999% 把逻辑搞崩再写入 NVS同时更新内存里的变量。OTA 是第二个刚需。我把ArduinoOTA加进去之后改代码只需要在同一个局域网下点一下上传特别是我在阳台调试水泵时长的时候省了大量来回跑的时间。OTA 有几个注意点一是ArduinoOTA.handle()必须放在loop()里频繁调用不能有长阻塞二是 OTA 过程中如果水泵正在转升级重启会让泵停掉所以我在 OTA 开始前主动把泵停掉并进入安全态三是 OTA 密码别用默认值虽然只是局域网但邻居连上你家 WiFi 的概率也不是零。5. 一个完整夏天的踩坑记录与排查链路5.1 水泵一启动 ESP32 就重启从电源查到地线这个现象最早出现在系统装好后的第三天。每次水泵启动的瞬间串口打印一行乱码然后板子重启日志里能看到Brownout detector was triggered。一开始我以为是代码问题在提示词里让 AI 帮我加了各种异常处理没用。后来才想明白这是电压跌落纯硬件问题软件层面再怎么加保护都挡不住。排查链路是这样的第一步用万用表量 12V 输入端水泵启动瞬间从 12.1V 掉到 10.8V说明电源本身扛不住启动电流。第二步量 ESP32 的 3.3V启动瞬间掉到 2.6V低于欠压检测阈值所以复位。第三步定位原因——我的降压模块是从 12V 取电的水泵启动拉低 12V 母线降压模块输入跟着掉输出自然稳不住。修复方案分三层。第一层加大电源余量把 12V 适配器从 1A 换成 2A母线跌落从 1.3V 降到 0.4V。第二层在降压模块输入端并 1000uF 电容给瞬时跌落做缓冲。第三层也是最有效的一层给 ESP32 单独一路供电——用一个小 5V 适配器专门喂主控和水泵完全不共电源只共地。改成三路供电之后12V 给泵、5V 给主控、3.3V 传感器从主控取这个问题彻底消失。提示水泵和主控共地是必须的MOSFET 的开关参考地要和 ESP32 的 GND 连在一起否则栅极电压没有参考MOSFET 会工作异常。但共地不等于共电源这两件事一定要分清。5.2 湿度读数缓慢漂移探头位置和盆土结构的锅系统稳定运行了一个多月之后我发现一个怪现象同一盆花刚浇完水读数 58%过两天掉到 40%再过三天还在 40% 附近晃直到第四天突然掉到 30%然后触发浇水。按理说土壤水分应该是连续下降的曲线不该有平台期。我挖开土看了一次才明白探头插在盆边缘靠盆壁的位置那一小块土和盆中心的土水分交换很慢边缘土干了中心还是湿的探头读的是边缘局部。而且盆壁温度变化大对电容式探头也有影响。解决办法是把探头往盆中心挪深度插到根系主要分布区大概土面下 5-8cm并且斜着插而不是垂直插让探头的感测面有更大的接触面积。另外我加了一条单点读数不代表整盆的校正逻辑不在读数上做假而是在策略上接受不确定性把启动阈值从 32% 放宽到 28%把停止阈值从 55% 提到 60%用更宽的区间来吸收局部测量误差。5.3 灌溉策略的边界条件雨天、夜间、水压纯阈值控制在实际环境里会遇到几个尴尬场景。第一个是雨天空气湿度高、蒸发慢但盆土读数可能还处在阈值边缘系统照浇不误等于白浇。我的处理是加一路环境湿度参考——不一定非要装雨滴传感器用一个便宜的 DHT22 测空气湿度就够了当空气湿度长期高于 85% 时把启动阈值临时下调 5%相当于下雨天宽松一点。第二个是夜间浇水。傍晚浇水水分在土里停留一整夜根系泡得久有些植物容易烂根而且夜间蒸发慢浇同样的量效果过盛。我在代码里加了一条时间窗口限制只在早上 6 点到 10 点之间允许启动浇水其余时间只记录不动作。这个时间窗如果需要可以用 NTP 校时我一开始懒得加 NTP靠millis()计时结果断电重启之后时间归零窗口判断全乱浇了两次半夜的水后来老老实实加了 NTP 同步。如果 NTP 失败比如断网就用上电后经过时间估算宁可放过一次浇水也不要半夜开泵。第三个是水压。我用的是水箱加自吸泵的方案水箱水位低的时候泵的负载变轻、流量变大同样的运行时间浇的水更多。这个我没做闭环补偿需要流量计但我在水箱里加了个最简单的浮球开关当缺水信号接了一个 GPIO缺水时直接禁止启动——这比任何软件判断都可靠。5.4 用表格把常见故障和排查顺序固定下来跑了大半年我把遇到过的问题整理成一张排查表现在再出问题我基本照着走一遍就能定位省了很多时间现象最可能原因排查顺序处理方式水泵启动时主控重启电源跌落或共地不良量母线电压 → 量 3.3V → 查地线加大电源余量、并电容、分开供电湿度读数长期不动接了 ADC2 引脚或探头断了查引脚号 → 手动短路测试换到 ADC132-39、换探头湿度读数乱跳采样未滤波或供电纹波大看原始毫伏值波动幅度加中位数滤波、传感器单独稳压水泵自己启动栅极悬空或复位期间电平不定断电测栅极电压加 10k 下拉电阻频繁启停阈值无滞回看日志启停间隔启动/停止双阈值 最小间隔联网后数据不更新主循环被阻塞或 MQTT 未重连看是否有 delay 长阻塞全非阻塞 重连节流注意这张表里水泵自己启动那一项如果你用的是继电器模块而不是 MOSFET还要额外检查继电器模块是不是低电平触发。市面上很多模块是低有效你按高有效写代码一上电 IO 拉低泵就转了。这个坑我踩过第一次上电差点把桌面淹了。6. 从能跑到能过冬外壳、供电与长期维护的收尾活代码跑稳之后剩下的事情其实是让它活得久。我把整机装进一个 IP65 的防水接线盒盒子上开了三个孔一个是传感器线出线孔用防水接头别用热熔胶夏天一晒就化一个是水管出线孔还有一个是电源进线孔。盒子里放了一小包干燥剂每季度换一次。ESP32 板子用尼龙柱架空不要直接贴盒底夏天盒内温度能到五十多度。供电这块我给电源加了独立的空气开关和一个保险丝。这个不是危言耸听——水泵堵转时的电流能到额定值的三四倍没有保险丝的话线材发热是真有隐患。保险丝选额定电流的 1.5 倍左右我用的 1A 慢熔。维护上我做了两件小事都很便宜但很有用。第一件是在代码里加了一个运行统计累计浇水次数、累计运行秒数、累计故障次数存在 NVS 里每次连上就上报一次。靠这个我能看出泵的累计工作时长大概两百小时左右就该检查一下泵头和管路了。第二件是给探头做了个快拆结构用防水航插连接需要清洗探头或者换盆的时候拔下来就行不用拆整个盒子。如果你也想照着做一套我的建议是先别追求功能全。先把读湿度、判断、开关泵这条最干的链路跑通跑一个星期看日志确认读数稳定、不误浇再往上加联网、加远程配置。我见过太多人一上来就把 MQTT、可视化面板、手机 App 全堆上结果底层读数都没校准上层做得再漂亮也是错的。这套系统真正的价值不在代码有多复杂而在于你对那盆土的理解有多细——AI 能帮你把代码写快但土壤的脾气还是得你自己蹲下来摸一摸。