一段哈利法塔的 AI 建模演示，把建筑师使用 token 的问题从聊天窗口带进了生产现场。
演示对象：哈利法塔系统模型。画面显示 828 米、163 层、7 个机械层和分层切换的机电系统。它展示的重点，是 AI 如何把复杂建筑资料转成可浏览、可解释、可继续加工的模型。
原帖视频制作的浏览器模型演示：建筑结构、楼层和机电系统按图层切换。
Solvaix 在 X 上展示了一段由 Claude Opus 5.5 生成的哈利法塔浏览器模型。帖文列出的元素包括核心筒、外伸桁架、57 部电梯、逐层风管、喷淋头、冷冻水回路、电缆桥架、194 根桩和 3.7 米厚的筏板。帖主把它描述为“21,133 个元素”的联邦模型。
这些数字和元素属于原帖口径。视频真正展示出来的，是模型如何按楼层、系统和对象切换。结构、机械层、管线和竖向交通被放进同一套可视层级，观看者可以沿着建筑高度理解设备如何分布。
token 被花在了一条连续的任务链上。
建筑师使用模型时，token 对应的工作不止一次提问。模型要读取项目资料，理解空间和构件关系。它还要保留上下文，生成中间结果，再根据反馈继续修改。
哈利法塔这个演示可以被拆成几个生产动作。先整理建筑信息，再生成结构和机电对象。接着建立图层与浏览关系，最后输出一个客户和团队都能打开的浏览器模型。每一次上下文传递，都服务于下一步结果。
视频中段画面：模型按楼层和系统展开，复杂设备被组织成可切换的视觉层。
这也是 token 进入建筑生产后需要记录的内容。项目要保留所用资料、提出的约束和生成的中间版本。人工保留或修改了哪些结果，也应当留下记录。单次演示的价值有限，能反复调用的上下文、规则和检查步骤，才会沉淀成工作能力。
AI 建模先改变效率，再改变表达方式。
如果输入、生成、验证和交付被稳定串起来，AI 可以整理项目资料，批量处理重复建模动作，快速生成多个表达版本。它也可以把复杂系统转成客户和团队都能理解的浏览界面。
哈利法塔官方资料显示，这座建筑高 828 米，设有 57 部电梯和 7 个双层机械层。基础由 3.7 米厚的钢筋混凝土筏板和灌注桩支撑。官方还列出每天约 946,000 升的供水量，冷凝水回收系统每年可补充约 1,500 万加仑的水。
这些系统让建筑设计的 AI 化有了具体对象。模型需要理解的不只是外形，还包括设备、交通、结构、维护和交付之间的关系。浏览器模型把这些关系先变成可见的讲解界面，正式 BIM 文件继续承担构件属性、坐标、版本、碰撞关系和维护数据。
视频末段画面：系统图层与建筑剖面叠合，模型以浏览器中的可视化方式收束。
建筑师要建立自己的 AI 生产方法。
项目资料如何进入模型，哪些判断交给 AI，哪些结果需要人工确认，都应该写进流程。模型输出还要进入 Revit、Navisworks、浏览器模型或汇报文件。
帖主给出的边界同样清楚。这类浏览器模型短期内不会取代 Revit 或 Navisworks，更适合在正式模型打开前，带客户或新成员快速走一遍系统。
原帖还说明，哈利法塔的真实 BIM 模型并未公开，视频中的系统路径是示意性的。
这段演示没有公布具体 token 消耗量，也没有提供工程交付测试。它把观察重点放在两个问题上。AI 能把多少建筑资料转成可继续加工的中间成果？设计师能否把这些成果接回真实的软件、判断和交付流程？
来源：Solvaix X 帖；哈利法塔官方结构与建筑资料。