从我第一次看到 text-to-cad 这个方向的时候我就知道这不是一个“锦上添花”的玩具功能。做机械设计、结构件或者非标自动化的人应该都有过那种体验产品经理丢过来一句话“这里加一个带四个安装孔的底板孔距 50板厚 5”然后你打开 CAD 软件从新建文件开始拉伸、开孔、倒角、标注一步步把这句话变成一个可以出图、可以加工的模型。整个过程不算难但非常枯燥也非常容易出错。text-to-cad 要解决的就是这句话到模型的最后一段距离它直接把人从重复的建模操作里捞出来让你把精力放在真正需要判断和决策的地方。这篇文章我打算用一个做机械结构设计多年的视角把 text-to-cad 的前因后果、实现思路、工具选型和实操过程拆开讲一遍。文章里不会只给你甩一堆名词也不会只贴一个“演示成功”的截图就完事我会把从文本理解到几何生成的整条链路摊开把我实际踩过的坑、试过有效的办法、以及我认为接下来值得继续做的方向都一并写出来。无论你是做 CAD 二次开发的老手还是刚接触程序化建模的新人只要你需要在“自然语言”和“三维模型”之间搭一座桥这篇内容都应该能给你一个相对完整的参考。我把话放前面text-to-cad 的门槛没有想象中那么高但坑也绝对比宣传视频里看到的要多这篇文章就是帮你把这些坑提前填平的。1. 从一段描述到一块实体text-to-cad 到底在解决什么问题先别急着去找现成的模型和代码先把问题本身搞清楚。text-to-cad 的字面意思很直白就是“文本转 CAD 模型”。但我更愿意把它理解成一次建模方式的重构过去我们是通过鼠标和命令行在跟几何内核对话现在则是通过自然语言直接表达设计意图。它和前几年火过的“参数化设计”还不完全是一回事。参数化设计强调的是“尺寸可驱动、模型可复用”但你仍然需要手动搭建那套参数关系text-to-cad 强调的是“意图理解”让机器替你把“我要什么”翻译成“怎么建”。这种重构带来一个非常实际的价值把建模门槛从“会操作软件”降低到“会描述需求”。一个结构工程师可以不用再死磕某个 CAD 软件的冷门命令他只需要说清楚“底部法兰外径 120内径 60均布 8 个沉头孔”剩下的几何构建工作由系统来完成。对于企业来说这意味着新人的培训成本可以大幅压缩老工程师的重复劳动也可以大量释放。但别高兴太早这件事真正难的地方在于自然语言是充满歧义的而 CAD 模型是可度量的精确几何。两者之间存在一个巨大的鸿沟。举个例子“在板的中间开一个孔”这个“中间”到底是几何中心还是某个基准面的投影中点“一个孔”是通孔还是盲孔直径多少公差等级呢这些信息在人跟人沟通的时候可以通过上下文和常识自动补全但机器不会它需要一套机制去处理这种不确定性。这也是 text-to-cad 和普通文本生成任务最大的区别你不能只生成一段“看起来合理”的文字你生成的东西必须能通过几何引擎的拓扑检查必须能量出真实的尺寸必须能导出成加工能识别的格式。所以text-to-cad 本质上是三条技术线的交汇自然语言处理、几何建模、以及数据格式转换。我在后面几节会分别展开。1.1 核心需求解析谁最需要这个东西我给这个方向画了一个粗略的用户图谱。最急需的是非标自动化设备设计领域因为这类设计每天都要产出大量结构相似的钣金件和机加件区别往往只是尺寸和孔位布局整套流程高度可模板化。其次是机械零部件的选型阶段工程师经常需要快速拉出一个大致形状来做装配仿真和干涉检查相对于精细建模他们更看重“出模速度”。第三类用户是教育领域用来教学生理解工程图学学生把读图结果用文字描述出来再生成模型做对比比死记硬背命令效率高得多。还有一个容易被忽略的场景就是通过文本对已有模型做修改。比如你手上有一个旧版本的支架你希望把侧板加高 15 毫米把两个安装孔从直径 8 改成直径 10。在传统流程里你需要找到对应的特征修改草图然后重建。在 text-to-cad 的思路里这类修改可以被抽象成“增量编辑指令”系统解析文本后自动定位特征并完成修改。这个场景的商业价值比从零生成还大因为它直接嵌进了迭代设计的日常流程。1.2 为什么现在才火起来严格来说 text-to-cad 不是什么横空出世的概念。CAD 领域很早就有人研究“用命令流描述几何”AutoCAD 的脚本文件、Pro/E 的关系式本质上都是文本驱动建模。只是那时候的“文本”是固定格式的编程语言不是自然语言。真正把这把火点起来的是大语言模型在代码和结构化输出上的能力突破。模型学会了把“加四个孔均布在直径 100 的圆上”理解成“4 个特征圆形阵列阵列直径 100”并且能直接生成对应的程序化建模代码。再叠加一个基础设施层面的变化程序化建模内核开始以库的形式开放出来。过去你调几何内核得买商业授权、学习一团庞大的 API 文档现在像 CadQuery、OpenSCAD、trimesh 这些开源库已经能覆盖相当一部分 B-rep边界表示建模需求。有了大模型做“翻译”再有了开源内核做“执行”text-to-cad 才真正具备了从论文走向应用的条件。2. text-to-cad 的核心链路拆解如果你准备自己搭一个 text-to-cad 系统或者你只是想知道这东西内部是怎么工作的我建议你把整条链路拆成三个层次来看文本理解层、几何生成层、输出对接层。别指望一个大模型直接从文本输出二进制 CAD 文件那不现实工程上也不会这么干。现在所有可落地的方案几乎都是“模型生成中间表示中间表示驱动内核建模”的分层结构。2.1 文本理解层从自然语言到参数约束这一层负责把用户的描述解析成结构化的建模参数。比如“长 100 宽 50 高 20 的长方体顶面四角倒圆角 R5”文本理解层需要输出一个数据字典大致是基体类型为 box长 100、宽 50、高 20倒角特征为矩形阵列圆角半径 5位置在顶面四角。这里有一个关键选择到底让大模型直接输出参数还是让大模型先写一段代码再由代码生成参数两种路线都有团队在试。直接输出参数的好处是格式稳定、好校验坏处是你得为每一种几何特征设计一套参数模板覆盖面有限。让模型写代码的好处是灵活OpenSCAD、CadQuery 这类库本身已经提供了很丰富的建模原语模型只要生成合法的建模代码即可坏处是代码可能写得对但建出来的模型不是你想要的而且代码层面的错误排查起来比较费劲。从我实际测试的结果看现阶段做项目优先选择“代码生成”路线因为大模型对代码语法的掌握远比对“自定义参数字典”的掌握要成熟。你如果让模型在一堆 JSON 字段里选值它经常会在嵌套层级上犯迷糊但你让它生成 CadQuery 代码它反而能比较准确地调用 workplane、slot、hole 这些 API。这不是因为模型更聪明而是因为这类库的训练语料在开源社区里足够多模型见过的模式足够丰富。2.2 几何生成层程序化建模与边界表述拿到参数和代码之后真正的几何构建发生在这一层。程序化建模的核心思想是“用代码描述建模过程”先建立线、再建面、再拉成体、再在体上做布尔运算。以 CadQuery 为例它内部封装了 OpenCascade 几何内核你写的每一行建模代码最终都会被翻译成内核 API 调用生成拓朴实体。这一层要关注的是几何有效性。模型生成的代码语法可能没问题但几何上可能完全不可用。最常见的是布尔运算失败比如你要在一个实体上减掉一个孔但孔的位置刚好让两个面发生零厚度的接触内核就会报错还有一种是面片翻转生成的 STL 网格法线方向不一致导致切片软件或渲染器把模型当成“破洞”。所以几何生成层绝不能只做“执行代码”这一件事它还要做合法性校验。我自己的做法是在生成层后置一道自动检查流水线先检查实体是否非空再检查体积是否大于零然后跑一遍形状的包围盒确认尺寸落在合理区间最后做布尔求差的“试切”看看有没有退化面。这些检查听起来简单但在批量自动化处理的场景里能筛掉绝大多数坏模型。2.3 输出对接层格式选择决定下游能不能接住CAD 的格式生态非常分裂。工业界通用的是 STEP 和 IGES这是 B-rep 模型的标准交换格式3D 打印和网格处理常用 STL、OBJWeb 端展示则用 glTF。text-to-cad 系统不能只输出一种格式必须根据下游需求做适配。这里有个容易踩坑的点很多开源程序化建模库原生支持的是 STEP 导出但用户最常要的却是 STL。如果你在几何生成层得到的是带精确曲面的 B-rep 模型导出 STL 其实是一个“离散化”过程需要设定弦高误差和角度公差。弦高误差设得太小文件巨大设得太大圆柱面直接变成多边形棱柱。我一般给机械件设 0.01mm 的弦高误差给外观件设 0.05mm这个经验值在大多数场景下兼顾了精度和文件大小。3. 工具选型从零搭一套 text-to-cad 有多少种走法“从零搭一套”这个说法其实有点吓人因为真要完全从零去训练一个能理解 CAD 语义的大模型个人开发者或者中小团队很难扛得住那套算力和数据成本。现实的做法是直接站在已有的模型和库上面做组合。我根据上手难度和落地效果把主流路线分成三种你可以根据自己的基础来选。3.1 路线一CadQuery 加通用大模型的代码生成这是我最推荐给个人开发者和机械设计师的一条路线。CadQuery 是一个基于 OpenCascade 的 Python 建模库API 设计得非常接近“人类思考建模的过程”比如你可以先选择一个面然后在面上画草图再拉伸。这种流程化 API 的好处是大模型很容易学会调用顺序。你只需要把 CadQuery 官方文档里的常用用法整理成提示词的示例大模型就能生成像模像样的建模代码。我在这套方案里踩过一次印象很深的坑。CadQuery 有两个版本分支老版本的 API 和 2.x 版本的 API 差异很大如果你在提示词里混用了两者的写法生成的代码会报一堆属性错误。后来我把提示词模板固定成“只允许使用 CadQuery 2.4 及以上版本的 API”并在示例代码里标明版本号模型的错误率立刻下降了一个档次。这路线的优势是灵活任何能用 CadQuery 表达的形状都能做不管是带复杂孔系的法兰盘还是异形支架。劣势是最终效果的上限取决于模型写代码的水平对于特别复杂的自由曲面CadQuery 本身就不擅长用这条路去硬做肯定是强人所难。3.2 路线二直接用大模型出 OpenSCAD 脚本如果你要生成的模型以“程序化参数化”为主比如各类齿轮、螺纹、建筑结构件OpenSCAD 其实比 CadQuery 更“贴脸”。OpenSCAD 的建模哲学就是代码即模型它自带一套非常简洁的 CSG 建模语言支持基本体素和布尔运算的组合。大模型写 OpenSCAD 的代码往往比写 CadQuery 更少出错因为 OpenSCAD 的语法更接近函数式描述没有那么多面向对象的上下文。但 OpenSCAD 也有一个硬伤它对倒角和圆角这类“圆滑过渡”的支持很弱。如果你要做的零件有很多圆弧过渡、复杂拔模斜度OpenSCAD 会让你建得非常痛苦模型生成出来也经常是一股“低多边形”味。所以这条路线更适合做概念原型和参数化零件库不适合做精细的机械件。3.3 路线三训练专用模型或者微调现有的开源模型这是进阶玩法适合团队手里有大量标注数据并且有模型训练资源。目前开源社区已经有一些专门做过 CAD 指令微调的模型它们在生成 CAD 代码的任务上会比通用模型更稳。你可以在这些模型的基础上用自己积累的模型库做进一步微调让模型学会你们公司的标准件命名规范、出图规范和数据格式。这条路线的门槛不只是算力更多是数据。text-to-cad 的微调数据和普通文本聊天数据不一样它要求“文本描述”和“可执行建模代码”成对出现而且描述里最好带上公差、单位、基准等工程信息。我见过不少团队在这个环节被卡住因为他们的历史图纸很多是二维 PDF根本没有可用的三维源文件建模脚本更是无从谈起。如果你决定走这条路我建议你优先从“参数化模板”类零件入手收集数据比如“法兰盘/支架/底板/轴套”这几类数据量不需要特别大几百个高质量样本就能肉眼可见地提升效果。4. 实操用一句自然语言生成一个带孔法兰盘理论说了不少接下来进入正题。我拿一个最常见的机械零件——法兰盘——来完整演示一遍 text-to-cad 的实操流程。我选这个零件是因为它足够典型有主体特征、有阵列特征、有孔特征难度适中能覆盖住大部分建模需求又不至于像叶轮那样让程序化建模直接崩盘。4.1 准备环境和依赖我的环境是 Windows 11 加 WSL2 的 UbuntuPython 3.11。建议新建一个虚拟环境避免把系统 Python 搞乱。python -m venv cad_env source cad_env/bin/activate pip install cadquery2.4.0 pip install jupyter pip install trimesh这里推荐装 Jupyter因为你会需要交互式地查看每一步生成的中间结果。CadQuery 本身提供了cadquery.vis模块可以在 Jupyter 里直接展示三维预览调试起来非常方便。如果只想在命令行做批量验证那用 trimesh 读取 STEP 再导出 STL 也够用。4.2 提示词怎么写给模型很多人在 text-to-cad 这一步翻车不是因为模型不够强而是因为提示词写得像聊天。你直接丢一句“给我画一个法兰盘”模型大概率会给你一段泛泛的示例代码尺寸全靠猜。正确做法是把提示词写成“结构说明加参数明细”的形式。我用的模板大概是这样的用 CadQuery 生成一个圆形法兰盘模型要求如下 1. 主体为一个外径 120mm、内径 58mm、厚度 15mm 的圆环。 2. 圆环外圈有 6 个均布的安装孔孔径 10mm孔心所在圆直径为 100mm。 3. 法兰端面四个角做 C1.5 倒角。 4. 使用合法 CadQuery 2.x API代码风格参考 CadQuery 官方示例注释写中文。这已经不是一个“提示词”而是一份“规格说明书”。模型收到这种结构化的输入输出的代码质量会稳定很多。你可以理解为大模型在生成代码的时候实际是在做“翻译”它的输入结构越接近目标代码的结构翻译的偏差就越小。4.3 让模型生成代码并执行把上面的提示词发给一个支持代码生成的大模型正常能得到类似下面的代码这会因为模型版本不同而细节各异import cadquery as cq flange ( cq.Workplane(XY) .circle(120 / 2) .circle(58 / 2) .extrude(15) ) flange ( flange.faces(Z) .workplane() .circle(100 / 2) .cb hole(10) .edges(Z) .chamfer(1.5) ) show_object(flange)别急着直接拿去导出先检查几件事。第一模型生成的.circle()里用的直径还是半径CadQuery 的circle()接受的是半径参数如果你在提示词里给了直径 120这里应该写120/2如果模型直接写了120那模型外径就是 240活活大了一倍。第二cb hole还是holeCadQuery 2.x 的新 API 支持cb hole一次完成中心定位和打孔的复合操作老版本里你得分开写。第三倒角选择的面是否正确你要倒的是顶面外圈棱边如果模型对整个外圈都做了倒角侧面棱边也会被削掉一圈视觉上会和你预期的不一样。把这些修正完之后再执行。如果是在 Jupyter 里我会分段运行先生成主体预览再打孔预览最后倒角预览。分段预览能让我在每一步出错时立刻知道问题出在哪个环节而不是等最终导出的模型出了问题再回头倒推。4.4 导出和后处理模型确认没问题后导出 STEP 和 STL。STEP 留给后续结构仿真和加工STL 可以用来快速 3D 打印验证装配尺寸。cq.exporters.export(flange, flange.step) cq.exporters.export(flange, flange.stl, tolerance0.01, angularTolerance0.1)tolerance是弦高误差单位毫米angularTolerance是角度误差单位度。我习惯 STL 的弦高误差控制在 0.01这样圆柱面有足够多的三角面片同时文件不至于爆炸。导出后用 trimesh 快速确认一下模型体积和面数import trimesh mesh trimesh.load(flange.stl) print(mesh.volume) print(mesh.is_watertight)is_watertight为 True 是最基本的要求如果为 False说明 STL 网格有破洞或者非流形边送去 3D 打印大概率会出问题。4.5 优化把标注也顺手加上真实出图不能只有三维模型还得有标注。text-to-cad 的好处是模型尺寸都是参数化的标注信息可以直接从建模参数里提。我在做完法兰盘之后会再让大模型基于刚才的代码生成一份 JSON 格式的关键尺寸表直接对接后端的自动标注工具。这一步的核心价值是让“模型”和“尺寸数据”始终同源改了一处参数标注跟着变不会出现改图忘了改标注的尴尬。5. 翻车记录text-to-cad 路上最常见的四类问题以下是这段实操过程里反复遇到、排查起来最费时间的问题我把它们整理成一份速查清单。每个问题都附带了我自己的排查思路希望能帮你省掉一些弯路。5.1 提示词解析失败模型给出的代码和需求对不上症状模型返回的代码能运行但出来的模型和你的描述明显不同。比如你说“6 个孔均布”它给你写了 4 个。排查思路先检查提示词里是否把数量、位置写得足够明确因为“均布”这种说法在大模型眼里不如“以圆心为基准360 度等间距分布 6 个孔”来得清楚。如果提示词已经明确那就是模型的注意力偏了最简单的办法是在提示词里加一句“先列出你识别到的参数表再写代码”强制模型先结构化理解一次。这个“先列参数表再写代码”的技巧能提升不少的成功率。5.2 布尔运算失败孔打不上、切除没生效症状cut操作抛异常或者最终模型里孔的位置出现残片。排查思路布尔运算失败绝大多数是面重合导致的。比如你用一个孔的底面正好贴在法兰端面上内核就没法判断是共面还是相交。我在 CadQuery 里遇到这种情况会把打孔的工作平面往里偏移 0.001mm人为制造一个微小的重叠量让布尔运算有明确的交集可算。这一点点偏移在公差范围内完全可以忽略但能显著提升布尔运算的稳定性。5.3 参数漂移单位、公差和目标不一致症状生成模型的尺寸单位不是毫米。模型可能给你的是英寸也可能是基于“图形单位”的相对值导入到工程软件里尺寸全乱。排查思路在提示词里钉死单位“所有尺寸均以毫米为单位不允许出现英寸”。另外你自己的检验脚本里加一道体积和包围盒的校验比如法兰盘外径如果小于 110 或者大于 130直接判定为参数错误这样就有一个客观闸门兜底。不要相信模型的自觉要靠校验逻辑兜底。5.4 两次生成结果不一致用同样一句话得到的模型有差异症状同一段提示词第一次生成的外径 120第二次变成 120.5或者孔的数量不一样。这个其实是大模型采样策略带来的固有随机性。排查思路如果你要的是可复现的自动化流程两个办法。第一把模型温度参数调低到 0.1 以下让输出趋向贪心解码第二在提示词里指定“只输出代码不解释”减少模型的自由发挥空间。我实测下来低温度加结构化提示词重复生成的一致性可以大幅改善。需要强调完全一致很难保证所以在批量生成场景里务必在流程里设置几何校验而不是完全信任生成结果。6. 落地过程中我形成的几条经验最后讲几条我在实际项目里沉淀下来的经验不算完整的方法论但至少能帮你在起步阶段少交学费。第一条经验是“先解决 80% 的通用件再碰 20% 的复杂件”。text-to-cad 现阶段对标准件、钣金件、规则机加件的生成效果已经比较能打但遇到自由曲面、复杂装配体、需要大量参考基准的模型效果依然不稳定。做产品规划的时候不要一上来就想着“所有零件都能用一句话生成”那是给自己挖坑。先把法兰、支架、底板、轴套、导轨安装面这类规则件跑通就已经能覆盖相当大的日常工作量。等通用件稳定了再考虑怎么扩展到更复杂的类别。第二条经验是“必须把人工审查嵌入流程”。不管模型生成的代码看起来多合理我在导出 STEP 之前都会做一次人工目检。这不是不信任模型而是因为 CAD 模型的错误往往是“看似正确、实际不可加工”的类型孔位差了一毫米肉眼在屏幕上很难看出但到了装配和加工阶段就是废件。所以我的流程是模型生成加自动校验加人工抽查三层筛子宁可稍微慢一点也要保证出去的模型是能用的。第三条经验跟数据积累有关。每次你修正了一个模型生成错误都应该把“错误输入、正确代码”存下来作为样本。长此以往这不仅是你个人的资产更是以后微调专用模型时最宝贵的数据来源。我自己建了一个简单的表格记录提示词、生成代码、问题类型和修正方案目前已经积累了上千条。很多当时觉得头疼的问题翻回去看的时候规律性其实非常强。text-to-cad 不是一个“装上就能用”的成品它更像是一条需要不断调优的流水线。文本理解、几何生成、格式输出每一层都有各自的坑而你只有亲手跳过这些坑才知道哪些环节需要模型更强哪些环节只需要工程手段就能绕过去。我现在的体会是真正能把这个技术落地的前提不是某个模型参数有多强大而是你对自己要生产的模型有多大把握以及你愿不愿意在它身上投入足够的调试时间。这和我十几年前学三维建模时的心态如出一辙先把最常用的命令练到肌肉记忆再逐步往复杂功能扩展。text-to-cad 也是一样先把最简单的法兰盘、底板跑顺再去追那些复杂的曲面你会发现原来那些“不靠谱的生成结果”很多其实只是提示词写得还不够像一份工程规格书。