GPT-6 Astra 3D 实测：一句话造出一栋能走进去的房子

原作者：Thomas Ricouard 原文链接：https://elsewhere.news/en/crossing/openai-gpt-6-astra

结论先行

OpenAI Codex 工程师 Thomas Ricouard 只说了一句话——「我要一栋极简、家具有质感、带花园、有电影感的房子」——Astra 就用 Blender Python API（bpy） 建出了可编辑场景，一路迭代成完整住宅，再经 FBX + JSON 场景描述导入 Unreal Engine 5，变成能第一人称漫步、按 E 开门和开橱柜的应用。对 Web3D 从业者最有价值的一点：它不是吐贴图或后期效果，而是建真的模型，并能自己检查渲染图，修法线、修穿模。但平面图只是概念演示，离能发布上线还需要专业人士复核。

原文出处

作者：Thomas Ricouard（OpenAI Codex 工程师） 原文：Hands-On with OpenAI GPT-6 Astra: Building a Walkable House from a Single Sentence 发布：2026-09-06（Crossing / elsewhere） 链接：https://elsewhere.news/en/crossing/openai-gpt-6-astra

编者按称这是目前关于 GPT-6 Astra 最翔实的评测之一，展示了两项能力：能直接在 Blender 里做 3D，以及会主动验证并优化自己的成果。房子被命名为 Solace。

要点解读

1. 流程顺序比 prompt 本身更重要

作者的起点只有一句话：

“I want a minimalist house with refined furniture, a garden, and a cinematic look.”

随后是这条链：先描述场景 → 在 Blender 生成可编辑场景 → 先画平面图确认 → 再扩建为完整住宅 → 导出 UE5 做实时可漫步。他特别强调顺序不能乱：

“The order matters: review the floor plan first, then the model, and only then invest extra effort in a real-time experience version.”

平面图阶段 Astra 给出的是单层 U 形住宅围合一个种植庭院：中央是起居/餐厅/厨房，两翼是三间卧室、办公室、多个卫浴和步入式衣帽间。它还处理了动线问题——卧室不做过道、庭院形成 circulation loop 避免穿越厨房工作区。

本站判断：这一步是整篇最值得背诵的。直接从「一句话」跳到「实时场景」是多数人踩坑的根源；把平面图当成中间产物显式确认，等于给后面所有昂贵的渲染和烘焙的成本加了一道槛。

2. 它会自己检查渲染并修错——这是走向 computer use 非常大的进步

Astra 第一轮生成后没有宣布完成：

“Astra didn't call it done after the first pass. It reviewed the preview images itself, adjusted the composition and lighting, and even fixed details like plants clipping into each other and an unnaturally placed sofa throw.”

一个具体例子：渲染图里水槽的法线错了，本该平坦的盆底看起来被压扁；它就自己修正法线、重做圆角后再渲染，画面干净了，而厨房设计本身没被动过。

它还能用 --python flag 在后台跑 Blender 定位相机、选镜头、出图，同时通过 computer use 打开 Blender，把应用内场景和已保存的渲染做对比。官方基准的提升也印证了这点：ScreenSpot-Pro 从 76.9% → 92.7%，BenchCAD 从 83.3% → 95.9%。

本站判断：闭环「渲染 → 看图 → 改模型」才是 agent 做 3D 的真正门槛，比「生成一段 Three.js 代码」难得多。能自己发现法线错误，说明它确实在看图，不是盲写脚本。

3. 细节是真模型，不是贴图

这是区分「能看」和「能用」的关键。Astra 建的是真正建模到场景里的几何体：

  • 陶器、水槽、洗脸盆是真正挖空的（carved-out interiors）
  • 床有 frame / slats / mattress，bedding 的褶皱是建模出来的——所以不需要跑布料模拟
  • 衣柜内部有 shelves 和 hanging rod；办公桌带 cable management
  • 厨房有 oven cavity、grill、cutlery drawers
  • 后期加的餐具是 hollowed dishware、fluted glasses、带缝线的折叠亚麻

“None of this is textures or post-processing — these are actual models built into the scene.”

材质上它对齐了木纹方向，纹理比例匹配家具的真实世界尺寸（用了 Poly Haven 的 oak / walnut / plaster 扫描，含 White Oak Veneer）。

4. Blender → Unreal 的导出链：FBX + JSON 场景描述

Astra 自己写了一套导出/导入工具：

  • 几何体导出为 FBX，并应用修改器（包括从 Blender curves 生成的细节）
  • 附带一份 JSON scene description，记录每个部件的位置、所用材质，以及灯光和相机的布置方式，Unreal 据此重建场景
  • 处理单位差异（Blender 用米，Unreal 用厘米）和坐标轴差异
  • 重复树木共享 instanced mesh，森林里每棵树不必各自持有完整几何
  • 材质按 wood / stone / fabric / glass / water 分别构建对应 Unreal 材质，保留原始纹理与木纹方向

本站判断：「几何体走通用格式 + 场景结构走 JSON」这个分工很聪明，也是 Web 端最该借鉴的一点。Three.js 侧同理——模型用 glTF/GLB，场景图、灯光、材质映射用一份 JSON 描述，比让模型直接吐一坨 scene.add() 代码可控得多。另外两个转换坑在 Web 端一样存在：Blender 是 Z-up 而 Three.js 是 Y-up，坐标必须显式转换；单位不统一会直接毁掉相机视高和物理尺度。

