智慧农业最后一百米:破解乡村数字化落地的设备与运维难题
做了快八年农业数字化项目我最深的一个体会是智慧农业真正难的从来不是算法有多高级、传感器有多精密而是怎么让技术在没有网线、没有专职IT人员、甚至不少农户只用老年机的村子里持续稳定地转起来。前段时间复盘了一个扎根基层的助农服务网络在乡镇场景里做数字化落地的事情正好把“最后一百米”这件事讲透了。这套体系不追求大而全重点放在数据怎么采、设备怎么维护、农户怎么愿意用这三件事上。对做乡村数字化、智慧农业设备、基层服务网络的朋友来说里面很多踩坑和补坑的细节值得拿出来聊聊。1. 智慧农业为何卡在“最后一百米”1.1 设备下乡后的真实落差很多智慧农业项目在方案书里非常漂亮大屏上实时跳动着气象、墒情、虫情数据鼠标一点就能远程控制灌溉。但项目一落地尤其是到了丘陵地带的村子现实很快会给你上一课。我见过一个真实的试点片区上线三个月后设备在线率掉到了六成以下。也不是设备质量差就是没人管、管不过来。气象站被鸟在超声波风速仪上搭了窝土壤墒情传感器的地线被野兔啃断太阳能板被落叶和鸟粪糊住导致供电不足还有的设备因为基站信号弱数据积压在本地缓存里一积就是好几天。这些故障放在城市机房根本不是问题机房有恒温恒湿、有专职运维、有备用电源但在田间地头一个传感器坏了可能半个月都没人发现。而一旦农户发现“这个系统好像不太准”“设备坏了也没人管”信任感就会急剧下降后面再想推广任何功能都很难。所以做乡村智慧农业第一个要转变的思路是不要按“机房思维”来设计系统要按“露天环境无人值守低教育成本维护”来设计系统。1.2 乡土场景的三个隐藏约束在乡镇做数字化有三个约束条件是坐在办公室里写方案的人很难想象到的。第一个是网络。村里并不是完全没信号而是信号非常不稳定。很多地块处于山谷、山腰位置4G信号只有一两格更不要说WiFi覆盖。你没法假设所有设备都能实时在线也没法假设农户的手机每次都能流畅打开App。所有设计必须支持离线优先先存在本地等到有信号了再批量上传。第二个是人。现在留在村里种地的主力是五十岁以上的农户智能手机操作水平普遍有限。你做一个功能丰富的App界面按钮再多他们根本找不到入口。很多时候“会用”不是靠阅读理解而是靠别人手把手教几遍或者照着图片一步步操作。培训不能只发一份PDF必须有大字版手册、短视频教程、现场演示缺一不可。第三个是利益结构。智慧农业要采集数据但在乡土社会里数据天然带有敏感性。农户对“我的地数据被拿去做什么”是有戒心的。所以系统在设计时要主动把采集范围限定在生产环节的必要数据上比如土壤湿度、气象、农事记录并且要让农户清楚知道这些数据是给自己看的是帮忙算浇水和施肥的而不是拿去和别人比的。这个信任问题比技术问题更难解决。正是因为这三个约束直接把城市或大农场的智慧农业方案搬到乡镇十有八九要翻车。2. 从顶层设计到基层落地底层逻辑与模式选择2.1 为什么不能照搬大农场的智慧农业方案大农场的智慧农业是什么玩法几千亩连片土地配备专职农机手和农业技术员有稳定的电力和网络可以上云边协同、AI病虫害识别、自动驾驶农机。这些硬核技术上马没问题因为有人维护、有成本分摊、有规模效应。但小农户是什么情况地块小且分散一家三五亩地东一块西一块。你不可能在每块地都部署全套智能设备成本根本摊不回来。更现实的是农户需要的是“什么时候浇水、什么时候打药”这种非常具体的提醒而不是一个大屏上的数据曲线。打个比方联合收割机在大平原上效率极高但你不会拿它去开垦山上的菜园子。乡镇场景需要的是轻量、便宜、皮实、能离线跑、坏了能快修的工具。所以这套助农服务网络当时定下的设计原则很明确设备只选低成本、低功耗、易安装的型号数据能用耐用的传感器测就不上高成本的设备交互能简则简凡是需要专业知识才能看懂的功能一律砍掉。2.2 “平台本地服务站长”的双层架构逻辑真正让我觉得有价值的设计是“平台本地服务站长”的双层架构。平台侧负责数据中台、远程设备告警、离线数据接收、统一知识库和农户小程序后台。云端做的事情主要是三类一是把分散在各地设备上报的数据汇总、清洗、存储二是根据阈值规则生成告警比如土壤湿度过低提示灌溉三是生成简单易懂的农事建议和统计报表。本地侧则设了一个角色叫“片区服务站长”。这个站长不是外包工程师通常是在当地有威望、懂农业、会简单使用智能手机的人比如农资店店主、种植大户、返乡青年。平台远程监控发现设备离线生成工单推给站长站长就近去现场检查太阳能板是不是被挡住了线缆是不是被动物咬了传感器是不是进水了这些常见小故障站长都能处理。处理不了的再通过视频连线让平台技术员远程指导或者寄回维修。为什么一定要用本地人因为数字化系统的维护本质上是服务而服务需要距离近、响应快、沟通顺。一个外地工程师坐高铁过来修一个传感器来回成本比传感器本身还贵。而本地站长骑着电动车二十分钟就能到田里而且他懂方言、懂人情能进得了农户的门农户也愿意听他的话。这个“最后一米”的信任关系远程系统替代不了。2.3 轻量化数字底座设计底层架构确定后数字底座怎么设计有几个关键取舍。数据模型不要一上来就搞复杂的GIS地图和三维地块建模。先把“地块、作物、设备”三个核心对象管好每个地块有名称、面积、种植作物每个设备绑定到地块每个地块关联农事记录。这套模型足够支撑绝大多数乡镇场景。通信方式也要因地制宜。单点传感器直接走4G如果信号不好就通过低功耗短距协议先汇聚到一个信号较好的网关再由网关统一上传。所有终端必须支持本地缓存和断点续传数据没传上去不能丢等网络恢复后按时间戳补传。这个设计在信号差的山区尤为关键。云端功能上第一版不要做大屏可视化。大量项目死在“大屏做得很炫但业务没跑通”上。真正先做的是三件小事告警工单系统、巡检打卡系统、农事记录系统。这三件事直接对应“设备坏了怎么处理、站长干了什么活、农户做了什么事”是运营闭环的地基。3. 核心环节实操拆解软硬一体怎么落地3.1 硬件选型与布点策略设备选型上我的经验是不要追求参数最好而要追求“在恶劣环境里活得更久”。以土壤墒情传感器为例市面上有电容式和张力计式。电容式便宜、响应快但长期埋在土里容易受盐碱影响漂移张力计式更稳定但价格偏高、维护麻烦。乡镇场景我建议选电容式里口碑稳定的型号配合定期校准性价比最高。气象站方面超声波式风速仪比机械风杯式更耐用没有活动部件就不容易被鸟搭窝、被杂物卡住。虫情测报灯要选拍照式而不是计数式因为拍照后人工后台看图确认更靠谱计数式误报率太高会把农户的信任感消耗光。布点密度也有讲究。墒情传感器不是越多越好一个五十亩以内、地形差异不大的片区布置三到五个点就够用了关键点是放在不同坡向和灌溉条件的代表性位置。气象站覆盖范围大一个村子一台基本够但要避开建筑物和树木遮挡。虫情测报灯放在田边通风处离作物不要太近否则灯光本身会干扰病虫害的自然分布。供电是个容易被低估的坑。田间没有市电几乎全靠太阳能板加蓄电池。一定要按“连续七天阴雨还能运行”来配电池容量因为南方梅雨季、北方连阴天都可能超过一周。太阳能板安装角度要按当地纬度调整还要加装防鸟刺否则鸟粪一糊发电效率直接掉一半。3.2 数据采集与人工协同设备自动采集的数据解决的是“环境怎么样”的问题但农业决策还缺另一半人在田间做了什么。比如你从墒情数据发现土壤变干了可以提醒农户浇水但“什么时候浇了水、一亩地用了多少水、什么时候施了肥、用了什么肥”这类信息机器测不出来只能靠人记录。这套系统专门设计了一套人工补录机制农户或服务站长在小程序里用选择题加拍照的方式快速记录农事操作。选择题就是为了降低录入门槛比如施肥类型直接给几个选项用量可以滑动选择区间再拍一张肥料包装袋的照片后台就能拿到结构化的农事记录。乍一看这好像是个很笨的办法但实际跑下来非常有效。补录的数据和环境数据一结合才能回答“灌溉提醒到底有没有被执行”“施肥后土壤养分变化趋势是什么”这类问题。没有人工补录所谓智能决策就是空中楼阁。自动采集和人工补录之间要有明确分工自动采集管高频变化比如温湿度每三十分钟测一次两小时上传一次人工补录管低频事件只在农户实际操作时发生。这样既不会漏掉关键信息也不会让农户觉得每天都要打卡、用起来太累。3.3 农户端交互的关键细节给农户用的小程序交互设计和城市互联网产品完全是两套逻辑。城市产品追求效率恨不得三步完成操作农户端追求的是“简单到不可能点错”。第一所有字体不小于十八号关键按钮更大不搞扁平化设计按钮要有明显的立体感因为视力不好的老人需要明确的“这是一个可以按的实体按钮”的视觉提示。第二所有操作入口配示意图。不是插画而是用当地真实作物的照片比如“记录施肥”就放一张手拿肥料袋的照片农户一看就知道点哪里。第三重要告警不用App推送而是语音电话外呼。很多农户的手机常年不装App、不登录甚至不会看通知但电话一定会接。灌溉提醒、霜冻预警这类关键信息用电话语音播报最稳妥效果比一百条推送都好。第四离线可用。农户到田里干活时经常没有信号小程序要支持先填写、保存到本地到家有WiFi时再自动上传。绝对不能因为“网络异常”就把表单卡住那会直接劝退用户。第五账号体系不要复杂。一个家庭一个账号不分多个角色权限登录用手机号加验证码或者干脆扫站长提供的二维码直接进入。乡镇用户记不住密码更不可能记住“账号加密码加验证码”的组合。4. 从试点到复制完整实施流程与关键节点4.1 试点片区选择标准与准备清单这套系统如果一上来就全面铺开大概率会失控。正确做法是先选一个条件合适的片区作为试点把流程跑通、坑都填完再往外复制。试点片区怎么选我总结出几个标准第一有相对成规模的产业基础比如连片种植的果园或大棚这样设备利用率高、数据价值明显第二交通还算便利不能选那种进村要开一小时盘山路的极端地方否则运维成本会拖垮早期项目第三有愿意配合的带头人比如村内的种植大户或农资店主这个人就是未来服务站长的种子人选第四当地4G网络不能完全空白至少有一个信号较好的位置可以放网关。选好试点后准备工作要有一个明确的清单地块清单编号、面积、作物类型、管理人设备清单型号、数量、安装位置、SIM卡号现场勘察表光照情况、信号强度、动物活动痕迹培训签到表以及紧急联系人通讯录。这些看起来是很基础的东西但前期不做好后面数据对不上、设备找不到位置、故障没人联系各种混乱都会冒出来。4.2 上线前培训和试运行的关键步骤培训不是讲一遍PPT就完事而要分对象、分内容、分层次来做。对服务站长培训重点是设备巡检和简单故障处理内容要包括太阳能板清理周期、线缆检查方法、传感器状态灯的读法、设备离线后的排查顺序以及如何在小程序里提交工单。对农户培训重点不是教他们用手机而是让他们理解这套系统能解决什么具体问题。比如什么时候该浇水系统会打电话提醒农田气象数据每隔多久更新可以在小程序里查看。培训材料一定要是实物大字版操作卡片、十分钟以内的短视频教程、现场演示设备拆装。发PDF让大家自己看基本等于没培训。试运行期至少安排一周。这一周里平台侧要盯三个指标设备在线率、农事补录率、告警响应时长。在线率低于八成要排查供电和信号问题补录率过低说明交互设计或培训有问题告警响应时长超过两小时说明工单流程没打通。这些指标没有达标之前不要急着扩大范围。试运行期的另一个关键动作是建立“问题日报”机制每天把当天出现的所有问题汇总起来分技术问题和操作问题逐条解决。很多项目就是忽略了试运行期的问题沉淀直接铺开结果同一个坑在几十个村重复踩。4.3 数据运营与效果闭环设备上线之后最怕的不是设备坏而是数据躺在服务器里睡觉。这套体系做了一个很务实的闭环数据-提醒-农事-记录-评估。土壤墒情数据低于阈值系统提醒灌溉农户收到提醒后去浇水在小程序里补录一条灌溉记录月底系统自动生成一份农事统计农户能看到这个月浇了几次水、大概用了多少时间站长也能看到哪些地块农事记录经常缺失方便重点跟进。闭环里最关键的一环是“让数据反哺农户”。如果农户用了一个月感觉这个东西只是“给我发提醒”但提醒又没有带来明显的省水省电或产量变化他就会觉得系统没用。所以每次告警提醒都要尽量精准比如“下午到夜间有降温注意大棚防风”而不是泛泛的“气象预警”。精准的提醒才能建立信任信任到位农户才会持续补录数据后续的优化才有数据基础。5. 常见问题与排查技巧实录5.1 设备与系统问题速查表运营过程中很多问题反复出现这里整理一份速查表基本覆盖了乡镇场景里最容易遇到的故障。问题现象可能原因排查步骤设备长时间不在线SIM卡欠费、天线松动、供电不足先看设备指示灯再查SIM卡余额最后用万用表测电池电压太阳能板无法正常充电鸟粪落叶遮挡、角度不对、电池老化清洗板面检查是否被遮挡测试电池内阻土壤墒情数据漂移传感器未校准、电极附近有石块、长期浸水现场挖出传感器清洁后重新标定虫情拍照上传失败信号弱、图片过大、存储卡已满检查本地缓存缩小图片尺寸清理存储卡农户登录不上小程序验证码收不到、手机内存满、版本太旧换用短信登录清理缓存重新扫码进入数据上传缓慢网关挂载设备过多、信道冲突分批上传更换传输频段重启网关告警电话没人接号码未保存、被标记骚扰电话将外呼号码加入白名单增加短信和App双重提醒同一个地块数据重复设备部署间距过近、传感器串号核查设备编号与地块绑定的关系重新分配这份表打印出来给每个站长一份现场遇到问题时按流程排查绝大多数小故障不用等远程工程师。5.2 项目推进中容易踩的坑第一个大坑是一开始就让站长填写大量表格。我们曾经为了收集地块信息设计了一张有十几个字段的表结果站长要么漏填、要么乱填。后来精简到四五个必填字段其他都用选择题和自动定位替代录入质量反而上去了。记住一个原则凡是让使用者觉得“填表很痛苦”的流程一定会被偷工减料。第二个大坑是告警发得太频繁。系统刚上线时土壤湿度稍有波动就发一次提醒一天下来农户手机上全是通知最后直接屏蔽了电话。后来改成只有当湿度低于阈值超过一定时长才触发提醒并且同一天同类告警最多发一次。告警要有“钝感力”宁缺毋滥。第三个大坑是设备固定不牢靠。雨水冲刷、动物碰撞、人为挪动都是常见现象。设备安装时一定要做水泥基座或固定支架埋线要深、要套防护管特别是过路的地方。很多离线问题根本不是设备坏了就是线被蹭断了或者设备被碰歪了采集不到数据。第四个大坑是忽视农田作业对设备的物理破坏。例如旋耕机经过时把传感器地线带断喷雾机把虫情灯的集虫袋打湿收割机撞弯了气象站支架。这些事需要提前和农机手打好招呼在地块图上标出设备位置必要时候用醒目的旗杆或围栏把关键设备保护起来。还有一个特别容易被忽略的坑站长过于依赖远程监控频繁提醒后反而降低了自己巡检的主动性。后来平台把“主动巡检次数”也纳入考核每周至少实地巡检一次哪怕没有告警也要去看一眼。这个制度一推行设备在线率明显上升。数字化系统反而需要“非数字化”的现场动作来兜底这是很有意思的一点。写在最后的一些体会这次复盘给我最大的收获是在乡镇做智慧农业不要总想着“用技术替代人”而要想着“用技术放大本地人的能力”。平台做得再好如果服务站长不积极、农户不信任一切都是白搭。还有一个小经验想分享给同行如果你现在正准备做一个乡村数字化项目别急着上人工智能和大数据分析先把“一个设备坏了谁能最快修好”“一条告警发了农户会不会看”这两个问题解决。基础运维的稳定性和用户体验的一致性比任何华丽的功能都重要。这套“最后一百米”的实践后续能扩展的方向其实不少。比如把连续两三年的农事记录和产量数据结合起来做品种适应性分析或者把多个片区串成一张服务网络共享一个远程技术支持团队。但前提还是那句话路要一步一步走先让系统在田里稳定跑一年再谈更深的东西。

