AI+Three.js：智慧农业3D大屏巡检系统开发实战-北京尧图网络

4月中旬一家做设施农业的公司找到我们说要上一套“智慧农业3D大屏”要求就一条——“能巡检整个园区”。接到这个需求时我原本以为又是一块平平无奇的汇报大屏无非是放几个三维模型、挂几张图表撑撑门面。但真正用GPT-6 Astra和Tripo3D把这条链路从调研一路跑到交付后我发现这个项目的水准完全超出了预期从需求梳理、技术选型、3D资产生产、大屏开发到可巡检交互整个流程只用了28个工作日而且大量重复劳动都交给AI工具扛了下来。这篇文章我会把过程完整记录下来包括我们为什么选这三件套Three.js GPT-6 Astra Tripo3D、Tripo3D生成农业3D资产时提示词怎么写、GPT-6 Astra在需求调研和开发阶段具体帮我们做了哪些事、以及最后巡检交互和性能瓶颈是怎么解决的。内容有点长但每一步都是可以做笔记的实操细节适合正在做数字孪生、可视化大屏、智慧农业方向或者想用AI工具重组传统开发流程的团队参考。1. 项目概述与需求拆解1.1 需求调研客户说要“大屏”实际要的是“巡检能力”项目走到前端开发之前最关键的一步其实是需求调研。客户一开始拿来的需求说明书写得很简单“做一个3D大屏展示园区全貌最好能转起来感觉很高级。”这句话放在两年前我大概率就按“三维展示图表”的标准模板去做了。但这次我们加了两个动作第一跟客户的生产负责人张工化名约了个园区实地走访第二把所有访谈记录丢给GPT-6 Astra让它帮我们做一轮需求结构化分析。实地走访那天最有价值的收获是张工带我们看了他们的中央控制室。控制室里其实已经有一套2D的Web管理系统能看实时温度、湿度、水肥机状态、摄像头画面。但问题是这套系统是表格形态的几十个设备排成列表遇到异常要一条条翻。他说“我每天要巡一遍园区大棚、泵房、分拣中心一圈走下来一个多小时下雨天更麻烦。我就想坐在这个办公室里能像站在园区里一样把每个角落都检查一遍。”这句话才是核心需求——“巡检”而不是“展示”。巡检查什么结合他接下来零零碎碎提到的痛点可以归纳成四件事远程巡视园区重点区域不用雨天跑现场。定位异常设备比如某个大棚的风机没转、水肥机的EC值偏高能在三维场景里直接看到位置。查看关联的实时数据点击某个大棚、某台设备时能看到对应的传感器数值和摄像头画面。保存例行巡检轨迹每天按既定路线看一遍形成记录。搞清楚这些我才确定要做的不只是一个模型展示屏而是一个“可巡检数字园区”。1.2 用AI把零散记录变成需求清单这一步按传统做法是产品经理整理访谈纪要再开会过需求。但这次我们把访谈录音转写稿、现场拍的照片、以及张工手写的几条备注全部整理成一个文档扔给GPT-6 Astra让它先出一版“需求要素提取表”。Astra给到的输出包括角色清单、场景清单、数据项清单、交互行为清单直接把散乱信息结构化。比如它自动识别出了“环境监测”“水肥控制”“视频监控”这三类核心场景并关联了具体设备类型。这个初稿对我们很有用省了不少来回讨论的时间——虽然它也会漏掉一些行业细节比如农业里经常提到的“积温”概念但作为需求整理的加速器是合格的。最终我们汇总出一份需求功能清单编号功能模块具体说明优先级F1园区三维场景1:1还原园区建筑、大棚、道路布局P0F2实时数据联动大棚温湿度、土壤墒情、气象站风速风向接入大屏P0F3设备状态可视化风机、卷帘、水肥机运行状态在模型上高亮反馈P0F4巡检路径漫游自动沿预设路径飞行巡视可暂停、可跳转P0F5点击查看详情点击任意大棚/设备弹出信息面板含实时数据和监控画面P1F6异常告警定位超阈值数据触发模型颜色闪烁和告警弹窗P1有了这个清单后面开发方向就不会跑偏也避免了返工。1.3 需求转技术指标的关键决策需求清单出来以后要走一步“翻译”把业务功能翻译成技术指标这一步决定了整个项目能不能落地。先说园区场景规模。客户园区约120亩里面有12栋连栋温室、20个大拱棚、1栋配套分拣中心加上泵房、工具房若干还有道路、围栏、树木这些环境要素。如果全部按高精度模型做三角面数破千万是轻轻松松的普通电脑根本扛不动。这里必须做取舍——不是所有建筑都需要“好看”关键是“可辨认”。对3D模型的要求是建筑体块特征准确、外观配色接近真实、能区分功能区域。这个定位直接决定了后续Tripo3D生成模型的精度等级和优化策略。数据接入方面客户现有物联网平台有标准HTTP API和WebSocket接口我们需要做的不是造数据而是做数据通道和场景联动。当时确定的方案是点位数据和实时状态通过WebSocket推送秒级延迟。历史曲线、统计报表通过HTTP API拉取。每个大棚有唯一ID通过这个ID把模型Mesh、设备数据、监控视频关联起来。这个方案的好处是业务逻辑清晰前端只管展示不参与数据存储和计算。也避免了把几百个点位一次性轮询带来的性能压力。2. 技术选型与方案设计2.1 为什么选Web端Three.js而不是Unity数字孪生大屏的渲染方案业界主流的无非三条路Web端Three.js/WebGL、游戏引擎Unity/Unreal、专用数字孪生平台。我们这次选的是Web端 Three.js理由很实际第一交付环境。客户的大屏是浏览器撑满整个屏幕运行的而且后续要嵌入他们已有的管理后台Web方案可以零安装、直接打开。Unity要跑WebGL构建包体量大、加载慢做复杂交互还要改编译目标不值当。第二团队栈。我们是Web前端团队迭代Three.js应用不需要额外学C#和引擎资源管线。第三可控性。Three.js用的是通用3D方案模型加载、Raycaster点击、相机动画都有成熟API二开成本低。用专用平台反而容易被平台的私有格式绑定。为了更直观对比我做了个选型评估表对比项Web端 Three.jsUnity WebGL专用数字孪生平台加载速度快可压缩分片加载较慢包体一般几十MB起步中依赖平台运行时开发灵活性高完全代码控制高但需跨语言调优低受平台功能限制团队学习成本低前端可快速上手高需学习C#和引擎管线中需学习平台SDK数据接入能力原生WebSocket/HTTP需做JsBridge桥接依赖平台规则引擎长期维护成本低代码即资产中版本升级成本高高平台年费结论很简单项目规模可控、团队栈是Web、后续有系统集成需求时Web端Three.js是最优解。如果你的项目要做超大规模场景比如整个城市的数字孪生可能要考虑游戏引擎或专业平台但对农业园区这个量级Three.js绰绰有余。2.2 Tripo3D入场AI生成3D资产的取舍3D资产怎么来这是项目启动时争论最多的一件事。传统选项有两个一是外包给建模公司二是团队学Blender自己建模。但这两个选项都不太理想。外包建模精度有保障但周期感人——12栋连栋温室加20个大拱棚还有各种农机、树木、路灯精模一套报价下来可能要十来万而且每一轮修改都是额外费用。自己建模呢我们团队是前端工程师三脚猫的Blender水平去抠模型怕不是要在大棚弧面上磨一个月。后来调研到Tripo3D我们眼前一亮。这是一款AI生成3D模型的在线服务它本身和腾讯生态有深度绑定目前迭代速度很快支持文本生成3D模型、图片生成3D模型生成结果可以直接导出GLB/GLTF格式。实测下来它对“建筑类、机械类、器物类”物体的生成效果远好于角色和生物类而这正好符合农业园区的模型需求我们不需要精细的“人”需要的是“大棚”“风机”“水肥一体机”这些结构规整的设备。算法的判断是Tripo3D 负责单体资产生产Blender 负责后处理拼装Three.js 负责最终渲染。AI模型生成肯定做不到“生产级直出”但它的优势在于把“从无到有”的过程压缩到分钟级极大降低了建模门槛。2.3 GPT-6 Astra 在方案和编码中的定位然后说GPT-6 Astra。团队选它的原因有三个第一是代码能力。Astra对前端三件套TypeScript、Three.js、ECharts的理解非常准确生成代码的可用率高。第二是私有化部署体验好考虑到项目涉及客户园区数据部分代码和数据样本不适合传到公网服务而Astra提供开源权重模型本地部署方案——这也是这次项目选择它的一个重要原因。第三是它能处理长上下文可以一次性把我们项目的依赖、目录结构、API定义喂进去减少来回对话的损耗。但我们对Astra的定位不是“自动编码器”。实际分工是这样的AI负责需求整理、代码骨架生成、胶水代码接口封装、类型定义、数据转换、报错排查线索。人负责产品决策、场景结构设计、模型后处理、性能调优、代码审查。说白了AI是最好的“高级实习生”能非常快地完成结构性、重复性的工作但“这个场景该怎么设计”“这个交互会不会误导用户”这种需要行业认知的事情还是得人来定。这个定位很关键它决定了后面开发的节奏Astra帮我们省掉大约40%的编码时间但我们没有让它独立写任何一段上生产的代码所有AI产出都经过人工Review实测下来项目没出过因为AI代码导致的低级事故。3. 3D资产生产流水线3.1 Tripo3D 提示词的设计心法模型质量七分靠提示词。Tripo3D的文本生成3D能力虽然不弱但如果你只写“一个大棚”它给你生成的只能是“一个粗糙白色大棚形状的色块”。要让AI产出能用的模型提示词必须满足三个要素结构描述、风格约束、视角习惯。先说结构描述。你要先想清楚这个物体在园区里从哪个角度被看。比如连栋温室人在大屏上会俯瞰、侧看、平看所以提示词要写到“全钢结构透明或半透明薄膜覆盖顶部弧形侧面可见卷帘通风窗地面有水泥基础”。这六个特征缺一个生成出来的模型就可能少细节。然后是风格约束。农业3D大屏追求的不是“照片级真实”而是“干净清晰的可识别性”。实战下来加“低多边形写实风格PBR材质工业设计风格”这几个词出来的模型比纯写实风格更耐看而且面数更可控。纯写实风格容易生成一堆噪点级的小物件减面时会连累整体效果。最后是视角习惯。Tripo3D默认的生成视角是前45度俯视所以提示词里最好加一句“模型主体完整各角度外观一致无破损空洞”。这句话能明显减少底面漏面、背面空洞的情况。举两个实际例子。这是生成“连栋温室”的提示词全钢结构玻璃连栋温室长度45米跨度12米顶高6米半透明薄膜覆盖顶部弧形天窗侧面有卷膜通风口底部水泥基础低多边形写实风格PBR材质模型主体完整各角度外观一致无破损空洞这是生成“水肥一体机”的提示词农业水肥一体化灌溉设备立式柜体顶部有显示屏带有施肥罐、过滤器、管道接口工业设计风格金属与塑料材质低多边形写实风格PBR材质模型主体完整各角度外观一致提示词在Tripo3D里反复调整了大概三轮才找到最稳定的输出模式。我的经验是结构描述宁可写得更啰嗦也不要贪图简洁——AI生成模型时靠的是语义组装你给的信息越具体它走偏的概率越小。3.2 模型后处理统一方向、比例与面数Tripo3D生成的GLB模型拿来直接用是不行的。它有三个老毛病方向不统一、比例没标准、面数偏高。方向不统一是说同一个大棚可能生成出朝东的也可能生成出朝西的在场景里拼装时朝向全乱了。比例没标准是说Tripo3D生成模型的尺寸参考是“归一化到1立方”不一定是真实米制尺寸。面数偏高则是关键性能隐患有些模型一栋大棚面数能到28万全园区几十个模型堆在一起任何一张普通显卡都要跪。我们的处理流程是“Blender三步走”第一步归一化比例。把GLB文件导入Blender后先测量模型的标记长度比如大棚的跨度然后整体缩放让1个单位等于1米建立标准的真实尺寸坐标系。第二步修方向。旋转模型让正面朝向Y轴负方向Three.js的默认正面习惯再应用全部变换确保导出后定位不会扭曲。第三步减面。用Blender的Decimate修改器按“Planar”平面模式减面目标是把单栋大棚压到5万面以内。减面时要看模型结构——切掉内部过多的管线细节保留外部轮廓和主要设备表现即可。减完后在材质球里检查一遍避免表面出现明显的破面或交叉重叠。这个后处理流程是AI替代不了的必须人对每个模型人工过一遍。但它也不会花费大量时间因为大部分模型结构简单平均一个模型20分钟能搞定。3.3 园区拼装与坐标对齐单体资产完成后就进入园区总装阶段。总装我强烈建议在Blender里完成而不是在Three.js里用代码摆坐标。原因很简单Blender里你可以打开航拍图/卫星图作为背景底图用视觉对齐去摆建筑和道路效率远高于手工敲数字坐标。实际操作把客户提供的园区卫星图导入Blender作为背景参考然后按“先道路、后建筑、再环境”的顺序布局。建筑之间的间距参考卫星图的比例尺换算成真实米数道路按实际宽度拉出平面作为地面贴图区域。这个阶段有大量重复劳动——20个大拱棚位置相近挨个摆放没有意义。这里可以直接复制阵列在Blender里把第一个大拱棚摆准位置后通过Array修改器生成一行再分别微调Y轴偏移一分钟排好一整排棚。拼装完成后把整个园区所有模型合并成一个GLB场景导出。这里要注意Three.js加载GLB场景后内部物体如果全部合并成一个Mesh就无法做单独点击拾取。所以导出时要保持“一组物体对应一个Mesh”并在Blender里命名好物体比如GH-01-001对应1号连栋温室。命名规范直接决定了后面代码里点击事件的挂载效率这个习惯越早建立越省心。4. 大屏开发与数据接入4.1 前端架构与模块划分3D大屏的代码工程最忌讳的是写成“一个入口文件干到底”的屎山。因为交互逻辑比较长——场景初始化、相机控制、模型提示、数据面板、图表联动、告警逻辑都挤在一起一定会失控。我们的工程用 Vue 3 TypeScript 搭建模块按职责拆成四层渲染层负责Three.js场景、相机、光照、渲染循环任何业务逻辑不写进来。数据层负责WebSocket连接、HTTP请求、数据清洗、状态存储Pinia。交互层负责鼠标拾取、点击事件、巡检路径、相机动画。展示层负责覆盖在3D画布上的HTML组件包括顶部统计栏、侧边信息面板、告警弹窗、ECharts图表。这四层通过事件总线通信。比如数据层收到“1号棚温度超阈值”的消息不直接改场景而是emit一个alert-triggered事件交互层监听这个事件后去驱动模型高亮和弹窗。这样做的好处是每层都可以独立调试数据层断开了也不会导致场景崩溃。这段架构代码包括目录结构、事件类型定义、Pinia store的骨架都是让GPT-6 Astra先生成初稿我们再Review填业务逻辑。Astra生成的过程大概花了半小时如果全手工写至少得一个下午。4.2 实时数据通道WebSocket 封装大屏的数据实时性决定了它是不是“真巡检工具”而不仅是个花瓶。客户物联网平台的WebSocket接口是标准的JSON推送协议我们需要在前端封装一个健壮的实时数据客户端。这个封装有几个细节非常关键心跳保活、自动重连、断线缓存。心跳保活很简单每30秒发一个{type:ping}服务器回pong。如果连续三次收不到pong强制断开重连。自动重连要加退避策略——不固定间隔重连而是按“1秒、2秒、4秒、8秒”递增最多重试5次超过5次后提示用户手动刷新。断线缓存的意思是重连成功后要把离线期间丢掉的最近50条点位数据补拉一次避免大屏出现数据空洞。这部分代码用GPT-6 Astra生成的核心逻辑没问题但Astra初次生成的代码有两个小坑一是没有处理TypeScript泛型导致推送的JSON解析类型不安全二是没加ping的超时计时器服务器假死时连接会一直挂着。这两处都是我们Review时手动修正的。所以经验是AI写的代码你可以信但不能不审。4.3 数据驱动的场景更新数据接到以后还要让3D场景“跟着数据动起来”。我们实现了三种联动方式第一种是颜色联动。每个大棚Mesh上挂一个用户数据字段greenhouseId数据层收到温度数据后根据温度值刷新Mesh的材质颜色——正常显示灰白偏高变成淡黄超过阈值变红并闪烁。颜色映射逻辑不写在渲染层而是由展示层根据温度值计算好颜色再传递给渲染层。第二种是位置联动。农业园区里卷帘机、风机这类设备物理状态是“开启/关闭”的我们用模型旋转角度变化来表示风机开启时叶片高速旋转卷帘机开启时帘幕向下展开到指定角度。这种动画不能直接在渲染循环里逐帧改得用Tween库比如gsap打关键帧避免和其他动画冲突。第三种是面板联动。点击大棚时侧边面板不仅显示该大棚的基础信息还挂一个嵌套的ECharts折线图拉取最近24小时的温湿度曲线。图表组件用echarts官方的echarts-gl还不行我们直接用的是普通2D折线图——在大屏场景里24小时曲线用2D展示比3D柱状图要直观得多。首次接入时踩了一个坑环境数据每5秒推一次但图表数据要1小时级别的历史序列两者直接混用会导致图表更新频率过高、发生闪烁。后来用Astra帮我们加了一个“数据打点与聚合”的工具函数把实时数据按分钟聚合到历史序列里才解决了这个问题。5. 可巡检交互的落地5.1 巡检交互的四层结构做可巡检园区最大的难点不是渲染而是交互层级的设计。我一开始犯的错是把整个场景当成一个“可以自由旋转的模型”想着鼠标拖拽就行。但客户真正要的巡检有明确的空间认知逻辑从园区外部看到园区内部从区域看到设备从设备看到数据。我把这个认知过程拆成四层第一层全园概览。相机在150米高空俯瞰全园能看清道路、建筑、大棚分布。第二层区域聚焦。点击或自动飞到某个区域比如“1号连栋温室区”相机俯冲到30米高度能看清该区域内部结构。第三层设备定位。在区域内高亮显示所有设备点位点击某个具体设备相机飞到10米附近模型放大居中。第四层数据详情。设备聚焦后右边滑出信息面板展示实时数据、历史曲线、摄像头画面。这个四层结构每一层都对应一套相机参数位置、朝向、FOV和一套交互规则键盘、鼠标、按钮。设计好这套层级后用代码实现只是时间问题方向不会偏。5.2 相机漫游与路径动画自动化巡检路径是实现“可巡检”的核心功能。客户要求的“每天按既定路线巡逻”我们用Three.js的相机动画来实现。具体做法是在Blender里预先标记好8-10个巡检关键点每个点包含相机位置、注视目标、停留时间。全部导出成一个JSON文件前端加载后按顺序播放实现类似“无人机巡航”的效果。关键实现的代码逻辑import { PerspectiveCamera, Vector3 } from three import gsap from gsap // 从Blender导出的巡检点数据结构 interface PatrolPoint { id: string label: string cameraPos: [number, number, number] lookAt: [number, number, number] dwell: number // 停留毫秒 } // 播放巡检路径 export function playPatrol(camera: PerspectiveCamera, points: PatrolPoint[]) { const duration 1800 // 两段点之间飞行时间ms points.forEach((point, index) { const startTime index 0 ? 0 : points.slice(0, index).reduce((sum, p) sum p.dwell, 0) index * duration gsap.to(camera.position, { x: point.cameraPos[0], y: point.cameraPos[1], z: point.cameraPos[2], duration: duration / 1000, delay: startTime / 1000, ease: power2.inOut, onUpdate: () camera.lookAt(new Vector3(...point.lookAt)), }) }) }注意一个细节相机动画不能只补间position还要同步调camera.lookAt否则飞行过程中视角朝向会僵硬地一直看着原点用户没法看清沿途的园区。上面代码用了onUpdate回调去实时更新视角目的就在这里。实际播放时还有一个交互bug用户在动画播放过程中手动拖拽场景相机位置会被“抢走”导致动画和手动操作相互打架。解决办法是播放状态下锁定轨道控制器动画结束后再解锁。锁定状态在UI上要加一个明显的“暂停巡检”按钮不然用户会以为页面卡死了。5.3 点击拾取、POI标注与信息面板可巡检不只有自动飞行还需要“指哪到哪”的能力。点击某个大棚、某台设备立刻看到对应的数据和状态。Three.js里做点击拾取用的是Raycaster射线检测。但要注意全园区几十个模型逐帧做全量射线检测肯定卡。优化思路是“按需拾取”正常状态下只拾取高亮的建筑层十几个Mesh只有巡检动画飞近某个区域后才开启该区域的设备级拾取。拾取后要显示信息面板。面板不能用Three.js的Canvas/SVG去做直接在HTML上覆盖一个position: fixed的div数据绑定到Vue的响应式变量里。这样图表、表格、图片这些复杂的UI都能用前端老本行来写复用性最高。POI标注我们用的是Three.js的CSS2DRenderer在3D场景里悬浮显示“1号棚”“水肥机房”等文字标注。CSS2DRenderer的优点是文字始终面向相机、不会被模型遮挡实现成本也低。缺点是大屏4K分辨率下默认字号偏小要把字体大小按视口比例缩放否则在拼接屏上看不清。6. 常见问题与排查技巧实录6.1 首屏加载性能从9秒压到3.5秒大屏首屏加载速度是客户第一眼印象的分水岭。第一次把全园区GLB丢进页面时首屏加载用了9秒多黑屏时间巨长客户脾气都要上来了。优化做了三件事第一Draco压缩。Three.js原生支持加载Draco压缩后的GLTF文件。把GLB转成GLTF后套用Draco压一遍模型文件体积能缩小70%左右。代价是加载后需要解码但解码比网络下载等待快得多。第二gzip CDN。模型文件放在CDN上开启gzip传输WebSocket接口和后端在同一地域3D资源走CDN边缘节点。这一步把网络耗时进一步压缩。第三按需加载。首屏只加载全园概览这一层所需的“外壳模型”远景建筑和道路总面数控制到总体的30%等用户点击进入某个区域后再动态加载该区域的精细模型。代码上用THREE.LoadingManager管理加载完成前显示一个进度条。优化完成后实测首屏加载稳定在3.5秒左右后续区域模型跳转控制在1-2秒内客户体验明显改善。6.2 材质与光照的细节坑4K大屏上材质问题会被放大得非常明显。第一版场景把灯一打大棚薄膜材质出现了明显的“死黑”和“过曝”并存——向阳面白花花一片背光面黑成一坨阳光棚的效果变成了夜间大棚。排查后发现两个原因一是环境贴图强度太高用的HDR贴图本身动态范围过大二是材质球的粗糙度和金属度设置不合理薄膜材质给了过高的金属度导致反光严重。解决方案是用Three.js的PMREMGenerator生成低动态范围的RoomEnvironment环境贴图色温偏冷一点点然后把所有非金属材质的metalness统一降到0.05左右roughness按材质类型分别设置——薄膜0.6、钢结构0.4、混凝土0.8。调整完后整个场景的明暗关系看起来就自然了大棚也有“玻璃质感”了。这里有个经验技巧4K大屏和普通显示器对对比度的感知不一样调材质时不要盯着自己的2K显示器看因为很多细节在2K下根本看不出来。把渲染器的pixelRatio锁到2然后截图在4K电视上对比检查才能发现真实问题。6.3 WebSocket稳定性问题这个坑在演示前一天踩到了开发环境下跑得好好的WebSocket部署到客户机房后图片数据传输隔几分钟就断一次。排查过程花了不少时间。第一轮怀疑是网络环境问题但测试其他WebSocket服务是正常的。第二轮把日志打出来发现断开前服务端会主动发一个close帧没有任何错误码。后来打开浏览器开发者工具去抓包才发现是被客户机房的防火墙拦截了——原因是我们的客户端每30秒发一次ping包而这个频率在某些防火墙策略里被判定为“异常高频心跳”触发了主动断开。解决办法是把心跳间隔从30秒调整到60秒并且在断线重连时加入1-3秒的随机延迟这样每个客户端的重连请求错开不会形成周期性洪峰。改完后跑了一整天连接稳如老狗。这个经验后来我在很多WebSocket项目里都会先提醒对方心跳频率不是越快越好要结合网络设备策略来定。7. 经验总结与后续扩展建议整个项目做下来我最真实的感受是AI工具不是替代者而是杠杆。Tripo3D把原本10万元级、1个月的建模周期压缩到两周加几万块的成本GPT-6 Astra把重复性的编码工作压缩到三分之一的时间但这都不代表工程师没活干了。相反工程师的注意力从“怎么把代码敲出来”转移到了“怎么设计好架构、怎么调好性能、怎么让客户真正用起来”。这个项目能跑通我认为有三个关键原则可以复用第一AI产出一定不是“拿来即用”它是初稿、是加速器真正的质量保障来自人工Review和现场打磨。无论是Tripo3D的模型后处理还是Astra的代码审查都离不开这条底线。第二业务需求调研比技术实现重要得多。如果当初没有去园区实地走访按“展示大屏”来做最后交付的东西客户不会满意。是“能巡检”这个真实需求让这个项目比普通可视化大屏高了一个档次。第三性能问题永远是3D大屏的生死线。模型、材质、光照、数据通道每一项都要有量化指标宁可前期多花时间在资产优化上也不要在客户现场卡成幻灯片。后续如果有机会迭代我会建议客户做两件事一是把巡检记录的保存和回放做成常态化功能变成每天的工作台账二是接入AI分析能力让系统能根据历史数据和环境模型自动给出“哪几个棚需要优先巡查”的提示。这一步做成了这个园区就能从“可巡检”走向“智慧巡检”价值又会不一样。最后分享一个开发中的小技巧在所有模型和交互逻辑里提前埋好“数据埋点”记录用户在3D大屏上的操作行为点了哪里、看了多久、巡检到哪个节点停了。这个数据在项目上线后可能不起眼但等客户提出“哪里需要优化”时它就是最好的决策依据——毕竟用户的行为永远比他们嘴上说的需求更诚实。

