给 AI agent（代理）一个模型创意，引导它动手构建，就能得到一个 LDraw LEGO 模型。构建结束后会产出一套用 LDraw 语言写成的源代码，还有多种呈现方式：3D 查看器、3D 播放器、面向 Meta Quest 3 的 VR 交互，以及图片等。除此之外，还能拿到可在 Blender 中编辑的 glTF 文件，格式为 .glb，元信息存为 Blender 的自定义属性，以及聊天记录和 agent 的思考过程。

给 AI agent 一个模型想法。引导它、让它去搭建，就能得到一个 LDraw LEGO© 模型。

搭建完成后你会得到：

• 它的源代码，用 LDraw 语言写成。
• 多种形式的成品：3D 查看器、3D 播放器、VR 互动（Meta Quest 3）、图片……
• Blender 可编辑的 glTF 文件，.glb 格式，元信息以 Blender Custom Properties 保存。
• 聊天记录和 agent 的思考过程。
• 还有更多 👌

有视频演示可以看。

安装

agent 用来寻找合适零件和示例模型的重要工具用到了 jev-rerank（我也是作者）。这是一个带重排序的语义搜索工具，由 TypeSafe 的 Jev System One AI 模型支撑。如果你有 TypeSafe API key（TYPESAFE_API_KEY），在 web 应用的 Settings 区域填入。没有的话，重排序搜索不会工作，agent 会退回 FTS（全文搜索）策略，可能（也许）得到更差的模型。

用 Docker 把 ldraw-nova 当作 web 应用运行。需要 Git 和 Docker。

这个 web 应用以 docker 方式运行，构建镜像需要两个并列的仓库：

• ldraw-nova：就是这一个 😉
• ldraw-nova-docker：提供 Docker 配置和 web 应用。

1. 在同一 tag 下把两个仓库克隆到并列位置，它们才能配合工作：

git clone --branch v0.6.0 https://github.com/anteloc/ldraw-nova.git git clone --branch v0.6.0 https://github.com/anteloc/ldraw-nova-docker.git

2. 构建 Docker 镜像。首次构建要花些时间，需要约 5 GB 磁盘空间：

cd ldraw-nova-docker docker compose build

3. 启动应用：

docker compose up -d

4. 用浏览器打开：

https://localhost:8443：Meta Quest 3 上的 VR 需要这个地址。证书是自签名的，第一次要接受浏览器警告。 http://localhost:8765：纯 HTTP，没有证书警告。自签名证书碍事时就用它，但 VR 在上面用不了。

同一网络里的其他设备可以用你电脑的 IP 代替 localhost 访问，比如从 Quest 3 访问 https://192.168.1.20:8443。应用没有登录，所以只在信任的网络上运行。

停止：

docker compose down

为什么要做这些？

简单说：我这么做是为了得到能设计可搭建的实体物品的 agentic LLM！

发现 LDraw —— 一门汇编语言（双关 😜），既简单、底层，又能执行并生成 3D CAD 模型 —— 让我想到用 ChatGPT 和 Claude 做实验，试着让它们用 LDraw 写代码，就像它们用其他编程语言那样。

让我意外的是，尽管这门语言极其偏重数学（零件旋转、定位……），而 LLM 通常不擅长这个，agent 在初步测试中却做得相当好，后续项目也有不错结果，但始终不足以认为生成的模型是正确的：

• 初期研究：ldbuilder-ai
• 第一次尝试 agentic python 工具：py2bricks
• 第二次尝试：py4bricks

这三次尝试以及不少其他实验，让我得出以下结论：

💡 结论 1：对 agent 来说存在一条通往几何数学的最小阻力路径，即给 agent 提供生成 LDraw 源码的工具，就能绕开（邪恶的！）几何数学……因为它们在生成「能算出数学的 python 代码」上表现好得多，而不是自己做数学！

💡 结论 2：agent 从「产生模型的 python 代码」中学习，比从模型本身学习表现更好（又是 LDraw 邪恶的几何……）。

那么剩下的唯一一件事 🤔 就是做一个基于 python 的工具，带上必要的原语、动词、构造性词汇……这样 agent 就能通过示例学习，再自己做类似的事。

这真的很难做对，哪怕是 vibe coding……直到 GPT-6 Astra 和 Claude Opus 5.5 出现……然后 vibe code 成功了！🚀🚀🚀

工作原理

ldraw-nova 提供 agent 用真实 LDraw 零件设计模型所需的工具、示例和指令。

流程如下：

• agent 接收一个 prompt。
• 阅读 instructions.md 以及与 LDraw 语言、LEGO© 模型搭建相关的文档。
• 规划怎么搭建：需要哪些零件、要创建哪些子模型、美观等。
• 迭代进行：从模型/子模型渲染图像 → 检查，调整定位和美观…… → 再回头渲染……直到它认为模型完成、可以交付。

提供的工具帮助 agent：

• 找到合适的零件。
• 还有可作为起点的示例模型和子模型。
• 碰撞和间隙检测，用于正确放置零件。
• 无头渲染，用于检查当前结果。
• 以及更多……

