半夜改图这种事干过机械设计的人应该都懂。我印象最深的一次是主管丢过来一句话“把你上次那个支架改成35毫米高侧面再加两个安装孔。”听起来很简单对吧我打开软件改草图、删特征、重新拉伸、补两个孔等把模型改完再导出去二十分钟已经没了。当时我就在想要是能直接把这句话扔给计算机然后它自己把模型给我改好那该多舒服。这个念头现在还真有了一门正式的名字——text-to-cad。所谓的text-to-cad就是把一句自然语言描述比如“一个60乘40乘5毫米的底板四角各有一个半径3毫米的安装孔”直接变成可编辑、可生产、可装配的CAD模型。它跟我们在网上常见的“文字生成3D模型”不一样后面这句话我会专门展开说。这篇文章主要面向三类人搞机械结构和产品设计的人、刚学三维建模还没翻过“参数化”这座山的新手、以及想把这股AI能力接进自己工作流的开发者。我把技术原理、实操流程、提示词写法和踩坑记录都整理出来希望能给你一张可以直接照着走的路线图。1. text-to-cad 到底在解决什么问题1.1 先搞清楚 text-to-3D 和 text-to-CAD 的区别很多人第一次听到text-to-cad脑子里浮现的是那些“输入一段话生成一个3D模型”的AI工具比如文本生成网格模型的那一类。这个理解不算错但如果你真的做工程设计就必须把它们分清楚因为两者输出的东西根本不是一个量级。普通的文本生成3D输出的通常是一个网格模型mesh本质是一堆三角形拼出来的表面。它的优势是形状自由能做“奇形怪状”的雕塑化造型比如一棵树、一只怪兽、一块奇特的石头。但代价也很明显没有参数没有特征树没有约束关系也没有可制造性。你没法像在CAD软件里那样选中一个孔的轴线去调位置也没法改一个尺寸让整个零件跟着变更别说直接拿去走CAM编程或者有限元分析。而text-to-cad输出的是边界表示B-rep模型或者更直白一点它输出的是参数化建模逻辑。在主流实现里模型会自动生成一段CadQuery、build123d或OpenSCAD的代码你用代码去构建实体而不是用神经网络去“捏”一个表面。这段代码本身就是一个完整的建模历史尺寸、约束、布尔运算全都写在里面。你可以打开它像打开一张保留完整的草图一样想改哪里改哪里。我画个简单的表对比一下对比项text-to-3Dtext-to-CAD输出形式三角网格meshB-rep实体、参数化代码可编辑性差只能整体缩放或局部雕刻好特征、尺寸、约束均可改装配配合基本不具备天然支持能参与真实装配制造能力不能直接用于CAM/CAE可输出STEP/STL用于加工典型场景游戏资产、概念外观结构件、机械零件、外壳设计这个区别决定了text-to-cad解决的不是“凭空造形状”而是“让设计意图快速变成可用的工程模型”。1.2 它踩中了哪些痛点做设计的人一天里面很大一部分时间其实不是在设计而是在“操作软件”。我认识不少工程师建模水平不差但大量的重复性劳动比如建标准件、改尺寸系列、做相似结构占掉一大半精力。text-to-cad这类工具最直接的价值就是把这部分时间压缩掉。第一是降低门槛。一个实习生到岗可能练了一个月草图绘制和特征建模还不一定能独立把一个带孔的支架画利索。但如果有一个可靠的text-to-cad工具他最低限度可以先“用嘴说”把模型草稿生成出来再在生成的代码里改参数。这等于把表达设计的语言从“软件操作”换成了“自然语言”天然对新手更友好。第二是加速方案迭代。以前做一个方案的初版模型建模、倒角、挖孔、调整尺寸少说半小时起步。有了这类工具你可以在几分钟里生成三四个方案的粗略模型摆在屏幕上对比再挑一个方向精修。这种“先发散后收敛”的节奏对概念阶段非常有用。第三是模型库的复用。text-to-cad的背后逻辑是代码等于把几何变成了一种可以用搜索引擎和大模型统一处理的东西。未来你完全可以说“把上次那个V3版本的电机支架改一下”它直接从模型库里检索代码再做参数修改这比翻文件夹再改模型要自然得多。2. 主流的实现路线和核心技术拆解2.1 路线一LLM 生成建模脚本目前最成熟、也最容易复现的实现方式是让大语言模型LLM直接生成一段建模代码。整个流程大概是你输入一句描述模型根据语义生成一段CadQuery或OpenSCAD代码然后在本地环境里执行这段代码得到三维实体最后从多个角度渲染出图片用来和你的文字描述做一致性验证。这里有个很关键的选择——为什么大家都选CadQuery或OpenSCAD而不是让模型直接去调FreeCAD或者SolidWorks的API原因很简单CadQuery这套东西是“代码即模型”的典型代表几何操作被封装成了Python方法模型输出什么就是什么执行成功与否马上就能知道而且它的运行环境完全可以在命令行里跑不需要启动任何图形界面。对于大模型来说它输出的文本天生就是代码而CadQuery的语法正好是文本两者无缝衔接。如果从一篇研究性质的实现来看它的核心流程可以概括为检索加生成两步。第一步先把桌面输入的描述向量化从一个预先整理好的“文本-代码”样本库里面检索最相似的几个示例作为小样本喂给大模型参考。第二步让大模型基于参考片段生成完整代码再执行渲染。如果渲染出来的图片和用户意图差距太大就把评估结果作为反馈再迭代一次。这个循环就是很多人说的“agent”本质是让模型的输出可评估、可修正。2.2 路线二直接生成参数化模型另一个方向是绕过代码直接让神经网络生成参数化模型的特征序列。你可以把它理解成让模型自己去“理解”特征树的排列方式先拉伸再切孔再倒角每一步都对应一组参数。这个方向更接近人类建模者的思维但目前还没有完全成熟主要卡在数据上——CAD特征树的标注数据比文本-图片对难收集得多而且一个模型可以有完全不同的特征顺序来表示想要让网络稳定地输出这种结构化的序列难度很大。所以现阶段我个人的判断是代码生成路线会先跑通因为它复用了大语言模型已有的代码能力。而直接生成特征序列的路线要是能把数据问题解决未来的上限可能更高因为它不需要中间层而且天然是参数化的。2.3 关键的“渲染反馈”闭环判断一个text-to-cad系统好不好用不能只看它生成的模型样子对不对还要看它有没有“自我纠错”的机制。业内一个常见的做法是让代码执行后从6个或12个固定的摄像头角度渲染出图像再让一个视觉-语言模型或CLIP之类的模型去评估“这组渲染图是否符合原始描述”。这个过程有点像你让一个实习生画图画完了你拿过来看一眼说“这里不对孔的位置太靠边了”他拿回去改改完再给你看直到你说OK。text-to-cad的agent就是这么干的只不过扮演“审图人”的是一套自动评估机制。这也是为什么这类系统的运行时间往往比较长——它可能要让模型和评估器来回几轮而不是一次性出图。2.4 为什么 B-rep 比网格难这么多凡是做过一点图形学的人都会感慨生成网格可以用扩散模型一股脑把三维体素或者点云画出来但生成B-rep逃不开“拓扑正确”这四个字。所谓拓扑正确就是说一个实体必须是封闭的、无自交的、流形(manifold)的表面不能有裂缝、不能有悬空的边、不能有两个面穿在一起。网格模型在这方面的容忍度很高即使偶尔有瑕疵渲染出来看不太出来游戏引擎也能接受。但CAD模型对拓扑的要求非常苛刻因为下游的CAM加工、有限元网格划分、装配约束全都依赖几何的一致性。一个带洞的实体压根没法加工一个面方向反了的实体导到CAM里刀路计算会直接报错。这就是text-to-cad比“图生3D”困难得多的根本原因它不仅要“长得像”还必须“建得对”。而用代码生成的方式天然可以利用CadQuery执行时的错误信息来把关——代码执行不成功说明几何构造失败系统就换个思路再来。这比直接让神经网络输出一个“看起来对”的网格要稳妥得多。3. 从文本到模型完整实操流程3.1 环境准备如果你打算自己搭一套text-to-cad的流程不需要一上来就追求研究级别的大模型。先用最朴素的“LLM CadQuery”就能跑通关键是体验整个链路。以下是我建议的一套本地环境# 建议使用 Python 3.10 或 3.11 python -m venv cadenv source cadenv/bin/activate pip install cadquery build123d numpy # 如果你想解析和检查STEP文件可以加 pip install trimesh如果只是想快速体验无需自己准备模型可以直接用在线服务。但你如果想深入就要把自己当成一个“提示词工程师”在本地搭好CadQuery的调试环境因为你要反复看生成的代码、执行、看报错、再修改。把CadQuery当成一个解释器来用比在CAD软件里改方便得多。3.2 提示词怎么写才不翻车这是整个实操里最影响成败的部分。我发现很多人用这类工具翻车不是模型不行而是描述太“人类化”了。你跟我说“给我做个支架”我能理解但模型不知道你要什么尺寸、什么形状、孔开在哪里。机器不是读心术必须把关键信息量化。我总结了一个实用的提示词结构五个要素对象类型、整体尺寸、特征动作、位置关系、单位公差。举例说明差的提示词“做一个带孔的板子。”好的提示词“做一个长方形的底板长60毫米宽40毫米厚5毫米在底板的四个角附近距离每条边各5毫米的位置打四个直径6毫米的通孔底板中心再挖一个直径20毫米、深度2毫米的沉孔。”后者看起来啰嗦但正因为信息密度高模型才能输出和你预期一致的参数化代码。如果你不写单位模型默认用毫米居多但你不写它就可能自由发挥如果你不写孔和边的距离它就随机放最后出来一个孔贴着边缘的废件。还有一个小技巧一次性说清楚所有关键尺寸不要指望模型自己“推理”。它不是一个知道你心里在想什么的合作设计师它是一个翻译器把你说的变成代码。你说得越明确它翻译得越准。3.3 实测一个完整例子我拿一个最常见的电机支架来做演示。这是我的输入生成一个L形电机支架底板长80毫米、宽50毫米、厚8毫米立板高60毫米、厚6毫米与底板左端平齐底板上有4个直径5.5毫米的安装孔横向间距40毫米纵向间距30毫米孔中心距板边10毫米立板中央有一个直径20毫米的通孔。一个好的系统应该能输出类似这样的CadQuery代码import cadquery as cq # 底板 base cq.Workplane(XY).box(80, 50, 8) # 立板 upright cq.Workplane(XY).workplane(offset-29).moveTo(-34, 0).box(6, 50, 60) # 合并 part base.union(upright) # 底板安装孔 part part.faces(Z).workplane() \ .pushPoints([(-20, -15), (20, -15), (-20, 15), (20, 15)]) \ .hole(5.5) # 立板轴孔 part part.faces(X).workplane().workplane(offset0).center(-6, 0).hole(20) show_object(part)注意这段代码里的坐标值不是凭空来的。底板长80四个孔的横向间距40意味着孔左右各距中心20纵向间距30意味着前后各距中心15。立板要“与底板左端平齐”所以X方向就要偏移到底板左端边缘这些都是从文字描述中解析出来的约束。你看到代码的瞬间就能判断系统是否真正“理解”了你说的相对位置关系而不是瞎编一个数字。3.4 拿到生成代码后怎么改这里想强调一个观念text-to-cad的价值不只是那一个模型而是那一段模型生成的逻辑。你拿到代码之后完全可以用传统参数化设计的思路去修改。比如想把手板厚度从6毫米改成8毫米不用重新生成直接在代码里把upright那行的厚度参数改一下重新执行就行。我一般把生成代码当成“设计草稿源文件”会在本地建一个模板库把经常用到的结构片段存下来。下次遇到类似的支架、底板、法兰盘直接把模板拿过来改参数。这比重新让模型生成一遍更可控因为你清楚这段代码之前的验证结果改出来的新模型大概率是可靠的。4. 工具选型解析4.1 现在能用的几种选择text-to-cad这个概念还不算大众但可用的东西已经分出了好几个层次。第一类是研究原型比如一些高校公开的“text-to-cad”开源项目。它们往往是最能展示完整技术链路的检索、生成、渲染评估、迭代优化整套代码和数据集都公开。适合想研究技术细节、或想二次开发的人。第二类是商业化的在线工具比如某些初创公司推出的“Text-to-CAD”网页应用。它们的优势是把整个推理链路打包成了服务不需要本地配环境输入描述就能出结果很多还支持直接导出STEP格式。对设计师来说这是最省事的选择但代价是代码不可见、不可控而且按次计费不适合大规模复用。第三类是“LLM 插件”的野路子。你可以把一个支持API的大模型接进CAD软件的脚本环境里让它按固定模板生成Python脚本再执行。这种方式的定制性最强但需要自己编写中间逻辑比如如何把模型输出的代码喂给CAD内核、如何处理报错。适合有开发能力的团队拿来和现有设计流程深度绑定。4.2 一张表说清各自定位工具类别典型特点上手门槛适合场景开源研究原形全链路透明、可改可扩展较高需要配Python环境技术研究、二次开发商业在线服务用了即走、界面友好低无需配置环境概念快速验证、单件草稿LLM插件自建与设计流程深度集成高需要写胶水代码团队内部工具、自动化设计4.3 我的选型建议坦白讲我自己的习惯是“混着用”。做概念验证的时候我用在线服务因为它快不要动脑配置环境等确认方向可行进入详细设计阶段我会把关键约束拿出来回到本地用开源方案生成模板代码再由工程师手工精修参数。如果你是个初学者我建议先从在线服务开始体验一下“输入文字变成模型”的感觉。但别停留在玩一玩——你应该把生成的模型输出成STEP丢进一个支持参数化检查的软件里看看它的可编辑性到底强不强。这样你对这类工具的能力边界会有一个非常实际的认识。5. 常见问题与排查技巧实录5.1 高频翻车现场和应对我实测的过程中经常遇到的问题是那么几类我整理成一张速查表你可以直接对照问题现象常见原因解决办法生成的模型形状离谱和文字描述毫无关系提示词太笼统缺少尺寸和位置约束按“对象-尺寸-特征-位置”的结构重写脚本执行直接报错生成失败模型调用了不存在的CadQuery方法或参数类型不对提供给模型一个已有的正确代码示例作为参考模型看起来对但导出STEP后在CAM里算不出刀路存在薄面、退化面或微小的几何裂隙用几何检查工具跑一遍再回模型修参数所有孔的位置都一样没有按描述分布坐标推导逻辑错误常见于模型对“相对位置”理解偏差把孔距和边距用绝对坐标明确写出来生成速度慢到没法用agent循环反复评估修正可能迭代了多轮减少不必要的渲染评估轮次上限或在提示词里固定细节5.2 几何合法性校验做工程设计的人最怕的不是模型丑而是模型“看着对、实际不能用”。所以拿到任何生成模型之后都应该做一个几何合法性检查。在开源层面可以用trimesh或者manifold这类库检测网格的流形性和封闭性。如果是B-rep模型导出STEP之后用CAD软件自带的“检查”或“修复”工具跑一遍确认没有坏面、反转法向、零厚度等问题。我自己踩过一次很深的坑一个看起来完美无缺的钣金件导出STEP后下料机直接报警说轮廓有自相交。我查了半天发现是生成代码里的一个圆角特征和相邻平面碰撞出的结果。这类问题在生成阶段很难肉眼看出只有当你把它当成真零件去加工时才会暴露。所以所有AI生成的模型都要当作“未审图的外协件”对待严格检查后再进入下一环节。5.3 质量评估怎么做如果你想评估一个text-to-cad系统到底好不好不能只看它生成的图漂不漂亮要有量化手段。常用的做法包括把生成模型和CAD软件里的真实模型渲染成多角度图像用IoU或CLIP相似度对比检查生成代码能否稳定执行成功统计产生无效实体的比例以及最重要的人为评审——找个工程师打开模型看特征树看它是否真的符合设计意图。我看到很多评测文章只拿“像不像”说事这其实是外行视角。真正的评测标准应该是代码可读性如何、参数化改尺寸是否顺利、能否直接进入装配或CAM流程。这些才是工程意义上的质量标准。6. 实践心得与下一步玩法6.1 把模型当“草稿”把代码当“资产”用了一段时间之后我对这类工具的定位有了一个转变它最值钱的不是每次生成的那个几何体而是那些被验证过的代码片段。因为几何体是一锤子买卖的消耗品而代码是可以反复编辑、组合、复用的资产。我现在会把每个常用零件都整理成一个带注释的CadQuery脚本放进公司内部的代码库里。下次有人要类似的零件我直接改参数十分钟出图这比让AI从头生成要可靠得多。6.2 局限与边界我也要说清楚它的边界免得你把期望值抬得过高。目前的text-to-cad还不擅长处理大型装配关系、复杂曲面比如流线型外壳、或者对公差和粗糙度有明确要求的精密零件。它更像一个“想法孵化器”负责把文字描述快速发酵成有形态的草稿而不是取代工程师做详细设计。对于需要严谨配合的机械结构我依然会在AI生成的模型之上做大量的约束和校验工作。这不代表这类工具没用而是说它应该被放在设计流程的最前端用来抢占“从无到有”的前半小时。6.3 后续扩展思路如果往后想做深有几个方向值得关注。一是把text-to-cad和参数化模型库结合起来做成“用说话就能调取设计规范”的接口二是引入用户反馈让系统记住哪些方案在工程上是可用的形成一个面向团队经验的数据闭环三是把生成结果直接接进CAE仿真让“描述-建模-仿真”整条链路在几分钟内跑完。这几条路现在还都处于早期但每一条都有实际价值。最后再分享一个小技巧。我实际用下来发现把提示词写成一个“设计任务单”的方式最有效就是把你要的东西逐条列清楚像给外协厂商发询价单一样。让系统直接“读单”干活比我随手打几个词得到的结果稳定得多。这个习惯你一旦养成了就会发现不管是生成支架还是法兰盘成图率都会高出一截。说到底text-to-cad现在还只是把“说草图”这个能力教给了机器而我们工程师真正值钱的从来都是知道该“说什么、说清楚什么”的那部分眼光。