相关新闻

具身智能多模态对齐:从模型架构到部署落地的工程实践

具身智能多模态对齐:从模型架构到部署落地的工程实践

1. 具身智能中的多模态对齐:为什么模型与部署是两条腿走路搞具身智能的人最近应该都有一个共同感受:算法论文刷得飞快,但真要把一套多模态对齐方案落到机器人本体上跑起来,坑多得能写一本书。我过去一年多时间深度参与过几个具身智…

2026/10/14 7:18:36 阅读更多 →
MCP未死:Pi 1.0实践与工具接入标准化解析

MCP未死:Pi 1.0实践与工具接入标准化解析

最近几个月,我的信息流里“MCP 已死”这句话几乎每隔几天就要被翻出来吵一轮。就在争论最热的时候,Pi 1.0 发布了,头号卖点竟然是“原生支持 MCP”,活像故意往这个话题上浇油。我先说结论:我把 Pi 1.0 在本地完整跑了一…

2026/10/14 7:18:36 阅读更多 →
具身智能多模态对齐:从模型到部署的工程实践指南

具身智能多模态对齐:从模型到部署的工程实践指南

1. 具身智能里“对齐”到底在解决什么问题第一次接触“多模态对齐”这个词,很多人会下意识把它和“让模型看懂图片”画等号。这个理解不算错,但放在具身智能的语境里,它只覆盖了不到三成的含义。具身智能的对齐,本质上是让一个能感…

