用 GPT-6 Astra 和 Tripo3D 做智慧农业 3D 大屏：从调研到可巡检园区全流程实录

上一篇智慧厂房文章写到最后，我留了一个问题：那条从调研、设计、切素材、建模到网页化的链路，换个场景还能跑通吗？

这次我换成智慧农业。厂房里看设备和分区，农业园区里要看地块、作物、墒情、水肥和当天作业。画面中心也不再是一栋厂房，而是有温室、露地、道路、水体和水肥房的一整片园区。看上去只是换了一套素材，做起来才发现，农业场景更容易露馅：树如果浮在地上，玉米像一排黄色棍子，大棚外面漂亮、里面空空的，观众一眼就能看出来。

项目叫 smart-agriculture-3d-dashboard。这篇按真实推进顺序写，从调研、三稿设计、素材拆分、建模小样、整园深化、网页联动，一直写到人物生成、骨骼动画、近景巡检与最后的浏览器验收。我也摘录了几处与 Codex 的实际对话：它们比事后写一条漂亮流程，更能说明每次返工是怎么发生的。屏幕上的业务读数是固定样例，不是现场实时数据。

我没有直接让 GPT-Image-2.5 生成一张“农业科技大屏”。先把使用场景定为农业园区生产管理：园区负责人打开屏幕，要先看到种了什么、种在哪，再看到土壤墒情有没有值得核实的差异，水肥执行到哪一步，以及今天的农事作业落在哪些地块。调研时查了农业行动计划、FAO 的作物需水资料、农业监测和水肥设备公开说明，也看了农业大屏案例。参考资料用于确定观察对象与解释边界，没有拿别人的图或业务数字直接用。

为了让后续设计有可核对的对象，项目先设定了一个无具体地名的概念园区：12 个种植单元、240 亩，包括 8 个棚区和 4 块露地；种植番茄、黄瓜、甜椒、生菜和甜玉米。这些数字是可复现的设计样例，不是某个真实园区的测绘或生产记录。

数据口径也要提前定。比如 G03 的 20 厘米土壤含水率是 22.4%，同组中位数是 27.1%，差了 4.7 个百分点。界面可以提示“低于同组中位数”，但不能顺手写成“缺水告警”：没有土壤类型、作物阶段和农艺阈值的现场证据，差异本身不足以支持这个结论。G04 的读数延迟，就标采样时间并退出当次比较。

Brief 之外还做了一份可复算的数据样例：12 块地面积、五种作物分项、24 项作业的 15/6/3 状态，以及 128/160 立方米用水，都先核对总分关系。后面无论图片、图表还是交互出现相反数字，都能回到这份样例查。真实园区台账、接口和测绘资料没有提供，所以这一步验收的是设计口径与样例算术，不是现场农业诊断。

设计阶段做了三个方向：A 是田园生产全景，中央用连续鸟瞰园区串联地块和作业；B 是地块对照研究台，把同作物地块放在共同尺度上比较；C 是农事生产日程，让当天作业成为阅读主轴。我选了 A，因为这块大屏需要先建立整园空间关系，再去看某个地块的证据。三稿是不同的信息组织方式，不是同一张图换颜色。

这一步的对话其实很短。我在三稿里选了“A 田园全景”，随后补了一句“真实字体＋程序化图表合成”。

设计稿确定后，我没有把整张图片直接铺在页面上。先做一张可交互的 HTML 审阅页，逐项标出中央物理边界、文字、图表和装饰。点击一个元素，就能查到它在原图里的坐标、属于哪一层、最后落到哪个模型节点或前端组件。项目把画面拆成四类：温室、道路、水体等由三维场景负责；地块边界和选中态由运行时空间层负责；文字和图表由 React、ECharts 负责；标题承托、图标、边框等静态装饰才从设计真源提取。

中央区单独拆出了 12 个种植单元、水肥房、湖面和环境参考。设计图片只作为可见轮廓与材质线索，不能直接当成运行时的三维地形或模型贴图。这一步的验收是在审阅页逐项核对边界和归属，先解决“后面谁来做”这个问题。

归属定好后才分批提取天气、作物、标题檐、面板框等静态素材。每一批都记录源区域、透明边缘和文件哈希，切完放回原位比对差异。最后 271 个逻辑元素都有去向；素材包保留 21 份母版，其中 19 份界面源切、1 份中央物理参考、1 份加载海报；真正发布到页面资源目录的是 20 份界面与海报文件。技术检查和逐资产复核通过后，素材才进入 Scaffold 的图片配置。

