Text-to-CAD实测：一句话生成可编辑参数化模型

半年前我第一次在浏览器里输入“生成一个M6六角螺栓，螺纹长度20毫米，总长30毫米”，十几秒后屏幕上弹出一个能直接导进SolidWorks的STEP文件时，我确实愣了一会儿。这和过去理解的“AI生成3D”完全不是一回事——它不是生成一张像螺栓的图片，而是真的生成了带特征历史、带参数约束、能继续编辑的CAD实体模型。text-to-cad这个方向从玩具变成工具的速度，比我想象中快太多了。

这篇文章不是概念科普，我想把这段时间实测text-to-cad的完整心得写出来：它背后的技术链路到底怎么运转的，主流方案有哪些坑，怎么把一句话需求变成真正能下料、能加工的模型。无论你是机械工程师、工业设计师，还是刚接触CAD的学生，只要你想搞清楚“写一句话就能建模”这件事到底靠不靠谱，这篇文章应该能给你一个相对完整的答案。

1. 为什么text-to-cad不是“AI画图”，而是建模范式的一次转移

1.1 先回答一个尖锐问题：这和3D打印随便拉个模型有什么不同

很多人第一次看到text-to-cad，第一反应是：这不就是输入文字生成3D模型吗？类似工具早就有了，比如一些文生3D模型的服务，生成一个“像”马的网格体，或者生成一个看着像螺栓的STL文件。

这里面的本质差异，用一句话概括：文生3D生成的是“形状”，text-to-cad生成的是“工程定义”。

什么叫工程定义？就是模型文件里不光有三角网格的顶点坐标，还要有完整的B-rep（边界表示）几何数据、特征树历史、参数约束关系。也就是说，你拿到的不只是一个“看起来像螺栓”的实体，而是一个可以被修改设计参数、可以被装配约束、可以出工程图、可以直接走CAM编程的零件。

这个区别在什么场景下会体现得特别明显？比如你想把螺栓长度从30毫米改成25毫米。传统文生3D给你的是一个导出的STL网格，你没有原始参数，只能在网格上硬切，切完螺纹还是乱的。而text-to-cad生成的是参数化模型，改一个长度参数，螺纹跟着一起拉伸，整个模型自动更新。

1.2 从“点线面操作”到“意图描述”：交互范式的改变

我用了十几年CAD软件，从最早的Pro/E到现在的Fusion 360，核心交互逻辑一直是：你在界面上选择命令，用鼠标在草图上画线、画圆、拉伸、切除。这套交互的最大问题是——软件记不住你的意图，只记住你的操作。

举个例子。你要设计一个支架，要求“底部四个安装孔，孔距符合标准安装导轨的间距”。传统做法是：你查手册，拿到导轨安装孔距数据，然后计算坐标，然后在草图里一个一个标尺寸，再拉伸切除打孔。整个过程里，你的脑内思维是“我需要一个符合标准的安装孔组”，而你在软件里表达的是“在这几个坐标位置画圆、拉伸切除”。

text-to-cad想改变的正是这一层。你直接告诉系统“做一个导轨安装支架，底部四孔，孔距符合某型号导轨标准”，系统负责把“意图”翻译成“特征操作序列”。这样一来，设计师可以把精力放在“设计什么”而不是“怎么画出来”上。

1.3 一张表看懂：text-to-cad与其他生成方式的能力边界

我做了个对比表，把常见几种“用文本/代码生成模型”的方式放在一起看：

这张表告诉我一个结论：text-to-cad真正对标的不是文生3D，而是“传统的人工参数化建模流程”。它把“人写代码/人点鼠标”变成了“机器写代码/机器生成特征”。所以评价这个工具好不好用，标准不是“生成得像不像”，而是“生成的特征树干不干净、参数能不能改、下游能不能继续加工”。

2. 技术链路拆解：一句话指令如何变成可编辑的特征树

2.1 第一跳：自然语言到草图的语义解析

text-to-cad最前面的模块，本质上是把人类语言里的几何语义抽出来。这不是简单的关键词匹配，而是要理解“长30毫米”修饰的是哪个尺寸，“通孔”和“盲孔”在制造层面的差别是什么，“沉头”意味着头部直径和深度之间有约束关系。