2026/10/14 7:18:36 阅读更多 →

最新新闻

模型上下文协议MCP实战:从架构原理到工具集成落地

模型上下文协议MCP实战:从架构原理到工具集成落地

1. 从一个真实困境说起:为什么我们需要模型上下文协议如果你最近半年在关注大模型应用开发,大概率会反复听到一个词——MCP,也就是模型上下文协议(Model Context Protocol)。我第一次接触这个概念的时候,心…

2026/10/14 8:11:50 阅读更多 →
大智慧通达信交易插件TradeX-TPS:量化下单中间件原理与实战配置

大智慧通达信交易插件TradeX-TPS:量化下单中间件原理与实战配置

简介:这是一套面向股票量化交易与自动化下单场景的插件工具,适配大智慧、通达信两大行情软件,通过TradeX.dll或Trade.dll连接券商服务器,实现买入、卖出、撤单、按预设比例清仓,以及账户信息、持仓和可撤单信息的查询&…

2026/10/14 8:11:50 阅读更多 →
模型上下文协议MCP实战:从零搭建本地文件检索服务

模型上下文协议MCP实战:从零搭建本地文件检索服务

1. 模型上下文协议到底在解决什么问题第一次听到“模型上下文协议”这个词,很多人会以为它又是一个新的大模型训练框架,或者某种提示词模板规范。其实都不是。它要解决的是一个更底层、更工程化的问题:当大语言模型需要和外部世界打交道时&am…

