我做了一个开源的乐高 AI 生成器
文章摘要
ldraw-nova 是开发者 anteloc（HN 账号 antelocnova）开源的一套工具：用户给 AI 代理一个模型创意，代理就能一步步搭出一个用真实乐高零件组成的 LDraw 格式 CAD 模型。这是作者第一次在 HN 发帖。他起初的 Show HN 提交因新账号限制没有通过，只好用普通帖子重发。HN 管理员 dang 偶然看到后，亲自给帖子加上了「Show HN」，把作者的说明移到正文，还说新账号的 Show HN 限制本来就不是为这种项目设的。帖子最终拿到约 170 分、50 多条评论。
LDraw 是什么。 LDraw 是乐高爱好者社区的一种开放标准，作者把它称为乐高的「汇编语言」：一个 .ldr 或 .mpd 文本文件逐行写明每个零件的编号、颜色、坐标和旋转矩阵，交给 LDView、LeoCAD、Studio 等软件就能渲染成可交互的三维模型。也就是说，一个 LDraw 源文件就等于一个乐高 CAD 模型。作者的想法很直接：既然 ChatGPT 和 Claude 能写代码，如果能让它们写出高质量的 LDraw 源码，它们就等于在设计高质量的乐高模型。
一路试错得出的两条结论。 作者从去年 12 月开始尝试，此前做过 ldbuilder-ai、py2bricks、py4bricks 三个项目，效果都还不错，但离「模型正确」总差一截。LDraw 本质上全是几何数学（零件的位置和旋转），而 LLM 恰恰不擅长直接算数学。他总结出两点：
- 让代理写 Python 代码去生成 LDraw，绕开了直接做几何计算，效果比让它直接输出坐标好得多。
- 代理从「生成模型的代码」中学习，比从「模型文件本身」中学习更有效。
所以剩下的任务是搭一套 Python 工具库，提供构建所需的基本元素和「动词」，让代理照着示例学会自己搭建。作者说这一步一直很难做对，直到 GPT-6 Astra 和 Claude Opus 5.5 出现，才把这套工具「vibe coding」出来。
工作流程。 代理接到提示词后，先阅读仓库里的 instructions.md 和关于 LDraw 与乐高搭建的文档，再规划需要哪些零件和子模型、整体外观如何，然后进入循环：渲染模型图片，从多个角度检查，调整位置、颜色和细节，再渲染，直到它认为模型完成。代理通常不会直接一个个摆零件，而是先写出一份完整描述模型几何的 plan.json，再据此写一个 generate.py，运行后生成 .mpd 文件。作者把这比作一种「编译器」：代理写出生成器，生成器产出用汇编语言写成的三维模型。工具链提供零件和示例模型的检索、碰撞和缝隙检测、无头渲染等能力。仓库还附有分门别类的代理指南，涵盖车辆、宇宙飞船、Technic 结构、机械装置和大型模块化街景等。
交付物与运行方式。 每次生成会得到 LDraw 源码、3D 查看器、可在 Meta Quest 3 上交互的 VR 视图、可以导入 Blender 编辑的 glTF 文件，以及完整的对话记录和代理思考过程。整套东西打包成 Docker 化的 Web 应用，可以选择 OpenAI、Claude 或 OpenRouter 作为后端。零件检索用的是作者自己的 jev-rerank 语义搜索（依赖 TypeSafe 的 Jev System One 模型做重排序）；没有 API key 时会退回全文搜索，模型质量可能变差。作者在 GitHub Pages 上放了一个示例画廊，并建议好奇的人用文本编辑器打开 .mpd 文件，看第一行 0 FILE 之后的注释，那是代理在动手前对模型的构想。
HN 评论精华
dang 的介入与建议。 管理员 dang 解释，因为大量新账号发来缺乏好奇心的 Show HN，网站不得不设门槛，而这个项目完全不属于那种情况，「如果有更好的筛选办法，我们会写软件让你这样的帖子第一次就通过」。他还建议多放些图片或一段不加修饰的演示视频，并问作者有没有真的把模型搭出来。作者回答说没试过：大模型动辄需要上千个零件，凑齐一套都很难，他正考虑先 3D 打印一个小模型看看实物效果。
相关研究。 vunderba 提到去年 arXiv 上一篇论文研究的正是用 LLM 通过 LDraw 搭模型，其中一个实验是给定一组零件，让 LLM 用它们「搭」出工具。作者说他也试过类似思路：约束太多，代理每次都搭出差不多的房子，缺乏创意；约束太少，又会漂移成搭不出来的模型。现在的迭代方式是先让它自由发挥，零件一开始放错没关系，再一点点修正位置和颜色。他还说，以他的经验，Opus 5 生成的模型质量明显更好，Opus 5.5 又更好一些。jasonhong 介绍了卡内基梅隆大学的 BrickGPT：作者构建了一个包含 4.7 万多个稳定积木结构的数据集，训练模型用「预测下一块积木」的方式生成，并在推理中做物理有效性检查和回滚，生成的设计可以由人或机械臂实际拼装出来。作者说他记得那把由机器人拼出来的积木吉他，并承认 Nova 目前只检测碰撞，不考虑结构稳定性。他设想让代理通过物理引擎或 MCP 获得稳定性反馈，像现在用渲染图找缺陷一样迭代修正。dy 正在和孩子为 FIRST 乐高联赛做带物理建模的类似项目，josh-wrale 也认为要用于机器人，物理模拟必不可少。
代理到底会不会摆零件。 ash_091 分享了自己用 FreeCAD + freecad-mcp + Claude 做零件的经历：他提供型号和几个卡尺测量值，经过两三轮修改，做出了 ESP32 显示屏外壳、铣削铝制的热端支架和把 3D 打印机改成绘图仪用的笔架，三个零件第一版就能用。AI 最大的短板是理解零件怎么装配。作者说他也被装配问题折磨了很久，解决办法是告诉代理每块积木的哪些部位是连接点（数据来自 LDCad 的 shadow library），这样就能写工具自动检查两个零件是否「正确地」连在一起。他还试过 FreeCAD，但零件一多，FreeCAD 的约束求解器就吃不消。被问到代理是否会犯错时，他说两种情况都有：乐高零件的合法位置和旋转是有限的离散整数，给足例子后代理能找到规律，在房屋这类品类上做得不错，但仍经常把正负号弄反，比如该转 +90 度却转成 -90 度，这时就要靠碰撞检测和修正循环来收尾。
成本与本地模型。 CptBroccoli 问生成一个模型要花多少 token。作者说主要取决于搭建过程需要多少「思考」：Technic 机械模型的初始放置通常偏差更大，所以更贵，粗略估计用 Astra 搭一个 Technic 机构大约要 5 美元。这也是他做这套工具的原因之一：让高端模型负责规划，视觉模型负责检查，低端代理负责反复搭建。SillyUsername 问本地模型表现如何，作者当场用 Qwen 3.8 27B 通过 OpenRouter 试了两次，结论是整体很慢，先用 Plan 模式再切到 Agent 模式效果更好也更快，但模型仍有缺陷，并把实验记录和结果图发到了 GitHub。
Technic 与机械。 1e1a 问能否用 Technic 零件做出能动的机械。ash_091 找到了仓库里的机械装置示例，jasonmarker 追问零件是否真的能正确运动。作者承认这部分还没做完，目前只有 Atlas 起重机等少数特例效果好，正在先做 Technic 结构骨架，以便之后装齿轮和传动装置，让机械真正动起来是他的目标之一。
延伸的点子。 ttul 想要一个拍下一堆散乱乐高、自动生成零件清单的工具，ash_091 立刻推荐了 Brickit；ash_091 还建议加入「只用手头已有零件」的约束。_bernd 分享了整理孩子一万多块积木的经验：准备大量宜家收纳盒，先按大件、类别和零件分，最后才按颜色分。dchuk 用 Claude 修改从 MakerWorld 下载的 3MF 模型，比如把压合结构改成嵌入 M 螺栓和螺母，他说比在 CAD 里手改好用得多。作者顺着这个思路设想：在保留连接点不变的前提下，让代理「变异」现有零件生成新形状，以补足官方零件库的不足。thomasfl 说下一步该让 AI 和机器人盖真房子，作者说他常想给 LDraw 零件库加入真实尺寸的建筑砌块。jjohnson5253 介绍了自己从体素转乐高的 brickbuilderai，希望合作。
反对声音。 khazhoux 说 LLM 侵入乐高这个纯粹靠想象力的世界，让他有点不舒服。cyclopeanutopia 更直接：「什么乐趣都要被拿走，你们到底怎么了。」bcraven 反驳说，每个人觉得有趣的事不同，作者显然很享受做这个项目，你凭什么替别人决定什么好玩。