企业官网建设流程全解析

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给到的输出包括角色清单、场景清单、数据项清单、交互行为清单，直接把散乱信息结构化。比如它自动识别出了“环境监测”“水肥控制”“视频监控”这三类核心场景，并关联了具体设备类型。这个初稿对我们很有用，省了不少来回讨论的时间——虽然它也会漏掉一些行业细节（比如农业里经常提到的“积温”概念），但作为需求整理的加速器是合格的。

最终我们汇总出一份需求功能清单：

有了这个清单，后面开发方向就不会跑偏，也避免了返工。

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、后续有系统集成需求时，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大屏上的操作行为（点了哪里、看了多久、巡检到哪个节点停了）。这个数据在项目上线后可能不起眼，但等客户提出“哪里需要优化”时，它就是最好的决策依据——毕竟用户的行为，永远比他们嘴上说的需求更诚实。