从文本到CAD模型：text-to-cad技术原理与工程实践

1. 一个需求单引发的思考：text-to-cad到底戳中了谁

很多人在聊text-to-cad时，都喜欢从"AI会不会取代设计师"这个角度切入，我觉得这不是重点。我自己的经历是，真正让人头疼的从来不是设计本身，而是"从需求文本到第一版模型"之间的那段空白。尤其在非标设备、结构件、自动化方案这些领域，客户的初始需求往往就是一段话：底座高度300，上面开四个腰形孔，孔距按标准导轨做，外加两个M8螺纹孔。这段话在任何人脑里都足够清晰，但到了CAD里就是一笔一笔的草图、约束、拉伸、打孔，而且每一步操作背后都有一整套软件交互逻辑等着你。

1.1 先还原一个真实的CAD打样场景

传统流程里，我拿到这段话后会经历这样几步：翻资料库找类似的底座，如果没有就新建文件，选基准面，画中心线，用智能尺寸标注约束，拉伸一个基体，再选面打孔，最后检查干涉。整个过程如果顺利，半小时起步；如果不顺利，比如基准面选错了，或者草图的几何约束没设置好导致过定义，来回调整尺寸，一上午就没了。更别提网上天天有人搜"cad画直线显示2.1616e+什么原因"这类问题，那只是因为坐标输入格式触发了科学计数法显示，就足以拦住一批刚入门的人。CAD工具的上手成本，从来都不在产品逻辑，而在这些琐碎到离谱的操作细节里。

这个过程里最反直觉的是，真正花时间的不是"设计决策"，而是"把决策翻译成几何操作"。你能想象"I形梁"只需要三个字，但在CAD里你要先算好翼缘和腹板的尺寸比例，画出截面，再沿路径拉伸。text-to-cad这类项目刚好摸到了这个痛点：它把"翻译"这一步接管了。我第一次跑通它的时候，最大的感受不是"模型生成得多逼真"，而是"原来我从需求到实体之间的那一大段机械操作，真的可以被压缩掉"。

1.2 定位：它不是替代CAD，而是替代"从零开始"

我实测后的结论是，text-to-cad的目标不是替代SolidWorks或者AutoCAD，它更像是一个"从零到一的加速器"。你给它一句描述，它返回一个参数化模型文件，你可以把它导入常规CAD软件继续修改。这就好比以前写文章要面对一个空白Word文档，现在先让AI起个草稿，你再改。"起草"这个动作，是它真正替代的部分。

这一点决定了它的使用边界：适合做概念模型、标准件、结构件的前期设计，不适合做需要严格公差分析、复杂曲面造型、多实体装配关系验证的最终设计。搞清楚这个边界，再上手就不会有"AI生成的东西根本不能用"的失落感。我见过不少同事第一次用这类工具，指着一个生成出来的小零件说"这尺寸不对啊"，然后直接下结论说工具没用——其实问题出在提示词没写清楚，跟工具本身没关系。

1.3 哪些人应该先关注它

我梳理了一下，目前最该关注text-to-cad的人群有三类。第一类是做非标自动化和结构设计的工程师，你们每天面对大量"文字需求转模型"的琐碎工作，这东西能帮你把方案阶段压缩一大半。第二类是产品经理和方案工程师，你们不需要亲手画图，但经常需要出概念图给客户看，用text-to-cad生成一个粗略模型比找设计同事排队快得多。第三类是CAD教学和培训领域的人，后面我会专门说，它在教学场景里的价值可能被严重低估了。

2. 从一句话到几何体：底层工作链路拆解

想用好一个工具，先得知道它怎么工作。text-to-cad的内部链路虽然各家实现不同，但骨架基本一致，可以拆成两个底座加一个输出环节：大语言模型的意图理解、程序化建模的参数映射、最终几何文件的序列化输出。理解这条链路，你就能明白为什么它有时候表现惊艳，有时候又蠢得离谱。

2.1 两个技术底座：LLM的意图理解和程序化建模的参数化

