用 AI 生成功能部件：CadQuery 与 OpenSCAD 两条代码生成 CAD 路线怎么选

CadQuery 和 OpenSCAD 都能把 AI 写的代码变成正确、可打印的功能部件——2026 年的一项受控基准测试中，六次尝试全部通过。两者的区别在于失败方式：CadQuery 会大声地、尽早地失败，并允许你查询它的几何体；OpenSCAD 跑得又快又安静，却可能把坏零件认证成好的。如果你需要 AI 产出一个"装得上"的零件，按任务形态选工具，并用数字而不是截图去验证导出的网格。

要点速览

• 六个 AI 代理用两种工具各做了三个可打印零件；六件成品全部通过独立网格检查，但过程中出现了 16 次失败，两种工具的报告方式截然不同。
• CadQuery 失败得早且响亮；OpenSCAD 失败得无声且滞后。在无人值守的流水线里，"静默的成功"才是代价最高的失败。
• 两个工具自身的状态输出都不可信：它们都曾把独立解析证明已损坏的几何体认证为正常。
• 任务形态比工具更能决定成败：快速棱柱类零件偏向 OpenSCAD，必须互相配合的两件套偏向 CadQuery，真正的螺旋螺纹则被 OpenSCAD 干净利落地拿下。
• 渲染图几乎没抓到任何致命问题。真正抓住打印级缺陷的，是体积、干涉和断言这些数字。

用 AI 做一个零件的两条路线

向 AI 要"一个支架"，回来的可能是两种完全不同的东西。图像生成器返回一张支架的图片——往往很有说服力，高光完美、阴影逼真，但图片里没有一个尺寸是可信的。图像转 3D 的模型可以更进一步给出网格，可一个从未按规格设计过的网格，照样没有可信的壁厚、间隙或螺纹牙型。

代码生成 CAD（code-CAD）是另一条路。模型写出一份脚本，每一行都是尺寸，工具把脚本编译成精确几何体。当零件有活儿要干——一个孔要配某颗螺丝、两个半壳要卡扣咬合、一段螺纹要真的能旋进去——就该走这条路。上述基准测试的 HN 讨论里有一句话说得很到位：有用的零件必须按规格设计，让少数几个尺寸贯穿整个设计，而不是拼装到"看起来对"为止（讨论）。

这条界线也是图像路线诚实的边界。我们做的是 SketchTo，一个 AI 图像工作室，所以不妨直说：如果你要的是零件或产品"长什么样"的概念渲染图，SketchTo 的草图转渲染这类图像工具就是正确的车道；而一旦需求变成"这个必须装进那个"，你就需要 code-CAD——接下来的问题才是 CadQuery 还是 OpenSCAD。

认识这两个工具

OpenSCAD 自称"程序员的三维实体 CAD 建模器"。它是一个脚本编译器：你用它自己的紧凑语言描述对象，它负责渲染结果。它的两种主要建模技术是构造实体几何（CSG）——对基本体做交、并、差——和二维轮廓拉伸。它导出 STL 和 OFF，读取 DXF 二维轮廓，用 CGAL 做 CSG 求值。

CadQuery 是一个用于构建参数化 3D CAD 模型的 Python 库，设计上就可以脱离 GUI 使用。它构建在 OCP 之上——开源 OpenCascade 内核的 Python 绑定。这是一个边界表示（B-rep）内核，它知道每个面和边在哪里，而不只是一堆三角形。CadQuery 除 STL 外还导出 STEP、AMF 和 3MF，它的文档也把理由说得很直接：标准 Python、一个原生支持 NURBS、样条、曲面缝合、STL 修复和 STEP 导入导出的内核、更少的代码，以及比 OpenSCAD 更快的构建速度。

这些是厂商的说法。那 AI 代理实际驱动这两个工具做出成品时，会发生什么？

基准测试怎么做

ModelRift——一个从文本生成 OpenSCAD 模型的平台——在 2026 年 9 月做了一次受控对比（来源）。实验设置：

• 六个代理、三个任务、两种工具。 每个格子是独立的 Claude Opus 5 代理，跑在 Claude Code 里，互相不通气。版本：CadQuery 2.8.0（Python 3.14）、OpenSCAD 2026.06.12。
• 同等的技能文件。 OpenSCAD 技能和移植版 CadQuery 技能携带同样的 3D 打印设计规则——壁厚、间隙、悬垂。唯一的不对称：CadQuery 文件里多了一份 API 速查表，因为模型本来就熟悉 OpenSCAD 语法。
• 三个难度递增的任务。 T1：带三角加强筋、沉头孔和圆角的 L 形支架。T2：50 × 26 mm PCB 的两件式卡扣外壳，盖子和盒体必须真的装得上。T3：M24×2 软管接头，带真正的螺旋螺纹——明确禁止堆叠圆环。
• 独立验证。 每个导出的 STL 都经过一个解析器检查水密性、体积、包围盒、非流形边和边界边、翻转面和连通分量。两个工具自己的报告都不算数。

测试方对局限也交代得很清楚：每个格子只有一个代理（部分差异来自代理方差）、排除了 BOSL2 库（这很可能改变 OpenSCAD 在 T2、T3 的结果）、只测了建模——没测修复别人写坏的模型，而且测试早于渲染器的一项视觉反馈修复。

三个任务的基准汇总数据。来源：ModelRift 博客 modelrift.com（2026 年 9 月）。

结果：六发六中，路上却有 16 次失败

六件成品全部通过独立网格检查——水密、单一连通体、零非流形边。所以对比落在过程上：全程共 16 次不同的失败，其中九次工具只字未提。