实测下来，这类系统目前普遍采用的做法是：把自然语言描述转成一个结构化的中间表示（Intermediate Representation），例如一组带参数的特征指令列表。比如“创建一个矩形底座，长100毫米、宽50毫米、高10毫米，四角倒R5圆角”，会被转成类似这样的序列：

• 创建一个矩形草图，尺寸100x50
• 拉伸该草图，高度10毫米
• 在四个角点分别创建R5圆角特征

这个解析过程通常由大语言模型完成。LLM的优势在于能理解“四角倒R5”这种口语化的表达，劣势在于有时候会猜错你的真实意图——比如“圆角”在某些方言里指的是圆柱体端部的倒角，这种歧义需要建模者自己检查。

2.2 第二跳：从特征序列到CAD内核的建模代码

中间表示拿到之后，下一步是把特征序列翻译成具体CAD内核能执行的代码。这里有一个非常重要的分支：有的系统直接操作商业CAD内核（通过API调用Parasolid或ACIS），有的系统生成开源内核的脚本代码（如CadQuery、OpenSCAD）。

我自己更偏好基于开源内核的方案，原因有几点：

• 不依赖特定商业CAD软件授权，文件格式透明
• CadQuery这类库生成的STEP文件，导入主流的SolidWorks、Fusion 360都没有问题
• 生成的是Python代码，出了问题我能打开代码手动修，不至于整个模型推倒重来

不过商业内核方案也有它的价值——它和SolidWorks、NX这类软件的集成度高，生成的模型直接就在原生环境里，特征树完全兼容，编辑体验更顺滑。代价是价格更贵，而且往往只能在自己的云平台里调用，迁移成本高。

2.3 第三跳：特征历史重建与几何验证

这是text-to-cad目前最脆弱、也最核心的一环。一个模型就算生成出来了，用户仍然要在CAD软件里继续改。如果特征树是乱的——比如先打的孔在拉伸之前就定义了后面的依赖关系全部错乱——那这模型实际上没法用。

几何验证模块做的事通常包括三件：

1. 布尔运算合法性检查：保证实体没有退化面、没有非流形边
2. 特征依赖顺序校验：确保后续修改参数时，特征重算顺序不会崩
3. 尺寸边界检查：防止出现0厚度薄片、过小圆角等会导致制造失败的结构

我见过很多“看起来正常、一改参数就报错”的生成模型，问题基本都出在这一跳。我的经验是：不要信任生成结果的默认特征顺序，拿到手先在CAD里拖一下关键尺寸看会不会重算失败。这一步能帮你省下巨大的后期返工成本。

3. 主流方案横评：闭源云服务、开源模型与CAD内置工具的取舍

3.1 三类方案的典型代表

这一两年text-to-cad的落地形态大致分三类，我每个都试过一遍，说下真实感受。

第一类：闭源云服务。代表是Zoo推出的Text-to-CAD，直接在网页里输入描述，系统调用背后的LLM和建模引擎生成可下载的STEP文件。优点是开箱即用，不需要配置任何环境；缺点是提示词和输出模型都闭源，出了问题你只能反复改描述重新生成，没法从根上调试。

第二类：开源模型+参数化建模库的组合。这个方向更灵活，典型做法是用大语言模型生成CadQuery或build123d代码，然后本机执行代码生成实体。类似“text-to-cad”的开源项目已经有不少，质量参差不齐。优点是可控、免费、能改代码；缺点是需要自己搭一套流程，对新手有一定门槛。

第三类：商业CAD软件的内置生成式工具。比如Autodesk平台的生成式设计模块，Fusion 360里已经能通过设定约束条件自动产出多个设计方案。严格来说它不是“文本到CAD”，而是“约束到CAD”，但从产品逻辑上它是同一方向——把设计意图直接映射成几何。

3.2 实测数据：生成质量、速度与可控性对比

我拿一个“带四个通孔的矩形法兰”做基准测试，三类的表现差异如下：

数据说明一个事：闭源云服务快，但可控性中庸；开源方案灵活，但要求你有能力修代码；CAD原生工具稳定，但覆盖面窄，得看软件本身支持的生成范围。如果你的目标是日常结构件设计，没有哪个方案能完全碾压其他。

3.3 选型决策表：什么场景用什么工具

这套判断依据是我踩了好几个坑之后总结出来的：

4. 实操一条龙：用文本驱动生成可制造的法兰盘模型

4.1 环境准备：你需要哪些组件

