前两年我刚开始接触 text-to-cad 这个概念时第一反应其实是“怀疑”。把一句自然语言变成能拿去加工、装配的三维模型听起来更像科幻演示不像工程现实。后来我自己搭了一套完整流程从一句话生成法兰盘、支架、外壳到导入商业 CAD 里做装配和出图跑通之后我的判断彻底变了——这件事是能落地的而且它解决的痛点非常具体。它并不是要取代传统 CAD 操作而是把“语言理解”和“参数化建模”这两件本身就可靠的事用工程化的方式串在一起让三维建模的门槛和效率同时发生质变。这篇文章我想从方案设计的角度完整拆一遍text-to-cad 到底在解决什么问题、整套系统应该怎么搭、关键环节有哪些坑以及什么场景真正值得用。1. text-to-cad 到底在解决什么问题1.1 传统 CAD 建模的痛点传统 CAD 建模最大的问题不是“功能不够”而是“操作和学习成本太高”。一个熟练工程师用鼠标键盘在界面里点选、拉伸、切除、打孔完成一个中等复杂度的零件可能只需要十几分钟但对于一个只做过简单三维设计的人来说光是搞懂草图约束、基准面、特征树就够头疼的。哪怕是资深工程师面对重复性很强的标准化零件——比如各种规格的法兰、垫片、支架——也得一次次重复同样的操作流程只是尺寸不同而已。更深层的问题在于“设计意图的传递”。很多非标设备的工程师手里有一张手写草图或者一段口头描述“这里有个安装板200 长 150 宽四个角上打 6 个的孔”但到了建模软件里这些信息需要被翻译成一系列精确的几何操作。翻译过程中一旦理解偏差做出来的模型和实际需求对不上来回改模型的时间往往比新建一个还长。text-to-cad 就是从“翻译”这一环切入的让机器直接理解自然语言里的尺寸、特征和约束再自动生成对应的几何模型。1.2 文本驱动建模的核心价值核心价值可以归结为三句话让小白能建模让老手能提速让设计意图有据可查。对小白来说输入“一个外径 60、内径 25、厚度 8 的法兰盘带 6 个均布的安装孔孔径 6孔中心距 44”远比打开软件学习怎么画圆、怎么拉伸、怎么阵列要直观得多。对老手来说批量生成几十个不同规格的同类零件时不需要再手动改特征参数直接改文字描述重新生成即可。更重要的是自然语言描述本身就是一种“参数化记录”它比特征树更接近人类的表达习惯后续做设计变更时直接改一句话比在特征树里找参数可读性好太多了。不过这里要强调一点text-to-cad 的目标不是完全替代传统 CAD而是填补“从需求到模型”之间的空白。最终的生产级模型仍然需要经过 CAD 软件的校验和加工工艺验证这个边界我想清楚之后整套方案的定位就明确了。2. 从文字到模型整体方案如何搭2.1 方案选型为什么是“大模型 脚本化建模”组合我见过很多团队尝试直接让大模型输出三维网格文件比如直接生成 STL 或 OBJ目前这条路基本走不通。原因是三维网格数据量大、拓扑关系复杂现有大模型在这类数据上的生成质量远不够稳定而且生成的模型往往是不可编辑的“死模型”没法继续做参数化修改。真正靠谱的路线是让大模型理解自然语言输出一段结构化的建模脚本再由脚本化 CAD 内核执行这段脚本生成精确模型。这个组合的本质是大模型擅长“语义到结构化信息的映射”而脚本化建模内核擅长“精确的几何计算”。两者互补彼此做自己最擅长的事。我用的大致分层是这样的语义层大模型负责把自然语言意图解析成参数表比如尺寸、数量、位置关系、特征类型。表达层根据参数表生成一段建模脚本脚本调用内核提供的建模原语圆柱、立方体、孔、阵列、布尔运算等。执行层脚本化内核运行脚本执行布尔运算和特征操作输出带参数特征的模型文件。为什么不用传统 CAD 的宏录制宏录制确实也能生成脚本但它需要你先在界面里手动操作一遍操作过程无法回溯成自然语言。而大模型直接生成脚本不需要任何前置操作从零开始就能建模灵活度完全不是一个级别。2.2 数据流与模块拆解我实际跑通的完整数据流大概是这样的用户输入一个描述语句比如“生成一个 L 型支架两个安装面分别长 80 和 60宽 40厚度 5每个安装面上有两个直径 6 的安装孔孔距 45 和 25”。大模型对语句做意图解析输出结构化 JSON 参数表里面包含类型、尺寸、特征列表。后端服务把 JSON 参数表映射到建模脚本模板上填充参数并执行。建模内核生成几何模型导出为 STEP、STL 或原生脚本文件。对模型做校验检查体积、质量、特征数量、是否存在干涉。这个流程里最关键的一环是第 2 步和第 3 步之间的“参数规范化”。大模型直接生成的 JSON 往往会出现字段名不一致、单位不统一、特征重复等问题。我在这两层之间加了一个“参数清洗”模块做三件事单位归一化所有长度统一到毫米、字段名映射把“孔径”“直径”“打孔尺寸”这类同义表达映射到同一个字段、范围校验孔距不能大于板长孔径不能大于外径。2.3 提示词设计技巧提示词在这里不是写一段话就完事的。我试过几种模式比较稳定的做法是给大模型定义一个输出模板让它按模板填空。例如要求它“将用户的建模需求解析为 JSON严格按照以下结构输出part_type、length、width、height、features[]”。然后在系统提示里明确单位规则“如果用户未说明单位默认按毫米处理并在直径类专业字段中保留一位小数”。另外要特别处理“隐含特征”。用户说“四个角上打孔”时实际上隐含了“孔到边距离相同”“对称分布”这些约束。我在提示词里要求模型把这类隐含信息显式化输出为约束字段否则后续建模时孔的位置会完全随机。3. 实操全流程从一句话到可装配的零件3.1 意图解析与参数抽取以我之前做的一个模拟项目“某安装法兰 Demo”为例用户输入的是“做一个圆形法兰外径 60内径 25厚度 8有 6 个均布安装孔孔径 6孔中心距 44外圈倒角 1。”这句话里包含了几个关键信息零件类型是圆形法兰核心尺寸有五个外径、内径、厚度、孔径、孔中心距还有一个隐含特征“倒角”以及阵列信息“6 个均布”。解析成 JSON 大概是{ part_type: circular_flange, outer_diameter: 60.0, inner_diameter: 25.0, thickness: 8.0, features: [ { type: hole, diameter: 6.0, pattern: circular, count: 6, pitch_circle_diameter: 44.0 }, { type: chamfer, edge: outer_periphery, size: 1.0 } ] }这里最值得注意的坑是大模型很容易把“孔中心距 44”理解成“孔分布在半径 44 的圆上”但实际工程语义是“中心距直径 44”。我在后处理里对这类字段做了语义修正如果同时出现 pitch_circle_diameter 和 outer_diameter就校验一下逻辑关系孔中心距直径必须小于外径减去孔径的一半否则提示错误。3.2 代码生成与几何构建拿到结构化参数后下一步是把 JSON 翻译成建模脚本。我用的是脚本化建模内核的编程接口生成的脚本大致长这样import cadquery as cad # 半径计算 outer_r 60.0 / 2 inner_r 25.0 / 2 pcd_r 44.0 / 2 hole_r 6.0 / 2 # 构建法兰主体外圆柱减去内圆柱 flange cad.Workplane(XY).circle(outer_r).extrude(8.0) \ .faces(Z).circle(inner_r).cutBlind(-8.0) # 在外表面上创建 6 个均布安装孔 flange flange.faces(Z).workplane() \ .pushPoints([(pcd_r, 0), (pcd_r * 0.5, pcd_r * 0.866), (-pcd_r * 0.5, pcd_r * 0.866), (-pcd_r, 0), (-pcd_r * 0.5, -pcd_r * 0.866), (pcd_r * 0.5, -pcd_r * 0.866)]) \ .circle(hole_r).cutBlind(-8.0) # 外圈倒角 flange flange.edges(%CIRCLE).fillet(1.0) # 导出 flange.export(flange.step)这段脚本里有几个工程细节需要解释。首先是阵列点的计算6 个孔均匀分布在圆周上角度间隔是 60 度坐标用三角函数算出来。这里如果用“极坐标阵列”内核原语会更简洁但我故意展示手动计算点的写法是因为实际生产中对孔位的相位角有特殊要求时手动推点更可靠。其次是切割方向cutBlind(-8.0)表示沿 Z 轴负方向切穿整个厚度如果写成正方向孔就会落在错误的一侧。最后是倒角edges(%CIRCLE)会选中所有圆形边包括外圈、内圈和孔边这时候必须加额外的过滤条件只选中外圈边否则所有圆边都会被倒角内孔和安装孔边缘也会被错误倒掉。3.3 后处理、校验与导出脚本执行成功并不代表模型是对的。我见过脚本不报错但零件彻底加工不了的情况孔没有切穿、倒角把安装面破坏了、布尔运算留下一堆碎面。所以后处理校验是必需环节我一般做三步几何检查用内核自带的检查工具确认模型是实体solid而非壳体shell检查有没有非流形边。参数检查回到 JSON 参数表逐一核对最终模型的实体体积与理论体积的误差。法兰的理论体积公式是 π × (外径² − 内径²) / 4 × 厚度如果是铸铁材质还能估算质量偏差过大说明建模逻辑有错。干涉检查如果生成的零件要用于装配我会用 STEP 文件在商业 CAD 里做一次装配干涉检查确认孔位和配合尺寸没有问题。导出格式的选择也值得说几句。我通常同时导出两种格式STEP 用于后续 CAD 编辑和装配STL 用于 3D 打印或快速渲染。STEP 保留的是 B-Rep 实体信息能继续编辑STL 是三角网格只能看不能改。4. 常见问题与排查技巧4.1 单位、缺省与语义歧义text-to-cad 最常见的翻车点就是单位问题。英文用户说“a 1-inch bolt”中文用户说“一个 1 寸的法兰”模型如果默认按毫米解析结果会差 25.4 倍。我的方案是提示词里强制要求模型在参数表里附带单位字段如果原文没写单位默认毫米同时在界面上向用户展示解析结果让用户确认单位。还有一个高频坑是“厚度”和“高度”的歧义。法兰盘的厚度 8 毫米用户可能说成“高 8”支架的“高 40”指的是立板高度而不是厚度。大模型经常混淆这两个语义。我在后处理里增加了一个规则对圆形回转体类零件“高度”默认映射到厚度对方形支架类零件“高度”映射到垂直于底面的尺寸。这个基于零件类型的语义映射能大幅减少歧义错误。4.2 几何约束冲突与特征失败几何约束冲突基本上是建模失败的元凶。典型情况包括孔径大于板宽、孔中心距大于板长、倒角尺寸大于板厚、阵列孔的分布圆大于零件外径。这些矛盾在自然语言描述里很容易被忽略用户说“做一个 40 宽的板打个直径 60 的孔”这明显不现实但大模型可能照样生成脚本然后内核报错或者生成一个被切穿的残缺实体。我的处理方法是建立一套“尺寸关系校验表”在脚本执行之前先做逻辑判断。比如孔径必须小于板宽的一半孔中心距直径必须小于外径减去孔径倒角半径必须小于壁厚。一旦校验失败直接返回错误提示给用户而不是继续生成一个坏模型。这个前置校验让失败率显著下降。4.3 脚本稳定性与异常数据大模型生成的脚本还有一个问题非确定性。同样一句话每次生成的代码可能都不一样有时候能用有时候不能。我踩过一次坑生成的脚本里多了一个无用的空操作导致后续的特征顺序错乱模型出来多了一个莫名其妙的凸台。后来我给脚本生成加了一道“模板约束”所有常见零件类型都维护一套经过验证的脚本模板大模型只负责填写参数变量而不是自由编写整个脚本。这样一来代码路径是固定的大模型出错的范围被限制在参数层面稳定性高了很多。4.4 排查流程速查表我把常见问题整理成一张表方便排查现象可能原因处理方式模型尺寸是需求的几十倍单位解析错误英制被当公制检查单位字段强制默认毫米并确认孔没有穿透切割深度正负号写反或深度不足校验 cutBlind 方向与深度符号倒角出现在所有圆边上过滤器选择范围太宽精确指定边类型或面拓扑阵列孔位置不对相位角计算错误或中心距直径半径混淆重点检查 pitch circle 是直径还是半径模型是一个壳体而非实体布尔运算后未合并实体运行实体修复工具重建闭环脚本有时成功有时失败大模型自由代码不稳定切换为固定模板只填参数不生成逻辑某些特征完全缺失自然语言中的隐含信息未被解析调整提示词要求显式输出特征列表这张表不是全量清单但覆盖了我在实际项目里遇到的最主要的几类问题。5. 应用场景与能力边界5.1 现在做得好、做得值的地方目前 text-to-cad 最有实用价值的场景是标准化零件的批量生成。一个设备上往往有几十种规格不同的法兰、垫片、支架、过渡板如果让工程师一个个画要花一整天用 text-to-cad 自动生成配合参数表批量处理几十分钟就能把模型全部产出来。虽然是模拟项目但这个方法在非标设备设计的前期方案阶段非常好用。第二个值得关注的场景是“跨软件协同”。我生成 STEP 之后会在多个不同的 CAD 软件里打开检查发现只要参数解析正确STEP 文件在不同软件之间的兼容性相当稳定。这意味着 text-to-cad 可以作为一个前置模块嵌入现有设计流程而不是替代设计流程本身。教育场景也很有趣。给刚入门三维建模的学生展示“一句话建模”能帮他们快速理解特征参数化思维。学生不需要花大量时间泡在菜单里可以直接看到语义和几何之间的关系。5.2 还做不好的事与改进方向说句实话text-to-cad 目前做不好的事情也很明显。复杂自由曲面依旧是软肋。类似飞机机翼、汽车外饰这类 A 级曲面用自然语言描述根本说不清楚大模型也无从生成。现在只能做规则几何体组合带一点圆角、倒角、放样已经是上限了。多零件装配和配合关系也很难。描述里说“轴和孔过盈配合”模型能生成两个零件但配合公差、装配顺序、约束关系很难一次性表达完整。我实验过生成一个由 5 个零件组成的小装配体结果是每个零件单独看都还行放到一起就出现干涉和间隙不均。目前这个问题没有完美的解法更可行的路线是让 text-to-cad 生成单件模型再由装配模块用传统方式定义约束关系。还有一个方向值得关注把加工工艺知识纳入系统。比如同一个零件用 3D 打印还是 CNC 加工对倒角、壁厚、孔公差的要求完全不同。目前的系统不具备这个判断能力生成出来的模型虽然几何正确但不一定加工友好。让大模型在生成的同时附带“加工建议”标注是后续非常值得做的扩展。最后分享一个我从实践中得到的技巧不要追求“一步到位”。text-to-cad 目前最合适的用法是先让它生成一个“接近正确”的初版模型然后在 CAD 里做精细调整。设计师与其从零画图不如在一个已经 80% 正确的模型上改尺寸和特征效率会高非常多。整套流程跑下来我认为 text-to-cad 不是要取代 CAD 的精确与严谨而是把“需求到模型”这条路上最耗时的前期工作承担下来让设计者把精力真正花在判断和优化上。