1. 这个方向解决的实际问题先说说我为什么关注text-to-cad这个方向。CAD建模这件事入门门槛其实比你想象中高得多。我在社区里看到太多人问我想画一个带孔的盒子该用什么命令也见过很多非机械专业的创客、硬件爱好者想法很清楚却在软件操作上卡了一周。传统CAD软件的学习曲线非常陡菜单层级深、命令繁多、快捷键记不全三维空间思维又劝退一批人。而text-to-cad想做的事情很简单把你脑子里的三维结构用自然语言说出来程序直接帮你把模型文件生成好。这听起来很像魔法但它背后的实现路径其实是可以拆解的。目前主流做法不是让AI直接画出一个网格体而是让大语言模型理解你的需求然后生成一段参数化建模代码——通常是OpenSCAD、CadQuery这类程序化建模语言。程序跑一遍CAD模型就出来了。为什么绕这一圈而不是直接生成STL网格后面我会详细解释。这个思路的好处很明显参数化的模型可以被后续修改尺寸可以调整特征可以复用更重要的是它能在你现有的工作流里作为一个新入口存在——不是替代设计师而是把从零开始搭积木的环节大幅压缩。这篇文章适合哪类人第一种是没系统学过CAD、但有明确设计需求的创客和硬件原型开发者第二种是想评估AI生成CAD模型能力边界的产品经理或技术管理者第三种就是纯粹对LLM应用感兴趣、想试试看自然语言驱动几何建模的开发者。我会把原理、工具、实操步骤和坑都写清楚你照着走一遍基本就能跑通一个最小闭环。2. 方案选型为什么代码生成路线胜出2.1 四条技术路线的对比text-to-cad在业界有几种实现思路我在这里先做一轮横向对比免得你选错方向。第一条路线是直接生成网格模型。你输入一个花瓶模型直接输出STL或OBJ文件。这个方案看起来最直接但问题非常致命生成的网格通常没有拓扑结构不能参数化修改无法进入传统的CAD工作流。你拿到一个花瓶模型想改一下口径做不到只能重新生成。在工程场景里这种一次性消耗品价值非常低。第二条路线是借助多视图图像重建。让AI生成模型的三个视图照片再用photogrammetry技术反推三维形状。这听着很酷但精度很差而且视图生成本身就不可控重建出来的几何常常是变形的、带噪声的。做创意展示可以做结构件完全不行。第三条路线是直接输出BREP边界表示文件比如STEP格式。这是CAD的原生语言但目前的LLM对BREP这种强拓扑结构的生成能力非常弱训练数据也少。偶尔论文里看到一些实验结果离产品化还远。第四条路线就是我前面提到的代码生成LLM输出一段参数化建模脚本。这是目前最现实、可落地、可修复、可扩展的方案。生成的代码如果有小问题你可以让模型修也可以自己改出错成本极低。现在海外社区里像Zoo.dev团队的KittyCAD还有老牌的OpenSCAD生态都在往这个方向使劲。2.2 为什么代码生成适合LLM这里有一个关键认知LLM本质上是文本生成器而不是几何引擎。你让它直接想出一个三维形状这超出了它的能力边界。但如果你让它写一段代码——尤其是OpenSCAD这种类C语言的声明式脚本——就落回了它最擅长的文本生成能力圈。大模型在海量开源代码上训练过其中包含大量OpenSCAD、CadQuery的示例它见过足够多用圆柱体和立方体拼出零件的写法。所以它不需要真正理解几何它只需要复现出合理的建模步骤剩下的计算交给几何内核去做就好。这个外包的思路很重要。LLM负责把自然语言翻译成建模操作序列并且根据约束反复调整参数真正的布尔运算、倒角、放样、截面扫描都由OpenSCAD或CadQuery的底层C几何内核完成。分工明确每层做自己最擅长的事。我实测下来OpenSCAD脚本和CadQuery脚本的成功率有明显差别。OpenSCAD的语法更简单接近声明式放一个圆柱、减掉一个方块LLM生成这类脚本的成功率更高。CadQuery是Python API功能更强但语法更复杂Workplane的链式调用逻辑稍一多就容易出错。建议入门先用OpenSCAD等流程跑通再上CadQuery做高精度控制。2.3 微调模型 vs 通用大模型另一个你需要做的选择是用通用大模型GPT系列、Claude、Gemini等还是专用微调模型。通用模型的好处是理解能力强能处理模糊的自然语言描述但它们在CAD代码上的表现不稳定——有时候生成的代码有语法错误有时候布尔运算写反了。专用微调模型比如一些团队基于Llama或CodeLlama微调的CAD专用模型在OpenSCAD代码生成上表现更稳定但对话能力差不太适合来回交互式修改。我的建议是混用。前期需求探索、弄清楚自己要什么的时候用通用大模型聊天聊清楚之后把最终结论转成结构化提示词交给专用模型或者通用模型做代码生成。平时我大多数情况直接用通用模型毕竟它的常识理解能力太强了少走很多弯路。3. 核心工具链与建模原理3.1 这套流程里需要哪几个零件跑通text-to-cad最小流程需要三样东西一个大模型API或者本地推理环境、一个程序化CAD引擎、一个查看模型文件的工具。模型API的选择取决于你的预算和隐私要求数据敏感性高的场景建议本地部署开源模型数据不敏感、追求效果的直接用云API。程序化CAD引擎里OpenSCAD是首选有三个理由开源免费、脚本语法简单、命令行支持批量导出STL/STEP。CadQuery作为进阶备选它是Python库适合已有Python开发经验的用户。查看模型文件的工具OpenSCAD自带的预览窗口就够用导出STL之后也可以用FreeCAD、MeshLab或者Windows自带的3D查看器做终检。整个流程是这样一个链条自然语言描述 → LLM翻译成CAD脚本 → 几何引擎解析脚本 → 生成三维模型 → 导出为STL/STEP → 进入后续制造流程。链条每一环都有可能出现问题我们后面逐个排查。3.2 OpenSCAD的建模语言为什么适合LLM生成OpenSCAD的脚本语言有几个特点简直是为LLM生成量身定做的。第一个特点是搭积木式的CSG建模。核心操作就是并集、差集、交集加上最简单的几何体立方体、球体、圆柱、多面体。这跟自然语言描述的思维方式非常接近。你说一个圆柱底部挖一个孔翻译成OpenSCAD就是cylinder加differenceLLM对这种映射关系的把握非常稳。第二个特点是参数少且显式。尺寸、圆心坐标、旋转角度都是直接写在括号里的数字。这不像传统CAD软件那样有各种依附关系、草图约束降低了LLM的表达负担。第三个特点是可读性好。生成的脚本任何人打开都能一行行读明白方便调试。出了问题你可以直接把报错信息扔回给模型让它修形成一种简单的生成-报错-修复闭环。我测试的时候发现把任务描述得越结构化模型生成的代码质量越高。比如不要说一个带盖子的盒子要说一个长方体长60mm、宽40mm、高30mm中空壁厚2mm顶部有可分离的盖子。不是模型笨是模糊描述本身信息量不足它只能靠猜。3.3 CadQuery与更高精度场景如果你面向的是需要导入传统CAD软件继续深加工的零件OpenSCAD有时候不够用——它的STEP导出质量和参数化机制都比较朴素。这时候CadQuery可以利用Python的完整语法做更复杂的逻辑循环、条件判断、数学计算、外部数据导入。CadQuery的核心概念是Workplane从某个基准面开始往一个方向挤出草图轮廓然后再基于已有面继续做特征操作。这非常像传统CAD软件里的特征树思路但用Python代码表达。LLM对这种链式调用代码的生成能力在逐步提高但确实不如OpenSCAD稳定。我的经验是生成CadQuery代码的时候给模型一个代码模板至关重要让它在框架里填空而不是从头推导整段代码。模型犯错的概率会低很多。3.4 从脚本到几何的完整推导不管用OpenSCAD还是CadQuery脚本最终要经过几何内核的解析。你写的cylinder(h20, r5)底层会构建一个圆柱体的BREP数据你写的difference()底层会对两个BREP对象做布尔减运算。这一步和你手动在FreeCAD里做布尔运算的本质完全一样只不过操作命令变成了文本。在OpenSCAD的预览模式下几何计算是即时更新的。改一个数字形状立刻变化。这给了我们一个非常高效的探索-反馈循环。你甚至可以把调整壁厚到3mm这种指令直接丢给模型让它输出修正后的完整脚本覆盖原来的文件。在参数化建立之后后续迭代成本极低。4. 实操从一句话到STL文件4.1 第一步结构化你的自然语言需求直接说给我建一个壳子是没有用的。你得把需求拆成六个要素几何类型、关键尺寸、相对位置关系、特征操作、圆角倒角要求、单位和精度。我一般这样组织提示词总体形状如一个开口朝上的薄壁圆筒尺寸参数如外径50mm高度80mm壁厚3mm附加特征如底部有一个直径10mm的通孔用于穿过线缆细节要求如顶部边缘做1mm倒角输出要求如用OpenSCAD写代码单位用毫米放在一个输出块里这样模型拿到的信息是完整的写出来的代码自然更准确。你可能会觉得直接说人话不是更自然吗但实际操作下来结构化描述能显著降低模型的猜测空间。4.2 第二步写出有效的Prompt模板我长期在用的一个Prompt模板分享给你任务根据下面的描述生成一段OpenSCAD代码。 要求 1. 单位毫米 2. 坐标原点模型底部中心位于原点 (0,0,0) 3. 除非特别说明不要使用外部模块 4. 代码要参数化关键尺寸使用变量定义 5. 布尔运算使用 difference 时被减去的对象要大一点避免共面问题 描述 [在这里写你拆解好的六要素描述]这里有几个细节解释一下。底部中心位于原点这个约束极其重要。LLM默认的建模坐标往往很随意如果你不约束原点后续做3D打印切片或者CNC加工定位时模型位置会不理想。不要使用外部模块是为了减少依赖避免模型生成依赖BOSL2等外部库的代码导致你本地跑不起来。布尔运算的被减对象要大一点是经典避坑技巧。两个曲面完全共面时几何内核做差集经常失败或出现奇怪的破面加一个0.001mm的偏移就能绕开。4.3 第三步生成并运行OpenSCAD脚本我用一个具体案例来说明。假设我想做一个树莓派外壳的简版——一个带四个安装柱的平板底座。我给的描述是这样的一个矩形底板长85mm宽56mm厚2mm。 四个角各有一个圆柱安装柱高度6mm直径8mm中心距板边缘5mm。 每个安装柱中心有一个直径3mm的通孔贯穿整个柱子和底板。 所有外部垂直边缘做1mm倒角。模型生成的OpenSCAD代码大概是这样的结构// 参数化定义 base_length 85; base_width 56; base_thickness 2; standoff_height 6; standoff_diameter 8; hole_diameter 3; edge_radius 1; margin 5; // 底板 difference() { minkowski() { cube([base_length - 2*edge_radius, base_width - 2*edge_radius, base_thickness]); cylinder(redge_radius, hedge_radius, $fn32); } // 四个安装孔(穿透底板部分) for (x [margin, base_length - margin], y [margin, base_width - margin]) { translate([x, y, -1]) cylinder(dhole_diameter, hbase_thickness2, $fn32); } } // 四个安装柱 for (x [margin, base_length - margin], y [margin, base_width - margin]) { translate([x, y, base_thickness]) cylinder(dstandoff_diameter, hstandoff_height, $fn64); }注意这里的minkowski()做倒角是OpenSCAD里常见的技巧。如果你直接用$fn去控制圆角数量文件渲染会很慢用minkowski可以保证外观圆润的同时代码还很短。这是模型从训练数据里学会的常用方案之一比我手写还省事。运行代码你马上能看到一个带圆角底板、四个圆柱从底部升起的模型。如果形状对导出STL进入切片软件或者CAD检查都行。4.4 第四步验证和迭代修改验证是第一优先级的事情。首轮生成的代码大概率有小问题很正常别指望一步到位。我建议按三个层次验证第一层模型能不能正常渲染。打开OpenSCAD预览看有没有语法错误。OpenSCAD的报错信息已经比较友好了直接指向第几行。把这行报错扔回给模型让它修通常一轮就好了。第二层形状方向对不对。旋转视角看模型确认没有镜像、倒置、方向不对的问题。这一步只能靠人眼判断。第三层关键尺寸实际是多少。用OpenSCAD的测量功能或者导入FreeCAD测一下确认孔位、间距这些核心尺寸没有偏差。算一下安装柱中心距应该是85-2*575mm如果测量出来不对说明描述里有歧义回到Prompt层面修正。4.5 第五步导出STEP并衔接下游工作OpenSCAD的默认导出格式是STL但STL只有三角面片不含几何精度信息后续没法编辑。更专业的做法是导出STEP文件。OpenSCAD从2021版本开始支持基于PythonOCC内核的STEP导出能力。你可以直接在界面操作导出STEP也可以用命令行openscad -o output.step input.scad注意需要安装额外的依赖具体看你系统的包管理提示否则导出会失败。拿到STEP之后你可以导入FreeCAD做特征编辑、尺寸标注或者直接导入Fusion 360做装配仿真。到这一步text-to-cad这条链路的价值才算完整体现出来它快速产出可编辑的参数化几何体但真正的工程细节你仍然需要在传统CAD环境里做收尾。如果你要做3D打印STL已经够用。切片软件Cura、PrusaSlicer、OrcaSlicer都能直接读取。5. 常见问题与排查技巧实录5.1 语法错误和依赖缺失最常遇到的问题是模型生成了自己不熟悉的模块名或参数。比如它可能使用cirlce拼成了circle的大小写错误或者使用了import外部库的语法。前者好办OpenSCAD会自动高亮报错位置你让模型重新生成即可。后者建议沉默处理——直接在提示词里加一句只用原生的OpenSCAD函数。本地环境缺失依赖的情况我也会经常遇到。特别是从命令行导出STEP时提示找不到pythonocc相关的包。解决方式是在你的Linux发行版里安装openscad-step包或者在Windows/macOS上使用自带的STEP导出插件。每个平台的安装细节略有区别但思路是一致的先确认OpenSCAD版本够新再装对应平台的STEP支持组件。5.2 模型能显示但不导出、出现破面预览窗口看到模型没问题一导出STL就有麻烦。常见的现象有导出报错、STL文件在切片软件里显示一堆洞、模型倒过来放导致打印悬空。破面问题通常来自布尔运算的共面冲突。前面提到过差集操作时两组曲面完美贴合几何内核判定不了边界。解决方法是修改脚本让被减的体比减去的体多走0.001mm到0.01mm打破共面的完美状态。打印悬空的问题更有意思。模型本身没问题但你忘了它在切片软件里的摆放姿态。OpenSCAD默认Z轴向上但切片软件通常以平台为XY平面如果模型底面在Z轴的负方向切片后就是悬空的。我在提示词里写了底部中心位于原点这样才能保证模型直接放在打印平台上。5.3 描述正确但生成结果不稳定同一个Prompt不同时间跑结果可能完全不同。大模型本身有随机性这在text-to-cad场景下影响尤其大。因为生成CAD脚本是精度敏感型任务一个尺寸差0.5mm零件可能就装不上了。解决思路是固定采样参数再选优。在调用API时可以把temperature调低到0.2以下获得更确定性的输出。如果还不行让模型先输出一个规划文本——列出它打算怎么做然后再生成代码。这个先规划后执行的小技巧实测非常管用模型在文本推理阶段会把几何关系捋顺后面的代码就稳定很多。5.4 复杂几何不支持怎么办目前的text-to-cad对旋转体、扫掠体、放样这类高级特征的支持偏弱。你说这个把手是沿着一条曲线扫出来的模型大概率会生成一段复杂的循环代码但效果不好。我的经验是把复杂特征拆成简单特征的组合。比如扫掠体拆成一串圆柱沿着路径排列或者用旋转体rotate_extrude去近似。别试图让模型一步到位做复杂件。正确做法是把它当学徒先让它把骨架搭出来你再逐步加特征细节。每一轮改一点比一轮生成一个巨型脚本成功率高得多。5.5 常见问题速查表问题表现可能原因排查方法快速解决语法报错模型生成了不存在的函数看报错行号让模型修复或改用原生OpenSCAD函数导出STL时破面布尔运算共面放大检查连接处加0.001mm偏移打破共面打印时悬空模型在Z轴负方向查看模型坐标系在提示词中固定原点到底部中心尺寸偏差大于0.5mm描述太模糊测量关键尺寸结构化提示词明确数字模型没有壁厚描述未提壁厚切片预览确认补充薄壁等特征描述运行卡死圆柱的$fn数值过高检查代码降低$fn到64以内无法导出STEPOpenSCAD缺少组件检查版本和依赖安装STEP支持包6. 进阶把text-to-cad接入真实工作流6.1 规律总结什么时候该贴进你的项目text-to-cad适合用在一个项目的概念设计早期。结构工程师拿到一个需求快速生成三五个粗略方案对比一下大致形态和干涉情况再定方向。这种低成本快速迭代优势在需求频繁变化的前期价值最大。一旦设计方向确定进入详细设计阶段text-to-cad的帮助就减弱了。这时候你需要的是精确控制、DFM面向制造的设计检查、应力仿真这些还是要在专业CAD环境里做。我的建议是text-to-cad做高速草图专业CAD做精加工。6.2 用开源工具搭建本地管线开源方案分享一套给你你本地的OpenSCAD Ollama用于跑开源模型 自写Python脚本负责管理提示词和批处理导出。这套管线适合对数据隐私要求高的场景。Ollama可以选择Qwen2.5-Coder-32B这类代码能力强的开源模型在代码生成尤其是OpenSCAD这种小众语言上的表现还可以接受。如果你实在不想折腾本地模型用成熟API做前端交互OpenSCAD做后端执行器也完全可以。这里的关键是前端后端的松耦合架构。LLM不直接输出模型文件而是输出中间代码几何引擎负责最终计算。这个架构的优雅之处在于以后出现更聪明的模型你只需替换前端的模型调用后端不用动。6.3 参数化库与模板沉淀这个技巧强烈建议认真掌握。跑通几个案例之后你会发现自己反复生成类似的结构带孔的板子、卡扣、安装柱、加强筋。把这些常用结构沉淀成OpenSCAD模块放到你的模板库里。以后提示词让它调用plate_with_holes模块参数见模板生成的代码更短而且不容易出错。我自己的模板库里放了十几个常用模块每次设计新零件至少能省一半时间。这个复用思路跟写代码是一个道理——封装变化稳定接口。7. 当前边界与值得关注的方向目前text-to-cad在简单机械零件、壳体类零件、标准连接结构上表现很好但在曲面造型、复杂自由曲面、大装配体上的能力还非常有限。如果你设计的产品是消费电子外壳那种复杂的曲面造型用text-to-cad做探索意义不大它生成的曲面往往缺乏美学价值。但对内部结构件、支架、隔板、固定座这类功能优先的零件它已经能很好地上岗了。未来值得关注的几个方向一是专用微调模型越来越多各家团队都在标注更精细的CAD数据二是多模态大模型结合直接看图改模型会变成可能三是与拓扑优化、仿真分析的集成从文本直接生成一个满足强度条件的结构件不再遥远。我个人的看法是text-to-cad短期内不会取代传统CAD但它正在改变设计的入口环节。过去设计师从空白画布起步现在可以站在自然语言的肩膀上起步。这个转变对非专业设计师的影响尤其大——设计能力的门槛正在被技术拉平。结尾的个人体会我实际用下来最大的感受是text-to-cad真正省下的不是建模时间而是打开软件前那段犹豫时间。很多时候你有一个不成熟的想法传统流程里必须先建个模型才能讨论模型不好建想法就一直悬着。现在你可以一句话把想法变成可视化的模型哪怕很粗糙它已经能激发下一步讨论和修改了。这种快速试错的节奏才是这类工具最珍贵的价值。最后分享一个小技巧把你测试过的成功提示词按类型归档随时翻用。我踩过不少坑之后发现好的提示词跟好的设计图纸一样都是复利资产。头几次用可能还不顺手多攒几轮生成效果会越来越好你的设计速度也会越来越快。希望这套流程对你也有同样的效果欢迎拿着案例去试遇到奇怪的问题再回来交流。