讲完理念和选型，来点能直接上手的。我用的是“大语言模型生成CadQuery代码”这条开源路线，整体成本为零（除API费用），而且在本地跑，数据不出公司网络。

需要准备的东西：

1. Python 3.10+ 环境：我推荐用venv建独立环境，避免污染系统Python
2. CadQuery库：安装命令pip install cadquery，版本用2.x以上
3. 一个可调用的LLM API：OpenAI、Claude或任何国产大模型都可以，只要它支持函数调用或代码生成能力强
4. CQ-editor：CadQuery官方提供的可视化调试工具，强烈建议装，能看到生成过程

装完CadQuery后跑一下官方示例，确认OCC内核能正常工作。我之前踩过Python版本太新导致OCC wheel装不上的坑，如果你遇到类似问题，直接换Python 3.10或3.11基本能解决。

4.2 提示词工程：把设计意图翻译成机器能懂的参数

这是text-to-cad实操里最关键的环节。刚开始我直接输入“给我一个法兰盘”，生成结果惨不忍睹——没有厚度、没有螺栓孔数量、没有倒角信息。后面我总结出一套“设计输入五要素”：

• 几何轮廓：法兰外径、内径、厚度
• 孔特征：螺栓孔数量、孔径、分度圆直径
• 过渡特征：倒角/圆角的具体位置和半径
• 制造约束：拔模角度、壁厚、加工精度
• 标准和单位：公制/英制、遵循什么标准

我自己常用的一套System Prompt模板大概长这样：

你是一个专业的CAD建模代码生成器。你的任务是根据用户描述， 生成可执行的CadQuery Python代码。 硬性要求： 1. 所有尺寸默认使用毫米（mm），除非用户明确指定单位 2. 必须为每个关键特征添加注释 3. 优先使用workplane操作，保持特征树清晰 4. 圆角必须明确指定半径，不允许使用默认值 5. 生成的实体必须可作为水密实体用于STEP导出 6. 如果用户描述不完整，请明确列出缺失参数并给出建议值， 然后基于建议值继续生成

实际输入示例：“创建一个外径80毫米、内径40毫米、厚10毫米的法兰盘，六个M6螺栓孔，分度圆直径60毫米，外缘倒C1.5斜角。”

LLM翻译出的CadQuery代码核心部分大致逻辑是：先建一个外径80的圆拉伸到10毫米厚，再钻内孔，再沿分度圆做6个螺栓孔的阵列，最后在外缘做倒角。这一步跑通之后，你会发现整个流程本质上和在CAD软件里点操作没有区别，只是把“点击”换成了“文字”。

4.3 从生成到导出：导入CAD软件的完整链路

代码生成后，执行它有两种方式：一是直接在CQ-editor里打开运行，二是写成脚本批量执行。我建议先走CQ-editor，因为你需要可视化检查模型，确认没有奇怪的破面或多余的几何体。

核心导出代码如下：

import cadquery as cq # ... 省略由LLM生成的主体建模代码 ... # 假设最终实体存储在 result 变量中 cq.exporters.export(result, "flange.step")

导出之后，直接在SolidWorks里“打开”这个STEP文件。注意关键操作：打开时会弹出一个选项，是否识别特征。不同的CAD软件对STEP文件特征识别的能力差别很大，有的只把模型当成一个哑实体（dumb solid），有的能还原一部分特征历史。

如果软件只识别为哑实体，也别慌。可以用软件里的“FeatureWorks”之类工具做特征识别，或者干脆接受“参数不可改”的现实——反正对于下料和图纸输出来说，哑实体已经够用了。真正需要参数化修改的场景，我建议把STEP文件里的关键尺寸用测量工具重标一遍，然后重建特征树，这个过程熟练后大约只要原建模时间的四分之一。

5. 实测翻车记录：语义歧义、单位陷阱与特征树污染的修复过程

5.1 语义歧义导致的几何翻车

最典型的坑是我让系统“生成一个带四个圆角的长方体底板”。我脑子里想的是“四个角都要R10圆角”，结果系统生成的是四个完全不同的圆角半径——它认为“圆角”是个装饰性概念，自动分配了“美观”的参数。

