生成式 AI 构建的是形状，而非游戏
我尝试测试一款新的 Minecraft “prompt-to-build” 工具。我原本期待一场革命，结果却只得到了一个墙壁的地图。
该工具可以在一分钟内创建一个球体或一座塔楼。这些看起来很不错。但只要我提出具体的规则要求，它就会失败。
我要求建造一个 15x15 的木制小屋，并带有一个朝南的门。AI 给我的却是一堵没有门的灰色墙壁。尺寸不对，没有木头，毫无用处。
核心问题在于：
生成式模型是“合理性引擎”（plausibility engines），而游戏需要的是“正确性引擎”（correctness engines）。
模型可以做出看起来“正确”的东西。但游戏需要的是“确实正确”的东西。单纯通过扩大模型规模无法解决这个问题。你无法通过增加规模，就让一个“看起来像房子”的东西变成一个“拥有可用门的房子”。
这种差距的存在是因为缺失了三个要素：
- 离散约束（Discrete constraints）：模型可以近似“小”，但它无法保证“恰好是 15 个方块”。
- 组合结构（Compositional structure）：模型可以绘制一个形状，但它无法管理多个物体之间相互关联的场景。
- 功能正确性（Functional correctness）：模型不知道玩家是否真的能穿过一道门，它只知道门长什么样。
为了解决这个问题，我们必须停止使用单体模型（monolithic models）。我们需要一种将连续性与离散性分离的流水线（pipeline）：
- 规划（Plan）：使用符号规划器（symbolic planner）将提示词转化为严格的规则列表和场景图（scene graph）。
- 生成（Generate）：使用生成式模型为每个物体创建独立的形状。
- 布置（Place）：使用求解器（solver）排列这些形状，使其符合所有规则。
- 验证（Verify）：使用检查器（checker）来证明结果与原始规划相符。
生成器提供美感，结构提供正确性。
AI 内容的未来不是一个巨大的模型，而是一个协同工作的专业化工具系统。最终的赢家拥有的不会是最好的形状生成器，而是最好的验证闭环（verification loop）。
Optional learning community: https://t.me/GyaanSetuAi