#WorkBuddy# 我把一张充电桩平面示意图做成了可旋转、与原图 100% 对位的 3D 场景（附踩坑全过程）

引子

我最近在做一个商场停车场充电桩建设方案，手头只有一张平面布局示意图（白底线稿）。领导要拿它做汇报，希望"立起来"——最好能在会上旋转、缩放、俯视核对。我想到用 WorkBuddy 的 3D 与图像生成能力来做这件事，结果前后经历了三次迭代才真正达标。这篇文章把我的完整踩坑过程写下来，重点说清楚为什么 AI 生图保证不了精确对位，以及最终靠程序化建模才解决，文末附可复用的坐标映射代码。

一、先澄清产物形态（别急着生成）

"把平面图做成 3D"这句话其实对应两种产物。WorkBuddy 先通过提问帮我澄清了：

• 3D 模型文件（.glb / .obj）：可在网页旋转缩放的真实模型，但对单张照片里的主体效果最好，把整张建筑平面图一次还原成完整场景能力有限。
• 立体渲染图（图生图）：一张有立体感的 2D 图，不可旋转，更贴近汇报展示。

我的用途是汇报展示，所以方向定为"立体效果"。起初我走的是图像生成路线。

图1：原图-充电桩布局示意图

二、第一次翻车：没用我给的示意图，凭想象生图

这是最该记的一段。我让 WorkBuddy 用图像生成能力出了一版停车场鸟瞰渲染图（见下方配图），它自认为还原了我的原图。结果我一比对就发现不对：充电桩数量、位置都和我的平面图对不上。

根因后来才清楚：那次生成根本没有用到我给的示意图，而是 WorkBuddy 按文件名和常见场景"想象"出来的。原图本身是一张纯灰阶黑白线稿（1920×1329，最大饱和度仅 32，彩色像素占比 0.047%），连颜色都区分不了设备，模型当时也没真正读进去，于是就凭空编了一套布局去生图。

教训：以某张图为准的任务，一定要让工具真正读到图，并逐元素核对，绝不能被"看起来像"的想象图骗过。

图2：AI 凭想象生成的 3D 渲染图（数量、位置与原图不符）

三、第二次：用原图确认布局，生成布局一致的渲染图（但不够真实）

我重新把示意图交给 WorkBuddy，这次它真正读图了，并先把读到的内容整理成文字描述让我逐项确认。关键数据如下：

• 24 个车位，北排 13–24 自西向东递增，南排 12–01 自西向东递减（编号方向与北排相反，容易错）
• 12 台 120kW 双枪充电桩，南北通道各 6 台，每台服务相邻 2 个车位
• 箱式变压器 1 台，在停车场北侧外缘（北排 17–19 正北方向、虚线框外）
• 低压柜 1 个，在中央通道正中心

确认无误后，WorkBuddy 改用 Three.js 按坐标精确建模。这里的核心认知是：AI 生图是概率性的，只有代码按坐标放置元素，才能做到数量、位置 100% 对位。

坐标映射的关键代码（车位宽 2.5m、长 5.5m、通道宽 6m）：

// 车位序号 -> X 坐标
function idxX(i){ return (i - 5.5) * 2.5; }
// 北排：车位号 n(13..24) -> 序号 n-13
function northX(n){ return idxX(n - 13); }
// 南排：车位号 n(12..01) -> 序号 12-n（方向相反！）
function southX(n){ return idxX(12 - n); }
// 充电桩 x：南北对齐，取相邻车位中点
const chargerX = [-12.5, -7.5, -2.5, 2.5, 7.5, 12.5];

页面用 ES module + importmap 从 CDN 引入 Three.js，必须走 HTTP 协议（file:// 会因 CORS 白屏）。本地预览命令：

python -m http.server 18899
# 浏览器打开 http://localhost:18899/charging_station_3d.html

这一版布局和我原图严格一致，可旋转、可俯视核对，但渲染质量偏"工程示意"——材质简单、光照平，离"实物感"还有距离。

图3：第二次成果（与原图布局 一致）

四、第三次：优化渲染质量，补充场景细节

我要求 WorkBuddy 把真实感做上去。这版（布局坐标不变，只升级材质与光照）改了几处关键：

// 1) 真实大气散射天空，只放 Sky 烘焙环境反射，避免把场地烘进反射
const tmp = new THREE.Scene(); tmp.add(makeSky());
scene.environment = pmrem.fromScene(tmp).texture;
// 2) 电影级色调映射（默认 Linear 会显塑料感）
renderer.toneMapping = THREE.ACESFilmicToneMapping;
renderer.toneMappingExposure = 0.92;
// 3) 车漆用清漆层材质
const paint = new THREE.MeshPhysicalMaterial({
  color, metalness: 0.78, roughness: 0.26,
  clearcoat: 1.0, clearcoatRoughness: 0.05
});

同时补充了大量场景细节：真实天空与太阳光晕、PMREM 环境反射让车身和金属有反射、车辆用流线型轮廓拉伸成型、充电桩加了散热格栅 / 状态灯条 / 双枪线缆、箱变加了百叶窗与高压警示牌、低压柜加了双开门与把手；场景层面还放了行车方向箭头、路灯、树木、草地外场。

到这一步，画面已经接近实物级，能直接用于汇报。

图4：第三次成果（优化渲染细节）

五、踩坑清单（我学到的几条）

1. 布局精确对位，AI 生图做不到：汇报级"数量、位置、布局一致"的需求，别指望概率性生成，程序化建模才是正解。
2. 以图为准的任务，先确认工具真读图：别被"看起来像"的想象图骗过，生成后务必逐元素与原图核对。
3. Three.js 必须走 HTTP 打开：ES module + importmap 用 file:// 会白屏，本地起一个 http.server 即可。
4. 先确认布局再谈真实感：顺序错了就是返工。我正是先搞定"对位"（第二次），再优化"真实感"（第三次），避免了一边改布局一边改材质的内耗。

六、后续还能怎么继续优化

如果还要往下做，我列几个方向：

• 夜景 / 傍晚版：点亮充电指示灯与路灯，汇报时更抓眼
• 充电枪连接到车辆：体现"正在使用"的状态
• 导出 PNG 静帧：斜视 / 俯视 / 车行视角各一张，直接插入 PPT
• 离线单文件版：把 Three.js 内联进 HTML，不依赖 CDN，便于拷给别人
• 车辆进一步真实化：可引入外部合规的 GLTF 车型资产，进一步提升车辆真实度

七、总结

• 成本：图像生成约 1 张 × 5–10 积分；建模本身不耗积分，主要是多轮对话与代码迭代。
• 收益：拿到一个可旋转、可缩放、与原图 100% 对位的 3D 场景，经得起评审逐一点数核对。
• 核心结论：先保证"对位"，再追求"真实感"——这个顺序让我少走了很多弯路。

如果你也在用 WorkBuddy 做工程可视化，欢迎在评论区聊聊你的路径。