2026/10/14 8:11:50 阅读更多 →
BepInEx 6.0 IL2CPP 插件框架:加载机制、配置排查与稳定性实践

BepInEx 6.0 IL2CPP 插件框架:加载机制、配置排查与稳定性实践

BepInEx 6.0 IL2CPP 插件框架:加载机制、配置排查与稳定性实践 【免费下载链接】BepInEx Unity / XNA game patcher and plugin framework 项目地址: https://gitcode.com/GitHub_Trending/be/BepInEx BepInEx 是一个面向 Unity 与 .NET 游戏的插件&#xff…

2026/10/14 8:11:50 阅读更多 →
context-mode:基于SQLite+FTS5+BM25的上下文调度工程实践

context-mode:基于SQLite+FTS5+BM25的上下文调度工程实践

1. “context-mode”到底是什么?别被术语唬住,它本质是让AI真正“听懂上下文”的工程化方案最近在多个技术社区和开源项目讨论里,“context-mode”这个词出现频率陡增,尤其和MCP、SQLite、FTS5、BM25这些词高频绑定。很多人第一反…

2026/10/14 8:11:50 阅读更多 →
AI辅助量化策略开发:从零搭建ETF轮动回测框架

AI辅助量化策略开发:从零搭建ETF轮动回测框架

