text-to-cad把一句人话变成能拿去加工的三维模型这几年做3D打印和机械设计的朋友应该都有一个共同的痛点建模门槛是真的高。CAD软件动辄几十个按钮草图、约束、特征树、装配体每一项都是学习成本。而另一拨人比如写代码的工程师、做产品的非机械专业同学脑子里有很清楚的结构想法嘴里能说出来手上却画不出来。所谓text-to-cad就是把这个“想法到模型”的过程从鼠标点击、命令输入简化成一句自然语言。你说“一个长100毫米、宽80毫米、厚5毫米的底板四个角打沉头孔中间开一个矩形槽”它直接给你生成一个可编辑、可导出、可拿去CNC或者3D打印的CAD文件。这篇文章我打算把text-to-cad的核心原理、主流实现路线、最小可落地的操作流程以及我自己实测中踩过的坑全部拆开讲一遍。无论你是刚接触CAD的新手还是想把这套能力接进自己工作流的工程师都可以从里面找到能直接“抄作业”的东西。1. text-to-cad到底在解决什么问题1.1 传统建模方式的高门槛和表达断层先别急着聊AI我们得先搞清楚CAD建模本身卡住了多少人。传统的参数化建模比如SolidWorks、FreeCAD、Fusion 360本质上是在干一件事把设计师脑子里的几何意图转换成计算机能理解的特征操作序列。这个过程需要你熟练使用草图平面、约束关系、拉伸旋转、倒角打孔等一整套工具链。一个简单的零件新手可能要折腾一晚上而老手也要反复看图纸、量尺寸。更麻烦的是很多人并不具备“把想法翻译成几何操作”的能力却具备“把想法翻译成文字”的能力。比如一个做硬件的创客想做一个树莓派外壳他心里清楚板子多大、接口在哪个方向、开孔位置在哪但你让他去画草图他可能连“同心约束”是什么都要先搜一下。这就是表达断层想法是自然语言CAD操作是结构化命令中间缺一个翻译层。text-to-cad的价值恰恰就是把这一层翻译交给了模型。它做得好的地方不是取代设计师而是把“用专业工具表达”的成本降下来让更多人可以直接用母语去描述几何。1.2 为什么偏偏是现在这件事能成其实“自然语言生成三维模型”这个概念并不新鲜图形学里做文本到网格生成已经好多年了。但之前的路线大多是朝着“生成类似图像的表面形状”去走生成出来的东西像雕塑好看但不精确。对于一个需要装配、需要公差、需要开孔位置的机械零件来说那种“雕塑模型”完全不能用。真正的转折点是发现CAD模型本质上不是像素密集的图像而是一段带严格语法的程序化指令。一个法兰盘可以写成“圆柱体加六个阵列孔再减去中心通孔”这种描述天然贴近自然语言的结构。而大语言模型最擅长的恰恰就是从自然语言到结构化代码的映射。换句话说text-to-cad不是自己发明了一条路而是顺着LLM的代码生成能力把原本被忽视的“CAD脚本程序化建模”重新抬上了桌面。再加上近几年程序化建模的生态越来越成熟OpenSCAD、CadQuery、FreeCAD的Python API都是纯代码建模工具LLM可以直接生成这些代码然后在本地渲染成模型。这让整个流程的落地成本大幅下降也让text-to-cad从学术玩具变成了工程师可用的工具。2. 技术路线拆解文本到底怎么变成实体模型2.1 路线一让大模型直接写CAD脚本目前最主流、也最容易自己动手复现的路线是让LLM生成一门CAD描述语言或一个程序化建模库的代码。常见的目标语言有三种。第一种是OpenSCAD一种声明式CSG建模语言。它语法简单入门成本极低一个立方体加一个圆柱体再做个差集几行代码就完事。LLM很容易学会它的语法因为它足够小、足够规整。第二种是CadQuery一个基于Python的建模库。它更接近工程师的习惯支持基于面、边、顶点的操作能做圆角、倒角、抽壳等操作。LLM生成CadQuery代码的成功率比OpenSCAD稍低但胜在生成的模型精度和可编辑性好。第三种是FreeCAD的Python API或者一些商用软件自带的脚本接口。这类接口比较底层函数命名复杂LLM经常写错建议不用作为首选。以我自己的实测来看如果不是做复杂机械结构只是做外壳、支架、底板、法兰这类常见零件OpenSCAD和CadQuery已经覆盖了绝大多数需求。而且这两者都能导出STL、STEP等通用格式后续接到切片软件或者CAM软件都很方便。这里有一个特别重要的认识LLM生成的是“建模过程的代码”而不是直接生成“三角形网格”。这个选择的差异极大。如果直接生成网格Mesh你会得到一堆顶点和面片。它看着像模型但没法参数化修改想改一个孔的位置得重新跑一遍生成过程而且孔还是歪的。程序化代码则完全不同代码就是模型的定义修改一个变量整个模型联动变化。这也是为什么text-to-cad必须走程序化建模路线的根本原因它保证了生成结果的可编辑性和可推导性。2.2 路线二生成特征树结构与构造历史比直接生成代码更高级的做法是让模型输出一个CAD特征树Feature Tree比如“先拉伸一个长方形再在顶面草绘一个圆创建切除特征再阵列三份”然后由一个专门的解析器把这些特征翻译成标准CAD操作。这条路线更贴近传统CAD软件的底层逻辑生成结果也能无缝导入SolidWorks、FreeCAD这些软件中继续编辑。但它的工程难度更大你需要准备大量带有完整特征树标注的训练数据而且解析器对非法特征序列的纠错能力有限。目前这条路线大多停留在学术研究和小范围demo对普通用户来说还是“生成代码”路线更成熟、更好上手。不过我建议关注这个方向因为一旦特征树的生成和解析稳定下来text-to-cad就不再是“玩代码”而是真正能替代传统交互式建模的设计入口。2.3 训练数据的构成文本描述和CAD命令序列的配对无论是走哪条路线数据都是最关键的环节。要让LLM学会“文本到CAD命令”的映射光靠通用代码数据是不够的。好在CAD脚本本身就是代码而代码注释和文档又提供了大量自然语言描述这给训练数据构建提供了捷径。比如OpenSCAD社区有海量的用户库每个库文件顶上通常有一行注释“某个参数化可调轴承座”之类。学术界也做了一些公开数据集比如Text2CAD这类工作核心思路就是收集大量带文本描述的CAD模型再按“从新手到专家”的多个抽象层级把同一个模型拆成不同详略程度的自然语言描述让模型学会在同一模型的不同描述下都能生成正确的命令序列。值得注意的训练技巧是越是细粒度的描述越能约束模型生成正确的结果。比如“一个板子”和“一个长100宽80厚5、四角带M3沉头孔、底面挖槽的板子”前者能生成一堆“看起来像板子”的变体后者才能锁定成一个准确零件。所以在工程使用中我们会通过提示词设计把描述从模糊推向具体以换取生成稳定性。2.4 推理方式零样本、微调与多轮自纠错实操层面文本到CAD的推理方式有三种对应不同使用场景。零样本推理就是直接把任务交给通用LLM比如让GPT-4或者本地开源模型生成OpenSCAD代码。优点是省事不需要任何训练资源缺点是复杂模型的生成成功率低。对于零件级、工具级、外壳级的东西零样本已经够用。微调专用模型是在大量CAD脚本语料上继续训练一个开源模型比如DeepSeek-Coder、CodeLlama、Qwen-Coder这类代码模型。微调之后模型对CAD词汇、命令习惯、常见结构的把握会明显更准。缺点是微调需要一定算力和数据准备适合有比较大迭代需求的团队。多轮自纠错是一种工程技巧并不需要重新训练。做法是让LLM先生成一段CAD代码然后调用渲染器编译把报错信息或者渲染截图再喂给模型让它自我修正。实测下来这个模式能把成功率从五成拉到八成以上。我个人认为现阶段最务实的组合是微调或通用模型做初稿加上一轮到两轮自纠错循环最后人工做参数确认。3. 从零搭一个text-to-cad最小可用流程3.1 工具选型和环境准备我不推荐一上来就去搭复杂的训练环境先把手动流程跑通最重要。你需要准备的东西最少四件。第一一个大语言模型。可以是商用API也可以是本地模型。本地模型推荐7B或者14B级别的代码微调模型显存8G以上就能跑。如果是API记得在系统提示词里明确要求“只输出OpenSCAD代码不要解释”。第二OpenSCAD软件本体。它自带命令行渲染能力这是整个流程的自动化的关键。安装后打开命令行输入“openscad -o output.stl input.scad”即可导出模型。第三一个STL查看器。Windows上可以用3D BuildermacOS上用Preview或者全平台用MeshLab。这块其实不挑能转视角看模型就行。第四一段你自己用的提示词模板这个我下面会展开。3.2 实测示例从中文描述到一个能用的底板模型我拿一个真实需求来做演示一个树莓派外壳的底板我要的是“长100毫米宽80毫米厚5毫米四个角开直径3.2毫米的通孔孔中心距边沿8毫米底面挖一个60毫米乘40毫米、深2毫米的浅槽用来放电路板”。这条描述里所有尺寸都是明确的我们直接把它交给LLM附加一句“请用OpenSCAD代码实现”。LLM返回的代码大致如下// 外壳底板 // 参数化定义 length 100; width 80; thickness 5; hole_d 3.2; edge 8; slot_l 60; slot_w 40; slot_depth 2; difference() { // 底板主体 cube([length, width, thickness], centerfalse); // 四个角安装孔 translate([edge, edge, -1]) cylinder(dhole_d, hthickness2, $fn32); translate([length-edge, edge, -1]) cylinder(dhole_d, hthickness2, $fn32); translate([edge, width-edge, -1]) cylinder(dhole_d, hthickness2, $fn32); translate([length-edge, width-edge, -1]) cylinder(dhole_d, hthickness2, $fn32); // 底部浅槽 translate([(length-slot_l)/2, (width-slot_w)/2, -slot_depth0.01]) cube([slot_l, slot_w, slot_depth]); }这段代码生成一个带通孔和底部浅槽的板子。从生成到验证你需要做的命令只有一句openscad -o base_plate.stl base_plate.scad再用查看器打开STL确认尺寸没问题就可以直接扔进切片软件了。整个过程不到十分钟而同样的零件用传统方式建模光是把四个孔阵列对齐、把浅槽深度算明白就得花上二十分钟到半小时。3.3 提高生成成功率的提示词模板很多人用text-to-cad生成的代码跑不通问题往往不在模型而在提示词写得太随意。我自己用下来比较稳的模板包含五个固定模块角色指令、建模语言、参数列表、约束条件、输出格式。你可以直接拿下面这段去改你是一个OpenSCAD建模专家。请根据用户的自然语言描述生成完整的OpenSCAD代码。 要求 1. 所有尺寸必须以毫米为单位且使用变量定义不允许魔法数字。 2. 优先使用difference、union、intersection等布尔运算组织模型。 3. 圆孔使用cylinder创建并设置$fn32以保证圆滑。 4. 代码必须能被openscad命令直接渲染不需要额外交互。 5. 只输出代码不要输出解释。 用户需求长100毫米宽80毫米厚5毫米四个角开直径3.2毫米的通孔……这个模板的核心是把边界条件锁死。你注意第5条很多人会忽略“只输出代码”这步结果模型返回一大段文字加代码你还得手动清理自动化流程直接卡住。3.4 参数化思维把“一次性模型”变成“可复用组件”text-to-cad真正强大的地方不是一次生成一个模型而是生成一个带参数的模型生成器。同样是上面那个底板你只改第1、2、3行的变量就变成了另一个尺寸的板子。这意味着你可以把LLM当成“参数化设计工具的生成器”先让它生成一个模板之后你自己改参数就行不需要再反复让模型重新生成不仅省时间还能避免模型每次生成风格不一致的问题。我自己工作流里有一个固定套路第一次生成时会要求LLM把关键尺寸全部变量化并且注释清楚每个变量的作用。这样第二次、第三次使用时只需要告诉模型“修改脚本长度改120宽度改90”它就能基于已有脚本快速迭代。4. 实操中的典型问题和排查方法4.1 生成的代码为什么总是报错我在实际测试时用OpenSCAD作为目标语言各种开源和商业模型都有一定概率生成语法错误的代码。最常见的报错有三种。第一是括号不匹配。OpenSCAD大量嵌套LLM在长代码生成时会漏括号。我的处理方式很简单把编译器的错误提示原样贴回给模型让它自修复。比如“第32行第5列差一个右括号”模型十次里有九次能改对。第二是模块名写错。比如把cylinder拼成cylindricalrubberband式的联想错误在代码模型里也偶发。这类问题靠自修复也能解决。第三是变量类型问题。有些模型会把字符串和数字混淆比如给difference传了一个True进去。这种一般要把上下文错误信息一起给模型它定位更快。还有一个排查技巧先用抽象模型测试不要直接实渲染。生成一个简化版本的代码比如把孔数目从四个改成两个看看基本语法是否通过。如果简化版也报错说明是语法层面的问题直接修语法如果简化版能跑再逐步还原复杂度问题通常会出现在你增加的某一项操作上。4.2 单位、坐标系和布尔运算的坑这是text-to-cad最隐蔽的问题没有报错但模型全是错的。很多模型在训练时见过大量不同单位的CAD脚本OpenSCAD习惯用毫米但有些商用软件的脚本用英寸模型偶尔会把英寸的数值写成毫米。一个25.4的板子应该对应25.4毫米但模型可能把它理解为25.4英寸导致尺寸差一个数量级。我的经验是在提示词里明确“所有尺寸必须使用毫米且直径、半径、长宽高都要带上具体数值”并且在渲染后检查STL的包围盒尺寸。坐标系问题更常见。OpenSCAD的默认坐标系是Z轴朝上但很多LLM在生成曲面、旋转体时会把工具默认想象成“某个三维软件”的坐标系。比如你让它在底板边缘生成侧壁它可能生成了一个躺在底板平面的平板。排查的时候只看各轴尺寸是否与你预期一致就能发现。布尔运算也是重灾区。很多新手会让一个圆柱体去切一个立方体但因为圆柱高度不够造成只切了一半的效果。或者cylinder的高度与切面的延伸方向没有搭上出现“差集后边缘多出一条线”的怪异结构。我的规避方法是所有裁剪用的工具几何体统一在指定方向延伸出去2-3毫米也就是所谓的“无限长切刀”思路。你做差集时切刀一定要穿透整个主体而不是刚刚够到表面。4.3 圆角、薄壁和抽壳为什么容易翻车当我们开始处理圆角、倒角、薄壁、抽壳这类特征时LLM的生成质量会出现明显下降。原因其实不是模型笨而是这些特征在程序化建模脚本里依赖非常精确的操作顺序。比如给一个盒子做圆角你必须在外壳抽完之后再做圆角先抽壳后圆角能成功先圆角后抽壳可能直接报错或产生退化面。LLM对操作顺序的把握远不如对人类思维顺序那么敏感它生成的脚本经常是“看起来每一步都对但连起来就错了”。遇到这类需求我一般会中途介入一次只让LLM负责外形和基础功能圆角、倒角这类在OpenSCAD里用内置函数做或者在后续导入FreeCAD后用特征编辑工具补上。换句话说不要求一次生成完美模型把特征分阶段处理成功率会高很多。4.4 提示词策略描述越具体结果越可控我做过一组对比测试同样的模型分别用两句描述去生成。第一句是“给我一个扳手”生成结果是一个像扳手的雕塑形状但完全没有尺寸概念拿着也没用。第二句是“开口宽度24毫米总长180毫米头部厚度8毫米手柄长140毫米手柄末端带直径12毫米的挂孔”生成结果基本可以直接当草图参考来用。这不是模型能力问题而是自然语言本身的约束力问题。第一句描述给出的信息熵太低模型只能发挥想象力第二句描述把关键尺寸都框死了模型在有限自由度里生成自然稳定。所以提示词里建议包含的参数包括整体长宽高、厚度、孔径、孔位、倒角半径、圆角半径、数量、阵列方向。宁多勿少哪怕你描述得啰嗦一点也比描述得模糊要好。这也是text-to-cad和普通聊天最大的差异聊天可以随意建模必须精确。5. 适用场景、边界与接下来值得折腾的方向5.1 最爽的应用场景3D打印和创客圈子如果说哪个群体最能直接享受text-to-cad红利那一定是3D打印玩家。过去你看到一个网上分享的机箱风扇支架想改成自己机箱的尺寸你得下载源文件、学习软件、一点点改。现在你只需要把需求描述清楚“适配120mm风扇安装孔距105mm厚度3mm四角M3通孔外框140x140mm”模型直接给你一个能打印的STL。我实测下来这类“机电外壳、传感器支架、电池仓、面板开孔件”的生成成功率极高因为它们的结构就是方体加圆柱孔的排列组合正好是CSG操作最擅长的领域。另一个很实际的场景是产品概念的快速评估。比如你要给客户出三个不同尺寸的传感器外壳方案传统流程要建三个模型现在只需要让模型批量生成三版代码、三秒完成渲染客户对着三个STL就能做决策。成本几乎为零。5.2 当前边界别让它去设计需要人脑经验的复杂结构我必须诚实地说text-to-cad目前最不擅长的是那些需要材料力学、加工工艺、人机工程经验的复杂结构。比如一个需要计算应力分布的悬臂梁座或者一个需要保证模具能顺利脱模的曲面外壳LLM不知道哪里需要加筋、哪里需要设置脱模斜度它只会“按描述建模”不会“按物理验证建模”。换句话说它能帮你把形状从0变成1但从1到100的性能优化还是得靠人。另一个明显的边界是装配体。单个零件的生成已经比较可靠但一涉及多个零件的配合关系“轴孔配合公差”、“齿轮啮合模数”、“螺丝沉头厚度”这些概念模型经常会出错。不是完全不能用而是你需要人工检查每一个配合面。我的建议是现阶段把text-to-cad定位为一个“草图生成器和初稿工具手上”把最后的精修和装配验证留给传统CAD环境。5.3 后续值得关注的方向我觉得接下来有四个方向值得大家跟踪。第一个是多模态融合。把一张手绘草图加一句文字描述一起作为输入。手绘图提供大形位文字补充尺寸和加工要求这组合比纯文字稳定的多。第二个是工程约束条件作为输入。比如“这个零件要承受300N力材料用PLA”这类信息直接进入生成流程让模型不只是恢复形状还能自动加厚加强筋。这条路现在还在早期但对工程落地价值极大。第三个是自回归CAD模型的完善。从目前少数能跑的实验来看让模型像写代码一样逐行去预测CAD操作序列比一开始就输出完整脚本要稳定得多也更接近人的建模习惯。第四个是和数控加工联动。text-to-cad生成的模型直接接入CNC刀具路径规划甚至把工艺信息也写进自然语言需求里“切出这个零件铣平顶面”。这个场景一旦跑通等于把“设计到制造”的链条整个压缩到了一个对话里。5.4 我个人的实操体会把text-to-cad用了一段时间之后我最深的感受是它改变的不是建模速度而是建模的思维方式。过去我拿到一个需要修改的零件图第一反应是“我能不能找到会开SolidWorks的人”或者“我要不要花三小时重新学一下”。现在我第一反应是“我用语言描述一下它要长什么样先出个初稿再说”。这个转变远比工具本身的效率提升更有意义。当然它还不是万能的目前也没必要神话它。我自己在处理正式项目时通常还是会把人机生成的模型在FreeCAD里打开检查一遍尺寸链和布尔运算结果该修的地方手动修一下。但有了这个工具我从“零到模型”的时间可以缩短到原来的五分之一甚至更短。如果你也想试我建议从最简单的“底板加孔”开始让模型先写一个20行以内的脚本跑通一次之后再加圆角、再加阵列、再加壳体和装配。这种渐进式探索比一上来就生成一个复杂装配体要靠谱得多。最后再分享一个小技巧OpenSCAD渲染报错时别光盯着代码看把STL尺寸和视觉结果和原始需求对一遍——尺寸错了比语法错了难发现十倍因为语法错误有提示尺寸错误得靠测量。text-to-cad现在就像一个刚毕业、领悟力极强的实习生你给它具体的活儿它干得又快又好你给它一个模糊的愿景它也能给你做出来一个“看着像”的东西但你要真拿去用就得一句一句把需求给它说清楚。明白了这一点这工具就是你的下一代设计入口。