5. 可漫步到场景中之后，设计审查方式变了

UE5 版本是第一人称、正常视高自由移动，打包成了 Mac 应用。碰撞设置的取舍很实在：地面支撑玩家，墙体/家具/玻璃阻挡玩家，附近树干可作为障碍物，但不是每株蕨类都该变成隐形墙。

交互层面，导出过程记录每个门和抽屉由哪些部件组成、绕哪个轴旋转或朝哪个方向滑动、每个开关控制哪些灯。最终：

“The biggest change: things in the house actually work now.”

按 E 可以开门、开厨房橱柜、控制部分灯光，甚至操作咖啡机——按钮被按下、咖啡流入杯中、液位逐点上升。

作者也提到，可漫步成了他审查设计的新方式：从花园接近房子、进入起居空间，站在那些渲染镜头从没拍到的位置去看每个房间。

代码与验证

原文没有公开完整脚本，只描述了它用 bpy 构建场景、用 --python 后台渲染。下面按原文思路给一个最小可运行的 bpy 骨架，用来验证「脚本化建模 + 后台渲染」这条路径（Blender 可执行）：

# render_scene.py —— 用 blender --background --python render_scene.py 运行
import bpy

# 1) 清场，保证可重复执行
bpy.ops.wm.read_factory_settings(use_empty=True)

# 2) 脚本化建模：Astra 就是用 bpy 一次性建出建筑/家具/材质/灯光/相机
bpy.ops.mesh.primitive_cube_add(size=2, location=(0, 0, 1))
box = bpy.context.active_object
box.name = "Room"

# 3) 相机按原文参数：离地约 1.65 m（正常视高），24–26mm 镜头
cam_data = bpy.data.cameras.new("Cam")
cam_data.lens = 26                      # 24–26mm：接近人眼透视，不夸张
cam = bpy.data.objects.new("Cam", cam_data)
cam.location = (6, -6, 1.65)            # 1.65 m 视高
bpy.context.collection.objects.link(cam)
bpy.context.scene.camera = cam

# 4) Cycles + 自适应采样 + 降噪（原文用这套控制噪点）
scene = bpy.context.scene
scene.render.engine = "CYCLES"
scene.cycles.use_adaptive_sampling = True
scene.cycles.use_denoising = True       # OpenImageDenoise
scene.render.resolution_x, scene.render.resolution_y = 1920, 1080
scene.render.image_settings.file_format = "PNG"

# 5) 出图 —— 这一步的产物正是 agent 拿去"自检"的输入
scene.render.filepath = "//preview.png"
bpy.ops.render.render(write_still=True)

原文里可核对的硬指标：

项目数值
短片规格30 秒 / 1080p / 30fps → Cycles 渲染 900 帧
相机离地 1.65 m，镜头 24–26 mm，带 walking bob，未加景深（为保建筑细节清晰）
降噪adaptive sampling + OpenImageDenoise，离线渲染、剪辑不插补任何帧
静帧5 张原生 4K（exterior / atrium / living room / kitchen / bedroom）
对照故事板两套各 7 个场景，一套 Cycles、一套 UE5 Lumen 实时，机位一一对应
computer use 基准ScreenSpot-Pro 76.9% → 92.7%；BenchCAD 83.3% → 95.9%

适用场景与坑

该用它：

  • 概念设计与空间可视化——一句话起步，快速看到可编辑场景
  • 需要「能走近看」的资产：真几何而非贴图，任何角度都立得住
  • 长链条迭代：作者的方法论是先描述氛围 → 审平面图 → 要更精确的家具 → 最后真正走进去
  • 它同样适用于非建筑题材：作者用同一套流程做了 HELIOS 戴森球（5,120 块面板、只留三道狭缝）、巡洋舰 AURELION-07、莫奈的 Giverny 花园

人机分工作者说得极好：

“Astra handles the scenes, the scripts, and the Unreal project; I only handle judgment — what this space should become.”

别用它：

  • 当施工图用。原文明确警告：平面图在真正建造前，必须由专业人士对照场地、结构和建筑规范重新复核。这只是 concept demonstration
  • 指望实时端和离线端完全一致——Unreal 材质只能近似，故事板里浴室镜面就出现了 reflection artifacts

已知的坑：

  1. 第一版不是完整住宅：卧室等私密区域只有外部外壳，内部没真建
  2. 自检不能替代人工：原文说这些检查「不能替代逐张审查渲染图，也不能保证完全没有穿模或建筑细节错误」
  3. 法线/几何错误：钢水槽法线错误导致盆底被压扁，是看渲染图才发现的
  4. 灯光 flattening：初版有隐藏补光让房间变平，后来被移除并暖化
  5. 材质转换有损：部分 shader 效果只能近似，最终结果仍依赖手动检查和调试
  6. 碰撞过度：树干可以是障碍，但蕨类不该变成隐形墙——导出到引擎时要显式区分
  7. 预览构图失控：短片预览若停在空白墙或收得突兀，需要它回去重调

给 Web3D 读者的落地建议：想要在浏览器里复现类似效果，优先让 agent 产出 glTF/GLB + 一份场景 JSON，而不是让它直接写整页 Three.js 代码；实例化（instanced mesh）必须由你自己确认，否则森林这类重复资产会瞬间拖垮 draw call；单位与 Y-up/Z-up 转换要在导入时显式处理；相机视高按 1.65 m、镜头 24–26 mm 设，是最省事的一条「像人眼」的捷径。