第一块底座是LLM，它负责把自然语言拆成结构化指令。比如你说"法兰盘外径100，内径40，厚度10，均布6个M6螺纹孔"，LLM需要识别出这是一组旋转体特征加一组圆周阵列孔特征，而不是真的把它当成一句话。这个过程有点像一个熟练的制图员在听需求时下意识做"特征分解"：先本体后孔洞，先形状后阵列。LLM表现得像不像一个合格的制图员，直接决定了后续建模的质量。

第二块底座是程序化建模引擎。目前很多实现选择OpenSCAD、CadQuery这类以代码描述几何的库，因为它们的特征是"用函数生成实体"，天然适合让LLM输出成代码。CadQuery的box、cylinder、hole这些命令，本质上就是把CAD的草图-特征流程抽象成了方法调用。LLM生成CadQuery代码，相当于让模型直接写一份"建模程序"，而不是去操纵一个图形界面。这一步非常关键，因为代码本身就是可保存、可重跑、可参数化的，等于每次生成都在创建一个新的"建模脚本"。

2.2 实际输出路径：OpenSCAD、STEP还是DWG？

这一步直接决定你能不能在常用软件里打开结果。目前text-to-cad的典型输出有三种：OpenSCAD源码、STEP文件、STL网格。我的建议是优先选STEP，因为STEP文件存储的是B-rep边界表示，导入Fusion 360、SolidWorks、FreeCAD之后还能保留实体表面和边线，可以继续选面、打孔、倒角。STL只是三角网格，导入后只能当"实心疙瘩"看，改起来很痛苦。

我把三种格式的适用场景整理过一张表，方便你快速决策：

DWG在建筑和二维工程图里还是主流，但text-to-cad目前对DWG的支持普遍偏弱。这也符合当前技术现状：三维参数化建模对"特征"的表达更清晰，而DWG的二维图元（直线、圆弧、多段线）虽然简单，但要让LLM理解"剖视图怎么画""标注放哪层"反而更难。所以你在测试时如果发现文字生成的二维图很怪，不用太惊讶，这是目前的边界。我看到热词里"cad图纸合并""cad标注和图框插件"这些问题被反复搜索，就知道二维出图这块的自动化，还有很长的路要走。

2.3 为什么生成结果能保持"可编辑"而不是一张死网格

这是text-to-cad和单纯文生3D（比如一些AI图片转3D模型）最大的区别。文生3D生成的是网格模型，像雕塑，只能看，不能改；text-to-cad生成的是参数化实体，像积木，每个特征都是一个独立的操作记录。我在测试中把生成的法兰盘导入Fusion 360后，可以直接双击某个倒角特征改半径，改完整个模型自动更新，这种体验已经接近原生特征建模。

这一点也是我判断一个text-to-cad项目是否专业的关键指标：如果输出只有STL，那基本是玩具；如果输出STEP且附带构造历史（feature tree），那才是真正在设计工具链里能用的东西。有人说"能生成就行了，要什么自行车"，但你在实际项目里就会明白，模型后面还有出图、改版、加工对接一连串事，不可编辑的模型等于一次性筷子，用完就得扔。

3. 实测跑通：从提示词到可交付的STEP

理论说完了，上实操。我以自己最近做的一个法兰支架测试为例，完整走一遍从提示词到可交付文件的过程，包括环境准备、命令示例、导入验证。整个过程我记录了很多细节，因为这些东西才是网上的宣传帖不会告诉你的。

3.1 环境准备与模型选择

目前开源的text-to-cad方案里，比较有代表性的是基于CadQuery后端的一类项目。如果你本地跑，建议用Python 3.10以上环境，先装cadquery库，再装一个支持LLM调用的客户端（或直接用在线API）。如果你只是先体验，直接用网页版就行，把输出的STEP文件下载后导入电脑里的CAD软件，这样最快。我的经验是不要在一开始就纠结本地部署，先跑通效果再说，等确认这东西真能进你的工作流，再花时间搭环境也不迟。

