兼职铲屎官前两年在湖北做项目，一个稻虾基地的老板带我上新装的中控室，屏幕上跳动着溶氧曲线、虾塘实时画面，他很得意地跟我说：“这套AI系统装完之后，我夜里终于能睡整觉了。”结果那年梅雨季一场雷暴，UPS只撑了二十多分钟，网关掉线后，增氧机控制器进入了本地应急模式，凌晨三点溶氧跌到2.1mg/L，手机才收到延迟了二十分钟的短信。他连夜捞了半塘虾，第二天见我的第一句话不是问怎么修设备，而是问：这AI到底靠不靠谱？
养龙虾这件事，只要把“AI”和“安全”放在一起，很多人脑子里冒出来的都是杀毒软件、防火墙、漏洞扫描这些词。但我这些年做智慧渔业项目下来，最大的体会是：塘口场景里的AI安全，真正的含义不是防黑客，而是防“设备掉线、数据失真、告警不到人、控制指令乱发”这一连串看着不大、却足以让一塘虾出大事的隐患。这篇文章就围绕这些隐患慢慢聊，聊清楚AI系统在养龙虾塘口到底解决什么问题，安全风险最常藏在哪几个环节，以及选国产软件和配套硬件时，应该重点考核哪些能力——也顺便把我自己用过的、觉得靠谱的国产技术栈一并分享出来。
1. 塘口装了AI，为什么还会出事故：先看清安全边界
1.1 AI养龙虾的真实工作流程
很多人以为“AI养龙虾”就是一个摄像头加一套软件，能自动识别虾有没有病、水好不好。实际上，一整套能安全运行的AI养殖系统，至少要拆成四个环节：
- 感知层：溶解氧探头、水温探头、pH探头、氨氮探头、水下摄像头等，负责把塘口的环境状态变成数字信号。养龙虾最关键的两个指标是溶氧和水温，溶氧低于3mg/L时虾会开始浮头，低于2mg/L时可能出现大面积死亡风险。
- 传输层：传感器数据通过RS485总线、LoRa、4G或者网线汇集到边缘网关，网关再通过4G/光纤送到服务器或云端。这个环节最容易出问题，因为塘口环境潮湿、雷击频繁、供电不稳，任何一环断开，数据就断了。
- 计算层：数据到达本地AI盒子或云端后，由算法模型完成水质趋势预测、虾的活性分析、摄食行为识别等任务。这里的“AI”一般是用历史数据训练出来的模型，输入当前实时数据，输出未来一段时间的风险提示。
- 执行层：当判断达到某个阈值时，系统自动或半自动地控制增氧机、投饵机、进排水阀门等设备动作。这一层直接接触物理世界，一旦控制逻辑出错，后果最严重。
安全问题的根源恰恰在于：这四个环节必须同时在线、同时准确，才能真正兜住养殖生产的底线。而大多数事故，都是某个环节出现了一个“小毛病”，然后被其他环节的正常运转掩盖了，直到最后一刻集中爆发。
1.2 多数人理解的“安全”和真实风险点错位
我接触过的养殖场老板和基地管理者，对AI系统安全的理解通常有两类。一类觉得，AI安全就是要防止系统被别人黑，怕的是“黑客把我的增氧机关了”这种极端场景；另一类觉得，我的设备都在本地，数据不上云，那肯定安全。
实际上，塘口项目里真正高概率发生的事故，往往是这几个：
- 雷击把网关网口打坏，后台没有任何感知，只看到设备离线，但离线告警没配置成电话通知，于是整整一个晚上没人知道。
- 传感器探头没有定期校准，溶氧数据从3.0mg/L漂到了4.2mg/L，AI模型基于错误数据给出“水质正常”的判断，控制逻辑自然也不会启动增氧机。
- 运营商基站故障，4G网络中断，网关本地缓存容量不够，断线期间的数据全部丢失，AI重新上线后基于残缺数据做预测，结果一整天都在误报。
- 控制指令没有双确认机制，某个员工在App上误触了“关闭增氧”按钮，设备立刻动作，但系统没有给场长发确认通知。
这些问题，哪一个都不是“被黑客攻击”造成的，但造成的损失一点不比网络安全事故少。所以，给养龙虾场景做AI安全方案，首先要调整视角：安全不是一块杀毒软件能覆盖的，它是一条从传感器到人的决策链条，链条上任何一个环节断掉都不安全。
1.3 一个典型的“安全真空”事故拆解
继续说我开头讲的那个湖北基地。当时那套系统并非没有冗余设计，网关配了UPS，增氧机控制器也有本地自动启停逻辑。但事后排查发现了好几个叠加问题：
第一，网关的UPS设计容量只考虑了网关和路由器本身，忘了把外围的传感器集中供电箱算进去。雷暴导致市电中断后，传感器集中供电箱的电源适配器先撑不住，传感器全部断电，而网关的UPS还在工作，后台显示网关在线，却收不到任何实时数据。平台界面上一片正常，因为系统把“网关在线”当成了“系统在线”，没有对数据新鲜度做单独检测。
第二，溶氧跌落触发的是平台短信告警，但短信网关依赖第三方接口，暴雨导致服务器出口网络拥塞，短信排队二十多分钟才发出来。等场长看到短信，又花了几分钟从住处跑到塘口，增氧机虽然能自动启动，但启动前溶氧已经跌破了危险线。
第三，控制器的本地应急模式设置的是“当溶氧低于2.5mg/L，自动启动增氧机”，然而该批设备断电重启之后，回读到的传感器数据是缓存值，控制器判断溶氧“暂时安全”，没有第一时间启动增氧。直到平台重连、真实数据刷进来，应急模式才被激活。
这个案例说明，一套看似齐全的AI系统，安全边界并没有想象中那么宽。真正的安全，需要在设备侧、平台侧、告警侧和人的操作习惯上共同补齐。理解了这一点，下面谈误区和选型才有意义。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 四个流传很广的安全误区，每个都要有纠偏
2.1 误区一：传感器越多越高级，AI就越安全
几乎所有花钱买智慧养殖系统的客户，第一个要问的都是“你们能接多少路传感器”。似乎传感器数量越多、探头型号越贵，系统就越安全。但我在项目现场见过太多反例：塘口装了七八路溶氧探头，却没有一套定期清洁校准制度，用了三个月，探头表面附着藻类和污泥，数据偏差越来越大；还有的客户为了省钱，把多个探头串在手拉手的RS485总线上，线缆接头防水没做好，下雨后整条总线上所有数据全部跳变。
更麻烦的是，AI模型对输入数据质量非常敏感。如果传感器数据本身就不准，模型会把这些脏数据当成真实状态去学习、去预测，然后给出一个非常自信但完全错误的结论。这就是所谓“垃圾进，垃圾出”。
正确的做法是给数据质量单独建一套监控逻辑。比如溶氧探头每隔一段时间要自动比对一次相邻探头数值，两个探头读数差超过0.5mg/L时，系统应该标记该数据源为可疑状态，而不是继续采信。传感器不能只追求数量，更要考虑供电独立、探头安装位置、校准周期和故障自检。
2.2 误区二：数据不上云就等于安全，本地化越彻底越安全
很多养殖场老板对“上云”这件事有天然顾虑，担心塘口数据——包括投喂配方、产量统计、客户订单——被平台方看到，就选择“绝对本地化”方案，所有数据只存在本地服务器上。这种心态可以理解，但“不上云”不等于“安全”。
本地化部署有一个容易被忽略的致命问题：单点故障。塘口所在区域夏天雷雨多、电压波动大，一台本地服务器的硬盘、电源、主板随时可能出问题。如果没有做异地备份，一旦服务器损坏，意味着历史数据全部丢失，AI模型连重新训练的基础数据都没有了。
安全的数据策略应该按敏感度分级，而不是一刀切。实时环境数据（水温、溶氧）这类低敏感度数据，可以借助云端平台做趋势分析和多人远程查看；设备控制日志和操作记录，必须保留在本地并定期加密归档；经营数据如产量、售价、客户信息，则要做更严格的权限管控，并且至少有一份异地的加密备份。比较稳妥的方式是“边缘本地为主、云端备份为辅”，核心控制逻辑放在本地边缘网关，历史数据通过加密通道同步一份到私有对象存储或云端。
2.3 误区三：AI预警响了，人就能放心去睡
AI预警系统的价值，确实在于把养殖户从“守塘”这件事里解放出来，但很多人会走向另一个极端：认为上了AI系统，夜里就可以安心睡大觉，甚至把巡查频率从每晚三四次降到了一周两次。
这里必须说清楚：AI预警不是保险箱，它只是一个把风险发现时间提前的工具。预警响了，不代表风险已经被处理了，只代表系统认为某个指标正在朝异常方向走。真正决定是否出事的是人对这个预警的响应是否及时、动作是否正确。
我见过一个做得比较好的基地，他们设定了一套告警升级机制：第一级预警（溶氧低于3.2mg/L）推送到值班员微信；十分钟内如果没有确认，自动电话呼叫值班员；如果二十分钟后溶氧继续下跌，系统自动升级呼叫场长，并启动增氧机。所有告警记录都会留痕，第二天早会上复盘。另外，他们每个月还会做两次“假告警演练”，人为触发一个测试事件，检验告警链路是否畅通、值班员是否能在规定时间内响应。这套机制的存在，才让AI预警真正变成了安全兜底手段。
2.4 误区四：软件系统装完一次，后面就不用管
任何一个在传统养殖行业里推过数字化系统的人，都会遇到一个共同问题：验收之后，系统就没人维护了。国产软件服务商把系统交付完，项目组撤走，后面设备漂移没人校，平台版本不升，算法模型还是半年前的参数。几个月后再打开后台，看起来一切正常，实际上一堆功能已经在悄悄失效。
这里不全是服务商的锅，甲方也有责任。很多养殖基地把软件系统当成“一次性的硬件设备”，买回来插上电就能用一辈子。但AI系统的特点决定了它必须持续喂数据、持续调参、持续迭代。我建议在采购合同里就要明确三件事：数据导出的格式和频率、模型参数更新的次数、支持响应的时间等级。如果服务商连“数据能不能完整导出”都含糊其辞，那这套系统越用越容易被“绑架”，后期安全根本无从谈起。
3. 考察国产软件时要盯住的四个安全能力
3.1 设备侧：AI盒子不是越便宜越好
塘口AI系统里，边缘计算盒子负责在本地跑模型推理和规则引擎，相当于整个系统的“大脑中继”。市面上的AI盒子很多，从几百块的树莓派方案到数千元的工业级边缘计算设备都有。如果只看价格，很容易买到不适合养殖场景的产品。
养殖塘口的AI盒子至少要满足几个条件：一是宽温设计，南方夏天机柜温度可能超过40度，北方冬天可能低于零下，消费级设备很难扛住；二是防护等级，机柜进水、潮湿凝露是常态，接口需要做防腐蚀处理；三是支持断网续传和断电自恢复，不能出现一次断电后设备起不来、要人工去现场重启的情况；四是推理能力要不依赖公网，至少本地能跑一个轻量模型，比如溶氧预测或虾的密度估算。
在国产芯片方案里，瑞芯微RK3588系列算是目前用得比较多的一款，算力足够跑轻量级视觉模型，价格适中，国产化程度也高。团队不想自己折腾的话，可以找基于RK3588做了工业级外壳和看门狗方案的AI盒子厂商，重点问清楚是否有硬件看门狗、系统是否支持远程升级、历史数据本地存储的容量有多大。
3.2 通信链路：数据不能断在塘口
很多AI系统出事，不是算法不行，而是数据链路先断了。塘口的通信链路比办公楼复杂得多，涉及传感器总线、网关到云端的公网、云平台到手机App的下行链路，每一段都要考虑容错。
先说传感器总线。RS485是水产养殖行业最常见的传感器接口，但它的缺点是设备一多、距离一长就容易受干扰。建议采用分段隔离加终端电阻的接法，并在网关侧加TVS管防浪涌，避免雷击时高压沿着总线打坏一排传感器。
再说网关到云端的链路。这里最稳妥的是支持多链路的网关，比如4G作为主链路，有线宽带作为备用链路，或者一主一备两张不同运营商的SIM卡。网关要支持MQTT QoS 1或至少QoS 0加本地缓存，网络断开期间数据先落本地，恢复后按时间戳补传。通信加密方面，TLS是标配，但要特别注意证书过期问题。我给好几个项目做运维时都遇到过：设备刚部署时好好的，半年后证书过期，设备全部连不上平台，而现场根本没人记得要更新证书。选择支持自动续期证书的方案，或者用双向认证加自建CA管理，能省掉很多麻烦。
3.3 算法可信度：AI模型不是万能的“老师傅”
讲AI就绕不开模型。很多软件厂商在推销时会说自己的AI模型“经过几十万张图片训练”“准确率超过98%”，但养殖户往往忽略了一个问题：这98%是在什么条件下测出来的？
我见过一个识别虾摄食行为的模型，在演示环境里效果很好，但换到水质浑浊、光照不足的塘口，识别直线下降。原因是训练数据大多数来自清水池，而实际塘口普遍浑水、有浮游生物、光线条件复杂。这种“场景泛化能力不足”的问题，在任何AI系统里都可能存在。
所以，评估算法可信度时不要只看演示指标，要问三个问题：模型是在哪些塘口、什么水质条件下采集的数据训练的？如果现场环境跟训练环境差异很大，模型效果会打几折？模型能输出不确定性吗——比如识别结果为“不确定”而不是强行给一个判断？
更安全的做法是让AI和规则引擎分工：AI负责预测趋势和识别异常模式，规则引擎负责兜底关键时刻。例如，AI预测未来一小时溶氧会低于3mg/L，系统提前提醒增氧；但真正到溶氧跌破2.8mg/L这个硬阈值时，不需要AI判断，规则引擎直接触发增氧机。这相当于把“经验丰富的老手”和“严格执行的机器”结合起来，哪怕AI判断错了，规则兜底也能保证不出现极端事故。
3.4 平台侧：国产化不只是“软件名字是中文”
近几年国产化替代是一个大趋势，养龙虾的智慧养殖系统也越来越多地强调“纯国产”。但我的建议是：不要只看软件界面上写的是中文品牌，要看它底层技术栈是否真的可控。
有些系统号称国产化，实际上只是套了个国产界面，底层依赖的数据库、消息中间件、AI框架都是闭源商业组件，一旦服务商出问题，你可能连数据都导不出来。判断平台可不可控，可以从这几个角度考察：是否支持部署在自己的服务器上；数据库导出格式是否开放；API文档是否清晰；如果服务商倒闭，系统能不能继续运行，数据能不能迁移到其他平台。
我在这几年的项目里比较常用的国产开源组合是这样的：物联网接入层用EMQX——这是国产开源MQTT消息中间件，设备接入和断线重连机制都很成熟；业务平台层用JetLinks——国产开源物联网基础平台，支持设备管理、规则引擎和数据可视化，能私有化部署；AI模型部分用百度飞桨PaddlePaddle生态，PaddleDetection做虾类目标检测，训练完成后可以导出为RKNN格式部署到瑞芯微的端侧设备上；数据存储方面，轻量场景用MySQL或PostgreSQL，量大一些的时序数据可以接TDengine，这些都是国内社区非常活跃的方案。用这套组合的好处是：没有哪个环节被某个商业云平台锁定，数据都在自己手里，预算够就找服务商做落地，预算少就自己学着自己搭。
4. 可以照抄的开源工具组合与部署建议
4.1 JetLinks：国产开源的物联网基础平台，适合长期自持
JetLinks是我在智慧养殖项目里用得比较多的一套国产开源物联网平台，基于Java开发，设备接入、产品模型、规则引擎、告警中心这些功能都齐。最让我看好的一点是它支持完全私有化部署，数据可以全部落在一台本地服务器上，也可以把设备接入层放云端，业务层放本地。
它在塘口项目里的作用可以这样理解：每一台溶氧探头、每一个增氧机控制器都先注册到JetLinks的设备列表里，平台负责维护设备的在线状态、上报属性和下发指令。规则引擎可以配置一些基础联动逻辑，比如“溶氧连续三次低于阈值，自动给指定手机号发通知”。相比纯自研一套平台，JetLinks能省掉大量基础工作，而且因为开源，后期想改逻辑，企业自己养一个开发就能维护。
使用JetLinks时有一点要注意：它的规则引擎更适合处理“中等复杂度”的规则。如果塘口控制逻辑非常多，比如几十个塘口、几百个设备、规则之间有依赖关系，建议把核心控制规则放到边缘网关来跑，JetLinks只做数据汇聚、展示和上层业务管理。不要把平台的规则引擎当成实时控制中枢，一旦平台宕机，底层控制就瘫痪了。
4.2 EMQX：解决设备接入“同时在线”和“断线重连”的稳定问题
养龙虾的塘口设备数量不算多，但连接质量非常不稳定，因为网络环境差、IP变化频繁、信号时好时坏。这种情况下，MQTT协议几乎是最合适的选择，而EMQX作为国产开源消息中间件，在这一领域口碑很好。
EMQX最吸引我的是它的断线重连和会话保持机制。设备端和Broker之间的连接断开后，EMQX可以根据遗嘱消息判断设备是否异常下线，并通过保留消息保存设备最新状态。新设备上线后，可以立刻拿到当前状态，不用等下一次上报。而且EMQX的集群扩展能力很强，即使将来从几十个塘口扩展到几百个，也不需要把架构推倒重来。
实际部署时，EMQX可以装在云服务器上，也可以装在本地服务器上。对于数据敏感的项目，我倾向于在两处都装：云端EMQX负责远程监控终端连接，本地的JetLinks使用内置规则直接跟边缘网关走内部MQTT通道，两者通过桥接模式同步必要数据。这样外网断了，本地系统照样能跑。
4.3 飞桨PaddlePaddle：从训练到端侧部署的一条国产AI链路
AI模型部分，我选择百度飞桨PaddlePaddle生态，主要原因是它在国产硬件适配方面做得比很多海外框架更顺。在养龙虾场景中，常见任务包括：水下视频里虾的检测与计数、投饵时虾的聚集活跃度分析、塘口水面异常漂浮物识别等。这些任务在飞桨里基本都能找到现成的模型库和训练脚本。
以虾的目标检测为例，用PaddleDetection里的PP-YOLO系列模型，在几千张标注好的图片上微调，一般能达到可用的效果。飞桨的优势在于它对硬件部署非常友好，模型可以导出成静态图，再通过Paddle2ONNX或者直接导出RKNN格式，跑到瑞芯微RK3588等国产边缘芯片上。这样从训练框架到推理硬件，整条链路都可以不依赖海外闭源生态。
当然，飞桨的学习曲线还是存在的，不是所有养殖团队都能直接从零训练一个模型。我建议这样分工：如果只想用现成能力，可以找做智慧养殖算法服务的公司，让他们用飞桨帮你定制；如果团队里有一个懂Python的工程师，可以考虑自己先拿公开数据集做一轮目标检测训练，跑通整个流程后再喂真实塘口数据迭代。这条链路最大的好处是可控，后续想调整模型结构、想换数据集重新训练，都不会被某个软件厂商卡住。
4.4 商业SaaS与私有化部署该怎么权衡
开源组合适合愿意投入学习成本、对数据自主性要求高的团队。但现实中，很多养殖基地根本没有专职IT人员，这时候硬上开源平台，后期维护难度会很高。对于这类用户，我更建议选择成熟商业SaaS或工业软件，但要按下面几条标准来筛：
第一，数据能不能备份出来。商业SaaS平台多半会把数据存在他人的服务器上，这不必然是坏事，但你必须确保能拿到自己的历史数据。合同里要写明支持导出Excel、CSV、开放API接口，且不能收取不合理的数据导出费用。
第二，离线可用性。塘口不是机房，网络随时可能出问题。问清楚SaaS平台的告警下行是否支持短信/电话方式，能不能脱离App独立工作。如果手机没信号，告警还能不能送达？如果全部都依赖网络，那这套系统的安全边际非常低。
第三，私有化版本是否真实存在。很多商业SaaS声称支持私有化部署，但实际上只是把软件安装包丢给你，没有配套的部署文档和运维支持。买之前最好先让服务商在你指定的服务器上跑一次演示环境，确认不是“口头私有化”。我见过不止一次，客户买了所谓私有化版本，结果连基础的数据初始化都没人负责，最后项目烂尾。
5. 最小可用闭环的安全设计：从传感器到操作员确认
5.1 网络怎么组：三层隔离不是IT系统专属
养龙虾塘口面积往往很大，设备分布在池塘边、工具房、办公室等多个位置，网络设计如果图省事，很容易埋下隐患。我推荐一个比较稳妥的三层隔离结构：
第一层是设备内网。所有传感器、控制器、摄像头都接在独立的设备局域网里，地址段跟办公网络完全分开。设备网里只允许边缘网关主动访问，云平台不能直接反向访问设备。第二层是边缘网关层。网关负责协议转换、数据缓存、本地规则判断，是整个系统的核心节点，要放在防水防尘的电控箱里，并配独立电源和防雷模块。第三层是外部网络层。网关通过4G或光纤访问云端平台，平台下发控制指令时，也先到达网关，再由网关转发给设备。所有执行动作都通过网关层做一层校验，不允许设备裸露在公网IP上。
这么做的好处是：就算云平台被攻破，攻击者拿到的只是网关的对外接口，无法直接控制塘口设备；即使设备内网出现问题，也只是局部网络异常，不会影响办公网络和整个基地的管理系统。
5.2 数据要分几类：不同数据用不同安全策略
在数据管理层面，我习惯把养龙虾AI系统产生的数据分成三类：
第一类是实时环境数据，包括水温、溶氧、pH、氨氮、摄像头画面。这类数据实时性要求高、敏感度低，可以走公网传输，放到云端进行多塘口比较和长时间趋势分析。第二类是控制操作数据，包括每一次增氧机启停、投饵机动作、用户操作记录。这类数据直接关系人身和设备安全，必须至少保存在本地数据库中，操作日志要保留操作人、时间、设备、结果、IP来源，不能删除。第三类是生产经营数据，包括放苗密度、饲料配方、产量、销售价格和客户信息。这类数据对基地经营非常重要，需要高强度加密存储，访问必须走权限控制，并定期做异地备份。
数据分类清楚之后，再设计数据库表结构、接口访问权限和备份策略，思路会清晰很多。不要把所有东西一锅烩地存到一个库里，安全性和后期维护效率都会大打折扣。
5.3 模型和规则怎么协同：先用规则兜底，AI做预测
在AI系统落地的初期，我强烈建议不要直接把AI的预测结果作为设备自动控制的唯一依据。原因很简单：你还不确定模型在这个塘口、这种水质、这个养殖周期里表现是否稳定。贸然让AI全权接管控制，一旦模型误判，后果可能比不用AI还严重。
比较稳妥的协同机制分三步走：
第一步，规则兜底。用硬阈值规则作为最底层安全网，例如溶氧低于2.8mg/L强制启动增氧机，投饵机不允许在特定天气条件下自动投喂，进排水阀门每次动作前必须检查水压和设备状态。这些规则不依赖模型，逻辑简单可靠。
第二步，AI预警。利用历史数据和实时数据训练模型，预测未来三十到六十分钟的溶氧变化、虾的活跃度变化、异常摄食行为。AI的输出是“预测”而不是“命令”，系统提前把风险推送给管理人员，给他们留出人工处理时间。
第三步，人工确认闭环。当AI预测某个塘口即将出现低氧风险，系统将建议操作推送界面给值班人员，由值班人员决定是否提前开启增氧。只有在系统运行三个月以上、积累的预测准确率得到验证后，才考虑将部分低风险动作改成自动执行。
5.4 告警闭环：电话、短信、通知、浏览器推送全打通
告警是整个安全体系里最容易被忽略、也是最考验细节的一环。很多系统所谓的告警，就是在App里弹一条中心通知，但塘口的工作人员经常不开App，远程管理人员也不可能一直盯着手机。
我逐步测试下来的可靠推送顺序是：首选电话语音告警，用语音播报告诉值班人员具体塘口和具体指标，因为电话能最大限度打断人的注意力；其次短信，适合不需要立刻处理但需要留痕的通知；再次是企业微信/钉钉群机器人推送，适合把信息同步给多人；最后才是App推送。告警策略里要加入“确认”动作：值班人员收到告警后必须在系统里点击“确认”，否则系统默认他没看到，自动升级到上一级负责人；如果升级后仍然没人确认，再触发电话呼叫。这样层层递进，虽然实现起来比单纯发一条推送复杂，但实际救援效果差别很大。
6. 我在实际项目中踩过的一些坑
6.1 备用电池被高估，雷雨季最需要做满载测试
开头提到的湖北案例里，网关UPS厂家标称续航30分钟，但实际满载功耗下只撑了二十多分钟。关键问题在于，厂家标称的是“网关主机功耗”下的续航，而现场实际接了光电转换器、传感器集中供电模块、还有一路用于远程管理的工业路由，整套负载电流比标称值高出一大截。
解决办法是现场做一次满载断电测试，把所有设备都接上，人为断电后记录实际续航时间。不要只听厂家宣传，也不要只测网关单机。雷雨季节之前，至少每个月做一次断电续航测试并记录变化曲线。电池容量是逐渐衰减的，等到真正断电才发现撑不住，那就晚了。
6.2 同一套软件对不同批次设备固件的兼容性差距
有一次项目里遇到一个很诡异的问题：同一型号的溶氧探头，一部分数据显示正常，另一部分数据每隔几分钟跳变一次。排查了很久，最后发现原因让人哭笑不得：经销商发过来的两批探头虽然外观一样，但内部固件版本不同，Modbus寄存器地址有细微差异，读取代码按旧版本的寄存器地址去解析，新版本返回的数据自然对不上。
这个坑的教训是：系统集成时必须建立设备固件版本台账，每批次设备进场都要先做一次协议一致性测试，再接入正式系统。不要在设备装好后才测试，更不要随意混用不同批次固件的同型号设备。很多国产设备的固件升级比较随意，厂商可能在一个月内改了好几个版本，如果没有可靠的版本管理机制，系统越跑越乱。
6.3 算法模型被养殖密度“带偏”的教训
飞桨训练虾目标检测模型时，我用了一批低密度清水池的视频数据做预训练，当时测试效果不错，第一批部署到基地也还可以。但到了养殖后期，虾的密度增大、水体变浑浊，模型识别率明显下降。原因是训练数据里“虾密集叠加”的样本太少，模型没见过这种场面，特征提取就乱了。
后来我们把老塘口和高密度塘口的视频数据重新标注了一批，加入训练集做二次微调，识别率才恢复。从那时起我给自己定了一条规矩：任何视觉模型的训练集必须覆盖不同养殖阶段、不同水质条件、不同光照情况，至少要保证每种典型场景有足够的样本。模型上线后也不能一劳永逸，每个养殖周期结束时要复盘一次预测误差，用新的场景数据更新模型。
6.4 国产软件服务支持的真实体验
选国产开源软件最大的好处是自主可控，但也得接受现实：很多开源项目没有面向最终用户的技术支持，遇到问题得自己在社区里翻帖子或者付费找外部团队。所以我一般会给客户两个选择：如果自己团队没有技术能力，宁愿找一家专做智慧渔业的系统集成商，用商业支持换省心；如果团队里有两个能写代码的人，建议采用开源组合，长期来看性价比更高，也能避免被单一软件厂商绑定。
有一次我们帮一个基地把原有SaaS平台的设备数据通过API导出，再迁移到JetLinks自建平台上，整个过程花了近两周，主要时间都花在清洗历史数据和映射设备属性上。这件事提醒我，从项目第一天起就应该把设备命名规范、数据上报格式和用户权限体系定义清楚，不然后面做平台切换时，历史数据迁移会比重新部署一套系统还痛苦。
最后再说一个我在每个项目里都会强调的习惯：无论选择哪家国产软件，都要把“系统如何交回给使用者”当作验收的一部分来做。真正的安全，不只是服务器和数据链路的安全，更是让养虾人每天愿意打开系统、看懂告警、按流程操作的安全。这套设备和技术再先进，如果最终没有被现场的人接受和信任，那就只是一堆昂贵却无人维护的电子垃圾。