1. 为什么说现在是个人做量化的最好时机我接触量化交易差不多有七八年了,最早那会儿,个人想做一套自己的策略,门槛高得离谱。你得自己搭数据库、自己写回测框架、自己处理除权除息、自己搞行情接口,光是数据清洗就能耗掉大半个月。…

2026/10/14 8:10:50 阅读更多 →

日新闻

AnyPS5通用适配层设计:兼容性与性能的工程取舍

AnyPS5通用适配层设计:兼容性与性能的工程取舍

1. 从"AnyPS5"这个名字说起:它到底想解决什么问题第一次看到"AnyPS5"这个标题,我脑子里冒出来的第一个念头是:这大概率是一个围绕"跨平台运行"或者"通用适配"做文章的项目。名字里的"Any"…

2026/10/14 0:00:41 阅读更多 →
Flutter跨平台开发实战:二手交易应用与HarmonyOS适配

Flutter跨平台开发实战:二手交易应用与HarmonyOS适配

1. 项目概述:Flutter跨平台二手交易应用开发作为一名长期从事移动应用开发的工程师,我最近完成了一个基于Flutter框架的二手物品交易平台项目。这个项目最吸引我的地方在于它完美结合了Flutter的跨平台优势与HarmonyOS的生态特性,实现了"…

