AI 生成 CAD：OpenSCAD 与 CadQuery 对决
Benchmark: CadQuery vs. OpenSCAD for agentic CAD work
ModelRift 团队用 Claude Opus 5 驱动六个 AI 代理，在三个不同难度的 3D 打印任务中对比 OpenSCAD 和 CadQuery。结果显示，两者最终都能生成可打印的模型，但失败模式截然不同。OpenSCAD 在复杂几何构建上更稳健，而 CadQuery 的参数化优势在迭代中更明显，却也因底层库的静默错误导致几何体丢失。文章强调，无论工具如何自报平安，独立的几何解析才是验证 AI 生成质量的唯一标准。
能力测试其实是答案中无聊的部分，两者的真正差异在于它们各自如何失败。
HN 评论区
58- rounce
两条工具链都已交付。区别在于它们失败的方式。
啧，这种 LLM 生成的风格简直糟糕透顶，读起来让人难受，说了大堆话却等于什么都没说。
- dofm
这里的所谓“发现”根本不需要做 AI 实验就能得出：
- “CadQuery 会大声且尽早报错……而 OpenSCAD 则静默且滞后地失败”
这应该是不言自明的，从文档和几何构建的方式就能看出来。OpenSCAD 根本没有失败的概念，即一个形状导致另一个形状无法工作；你只是在空间中绘制等效的 3D 像素。只要语法没问题，它总会以某种潜在无意义的方式“成功”。
- 渲染过程没捕捉到任何关键问题
带有空腔的物体通过这种方式根本不会暴露其主要问题。
- CadQuery 可被查询，而 OpenSCAD 不行
这难道不是两份文档里都写得很清楚吗？一个是通过在可存储于变量中的前一个结果上迭代构建；另一个则不是。
- OpenSCAD 的渲染没有“零件边缘”的概念
再次强调——文档里应该写得很清楚，其中没有描述操作边缘的方法（很大程度上也是因为它是声明式的）。
- 速度方面 OpenSCAD 占优，但这几乎无关紧要
没错，如果结果错了，再快也没用。
- “决定因素是可验证性而非表达能力，CadQuery 在此方面的领先幅度比语法差异所暗示的要大得多。”
没错，因为差异在于语义。这点从文档里就能看出来。基于现有几何进行迭代构建，本质上就更可验证，因为行不通的东西就是行不通。
说实话，人们在尝试构建 AI 工具之前，难道都不先试着学学 CAD 吗？
- rao-v
我尝试修改提供的 CadQuery 技能，使其能与 build123d 配合使用（令人惊讶的是，gemini 在这方面表现相当不错），结果非常出色（在稍微注意避免泄露基准测试的通过/失败标准后，效果可能比报道中的 CadQuery/OpenSCAD 结果更好）。如果你对这一领域感兴趣，值得一试。
我喜欢 build123d，主要是因为它能导出标准的 STEP 文件（就像 CadQuery 一样），同时拥有对 Python 非常友好的设计。
- darkteflon
我在这个领域玩了一段时间，算是一个有一定经验的业余爱好者——主要是为了 3D 打印功能性零件。
我使用一个单一的仓库来管理所有模型，配合 Claude 和 build123d（外加一个 VS Code 可视化扩展）。随着时间的推移，我建立了一个包含有用技能的小文件夹，总体结果令人满意。
不过，我一直关注着 CadQuery，正找个机会试试。对于懂行的人：它和 build123d 相比怎么样？
- YuechenLi
哦，说到这个话题，我实际上用 GPT 构建了一个几何 CAD 内核，我觉得很有前景，而且在我有偏见的看法里，它比 OpenSCAD 或 CadQuery 的 OCCT 后端更先进。这里有人想克隆我的仓库，用你们的 Claude 或 GPT 试试，看看效果是否比我更好吗？
https://github.com/yuechen-li-dev/Aetheris/
它目前还有点小 bug，但正在积极修复中。不过，Claude 和 GPT 似乎在我的当前设计下表现比其他 CAD 栈更好。我还没加入螺纹功能，所以无法对 T3 发表评论，但总体而言生成的零件质量相当不错，而且我也让圆角和倒角功能正常工作了，这是个加分项。