AI+Three.js：智慧农业3D大屏巡检系统开发实战

相关推荐

AI如何助力本科生高效完成文献综述

MiFlash 2022.05.07刷机：驱动、Fastboot与9008避坑

C#与.NET 4.5下的MQTT客户端源码解析与联调实践

更多资讯

智能从来不是工具，是结构：Copilot 救不了组织

2026日语能力考试N1、N2、N3、N4、N5历年真题及答案合集PDF（2010-2026年）

CAN 位时序与 500kbps 参数推导：HAL 里看不到 0x001A0005，但它就在那

门店上 AI 项目怎么立项排期？6 个阶段、8 到 12 周参考周期与 3 个最容易返工的节点

2026 AI 全栈开发面试题：前端、后端、模型、部署一篇打通

结合第三方视觉平台开发基本视觉应用，是机器视觉工程师的核心能力之一

今日更新

微信个人号API开发案例：图片/语音/视频消息怎么下载解析存到本地？

Python股票自动交易系统源码解析：从行情获取到风控的完整链路

视酷酷信IM源码部署指南：Java 17+MySQL 8.0.33实战配置

本周精选

防幻觉智能体架构：电源硬件设计中的大模型编排与工具化实践

OpenGL面试核心考点：渲染管线、矩阵变换与性能排查全解析

全国计算机二级C语言真题PDF高效刷题指南

本月热门

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

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

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？