解决办法不是去抱怨模型笨，而是把需求写到没有歧义的程度：“长100、宽60、高8的长方形底板，四个角点分别应用R10的固定半径圆角。”类似问题还有很多，比如“沉头孔”这个词，有的系统能正确理解，有的会把“沉头”翻译成一个圆柱形凹槽而不是锥形沉孔。遇到这种情况，我的建议是在System Prompt里加入一个“生产术语表”，把常见机械加工术语的精确几何定义定义清楚。

5.2 单位与公差：制造层面的隐形陷阱

这个坑相当隐蔽。有一次我输入“做一个直径1.5英寸的轴”，系统生成的时候默认按毫米处理，“1.5英寸”被当成“1.5毫米”。打开模型后看上去很合理，但放到装配体里，和其他英制零件一配，整个干涉。

更麻烦的是公差问题。文本描述里如果出现“过渡配合”“间隙配合”这类词，当前的text-to-cad模型基本无法正确转换。公差在工程图纸里是一个区间，而不只是一个数值。我的处理方式是：用文本生成基本几何，公差和配合关系全部在CAD软件里后期标注。你千万别指望系统能理解“H7/g6”的含义，至少现在版本做不到。

5.3 特征树污染与后期编辑困难

这是我认为目前text-to-cad最需要警惕的问题。系统往往会生成一大堆不必要的中间特征——比如为了做一个简单的通孔，先建了辅助平面、画了草图、做了旋转切除，最后还留了几个隐藏的坐标系。这种模型表面上看没毛病，但一旦你想把孔径从8毫米改成10毫米，整个特征树的依赖关系就乱成一团。

我的排查方法是在拿到生成模型后，先打开特征树目录，做一次“简化”：

• 删除所有不影响实体形状的辅助平面和草图
• 把多个布尔运算合并成单个特征
• 检查是否有孤立几何体（例如内部残留的退化面）

熟练之后这个过程很快，但是它能极大影响后续的编辑体验。如果生成模型是要长期维护的，那最初生成后的一小时整理时间，绝对值得花。

6. 工作流会怎么变：设计师的新任务不是画图，而是写“建模提示词”

6.1 效率模型：从几小时到几分钟的时间账

作为工程师，我最关心的还是效率。拿刚才那个法兰盘来说，传统CAD操作从新建文件、画草图、拉伸、打孔阵列到倒角，熟练工大概需要15到20分钟。用text-to-cad，包括修正提示词的时间，大约5分钟能拿到STEP文件，质量还相当稳定。

但要做个诚实的对比，在更复杂的零件上，比如一个带多个布尔运算的异形壳体，text-to-cad目前的表现反而不如人工。生成出来的代码经常需要大改，改代码的时间加起来和手动建模差不多。我现在的判断是：标准件、对称件、阵列件这类“特征重复度高”的零件，text-to-cad效率优势明显；真正自由曲面、复杂型面，它暂时帮不上忙。

6.2 能力边界：哪些设计场景暂时别碰

我整理了三个目前不建议用text-to-cad的场景，供兄弟们参考：

• 复杂曲面产品：比如鼠标外壳、椅子造型，这类需要Class-A曲面的设计，文本生成完全达不到要求
• 高精度配合件：需要微米级公差控制的场景，生成器的数值稳定性还不够
• 多零件装配体：当前技术主要面向单零件生成，装配关系的表达还在萌芽期

6.3 我的建议：怎么把这套工具嵌入现有流程

如果你想在公司里引入text-to-cad，我的建议是把它定位成“草稿生成器”而不是“最终设计工具”。具体做法是：

• 用text-to-cad快速生成两到三个满足基本要求的初版模型
• 挑一个最合适的，导入CAD软件后重新整理特征树
• 把整理过程中的“好提示词+坏提示词”记录下来，形成团队自己的提示词模板库

我自己已经在内部维护一个小工具集，把常用的法兰、支架、轴套等基础零件的提示词模板沉淀下来了。新项目启动时，先跑模板再微调，效率比从零开始高一个量级。

多说一句，从我的经验看，这件事对新人反而是机会——它降低了“从想法到模型”的门槛。以前初学者要学会一整套CAD软件操作才能开始做东西，现在只需要会描述需求，建模细节可以逐步在编辑过程中学习。这套“文本描述—生成初模—修正学习”的路径，可能比传统教材的“菜单逐项教学”来得快得多。反正我自己的实际操作体会是——先把文本提示词写好，后半段的人工修正，其实就是在给自己上最生动的一节CAD课。