Text-to-CAD 这个词我 2024 年在开发者社区第一次看到的时候第一反应是“又来一个炒概念的”。在制造业界折腾了这么多年我很清楚 CAD 模型不是一张渲染图STEP 文件里那些 B-rep 面、边、环背后全是设计意图和加工约束。直到自己亲手把一句话变成能导入 FreeCAD、能输出给加工厂的 STEP 文件我才意识到这次不是噱头——它是把“想法到模型”这条链路真正剪短了。这篇文章就围绕 text-to-cad 展开它是什么、底层靠什么跑通、现在有哪些工具能直接上手、以及我踩过的一堆坑。适合机械工程师、创客、独立开发者还有对 AI 生成 3D 内容好奇的同学。我会尽量少讲空话多给能直接照抄的操作路径和排查经验。1. Text-to-CAD 是什么从自然语言到可制造模型1.1 一句话定义与核心价值Text-to-CAD简单说就是输入一段自然语言描述比如“一个 L 形支架底板长 40mm宽 20mm厚 5mm竖板高 30mm底板上开两个直径 8mm 的通孔”模型直接给你一个可编辑、可参数化的 CAD 模型文件。核心价值不在“能生成一个 3D 模型”而在“生成的是 CAD 模型”。这两句话差别非常大普通的 AI 生图模型给的是像素text-to-3D 给的是三角网格STL/OBJ而 text-to-CAD 给的是参数化实体模型通常是 STEP 格式包含精确的几何拓扑能直接进 CAM 做刀路、能进 CAE 做仿真、能改参数重新生成。这意味着它输出的不是“看起来像的东西”而是“能拿去加工的东西”。我自己的理解是text-to-CAD 的本质是让模型学会“用 CAD 的语言表达一个产品”。就像你让一个经验丰富的工程师画草图他脑袋里想的不只是形状还有“这地方要倒角、那地方要留配合间隙”。现在这个能力开始被模型替代一部分了。1.2 和 Text-to-3D 的根本区别很多人会把 text-to-CAD 和 text-to-3D 混为一谈但其实完全是两个物种。text-to-3D 的代表如 Shap-E、Point-E 这类工具输出的是点云或者网格适合游戏资产、动画、渲染展示。网格模型的问题是没有拓扑信息你没法在 CAD 软件里选中一个圆孔的边去改直径更没法把它作为加工依据。Text-to-CAD 走的是另一条路它生成的是建模流程比如先画草图、再拉伸、再打孔、再倒角。用我常跟朋友打的比方——text-to-3D 给你的是泥塑表面好看但内部是实心的改起来只能捏text-to-CAD 给你的是加工图纸和步骤每一刀怎么下都写清楚了随时可以改。所以如果你只是想要一张炫酷的产品图text-to-3D 就够了但如果你要的是能生产、能装配、能做公差分析的实体模型那必须走 text-to-CAD。1.3 为什么是现在才火Text-to-CAD 的爆火不是凭空冒出来的它是几个条件同时成熟的结果。第一大语言模型到了能稳定写代码的程度。CAD 建模本质上有很强的程序化语法CadQuery、OpenSCAD 这些工具已经把建模抽象成可执行的代码这让模型可以用“写代码”的方式输出建模过程。第二CAD 领域积累了大量高质量的数据集比如 ABC Dataset 里有上百万个 STEP 格式的真实模型DeepCAD 数据集里有接近 18 万个从 Onshape 上解析出来的真实模型操作序列这些正好是大模型最爱的语料。第三云端推理和沙箱执行环境成熟了模型生成代码后可以自动在后端执行、校验、转格式最后把 STEP 发给你。这三个条件缺一个text-to-cad 都只是实验室里的玩具。现在它已经是能跑通的工程方案了。2. 技术拆解模型到底在生成什么2.1 三条主流技术路线我研究过目前开源和商业项目里的主流做法基本可以分成三条路线每一条对“CAD 模型”的理解都不一样这也是最值得掰开讲的部分。第一条是代码生成路线。代表是 Zoo 在 2024 年放出来的 Text-to-CAD我记得它是基于开源大模型微调出来的输出的是 CadQuery 的 Python 代码。模型生成代码后系统在沙箱里执行把代码转换成完整的 STEP 文件。这条路线的最大好处是每个人都能读、能改、能复现而且 CadQuery 背后的 OpenCascade 内核本身很成熟能保证生成的实体模型是严格正确的。第二条是命令序列预测路线。代表是 DeepCAD 和一些后续的 Text2CAD 研究。这类做法不直接生成代码而是把 CAD 建模过程表示成一串离散 token——先画什么草图、用什么约束、拉伸多少、倒角多少。模型像生成一句话一样生成这串 token然后用专门的几何引擎把 token 重建成实体。优势是推理速度快、规模容易控制劣势是可编辑性差你想改一个参数就得重新跑一遍模型。第三条是目前还在快速演进的扩散模型路线。有人试着把扩散模型用在 B-rep 的图结构上直接生成面、边、顶点的拓扑关系。这个方向学术价值很高但离产品化还有距离。我自己实际工作中最常用的是第一条路线。原因很简单代码是中间表示如果模型出了一点小毛病我能直接看到是哪句代码有问题甚至手动改掉而不用重新生成。2.2 数据与 Tokenization 背后的功夫不管哪条路线都绕不开数据和 token 化。CAD 模型不像文本那样天然是一串字必须先把几何和操作转成模型能理解的形式。以 DeepCAD 这类做法为例一个模型会被解析成类似这样的操作序列画一个圆心在某个坐标、半径为 10 的圆然后向上拉伸 5mm再在边缘倒一个 1mm 的圆角。每个操作和参数都会被量化成离散的 token比如半径这一项会被切到 256 或 1024 个区间。模型的任务就是预测接下来该出现哪些操作和参数。这跟语言模型预测下一个词本质上是同一件事。而代码生成路线更直接模型只是在学“代码语法 CAD API 的使用规律”训练时把十几万个真实 CAD 模型的对应 CadQuery 脚本喂进去再用 GPT-4 之类的大模型为每个模型生成文字描述配对成指令微调数据。等模型看到一句话时它就能联想出对应的脚本风格。这里面最花功夫的不是模型结构而是数据清洗。真实 CAD 模型往往是几十个步骤堆积出来的很多步骤对最终形状没有影响直接拿原始操作序列训练模型会学出一堆废话。所以要做“化简”去掉冗余操作、合并共线线段、规范坐标系才能得到干净的训练样本。这块工作没有捷径全是体力活。2.3 为什么大模型擅长生成 CAD 代码我自己觉得大模型在 CAD 这件事上比在写小说上可靠得多原因是 CAD 代码的“语法性”极强。你写一句诗可以有无数种解读但 CadQuery 里box(40, 20, 5)就只能是长 40、宽 20、高 5 的长方体。大模型在约束明确的 DSL领域专用语言里发挥是非常稳定的。更重要的是CAD 建模过程有很多“套路”开孔之前要先在面上新建工作平面、要切除就得先有实体、倒角要选边而不是选面。这些套路就是顺序决策问题而 Transformer 这类模型恰恰擅长捕捉长程依赖。模型学会了“先拉伸成板再在顶面上打孔”这类顺序逻辑输出自然就比随机堆操作靠谱得多。另一个不可忽视的点是代码是可校验的。模型写错了一句 API执行引擎会报错你可以把报错信息原样贴回去让模型自己改。这种“生成—执行—反馈—修复”的闭环是 text-to-CAD 能走向实用的关键也是纯文生模型做不到的。3. 实操跑通你的第一个 Text-to-CAD 工作流3.1 工具选型目前能直接上手的 text-to-CAD 工具我按用途分成三类。第一类是商业化在线服务最典型的就是 Zoo 的 Text-to-CAD。在官网输入描述就能生成也可以走 API 批量调用。它输出 CadQuery 代码和 STEP 文件对非程序员特别友好适合快速验证想法。第二类是开源研究项目比如 Text2CAD 这样的仓库。它们通常包含完整的训练、推理和重建代码但部署成本偏高还需要自己下数据集和 checkpoint。适合想做研究或者想深入理解原理的人不适合只想拿结果的生产环境。第三类是自己搭的“LLM CadQuery”工作流。你手头已经有了 ChatGPT / Claude 这类代码能力很强的大模型只是让它专门输出 CadQuery 脚本在本地执行预览。这条路线可控性最高我日常用的就是这一种。选型建议很简单如果你只是好奇直接用在线服务五分钟就能看到结果如果你想在生产里稳定复现建议走本地 CadQuery 路线如果你要发论文或者调模型再去碰开源研究项目。3.2 在线与 API 快速体验在线体验真的很省事。到 Zoo 的 Text-to-CAD 页面在输入框里用英文或中文描述你的需求提交后等十几秒到几十秒它会给你一段 CadQuery 代码和一个可下载的 STEP 文件。如果要把这个过程接进自己的脚本可以用 Replicate 之类的推理平台。大致流程是注册拿到 API token安装 Python SDK提交 prompt轮询结果。代码很少核心就这几步import replicate client replicate.Client(api_token你的token) prediction client.predictions.create( modelzoo-ai/text-to-cad, input{prompt: A simple L-shaped bracket, base 40mm x 20mm x 5mm, vertical plate 30mm high, two through holes of diameter 8mm on the base.} ) result prediction.wait() print(result.output)注意模型标识符可能会随平台更新变化跑之前先看官方文档确认一下最新的名称。在线服务适合做批量测试比如你想比较 10 个不同 prompt 的效果写个循环调 API 就行了。还有一个技巧大部分在线服务的输入框支持多行描述你可以直接把需求写详细不用缩写。模型对“详细描述”的容错度比“模糊描述”高得多。3.3 本地 DIY用 CadQuery 加 LLM 搭一个如果你希望完全掌控生成过程我推荐本地搭一个“LLM CadQuery”工作流。步骤不复杂环境配置一次后面就顺了。第一步安装 CadQuery。建议在 Python 3.8 以上的虚拟环境里执行pip install cadquery。在 Linux 和 macOS 上通常很顺利Windows 上需要确保有合适的预编译 wheel如果装不上可以考虑用 WSL 或者官方 Docker 镜像。第二步准备一个支持代码的 LLM 客户端。我用的是 Claude 的 API 加一个简单的前端脚本也可以用 ChatGPT 的代码解释器甚至是本地部署的 Qwen、Llama只要能稳定输出 Python 代码就行。第三步设计你的 prompt。这一步是最关键的我后面专门讲。模型会输出一段 CadQuery 脚本比如这样import cadquery as cq # 一个 50x30x5mm 的板中心开一个直径 6mm 的通孔 result ( cq.Workplane(XY) .box(50, 30, 5) .faces(Z) .workplane() .circle(3) .cutThruAll() ) cq.exporters.export(result, plate.step)第四步在 CQ-editor 或者启用了 CadQuery 扩展的 Jupyter 里运行代码。你可以在 notebook 里调用show_object(result)做 3D 预览确认形状对不对、孔位对不对、方向对不对。第五步导出。CadQuery 支持cq.exporters.export(result, filename.step)输出 STEP 文件也可以输出 STL 做 3D 打印切片。STEP 是首选它保留了实体拓扑后续在 FreeCAD、SolidWorks、Fusion 360 里都能继续编辑。这个小工作流看起来简单但它解决了最核心的问题模型只负责“写代码”而你拥有最终的裁决权。代码错了可以改几何错了可以量每一步都可追溯。3.4 Prompt 工程核心技巧Text-to-CAD 的 prompt 和写文书不一样不能只描述外观得描述“建模步骤”。我总结了四个字具体、步骤化。第一把单位写死。模型默认视 mm 为单位但如果你描述的是“两英寸长的板”模型可能还是按 2mm 输出出来就是 50 倍的大小误差。所以我每条 prompt 都会显式带上单位“单位为 mm”。第二按建模顺序描述而不是按视觉顺序描述。比如你要一个带孔的底座不要只说“中间有孔的方形座”而要拆成“先创建一个 50x30x5mm 的长方体然后在顶面中心开一个直径 6mm 的通孔”。模型对步骤化描述的理解准确率高得多因为它本来就是在学操作序列。第三限制 API 范围。在 prompt 里明确要求“只使用 CadQuery 标准 API如 Workplane、box、circle、extrude、cutThruAll、fillet、union”。这样能大幅减少模型幻觉出不存在的函数。第四留好迭代空间。第一次生成很少一次到位拿到结果后把错误信息或者尺寸偏差贴回去让模型“根据这个 error 修正”。这比重新描述一遍需求有效得多。我可以分享一个我自己的 prompt 模板请用 CadQuery 生成一个参数化模型单位为 mm。 需求 1. 先创建一个底板长 40宽 20厚 5。 2. 在底板长边的一侧创建竖板高 30厚 5。 3. 竖板顶部倒 R2 圆角。 4. 底板上沿中心线等距开两个直径 8 的通孔孔间距 24。 约束只使用 CadQuery 标准 API输出可运行的 Python 脚本不要额外的解释。用了这个模板之后成功率比“帮我画个 L 形支架”高出一大截。4. 落地场景与影响范围4.1 三类立刻能落地的场景第一个场景是概念设计和方案比选。以前工程师要出三个概念方案得各自建模一个下午就过去了。现在你把三个方案的文字描述丢给模型十分钟能拿到三个 STEP 文件再在 CAD 里细化和评估。它不替代你的设计能力但替代了“把脑子里想法变成可讨论实体”的时间。第二个场景是非标件和小批量定制。我见过不少做设备集成、工装夹具的团队经常要为一块挡板、一个电机支架建模型。这些件结构简单但很烦人卡住就得半小时。用 text-to-CAD 生成初稿再人工修正孔位和公差能压缩掉大半时间。尤其对独立开发者和三人小团队这个提效非常直观。第三个场景是教育和入门教学。以前教学生认识 CAD 模型得先教软件操作学生卡在界面里出不来。现在可以让学生直接描述一个物体然后看模型生成步骤代码——他看到的不是一个结果而是一连串建模逻辑。这对理解“草图—拉伸—特征”的工作流反而更直接。当然这只适合作为辅助教学手段不能替代规范的软件操作训练。4.2 对工程师工作方式的影响很多人担心 text-to-CAD 会取代机械工程师我的判断是不会至少在可预见的时间内不会。它取代的不是工程判断而是“把自己想法翻译成 CAD 指令”这个偏执行层的环节。这跟集成开发环境对程序员的影响很像。IDE 不会让程序员失业它只是把“记住所有 API 拼写”这件事外包给了工具让程序员把精力放在架构和逻辑上。text-to-CAD 对外行的意义是降低了建模门槛对工程师的意义是降低了重复劳动。但影响范围是实在的它会改变初阶 CAD 工程师的成长路径。以前入行得靠大量画图练出手感以后可能是靠“描述设计意图并审查 AI 输出”的能力。我对新人的建议一直是可以早点学会用这些工具但必须自己动手把每一步几何关系搞清楚否则你连模型错在哪都看不出来。5. 常见问题与排查技巧实录5.1 生成失败与 API 报错我在实际使用中遇到最多的问题是模型输出了一段看起来没问题但一运行就报错的代码。CadQuery 的报错信息通常很直白比如调用了不存在的方法、参数传了负数、工作平面选择语法不对。处理办法有两个。第一在 prompt 里锁死 API 范围这是预防。第二把完整报错信息原样复制回给模型让它自己修。我试过很多次让模型修自己的代码成功率比重新写一段还高因为它能看到具体错误。如果代码能运行但结果异常比如缺了一个孔、多了一块体这时候靠改 prompt 往往不如直接改代码来得快。我通常会把导出的 STEP 文件先转回代码看一遍定位到具体某个extrude或cutThruAll行手动调节参数再重新导出。这就是选代码生成路线的好处——可以人机协作。5.2 单位与几何错误有一个特别隐蔽的坑模型会“理解”尺寸但不一定“尊重”尺寸。你说“直径 3mm 的孔”它可能生成半径 3mm 的孔整整大了一倍。所以拿到模型后第一件事是量尺寸而不是看形状像不像。导出 STEP 后我习惯用 FreeCAD 或者 CadQuery 的boundingBox做一次快速校核bb result.val().BoundingBox() print(bb.xlen, bb.ylen, bb.zlen)如果整体尺寸差得离谱大概率是单位或半径/直径的语义理解出了问题。尺寸对但位置不对比如孔偏了就回去改代码里的坐标或pushPoints参数。另外一个常见几何问题是布尔运算失败。两块体刚好共面或者有零厚度的缝合边union或者cut会直接报错。解决办法是在 prompt 里避免设计共面结构或者代码里留出极小的间隙。实在不行就先分体导出在真正 CAD 软件里做布尔运算那边容错更好。5.3 从结果到实物的质量检查生成模型最终要走到加工所以质量检查不能省。我整理了一个排查清单每次生成后按顺序过一遍检查项方法问题表现整体尺寸量 bounding box差 25.4 倍是单位错差 2 倍常是半径直径混淆孔位与孔数剖视或选中孔面孔缺失、孔位偏移最小壁厚FreeCAD 里剖切测量壁厚为 0 或过薄影响加工布尔一致性导出 STEP 时检查有无报错共面、自交、碎边方位基准确定原点与基准面方向翻转、装配时对不上这五条都过了我才会把文件发给加工或者切片软件。行业里的真实项目精度和公差是靠工程师控制的AI 生成结果只能当“毛坯”。5.4 一批实用避坑技巧最后分享几个我用下来的小技巧都是常规文档里不会写的。一是描述里尽量少用“好看”“圆润”这类模糊形容词大模型对美学词的理解不稳定。你要圆角就直接写“给顶边倒 R2 圆角”效果完全不同。二是复杂零件一定要拆分。一次让模型生成整体复杂的装配体大概率翻车。我习惯把一个零件拆成几个子部件分别生成再用 CadQuery 的union或直接在 CAD 软件里组装。子部件越简单成功率越高。三是善用“生成两版”的策略。同样的 prompt 提交两次模型可能给出不同方案。其中一版出错另一版可能就是对的。在线服务有随机性这是免费的多样性。四是我个人很推荐的不要只看渲染结果一定要切开看剖面。很多模型表面光鲜内部孔道是断的。对非关键零件影响不大但对需要走管线或装配的零件就是致命的。提前剖视能省下不少返工时间。我自己在实际操作中的体会是text-to-CAD 现阶段最舒服的定位是“设计初稿生成器”而不是“设计器”。一个合格工程师需要的能力依然没变判断尺寸合不合理、工艺能不能落地、装配有没有干涉。AI 只是把画图的时间从一小时压到一分钟剩下的判断你必须拿回来自己把关。后面如果再遇到什么新坑我继续补在这篇里。