CadQuery 真能赢 OpenSCAD 吗？

一项围绕 Agentic CAD 的对比实测给出了一个不太符合直觉的结论：CadQuery 的 CAD 内核和工程能力明显更强，但在当前大模型实际写代码、修错误、交付模型的流程里，OpenSCAD 仍然更容易成功。

这不是在说 OpenSCAD 比 CadQuery 更专业，也不是说 Python 不适合做 CAD。问题在于，Agentic CAD 还处在“让模型先把东西稳定做出来”的阶段，理论能力更强的工具，不一定就是自动化工作流里的最佳工具。

本文讨论的 Agentic CAD，是指由大模型或其他智能 Agent 根据自然语言、草图、尺寸约束和迭代反馈，自动生成并修改参数化 CAD 脚本的工作方式。它和传统的“工程师手写脚本”不同：评价重点不只是几何内核能做什么，还包括模型能否理解 API、能否定位失败原因，以及修改一处后会不会把其他特征一起破坏。

先说结论：专业建模选 CadQuery，快速生成选 OpenSCAD

如果目标是机械零件、可进入后续 CAD 流程的精确模型，CadQuery 更值得投入；如果目标是让当前主流大模型快速生成一个能渲染、能导出、能继续修改的模型，OpenSCAD 依然是更稳的默认选项。

CadQuery 是基于 Python 和 OpenCASCADE Technology（OCCT）的参数化 CAD 库。它通过 Python API 创建实体、工作平面、孔、倒角、圆角和布尔运算，输出包括 STEP、STL、AMF 和 3MF 在内的多种格式。

OpenSCAD 是使用专用脚本语言描述实体几何的参数化建模工具。它的核心思路接近“用代码搭积木”：通过立方体、圆柱体、球体等基本体，再组合 union、difference 和 intersection 完成模型。

两者都属于 CAD-as-code，也就是用文本代码代替传统 GUI 操作。但它们面对 Agent 的难度完全不同：OpenSCAD 的语法和几何操作集合更小，CadQuery 的表达能力更接近真正的机械 CAD，同时也带来了更长的上下文、更复杂的对象状态和更多潜在错误。

| 对比维度 | CadQuery | OpenSCAD | 对 Agentic CAD 的影响 | | --- | --- | --- | --- | | 主要语言 | Python | OpenSCAD 专用语言 | Python 生态更强，但 API 面更复杂 | | 几何内核 | OCCT | CGAL | CadQuery 更适合精确实体和复杂曲面 | | 参数化方式 | 工作平面、选择器、特征链 | 布尔运算、模块、变量 | OpenSCAD 的状态更少，生成更容易稳定 | | STEP | 原生导入、导出 | 不支持原生 STEP 工作流 | CadQuery 更适合和专业 CAD 交换数据 | | NURBS 与样条 | 支持 | 能力有限 | CadQuery 更适合曲面和复杂几何 | | 代码生态 | 可使用 Python 标准库和第三方库 | 生态相对封闭 | CadQuery 更容易接入自动化流水线 | | 上手难度 | 较高 | 较低 | OpenSCAD 更适合快速原型和模型生成 | | Agent 修错难度 | 较高 | 较低 | 简单任务 OpenSCAD 的成功率更有优势 |

这次实测真正测的，不是“谁能画得更复杂”

Agentic CAD 的关键指标是闭环成功率，而不是单次生成的理论上限。 一个完整的测试，至少应该让模型根据同一组自然语言要求，分别生成脚本，执行脚本，检查导出结果，再根据错误信息进行多轮修正。

典型任务包括带孔的支架、带圆角的盒体、螺栓连接件、参数化外壳，以及需要反复调整尺寸的零件。这样的任务比“生成一个圆柱体”更接近真实使用，因为 Agent 必须同时处理尺寸、拓扑、特征顺序和输出格式。

参考实测的价值在于，它没有停留在“OCCT 比 CGAL 强，所以 CadQuery 必胜”的纸面比较，而是把当前模型实际能否写对代码放在第一位。测试结论偏向 OpenSCAD，并不等于 OpenSCAD 的几何内核更强，而是说明当前模型对 OpenSCAD 这种低状态、低语法复杂度的系统更容易完成有效控制。

