1. 从一句话到三维模型text-to-cad 到底解决了什么问题我在 CAD 建模这个圈子里摸爬滚打了十几年从最早的鼠标逐点画线到参数化建模再到现在的 text-to-cad工具链的变化可以说是天翻地覆。所谓 text-to-cad简单说就是你把一句自然语言描述扔给模型它直接给你吐出一个可以编辑、可以导入 SolidWorks 或 Fusion 360 的三维模型文件。比如你说一个直径 40mm、高 60mm 的圆柱体顶部有一个直径 10mm 的圆孔它就能给你生成对应的 STEP 或 STL 文件。很多刚接触这块的朋友会误以为它只是个高级的图块生成器实际用下来你会发现完全不是这么回事。text-to-cad 背后的核心价值在于它将设计意图直接翻译成几何约束关系省掉了中间大量重复性的草图绘制和特征建模操作。对于非专业建模人员来说这是极大的门槛降低对于专业工程师来说这相当于把一个能听懂人话的参数化建模助手放在手边。我最早接触这个方向是因为团队里经常接到一些非标零件的紧急需求客户电话里描述一个形状我要花半小时画出草图再拉伸打孔有了 text-to-cad 之后这个流程被压缩到了几分钟。现在市面上的主流方案大致分为两派一派是基于大语言模型做结构化命令生成再调用传统内核建模典型代表是 Zoo 的 Text2CAD 项目和复旦大学的相关研究工作另一派是直接用神经网络隐式表达生成体素或隐函数场再网格化成可编辑模型比如 AutoDesk 的某些实验性项目。前者生成的是参数化特征树可编辑性强后者生成的是网格模型有机形状表现力好但后期修改麻烦。这篇博文我打算把两派的核心逻辑都拆一拆重点记录我在实际项目中跑通全流程的实操经验、踩过的坑以及一些可以抄作业的参数配置。先交代一下我自己的使用背景我主要用它来生成机械加工零件和简单的结构件偶尔也用来做产品外形的快速验证。我的工作流是 text-to-cad 输出 STEP 文件然后导入 SolidWorks 做尺寸微调和装配。如果你跟我场景类似那这篇文章的实操部分会非常对胃口。2. 整体设计与技术选型两条技术路线的深度对比2.1 命令生成派 vs 几何生成派在我实际测试过的方案里两条路线的差异非常明显先看一张对比表再展开说。对比维度命令生成派几何生成派底层原理LLM 输出建模命令序列传统内核执行神经网络直接预测体素/隐式场输出格式STEP、BREP、参数化特征树STL、Mesh、隐式函数可编辑性强特征可回溯修改弱网格模型修改困难几何精度高符合 CAD 内核精度低受限于网格分辨率擅长形状规则机械件、拉伸旋转特征自由曲面、有机形态代表项目Zoo Text2CAD、复旦 Text2CADDreamFusion、AutoSDF命令生成派的核心思路是把自然语言先解析成操作序列。举个例子用户说创建一个宽度 100mm 的矩形底座在四个角上各加一个直径 8mm 的通孔模型会输出类似sketch_rectangle(0,0,100,50)、extrude(10)、hole(8, corner_positions)这样的指令序列然后交给底层几何内核去执行布尔运算和拉伸。这种做法的最大优势是最终模型的参数化信息完整保留在特征树里我可以在 CAD 软件里直接改尺寸灵活性非常高。几何生成派则不搞什么特征树它直接把文本描述映射到三维空间中的占用概率场然后通过 Marching Cubes 之类的算法提取等值面生成网格。这条路线的优势非常明显几乎不受拓扑结构限制什么古怪造型都能给你生成出来。但问题也同样致命——生成结果经常出现破面、孔洞、非流形边等问题对于需要在数控机床上加工的实际零件这种网格模型不能直接用还得花大量时间做曲面修复。我个人的建议是如果做机械加工件或者有严格装配关系的结构件优先选择命令生成派方案如果做概念设计、外观评审、3D 打印的摆件几何生成派也完全够用。两条路线不是对立关系我现在的项目里就是混着用根据任务性质随时切换。2.2 命令生成派的核心架构拆解命令生成派的技术栈其实可以拆成三层文本理解层、命令映射层、几何执行层。文本理解层目前基本都是拿预训练的大语言模型来做的比如 Zoo 项目用的就是 LLaMA 系列微调模型。这一层要做的事情是把自然语言里的尺寸、形状、位置关系、特征类型抽出来转成结构化的中间表示。以一个直径 40mm 高 60mm 的圆柱体顶部有直径 10mm 的孔为例模型需要正确识别出圆柱体是基础体素、40mm和60mm是约束参数、顶部是参考面、直径 10mm 的孔是布尔减运算。命令映射层负责把中间表示转成一套确定性的建模命令这套命令的语法一般参考 OpenSCAD 或者 CadQuery 的 DSL。我用过的几个方案里CadQuery 风格的命令序列最顺手因为它天然支持参数化一个零件的建模脚本可以复用和调整。命令序列必须是有序的、无歧义的模型还要生成合理的默认值——比如用户没提到圆角半径系统就得按照经验值补一个或者明确不处理。几何执行层就是传统的 CAD 内核OpenCASCADE 是绝大多数方案的选择。执行层把命令序列逐条跑完最终生成 STEP 或 BREP 文件。这里有个关键点文本理解层的错误可以通过命令序列的语法检查发现一部分但语义层面的错误比如把孔的位置从前端放到了后端只有依赖几何内核的合理性校验才能兜底。我在实践中的做法是额外加了一层规则校验零件是否封闭、是否有非流形边、体积是否合理、孔位是否在实体范围内等等。3. 核心细节解析与实操要点从提示词到输出文件的每一道关卡3.1 提示词工程怎么把话说清楚让模型不跑偏文本输入质量直接决定输出质量这条铁律在 text-to-cad 里比任何其他 AI 生成场景都适用。我的经验是一个好的建模提示词需要包含以下信息要素主体形状、关键尺寸、特征位置、特征类型、默认单位、精度要求。拿一个实际例子说明。我第一次用 Zoo Text2CAD 的时候输入的是做一个法兰盘上面有四个螺丝孔生成结果惨不忍睹——模型默认了 100mm 外径孔直接排成了一排完全没有按照圆周均布来理解。后来我调整了写法创建一个外径 120mm、内径 40mm、厚度 12mm 的法兰盘在直径 80mm 的螺栓圆上均匀分布 4 个直径 10mm 的通孔。这一次结果完全正确。这里面的门道在于螺栓圆这个术语。模型训练语料里包含大量机械设计文档螺栓圆的直径这个信息能让模型准确地定位孔的分布位置。如果你只说四个孔均布模型能理解均布的概念但不知道均布在哪个圆周上就会给你安排到外径边缘上去孔壁都快跟外圆切在一起了。另外要注意单位问题。绝大多数开源模型默认毫米如果你说做一个 12 英寸的支架有的模型能正确换算有的模型直接当成 12mm 处理。我的习惯是一律在提示词里显式声明单位比如所有尺寸单位均为毫米。这个习惯养成了之后返工率下降了一大半。3.2 关键参数的调优策略无论是用现成的开源模型还是自建部署几个核心参数对生成质量的影响极大。我整理了一份自己的调参记录。温度temperature直接控制模型输出的随机性。我发现建模任务跟文案生成完全两个路数写文案需要一点随机性让表达更丰富但建模命令序列是确定性任务温度稍微高一点都会导致参数值乱跳。我的建议是将温度设置在 0.1 到 0.2 之间超过 0.5 基本没法看孔的位置、圆角半径这些数值都会出现明显偏差。Top-p 采样阈值建议配合温度一起调低0.8 左右比较安全。这个值控制候选集的大小调低了能避免模型从一些低概率的奇怪操作里采样。我之前遇到过一次模型给长方体加了个球面凹陷就是因为 top-p 调太高让低概率的造型操作混进来了。还有一个常被忽略的参数是最大生成长度max_length。命令序列通常不长但如果设置得太短模型会在生成一半的时候被截断输出一个不完整的建模脚本几何内核执行到一半直接报错设置太长又容易让模型自由发挥编出一些根本不在建模语言规范里的指令。我用下来 512 到 1024 是个合理区间根据命令复杂程度动态调整。3.3 坐标系与特征基准面的约定生成模型时坐标系的选择是个隐藏的坑。大多数 text-to-cad 系统默认以全局坐标系原点为参考生成的零件位置和方向都基于这个原点。问题在于如果用户描述里提到了底面正面左侧这类方位词模型需要正确映射到坐标轴方向。我踩过最惨的一次是一个左右手件搞反的案子——提示词里说凸台在左侧模型默认 X 方向为左但实际装配时 X 对着右边整个零件装不上最后只好镜像重来。我的解决方案是在提示词里直接定义方向以全局坐标系为参考X 方向为零件正面Z 方向为零件顶面底面位于 Z0 平面。这样模型就有了明确的坐标系锚点方位词的歧义大大减少。如果你用的是支持自定义基准面datum plane的系统还可以进一步指定主基准面和参考基准面让模型的定位逻辑更接近手工建模的思维。4. 实操过程与核心环节实现完整跑通一个法兰盘模型4.1 环境搭建与工具链配置我目前使用的方案是 Zoo 团队发布的 Text2CAD 推理框架底层模型是微调过的 LLaMA-2-7B几何内核用的是 OpenCASCADEPython 3.10 环境下运行。模型的推理需要一张至少 8GB 显存的显卡CPU 模式也能跑但速度会慢到让人怀疑人生——我测试过用纯粹 CPU 推理一个中等复杂度的零件耗时超过三分钟GPU 加速后只要八秒左右。部署过程有几个关键步骤git clone https://github.com/zoo/Text2CAD.git cd Text2CAD conda create -n text2cad python3.10 conda activate text2cad pip install -r requirements.txt安装依赖的时候有个坑OpenCASCADE 的 Python 绑定pythonocc-core版本兼容性极差在 Python 3.11 上经常编译失败所以我一直锁定 Python 3.10 版本。如果pip安装卡住建议直接到 conda-forge 频道安装conda install -c conda-forge pythonocc-core7.7.0我用的是 Nginx Gunicorn 把推理服务封装成 HTTP 接口这样团队其他成员可以通过 REST API 提交文本生成模型不需要每个人都配一套 Python 环境。FastAPI 比 Flask 更合适因为它的异步支持能同时处理多个推理请求不会互相阻塞。接口层只暴露两个端口一个接收文本返回 STEP 文件一个接收 STEP 文件返回模型的参数化特征摘要方便下游 CAD 软件使用。4.2 从文本到 STEP 文件分步拆解下面我用一个法兰盘例子走一遍完整流程。假设用户输入的文本是创建一个外径 120mm、内径 40mm、厚度 12mm 的法兰盘在直径 80mm 的螺栓圆上均匀分布 4 个直径 10mm 的通孔外沿倒角 1mm材质为 304 不锈钢。第一步文本进入 LLM 后系统会先做意图识别和实体抽取。这个过程模型内部会先输出一段结构化 JSON包含主实体法兰盘、参数列表外径、内径、厚度、特征列表通孔阵列、倒角、材质标注。我在调试日志里看到过这段中间输出有时候模型会漏掉某个参数比如忘记厚度 12mm这时候就需要在后续的代码里做默认值补齐。第二步JSON 转成 CadQuery 风格的建模命令序列。这一步的代码逻辑大致如下import cadquery as cq def flange_from_text(params): outer_d params[outer_diameter] inner_d params[inner_diameter] thickness params[thickness] bolt_circle_d params.get(bolt_circle_diameter, outer_d * 0.67) hole_count params.get(hole_count, 4) hole_d params.get(hole_diameter, 10) # 创建基础法兰盘轮廓 result ( cq.Workplane(XY) .circle(outer_d / 2) .extrude(thickness) .faces(Z) .hole(inner_d) # 中心孔 ) # 在螺栓圆上打均布孔 for i in range(hole_count): angle 360 / hole_count * i result ( result.faces(Z) .workplane() .polarArray(bolt_circle_d / 2, 0, 360, hole_count) .hole(hole_d) ) result result.edges(|Z).chamfer(1) # 外沿倒角 return result执行这一步有几点要注意faces(Z)是要选中顶面作为下一步的草图平面这是 CadQuery 的典型用法polarArray能精确地在圆周上生成均布阵列倒角要用chamfer如果需要的是圆角则用fillet。第三步几何内核执行命令序列并验证结果。执行完成后系统会跑一遍网格检查检查实体是否封闭、是否有自由边、体积是否为正值、螺孔是否真的穿透了实体布尔减运算是否成功。如果某个孔没有贯穿通常是厚度方向的参数理解错误导致的需要在输入端修正。第四步导出为 STEP 文件from cadquery import exporters exporters.export(result, flange.step, exportTypeSTEP)这一套流程跑下来我的实测时间大概是热启动状态下 6 到 10 秒冷启动重新加载模型权重需要 30 秒到 1 分钟。对于设计验证场景这个速度完全可接受。4.3 复杂场景实战带空腔和加强筋的壳体只做简单的法兰盘体现不了 text-to-cad 的威力我挑一个复杂点的场景说说。有一次团队要快速验证一个控制器壳体要求是外形尺寸 150×100×50mm壁厚 3mm内部有一个隔板把空腔分成上下两层侧面开一个 30×20mm 的矩形散热孔四角有安装柱。这个模型如果用传统方式画我大概需要 20 分钟text-to-cad 生成初始版本只要了 15 秒但后续手工修正花了十分钟。生成的问题出在隔板的理解上——模型把隔板做成了贯穿整个壳体的完整平板但实际上我要的是隔板距离顶部 20mm只挡住下半部分不封顶。这是典型的语义理解偏差模型能理解隔板的概念但精确的位置关系需要额外的位置描述。修正思路是把距离顶部 20mm直接写进提示词同时补充隔板的边界信息隔板四边与壳体内壁贴合。生成结果立刻就对了。这个案例给我的启发是text-to-cad 能理解特征类型和大致位置但精确尺寸关系和贴合关系必须显式声明不能依赖模型的常识推断。5. 常见问题与排查技巧实录踩过的坑和梳理出的排查表5.1 建模失败原因分类与快速定位我用 text-to-cad 跑了大半年遇到的建模失败问题基本可以归结为四类语义理解错误、命令序列错误、几何内核执行错误、输出文件下游兼容问题。我整理了一份排查速查表。问题现象可能原因快速排查方法模型生成了但尺寸完全不对单位被误解或遗漏检查提示词是否显式声明单位孔没有穿透实体特征方向理解错误确认特征是否附加在正确的面上倒角导致实体异常倒角半径过大或位置错误查看几何内核报错信息STEP 文件导入后零件缺失特征导出精度设置不足显式设置导出容差和表面精度生成速度极慢模型在冷启动使用模型预热机制或常驻进程输出文件损坏无法打开命令序列被截断检查 max_length 是否过小快速定位的第一原则是先看日志里的中间表示JSON 和命令序列而不是直接看最终模型。中间表示是翻译结果最终模型是执行结果八成的问题都出在翻译阶段如果 JSON 里信息都对那问题基本锁定在几何内核层面。5.2 几何拓扑错误的修复方案网格模型生成派经常出现非流形边和破面这类问题虽然有自动修复工具但修复参数非常讲究。我用 MeshLab 做修复的经验是先小步长执行删除重复面和合并相邻顶点再检查是否有非流形边。顺序不能反先合并顶点有可能把本来正确的面缝合出错误拓扑先删重复面则可以避免这类问题。如果是生成 BREP 实体时出现了面自相交或者缝合失败OpenCASCADE 的ShapeFix_Shape工具可以救一部分场但严重自相交的模型基本只能重做。与其和内核死磕不如回到提示词层面改描述。举个例子我遇到过提示词里说圆角过渡结果模型在两条不相交的边之间做了圆角导致曲面自相交。把描述改成仅在顶面外沿做半径 2mm 的圆角之后问题迎刃而解。5.3 性能瓶颈与批量生成优化如果你像我一样需要批量生成几十个零件模型逐个推理的效率问题会很突出。我的优化经验有几点开启批处理推理显存允许范围内batch size开到 4 到 8吞吐量能提升 3 倍以上模型预热启动后随机生成几个简单零件作为热身避免每个请求都触发全量计算文件缓存相同或相似的提示词直接复用之前生成的结果用文本的哈希值做文件索引显存不够时用 FP16 半精度推理精度损失对建模任务影响不大但显存占用几乎减半。还有个小技巧生成的 STEP 文件可以在后处理阶段批量去除重复几何体用同胚检测算法和压缩坐标精度。CAD 软件虽然接收小数点后六位的坐标精度但实际加工只需要三位压缩后文件体积能缩小 40% 左右传输和打开都更快。5.4 团队协作与版本管理最后说一个很多人忽视的点text-to-cad 生成的不是图而是参数化描述 几何结果。所以版本管理也要跟代码一样严谨。我现在的做法是每一条提示词和它对应的生成结果都放进 Git 仓库提示词写清楚版本变化的理由。比如v1: 法兰盘外径 150mm 螺栓孔为 4 个 v2: 外径改为 120mm孔增加到 8 个新增螺纹孔 M6这样管理的好处是当某个改版需求来了我可以直接 diff 两个版本之间提示词的差异精确知道是哪个参数的变化影响了最终几何结果。迭代过程变得可追溯这在传统 CAD 里很难做到。还有一个协作上的经验让非建模团队也能安全使用这个工具需要在上层做一层参数白名单保护。比如只允许修改外径、高度、孔位这些参数固定壁厚和材料属性不可改变否则产品经理随便改一句描述生成的模型可能完全不满足强度要求。我在 FastAPI 层做了参数的取值范围校验超出阈值直接拒绝并返回错误信息这样才敢把接口开放给更多同事使用。6. 从发展脉络看 text-to-cad 的未来走向与个人实践感悟扯点个人的判断。我接触过早期的 AI 辅助设计工具也看着 text-to-cad 从一个需要手写一大段结构化指令的科研演示变成了现在这种可以直接对话式生成的实用工具。一个明显的趋势是大语言模型的能力提升直接带动了命令生成派的进步。以前模型理解不了均匀分布螺栓圆沉头孔这类专业术语随着训练语料里工程文档占比增加现在的模型在这些概念上的表现已经相当可靠。另一个趋势是几何生成派正在试图融合参数化思想比如用超网络预测参数化模型的参数张量而不是直接输出网格这样既保留了自由曲面表达能力又获得了参数化的可编辑性。作为每天实际使用它的工程师我最大的体会是text-to-cad 不会替代建模工程师它替代的是那些重复性的、确定性极高的草图绘制和特征创建劳动。设计师的创造性工作——理解需求、规划结构、权衡加工工艺——仍然是不可替代的。工具真正解放出来的是我从机械制图桌面里挣出来的时间让我有精力去思考产品整体架构层面的问题。最后再分享一个实用小技巧把常用零件类型的模板化描述整理成一个提示词库。比如法兰盘模板、支架模板、壳体模板每套模板写下描述格式和参数占位符需要新零件的时候只需要替换关键参数不需要每次都从头写提示词。我用这个方式把 80% 的重复性生成请求都变成了填表操作团队里的非专业人员也能参与到前期的结构仿真验证中效率提升非常可观。这套模板库我一直在维护每次遇到模型理解偏差就顺手补充进模板的注释里迭代了几轮之后现在的成功率已经稳定在九成以上。