本地环境的坑主要集中在cadquery的版本依赖上，特别是与OCC（Open CASCADE）内核绑定较深，Windows上偶尔会遇到DLL加载失败。遇到这种情况，优先看conda环境是不是干净，别用系统自带的Python混装。我见过很多人卡在这一步就放弃了，其实大部分时候只是缺了一个OCCT的运行时库，把conda环境重建一遍就好。

3.2 完整实操示例：描述一个法兰支架

我输入的提示词是这样的："设计一个L形法兰支架，水平底板长120，宽80，厚10，四个角分别开直径8的沉头孔，沉头直径14，深5；竖直板高100，厚8，顶部有一个直径30的圆孔，孔心距离竖直板顶部边缘40。使用铝6061材料。"

输出结果在OpenSCAD预览下能看到清晰的L形轮廓，沉头孔也分了两段：一段大直径浅孔，一段小直径通孔。把STEP导入Fusion 360后，我检查了模型参数树，发现底板拉伸、竖直板拉伸、沉头孔、圆孔都分成了独立特征，没有合并成一张"死形状"，这一点第一步就通过了。

不过尺寸我逐项核了：底板长120、宽80这两个主尺寸准确，但沉头孔的位置我描述的是"四个角"，系统默认按矩形阵列均布，孔心离板边缘的间距是它自己取的，我并没有给具体定位。所以如果你对孔位有严格要求，提示词里必须写出"孔心距边缘10"这样的精确约束，否则就是开盲盒。这是text-to-cad和人工设计最大的差别：人听到"四个角"会默认找合理的边距，模型只会按训练数据里的常见分布猜一个。

3.3 导出与下游软件对接

生成模型之后，我把STEP文件同时导入了Fusion 360和FreeCAD验证兼容性。Fusion 360的导入是直接打开，FreeCAD需要新建文件后再用File-Import菜单，两者都能正确识别实体。下一步我试着在Fusion 360里对底板边线做倒角，操作很顺，说明B-rep数据完整性没问题。

对接DWG场景时，文本转CAD的输出会麻烦一些。我当时把STEP导入后另存为DWG，二维工程图的确能生成，但标注样式、图层、线宽完全要重新设置。这里我的建议是：把text-to-cad当"三维建模器"用，别当"工程图生成器"用，图纸层面的工作还是留给专业CAD软件处理。网上有人问"cad导出图片""cad快速看图"，其实核心痛点都是出图效率，但至少在现阶段，text-to-cad帮不上太多这方面的忙。

4. 生成模型的三个硬伤：尺寸、约束、可编辑性

实测下来，text-to-cad能解决"从无到有"，但离"从有到准"还有明显差距。我给团队做工具选型评估时，不只盯着"它能不能生成模型"，更关注"生成之后我要花多久去修"。下面这三个硬伤，是目前所有同类工具的共性，对标一个CAD工程师的真实使用习惯来看尤其明显。

4.1 尺寸只是"看起来对"：毫米级误差的来源

第一类是尺寸精度问题。大尺寸、整数尺寸通常没问题，比如100、300、M6螺纹孔这类常见数字，模型对得很准。但一旦出现非整数尺寸、配合尺寸、或者有公差含义的尺寸，模型往往会四舍五入或用近似值。我测试过一个滑块导轨安装座，要求孔距46.5，生成结果变成了46.4，虽然只差0.1，但生产上这就是废件。

这里的根源在于，LLM生成程序化建模代码时，尺寸参数是从自然语言解析出来的，如果原文本描述不精确，模型就会用一个"合理的默认值"去填空。这不是bug，是概率模型的天性。所以拿到生成结果后，第一步永远是锁定尺寸全表核查，而不是急着标数出图。我的习惯是把所有关键尺寸列成一张Excel表，生成后一项项勾掉，跟图纸校对一个流程。

4.2 约束和特征的丢失

