开头一段时间我在做结构件和3D打印件时经常遇到一个很磨人的环节脑子里明明已经有了很清楚的造型但落到软件里要么是反复拉草图、加约束要么是在一堆面板里找命令。后来我开始尝试“text-to-cad”这个方向——直接把需求描述成一句话让语言模型理解后帮你生成对应的参数化CAD脚本或模型文件。这个思路听起来很科幻但实际已经有不少可落地的路径今天这篇就把我折腾了大半年的经验整理出来。先说清楚text-to-cad到底解决什么问题。它的核心目标不是“用文字生成一张好看的图”而是“用文字生成可以直接进工程流程的三维CAD实体”不但要求形状对还要求尺寸、约束、位置关系基本能用。也就是说它服务的对象更像机械设计、产品原型、3D打印、结构仿真这一类偏制造侧的场景。适合谁如果你会一点点编程或者愿意接受“文字描述脚本化建模”的工作方式那它可以帮你大幅压缩从想法到第一版模型的时间。如果完全没接触过CAD也能用它快速感受建模逻辑但要做好前期参数反复调整的心理准备。1. text-to-cad 到底是什么把一句话变成三维实体的原理拆解1.1 从自然语言到几何模型中间发生了什么text-to-cad的输入是自然语言输出是CAD能识别的几何数据。但语言和几何之间不是直接映射关系中间通常要经过一层“程序化描述”。我打个比方你让一个师傅做一张桌子他不会直接从嘴里蹦出桌子而是先在脑子里把桌子分解成“面板、四条腿、连接方式、尺寸、公差”然后按这个方案动手。text-to-cad也一样系统需要先把一句话拆分成至少四个维度的信息零件类型、整体尺寸、特征细节、约束关系。比如“一个40x40x20的铝制支架四角各有一个M3通孔底面有沉台”这句话里包含了基础体尺寸、材料、孔的类型和位置、孔的加工特征。要让CAD真正生成实体必须把这些信息转化为几何操作先拉伸出一个长方体再在四个位置做圆柱体最后做布尔减运算。这个过程如果人工在软件里做是几分钟的事而text-to-cad要做的就是自动把这套几何操作序列“翻译”出来。当前主流实现路径有两个大方向。一个方向是让语言模型直接生成参数化建模脚本比如CadQuery、OpenSCAD、FreeCAD Python API这样的代码。另一个方向是用生成模型直接从文本预测三维数据比如体素、点云或网格再把网格转换成CAD实体。前者的可控性更强因为脚本能带精确尺寸后者的形态自由度更大但工程精度常常不够。我目前的实践里正式做零件几乎都用第一种第二种更多用在概念造型和快速预览上。1.2 为什么语言模型能“听懂得”CAD的需求这里最关键的原因是CAD建模中的大量规则和工程常识在互联网上有海量文本语料语言模型在预训练阶段已经吸收了不少。比如“通孔”、“盲孔”、“沉头”、“倒角”、“公差配合”这些术语模型能通过上下文理解它们各自的含义再结合生成代码的能力把语义落到具体的几何命令上。但不要高估它的“理解”它本质上是概率化地组合知识。如果需求描述里有歧义比如只说“开几个孔”而不说位置、孔径、深度模型大概率会自己发挥而且发挥结果不一定符合你的加工预期。所以我一直建议和text-to-cad打交道相当于跟一个懂很多术语但刚入行的实习生沟通你给的信息越完整它是错越小。一个可以解释的现象是开源社区里很多效果不错的text-to-cad案例并不是靠一个超级大模型单独完成的而是“语言模型脚本模板约束校验”的配合。语言模型负责提取参数、生成主体脚本模板负责保证建模思路正确校验环节负责检查实体有没有破面、尺寸有没有越界。这也是我后面工作流里反复强调“不要裸用模型”的原因。2. 手把手搭一个 text-to-cad 工作流主流方案与工具选型2.1 现在有哪些路径可以走工具和路径的选择直接决定了你能得到“能看看的模型”还是“能加工的模型”。我把目前市面上比较常见的方案分成了四类整理成表格方便大家按自己的底子去选。方案建模方式典型输出适合场景上手门槛LLM生成CadQuery代码程序化参数建模STEP、STL机械件、规则几何件中等需要理解脚本逻辑LLM生成OpenSCAD代码声明式建模STL、DXF参数化原型快速迭代低语法简单直观LLM生成FreeCAD宏API操作建模FCStd、STEP已有FreeCAD流程的人中等需要了解FreeCAD对象模型Text-to-3D生成后转CAD生成网格再转换GLB、OBJ→STEP概念造型、快速评审低但转完多需要重建单看表格可能觉得第一条最有吸引力但在实际项目中我从不只押一个方案。理由也很简单每个方案都有“擅长区”和“盲区”比如CadQuery擅长精确控制尺寸和特征但让非程序员看代码会非常吃力OpenSCAD学起来快但复杂曲面能力很弱Text-to-3D生成出来的模型形状丰富但十有八九是网格网格转STEP后经常出现破面和非流形边根本进不了CAM流程。如果只做3D打印原型那STL和OBJ也够用如果后面要出工程图、做CNC或注塑STEP格式几乎是必须的。这也是我在工具选型时第一个要确认的问题最终交付给谁看是给切片软件看还是给加工师傅看这个决定直接决定模型走哪条路。2.2 我的选型逻辑和环境准备我自己的主力组合是“大语言模型生成CadQuery脚本 本地脚本库做约束验证”因为CadQuery生成的实体可以导出带精确几何数据的STEP这是后续做装配和仿真最省事的格式。环境准备也不复杂装好Python再装CadQuery库几行命令就能跑起来。需要说明的是不同大语言模型对CadQuery语法的掌握程度有差异类别、参数名偶尔会编造所以我的环境里会特意保留一份本地的CadQuery API手册快照遇到报错时先别急着改自然语言描述而是让模型把参数和CadQuery文档再对齐一次。另外如果尝试OpenSCAD方案环境更轻它本身是一种声明式语言可以用一段文字描述整个实体结构。它的优点是模型能很容易“看懂”并生成“接近可行”的代码缺点是复杂倒角、圆角和曲面形体会绕很多弯路。所以我会把OpenSCAD定位成“快速验证方案”一旦确定方向再迁移到CadQuery做精细化。所有方案都建议在同一个项目目录里统一管理三个东西模型输出的原始脚本、导出后的STEP文件、一份记录每次修改内容的文本说明。因为text-to-cad的迭代成本虽然低但修改记录如果不留好很容易出现“上一版能用的脚本被改坏了却找不到备份”的尴尬。3. 从一句需求到STEP文件一次完整实操解析3.1 把一句话需求拆成可执行指令纸上谈兵再多不如跑一个完整例子。我挑一个比较典型的件——一个带四个安装孔的L形支架这也是我在实际项目里做过很多次的类型。最初的描述往往是“做一个L形支架有安装孔”但这句话直接丢给模型出来效果通常很随意。后来我说“生成一个L形支架两翼尺寸分别为60x40x6和40x40x6安装孔径5mm分布在每个翼的居中位置孔距边缘10mm”效果立刻稳定了不少。这里有一个关键认知text-to-cad不是“一句话生成一切”而是“一段结构化描述生成可控结果”。我总结了一个拆分模板每次写需求都按这个来基础体整体形状、长宽高或直径厚度。特征孔、槽、圆角、倒角等注明类型和关键尺寸。位置约束孔距边缘多少、槽在哪个面、对称关系等。工程意图是通孔还是盲孔、精度要求、配合关系。输出要求CAD格式、是否需要参数化变量、是否要便于后期改尺寸。如果你觉得这样写太繁琐也可以反过来用先给模型一个简短的描述然后让它“提出三个澄清问题”。这个办法很有效因为模型会站在几何角度问出“孔径多大”“深度多少”“单侧还是双侧”这类业内人士会关心的问题。你回答完之后再让它生成完整脚本成功率会高很多。3.2 生成、校验、导出的三次循环实际生成过程不是一步到位的。我通常会分三步走第一步让模型给出CadQuery脚本第二步在Python里执行并检查报错第三步把生成的形状渲染或导出STEP用CAD软件打开确认。第一步要注意给模型指定“只生成代码不要解释”固然效率高但一旦代码错了缺少上下文解释反而不利于修正。我更喜欢让它在关键位置加注释尤其是说明“这里做了什么特征”“为什么这样给尺寸”。这些注释在你后期改模型时价值极高。第二步执行脚本时最常遇到的两类报错一类是CadQuery API使用错误比如把Box写成了box、Workplane方法名记错这类很好修另一类是几何逻辑错误比如先做了圆角再加孔导致孔的位置被改变这类报错不会立刻显现但会在导出后呈现为尺寸不对、特征丢失。我的经验是让模型给几何操作排好序先做布尔运算再做过渡特征能避免大量坑。第三步校验我强烈建议把STEP模型导入到任意一个能看实体的软件里旋转检查几个角度而不是只盯着代码或渲染图。看一眼实体是否破面、孔有没有贯穿、壁厚是否符合预期这些经验性的判断语言模型很难替你做。到这一步没发现问题基本就可以送3D打印或下料加工了。3.3 参数设计让模型返回“能改的”而不是“写死的”我在实际中发现text-to-cad最有价值的使用方式是让它生成“参数化模型”而不是一次性结果。什么叫参数化就是你定义好变量比如plate_width 60后续所有几何都引用这个变量。以后要改成70mm只改一处整个模型自动变化。这也是CadQuery这类脚本化建模比纯手动建模更适合搭配大语言模型的原因。你不仅拿到一个零件还拿到一个“可以反复修改的建模逻辑”。我通常会在需求里额外加一句“把主要尺寸定义为参数放在文件顶部并添加注释说明取值范围。”模型很吃这一套生成的代码结构会清晰很多。参数化工作的另一个好处是可以把一段生成脚本变成“自己的零件库”。比如支架、轴承座、端盖这类高频小件一次生成后就保留下来后续改改参数又是一版新件效率和一致性都远高于每次从头画。这一点对我这种经常要出方案的工程师来说省下的是实实在在的半天时间。4. 现实很骨感text-to-cad常见问题与排错心得4.1 高发问题速查表用text-to-cad的时间越长越发现它的问题不是“不知道”而是“以为自己知道”。我把这几个月遇到的高频问题整理成了一张表方便大家遇到类似情况时先按图索骥。症状常见原因处理办法模型生成了但孔位置明显偏移描述中缺少位置约束词补上“居中”“距边缘xx”“对称”等关键词导出STEP后破面网格转换或多实体未合并在CadQuery中使用union或检查combine逻辑尺寸单位错误描述中没写单位模型默认了另一种单位明确声明“单位毫米”或“单位英寸”圆角/倒角丢失操作顺序不对先倒了角又加了特征调整生成顺序为先主体、后开孔、最后过渡特征代码语法有误模型对API记忆不准确让它对照API手册重写或换用更成熟模型的版本生成的形状不符合工程可制造性出现了倒扣、过薄壁厚等增加“考虑铣削/注塑加工可行性”的约束描述这里表格里我特别想强调“倒扣”和“壁厚”这两个词。因为大语言模型生成形状时考虑的是“几何完整性”而不是“能不能从模具里脱出来”或“刀具能不能走进去”。有一个很典型的例子我让模型生成一个带内扣卡槽的壳件它确实把卡槽画出来了但卡槽位置导致模具根本无法脱模形状对工艺错。解决方法是在描述里主动加入制造工艺约束比如“请考虑CNC刀具可达到性”或者“壁厚不小于2mm”。4.2 为什么不能迷信模型生成的“第一个成功结果”很多人第一次跑通text-to-cad时会特别激动因为一次就生成了看起来完全正确的零件甚至渲染图都很漂亮。我得说句泼冷水的话你大概率没检查完。渲染图好看不代表几何正确STEP里一个隐藏的微小平滑面、一个重合面都可能在下游仿真或CAM里引发一堆问题。我自己踩过最大的坑是生成一个带多个阵列孔的法兰盘模型脚本一次通过渲染看起来孔位均匀我对了四个角点孔。但真正拿去加工时发现中间有一圈孔的圆周分布是均分的但圆心角基准方向偏了5度导致整体装配对不上。原因在于我描述时只说了“均布6个孔”没有说“第一个孔位于0度方向”模型就随机选了起始角度。从那以后我的所有文本需求里都会写“基准方向”“起始位置”“旋转方向”哪怕我觉得人眼看起来显然的默认值也坚持写出来。另一个容易被忽略的问题是“实体数量”。有时候模型会生成两个互相交叠但未合并的实体在视觉上看起来像一个零件导出STL时切片软件也能勉强处理。但在CAD装配或CAM编程里这种非流形几何就是灾难。生成完成后建议先用代码检查一下solids()的返回数量如果大于1就要留意是不是该合并而不是直接导出。最后分享一个排查技巧如果模型的某个尺寸总是和你预期不一致别急着反复改提示词。先把它的生成代码拿出来在注释里找到它计算尺寸的位置看看是不是它“自己理解”了一个计算逻辑。比如你说“开一个槽长度等于底板长度减去边缘间隙”模型可能为了确保边界自动给槽长多加了一个间隙值导致槽实际到了边缘。这种逻辑性偏差只有看代码才能发现。多养成“代码优先”的习惯很多问题都能在几秒内定位。4.3 别忽略后期修改的可维护性还有一点特别想提醒不要只把text-to-cad当成“一次性出图工具”把它当成“建模过程管理工具”。当你第二次、第三次修改同一个零件时如果原始脚本没有良好结构几版之后就会变成一坨谁都看不懂的乱代码。我在实际中会在第一次生成后要求模型给脚本做一次重构把尺寸参数集中到顶部、把每个特征的代码用函数封装、给每个函数写清楚输入输出。这个“重构请求”只需要多花两分钟但后续改图、复用省下来的时间是十倍的。另外输出格式的选择也是一个大坑。有时候你只是想快速做个视觉确认却导出STEP再导入折腾好几步有时候要交付STEP却只导出了STL格式不对被加工方退回。我的原则是视觉确认用渲染快照内部迭代用原生脚本正式交付用STEP切片打印用STL。不同流程对应不同格式别一锅炖。5. 我的使用体会text-to-cad现在最适合干什么5.1 适合的场景和不适合的场景用了这么长时间我对text-to-cad有了很明确的能力边界判断。它最适合的是“规则几何、重复特征、参数可变”的系列化零件比如各种支架、壳体、法兰、安装板、轴承座。这类零件可以用文字把结构和尺寸描述清楚模型生成脚本后结果稳定、可复用、易改参数效率是肉眼可见的提升。它还不适合用来做高度自由的消费级产品外观设计。那种需要曲面连续、渐变过渡、形态跟随语义的造型Current的生成结果更像“泥塑”而不是“加工模型”。当然市面上已经有直接从文本生成高质量网格的工具但这类网格转成CAD实体后常常要花大量时间重建对严谨工程场景来说反而是负优化。所以我的建议是做功能件和生产件就坚定走“脚本化CAD生成”做前期形态探索可以分开用网格生成工具等形态定稿后再进入CAD重做。如果你是在团队协作环境里用text-to-cad我建议把生成脚本和输出文件都纳入现有的版本管理流程。因为语言模型每次生成结果都有随机性即使同一个提示词两次输出也可能有细微差别。没有版本记录很难定位是哪一次修改引入了问题。这听起来像软件开发习惯但在AI辅助设计里它就是实用方法论。5.2 如何把text-to-cad变成自己的提效杠杆根据我的个人经验把text-to-cad用好的关键不在于“堆更多提示词”而在于“建设可复用的模板库”。我会把高频零件的需求模板整理成固定文本格式例如支架类、箱体类、轴座类每种模板都预留参数空位。用时填数字生成速度极快。这等于把自己的设计经验固化进了文本模板里模型生成只是把文本变成代码的最后一个环节。同时我也会把模型输出的高质量CadQuery脚本分门别类归档定期整理成“可复用零件脚本库”。这个脚本库的价值不在于脚本本身而在于每一个脚本都经过了一次或多次真实加工验证。下次遇到类似零件先查库再改参数不用从头让模型生成出错概率大幅下降。踩过几次坑之后我现在对text-to-cad的态度是“大胆用但永远留一手校验”。大胆用是指只要零件形状能描述清楚我就敢让它先出第一版省下的建模时间用来做更关键的评审和验证留一手是指从不跳过实体检查、从不忽略代码审查、从不省掉格式确认。工具能替我做重复劳动但不能替我做工程判断这两者边界越清晰效率就越高。最后再分享一个小技巧如果你刚接触text-to-cad不要一上来就挑战复杂装配体先拿一个简单的板类零件练手走通“描述-生成-执行-检查-导出”的完整链路你会比直接上手复杂件少踩很多坑。等这套链路形成了肌肉记忆再慢慢加特征、加约束、加工艺要求逐步把文本生成的复杂度往上顶。整个过程不神秘就是一次次“发需求、看结果、找问题、改描述”的循环跑得多了你就知道哪类描述对模型友好、哪类词它容易忽略到那时候你才算真正驾驭了它。