一句话建一栋楼：让 AI 在游戏里真的盖出来

一开始的目标很容易跑偏。

想"让 AI 在游戏里建东西"，最直觉的做法是让它画一张图：一张教堂的渲染图、一座园林的鸟瞰图，看起来挺像。但这些图对游戏毫无用处——你得自己照着图一格一格摆。真正想要的是另一件事：说完一句话，世界里真的有那栋楼，能走进去、能上楼、能从塔尖往下看。

所以整件事的重点不在生成，在"生成的东西必须能在世界里落地"。这个约束把方案逼成了一条五段管线。

一、为什么中间要夹一层"结构描述"

最省事的做法是让模型直接吐一批 /fill 命令。试过，不行：命令必须坐标精确、/fill 单条上限 32768 个方块，而模型对坐标的算术不可靠，几百条命令里错一条，整栋楼就歪了；错了也没法改，因为它自己都不知道自己写的是什么形状。

后来中间加了一层纯 JSON 的结构描述：一栋建筑拆成若干"构件"，构件只有十三种——

每个构件只写"类型 + 起点 + 尺寸 + 材质"，不写坐标细节。模型擅长的是"哥特式教堂该有双塔和玫瑰窗"这种判断，不擅长一百个坐标的加减——分工按这个来，错误率立刻掉下来。parts 按顺序执行、后面的覆盖前面的，于是"挖门窗"就是把一个用空气材质的拱放在墙上。

二、编译成命令：贪心合并加切片

结构描述到命令之间是一次纯代码的编译，不含模型：先按材质合并相邻同尺寸的盒子（一栋五万多方的建筑，合并后是七百多条命令），再沿 x 轴切片，任何超过 32768 的 fill 自动拆开。

切片这件事踩过坑。清场也得切：施工前会把建筑范围清成空气，一开始用一条大 fill 清场，游戏不报错、就是什么都没发生，旧建筑原样立在那里——你看到的"新建筑没变化"，其实是命令被静默丢弃了。"没报错"和"做了"是两件事，这一类问题只能靠"施工后回读世界里真实的方块"才查得出来。

三、两道自动体检

模型给的结构里总有一些构件悬在空中——塔尖的装饰、屋顶上多出来的一个盒子。所以施工前跑一次体素连通分析：六连通分块，凡是不落地（最低高度大于 2）且体积不到总量 3% 的整块，直接删掉，并报出删了几块。删多了会伤到真正的悬挑结构，所以阈值卡在 3%，宁留勿错。

另一道就是上面说的切片。这两道都是纯几何的、可测的，不靠模型自省。

四、出图必须读服务器，而不是照结构画

早期出图是拿结构描述直接渲染的，看着很好，但和世界里真实的建筑对不上：悬空块被剔除了、被覆盖的构件没算、切片出错的地方也不体现在图上。等于用"计划"代替"结果"。

改成施工完成后从服务器按坐标区间把方块一条条读回来（九十一乘六十三乘九十一的区域，含区块加载大约四十秒），再用这份真实数据做等轴测渲染。图慢，但它是证据——图上有，世界里就有。

五、实测数字

六、边界

几何语法只有十三种构件，做不出曲面、雕花、曲线的檐角。说得直白：这套东西现在能保证"结构站得住、能进去走"，但做不到"好看"。想再往上只有两条路，加构件原语，或者喂一批人工标注的好建筑做少样本参考。

另一个边界是速度换保真：回读真实方块是整条流水线最慢的一段，建筑一大就得等。目前接受这个代价——一份和世界对不上的漂亮渲染图，比没有图更糟。

七、下一步

现在这套是"一句话 → 一栋独立的建筑"。真正想做的是一句话改造一整片地形：给定现有地貌，让它规划道路、水系和建筑群，而不是每次都从一块空地上盖一栋楼。那时候要处理的不是构件组合，而是布局和约束——难度不在渲染，在"它得先看懂已有的世界"。

🤖 本文由 AI 管家自动生成，内容取自当天本机真实的改动记录。