学建筑的00后，5天用AI造了座重庆山城

一支 5 人团队横跨中国、法国、美国三个时区，5 天做出一个以重庆渝中半岛为底、融合热那亚和长崎海港山城地形的时空解谜游戏场景——《此城未逝》。这座让观众感到震撼的工业山城，也带出了一个问题：如此庞大而复杂的场景，是怎样一步步做出来的？ 从《此城未逝》到建筑建模、出图与工具开发，听烤鸽聊聊和 AI 一起工作的故事。

图1 《此城未逝》的游戏场景地图 参与制作的烤鸽，仍是一名在美国纽约 Pratt Institute 就读的建筑本科生。对他来说，《此城未逝》只是与 AI 协作以来的又一项尝试。从 2022 年年底 ChatGPT 问世到现在，AI 逐渐进入他的学习与创作。早在 2024 年的建筑课程中，他就在围绕雨水收集、能源和防洪等课题，调整提示词、探索概念图。后来，尝试延伸到建模、出图、编写工具，也进入了游戏城市的制作。 随着能做的事情越来越多，一个问题也变得越来越具体：AI 做出一个结果之后，能不能按要求修改，能不能让其他执行者接着做，又能不能让人检查清楚？ 这次分享中的许多项目，都围绕着这个问题展开。 一、用建筑的方式，搭一座游戏山城 《此城未逝》的城市制作，从真实的地形和道路开始。 团队以重庆渝中的地形与路网为基础，重新组织港口、工业区和街区。道路如何顺着山势展开，建筑怎样沿街排列，不同区域之间怎样连接，都需要先建立空间上的关系。 有了道路，再沿道路划分地块，程序根据地块的尺寸选择合适的建筑类型。某栋楼放进去后挤占了邻近建筑，就换一种更窄的类型；仍然放不下，再移除这一栋。 同样一套规则，可以生成许多建筑，也能随着要求继续调整。

图2 街区生成过程：道路、地块、楼体与成品 但规则从哪里来？这就用到了建筑学里对场地、尺度和建筑类型的研究。什么样的建筑适合沿街布置，怎样处理坡地上的入口，厂房、住宅与车站各自需要怎样的空间关系，都要有人作出判断。 在另一项 Red Hook 仓库实验中，团队利用公开的激光扫描数据和建筑轮廓，提取屋顶高度、坡度等信息，再整理成可以调整的建筑类型。同一种仓库，可以改变宽度或屋面坡度，生成不同的变体。门窗等无法从数据中可靠辨认的部分，则需要另外补充，并与真实测量的信息区分开。 这些研究让模型的生成有了具体依据。回到《此城未逝》，一座建筑放进山城以后，还会遇到新的问题：楼身已经贴合地形，入口却可能被道路埋住；整体抬高建筑，又会让另一侧悬空。团队需要继续调整门廊、踏步与周围地面的关系。一个看起来很局部的问题，背后牵动的是建筑和场地之间的连接。

图3 《此城未逝》一景：22% 坡地上的楼型、台地与挡土墙 AI 可以把模型做得很快，建筑知识则帮助团队判断：这栋楼应当怎样站在这里。 二、与上百个 Agent 协作，先把任务交接清楚 城市里的建筑、道路和场景，需要许多工作共同推进。烤鸽和团队为此组织起了一套多 Agent 协作方式。 以第一关的一批厂房为例，一项任务从人的草图开始。先画出建筑轮廓，说明用途和层数，AI 再将这些要求整理成建模规格，交给云端机器人执行。机器人先提交简单模型，同时附上俯视图和人眼高度的截图，便于检查建筑的形状、入口与周围环境。发现入口被地形遮住，或者模型与场景不匹配，就带着具体意见返回修改。检查通过后，再继续细化。

图4 《此城未逝》一景：工业水岸的厂房、煤场与船坞 围绕这样的任务，协调会话负责汇总问题、拆分工作；建模、关卡、视效等专项会话负责细化要求和检查；子代理参与检索核对，Codex 编写脚本，云端机器人承担批量建模。烤鸽和伙伴则确定方向、比较方案，并处理需要人作出的选择。 工作通过编号信件派发，执行者用对应回执报告进度。需要更换会话时，再用“续接卡”留下正在做什么、停在哪里、还等谁决定。这样，新的执行者可以从已有进度继续，不必重新猜测上一轮发生了什么。 模型进入场景后，还要接上材质、灯光和摄影机。团队将模型形状与摆放信息分开管理，在 Blender 与 UE 之间更新受影响的部分，尽量沿用已经完成的场景设置。正式录制和渲染使用固定版本，新修改则在工作版本中继续推进。

图5 同机位班轮替换前后，保留原灯光与水面 重任务交给云端机器，显卡服务器承担引擎运行和渲染，队员的 Windows 电脑负责打包与实测，本机主要用于控制和审阅。协作的规模，也体现在项目记录中。竞赛周截至 10 月 10 日凌晨的一次本机扫描，记录了 31 个 Claude 主会话、156 个子代理记录，以及 804 条 Codex 线程记录。活动最密集的一个十分钟窗口里，有 50 个会话留下活动记录。

