在机械设计和三维建模这个圈子里摸爬滚打这些年，我一直觉得“从想法到图纸”这一步是效率的瓶颈。哪怕是画一个简单的法兰盘，你也得先把草图轮廓理清楚、再把拉伸和打孔顺序排好，更别提那些几十个特征堆叠的复杂零件了。最近一年，一个叫text-to-cad的概念开始频繁出现在我关注的论文和工具更新里。简单说，就是用自然语言描述你想做的零件，让AI帮你把三维模型直接生成出来，甚至直接落到可编辑的参数化特征树上。这篇文章我不打算给你堆概念，而是把text-to-cad这条技术路线的原理、工具选择、实操流程和踩坑经验一次说清楚，让真正画图的人看完能上手用。
先说清楚它能干什么：text-to-cad解决的核心痛点是“设计意图转几何表达”这段纯体力活。你告诉AI“一块200乘100乘10的铝板，四角各开一个直径8的沉头孔，孔距边20”，它输出给你的不是一张图片，而是一个带着完整特征历史、可以继续修改的CAD文件。适合谁看？机械工程师、创客、3D打印玩家，还有刚入门参数化建模的学生。看完这篇文章，你至少能搭起一条自己的text-to-cad流水线，让AI帮你完成重复繁琐的建模步骤。
1. 先拆穿text-to-cad的真实面目
1.1 它和文生图根本不是一回事
很多人一听text-to-cad，下意识会想到Midjourney那种文生图工具。但这两者的底层逻辑差别非常大。文生图出来的是一个像素矩阵，好看就行，不用考虑尺寸精度；而CAD模型的核心是可编辑的实体几何，包含严格的尺寸、约束、拓扑关系和特征历史。AI如果只是生成一张“看起来像法兰盘”的图片，对工程师毫无意义，因为没法直接加工、没法继续修改。真正的text-to-cad必须做到输出可编辑的B-Rep实体或参数化特征树，这才是它区别于纯生成式AI的关键分水岭。
我试过的几个早期demo项目，确实有直接输出网格（Mesh）的，表面看形状挺像那么回事，但一进CAD软件就傻眼了：没有特征树、没有尺寸约束，想改一个孔径比重新建模还麻烦。这就是典型的“看起来很美，用起来想扔”。
1.2 从自然语言到特征树的三个台阶
目前实用的text-to-cad方案，走的基本是“三步走”路线。第一步，用大语言模型（LLM）理解你的自然语言描述，解析出几何参数、特征类型和约束关系；第二步，把解析结果转换成一段参数化建模脚本，比如CadQuery脚本或FreeCAD的Python API；第三步，在CAD内核里执行这段脚本，生成真正带特征历史的三维实体和STEP文件。这三个台阶环环相扣，任何一环掉链子，最后出来的模型就会出问题。
这个思路的精妙之处在于：它没让AI直接去“画三维模型”，而是让AI去“写建模代码”。写代码这件事恰好是LLM的强项，而CAD软件又恰好能执行代码并保证精度。你可以把它理解成“翻译官中间商”——AI负责把人的意图翻译成机器听得懂的建模指令，机器负责精确执行。这条路绕过了AI直接生成几何体精度不足的死穴，是目前最靠谱的落地方式。
1.3 它到底能帮我们省多少时间
以我自己的实测经验看，花在“重复性标准件建模”上的时间能压缩百分之七八十。比如让你画一个带四个安装孔、中间沉台、边缘倒角的电机安装板，手工建模从草图到特征完成至少二十分钟，用text-to-cad把描述写清楚，一分钟内脚本生成，再花两三分钟检查修正，五分钟左右搞定。但要说完全代替工程师，那还早得很——复杂曲面、装配关系和工程图逻辑，AI暂时还搞不定。合理定位是：它是个超级建模助理，不是建模大师。
2. 技术底层的关键机制拆解
2.1 LLM如何解析几何描述
要让AI准确理解“四角各开一个直径8的沉头孔，孔距边20”这句话，背后需要模型具备空间想象能力和参数抽取能力。这其实是个苦活：自然语言里的“四角”“各”“距边”这些词，没有统一的几何语义，模型需要结合上下文推断出“四个孔呈矩形分布”“孔中心到相邻边的距离都是20”。LLM之所以能做到这一点，是因为它在海量包含工程文档、机械图纸、建模教程的语料上训练过，隐式学会了常见的几何语言模式。
但这里有个常见的坑：同一个零件，不同工程师的描述方式可能完全不同。有人说“沉头孔”，有人叫“锥形沉孔”，还有人说“台阶孔”。所以想让text-to-cad稳定工作，提示词策略比模型本身更重要。这块我后面专门讲。
2.2 为什么是CadQuery和FreeCAD脚本
选型时我对比过好几条实现路径，最后把重心放在CadQuery和FreeCAD上。CadQuery是一个基于Python的参数化建模库，它有清晰的链式API，可以这么说：先画一个箱体，再切掉一个圆柱，再在这个圆柱位置开槽，最后倒角。这种写法天然适合LLM生成，因为每一步语义单一、参数明确，模型不容易跑偏。FreeCAD同样提供Python API，而且能直接看到界面化的结果，对新手更友好。
相比之下，OpenSCAD的CSG语法也很适合代码生成，但它偏向程序化建模，做复杂草图和约束时会比较吃力。直接用原始B-rep内核编程（比如直接调OCCT的底层API）精度最高，但是可读性太差，LLM生成的代码错误率会高到没法用。所以“中等抽象层级的建模DSL”是最佳平衡点。
以下是三种主流脚本路线的对比表，我用了半年后整理的：
| 路线 | 上手难度 | LLM生成靠谱度 | 结果可编辑性 | 适用场景 |
|---|---|---|---|---|
| CadQuery | 中低 | 高 | 强，特征链清晰 | 各种机械零件、钣金件 |
| FreeCAD Python API | 中 | 中高 | 强，保留完整特征树 | 需要界面交互和人工复核 |
| OpenSCAD | 低 | 中 | 一般，CSG树可调参数 | 简单几何造型、创客3D打印 |
2.3 参数化实体和普通网格的本质差异
为什么我一直强调必须生成参数化实体，而不是网格？因为CAD的底层工作流是“特征树+约束”，你在SolidWorks或FreeCAD里看到的每一个拉伸、切除、圆角，都记录着参数和父子关系。这些参数不是死的数字，而是可以被变量驱动、被工程图引用、被后续设计变更影响的活数据。网格模型则是一堆三角形面片的集合，没有拓扑语义、没有尺寸约束，改一个面等于全部重来。
text-to-cad如果输出的是参数化实体，那它产出的东西就可以无缝嵌入你现有的设计流程，和手工建模的零件一样参与装配、出图、仿真。如果输出的是网格，那就是个漂亮的“孤儿”，只能用来看看渲染效果，进不了工程流程。
3. 工具选型与最小可行流水线搭建
3.1 大语言模型怎么选：在线还是本地
LLM是整条流水线的大脑，选型直接影响解析上游意图的能力。在线闭源模型（比如GPT-4系列、Claude系列）在复杂空间语义理解上确实领先，中文描述也能hold住，但劣势是数据出境、API费用、网络依赖。本地开源模型（比如Qwen2.5系列、Llama3系列）在隐私性和离线稳定性上占优，但参数量不够时会出现几何参数抽取混乱的问题，比如漏掉一个孔、把尺寸单位理解错。
我个人针对自己的场景总结了一条经验：能接受API调用费的中小团队直接用在线模型省心；有保密要求的企业单位老老实实上本地模型，最好选14B以上参数量的量化版本，并针对几何描述做专门的指令微调或加写Few-shot示例。
3.2 建模脚本端：CadQuery最适合起步
如果你只想试一条最简流水线，我建议“在线LLM + CadQuery”。CadQuery的生态里有内置的CAD查看器（基于OCCT内核），可以直接预览生成结果并导出STEP文件。这个组合的好处是：即使LLM偶尔抽风，你人工修正CadQuery脚本的成本也远比修正一个莫名其妙的三维模型要低，毕竟脚本是文本，改起来顺手。
安装CadQuery很简单，pip进一个Python环境就行：
pip install cadquery然后一行代码就能搭起最基础的查看窗口：
import cadquery as cq result = cq.Workplane("XY").box(100, 80, 10) cq.show(result)这个库生成的模型精度遵循OCCT内核的标准，量产级别的公差控制完全够用。
3.3 一条完整的text-to-cad最小流水线
上面讲那么多，不如直接跑通一条线。我常用的是这样一个流程：把用户描述发给LLM，让它输出一段CadQuery脚本，脚本里把所有关键尺寸提取成变量；本地收到脚本后先做一次静态检查（有没有语法错误、有没有明显越界的尺寸）；检查通过就执行脚本生成STEP文件，同时弹出一个三维预览窗口；工程师看一眼预览，没问题就保存入库，有问题就现场改脚本参数。这套流程用Python脚本编个后台就能串起来，核心代码部分也就几十行的事。在这种架构下，LLM只管“翻译”，OCCT内核管精度，两者各干各的擅长事，配合起来非常舒服。
4. 手把手实操：把一句话变成STEP文件
4.1 提示词设计：这是最重要的一步
我在这个环节上栽过的跟头是最多的。早期我试过直接说“帮我画一个电机底座”，出来的模型千奇百怪，后来才明白问题不在模型而在提示词。text-to-cad的提示词有一个基本公式：明确形状基准+明确主要尺寸+明确特征位置+明确加工细节。比如：
“使用CadQuery生成一个底板：长120、宽60、高8，单位毫米。在XY平面上创建该底板，四个角各设置一个直径6.5的通孔，孔中心坐标相对于底板边缘分别为X=10、Y=10。底板中心加工一个直径30、深度4的圆形沉台，沉台底部再开一个直径12的通孔。”
这种描述把所有歧义都消掉了，模型基本不会跑偏。工程图里的“三视图描述法”“基准面定位法”在日常对话里很少见，但在text-to-cad里非常出效果。
4.2 从提示词到CadQuery脚本的实例演示
我用上面那句描述，让LLM辅助生成了一个CadQuery脚本，经过小幅修正后的关键代码大致是这样：
import cadquery as cq length = 120 width = 60 thickness = 8 hole_d = 6.5 edge_offset = 10 result = (cq.Workplane("XY") .box(length, width, thickness) .faces(">Z") .workplane() .rect(length - 2 * edge_offset, width - 2 * edge_offset, forConstruction=True) .vertices() .circle(hole_d / 2) .cutThruAll() .faces(">Z") .workplane() .circle(15) .cutBlind(4) .faces(">Z") .workplane() .circle(6) .cutThruAll()) result.export("motor_plate.step")这里有几个容易出错的地方，我逐个说明。rect(...)加forConstruction=True是为了生成一个构造矩形，目的是拿到四个角点坐标，这样打孔的位置就能精确落在边距偏移量上。后续的circle(15)和cutBlind(4)代表半径15、深度4的沉台，而非直径，这需要看你自己的尺寸定义习惯保持一致。
4.3 执行脚本、检查结果、导出STEP
执行这一段代码，CadQuery会生成一个精确的实体模型，用内置的查看器打开能直接看到：
- 底板厚度沿着Z轴方向向上拉伸；
- 四个通孔没有贯穿到沉台区域，因为孔径6.5且位置在角上，和中心沉台没有干涉；
- 沉台深度和通孔特征层级清晰，后续想改尺寸只需改顶部那几个变量。
到这一步，导出STEP文件就算大功告成。这个STEP文件可以直接拖进FreeCAD、SolidWorks或者Fusion 360做后续操作。需要提醒的是，CadQuery导出时如果遇到多实体错误（比如一个模型被意外拆成了几个孤立实体），可以先用clean()方法修复几何后再导出。
4.4 如何验证生成结果的准确性
模型生成之后别急着开心，用目测加测量双重确认。我一般会先在CadQuery脚本里加一段自动测量代码，提取实体体积、边界框尺寸，甚至关键孔位坐标，直接打印出来和设计参数对比。这也是脚本化建模的优势——验证过程完全可以自动化。一旦发现尺寸偏差超过你设定的公差范围，就说明LLM解析参数时出了问题，回去检查提示词里的描述有没有歧义。
5. 实际运行中的高频问题与排查手册
5.1 常见问题速查表
下面这张表是我这几个月使用过程中真金白银踩出来的问题汇总，建议收藏备用：
| 现象 | 主要原因 | 快速排查方法 |
|---|---|---|
| 输出模型和描述完全不符 | 提示词缺失关键定位信息 | 检查是否写了基准面、坐标原点、主要尺寸 |
| 孔径位置全部偏移 | 把“距边距离”理解成了“距中心距离” | 查看生成代码中偏移量的计算方式 |
| 沉台方向反了 | 草图平面和拉伸方向定义错误 | 检查.workplane()所在的面和处理顺序 |
| 尺寸过大过小 | 单位混淆（mm/in）或坐标缩放异常 | 在提示词中明确写“单位毫米”，代码中统一用mm |
| 脚本报错Unable to create geometry | 先切割局部再倒角导致拓扑错误 | 调整特征顺序，倒角尽量放最后 |
| 生成结果有干涉 | 先生成孔再叠加其他特征 | 检查布尔运算顺序，必要时拆分特征 |
5.2 文本描述模糊导致的歧义类问题
如果说提示词工程是text-to-cad的上限，那么模糊描述就是它的下限。遇到过最典型的案例是“在板的右侧开一个U型槽”，这句话在自然语言里完全没有歧义，但对建模脚本来说问题大了去了：U型槽是通的还是盲的？槽的宽度和深度多少？“右侧”是沿长边还是宽边？尺寸到底是多少？这种描述喂给模型，出来的结果全靠猜，基本没法直接用。所以我的原则是：凡是涉及定位、尺寸、深度，提示词里必须给出具体数字和参考基准，宁可冗余，不可含糊。
5.3 单位制和坐标系混用的坑
国内小伙伴习惯毫米，国外不少开源示例用的是英寸，CadQuery默认的底层单位是毫米，但如果你参考了英文博客的代码，很容易把0.5看成0.5英寸，结果模型小了一大截。坐标系同样是个坑，Workplane("XY")和Workplane("XZ")差之毫厘谬以千里。建议在项目里强制统一约定：所有尺寸都写成变量、所有文本都带单位、所有特征都从同一个基准面开始构建。
5.4 从单次生成到模板沉淀
用了一段时间你就会发现，很多零件其实是“同一祖宗，不同尺寸”。电机安装板、传感器支架、轴承座，这些通用结构完全可以直接沉淀成模板。把生成过的靠谱CadQuery脚本收集起来，参数全部变量化，下次遇到类似需求，直接拿模板套参数比再跑一遍LLM靠谱得多，速度也更快。我自己就维护了一个本地模板库，按功能分类存放，这可能是text-to-cad真正发挥效力的最实在方式——AI负责初期翻译，模板负责长期积累。
最后再分享一点个人体会：text-to-cad这个方向，本质上不是要用AI完全替代工程师的建模能力，而是把从“脑子里的想法”到“计算机里的几何”之间那段低价值的翻译工作自动化。我习惯的做法是，先在CAD里建好最常用的零件模板库，再用LLM驱动CadQuery做变化衍生，最后用FreeCAD做人工复核，这套组合拳打下来，设计周期明显缩短。如果你也正准备尝试，我建议从一块简单的带孔安装板开始，把整个链路跑通，再去挑战复杂模型。过程中遇到奇怪的几何错误不要慌，绝大多数问题在提示词和特征顺序上都能找到答案，多试几次你就能建立起属于自己的判断力。
