从我第一次看到 text-to-cad 这个方向的时候，我就知道这不是一个“锦上添花”的玩具功能。做机械设计、结构件或者非标自动化的人，应该都有过那种体验：产品经理丢过来一句话，“这里加一个带四个安装孔的底板，孔距 50，板厚 5”，然后你打开 CAD 软件，从新建文件开始，拉伸、开孔、倒角、标注，一步步把这句话变成一个可以出图、可以加工的模型。整个过程不算难，但非常枯燥，也非常容易出错。text-to-cad 要解决的，就是这句话到模型的最后一段距离，它直接把人从重复的建模操作里捞出来，让你把精力放在真正需要判断和决策的地方。
这篇文章我打算用一个做机械结构设计多年的视角，把 text-to-cad 的前因后果、实现思路、工具选型和实操过程拆开讲一遍。文章里不会只给你甩一堆名词，也不会只贴一个“演示成功”的截图就完事，我会把从文本理解到几何生成的整条链路摊开，把我实际踩过的坑、试过有效的办法、以及我认为接下来值得继续做的方向，都一并写出来。无论你是做 CAD 二次开发的老手，还是刚接触程序化建模的新人，只要你需要在“自然语言”和“三维模型”之间搭一座桥，这篇内容都应该能给你一个相对完整的参考。我把话放前面：text-to-cad 的门槛没有想象中那么高，但坑也绝对比宣传视频里看到的要多，这篇文章就是帮你把这些坑提前填平的。
1. 从一段描述到一块实体，text-to-cad 到底在解决什么问题
先别急着去找现成的模型和代码，先把问题本身搞清楚。text-to-cad 的字面意思很直白，就是“文本转 CAD 模型”。但我更愿意把它理解成一次建模方式的重构：过去我们是通过鼠标和命令行在跟几何内核对话，现在则是通过自然语言直接表达设计意图。它和前几年火过的“参数化设计”还不完全是一回事。参数化设计强调的是“尺寸可驱动、模型可复用”，但你仍然需要手动搭建那套参数关系；text-to-cad 强调的是“意图理解”，让机器替你把“我要什么”翻译成“怎么建”。
这种重构带来一个非常实际的价值：把建模门槛从“会操作软件”降低到“会描述需求”。一个结构工程师可以不用再死磕某个 CAD 软件的冷门命令，他只需要说清楚“底部法兰外径 120，内径 60，均布 8 个沉头孔”，剩下的几何构建工作由系统来完成。对于企业来说，这意味着新人的培训成本可以大幅压缩，老工程师的重复劳动也可以大量释放。
但别高兴太早，这件事真正难的地方在于：自然语言是充满歧义的，而 CAD 模型是可度量的精确几何。两者之间存在一个巨大的鸿沟。举个例子，“在板的中间开一个孔”，这个“中间”到底是几何中心，还是某个基准面的投影中点？“一个孔”是通孔还是盲孔？直径多少？公差等级呢？这些信息在人跟人沟通的时候可以通过上下文和常识自动补全，但机器不会，它需要一套机制去处理这种不确定性。这也是 text-to-cad 和普通文本生成任务最大的区别：你不能只生成一段“看起来合理”的文字，你生成的东西必须能通过几何引擎的拓扑检查，必须能量出真实的尺寸，必须能导出成加工能识别的格式。
所以，text-to-cad 本质上是三条技术线的交汇：自然语言处理、几何建模、以及数据格式转换。我在后面几节会分别展开。
1.1 核心需求解析：谁最需要这个东西
我给这个方向画了一个粗略的用户图谱。最急需的是非标自动化设备设计领域，因为这类设计每天都要产出大量结构相似的钣金件和机加件，区别往往只是尺寸和孔位布局，整套流程高度可模板化。其次是机械零部件的选型阶段，工程师经常需要快速拉出一个大致形状来做装配仿真和干涉检查，相对于精细建模，他们更看重“出模速度”。第三类用户是教育领域，用来教学生理解工程图学，学生把读图结果用文字描述出来，再生成模型做对比，比死记硬背命令效率高得多。
还有一个容易被忽略的场景，就是通过文本对已有模型做修改。比如你手上有一个旧版本的支架，你希望把侧板加高 15 毫米，把两个安装孔从直径 8 改成直径 10。在传统流程里，你需要找到对应的特征，修改草图，然后重建。在 text-to-cad 的思路里，这类修改可以被抽象成“增量编辑指令”，系统解析文本后自动定位特征并完成修改。这个场景的商业价值比从零生成还大，因为它直接嵌进了迭代设计的日常流程。
1.2 为什么现在才火起来
严格来说 text-to-cad 不是什么横空出世的概念。CAD 领域很早就有人研究“用命令流描述几何”，AutoCAD 的脚本文件、Pro/E 的关系式，本质上都是文本驱动建模。只是那时候的“文本”是固定格式的编程语言，不是自然语言。真正把这把火点起来的，是大语言模型在代码和结构化输出上的能力突破。模型学会了把“加四个孔均布在直径 100 的圆上”理解成“4 个特征，圆形阵列，阵列直径 100”，并且能直接生成对应的程序化建模代码。
再叠加一个基础设施层面的变化：程序化建模内核开始以库的形式开放出来。过去你调几何内核，得买商业授权、学习一团庞大的 API 文档，现在像 CadQuery、OpenSCAD、trimesh 这些开源库已经能覆盖相当一部分 B-rep（边界表示）建模需求。有了大模型做“翻译”，再有了开源内核做“执行”，text-to-cad 才真正具备了从论文走向应用的条件。
2. text-to-cad 的核心链路拆解
如果你准备自己搭一个 text-to-cad 系统，或者你只是想知道这东西内部是怎么工作的，我建议你把整条链路拆成三个层次来看：文本理解层、几何生成层、输出对接层。别指望一个大模型直接从文本输出二进制 CAD 文件，那不现实，工程上也不会这么干。现在所有可落地的方案，几乎都是“模型生成中间表示，中间表示驱动内核建模”的分层结构。
2.1 文本理解层：从自然语言到参数约束
这一层负责把用户的描述解析成结构化的建模参数。比如“长 100 宽 50 高 20 的长方体，顶面四角倒圆角 R5”，文本理解层需要输出一个数据字典，大致是：基体类型为 box，长 100、宽 50、高 20，倒角特征为矩形阵列，圆角半径 5，位置在顶面四角。
这里有一个关键选择：到底让大模型直接输出参数，还是让大模型先写一段代码，再由代码生成参数？两种路线都有团队在试。直接输出参数的好处是格式稳定、好校验，坏处是你得为每一种几何特征设计一套参数模板，覆盖面有限。让模型写代码的好处是灵活，OpenSCAD、CadQuery 这类库本身已经提供了很丰富的建模原语，模型只要生成合法的建模代码即可；坏处是代码可能写得对，但建出来的模型不是你想要的，而且代码层面的错误排查起来比较费劲。
从我实际测试的结果看，现阶段做项目优先选择“代码生成”路线，因为大模型对代码语法的掌握远比对“自定义参数字典”的掌握要成熟。你如果让模型在一堆 JSON 字段里选值，它经常会在嵌套层级上犯迷糊；但你让它生成 CadQuery 代码，它反而能比较准确地调用 workplane、slot、hole 这些 API。这不是因为模型更聪明，而是因为这类库的训练语料在开源社区里足够多，模型见过的模式足够丰富。
2.2 几何生成层：程序化建模与边界表述
拿到参数和代码之后，真正的几何构建发生在这一层。程序化建模的核心思想是“用代码描述建模过程”：先建立线、再建面、再拉成体、再在体上做布尔运算。以 CadQuery 为例，它内部封装了 OpenCascade 几何内核，你写的每一行建模代码最终都会被翻译成内核 API 调用，生成拓朴实体。
这一层要关注的是几何有效性。模型生成的代码，语法可能没问题，但几何上可能完全不可用。最常见的是布尔运算失败，比如你要在一个实体上减掉一个孔，但孔的位置刚好让两个面发生零厚度的接触，内核就会报错；还有一种是面片翻转，生成的 STL 网格法线方向不一致，导致切片软件或渲染器把模型当成“破洞”。所以几何生成层绝不能只做“执行代码”这一件事，它还要做合法性校验。
我自己的做法是在生成层后置一道自动检查流水线：先检查实体是否非空，再检查体积是否大于零，然后跑一遍形状的包围盒，确认尺寸落在合理区间，最后做布尔求差的“试切”，看看有没有退化面。这些检查听起来简单，但在批量自动化处理的场景里能筛掉绝大多数坏模型。
2.3 输出对接层：格式选择决定下游能不能接住
CAD 的格式生态非常分裂。工业界通用的是 STEP 和 IGES，这是 B-rep 模型的标准交换格式；3D 打印和网格处理常用 STL、OBJ；Web 端展示则用 glTF。text-to-cad 系统不能只输出一种格式，必须根据下游需求做适配。
这里有个容易踩坑的点：很多开源程序化建模库原生支持的是 STEP 导出，但用户最常要的却是 STL。如果你在几何生成层得到的是带精确曲面的 B-rep 模型，导出 STL 其实是一个“离散化”过程，需要设定弦高误差和角度公差。弦高误差设得太小，文件巨大；设得太大，圆柱面直接变成多边形棱柱。我一般给机械件设 0.01mm 的弦高误差，给外观件设 0.05mm，这个经验值在大多数场景下兼顾了精度和文件大小。
3. 工具选型：从零搭一套 text-to-cad 有多少种走法
“从零搭一套”这个说法其实有点吓人，因为真要完全从零去训练一个能理解 CAD 语义的大模型，个人开发者或者中小团队很难扛得住那套算力和数据成本。现实的做法是直接站在已有的模型和库上面做组合。我根据上手难度和落地效果，把主流路线分成三种，你可以根据自己的基础来选。
3.1 路线一：CadQuery 加通用大模型的代码生成
这是我最推荐给个人开发者和机械设计师的一条路线。CadQuery 是一个基于 OpenCascade 的 Python 建模库，API 设计得非常接近“人类思考建模的过程”，比如你可以先选择一个面，然后在面上画草图，再拉伸。这种流程化 API 的好处是，大模型很容易学会调用顺序。你只需要把 CadQuery 官方文档里的常用用法整理成提示词的示例，大模型就能生成像模像样的建模代码。
我在这套方案里踩过一次印象很深的坑。CadQuery 有两个版本分支，老版本的 API 和 2.x 版本的 API 差异很大，如果你在提示词里混用了两者的写法，生成的代码会报一堆属性错误。后来我把提示词模板固定成“只允许使用 CadQuery 2.4 及以上版本的 API”，并在示例代码里标明版本号，模型的错误率立刻下降了一个档次。
这路线的优势是灵活，任何能用 CadQuery 表达的形状都能做，不管是带复杂孔系的法兰盘还是异形支架。劣势是最终效果的上限取决于模型写代码的水平，对于特别复杂的自由曲面，CadQuery 本身就不擅长，用这条路去硬做肯定是强人所难。
3.2 路线二：直接用大模型出 OpenSCAD 脚本
如果你要生成的模型以“程序化参数化”为主，比如各类齿轮、螺纹、建筑结构件，OpenSCAD 其实比 CadQuery 更“贴脸”。OpenSCAD 的建模哲学就是代码即模型，它自带一套非常简洁的 CSG 建模语言，支持基本体素和布尔运算的组合。大模型写 OpenSCAD 的代码往往比写 CadQuery 更少出错，因为 OpenSCAD 的语法更接近函数式描述，没有那么多面向对象的上下文。
但 OpenSCAD 也有一个硬伤：它对倒角和圆角这类“圆滑过渡”的支持很弱。如果你要做的零件有很多圆弧过渡、复杂拔模斜度，OpenSCAD 会让你建得非常痛苦，模型生成出来也经常是一股“低多边形”味。所以这条路线更适合做概念原型和参数化零件库，不适合做精细的机械件。
3.3 路线三：训练专用模型，或者微调现有的开源模型
这是进阶玩法，适合团队手里有大量标注数据，并且有模型训练资源。目前开源社区已经有一些专门做过 CAD 指令微调的模型，它们在生成 CAD 代码的任务上，会比通用模型更稳。你可以在这些模型的基础上，用自己积累的模型库做进一步微调，让模型学会你们公司的标准件命名规范、出图规范和数据格式。
这条路线的门槛不只是算力，更多是数据。text-to-cad 的微调数据和普通文本聊天数据不一样，它要求“文本描述”和“可执行建模代码”成对出现，而且描述里最好带上公差、单位、基准等工程信息。我见过不少团队在这个环节被卡住，因为他们的历史图纸很多是二维 PDF，根本没有可用的三维源文件，建模脚本更是无从谈起。如果你决定走这条路，我建议你优先从“参数化模板”类零件入手收集数据，比如“法兰盘/支架/底板/轴套”这几类，数据量不需要特别大，几百个高质量样本就能肉眼可见地提升效果。
4. 实操：用一句自然语言生成一个带孔法兰盘
理论说了不少，接下来进入正题。我拿一个最常见的机械零件——法兰盘——来完整演示一遍 text-to-cad 的实操流程。我选这个零件是因为它足够典型：有主体特征、有阵列特征、有孔特征，难度适中，能覆盖住大部分建模需求，又不至于像叶轮那样让程序化建模直接崩盘。
4.1 准备环境和依赖
我的环境是 Windows 11 加 WSL2 的 Ubuntu，Python 3.11。建议新建一个虚拟环境，避免把系统 Python 搞乱。
python -m venv cad_env source cad_env/bin/activate pip install cadquery==2.4.0 pip install jupyter pip install trimesh这里推荐装 Jupyter，因为你会需要交互式地查看每一步生成的中间结果。CadQuery 本身提供了cadquery.vis模块，可以在 Jupyter 里直接展示三维预览，调试起来非常方便。如果只想在命令行做批量验证，那用 trimesh 读取 STEP 再导出 STL 也够用。
4.2 提示词怎么写给模型
很多人在 text-to-cad 这一步翻车，不是因为模型不够强，而是因为提示词写得像聊天。你直接丢一句“给我画一个法兰盘”，模型大概率会给你一段泛泛的示例代码，尺寸全靠猜。正确做法是把提示词写成“结构说明加参数明细”的形式。我用的模板大概是这样的：
用 CadQuery 生成一个圆形法兰盘模型，要求如下： 1. 主体为一个外径 120mm、内径 58mm、厚度 15mm 的圆环。 2. 圆环外圈有 6 个均布的安装孔，孔径 10mm，孔心所在圆直径为 100mm。 3. 法兰端面四个角做 C1.5 倒角。 4. 使用合法 CadQuery 2.x API，代码风格参考 CadQuery 官方示例，注释写中文。这已经不是一个“提示词”，而是一份“规格说明书”。模型收到这种结构化的输入，输出的代码质量会稳定很多。你可以理解为，大模型在生成代码的时候实际是在做“翻译”，它的输入结构越接近目标代码的结构，翻译的偏差就越小。
4.3 让模型生成代码并执行
把上面的提示词发给一个支持代码生成的大模型，正常能得到类似下面的代码（这会因为模型版本不同而细节各异）：
import cadquery as cq flange = ( cq.Workplane("XY") .circle(120 / 2) .circle(58 / 2) .extrude(15) ) flange = ( flange.faces(">Z") .workplane() .circle(100 / 2) .cb hole(10) .edges(">Z") .chamfer(1.5) ) show_object(flange)别急着直接拿去导出，先检查几件事。第一，模型生成的.circle()里用的直径还是半径，CadQuery 的circle()接受的是半径参数，如果你在提示词里给了直径 120，这里应该写120/2，如果模型直接写了120，那模型外径就是 240，活活大了一倍。第二，cb hole还是hole，CadQuery 2.x 的新 API 支持cb hole一次完成中心定位和打孔的复合操作，老版本里你得分开写。第三，倒角选择的面是否正确，你要倒的是顶面外圈棱边，如果模型对整个外圈都做了倒角，侧面棱边也会被削掉一圈，视觉上会和你预期的不一样。
把这些修正完之后再执行。如果是在 Jupyter 里，我会分段运行：先生成主体，预览；再打孔，预览；最后倒角，预览。分段预览能让我在每一步出错时立刻知道问题出在哪个环节，而不是等最终导出的模型出了问题再回头倒推。
4.4 导出和后处理
模型确认没问题后，导出 STEP 和 STL。STEP 留给后续结构仿真和加工，STL 可以用来快速 3D 打印验证装配尺寸。
cq.exporters.export(flange, "flange.step") cq.exporters.export(flange, "flange.stl", tolerance=0.01, angularTolerance=0.1)tolerance是弦高误差，单位毫米；angularTolerance是角度误差，单位度。我习惯 STL 的弦高误差控制在 0.01，这样圆柱面有足够多的三角面片，同时文件不至于爆炸。导出后用 trimesh 快速确认一下模型体积和面数：
import trimesh mesh = trimesh.load("flange.stl") print(mesh.volume) print(mesh.is_watertight)is_watertight为 True 是最基本的要求，如果为 False，说明 STL 网格有破洞或者非流形边，送去 3D 打印大概率会出问题。
4.5 优化：把标注也顺手加上
真实出图不能只有三维模型，还得有标注。text-to-cad 的好处是模型尺寸都是参数化的，标注信息可以直接从建模参数里提。我在做完法兰盘之后，会再让大模型基于刚才的代码生成一份 JSON 格式的关键尺寸表，直接对接后端的自动标注工具。这一步的核心价值是让“模型”和“尺寸数据”始终同源，改了一处参数，标注跟着变，不会出现改图忘了改标注的尴尬。
5. 翻车记录：text-to-cad 路上最常见的四类问题
以下是这段实操过程里反复遇到、排查起来最费时间的问题，我把它们整理成一份速查清单。每个问题都附带了我自己的排查思路，希望能帮你省掉一些弯路。
5.1 提示词解析失败：模型给出的代码和需求对不上
症状：模型返回的代码能运行，但出来的模型和你的描述明显不同。比如你说“6 个孔均布”，它给你写了 4 个。
排查思路：先检查提示词里是否把数量、位置写得足够明确，因为“均布”这种说法在大模型眼里不如“以圆心为基准，360 度等间距分布 6 个孔”来得清楚。如果提示词已经明确，那就是模型的注意力偏了，最简单的办法是在提示词里加一句“先列出你识别到的参数表，再写代码”，强制模型先结构化理解一次。这个“先列参数表再写代码”的技巧，能提升不少的成功率。
5.2 布尔运算失败：孔打不上、切除没生效
症状：cut操作抛异常，或者最终模型里孔的位置出现残片。
排查思路：布尔运算失败绝大多数是面重合导致的。比如你用一个孔的底面正好贴在法兰端面上，内核就没法判断是共面还是相交。我在 CadQuery 里遇到这种情况，会把打孔的工作平面往里偏移 0.001mm，人为制造一个微小的重叠量，让布尔运算有明确的交集可算。这一点点偏移在公差范围内完全可以忽略，但能显著提升布尔运算的稳定性。
5.3 参数漂移：单位、公差和目标不一致
症状：生成模型的尺寸单位不是毫米。模型可能给你的是英寸，也可能是基于“图形单位”的相对值，导入到工程软件里尺寸全乱。
排查思路：在提示词里钉死单位，“所有尺寸均以毫米为单位，不允许出现英寸”。另外，你自己的检验脚本里加一道体积和包围盒的校验，比如法兰盘外径如果小于 110 或者大于 130，直接判定为参数错误，这样就有一个客观闸门兜底。不要相信模型的自觉，要靠校验逻辑兜底。
5.4 两次生成结果不一致：用同样一句话得到的模型有差异
症状：同一段提示词，第一次生成的外径 120，第二次变成 120.5，或者孔的数量不一样。这个其实是大模型采样策略带来的固有随机性。
排查思路：如果你要的是可复现的自动化流程，两个办法。第一，把模型温度参数调低到 0.1 以下，让输出趋向贪心解码；第二，在提示词里指定“只输出代码，不解释”，减少模型的自由发挥空间。我实测下来，低温度加结构化提示词，重复生成的一致性可以大幅改善。需要强调，完全一致很难保证，所以在批量生成场景里，务必在流程里设置几何校验，而不是完全信任生成结果。
6. 落地过程中我形成的几条经验
最后讲几条我在实际项目里沉淀下来的经验，不算完整的方法论，但至少能帮你在起步阶段少交学费。
第一条经验是“先解决 80% 的通用件，再碰 20% 的复杂件”。text-to-cad 现阶段对标准件、钣金件、规则机加件的生成效果已经比较能打，但遇到自由曲面、复杂装配体、需要大量参考基准的模型，效果依然不稳定。做产品规划的时候，不要一上来就想着“所有零件都能用一句话生成”，那是给自己挖坑。先把法兰、支架、底板、轴套、导轨安装面这类规则件跑通，就已经能覆盖相当大的日常工作量。等通用件稳定了，再考虑怎么扩展到更复杂的类别。
第二条经验是“必须把人工审查嵌入流程”。不管模型生成的代码看起来多合理，我在导出 STEP 之前都会做一次人工目检。这不是不信任模型，而是因为 CAD 模型的错误往往是“看似正确、实际不可加工”的类型：孔位差了一毫米，肉眼在屏幕上很难看出，但到了装配和加工阶段就是废件。所以我的流程是模型生成加自动校验加人工抽查三层筛子，宁可稍微慢一点，也要保证出去的模型是能用的。
第三条经验跟数据积累有关。每次你修正了一个模型生成错误，都应该把“错误输入、正确代码”存下来作为样本。长此以往，这不仅是你个人的资产，更是以后微调专用模型时最宝贵的数据来源。我自己建了一个简单的表格，记录提示词、生成代码、问题类型和修正方案，目前已经积累了上千条。很多当时觉得头疼的问题，翻回去看的时候，规律性其实非常强。
text-to-cad 不是一个“装上就能用”的成品，它更像是一条需要不断调优的流水线。文本理解、几何生成、格式输出，每一层都有各自的坑，而你只有亲手跳过这些坑，才知道哪些环节需要模型更强，哪些环节只需要工程手段就能绕过去。我现在的体会是，真正能把这个技术落地的前提，不是某个模型参数有多强大，而是你对自己要生产的模型有多大把握，以及你愿不愿意在它身上投入足够的调试时间。这和我十几年前学三维建模时的心态如出一辙：先把最常用的命令练到肌肉记忆，再逐步往复杂功能扩展。text-to-cad 也是一样，先把最简单的法兰盘、底板跑顺，再去追那些复杂的曲面，你会发现原来那些“不靠谱的生成结果”，很多其实只是提示词写得还不够像一份工程规格书。