有两行值得再看一眼。"静默的错误几何"几乎打平——两个工具都产出过错而不知错的零件。而重算速度这个 OpenSCAD 的招牌优势（快 30–100 倍），在由模型推理主导的代理循环里其实是噪音；它真正起作用的场景是实时定制器或大规模参数扫描，不是一次性的生成任务。

镜像般的失败方式

这次基准最有用的发现，是两个工具的失败方式正好相反。

CadQuery 失败得响亮而早。 T1 里 .fillet(3.0) 直接报错 BRep_API: command not done——这条消息既不说哪条边，也不说哪个半径。代理只能手动二分排查，最后发现原因是个算术问题：4 mm 的壁装不下两个 R3 圆角。报错难懂，但停下来的构建不会假装成功。

OpenSCAD 失败得无声而滞后。 T2 里它在大约 45 次调用中没报过一个错误和警告，同时产出的零件被腔体减运算删掉了四个安装柱、槽位错位、还有一个它刚认证为完好的导出文件实际上是坏的。Manifold 后端对一个带四条非流形边和 60 个零面积三角形的网格返回了 Status: NoError。对无人值守的生成流水线来说，这才是更贵的失败方式：静默的成功和真正的成功看起来一模一样。

T3 是整场测试的缩影。 OpenSCAD 第一次编译就产出了正确的单线螺旋螺纹，43 毫秒，不依赖任何库——代理把螺旋线写成单个 polyhedron 里的原始顶点和面片运算，没有任何护栏。CadQuery 用 Wire.makeHelix 加扫掠剖面，六行可读代码表达了同样的几何，这部分也一次通过。然后在最后一行——把螺纹脊与芯柱做并集时——由于螺纹根部与芯柱半径恰好相切，并集静默地丢掉了芯柱。结果在渲染里看着完美，报告 valid=True、solids=1，体积却少了三分之一：期望 10323 mm³，实际 7065 mm³。抓住它的是个数字。

CadQuery T3 第一版：并集静默丢掉芯柱，只剩悬浮的螺纹圈。来源：ModelRift 博客 modelrift.com。

这个教训对两边都成立：任何一方的自报状态都不是最终结论。测试作者逐个解析了每个网格，"全部干净"这四个字的分量正来自于此。

验证：什么才能真正抓住缺陷

六次运行里，渲染图只抓到粗糙的大错——比如四个安装柱在减运算里消失。每一个会毁掉打印的缺陷都是被数字抓到的：一个体积、一个角度、一次干涉检查。T3 里 OpenSCAD 代理还差点因为螺纹特写"看着不对"而错杀正确的几何；它自己的备注是渲染不足以作为任何方向的证据。

在这一环上，两个工具给出的能力是真正不同的：

• CadQuery 可以被质询。 T1 的代理直接从 B-rep 上读出沉头孔的半角，证明它是 90°，然后把规格写成断言、每次构建都重新执行——比如断言盒体与盖子的干涉体积小于阈值。断言一失败，构建就停。
• OpenSCAD 只能 echo。 echo() 把数字打印出来等人读，没有任何东西会因此停下构建。两个 OpenSCAD 代理不约而同手写了二进制 STL 解析器——代码量跟模型本身差不多——来测量自己造出的东西。这行得通，但它只能看见导出的网格，看不见设计本身。

无论用哪个工具，测试给出的处方都成立：强制数值检查——壁厚、间隙、干涉体积、悬垂角——并在打印前对导出网格做独立审计。预览和导出不是一回事。

速度、格式与人机工程

基准之外，OpenSCAD 的优势还有：16 毫秒的重建、LLM 可以直接书写的紧凑文本格式、安全的沙箱，以及不需要配置 Python 运行时。它内置的 Customizer 能把参数块变成终端用户的设置界面。它的结构性限制：没有几何查询、不能导入 STEP、渲染画的是三角剖分而不是零件轮廓。

CadQuery 的优势：Python 生态、B-rep 精度和数据交换——从一个真正的 STEP 文件出发再加参数化特征，是 OpenSCAD 给不了的工作流，因为 STL 是有损格式。T2 里 CadQuery 的派生尺寸链立了功：改一下唇缘深度，边缘、板、槽和倒钩全部联动，因为每个尺寸都是派生的，不是手敲两遍的。代价在工具链——CadQuery 没有 Customizer 的对应物，常量块就是它的全部参数界面。

还有一件事值得知道：CadQuery 文档声称构建速度比 OpenSCAD 快，而这次基准测到的结果相反（重算 1.9 秒 vs 16 毫秒）。两者度量的不是同一批零件上的同一个操作——都当作特定来源的说法看待，如果重建速度对你的场景是决定性的，就用自己的负载去测。

该选哪一个

ModelRift 自己选择继续用 OpenSCAD——紧凑格式、沙箱和渲染速度，盖过了一个可以围绕工具补建的验证优势（他们的理由）。你的约束可能不同，但注意他们决策的形状：工具的选择，不如他们围绕工具搭建的验证闭环重要。

路线法则

如果交付物是一个功能部件，AI 图像生成就是错误的车道——渲染再好看也一样——code-CAD 才是正路。在 code-CAD 内部，让任务形态替你选工具，然后把力气花在基准找到所有真实缺陷的地方：循环里的数值断言，加上导出后的独立网格审计。图像与代码的这条分界线同样出现在 UI 生成里，我们在 AI UI 生成：两条路线里单独写过。

外观交给渲染，装配交给代码，验证永远交给数字。