agent 实际上不会一开始就放零件，除非是比如做原型、或通过修改已有示例模型来学习。

它产出模型的方式更像是：

• 从实验结果、文档和规划中收集所需信息。
• 建立一个或多个 plan，完整描述模型和子模型，包括几何，比如 atlas-crane.plan.json。
• 有了 plan，它创建一或多个生成脚本，比如 generate.py，执行后产出 LDraw 源文件——一门非常专门化的 3D CAD 语言——比如 atlas-crane.mpd。

概括地说，就像是：一个 agent 创建一个生成器，生成一个 3D 模型，用的是一门叫 LDraw 的汇编语言 🤯，可以说是某种编译器 🤓

agent →（produces）plan.json →（interpretation）generator.py →（execution）model.mpd

agent 的信息来源

这些是交给 agent、让它成为搭建者的一些指南和参考资料。

开发

这是首个版本，还有不少地方需要完善：

• Meta Quest 3 上的 VR：模型处理有很多问题，还有性能问题。
• 适配低端 agent：调整现有工具、文档和指令，改善 Luna、Haiku 等低端模型的使用体验。
• 生成成本高：目前只有昂贵的高端模型能生成大型且正确的模型。
• 提升效率：生成过程目前较慢。
• 增加并改进更多模型家族：人仔等人物和动物；Technic 模型如机器、引擎……；飞船方面生成的模型不太好。
• 从说明书搭模型：部分可用，把整页说明书以图片形式给出效果更好。
• 细粒度检查：用于检查子模型及其逐步搭建过程。

贡献

COMING SOON

致谢

我要感谢：

• LDraw 社区
• LDView 的 Travis Cobbs（@tcobbs）及贡献者
• LeoCAD 的 Leonardo Zide（@leozide）及贡献者
• LDCad 和 Shadow Library 的 Roland Melkert
• ldraw.rs 的 Park Joon-Kyu（@segfault87）及贡献者
• pyldraw3 的 Harold Martin（@hbmartin）及贡献者
• 以及所有其他众多 LDraw 创作者！

注意：这项工作中我使用了很多来源的 LDraw 模型、库、工具和文档。有许多了不起的人慷慨地把最好的作品捐献给公共领域和开源社区，有的人这样做已经几十年。如果你认为自己应该出现在这一节，请给我发邮件！

商标

LEGO(R) 是 LEGO 集团公司的商标，该公司不赞助、授权或认可本软件。

社区整体氛围是惊喜和好奇居多，作者把 LLM 接到乐高 CAD 的底层描述语言上，让模型直接生成可交互的三维模型，不少人觉得这是 LLM 走向真实制造的一块拼图。分歧主要在情感层面：一部分人认为 AI 侵入乐高这块纯粹靠想象的领地，把乐趣抽走了；另一部分人则把它当成通用的「让模型设计实体物件」的验证案例。

认为这是在剥夺乐高最纯粹的乐趣

• 有人直言看到 LLM 渗入乐高的纯想象世界会本能地不适（少数人）
• 更激烈的声音认为这类工具把什么都变得没意思了（少数人） > 行吧，什么好玩的东西都要被搞没。（@cyclopeanutopia）

把它视作让 LLM 设计实体物件的通用路径

• 有人最近用 FreeCAD 加 MCP 配合 Claude 做设计，三个零件——显示屏外壳、铝制热端转接件、笔与压力传感器支架——首次硬件版本就装配成功，只补充了零件编号和几处卡尺测量值（较多人）
• 相邻领域的经验是直接把 3MF 模型文件喂给 Claude 提改造需求，比如把纯压配改成内嵌螺栓螺母结构，比手工在 CAD 里调整快得多（较多人）

装配与空间干涉仍是模型的盲点

• 上述 FreeCAD 实践里最卡的地方不是造型而是装配顺序，有个零件需要穿过略窄的缝隙才能到位，模型没意识到，人也没意识到（较多人）

相关研究已有先例，约束零件集是有效手段

• 去年有一篇论文做的正是同一件事，让模型在给定零件集合的约束下「造工具」，当时用的是 Opus 4.5，换成更强的模型应该会更好（较多人）

期待延伸到机器人、物理仿真与更大尺度建造

• 有人关注它在机器人上的用途，但认为要做得好得引入物理仿真（少数人）
• 有人正和孩子用物理建模做 FLL 项目，看到这条路线很受启发（少数人）
• 也有人顺势畅想下一步是让 AI 和机器人去盖真房子（少数人）

关心实际生成成本

• 有人追问生成示例模型时各家模型的 token 开销大概是多少（少数人）

有价值的补充

• Arxiv 论文 2512.15743 做过同类实验：给模型固定一套零件作为约束，要求它用现有零件「搭」出工具，与纯自由生成相比更能保证可建造性。
• 有人在 FreeCAD 流程中发现，只要提供在线查不到的零件型号加几处关键尺寸，模型两三轮改版后就能产出可直接上机床或打印的零件。
• 有人提议做反向工具：拍一张散装乐高零件堆的照片，自动生成整个收藏的零件目录——这条更像社区情绪的玩笑，但也点出了零件库存管理的真实痛点。