在 OpenSCAD 中，一个简单零件通常可以拆成几个基本体，再用布尔运算组合。Agent 只要保持变量命名和括号结构正确，就能得到相当可用的结果。CadQuery 则经常需要处理工作平面、对象栈、选择器、链式调用和特征依赖。代码看起来像普通 Python，但每个调用背后都可能改变当前工作对象，错误往往不是语法错误，而是“代码能运行、几何却不对”。

这正是 CAD Agent 最难的部分：它不仅要生成代码，还要理解几何拓扑。比如一个圆角操作失败，原因可能是边选择器选错，也可能是圆角半径超过局部几何允许范围，还可能是上一步布尔运算生成了不同的拓扑结构。对人类工程师而言，这些问题可以通过界面、剖切和经验快速定位；对只看到文本报错的 Agent 而言，难度高得多。

CadQuery 的优势是真实的，而且不是小优势

CadQuery 的优势来自更接近工业 CAD 的实体建模内核，而不是来自“Python”这两个字本身。 CadQuery 以 OCCT 为基础，能够处理精确曲面、NURBS、样条、曲面缝合、STEP 交换和 STL 修复等能力。

B-rep 是边界表示模型，也就是用精确的面、边和顶点描述实体边界，而不是只记录三角形网格。CadQuery 使用的 OCCT 属于这一类更适合工程设计的几何内核；STL 则主要保存三角形网格，适合打印和可视化，却不适合无损地继续编辑工程特征。

这带来一个非常实际的差异：从一个外部 CAD 软件导出的 STEP 文件开始，再在其上增加参数化孔、凸台或倒角，是 CadQuery 的强项。 OpenSCAD 可以导入 STL，但 STL 已经丢失了原始的曲面、特征和设计意图，后续修改更像是在网格上重新搭建几何，而不是接着原设计继续工作。

CadQuery 的另一个优势是定位方式更丰富。OpenSCAD 更多依赖坐标、尺寸和布尔关系；CadQuery 可以依据工作平面、顶点、边、面的位置和类型选择特征。对于孔阵列、局部倒角和面上开槽，这种“根据几何关系定位”的方式更接近工程师使用 CAD 软件的习惯，也能减少硬编码坐标。

Python 生态同样重要。CadQuery 脚本可以使用标准库、数值计算工具、文件处理模块和成熟的开发环境，能够接入测试、版本控制、批量参数搜索和自动化验证。对于要把 CAD 生成嵌入产品配置器、制造流程或数据管线的团队，这比一个相对封闭的专用脚本语言更有吸引力。

CadQuery 2.8.0 于 2026 年 6 月发布，延续了基于 OCP 的架构，并进一步稳定自由函数 API；其底层绑定过渡到 OCP 7.9。这个变化对普通用户不一定立刻可见，但它意味着 CadQuery 正在减少中间层限制，直接释放 OCCT 的更多能力。对 Agent 来说，API 稳定性也很关键：接口越一致，模型越容易通过文档和示例学会。

OpenSCAD 为什么仍然是模型更容易写好的工具

OpenSCAD 的最大优势不是功能丰富，而是它把问题压缩到了模型更容易预测的范围。 一个 OpenSCAD 文件大多由变量、模块、基本几何体和布尔操作组成，执行顺序和结果关系相对直观。

对于大模型，这种低复杂度非常宝贵。模型可以从训练数据中学到大量常见写法，也可以通过错误信息快速修改括号、变量和模块参数。即使生成的模型不够优雅，只要尺寸和结构大致正确，用户就能继续编辑。

OpenSCAD 的语法还天然适合文本 diff。Agent 可以把“底板厚度从 4 毫米改成 6 毫米”落实为一个变量修改，版本控制系统也能清楚显示变化。CadQuery 同样可以参数化，但链式 API 更容易出现一处选择器变化、后续整个特征链失效的情况。

这里需要纠正一个常见误解：OpenSCAD 不是“只能做玩具模型”。它不适合作为完整的工业 CAD 替代品，但对于夹具、收纳盒、安装支架、3D 打印部件和规则机械结构，它足以覆盖大量需求。很多项目真正需要的是可重复生成、易于分享和快速调整，而不是完整的曲面设计能力。

对开发者来说，最合理的方案不是二选一

在 2026 年的 Agentic CAD 工作流里，CadQuery 和 OpenSCAD 更像是不同阶段的工具，而不是互相排斥的替代品。

对于概念验证和快速生成，可以先使用 OpenSCAD。它适合让 Agent 在几轮对话内生成一个结构清楚、参数集中、能够导出 STL 的模型。这个阶段的目标是验证尺寸和方案，而不是立刻完成制造级交付。