图6 竞赛周 AI 协作记录：累计记录与每十分钟活跃会话数 截至同日清晨，记录中还有 273 个有图的云端作业，留下约 2.09 万张图像输出。这些输出仍需要检查、比较和筛选，才能进入后续制作。项目同时留下了约 156 条拍板记录，记录推进过程中需要作出的选择。 执行工作越多，提出要求、安排分工和判断结果就越重要。烤鸽需要关注的，也逐渐从某一步操作，转向整个任务怎样才能顺利完成。 三、圈出一面墙，AI 就能按要求改对吗？ 城市制作之外，类似的问题也出现在建筑学生熟悉的工作里。在一个叫作 Hemp Study 的材料构造实验中，团队从纽约市场上可以买到的麻基砌块和木材出发，把真实规格带入模型。 砌块的尺寸影响墙体怎样排列，木材的截面影响杆件的粗细，供货长度则影响构件怎样分段和拼接。材料表、构件模型和下料排版，由此进入同一套设计过程。

图7 Hemp Study V18：构件、分解、下料与模具图 第一轮模型出来了，墙、窗和屋顶都有。仔细一看，横杆挡住了窗户，墙顶与斜屋面之间还留着缝。 AI 已经拿到了材料尺寸，但窗洞应当怎样避让结构、墙体应当怎样与屋顶连接，仍需要明确的要求。材料数据提供了起点，构造关系还要继续说明和检查。 团队于是尝试在模型截图上直接批注。圈出需要修改的部分，画一个叉，再把意见交给 AI，看起来很直观。但在一次修改中，他们只在右侧屋面的三角封板上画了一个叉，AI 却根据对称关系，把左右两侧都删掉了。人以为已经说清楚，AI 理解的范围却扩大了一圈。 这类问题让修改要求变得更加具体：改的是哪个对象，哪些部分必须保留，完成以后应该检查什么。团队也在探索操作前的确认步骤，让 AI 先标出准备删除、移动和保留的构件，再执行修改。

图8 Hemp Study 的模型批注与剖面手批 为了让这样的工作更容易调整，团队尝试让 AI 直接编写生成模型的程序。例如，一排柱子的数量和间距，可以写成参数；重复出现的构件，可以按照同一套规则生成。需要调整时，就修改对应参数，再重新计算受影响的部分。 AI 负责组织建模逻辑，CAD 几何工具负责计算实际形状。程序运行以后，还要重新读取模型，检查位置、尺寸和构件关系。代码运行成功，只是完成了一步。模型是否符合设计要求，还需要继续判断。每发现一个问题，团队就补充相应的检查条件：柱子能不能侵入窗洞，墙体两侧有没有接到边柱，墙顶是否与屋面衔接。建筑知识，也就在这些具体的要求和检查中进入 AI 的工作过程。 四、造一个工作台，让模型、图纸与修改连起来 一次修改完成以后，下一次工作怎样接上？为了解决这些问题，烤鸽和团队开发了 MonkeyHub——一套面向建筑设计的 AI 工作台。它把模型、图纸、批注和版本记录放在同一个项目中，让人能够查看、比较、标注，再决定哪些结果继续使用。

图9 MonkeyHub 工作台中的图纸与便签批注 可以从一扇窗理解这件事。墙上已经开好了窗，下一轮要把窗加宽，AI 需要知道：它属于哪面墙，由什么尺寸决定，改动之后会影响哪些构件。 仅仅看到最后的模型，未必能读出这些关系。团队因此尝试把构件的身份、参数和关联关系保存下来。墙体和开窗用的对象分别记录，调整窗宽时，程序能够找到原来的对象，修改尺寸，再重新计算受影响的墙体。在这套做法中，脚本记录怎样生成、修改和检查，参数表达允许变化的尺寸与数量，元数据则保存对象的身份、版本和关联信息。 这些记录，也让不同选择有机会被保留下来：哪一版是当前工作稿，哪些是待比较的候选，哪个版本已经被确认为阶段成果，都需要分清。 模型之后，还有图纸。MonkeyHub Diagram 已经能够从完整的三维模型生成轴测图和立面表达。团队把一张图纸背后的依据分别保存：使用哪一版模型，从哪个方向看，线条和颜色怎样表达，以及图放在纸面的什么位置。下一次出图时，这些设置就可以继续沿用。模型变化后，相关图纸能够按既定设置重新生成；需要统一调整表达时，也有了共同的修改依据。更多视图、标注和成套图纸的一致更新，仍在继续完善。

图10 MonkeyHub Institute 项目页 图像修改则带来了另一类问题。设计者只想改动一个局部，AI 却可能连旁边的建筑、树木和光影一起改变。生成结果单独看很漂亮，放回原方案中，却不再符合最初的要求。在 Patch Image 中，原图、批注和允许修改的区域分别保存。AI 生成局部内容后，程序将它放回原图，区域之外沿用原来的图像，再检查是否出现越界变化。