这个归属表后来很有用。最近我发现“复位视角”按钮周围竟然又冒出一块旧树林背景，排查后确认按钮外框和装饰图本身烘进了景色。定位到素材与组件层，把旧图撤掉，换成半透明按钮和矢量图标，三维场景才重新连成一片。一次像素回贴通过，不代表动态场景里永远不会出现旧背景；真正使用时还得复查。

模型阶段也不是一步到位。最早用 Three.js 做了 G03 棚区和水肥房小样，方便快速试轮廓和浏览器灯光。看到中间区域后，我觉得它还是缺少设计图里的园区体量，建筑构造也太像临时几何，于是明确要求改用 Blender MCP。

当时我在对话里直接指出：“我觉得你需要使用blender-mcp方式建立模型。”看到第一版后，又补了一句：“明显建模的中间部位没有对应的感觉。需要重新构建。”这不是让模型再加一层材质，而是把中央场景的轮廓、建筑关系和真实空间比例重新作为验收对象。

GPT-6 Astra 先通过已安装的 Blender MCP 做代表切片：三栋独立拱棚和一座水肥房。拱棚有骨架、围护、门框；水肥房补出窗洞、高低屋面和蓝色附属房。Blender 里保存可编辑的源场景，再导出 GLB，在浏览器用相同机位看轮廓、材质和阴影。这个小样通过后，才扩成 12 个种植单元的完整园区，包括道路、水岸、露地和水肥房。可编辑 Blend 与网页 GLB 分开保存，不能把浏览器画面当成唯一源文件。

Blender MCP 的 G03 与水肥房小样

整园总览出来后，拉近才发现“有大棚”不等于“棚真的像大棚”。我在对话里继续追问：“房屋建筑需要进一步深化，符合现实的房屋构建。大棚里面的蔬菜你也需要根据实际场景联想。”接下来才逐项深化端墙、入口、侧通风、支撑和水肥房开口，棚内补中央通道、四排作物、滴灌和吊蔓。番茄、黄瓜、甜椒分别做株型与果实，不共用一套绿色形状。Blender 渲染图和浏览器 GLB 都用接近 1.7 米的人视角检查：屋顶余量、通道宽度、作物会不会穿过棚顶。一次包围盒检查还把非碰撞误报为穿棚，最后改用实际变换后的顶点再量，才分清误报与真问题。

这版建筑与作物都按米制比例做，但“米”是建模单位，尺寸来自设计推断，没有实地测绘或 CAD 依据。它是可视化级模型，不是可用来核算温室荷载的建筑图。

模型做好只是前半程。网页用我之前发布的 @lius1314/visual-dashboard-scaffold 管理区块，React 负责卡片和交互，ECharts 画 7 组图表，Three.js 加载 Blender 导出的 GLB。设计稿切出的图标、边框走素材配置；文字和数字继续由真实字体及业务数据绘制；场景中的地块标记与可点击区域绑定到对应模型节点。这样才能在选中 G03 时，让模型、墒情卡和趋势图指向同一个对象。

我先验三条真实操作路径。第一条是从 G03 的 22.4% 点击到地块高亮，再看 20 厘米、40 厘米读数与最近 24 小时曲线；第二条是筛选番茄，让四个棚区面积和水肥分项一起变化，而标着“全园”的总量保持原口径；第三条是从进行中的农事记录点击地块，查看班组和截止时间，返回后保留筛选和页码。

状态处理也在这一步做。样例只有 G03 的历史曲线，点别的地块显示“暂无最近 24 小时记录”，不会拿 G03 的线冒充；G04 采样延迟，展示时间但不纳入同组中位数。模型加载中、加载失败和动效暂停都有对应界面。最后在真实浏览器里点击、快速切换和返回总览，而不只看静态截图。

总览能点之后，我又想知道它能不能走进去。先给 12 个地块做近距离观察机位，再沿服务道路生成巡检路线。进入 G03 或露地田，镜头靠近对象；巡检时可以第一人称、第三人称切换，也可以暂停、跳站和返回总览。路线按道路采样，并检查人物与大棚、水肥房之间的通行间隙。

巡检人物起初是占位模型。为了避免 AI 随手生成一个与园区格格不入的人，我先在对话里说：“然后生成一个巡检人物的三视图，我用来生成人物。”三视图把正面、右侧和背面放在同一尺度上：青绿色工装夹克、深蓝工作裤、工作靴与帽子保持一致，双臂微张，方便后续建模与绑骨骼。这张图是角色生成参考，不是可直接运行的三维资产。

来源：稀土掘金　原文