我不会写代码，但用Codex一天半做了一个三维空间 Demo

“一个完全不会写代码的人，是如何把一个临时冒出来的想法，慢慢做成了能点、能看、能管理的页面。”

作者 |陈泽邦

编辑/排版 |MM77

翠鸟AI技术漫研—拓新AI边界、探索技术增量

这不是一篇“我学会写代码了”的故事；恰恰相反，我到现在依然不会写代码。

但我开始能够把一个很模糊的想法说清楚，并和 AI 一起把它做成真的。

事情的开始很偶然。

有一天我看着一张办公空间的平面内容，突然冒出一个念头：

如果这些房间、桌椅、灯、摄像头、传感器不只是图纸上的符号，而是一个能看、能点、能筛选、能补充信息的对象，会是什么样？

人在看空间时，能顺手看到设备；

在看设备时，能知道它的位置、状态和附加信息；

当空间里有很多点位时，不需要在一张密密麻麻的二维图上反复找。

我想做的不是一个三维模型，而是一个“可以使用”的空间页面。

从一张平面图，到一个可以被使用的空间

如果完全从零建模，这件事对我来说基本就结束了。所以我一开始想找的，不是一个很复杂的开发方案，而是有没有办法从现有平面图和图元信息出发，先把空间搭起来。

在这个过程中，我用到了翠鸟工创云。

它给我的第一感觉不是“多了一个好看的模型”，而是把原本分散的图纸、图元、区域、设备这些东西，整理成了一套能继续往下用的空间关系。

这一步对我挺关键的。因为后面做页面时，我不是在一堆孤立的模型上硬贴功能，而是在一个已经有区域、有设备、有空间关系的基础上继续试。

我当时并没有先想到什么架构、接口、业务闭环这些词；只是觉得：既然空间已经整理出来了，那能不能把它做成一个更像产品的页面？

我的起点不是代码，而是把资料交给 Codex

我完全没有代码基础。

面对 SDK 文件、部署包、项目目录，我一开始是懵的。哪个文件重要，先启动哪个服务，报错以后该看哪里，我都不知道。

所以我的第一步很笨：

把 SDK 文档、部署文件和项目目录交给 Codex，让它先读。我的要求也很简单：先帮我看看这个项目，跑起来，再告诉我现在能做什么。

这一步反而让我放松了一点。因为我不用假装自己懂技术，也不用把问题包装成很专业的表达。

我只要说清楚“我想看到什么”，剩下的事情就可以一边看效果一边调整。

当然，过程也不是一路顺的。

有时候页面跑不起来，有时候灯光效果不对，有时候我以为能在前端改的东西，后来发现要回到空间治理里处理。很多判断都是边做边知道的。

功能不是一开始规划出来的，是边看边长出来的

这个页面没有一开始就写好完整需求，很多功能都是我盯着三维空间时临时想到的。

看到一堆灯，我就想能不能直接点开关；

灯亮起来以后，又觉得蓝色不像办公室的灯，想换成偏暖的黄白色；

再看一会儿，又觉得管灯和筒灯亮度不太一致；

看到摄像头，我会想这里以后应该有视频流，那弹窗里是不是先留一个位置；

看到设备太多，我又想按设备 ID 和类型筛一下；

看到区域信息，我又想到租户和能耗；

这些想法很碎，也不太像正式需求。但真实做东西的时候，好像就是这样：先看到一个不舒服的地方，再想能不能顺手改一下。

我后来觉得，这个 Demo 最有意思的地方不是功能有多复杂，而是很多想法可以先落到页面上，看一眼，再决定要不要继续。

一天半里，这个空间页面慢慢长出了什么？

做着做着，页面开始不只是“打开一个三维场景”。

它开始承担一些更贴近实际管理的工作：例如，设备空间化、租户/区域运营，按区域理解能耗。

租户管理里，区域不只是“报告厅”“办公室”这样的名字，而是带上出租状态、面积、业主和联系人。

第一是，设备空间化管理。

设备管理是最先变清楚的。以前设备像是表格里的一行数据，现在它同时出现在左侧列表和三维空间里。

点一下，就知道它大概在哪个区域、是什么类型、现在是什么状态。

灯具的开关效果也很直观。关灯就是收回状态，开灯就让对应位置亮起来。

这个小功能看起来不大，但它让我第一次觉得：哦，三维空间里的对象真的可以参与页面逻辑，而不是只负责展示。

关灯：状态与空间保持一致。

开灯：暖白灯效直接反馈到空间里

第二是，租户和区域运营。

能耗管理里，数字也不只是总量，而是落回到具体区域上——把“哪个区域用得更多、异常可能在哪里”直接叠加到空间上。

第三是，按空间理解能耗。

• 页面支持水、电两类视图，以及日、周、月、年等时间维度；
• 左侧展示本层总量、区域均值、平均空调温度、用量最高区域和区域排行榜，
• 三维区域则通过不同颜色形成热力分布。

管理者看一眼就能判断：本月耗电高的是公共区域还是办公区，异常值集中在哪个位置，接下来应该先去看哪里。

电能耗：按区域展示用量与热力分布。

水能耗：切换指标后，空间仍是理解数据的入口。

对我来说，真正重要的不是某个按钮，而是三维空间开始变成一个入口：设备、区域、状态、能耗这些信息，都可以围着空间组织起来。

这正是我一开始想要的：三维空间不是一张漂亮的背景图，而是一种更直观的工作入口。

我开始理解，三维数据化不是给模型贴标签

做着做着，我对“三维数据化”这件事有了一个更直白的理解。

它不是把几个设备名称飘在模型上，也不是做一个可以旋转的 3D 展厅；真正的三维数据化，是让空间里的每一个对象都能进入前端应用逻辑：

• 它在哪里；
• 它是什么类型；
• 它和哪个设备有关；
• 它目前是什么状态；
• 用户点击它以后，应该看到什么；
• 它未来可以和哪些业务信息连接起来。

中间会有一些很现实的小问题：

比如设备 ID 重复，两盏灯在三维点击时可能会被当成同一个对象；

又比如区域地板颜色，我一开始以为前端能随便改，后来才知道有些基础关系和材质还是应该回到空间治理里维护。

这些问题不算大，但它们让我意识到：三维空间不是背景图。它里面的对象、区域和关系，如果没有整理清楚，后面做应用就会一直被这些细节绊住。

最后：想法能先跑起来，讨论就不一样了

这一天半里，我没有学会写代码。

我做的事情其实一直很普通：看页面、提问题、判断效果、继续改。只是这一次，很多过去会卡在“我不会写代码”的地方，被工具一点点接住了。

我也不觉得这件事是在证明“一个人一天半能做完数字孪生”。

这话太大了，也不真实。它更像是让我看到了一种新的开始方式：先把想法做成一个能跑的原型，再围着原型继续讨论。

如果只是口头说“我想做一个三维数据空间”，大家可能很难想象。

但当页面真的能打开，灯真的能点亮，区域真的能显示租户和能耗，讨论就会变得具体很多。

一天半，我还是不会写代码。

但我把一个突然冒出来的念头，做成了一个能运行、能点击、能继续生长的三维空间Demo。

我想，这就是 AI 开发真正让人兴奋的地方：

它没有替代人的想法，反而让更多人的想法终于有机会被实现。