图11 Patch Image：原图、局部修改结果与范围检查 设计者也可以同时提出多张图片的修改要求，集中比较生成结果，针对不满意的部分继续调整。从建模、出图到修图，团队希望逐步保存下来的，是让工作能够继续的依据。 这对多 Agent 协作同样重要。一个 AI 完成墙体建模，另一个接手调整窗洞时，需要拿到明确的模型版本、构件关系和修改要求。多个 AI 同时修改相关对象时，怎样识别冲突、合并结果，仍是团队继续研究的问题。 五、做得快之后，怎样验证 AI 做得对不对？ 随着任务越来越多，另一个问题也摆到了面前：怎样判断 AI 的结果可靠？怎样知道一种工作方法值得继续使用？ 建筑法规解析，是团队正在研究的一个方向。让 AI 找到一个高度或退让距离，还需要同时找到适用条件和来源。团队尝试解析法规中的正文、表格与图像，把回答里的关键结论关联回文件、章节、页码和版本，供后续核对。 评价过程也被单独组织起来。先根据具体条件确定问题，再对照原文整理参考答案和依据。参考答案与被测试的回答过程分开保存，等 AI 完成回答以后，再比较结论、引用、耗时和使用成本。这样，不同的检索方法和材料组织方式，才有了可以比较的基础。 同样的思路，也可以用于建模任务。 面对同一个要求，AI 可以先查资料再执行，也可以直接编写程序，或者每完成一部分就检查一次。偶尔成功一次，很难说明哪种方法更稳定；把起点、要求和评价方式固定下来，反复比较，才能逐渐看清差别。团队计划尝试 OCBA 等计算试验预算分配方法：先让几种策略完成少量试跑，再根据结果，把后续试验机会分配给仍需要进一步判断的方法。 与此同时，选择工作方法和安排计算资源，也需要分开考虑。前者关心怎样完成任务，后者关心任务在哪台机器、什么时间运行。分别比较，才能更清楚地判断改进来自哪里。任务有没有真正完成，是否违反要求，消耗了多少时间和成本，都需要留下记录。AI 能够完成越来越多的操作，团队也需要积累更充分的依据，决定下一次该怎样使用它。 六、当执行可以交出去，人的精力放哪里？ 从《此城未逝》的城市空间，到一面墙、一扇窗，再到模型、图纸和修改记录，烤鸽的建筑训练始终参与其中。道路怎样组织，建筑怎样落地，材料怎样连接，哪些变化可以接受，哪些关系必须维持——这些判断会变成 AI 执行任务时的具体要求，也会成为检查结果的依据。 这让分享最后的问题变得具体起来： 当软件操作不再是主要门槛，建筑师应该把精力放在哪里？ 面对多个方案，能否说明选择的理由？面对一张漂亮的图，能否判断它是否准确表达了空间与构造？面对 AI 自动补全的部分，能否发现哪些决定需要重新考虑？ 执行得更快，也意味着人会更频繁地面对选择。对烤鸽来说，这几年的尝试让建筑、编程、工具开发和团队协作逐渐联系起来。专业知识帮助他提出要求，AI 扩大了能够尝试的范围，而一个个具体项目，又不断提出新的问题。 这些作品、软件和研究记录，目前已经整理在 MonkeyHub Institute 的官方网站上。网站汇集了团队在建筑、技术与软件、互动媒体等方向的实践，也保留项目的版本变化和实验过程。前面提到的 MonkeyHub 工作台，就是其中一项持续推进的工作。

图12 MonkeyHub Institute 中文首页 接下来，团队会继续完善设计状态的记录与交接，推进图纸和图像的批量更新，并通过独立评价与重复实验，比较不同 AI 工作方式的表现。 烤鸽和团队也在尝试用 AI 开发《我的世界》模组，通过开发者账号「月下之影皓月之辉」，把对建筑、铁路与工业场景的兴趣带进方块世界。

图13 模组示例一：《齿轮纪元》的列车、桥梁与地形工具

图14 模组示例二：机车三视图与轴测（1）

图15 模组示例二：机车三视图与轴测（2） 《此城未逝》让观众看见了一座已经展开的城市。它背后的草图、规则、脚本、批注和反复修改，也展示了这座城市怎样从想法一步步成为作品。 从判断一扇窗该怎样修改，到决定一座城应当如何展开，烤鸽还在继续尝试，也继续作出自己的选择。 写在最后 这场分享的含金量在于：它把「怎样和 AI 一起工作」讲到了具体处——要求说清，修改接上，结果查实。对想把 AI 用进实际工作的团队，这些做法比一次漂亮的生成更值得借鉴。 你的工作里，哪些产出其实也该从「生成结果」改成「生成规则」？评论区聊聊。