第一次听到text-to-cad这个概念是在去年一个机械设计的线上分享会上。有人提了一嘴以后你说一句话SolidWorks自己就把零件画出来了。当时我第一反应是不太信觉得又是AI圈子在画饼。结果今年自己从需求调研到动手跑通前前后后试了好几套方案之后我发现这个东西虽然还没到“一句话出完美图纸”的程度但它真的已经能当作快速出原型的辅助工具来用了尤其是配合同样是代码驱动建模的方式落地比想象中快很多。这篇文章就把我踩过的坑、试过的方法、还有我自己总结出来的提示词套路都写出来给你一个能直接照着操作的参考路径。1. text-to-cad到底做了一件什么事1.1 从一段文字到三维模型中间发生了什么想象一下传统方式客户说“我要一个底板200毫米长100毫米宽10毫米厚四个角打直径8毫米的圆孔”。你还得先打开软件选基准面画草图拉伸打孔可能还要加倒角。这套操作熟练工也要五分钟。但如果你在一个对话框里输入这句话几秒钟后拿到一个可编辑的CAD文件那就是两个世界的效率差距。text-to-cad的核心任务就是把“听人话”到“做模型”这个过程自动化。这事儿牵扯到三块能力。第一是自然语言理解它得知道“底板”“圆孔”“倒角”这些词对应什么几何语义还得知道“四角”“等距”这类空间关系词意味着什么。第二是参数提取能从“200毫米”“直径8毫米”里抓住具体数字和单位。第三是程序化建模它得把上面的语义和参数变成CAD软件能执行的操作序列。现在主流的实现方式通常是用大语言模型把自然语言翻译成一段程序比如CadQuery或OpenSCAD脚本再由程序执行生成实体或者网格而不是让AI直接吐出一个三角网格文件。这个选择很关键直接决定了下游能不能用。为什么大家普遍走“文字转程序再转模型”这条路因为程序化建模生成的模型带特征历史带参数甚至能回到CAD软件里继续编辑。工程师可以复核特征树改一个尺寸然后重新生成。工业界愿意接受AI辅助的前提就是结果可以追溯、可以改、可以走审批流程。如果AI只是吐一个三角网格文件那工程师拿到手里几乎没法继续操作最多看看外观加工、装配、出图全都废了。所以现阶段真正能被CAD软件接纳的text-to-cad方案基本都是往“代码生成器”的方向做。1.2 为什么不是“生成图片”而是“生成代码”有人会问直接用Stable Diffusion那套生成3D网格的玩法不就行了现在确实也有不少直接从文本生成三维网格的模型比如早期的Point-E、Shap-E还有一些基于扩散模型的研究。它们的输出是离散的高密度mesh视觉上可能挺像样但跟CAD系统里基于边界表示B-rep的实体模型完全不是一个世界的东西。你要对它进行倒角、打孔、装配、有限元分析几乎没法继续操作因为它没有连续曲面也没有特征历史更没有一个可调参数。而走“代码生成”这条路底层用的是CadQuery、Build123d、OpenSCAD这类带参数化建模能力的工具。输出是一段可读的脚本跑完之后能生成带特征历史的模型。比如一个方盒子打四个孔脚本里清清楚楚写着先拉伸、再定位、再切除。工程师拿到脚本一眼就能看懂模型是怎么来的改一个孔位坐标就是改一个数字这么简单。这样从简单的标准件到复杂的钣金件都能接受人工二次调整。从这个角度看text-to-cad从一开始就不是为了替代CAD软件而是把“构思到三维草图”这个环节从按天计算压缩到按分钟计算。它的目标用户也不只是专业工程师还有大量不熟悉建模工具、但需要快速验证想法的产品经理、结构工程师、创客和3D打印爱好者。你不用先花两个月学SolidWorks只要能把需求说清楚就能拿到一个能导入切片软件或者CAD软件的原型模型。2. 快速跑通一个最小可用方案2.1 准备环境其实不需要太复杂我在试过几个客户端的商业工具之后转向了开源社区方案。原因是商业产品往往把模型生成放在云端能用是好用但数据保密、格式导出、批量生产这些环节都受限。自己搭一套最小的text-to-cad流程其实不需要高端GPU训练模型你只需要三样东西一个能跑Python的电脑、一个大语言模型的API或者本地模型、以及一个能执行脚本的CAD内核。我这里以最简单的组合为例用OpenSCAD作为建模内核再用任意一个支持代码补全的大模型API写OpenSCAD脚本。OpenSCAD的好处是没有GUI一切模型都由脚本定义和自然语言到代码这个流程天然契合。你不需要额外安装SolidWorks或者Fusion 360直接下载OpenSCAD便携版解压就能用。模型API方面你用本地跑得动的Qwen或者Llama都行只要能稳定输出OpenSCAD代码效果一样。这个组合最大的优势是中间每一层都透明模型出了问题你可以定位到是语言理解错了还是脚本语法错了。2.2 写一个最简单的自然语言转CAD脚本我的第一个demo长这样在终端里输入一句描述然后脚本调用大模型拿到OpenSCAD代码再自动打开OpenSCAD渲染。import subprocess import json def text_to_openscad(prompt, llm_api): system 你是一个OpenSCAD脚本生成器。只输出.scad代码不要解释不要输出markdown。 response llm_api(prompt, systemsystem) with open(output.scad, w, encodingutf-8) as f: f.write(response) subprocess.run([openscad, -o, output.stl, output.scad])看到没有核心逻辑就这么简单。真正花时间的不是这十几行代码而是怎么让大模型明白“我要的OpenSCAD代码应该符合什么规范”。我后来会在system提示里加入OpenSCAD的常用内置模块清单比如cube、cylinder、difference、translate这些函数名让模型优先使用这些封装好的指令生成结果的语法错误率会低很多。第一次运行我输入的就是很普通的描述“一个30mm×20mm×10mm的长方体中间挖一个半径5mm的圆柱孔”。按理说这模型没什么难度但模型第一次输出的是CadQuery风格代码而不是OpenSCAD因为它在角色切换上没理解透。后来我把system提示改成“你只输出OpenSCAD 2021以上版本支持的语法”再配合几行示例第二次就成功跑出了STL文件。事实证明给模型做角色约束和格式示范比反复叮嘱它“准确”有用得多。2.3 调整提示词的几个关键技巧跑通一次demo之后我开始把同一个模型描述反复用不同措辞测试。这里我总结出几个非常实在的规律。第一把描述拆成“主体、尺寸、特征”三段式。不要写“我要一个带孔的板”而是要写“创建一个长80、宽60、厚15的平板四角各有一个直径6的通孔孔心距边缘10”。这个结构跟CAD建模的逻辑是一致的先有基体再有特征。模型按这个顺序组织脚本不容易漏要素。第二给尺寸带上单位。你写“板子厚度10”模型可能默认成毫米也可能抽风成厘米尤其是跨语言输入的时候单位歧义特别明显。我自己的习惯是在描述里全部用“长80mm”并且让system提示里明确写着“所有尺寸默认毫米除非用户显式说明其他单位”。第三复杂特征一次性说全没用不如分步迭代。你一开始就说“带散热孔、圆角、凸台、螺纹孔”最后的结果往往顾此失彼。我会先让模型生成基础形状再通过追加指令往里面加特征“在上一步模型基础上在四个角添加半径3的倒角”。分步操作的好处是每一步都简单模型不容易混乱而且你可以在中间节点停下来检查。3. 手把手拆解一个实例带安装孔的底板3.1 第一次尝试一句话直接出模型为了让整个过程更直观我拿一个真正会出现在产品设计里的零件来当例子一块80×60×15的安装底板四角各有直径6的通孔孔心距边缘10上表面需要有一个沉台用来放传感器。这个零件如果手工在OpenSCAD里写最多三分钟但我想看看text-to-cad能不能一条指令搞定。第一次我的提问是“生成一个安装底板带四个安装孔和中间的沉台”。这个描述丢给模型后脚本倒是没报错但渲染出来的模型完全不对。四个孔变成了一个小圆柱阵列沉台的位置跑到了零件外面整体尺寸直接是默认的100×100×20。问题出在哪尺寸没给模型拿不到真实参数就只能猜。位置关系也描述得不够清楚“中间”是哪个中间上下中间还是左右中间所以第一步就翻车是正常的不用怀疑人生。我把这个问题当成了提示词工程的典型教训自然语言里的“中间”有歧义必须转化成明确的坐标信息。你需要的不是让AI替你理解空间而是让它替你执行你已经想清楚的建模操作。想不清楚的时候模型也会给你一个想当然的结果。3.2 失败后的修正把需求拆成“参数特征约束”第二次我调整了输入不再用随意的一句话而是按照我自己总结的三段式写“创建一个80mm×60mm×15mm的长方体底板。特征四角各有一个直径6mm的贯通圆孔孔心距离相邻边缘都是10mm上表面中心有一个直径30mm、深度5mm的圆形沉台。”这个描述里参数是80/60/15/6/10/30/5特征是长方体基体、通孔、沉台约束是“孔心距离相邻边缘都是10mm”和“上表面中心”。模型这次输出的OpenSCAD脚本逻辑清晰先建立主体再定位孔再挖沉台。我把代码贴出来省得你自己去试difference() { cube([80, 60, 15]); // 四个角安装孔 translate([10, 10, -0.5]) cylinder(h 16, d 6, $fn 32); translate([70, 10, -0.5]) cylinder(h 16, d 6, $fn 32); translate([10, 50, -0.5]) cylinder(h 16, d 6, $fn 32); translate([70, 50, -0.5]) cylinder(h 16, d 6, $fn 32); // 上表面圆形沉台 translate([40, 30, 10]) cylinder(h 5.1, d 30, $fn 64); }这里有个细节我后来才注意到沉台是从上表面往下挖的所以圆柱体的z坐标应该是15减5也就是10高度稍微多给0.1是为了避免浮点重合面。这类经验模型是不会自动给你的需要你自己识别并在提示词里要求“贯通”“深度”这些方向信息。渲染后我用STL预览检查尺寸正确孔位正确沉台方向也对了。这个版本终于能投入实际使用了。整个修正过程让我最感慨的是text-to-cad真正的瓶颈其实不在模型生成能力而在人怎么把一个模糊的工程意图表达成机器能理解的结构化描述。3.3 从程序化模型导出STL并检查拿到scad脚本后用命令行或者OpenSCAD界面导出STL这一步看起来简单但有不少细节。首先是导出分辨率太阳洁面号$fn的设置直接决定圆的精度。如果你把$fn设成16圆柱看起来就是多边形打印出来的孔会坑坑洼洼。我自己做功能原型的时候安装孔至少设$fn32外观曲面设到64以上。但如果你的零件只用来做结构验证不需要追求高精度因为高精度会让STL文件特别大切片软件处理起来也会卡顿。导出之后一定要用第三方工具看一遍。为什么不用OpenSCAD自带的预览因为OpenSCAD的实时预览为了流畅显示精度比实际导出的STL低很多你在预览里看到的圆可能是12边形导出后却是个光滑的64边形。反过来也有可能预览里看着好好的导出STL之后发现有个面翻转了。我用的是常见的Meshmixer来做检查重点看法线方向是不是朝外、有没有非流形边、内部有没有游离面。这些是3D打印和CAM加工直接相关的要素漏一个都可能导致后续环节出问题。检查通过之后我会顺手把这个零件的提示词和脚本存成一个模板文件。后面再遇到类似的底板只需要在模板里改数字重复操作的成本基本为零。这个习惯让我在后续好几个项目里省了大量时间建议你也试一试。4. 影响实际效果的关键因素与排查方法4.1 提示词语义模糊导致几何错乱很多人在初试text-to-cad时遇到的最大问题是模型生成的CAD模型形状对但位置关系完全不对。比如让他们生成“左侧挖个槽”结果槽跑到了右侧。这类错的根源往往在语义歧义上“左侧”是站在零件前端看还是站在默认轴测视角看机器根本没有这个常识背景你如果不明确给坐标或者方向它只能凭训练数据里的概率猜测。我的解决办法是在描述特征时尽量用坐标或参考面而不是用“左边”“右边”这种相对词。比如“在x轴负方向一侧的中心位置开一个槽”这虽然不是最口语化但模型理解起来几乎没有歧义。如果你坚持用自然方位词那就把观察视角也写进去比如“从前视图看你面向的方向板的左侧”。这样虽然啰嗦但效果立竿见影模型误判的概率下降很多。4.2 单位、坐标与布尔运算的常见坑单位不一致是另一个高产雷区。有些模型会默认毫米但当你描述里混着“cm”“英寸”这类单位时结果经常会忽大忽小。我建议每次调用都让模型强制使用“毫米”为唯一单位并且在system提示里声明“如果用户没有指定单位一律按毫米处理”。我踩过最狠的一次是生成一个外壳描述里写了“5cm”模型却当成5毫米处理最后导出的模型小了整整十倍我还愣了半天才反应过来。坐标原点也值得单独说。很多text-to-cad工具生成的模型默认基准点放在长方体的一个角上也有放在质心的。这两种基准会导致定位结果差异很大。如果你要把多个零件装配在一起必须在提示词里明确“以模型底面中心为坐标原点”或者“以底面左下角为原点”否则后面做装配的时候你就会直面什么叫“天各一方”。布尔运算和重合面也是OpenSCAD系工具的老坑。当两个实体表面完全重合时布尔运算可能会出现无法化简的情况导致导出STL后出现裂缝或非流形面。比如你在一个100×100×10的平板上挖一个高度正好也是10的圆柱看起来应该贯通但因为浮点误差两个面没有完全相交结果就差了那么0.0001mm。解决方法是给圆柱高度多给0.1mm或者干脆给到100mm让它彻底穿透。这类细节在文本生成代码的流程里尤其容易翻车因为模型不会自己考虑到公差它给你的代码往往是最“直觉”的版本不一定是最稳妥的版本。4.3 一个快速排查清单我在实际用了一个多月之后整理了下面这个排查清单。每次模型生成结果不对不慌着改提示词先按这个顺序过一遍现象可能原因排查动作模型尺寸差得离谱单位被误判强制在提示词里写上全部单位检查生成代码中的数值孔或槽位置偏了坐标原点或方向歧义用绝对坐标或参考面重写特征描述布尔运算失败重合面、穿透深度不足给切除特征多留0.1mm以上余量生成的是网格而非实体脚本模型角色理解错误强化system提示明确“只输出OpenSCAD/CadQuery代码”特征数量不对自然语言里数量词被忽略把“四个孔”改成“四个分别位于四角、孔心距边缘10mm”导出STL有坏面布尔运算残留非流形边用Meshmixer自动修复倒回检查脚本中的差集操作这个清单不是万能的但它能帮你节省至少一半的试错时间。我每次遇到问题都会先对照这个表如果还解决不了再把生成代码逐行读一遍通常就会发现问题出在某个坐标或者尺寸计算上。5. text-to-cad在哪些场景能真正发挥作用5.1 哪些领域现在就能用如果只说一句话那就是“标准化程度越高text-to-cad越好用”。你让它生成一个非标的装饰雕塑它大概率做得很粗糙但让它生成一个带若干孔位的安装板、一个电工接线盒、一个简单的齿轮外壳、一套抽屉滑轨的适配垫片效果往往一下就上来了。为什么因为这些零件的特征高度结构化可以用有限几个参数完整描述正好落在大模型擅长的那类文本到规则映射的舒适区里。3D打印爱好者是目前最活跃的使用群体。很多时候你想打印一个物件但你的建模水平没到那个程度在Thingiverse上找参数又不一定符合自己需求。这时候你用text-to-cad描述一下要的尺寸和特征一分钟内就能拿到STL丢进切片软件。CNC加工领域也有用但门槛高一些因为加工需要考虑刀具半径、装夹方向、工艺留量这些信息目前的文本生成模型并不能自动处理。更多情况下它是帮你生成毛坯模型然后在CAM软件里补加工策略。教育领域对我来说是另一个有意思的方向。给学生上课的时候如果一开始就让他们记一堆投影规则和草图命令很容易劝退。但如果你让学生用自然语言描述一个零件再让text-to-cad生成模型他们能直观看到文字和三维形态的映射关系。这比传统教学更符合“想法驱动设计”的思维方式。5.2 工程上的边界从设计到制造还缺什么现在虽然能跑通但离真正的生产力工具还有距离。我最大的感受是text-to-cad只能解决“几何形状的生成”却解决不了“工艺合理性”的问题。举个例子你让它生成一个薄壁外壳它可能给出1mm壁厚但你如果打算用注塑模具生产这个壁厚可能不够或者会缩水。铸造的拔模斜度、钣金折弯的展开补偿、装配的公差配合这些知识模型目前还很难主动带入。所以我的建议是别指望text-to-cad一步生成最终图纸而是把它当作一个快速生成概念模型的加速器。拿到模型后该导入CAD软件修改的修改该做强度校核的做校核该问加工师傅的问师傅。工具的意义是把前面那段重复劳动压缩掉而不是替你决策。我在实际项目中把text-to-cad用在方案评审阶段给客户看一个3D效果比给二维草图省太多沟通成本。一旦方案确定还是回归到传统CAD里去细化。我自己的使用体验是text-to-cad最适合的场景不是让你凭空生成一个高难度的装配体而是把那些重复标准化、特征清晰的模型描述变成一次点击的事。你第一次用的时候肯定会翻车但只要把提示词结构想清楚——先说类型再说尺寸最后说特征和约束——成功率会大幅上升。后面甚至可以把自己常用的零件模板沉淀成一批固定的描述风格收到需求直接替换数字非常舒服。现阶段只要把握好“快速验证”这个定位它给你的回报绝对对得起你花进去的学习成本。