我们智能空间数字孪生项目里有个很常见的需求把吊扇产生的气流在虚拟场景里画出来让用户一眼看懂风往哪儿吹、风速大概多大。以前要实现这个要么直接上 CFD计算流体力学仿真网格划分、边界条件、迭代收敛一套流程下来根本不是实时能扛住的要么全靠经验瞎猜纯粹做个动画糊弄人。我当时在想能不能换个思路——让视觉语言模型VLM直接看一眼房间照片理解风扇位置、转速、风向这些关键信息再交给 Unity 在三维场景里把气流可视化出来。这个概念验证做完以后效果出乎意料地好整个链路从照片到粒子气流动画只需要几秒钟完全够用。这个项目适合两类人参考一类在做数字孪生、智能家居可视化需要把 IoT 设备状态变成场景里可感知的信息另一类是 Unity 开发者想了解怎么把大模型的语义理解能力接进游戏引擎里做自动化的场景编排。它不是替代 CFD 做精确仿真而是用 VLM 做感知 近似推断再在 Unity 里做视觉合理的动态表达。下面把整个思路、代码结构、踩坑记录都摊开讲。1. 项目全貌与核心思路1.1 为什么选 VLM 而不是传统气流仿真先说个现实问题吊扇气流分析如果交给 CFD 工具比如 Fluent、OpenFOAM、Airpak流程大概是——建立房间三维几何模型、划分体网格、设置风扇旋转区域边界条件、选取湍流模型、迭代计算、后处理出云图。这一整套下来单次仿真少说几十分钟多则几个小时而且每改一次风扇位置或转速就得重新来一遍。这在工程产品设计阶段当然没问题但在智能空间场景里我们更多时候要的是即时反馈用户把手机照片传给系统系统立刻告诉用户风扇在这个位置、风速大概能覆盖到沙发区域甚至把虚拟房间里的气流动画实时渲染出来。这要求的不只是算得快还要能理解图像语义——CFD 可看不懂一张照片里哪个是吊扇、哪个是吊灯。VLM 恰好补上了这个缺口。它具备图文理解能力能识别吊扇的形态、位置、朝向能从叶片形状估算大致转速档位甚至能通过画面里的场景元素沙发、床、桌椅推断气流影响范围。虽然它给不出精确的 PDE 数值解但能提供足够支撑可视化和近似分析的语义参数。我们最终要的是视觉上合理、实时可交互的气流表达而不是流体力学论文级精度所以 VLM 方案在架构上就是对的。1.2 整体工作流设计与数据闭环整个系统可以拆成三段感知段——通过摄像头或照片采集房间图像理解段——VLM 对图像做语义分析输出结构化 JSON风扇位置、数量、转速、方向等呈现段——Unity 接收 JSON在三维场景中生成粒子气流、流线路径和风速热区。有趣的是Unity 在这个链路里承担了双重角色。它不仅是最终的可视化呈现端还可以作为虚拟数据源——在 Unity 里搭建一个虚拟房间放置风扇模型用 RenderTexture 把虚拟画面拍成图片送给 VLM 做识别再把识别结果拿回来驱动可视化。这就是一个闭环自测系统真实世界照片可以跑通虚拟渲染图也能跑通两者共用同一套 VLM 接口和同一套 Unity 展示逻辑。这个设计带来的直接好处是调试效率大幅提升。我们不用每次都跑真实房间拍照直接在 Unity 里改虚拟场景就能验证 prompt 效果、测试坐标对齐、调试粒子参数。我在实际做的时候90% 的代码调试都是在虚拟闭环里完成的真实相机的接入在最后阶段才做起非常稳妥。1.3 为什么可视化呈现选 Unity选 Unity 不是因为它能算流场而是它做实时可视化的基建最齐全。粒子系统Particle System开箱即用LineRenderer 可以快速画流线自带的 UI 系统能叠加标注信息加上 Unity 有成熟的数据孪生生态后续接入 IoT 传感器、VR/AR 展示都是顺理成章的事。如果选 Web 前端方案也能做但做 3D 空间气流、多视角自由观察Unity 的效率会高很多。另外一点是 Unity 跨平台输出足够省心。调试时直接在编辑器里跑给客户演示时可以打包成 WebGL 或 Windows 可执行文件要是做移动端展示也有现成方案。这个项目做完刚好可以沉淀成一套VLM Unity的通用集成模板风扇气流只是第一个应用案例后面扩展到空调、取暖器、空气净化器都只需要替换 prompt 和可视化参数。2. 关键模块拆解VLM 识别与结构化输出2.1 设计一套能看懂风扇的提示词VLM 调用的核心在提示词Prompt设计。我之前最早踩过一个坑直接问模型这张图里的风扇在什么位置回答是在房间中央略偏右这种自然语言没法直接被 Unity 消费解析太痛苦。后来改为强制要求模型输出 JSON且字段、枚举值、坐标系都要预先约定好识别结果直接能进程序逻辑。我这里给出实际在用的提示词模板大家可以直接抄作业你是一个智能空间分析助手。请分析输入图片中的吊扇情况并只输出 JSON不要输出任何其他文字。 输出格式要求 { fan_count: int, fans: [ { id: int, position: {x: float, y: float}, relative_size: float, speed_level: int, blow_direction: down | side | up, oscillating: bool, obstacle_nearby: bool, confidence: float } ] } 字段说明 - position.x 和 position.y 是风扇中心在图像中的归一化坐标范围 0.0~1.0原点在图像左上角。 - relative_size 是风扇宽度占图像宽度的比例范围 0.0~1.0。 - speed_level 分 0停止、1低速、2中速、3高速根据叶片模糊程度判断。 - blow_direction 默认是 down吊扇默认向下吹风。 - obstacle_nearby 表示风扇下方附近是否有大型家具遮挡。 - confidence 是你对识别结果的置信度范围 0.0~1.0。这套提示词的效果是模型输出可以被json.loads直接解析Python 端或者用 Newtonsoft.Json 反序列化Unity 端。实际测试下来GPT-4V、Qwen-VL-Max 这类模型对 JSON 指令遵从度都很高偶发字段缺失可以通过默认值兜底。有个小技巧是在提示词末尾重复一句只输出 JSON模型就不容易额外解释一句根据图片分析……省掉不少清洗功夫。另外oscillating摆头和obstacle_nearby这两个布尔字段看起来很虚但对后续气流形态影响却大——摆头摆动范围要生成扇形扫掠气流有障碍则要在气流路径上添加遮挡偏转。2.2 从图像到坐标归一化与坐标系对齐VLM 输出的 position 是图像像素归一化坐标x、y 均为 0~1要在 Unity 里使用必须做一个坐标系映射。最简单的方案是提前在 Unity 场景里放置一个参考平面用于对齐真实照片中的房间布局。比如房间是 5m x 4m 的矩形把 Unity 平面对象也设成长宽 5m x 4m中心在原点。映射公式很简单Unity_X (image_x - 0.5) * room_width Unity_Z (0.5 - image_y) * room_depth注意 y 要取反因为图像坐标系的 y 轴朝下左上角原点而 Unity 世界坐标系 y 轴朝上我们用 Z 表示房间深度方向正好可以配合俯视平面布局。这个映射假设了相机近似平视或俯视 45 度以内在单目图像下没有深度信息必然存在误差但做可视化引导够用。更稳的做法是让 VLM 不仅仅输出像素坐标还输出风扇在房间平面布局中的相对比例坐标。例如提示词里增加一句如果画面是俯视或接近俯视请估计风扇在房间中的相对位置x 表示左右比例y 表示前后比例。 这类语义坐标比纯像素归一化坐标更贴近空间布局后期换算世界坐标也更自然。实测下来对大多数家居室内照片误差控制在房间尺寸的 10%~15% 之内作为气流影响范围可视化的锚点完全够用。2.3 常用 VLM 选型与调用方式VLM 选型直接决定识别质量和成本我按场景推荐三种云端通用模型GPT-4V、通义千问 VL识别质量最高语义理解能力强适合追求效果、不在乎延迟的场景。调用方式是 HTTP传图片 URL 或 Base64 编码返回 JSON。缺点是有网络延迟单次调用 1~3 秒还需要 API Key有按量计费成本。本地开源模型Qwen-VL、InternVL、LLaVA通过 Ollama、vLLM 或 Transformers 部署数据不出内网延迟低显卡够好的话几百毫秒适合做私有化部署。缺点是识别精度会差一点尤其是在叶片模糊判断转速档位这种细粒度任务上需要多调 prompt。NanoVLM手机端/边缘端例如通义千问的 tiny 版本或者经过量化的端侧多模态模型。适合打包到移动 App 里做离线识别但精度和输出稳定性都有限我一般只用作降级方案。调用规范上Unity 端统一用 UnityWebRequest POST 把图像 Base64 塞进 JSON body请求一个中转 APIPython FastAPI 或 Node 服务都行中转服务再转发给具体模型。这样做的好处是 Unity 端不用写死具体模型供应商的 API 协议换模型只改中转层。中转服务的代码也很简单我在后面第 4 节给个最小示例。3. Unity 端实现数据接入与气流可视化3.1 Unity 如何调外部模型服务并接收 JSONUnity 里调 HTTP 接口的标准姿势是用UnityWebRequest配合async/await或协程。我推荐用 async 方法代码直观不阻塞主线程太多。图像可以从摄像头取WebCamTexture、可以从 RenderTexture 抓虚拟场景自测也可以直接读取本地图片文件转成 Base64。下面是一个最小调用示例using System; using System.Text; using System.Collections.Generic; using UnityEngine; using UnityEngine.Networking; public class VLMClient : MonoBehaviour { public string apiUrl http://localhost:8000/vlm/analyze; public async void AnalyzeImage(Texture2D tex) { byte[] jpgBytes tex.EncodeToJPG(85); string base64 Convert.ToBase64String(jpgBytes); var payload new Dictionarystring, string { { image_base64, base64 } }; string jsonBody JsonUtility.ToJson(payload); using (var req new UnityWebRequest(apiUrl, POST)) { byte[] bodyRaw Encoding.UTF8.GetBytes(jsonBody); req.uploadHandler new UploadHandlerRaw(bodyRaw); req.downloadHandler new DownloadHandlerBuffer(); req.SetRequestHeader(Content-Type, application/json); var op req.SendWebRequest(); while (!op.isDone) await System.Threading.Tasks.Task.Yield(); if (req.result UnityWebRequest.Result.Success) { string respJson req.downloadHandler.text; var result JsonUtility.FromJsonVLMResponse(respJson); OnVLMResult(result); } else { Debug.LogError(VLM request failed: req.error); } } } }这里有个坑Unity 的JsonUtility不支持直接反序列化顶层数组也不支持Dictionary。所以响应结构最好设计成根对象 数组字段并在 Unity 里定义对应的[Serializable]类。如果需要更灵活的解析强烈建议引入 Newtonsoft.Jsoncom.unity.nuget.newtonsoft-json它对 List、GUID、字典等支持都更完善能省很多事。3.2 用粒子系统做气流矢量流动可视化核心是粒子系统。Unity 的 Particle System 默认是按固定方向喷射粒子但我们要的是气流在空间中的方向变化、速度衰减、扩散效应所以不能只用默认参数。我的实现方案是把粒子系统拆成两层第一层是发射层。创建一个空物体放在风扇位置下偏一点的位置模拟气流出口挂 Particle SystemEmission 速率设高一点100~300 个/秒Start Lifetime 设 2~4 秒Start Speed 由 VLM 的speed_level映射。映射关系我按经验设level 1 - 2.0 m/slevel 2 - 3.5 m/slevel 3 - 5.0 m/s。注意这只是一个视觉映射不代表真实风速但能让观众直观感受到高档比低档快。第二层是导向层。粒子发射后不能一直直线飞要模拟气流下坠、受阻偏转、水平扩散。这里我不用粒子系统的物理碰撞开销大、不可控而是在 C# 脚本里对每个粒子施加自定义力。具体做法是写一个AirflowController : MonoBehaviour实现ParticleSystem.trigger或直接每帧遍历粒子修改速度public class AirflowParticleUpdater : MonoBehaviour { public ParticleSystem ps; public Vector3 windDirection Vector3.down; public float spreadRadius 0.8f; private ParticleSystem.Particle[] particles; private int maxParticles 1000; void Update() { if (particles null || particles.Length ps.main.maxParticles) particles new ParticleSystem.Particle[ps.main.maxParticles]; int count ps.GetParticles(particles); float dt Time.deltaTime; for (int i 0; i count; i) { // 基础速度初始方向 微小的水平扩散 Vector3 vel particles[i].velocity; vel windDirection * 2.0f * dt; vel new Vector3( (Mathf.PerlinNoise(particles[i].position.x * 0.5f, Time.time) - 0.5f) * spreadRadius, 0f, (Mathf.PerlinNoise(particles[i].position.z * 0.5f, Time.time 100f) - 0.5f) * spreadRadius ); // 遇到障碍物Unity Collider时做简单偏转 if (Physics.Raycast(particles[i].position, vel.normalized, out RaycastHit hit, 0.5f)) { vel Vector3.Reflect(vel, hit.normal) * 0.4f; } particles[i].velocity vel; // 粒子生命周期根据速度衰减模拟气流减速 particles[i].remainingLifetime Mathf.Lerp(particles[i].remainingLifetime, 1.5f, dt); } ps.SetParticles(particles, count); } }用 PerlinNoise 做随机扩散比纯随机向量更平滑看起来气流更自然不会出现粒子到处乱蹦的爆炸感。这个效果实测下来非常接近真实气流那种湍流但整体有方向的感觉。3.3 流线与热力分布的近似可视化粒子流能表现动态气流但在范围覆盖的表现上不够直观。我还叠加了两层可视化流线路径和地面热力区。流线我用 LineRenderer 实现。根据 VLM 输出的风扇中心位置和房间布局生成几条从风扇出发、向房间边界延伸的曲线路径曲线控制点按气流扩散规律分布——中心线继续向前边缘线慢慢向外弯。代码上可以用三次贝塞尔曲线控制点参数根据speed_level和obstacle_nearby动态调整。例如低速时曲线更早下坠、扩散更窄高速时曲线向前延伸更远扩散也更宽。热力区更简单在地面上放置一个平面网格通过脚本控制每个格子的顶点颜色从风扇中心向外做径向衰减。颜色从红色高风速渐变到蓝色低风速透明度同步衰减。这个效果类似 CFD 后处理里的风速云图虽然数据不是来自真实流场求解但视觉表达上完全够用。需要强调一点这种近似可视化不是 CFD 的替代品。论文级气流分析仍然要用真实仿真数据但做数字孪生展示、IoT 联动、教学演示、方案汇报VLM Unity 的链路性价比极高快速出活、随传随看。4. 实操过程从零跑通最小链路4.1 环境准备与依赖先把用到的工具链摆出来Unity 2022.3 LTS其他版本也行但 LTS 最稳Newtonsoft.Json 包PackageManager 搜 com.unity.nuget.newtonsoft-jsonPython 3.10搭建中转服务VLM API Key或者本地装 Ollama qwen2.5-vl一张吊扇房间照片或者 Unity 自建虚拟房间 RenderTexture需要注意如果你用WebCamTexture在编辑器里测摄像头Unity 编辑器需要授予摄像头权限打包后如果用 WebGL 还要处理浏览器权限弹窗。为了调试顺畅我建议先把本地图片读取路径走通再接摄像头实时流。4.2 最小链路搭建步骤第一步验证 VLM 返回结果先用 Python 快速调一次模型不急着写 Unity。我用 FastAPI 写的最简中转服务from fastapi import FastAPI from pydantic import BaseModel import base64, json, requests app FastAPI() class AnalyzeRequest(BaseModel): image_base64: str app.post(/vlm/analyze) async def analyze_image(req: AnalyzeRequest): image_bytes base64.b64decode(req.image_base64) # 调用云端模型这里以 OpenAI 兼容接口为例 resp requests.post( https://api.vendor.example.com/v1/chat/completions, headers{Authorization: Bearer YOUR_API_KEY}, json{ model: qwen-vl-max, messages: [ {role: user, content: [ {type: image_url, image_url: {url: data:image/jpeg;base64,...}}, {type: text, text: PROMPT} ]} ] } ) content resp.json()[choices][0][message][content] # 清理可能包裹的 json ... 标记 content content.strip().replace(json, ).replace(, ) return json.loads(content)这一步的关键是内容清洗。大部分模型在 prompt 明确要求后不会再输出代码块但保险起见还是做一下 strip。跑通后你能在命令行看到类似下面的 JSON{ fan_count: 1, fans: [ { id: 0, position: {x: 0.42, y: 0.38}, relative_size: 0.22, speed_level: 2, blow_direction: down, oscillating: true, obstacle_nearby: false, confidence: 0.91 } ] }第二步Unity 里先做模拟数据测试这一步很关键先不接 VLM在 Unity 里写一个脚本模拟上面的 JSON看可视化效果是否达标。我遇到的情况是第一次生成的粒子只往一个方向喷完全不像气流后来把粒子 Updater 加上扩散和衰减逻辑才自然起来。所以千万别跳过去直接接网络请求不然视觉调优会非常痛苦。在这个阶段把三件事搞定粒子参数调出气流感、LineRenderer 流线呈扇形展开、地面热力区变色平滑。调好以后再去接真数据省时省力。第三步接入 UnityWebRequest 做实时识别上一步通过后把第 3.1 节的 VLMClient 脚本挂到主相机或一个管理空物体上。图片源可以灵活切换先用Resources.Load测试图片再用 WebCamTexture 摄像头抓帧最后再尝试 RenderTexture 虚拟场景截图。抓摄像头帧的代码片段IEnumerator CaptureFrame() { yield return new WaitForEndOfFrame(); var tex new Texture2D(camTexture.width, camTexture.height); tex.SetPixels(camTexture.GetPixels()); tex.Apply(); vlmClient.AnalyzeImage(tex); }注意摄像头纹理的GetPixels要放到帧末调用否则会抓到不完整的一帧。帧率控制上我一般每 3~5 秒采样一次VLM 单次推理 1~3 秒也和这个节奏匹配。第四步坐标映射与场景元素生成识别结果拿到后把position.x / position.y按第 2.2 节的公式换算成世界坐标在对应位置生成/移动一个风扇锚点空物体然后让粒子系统挂到这个锚点下面。每次识别得到新数据先判断风扇数量、位置是否变化如果变化就Clear()粒子再重新发射如果只变化了speed_level直接修改粒子系统的 Start Speed保留已有粒子避免闪烁。4.3 性能、延迟与降级策略实时链路最怕的是模型调用延迟导致 Unity 主线程卡顿。我的方案是VLM 请求放在异步方法里不阻塞主线程结果回来以后只在主线程里更新场景参数。如果识别结果没变化就做缓存不重复调用模型。降级策略必须做。模型偶尔会输出非法 JSON、识别不到风扇、或者完全不相关的内容。我在 Unity 端定义了DefaultProfile如果解析失败或fan_count 0就把风扇视为场景右上角、转速中等、方向向下继续渲染一个占位气流。同时 UI 上提示未识别到风扇展示默认气流。这样演示过程中不会黑屏或卡死体验会好很多。性能方面粒子数量是最大开销。编辑器里我开到 1500 个粒子不卡WebGL 建议降到 500 个以内移动端建议 200 个左右加 GPU Instancing。也可以把 Particle System 的Max Particles调低用更粗的粒子加 Trail 模拟气流轨迹视觉密度也够。5. 踩坑记录与调试速查5.1 Unity 解析 JSON 的坑JsonUtility不能直接解析顶层数组也不能解析Dictionary嵌套 List 支持也差。项目刚从 Python 后端联调时我直接用JsonUtility.FromJsonListFanData(json)结果返回空列表调试半天才发现是这个原因。换成 Newtonsoft.Json 后所有问题一次性解决var result JsonConvert.DeserializeObjectVLMResponse(respJson);另一个高频坑是大模型返回 JSON 时偶尔带 Markdown 代码块标记。即便提示词里反复要求只输出 JSON还是有概率输出json {...}所以中转服务里一定要做清洗把首尾的 json 和 干掉。Unity 端也建议再兜底一次检查如果 respJson.TrimStart().StartsWith({) 为 false就做一次子串截取。 ### 5.2 识别与坐标对齐的偏差问题 坐标偏差主要来自摄像头视角和实际房间布局的不匹配。我实测仰拍照片时VLM 输出的归一化坐标与真实位置偏差明显偏大因为透视畸变让风扇在画面里的相对位置不能直接映射到二维俯视平面。解决办法是设置参考物。 在提示词里加一句画面中如果有窗户、门或已知尺寸的家具如床宽 1.8m、茶几宽 0.6m请以它们作为参考估计风扇的实际相对位置。这能让 VLM 输出的坐标从像素比例进化为空间比例误差从 20% 以上降到了 10% 以内。 还有一个细节相机如果开启镜像图像坐标 x 轴要取反。移动端前置摄像头默认镜像这在接入 WebCamTexture 时特别容易出问题症状是粒子出现在镜像对称的位置。排查时可以放一个明显的标记物比如红色方块来验证左右映射方向。 ### 5.3 粒子性能与画面表达的优化 粒子系统参数直接决定效果和性能平衡。我的最终参数组合供参考 - Emission Rate Over Time200编辑器和桌面端移动端降到 80 - Start Lifetime随机 1.8~3.2 秒 - Start Speed由 VLM 速度等级映射 - Simulation SpaceWorld方便自定义向量修改 - Max Particles1000 以内 另外建议开 Particle System 的 Collision 模块时务必谨慎Unity 内置粒子碰撞是按单个粒子与 Collider 做检测粒子数量多时开销很大。我的方案是关掉内置碰撞改用第 3.2 节里的 Raycast 逻辑只对少量粒子做检测或者在认定无法穿过障碍物的区域提前把粒子速度压低视觉上也有碰撞效果但开销小得多。 ### 5.4 模型幻觉与安全边界 VLM 偶尔会胡诌明明图片里没有风扇它也能给你编一个置信度 0.95 的识别结果。尤其当图片模糊、光线暗、或风扇被遮挡的时候。工程上要有两道防线第一设置 confidence 阈值我设 0.6低于阈值就不启用识别结果第二把 VLM 的输出当成建议参数Unity 端永远有手动覆盖入口运营人员或用户可以在 UI 上手动修正风扇位置、转速。 更要强调一点不要让 VLM 直接控制真实设备。如果这个系统后续接入真实风扇控制VLM 只能作为感知层输出建议实际调速必须经过规则引擎或人工确认。尤其依据视觉推断的转速自动加大风扇这个功能我强烈不建议做——视觉识别本身有误差推断错误会带来真实物理后果安全和体验风险都太大了。 ### 5.5 常见问题速查表 | 现象 | 可能原因 | 解决办法 | | --- | --- | --- | | Unity 解析 JSON 返回空 | 用了 JsonUtility 解析数组 | 换 Newtonsoft.Json | | 模型返回带 Markdown 代码块 | 模型输出格式不稳 | 中转服务清洗去掉 json 标记 | | 粒子一直朝一个方向飞 | 自定义 Updater 未生效或脚本没挂上 | 检查粒子 Simulation Space 是否 World脚本是否挂到粒子系统同物体 | | 粒子卡顿严重 | 粒子数量过高或开了内置碰撞 | 调低 Max Particles关闭内置碰撞 | | 识别坐标左右颠倒 | 相机镜像未处理 | x 取反x_new 1 - x | | 多次识别后场景抖动 | 坐标映射噪声 | 对位置做平滑插值Lerp | | 模型识别不到风扇 | 图片不清晰或房间杂乱 | 提高图片分辨率、补光降低 confidence 阈值到 0.4 | | 编辑器里 camera 黑屏 | WebCamTexture 权限未给 | 包设置里打开摄像头权限编辑器运行时系统弹窗允许 | ## 6. 项目后续扩展思路 抛开这个具体项目看VLM Unity 这套组合的潜力远不止吊扇气流分析。我做完以后最大的感受是Unity 不只是一个游戏引擎它作为空间计算和数字孪生平台天然适合承接大模型的语义理解结果而 VLM 也不只是看图说话它可以成为自动化的感知引擎。 紧接着我就在盘几个扩展方向多风扇联动场景比如一个房间装了两台吊扇VLM 识别出各自位置和转速后Unity 里同时渲染两股气流并叠加干涉区域——这在传统 CFD 里面要算流场耦合工作量巨大但可视化层面的近似叠加效果相当直观也够做决策展示用。还有和真实 IoT 联动风扇加装基础的电流传感器或转速传感器把 VLM 识别结果作为辅助校验信号两路数据交叉验证既提升可靠性又能做异常检测。以及自动巡检方向一个无人机或固定摄像头周期性拍摄房间VLM 自动识别所有设备状态并同步到数字孪生场景里等于给虚拟场景装了一双自动的眼睛。 最后再分享一个小技巧VLM 的可视化驱动不一定要输出精确数值才用。哪怕它只是给了一个定性的描述——风扇很大、转速很快、旁边有柜子遮挡你也可以让 Unity 基于这些语义自动选一套预设的可视化模板。先把定性做实再逐步逼近定量。这套思路在快速原型验证阶段特别管用能让你在不确定模型精度的前提下先把产品体验和交互流程跑通再考虑精度优化。我在实际项目里很多时候就是先靠定性模板做出了一版效果给客户看拿到反馈后才投入算力去做量化校准效率翻倍。