用大模型生成 LDraw 源码，这个开源工具把乐高 CAD 模型直接拿捏了

LDraw 是一种描述乐高积木怎么拼的"低级语言"，一行指令对应一个零件的摆放。用 LDView、LeoCAD 这类工具打开 .ldr 或 .mpd 文件，就能看到一个可以旋转、拆改的三维乐高模型。换句话说，只要能写出合格的 LDraw 源码，就等于创造了一个乐高 CAD 模型。
有人盯上了这个思路：让 ChatGPT 或 Claude 直接生成 LDraw 源码。经过大半年的迭代和调试，还真的跑通了。作者基于 GPT-6 Astra 和 Opus 5.5 做了一套 Python 工具集，配好了指令和文档，让具备 agent 能力的模型可以输出 LDraw 模型。整个项目被打包成一个 Docker 化的 Web 应用，支持 OpenAI、Claude 和 OpenRouter 多个后端，方便不同 agent 接入。

LDraw 到底是什么

LDraw 不是渲染引擎，也不是建模软件，它是一种纯文本的"装配语言"。每行指令描述一个积木零件的位置、朝向和颜色，格式严格，像汇编语言一样底层。一个 .ldr 文件从头读到尾，就是在追踪一个乐高模型从第一块积木到最后一块的完整拼装过程。而 .mpd 格式支持多层级引用，能把复杂模型拆成若干子模块，大型作品也是靠它一层层组织起来的。
正因为 LDraw 是文本格式，大模型理论上可以"学会"写它。难点在于：模型需要理解三维空间关系，还要熟悉 LDraw 零件库里的编号体系，知道每个编号对应哪种积木、哪个尺寸。这不像写 Python 代码那样有明确的语法提示，出错成本很高——一个坐标写错，整个模型就歪了。

这套工具是怎么工作的

工具集的核心思路不是让模型一步到位生成完整模型，而是把任务拆成几个阶段：先由 agent 理解用户想要什么，再调用 LDraw 语法和零件库知识，分步输出源码。Python 工具层负责校验生成结果的格式合法性，比如检查文件头、坐标范围、零件编号是否在合法集合内。如果校验不过，就反馈给模型让它修正。
Docker 化的 Web 应用把这一整套流程封装起来了。用户在浏览器里选择一个后端（OpenAI、Claude 或 OpenRouter），挑一个 agent，然后用自然语言描述想要的乐高模型。应用会把描述传给 agent，agent 调用工具集生成 LDraw 源码，最后返回一个可下载的 .mpd 或 .ldr 文件。
打开生成的 .mpd 文件，最上面几行是元信息，比如文件作者、创建时间、零件数量。往下看到 "0 FILE" 开始的段落，就是模型的根层级描述。再往下展开，每个子模块的引用关系一目了然——这实际上是 agent 在"脑子里"构建模型的思维轨迹，比看最终渲染图更能理解它是怎么想的。

能生成什么样的东西

从项目提供的示例页面来看，生成的模型覆盖了几个类别：简单的几何形体，比如球体、圆柱体，用来验证基础指令的准确性；小比例的日常物品，比如椅子、桌子、小房子；还有稍微复杂的机械结构，比如带铰链的可动部件。这些模型的共同特点是：零件数量在几十到几百之间，结构层次分明，能被 LDView 正常加载和渲染。
当然，目前的生成能力还有边界。需要大量曲面过渡的模型、包含几百个异形零件的大型场景、或者对零件精度要求极高的场景，模型还很难一次生成到位。作者在示例页面也坦诚地标注了哪些是"能用"的，哪些是"半成品"。

怎么用起来

环境要求方面，Docker 是必需的，项目已经把依赖都打进镜像里了。拉下镜像后启动容器，浏览器访问对应端口就能看到 Web 界面。在界面上选好后端和 agent，输入框里用自然语言描述模型，比如"一个红色的乐高小汽车，四个轮子可转动"，点生成就行。
如果想深入调试，可以直接看 Python 工具集的源码。工具集里有 LDraw 语法校验器、零件库索引、以及 agent 调用模板。改模板可以调整生成策略，比如增加迭代次数、调整温度参数、或者加入更多约束条件。对 agent 开发者来说，这套模板是可以直接复用的——换成其他结构化输出任务，比如生成 SVG 图形或者 JSON 配置，思路是相通的。

为什么值得关注

这个项目的价值不在于"AI 能画乐高"这个表层功能，而在于它验证了一件事：大模型在面对类汇编语言的低级格式时，只要配好工具链和校验机制，是可以产出可用的结构化输出的。LDraw 的约束比自然语言严格得多，能跑通就说明 agent + 工具集的组合在处理格式化生成任务上有泛化能力。
另外，乐高社区一直缺少 AI 辅助设计工具。传统的乐高 CAD 软件依赖手工搭建，效率低、学习曲线陡。这个工具如果持续迭代，有可能让"描述即建模"变成现实——你说出想要的模型，工具直接出源码，再用 3D 打印或者买零件包就能做出实物。

还没解决的问题

目前最大的短板是生成一致性。同一个描述，换一个 agent 或者调整一下参数，输出的模型可能差别很大。这说明 agent 对 LDraw 语义的理解还不够稳定，工具层的校验规则也需要更细粒度。另一个问题是零件库覆盖范围有限，很多特殊零件还没有对应的编号映射，模型生成时会被迫用近似零件替代，效果会打折扣。
作者在帖子里明确说了，希望收到反馈和评论。这意味着项目还处于早期阶段，社区的参与会直接影响它的演进方向。如果你对乐高或者 agent 工具链感兴趣，值得去示例页面看看生成的模型长什么样，再决定要不要花时间跑起来试一把。