第二类是约束丢失。参数化建模的灵魂是约束：两个面平行、孔和边线同轴、阵列数量随主尺寸联动。text-to-cad生成的模型，外形正确但内部约束经常是"死"的。比如阵列孔的数量写死了6个，如果你把法兰外径从100改成120，孔的个数不会自动增多，还得手工改。

另外，我遇到过生成草图为"完全定义"但内部用了冗余约束的情况，导入后一改尺寸就报过定义错误。解决办法是导入后先运行软件的"修复草图"或"压缩冗余约束"功能。SolidWorks里有"完全定义草图"工具，Fusion 360在草图环境按D调出尺寸约束，建议逐一检查驱动尺寸。这种问题不会一开始就暴露，往往是你改到第三四个尺寸时才突然崩，非常打击信心。

4.3 如何评价生成质量：一个可参考的维度表

因为"质量评价"这个话题在团队里争论过很久，我整理了一张评价表，现在测试任何text-to-cad输出都按这个表打分，建议你也这样做：

这套表的核心逻辑是"生成模型不是终点，进入工程流程才是终点"。如果只是看看外观，那直接用渲染图就够了，没必要折腾成CAD。而一旦进入工程流程，"cad软件建模质量评价"就不再是抽象概念，它决定了你的模型是能直接下发加工，还是要返工两小时，这两者的成本差距是数量级的。

5. 把提示词当图纸规范写：工程化提问的几条经验

我在测试中发现，决定text-to-cad输出质量的最大变量，不是模型本身，而是提示词。同一个模型，用"做个支架"和"设计一个L形支架，底板120x80x10，底板四角孔径8沉头孔，竖直板高100厚8顶部孔径30"这两种写法，结果完全不是一个量级。所以提示词也是工程文件，值得像写图纸规范一样对待。

5.1 从"描述形状"到"描述加工逻辑"

我踩过最深的坑是把提示词写成"描述外观"。比如你说"一个可爱的圆形法兰"，模型确实能生成一个圆盘，但打孔、倒角全靠猜。正确思路是反过来，像跟加工师傅交代工序一样，先说主特征，再说从属特征，最后说孔洞细节。

一个实用的公式是：主基体（形状+总体尺寸）+ 辅助特征（筋板、凸台、凹槽）+ 孔洞阵列（孔径、孔深、位置约束）+ 表面处理（倒角、圆角、螺纹）。这四段信息齐全，生成结果基本不会跑偏。这本质上对应了特征建模的顺序逻辑，LLM在理解时也更顺畅。你甚至可以理解为，text-to-cad不是在设计软件，而是在"翻译一份迷你工艺流程单"。

5.2 6条高价值提示词模板

下面这6条是我反复测试后觉得能直接用、覆盖大多数场景的模板，你可以根据自己的零件类型替换参数：

1. 板类零件："设计一个矩形底板，长X，宽Y，厚Z，四角开直径为D的通孔，孔心距边E，沿短边中心对称。"
2. 轴类零件："设计一个阶梯轴，总长L，直径依次是D1、D2、D3，每段长度分别L1、L2、L3，两端倒角C1。"
3. 法兰类零件："设计一个法兰盘，外径D_out，内径D_in，厚度T，法兰面上均布N个螺纹孔，螺栓分布圆直径D_bolt。"
4. 支架类零件：前面案例里的L形支架描述就是典型模板，重点是"主基体+辅助特征+孔洞定位"三段式。
5. 壳体类零件："设计一个长方体壳体，外形长L宽W高H，壁厚T，底部内腔深度H1，顶部开口，侧面开一个直径D的圆孔，孔中心距顶面距离X。"
6. 加工说明："所有孔均为通孔，螺纹孔按公制标准M8x1.25，沉头孔沉头直径D1深度H1，下方通孔直径D2。"

我自己用下来，第六类"加工说明"往往是被忽略但极其重要的一块。很多人写提示词只描述几何，不提孔的性质和螺纹标准，结果生成出来的一堆光孔，跟实际需求完全不匹配。把这些话加进去，输出质量会有质的提升。