对于需要进入机械设计流程的项目，再切换到 CadQuery。只要涉及 STEP 交互、精确倒角、圆角、复杂曲面、外部 CAD 资产复用或批量参数化，CadQuery 的能力上限就会明显更高。

更成熟的架构是让 Agent 具备工具选择能力：规则几何优先使用 OpenSCAD，精确实体和 STEP 任务使用 CadQuery，网格修复交给专门工具，最终通过几何检查器验证输出。这样做的重点不是让一个模型掌握所有 API，而是把任务拆给更适合的执行器。

一个可落地的 Agentic CAD 流程至少应包含四层：

1. 需求解析层：把自然语言拆成尺寸、材料、容差、特征和输出格式。
2. 建模执行层：选择 OpenSCAD、CadQuery 或其他 CAD-as-code 工具并生成脚本。
3. 几何验证层：检查实体是否封闭、体积是否合理、孔是否贯通、单位是否一致，以及导出文件能否被目标软件打开。
4. 错误修正层：把脚本错误、内核错误和几何检查结果反馈给 Agent，而不是只告诉它“生成失败”。

没有验证层，所谓自动 CAD 只是“让模型写一段看起来像 CAD 的代码”。真正能用于生产的系统，必须知道生成结果是否满足约束。

实测结论应该如何解读

“当前模型更擅长 OpenSCAD”是一个阶段性工程结论，不是永久性的技术判断。 大模型对工具的掌握会随着训练数据、上下文长度、工具调用和视觉反馈能力变化。CadQuery 今天的复杂，可能会在下一代模型中变成普通 API 调用。

不过，工具本身的可验证性仍然不会过时。CadQuery 的选择器和特征链更强，也意味着 Agent 必须拥有更好的几何观察能力；如果系统只能读文本，OpenSCAD 的简单性就是优势。如果系统可以查看面、边、法线、包围盒和实体拓扑，CadQuery 的表达能力才有机会真正转化为成功率。

因此，选择 CAD 工具时不应只看内核排行榜，而要看完整任务的成功率、平均修正轮数、导出格式质量和人工接管比例。一个模型首次生成成功率为 70%、平均需要 1 次修正的简单工具，实际可能比首次成功率为 40%、但理论上能处理复杂曲面的工具更适合自动化生产。

OpenAI Hub 判断：CadQuery 是长期答案，OpenSCAD 是当前默认答案

如果你今天要搭一个 CAD Agent，建议先把 OpenSCAD 作为基线，再把 CadQuery 作为专业能力层接入。 这比一开始就用 CadQuery 解决所有任务更容易获得稳定结果，也能用真实数据判断什么时候值得切换。

对个人开发者，OpenSCAD 适合快速验证提示词、参数模板和模型修正策略；CadQuery 适合在项目进入精确建模、STEP 交换和 Python 自动化阶段后使用。对团队而言，最好同时维护两套生成器，并用同一批任务持续回归测试，而不是根据一次模型发布或一篇文章的结论永久选边。

CadQuery 的方向没有问题：OCCT、STEP、Python 和参数化特征，决定了它更接近可持续的工程工作流。OpenSCAD 也没有过时：简单、可预测、容易被模型生成，正是 Agentic CAD 早期最需要的特性。

最后的判断很明确：要做“像 CAD 的东西”，OpenSCAD 依然够用；要做能进入 CAD 流程的工程模型，CadQuery 更有潜力；要做真正可靠的 CAD Agent，答案是工具路由加几何验证，而不是押注单一工具。

参考来源

• CadQuery 官方文档（GitHub）：CadQuery 的项目代码、安装方式和功能说明。
• CadQuery 项目仓库：介绍 CadQuery 与 OpenSCAD 的关系、OCCT 能力、STEP 导入导出和多格式构建性能。
• CadQuery 社区讨论（Reddit）：专业用户分享 CadQuery、OpenSCAD 和 build123d 在 CAD-as-code 场景中的使用体验。
• OpenSCAD、CadQuery 与 build123d 对比讨论（Reddit）：相关 Agentic CAD 实测观点和工具选择背景。

注：本文依据公开资料与参考实测整理。不同模型版本、提示词、几何任务和验证器配置，会显著影响最终成功率；在生产环境中应使用自己的任务集进行回归测试。