养过虾的人都知道晚上最怕听到的不是虾跳而是增氧机没动静。水温、溶氧、pH、氨氮哪个数据没盯住一塘虾可能一夜回到解放前。百度智能云最近发布的 DuClaw名字听着挺有个性实际是个面向水产养殖场景的 AI 应用搭建平台主打零门槛让养殖户用自然语言和拖拽配置管虾塘。这篇文章我不打算重复官方新闻稿就从一个实际搞过项目的人视角拆一拆 DuClaw 能干什么、怎么上手、有哪些坑。DuClaw 这个名字里的“Du”很好理解是百度的 AI 基因“Claw”像虾蟹的那对钳子摆明了就是奔着“虾塘”来的。官方把它定位成“零门槛养虾平台”在我看来它真正的价值不是帮你把虾养出来而是把数据采集、设备控制、智能分析和养殖建议做成了一套可以对话、可以配置、可以自动响应的系统。换句话说以前你翻设备说明书、查水质表、凭经验判断现在你只需要在 DuClaw 里问一句“1号塘下午的溶氧趋势怎么样”平台就能直接告诉你结果甚至顺手把增氧机开了。这篇文章适合三类人一类是自己有虾塘、想上智能化但怕学不会的养殖户一类是做智慧农业项目、需要快速出演示方案的系统集成商还有一类是对大模型应用落地方案感兴趣的开发者。无论你是哪一类只要你关心“一个 AI 产品到底怎么把养虾这件事变简单”这篇文章都能给你一些可用的思路。1. 养虾这件事到底难在哪1.1 传统养虾的“三座大山”先说清楚一个背景虾这个东西对环境变化的敏感程度超出大部分人想象。早期我们做水产项目时见过不少养殖户每天晚上睡觉都不踏实隔一两个小时就要巡一圈塘听听增氧机声音正不正常看看水面上有没有虾跳起来的异常动静。为什么这么紧张因为高密度养殖模式下虾的生存窗口其实很窄。第一座大山是溶氧波动。白天气温高、藻类光合作用强溶氧还能撑住到了后半夜藻类不仅不产氧还要消耗氧再加上虾本身呼吸和有机物分解溶氧很容易跌到 3mg/L 以下。虾一缺氧食欲下降、体质变弱严重时候直接浮头处理不及时就是整塘损失。传统做法是靠经验加定期测量但人的精力终究有限尤其温度骤变或者闷热天等到感觉到不对劲时往往已经晚了。第二座大山是水质指标滞后。pH、氨氮、亚硝酸盐这些东西变化往往不是线性的可能连续几天看着正常突然某个指标就跨过临界值。传统检测方式多数是每天用试剂盒测一次早上测和晚上测结果可能差很多更不用说温度分层、水体流动造成的局部差异。数据滞后带来的最大问题是你看到的是“已经发生完”的结果而不是“正在发生”的趋势处理起来永远慢半拍。第三座大山是经验复制难。同一个村里有的人养虾年年赚钱有的人年年亏差距往往就藏在细节里什么时候该加料、什么时候该换水、下雨前要不要改底、增氧机该开几台。这些经验分散在人的脑子里很难标准化更别说让一个新人快速上手。所以养虾这个行业表面上是养虾实际上是管数据、管风险、管决策。这也是为什么百度智能云会专门做 DuClaw 这个产品因为它想解决的恰好就是这三座大山。1.2 DuClaw 怎么降门槛DuClaw 的降门槛思路跟一般“智慧养殖系统”不太一样。传统系统一上来就是一套大屏、一个后台、一堆传感器看起来很酷但真正让养殖户用他根本不知道从哪里开始。DuClaw 把入口做成了“对话框”和“模板库”的组合你不需要懂数据库不需要看复杂图表只要会用手机打字就能获取核心信息。具体来说DuClaw 内置了“虾塘水质监测”“增氧机联动控制”“投喂策略建议”“疾病风险预警”等常用场景模板。我理解它的逻辑是这样的用户先选一个模板平台自动把设备和规则关联好然后用户用自然语言提问平台负责把问题翻译成数据查询或者控制指令。比如你不想手动翻曲线直接问“今天凌晨4点溶氧最低到多少”系统就会返回具体数值并附一张趋势说明告诉你当时增氧机有没有正常工作。这个设计背后有一个很关键的取舍把复杂留给平台把简单留给用户。传统 SAAS 软件默认用户愿意学习复杂的配置流程但养殖户的核心诉求只有一个告诉我现在该不该开增氧机、要不要停料、水有没有问题。DuClaw 把这些问题变成了“零门槛”的自然语言交互同时又保留了一个低代码配置页给愿意深挖的养殖能手和技术人员。这样一来新手能快速上手老手也能把系统调成自己的风格覆盖的人群和场景就宽得多。2. 零门槛不是口号DuClaw 的整体设计与选型逻辑2.1 平台架构怎么搭我花了点时间扒了下 DuClaw 的能力边界虽然官方没有把每层架构都公开但从产品和 API 文档能看出一个大致的逻辑。整个平台可以分成四层设备接入层、数据层、智能引擎层、应用层。设备接入层主要解决“传感器怎么连上来”的问题。虾塘里常见的设备有溶氧传感器、pH 传感器、温度探头、氨氮传感器还有控制增氧机、投饵机的继电器和控制器。传统项目里最头疼的就是设备协议不一致有的走 Modbus RTU有的走 MQTT有的只有私有协议。DuClaw 的做法是提供预置物模型和边缘网关只要设备能联网或者接入网关平台就能把数据归一到统一格式后续应用不需要关心底层协议差异。数据层做的事不只是存储还包括清洗、对齐、计算。水质数据是典型的时序数据而且容易掺入噪声比如传感器探头被水草缠住、线路接触不良都会产生异常值。DuClaw 的数据层会在入库前做一轮过滤把明显跳变的毛刺值剔除再按照固定时间间隔对齐保证上层分析和规则判断用的是干净数据。智能引擎层是 DuClaw 最核心的部分它同时跑着大模型、规则引擎和轻量预测模型。大模型负责自然语言问答、策略解释和报告生成规则引擎负责毫秒级的阈值判断和设备联动比如溶氧低于 4mg/L 自动开增氧机预测模型则负责分析趋势判断未来几小时是否可能出现低氧风险。应用层最贴近用户包括手机端的对话窗口、电脑端的管理台、预警通知中心还有第三方系统的 API 接口。这层考虑得比较实际养殖户用手机看消息技术员在电脑上配置规则集成商通过 API 把 DuClaw 的数据接到自己的平台里。四层架构清晰职责分离这是我比较欣赏的设计。2.2 为什么选“大模型规则引擎”双核驱动现在做 AI 平台容易走进一个误区觉得大模型什么都能干就让大模型直接控制设备。真这么做会出大问题因为大模型是概率模型回答可以有创意但控制设备必须绝对确定。你问“今天天气怎么样”它可以自由发挥但你说“溶氧低于阈值立即启动增氧机”这个指令不能有半点含糊。DuClaw 的选择非常务实把大模型和规则引擎做成两个互补的引擎各管各自擅长的事。规则引擎解决“确定性任务”。它是一套 if-then 逻辑比如“溶氧连续 2 分钟低于 4mg/L执行增氧机启动”这个判断跟大模型无关延迟在毫秒级别即便是断电重启、网络抖动规则配置依然存在边缘网关里保证设备安全。养虾现场最怕系统“掉链子”规则引擎就是最后一道物理防线。大模型解决“复杂交互任务”。它把用户说的“1号塘水质最近咋样”翻译成具体的数据查询请求再把查询结果组织成一段人话回答“1号塘近期水温稳定在 28 度左右溶氧略有下降平均 4.2mg/LPH 8.0建议关注夜间溶氧提前做好增氧准备。”这种话术很接近老师傅给养殖户的建议规则引擎做不到只有大模型可以。这两个引擎通过一个“意图路由”模块连起来自然语言先进大模型做意图识别如果需要实时数据查询就调用数据服务如果需要设备控制就生成一条指令交给规则引擎校验后执行。这种方式既聪明又稳妥是我目前见过的大模型落地行业应用里比较成熟的套路。2.3 云端与边缘计算的取舍智慧养殖项目有个现实问题虾塘往往不在网络好的地方。我之前做过一个项目池塘边信号时好时坏基站偶发拥塞云端指令回传延迟很大。如果所有决策都依赖云端网络一断整个系统就瘫痪了。DuClaw 应该也是考虑到这一点所以采用了云端边缘网关混合架构。边缘网关放在虾塘边的控制柜里负责实时采集和本地策略执行。它跟平台保持连接但即使断网也能按照本地规则继续监控设备、控制增氧机。云端则承担大数据分析、模型训练、多塘口对比和远程访问。这样切分的好处是关键控制能力离设备更近故障风险分散而不是把全部压力压在一根网线上。选边缘还是云端要看的核心指标是“时延容忍度”。自动增氧这类操作时延必须控制在 3 秒以内适合放边缘投喂策略建议这种非紧急分析可以放云端慢慢算。你在项目里设计架构时也得先梳理哪些设备动作是安全相关的最好做成边缘自治哪些是运营优化相关的再交给云端。分清边界系统才会又好用又安全。3. 手把手跑通第一个养虾场景3.1 准备工作账号、设备与数据要实际体验 DuClaw第一步肯定是开通百度智能云账号然后在产品列表里找到 DuClaw 控制台。这一步没什么难度按引导完成企业或个人实名认证即可。接下来准备硬件如果你没有实体设备DuClaw 一般会提供“模拟设备”模式方便开发者先用虚拟数据体验全流程。我建议新手不管有没有真设备都先开一个模拟项目把逻辑跑通后再接物理硬件。我的推荐配置是一个多参数水质传感器溶氧、温度、pH 合一一个氨氮分析仪如果预算不够可以先不做一个带继电器输出的边缘网关以及若干个增氧机和投饵机控制回路。传感器通过 RS485 接入边缘网关网关执行本地规则并向上云平台传输数据。常规水质传感器精度情况溶氧 ±0.3mg/L、温度 ±0.5℃、pH ±0.1量程和精度信息要在设备注册时填准否则后续分析会出现偏差。设备物理连接完成后到 DuClaw 控制台“设备管理”页面添加产品。你需要给设备起一个标识比如pond1_sensor然后选择协议类型 MQTT 或 Modbus TCP。平台通常会自动生成设备密钥你会得到一个三元组ProductKey、DeviceName、DeviceSecret设备端用这个三元组鉴权连接平台。到这里原始数据还没有需要继续配置物模型。物模型可以理解成设备的数据字典描述设备会上报哪些属性。以水质传感器为例至少要定义水温、溶解氧、pH 三个属性属性的单位、数据类型、读写权限都要写清楚。比如溶解氧的数据类型是 float单位 mg/L属性读写权限为只读这样平台拿到数据后才知道怎么解析。物模型配置对后续所有操作都有影响建议一次配到位。3.2 创建项目与绑定设备设备接入后回到 DuClaw 控制台创建一个“养虾项目”。创建时可以选择场景模板比较常见的有“虾塘水质监测”“增氧机自动控制”“投喂策略推荐”。我建议选择“虾塘水质监测”模板因为它是后面所有高级功能的基础。模板选定后系统会生成一个项目空间包含项目 ID、所属用户、绑定的设备列表和默认规则组。接下来把刚才创建的pond1_sensor设备绑定到项目里。绑定动作看起来很简单但这里有一个关键细节不同设备的数据要映射到项目的“塘口模型”上。塘口模型就是项目里对“1号塘”“2号塘”的逻辑抽象每个塘口可以关联一个主传感器、一个备用传感器、若干控制设备。如果你有两个塘口就必须配置两条对应关系否则数据查出来会串。绑定好设备后建议先看一下数据接入是否正常。平台通常有一个“设备调试”界面能看到原始数据流。你观察几轮数据确认温度、溶氧、pH 都有值再进入下一步。这一步千万别跳过很多后面出现的“查不到数据”“曲线是空的”问题都是在这里埋下的雷。3.3 用自然语言问数据DuClaw 最吸引人的功能就是自然语言问答。但在使用之前需要先理解系统的工作方式。它不是简单地把你的问题当成关键词搜索而是走了一遍“提问 → 意图识别 → 数据查询 → 回答生成”的链路。比如你在对话框输入“1号塘现在的溶氧多少”系统接到的这个请求底层可以理解成一个类似这样的 API 调用POST /v1/projects/your_project_id/query { topic_id: pond1, query: 1号塘现在的溶氧多少, result_mode: natural_language }对应的响应可能是{ answer: 1号塘当前溶氧浓度为 5.2mg/L处于正常范围4mg/L最近30分钟趋势平稳暂不需要开启增氧机。, data_points: [ {time: 2024-06-01 10:30:00, value: 5.1}, {time: 2024-06-01 10:35:00, value: 5.3}, {time: 2024-06-01 10:40:00, value: 5.2} ], suggestion: 保持当前状态下一次增氧巡检建议在22:00进行。 }通过这个交互你不需要打开报表页去选时间范围、选指标、看图例直接一个句子平台就会告诉你结果。这个体验做的好的话对养殖户来说非常友好。我实测下来比较实用的问法有“今天凌晨溶氧最低到多少”“过去24小时 pH 超过 9 了吗”“2号塘和1号塘的溶氧对比一下”“如果现在不增氧1号塘什么时候可能出现低氧风险”这些问题的背后考验的是平台对时间、地点、指标、事件四要素的识别。刚开始用如果你发现回答不对可以给输入框加一点上下文比如明确塘口号和时间范围准确率会高很多。3.4 配置自动增氧预警规则自然语言问答适合“我来问”但真正的智能化还要能“替我做事”这就用到规则引擎了。在 DuClaw 项目里添加一个“自动增氧”规则流程类似低代码编排但填的参数必须想清楚。我给的示例配置如下规则名称1号塘低溶氧保护触发设备pond1_sensor触发属性dissolved_oxygen触发条件小于 4mg/L且持续 2 分钟执行动作启动 pond1_aerator通知方式短信通知 手机应用推送这个规则里最重要的不是“小于 4mg/L 启动增氧机”而是“持续 2 分钟”。为什么加这个条件因为传感器在设备启动、水体波动、电极干扰时会有瞬时的异常值可能每隔几分钟跳一次 3.8mg/L马上又恢复 5mg/L。如果条件里不加持续时间增氧机就会频繁启停电机寿命骤减虾也会被惊扰。持续 2 分钟意味着平台连续采集了几个周期都小于阈值才触发这能过滤掉 90% 以上的毛刺误报。配置完规则后还有一个动作要做设置“恢复释放条件”。比如增氧机启动后溶氧升到 5mg/L 以上并持续 3 分钟才停止增氧。这个设计避免临界值反复横跳是提高设备寿命的关键。很多人只配了触发没配恢复结果系统变成“开了关、关了开”到头来反而说是平台有问题。实际都是使用逻辑没闭环。4. 核心参数与模型细节深挖4.1 水质参数阈值别照搬网上的表做智慧养殖项目最忌讳的就是把一个网上抄来的水质阈值表直接填进系统里。不同虾品种、不同生长阶段、不同养殖模式的适宜范围都不一样。比如南美白对虾和罗氏沼虾对盐度、温度的需求差异很大苗期和成虾期的溶氧敏感度也不一样。我整理了一份相对通用的参考表适合南美白对虾成虾期你可以根据实际情况调整参数适宜范围预警阈值建议紧急处理阈值水温26-32℃低于 22℃ 或高于 35℃低于 18℃ 或高于 37℃溶解氧4-8mg/L低于 4mg/L低于 2.5mg/LpH7.5-8.5低于 7.0 或高于 9.0低于 6.5 或高于 9.5氨氮小于 0.2mg/L高于 0.5mg/L高于 1.0mg/L亚硝酸盐小于 0.1mg/L高于 0.3mg/L高于 1.0mg/L这个表只是起点真正上线前你需要结合当地水体本底值和虾苗实际情况做标定。比如有的虾塘在碱性土质区域pH 平时就偏 8.8如果参照网上写的“高于 9.0 预警”会天天报警实际虾并没有问题。所以你可以通过 DuClaw 收集两周以上的历史数据算一下正常波动范围再设置动态基线。记住智能系统的价值不是“用标准答案卡你”而是“基于你的数据讲你的情况”。4.2 设备数据清洗逻辑数据清洗听起来很技术其实你可以理解成“把不靠谱的测量剔除掉留下可信的数据”。水质传感器长期泡在水里电极表面会附着生物膜或污物导致读数飘移线缆如果被老鼠咬破会出现随机跳变供电不稳时数据会出现周期性的异常峰谷。DuClaw 的数据清洗逻辑一般包括三步去毛刺、去重复、时间对齐。去毛刺用的是阈值法和梯度法结合。阈值法很简单超出传感器量程或者物理合理范围的数据直接丢掉梯度法更精细它看相邻两个采集点的值变化速度。比如一个传感器连续 1 分钟读数都在 5.0mg/L 左右下一瞬间突然变成 1.2mg/L30 秒后又回到 5.1mg/L这种就是明显的毛刺因为水体中溶氧不可能在 30 秒内掉这么多。平台会自动把这个“异常点”标记为坏点不参与计算。去重复是把设备重复上报的数据过滤掉。实际项目中经常有网关配置了重传机制导致同一时间点出现多条相同数据。如果不去重统计平均值时相当于给这个时间点加了权重结果会失真。时间对齐则是把不同设备的上报间隔统一到相同的时间轴上。比如温度传感器 1 分钟上报一次溶氧传感器 5 分钟上报一次分析时就需要重采样通常是以最小公倍数或固定 5 分钟窗口做聚合确保每个指标有可比性。4.3 投喂策略是怎么算出来的除了水质监控投喂管理也是养虾成本的大头饲料成本能占到养殖总成本的 40% 左右。多喂了浪费且坏水少喂了虾长不快。这个问题靠感觉很难拿捏DuClaw 里内置了投喂策略引擎本质上是把养殖老师傅的估算逻辑变成可计算的公式再结合实时数据做修正。一个常见的每日投喂量计算公式是这样的每日投饵量kg 存塘虾体重估算值kg × 投饵率% × 温度修正系数 × 溶氧修正系数 × pH修正系数其中投饵率由虾的规格决定比如 40-50 头/斤的虾投饵率大约在 3%-4%温度修正系数参考水温26-30℃ 时取 1.0低于 22℃ 取 0.7高于 34℃ 取 0.8溶氧修正系数在溶氧高于 5mg/L 时取 1.0低于 3.5mg/L 时取 0.7。这些系数都可以在 DuClaw 里配置系统会让你选择养殖品种和当前估重方式。真实项目中“存塘虾体重估算”是最难的部分。DuClaw 的做法通常是让用户定期录入抛网打样数据比如每 10 天称一次虾的平均体重平台利用这些稀疏数据结合水温、投喂量做生长模型插值估算每天的存塘总量。需要注意这个估算是有误差的我建议你在系统给的投喂建议基础上结合晚上观察虾的摄食时间来判断如果 40 分钟内饵料还有剩余下次建议量下调 5%-10%如果 20 分钟内全部吃光可以适当增加。把 AI 建议和经验微调结合起来才是比较稳的打法。5. 常见问题与排查技巧实录5.1 设备上不了线先从物理链路查起我在项目里遇到最多的一个问题就是用户在 DuClaw 控制台添加完设备后设备状态一直显示“离线”。这时候很多人第一反应是怀疑平台配置错了其实大部分问题都出在物理链路和网络链路。排查顺序应该是设备供电是否正常网线/串口是否松动网关网络是否能访问云平台设备密钥是否填对。你就把它当成一个“管道堵没堵”的问题。有一回我们排查一个数据不上的问题查了半天最后发现是传感器的 RS485 线 A/B 接反了这种低级错误虽然好笑但确实常见。另一个高频原因是网关所在的 4G 信号差上线后频繁掉线这种情况下需要在网关外接天线或者调整安装位置。如果设备显示在线但数据不上报那要查物模型属性标识符是否跟设备端上报的 key 一致。很多时候厂商固件里上报的字段是DO物模型里配的是dissolved_oxygen对不上数据就进不来。这类问题通过“设备调试”界面能很快看明白。5.2 数据抖动厉害先清洗再调阈值有朋友问过数据曲线像锯齿一样溶氧在 3.8-6.2mg/L 之间来回跳这种情况下规则是不是很容易误触发。我的建议是先别急着调阈值先把数据源问题解决。先检查传感器探头表面是否干净污染会导致电化学电极输出不稳定需要拆下来用清水轻柔刷洗再放进饱和空气或标准液校准。再看屏蔽线是否单端接地如果线缆跟增氧机变频器走得太近强电干扰会直接耦合到传感器信号上造成读数大幅波动。最后看供电电源传感器工作在 12V 或 24V 直流如果电压纹波太大数据也会异常。排除物理问题后再到 DuClaw 里开启“数据平滑”选项。常用的方法有滑动平均和中值滤波。滑动平均适合变化的趋势中值滤波更适合去除尖峰脉冲。不要过度平滑否则真实的环境突变也会被抹掉。我一般把平滑窗口设为 5 个采集点既能过滤噪声也不会让系统反应太钝。5.3 预警要么不响要么乱响预警频率太高容易让人麻木预警始终不响又让人心慌。这里我给你一个排查表直接照着看现象可能原因解决方法该触发时不触发条件中的属性名配置错误去物模型确认属性标识符是否一致该触发时不触发设备处于离线状态先恢复设备在线规则默认只看在线数据触发后不执行动作动作设备没有绑定继电器检查控制设备物模型及输出引脚配置触发后执行太慢网络延迟高把控制规则下沉到边缘网关频繁误报阈值过紧持续时间过短提高阈值或增加持续判定时间别人收到通知我没收到通知渠道未验证检查手机号/应用内绑定状态核心思路是预警不响先确认链路再确认条件预警乱响先看看是不是条件缺了“持续时间”这个保险丝。另外规则上线前一定要做一次“模拟触发”测试。DuClaw 里通常有调试入口手动填入一条模拟数据看规则是否按预期执行。连这个测试都不做就上线后面出问题会浪费更多时间。5.4 大模型答非所问关键在上下文用 DuClaw 对话时偶尔会遇到答非所问的情况比如问“今天的水质咋样”它回复了一段投喂建议。这类问题多数不是模型笨而是缺少上下文。你要么没有指定塘口要么问得太宽泛导致意图识别无法确认要查询的数据维度。解决方法是把问题说完整增加“时间地点指标”三要素。比如把“水质咋样”改成“1号塘今天下午的溶氧和 pH 变化趋势怎么样”系统准确率会明显提升。此外DuClaw 通常会提供一个“快捷问答模板”你可以把常见问题固化成模板降低误识别概率。如果现场有很多本地叫法比如“增氧机”老板习惯叫“打氧机”你可以在平台的“同义词库”里配置这种映射这样大模型就能听懂方言和俗称。做这类配置不算技术活但需要养殖户和技术人员一起梳理把本地的常用语录进去系统才会越来越“懂你”。6. 从“养虾”到“智慧水产”DuClaw 还能怎么玩6.1 DuClaw 视觉识别给虾塘装上眼睛水质只是养殖的一部分虾本身的状态同样重要。比如虾是否摄食活跃、有没有浮头、体色是否异常这些靠人去巡塘看频率低且容易漏。如果虾塘上方架设了摄像头DuClaw 可以把视频流接入视觉分析模块识别水面动静和虾的聚集情况。一个很实用的场景是“摄食行为分析”。投喂后观察 20 分钟如果摄像头拍到大量虾聚集在食台附近说明食欲旺盛如果虾很快散开、食台剩余饲料多说明投喂量偏多或水温溶氧条件不好。视觉分析系统把结果反馈给 DuClaw平台再结合水质数据修正第二天的投喂建议这样就形成了“数据视觉决策”的闭环。这个组合特别适合生态虾塘或者不便于安装大量探头的养殖模式。不过也要注意视觉识别依赖光线和水体能见度暴雨天、水体浑浊的时候效果会大打折扣。所以视觉系统最好作为辅助增强手段核心保障仍然是水质传感器和规则引擎。6.2 DuClaw 产量预测从管理塘口到管理经营当你的水质、投喂、设备运行数据积累到一段时间后就能做一些更有价值的事情比如产量预测。这个预测不是拍脑袋而是基于历史同期数据、当前存塘规格、累计投喂量、成活率和环境应激事件等因素估算出塘时的总产量和规格分布。我在实际项目里体会到产量预测最大的价值不是“算出最终数字”而是帮你提前发现风险。比如系统预测出塘时间比预期推迟了 10 天你就该反思是投喂策略偏保守还是水温过低导致生长停滞。这就是把“养虾”从体力活变成数据活的过程。当然预测模型需要足够多的数据才能收敛至少要有 1-2 造完整养殖周期的历史数据。如果你的数据积累还少可以先跑水质监控和投喂建议别急着看产量预测。6.3 给开发者和集成商的一点建议如果你不是养殖户而是想在智慧水产方向做项目我建议你先在 DuClaw 上把最小闭环跑通再考虑自研。最小闭环指的是一个设备接上来数据能查到一个规则能触发一个通知能送到。这四个环节走通你已经比市面上 80% 的 demo 项目强了。DuClaw 的 API 设计得比较开放你可以通过 Webhook 把预警消息转发到企业微信、钉钉或者自己的平台。比如在规则动作里配置一个回调地址触发时平台会向该地址发送 JSON 格式的 POST 请求你的后端服务收到后可以执行二次处理比如生成工单、通知经销商、记录审计日志。这种扩展方式很适合做项目交付因为甲方往往不满足于“平台自己有通知”还希望跟自己现有系统打通。最后提醒一句大模型生成的内容一定要在关键控制链路里加上人工确认。像“自动投喂量增加 20%”这样的建议可以由模型给但真正执行前最好还是让人点一下确认或者在规则里设置一个不超过 10% 的执行上限。安全永远是第一位的宁可在形式上多一步确认也不能让模型直接全权控制影响养殖户收入的关键设备。我自己在跑完这套流程后最大的体会是DuClaw 真正打动人的不是某个单点功能有多炫而是它把“数据”“规则”“对话”三条线拧成了一股绳。真正做智慧养殖的人都知道AI 再聪明也替代不了现场的一个细节观察但如果你能把 AI 当成一个不知疲倦的巡塘助手把风险从“事后补救”变成“事前预警”养虾这件事确实会自由很多。