5.3 迭代式修改：把模型一步步逼近要求

几乎没有一次生成就能完全满意的，但迭代式修改比从头改模型快得多。我的工作流是：第一轮生成"结构草稿"，只检查主尺寸和特征顺序；第二轮用自然语言追加修改，比如"把底板四个角孔改为彼此间距60的矩形阵列，删除顶部凸台"；第三轮把STEP导入CAD后再手工精修。一般两到三轮后，模型就达到可交付状态。

有一点要提醒：修改请求尽量一次只改一个方面。一次说"把孔改大、再加个筋板、顺便倒圆角"，模型容易只完成其中一部分。这跟跟人沟通是反着的——人喜欢一次交代完，模型更适合分步确认。这是我在大量测试里的真实感受：text-to-cad的"听话程度"取决于你一次给它多少信息增量，信息增量越小，它执行得越准。

6. text-to-cad与现有CAD工作流的结合场景

最后聊聊实际落地。工具再好，进不了工作流就是白搭。我自己的判断是，text-to-cad短期内不会改变大型企业的CAD体系，但在三类场景里已经能产生真实收益。

6.1 与python脚本批处理结合的思路

第一类是程序化设计团队。如果你本来就用python批量对CAD进行修改、生成参数化系列零件，text-to-cad可以无缝嵌入这条链路。比如我们做非标设备的系列底座，原来用CadQuery写参数化脚本，现在直接让text-to-cad根据需求文本生成CadQuery代码，再在这个代码基础上调整参数批量跑。网上关于"python批量对cad修改"的搜索热度一直不低，说明这条需求是真实存在的，只是过去入口门槛太高，现在有了自然语言这层壳，普通工程师也能参与进来。

批量生成时要注意，让模型为每个零件都生成独立参数定义，不要写死数字。比如把底板长设为length_plate变量，后面集中修改这个值，才能实现真正意义上的参数驱动系列化。我试过直接把数字写死在代码里的方案，后来改一个系列产品要反反复复替换十几个数字，非常痛苦。如果你的目标不是单件而是系列化，那从一开始就要在提示词里强调"使用变量定义所有关键尺寸"。

6.2 对CAD学习者和设计流程的影响

第二类是学习和教学场景。很多新手最先在网上搜"cad制图初学入门""cad画直线显示2.1616e+什么原因"这类基础操作问题，这些恰恰说明传统CAD的上手成本高在"工具操作"而非"设计思维"。text-to-cad在教育中的价值是让学习者绕过操作壁垒，直接看到"描述-参数-几何"的对应关系，把精力放在设计意图表达上。当然，我也认同入行初期还是要老老实实练手工建模，不然连生成模型的错误都看不出来，更别提修改了。工具只是辅助理解，不能替代基本功。

第三类影响在概念评审阶段。设计评审会之前，用text-to-cad快速生成几个结构草案，比拿手绘草图或纯PPT演示直观得多，生成的STEP文件还能直接发给外协厂询价。这跟CAD热词里"cad软件建模质量评价"讨论的是同一件事：当一个工具能降低建模门槛，质量评价的权重就会上升，而这恰恰是工程师经验价值最集中的地方。我在一次客户方案会上就用三个text-to-cad生成的支架变体做了对比，客户当场就圈定了方向，前后只花了不到一小时，这在以前是不可想象的。

我个人的体会是，text-to-cad这类工具真正厉害的地方，不是"替你做设计"，而是把设计师从重复的建模操作里解放出来，让你有更多时间去处理真正的工程判断。但前提是，你必须拥有足以判断它输出是否正确的CAD功底。工具越强，基础越不能丢。以后我拿到一个新零件需求，会先想想这个问题适不适合甩给text-to-cad，适合的话就让它先打个样，我来做检查和精修；不适合的，该手画还是老老实实手画。这种"人机分工"的意识，可能比任何一项具体技术都更值得你提前培养。