2026/10/14 0:00:41 阅读更多 →
DFS算法解决飞机降落调度问题实战

DFS算法解决飞机降落调度问题实战

1. 项目背景与核心思路飞机降落问题是一个经典的调度优化场景,也是算法竞赛和面试中的高频题目。这个题目要求我们合理安排多架飞机的降落顺序和时间,确保所有飞机都能安全着陆而不发生冲突。在实际航空管制中,这类问题直接关系到飞行安全和机…

2026/10/14 0:00:41 阅读更多 →

周新闻

流感时间序列预测实战:ARIMA/LSTM全流程拆解与避坑指南

流感时间序列预测实战:ARIMA/LSTM全流程拆解与避坑指南

简介:基于 ARIMA、LSTM、Transformer 等模型的流感时间序列预测 Python 源码,面向计算机相关专业课程设计与期末大作业学生,以及项目实战学习者。内容覆盖预处理、平稳性检验、定阶、残差分析、多模型对比预测的完整时序建模流程,…

2026/10/14 3:30:28 阅读更多 →
影刀RPA新手教程:键盘模拟输入实战——输入文本与模拟按键的区别

影刀RPA新手教程:键盘模拟输入实战——输入文本与模拟按键的区别

影刀RPA新手教程:键盘模拟输入实战——输入文本与模拟按键的区别 做影刀RPA自动化,十个新手有八个栽在"往输入框里填东西"这件事上:要么填不进去,要么填了一半,要么直接把原来内容追加在后面。这背后的根因&…

2026/10/13 16:22:04 阅读更多 →
影刀RPA新手教程:阅文起点小说数据采集实战——书籍信息与章节内容

影刀RPA新手教程:阅文起点小说数据采集实战——书籍信息与章节内容

影刀RPA新手教程:阅文起点小说数据采集实战——书籍信息与章节内容 1. 认识影刀:什么场景该用RPA采小说数据 起点中文网的页面结构相对稳定——分类榜单、书籍详情、章节内容三块独立页面,跳转链路清晰。这种场景非常适合影刀自动化&#x…

2026/10/14 3:29:58 阅读更多 →

月新闻

我发现了一个新思路:用 Remotion + Claude Code 像写代码一样自动化生成短视频

我发现了一个新思路:用 Remotion + Claude Code 像写代码一样自动化生成短视频

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/13 22:01:27 阅读更多 →
Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式:TaoToken 统一 Key 配置与验证

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式:TaoToken 统一 Key 配置与验证

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/13 14:57:39 阅读更多 →
黑夜航拍船只数据集训练YOLOV5模型全流程解析

黑夜航拍船只数据集训练YOLOV5模型全流程解析

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/14 7:53:34 阅读更多 →