如果你最近在技术社区刷到过text-to-cad这个词那你应该已经感觉到AI辅助设计这个方向正在从看图说话往动手干活转变。text-to-cad的字面意思很简单你用自然语言描述一个零件比如直径50毫米、高度30毫米的圆柱体顶部倒角2毫米它在几秒内给你一个真正可编辑、可导出、可制造的CAD模型而不是一张效果图。这篇文章里我想从原理、技术拆解、落地实操和踩坑记录四个角度把text-to-cad这件事讲透特别适合正在评估要不要入局这个方向的机械工程师、产品设计师、独立开发者以及做AI应用落地的小伙伴参考。1. 先想清楚一件事text-to-cad 到底在生成什么1.1 不是从文本到图片而是从文本到可编辑的参数化特征树很多人第一次接触text-to-cad会拿它和AI生图对比输入一句话输出一个好看的东西。这个类比方便理解但很容易带偏思路。文生图模型输出的是像素矩阵本质是光栅化的猜测放大看细节会糊无法修改某个尺寸也不可能拿去加工。而CAD模型的核心是边界表示B-rep加上参数化特征树一个圆柱不是一个漂亮的截图而是一个圆心坐标、一个半径参数、一个拉伸操作、一个布尔运算记录以及一排可以双击修改的尺寸约束。所以text-to-cad真正生成的是描述如何建模的步骤和参数。它模仿的是工程师在SolidWorks里做特征建模的过程先建草图再拉伸或旋转再倒角或打孔。你要的是一个在原生CAD环境里双击就能改尺寸的实体不是一个PNG。这也是这个方向最迷人的地方它把自然语言直接翻译成了工程语言。用户不需要记住具体命令、不需要知道约束怎么添加只需要说清楚我要一个什么样的东西剩下的是模型帮你完成参数化建模。1.2 一套完整的生成链路一个完整的text-to-cad系统在逻辑上可以分为四段理解第一段是文本理解。大语言模型把你的自然语言解析成结构化意图比如识别出实体类型圆柱、长方体、法兰盘、关键尺寸直径、长度、孔径、特征操作倒角、圆角、阵列、相对位置顶部、中心、偏离10毫米。第二段是CAD序列生成。模型按照建模师傅的习惯输出有顺序的特征操作序列先画什么草图、在哪个平面建草图、拉伸多长、再切掉哪块。这一步输出的往往是一段结构化的代码、JSON或者某个CAD软件API的调用序列。第三段是几何内核重建。用一个真正的CAD内核比如Open CASCADE、Parasolid、ACIS或者FreeCAD、OpenSCAD这种调用内核的应用程序去执行刚才生成的命令序列在内存里构建出B-rep实体生成可显示的模型。第四段是后处理与校验。检查实体是否闭合、有没有破面、尺寸是否合理、能不能导出STEP或STL。这一环节虽然不起眼但直接决定输出物能不能往下游走——能不能3D打印、能不能进CAM编程、能不能被下游工程师接手。把整条链路拆开看就会明白text-to-cad的本质是一个面向几何建模过程的序列生成程序执行问题。它不是单点模型能解决的而是语言模型、几何内核、参数化引擎三个领域的组合拳。2. 核心技术点拆解五个绕不开的环节2.1 文本意图解析把自然语言变成结构化指令这一环节的挑战不在于分词或实体识别这种传统NLP任务而在于把口语化的描述转化成无歧义的建模指令。举个很实际的例子一个带法兰的圆管一边大一边小。这句话里法兰是特征名但到底法兰在左边还是右边一边大一边小是外径渐变还是壁厚渐变不同工程师会给出不同解读。语言模型要做的是结合上下文推断并输出一个带完整参数的结构化结果最好还能附上我做了这些假设。从实践角度我推荐用约束性更强的结构化输出格式来架起语言模型和CAD内核之间的桥。在微调阶段就把目标格式定义为JSON Schema而不是让模型自由发挥写自然语言{ primitives: [ {type: cylinder, radius: 12.5, height: 40, axis: [0, 0, 1], position: [0, 0, 0]}, {type: hole, radius: 3.2, depth: 20, axis: [0, 0, 1], position: [0, 0, 10]} ], features: [ {operation: fillet, target: top_edge, radius: 2} ], assumptions: [外径120毫米, 壁厚5毫米] }这样做有三个明显好处一是输出天然可解析不需要再用正则去猜二是参数有名字下游可以直接绑到CAD软件的尺寸变量上三是模型的选择空间被压缩幻觉发生率明显下降。2.2 CAD序列生成把指令变成特征操作有了结构化意图下一步是生成真正的CAD操作序列。这是目前学术界的重点研究方向也是工程落地里最讲究手艺的部分。生成CAD序列的思路大致有两条路。第一条路是端到端生成直接预测一整个特征操作序列比如草图点的坐标、线段类型、拉伸高度、布尔运算类型。代表工作是基于DeepCAD数据集的各种序列模型。这条路的问题是存在错误累积序列里第10步稍微偏离第30步可能完全失控模型却没有任何自我纠错机制。第二条路是分层生成先把问题分成草绘和特征两个阶段。第一阶段只生成二维截面轮廓第二阶段在轮廓基础上做拉伸、旋转、扫掠等操作。这个思路更贴近人的建模习惯生成的稳定性也更高。实际工程落地时我会优先选择这种两阶段方案因为它允许你在中间插入人工确认先让用户看一下生成的截面草图确认没问题再往下走。无论哪条路最有价值的一点是不要直接生成鼠标点击宏而要生成参数化特征历史——也就是记录特征的依赖关系、尺寸变量和约束条件。这样输出的是一个能被下游工程师重新编排的模型而不是一堆死亡操作记录。2.3 几何内核重建把序列变成实体模型这一环最容易被人忽视但恰恰是决定成败的部分。语言模型生成得再好内核执行不了等于零。几何内核负责的是把你给的二维轮廓旋转或拉伸成一个三维实体处理实体之间的布尔运算计算倒角圆角最后生成可以导出STEP的B-rep数据。目前开源生态里最可用的内核是Open CASCADE它通过FreeCAD、pythonocc等封装提供Python接口是大量text-to-cad原型项目的底层依赖。如果你不想走完整CAD内核也可以考虑OpenSCAD这种程序化建模工具它的脚本本身就是CSG树对AI生成极其友好因为输出和建模几乎一一对应没有特征的隐式依赖解析和重建的难度会低很多。我用下来最顺的组合是语言模型生成结构化的OpenSCAD代码再由OpenSCAD编译成实体。它牺牲了一部分工业级参数化能力但换来了极强的可控性特别适合快速验证想法。2.4 可编辑性与参数化保留前面反复强调可编辑因为这是text-to-cad区别于文生图的核心价值之一。一个真正合格的text-to-cad输出至少要满足打开模型后能看见完整的特征树双击某个尺寸能修改模型可以自动重建修改后不会因为约束缺失而塌掉或报错。这意味着生成时不能只记录最终几何体还得把特征之间的依赖关系写清楚。比如一个带沉头孔的安装板正确的序列应该是先建底板草图→拉伸→在指定位置建沉头孔草图→布尔减除而不是直接生成一个带洞的最终实体。后者就算形状对了修改孔位时整个模型可能就废了。在实操中我会在微调数据里刻意加入参数约束标注比如给每个特征标注范围radius_min、radius_max并在后处理阶段做约束冲突检测。凡是发现某两个特征共享了同一个几何引用却产生矛盾参数宁可放弃重建也不要输出一个看起来对但改不了的模型。2.5 模型微调与数据集text-to-cad不是拿来即用的通用大模型能力而是需要专门微调的方向。你需要的不是让它会说话而是让它懂建模。目前公开可用的CAD数据集主要有DeepCAD大约17万个来自Fusion 360的建模序列、ABC、Fusion 360 Gallery等。它们各有侧重DeepCAD适合做序列生成Fusion 360 Gallery参数化程度高适合做参数约束学习。使用前要仔细看它的格式定义搞清楚坐标系、单位和草图平面约定否则做好数据对齐就够你折腾几周。微调基座模型的选择上如果追求效果可以用强一些的开源基座比如Qwen系列或者Llama系列的大杯型号如果追求推理速度和部署性价比我会优先考虑Qwen2.5-Coder-7B或DeepSeek-Coder这种代码能力强的模型它们生成结构化输出的手感明显优于同等规模的通用模型。3. 实操一条可行的落地路径3.1 准备工作环境与基座模型如果你想动手搭一套最小可用的text-to-cad流程不需要买昂贵的显卡也不用从零训练一个模型。我建议的组合是本地部署一个小规模代码模型负责生成结构化输出配合FreeCAD的Python API完成几何重建。环境准备上你需要以下几样一台至少有8GB显存的GPU机器16GB会更舒服、conda环境、一个开源底座模型我推荐从Qwen2.5-Coder-7B-Instruct起步、用于推理加速的vLLM或llama.cpp以及FreeCAD的Python绑定。如果你不想碰Python重建生态备选方案是用OpenSCAD。它把脚本即模型的理念贯彻得最彻底几乎没有隐式依赖对AI生成极其友好cylinder(r 12.5, h 40, $fn 64); translate([0, 0, 15]) cylinder(r 3.2, h 25, $fn 32);3.2 数据该怎么准备数据质量决定模型质量这个规律在text-to-cad上更加明显。直接拿原始CAD文件喂给大模型是没有意义的必须转化成文本-序列对。具体做法是先从Fusion 360 Gallery或DeepCAD下载模型数据然后从每个模型的特征树里提取出操作序列序列的每一步要么是一个二维草图要么是一个特征操作。再配合人工标注或大模型辅助给每个模型写一句或几句自然语言描述比如直径为25毫米的定位销一端带2毫米倒角。这里有一个关键经验同一批训练数据里描述风格要多样化。不要全部写成型号尺寸公差这种机械手册风格可以加入口语化表达比如普通的圆盖子能盖住直径80的罐子就行。否则模型对人话的理解会比较弱生产环境里输入稍微随意一点就失灵。数据规模不需要贪多。先用几百条高质量数据打通流程验证端到端链路跑通再慢慢扩充到几万条。很多人一上来就想洗百万级数据结果在数据清洗上耗掉两个月模型效果还没比上几千条数据微调的版本。3.3 监督微调的配置建议我建议先用低秩适配LoRA方式做监督微调不要一上来就全参微调。低秩适配的成本低得多而且在生成结构化输出这个任务上效果很有保障。训练配置上以7B规模模型为例我实测下来比较稳的参数是LoRA秩设为32缩放系数设为16训练轮数2到3轮学习率2e-4到5e-4批大小根据显存调整8GB显存可以开到1到2的梯度累积步数。上下文长度不需要太长因为单个零件的建模指令通常不超过2048个token。训练时最好把输入输出都限制在同一套结构化模板里。比如输入统一是请根据以下描述生成CAD建模指令...输出统一是JSON格式。模板的稳定性比让它自由发挥更能压住小模型的幻觉。3.4 推理与后处理重建微调完成后推理阶段可以借助vLLM做批量推理也可以用llama.cpp做单机低资源部署。关键在于把输出直接约束成合法JSON。我建议在采样参数里把温度调到0.1以下关闭top_k随机性这样生成结果更稳定。对工业场景来说每次结果略有不同不是一个特性而是灾难。拿到模型输出的JSON之后接下来就是把JSON翻译成FreeCAD操作。我写过一套很轻的解析器核心逻辑是这样的import FreeCAD as App import Part def build_from_json(data, doc): for prim in data[primitives]: if prim[type] cylinder: cylinder doc.addObject(Part::Cylinder, Cylinder) cylinder.Radius prim[radius] cylinder.Height prim[height] cylinder.Placement.Base App.Vector(*prim[position]) doc.recompute()这样执行完成后一个真正的、可编辑的FreeCAD文档就出来了。你可以继续在上面改尺寸、加特征、导出STEP也可以直接发到Cura或PrusaSlicer准备打印。3.5 一个最小可运行的示例流程为了让你对整个流程有个直观概念我把最简单的一条全流程串一遍输入一句话直径25毫米、高度40毫米的圆柱顶部倒角2毫米模型回复一段JSON脚本解析后调用FreeCAD执行FreeCAD生成一个圆柱实体顶部边缘有2毫米倒角。这个流程看起来简单但它是整个text-to-cad系统的骨架。你以后无论加多少花活——多实体、布尔运算、装配体、阵列特征——都跑不出这个骨架。我的建议是先把这个骨架跑扎实再考虑扩大模型能力和数据规模。4. 常见问题与排查技巧实录4.1 生成的模型有破面或无法闭合这是最常遇到的问题。表面上看是几何内核处理失败但根因往往出在生成的参数上倒角半径大于特征本身的尺寸或者拉伸距离为负值导致拓扑翻转。排查时先不要怪内核而是把生成的结构化输出直接打出来做参数检查。我最常用的是做一组参数合法性校验半径必须大于0倒角不能超过相邻边最小长度布尔运算的两个实体必须有实际交叠。把这些规则提前写进后处理脚本能挡住八成的问题。如果问题已经发生在Open CASCADE层面可以尝试用end-to-end的自动修复工具比如FreeCAD里的Part模块的refineShape功能或者用meshlab对网格做一次修复再重新转为实体。4.2 文本与模型语义不匹配模型生成出来的东西和用户描述的意思不一致这事很常见。本质原因是训练数据里描述和CAD序列之间的语义对齐不够紧密。我自己试过最有效的缓解办法是推理时不再让模型一步到位生成整个模型而是先让它生成设计意图摘要我把它叫作生成前检查点。比如用户说要一个轴承座模型先总结我理解这是一个带底座的圆环结构底座上有四个安装孔然后用户确认之后再生成具体的建模指令。这个二次确认机制改变了使用的心理模型。它把模型从一个一次猜对的压力中解放出来变成先对齐理解再动手干活。实测在复杂零件上这个机制能把满意度从五六成拉到八成以上。4.3 输出参数不稳定同一个描述跑两次一次尺寸正常一次尺寸差一个数量级。这种随机性会让人抓狂。这基本都是采样参数的问题。解决方法是把temperature压到0甚至0.01同时固定随机种子。如果模型本身在同一个种子上输出也不稳定那需要回去检查你的微调数据里是否存在同一描述对应多种尺寸的情况。比如小孔有时候指直径3毫米有时候指10毫米模型就会学得很拧巴。数据清洗阶段最好给每个尺寸概念限定一个语义槽位比如小孔3-5毫米大孔8-12毫米然后人工或自动把训练数据里的描述规范一遍。4.4 单位与坐标系的坑文本里说高度40模型可能默认毫米也可能默认厘米甚至可能因为训练数据里混入了英寸而输出1.574。这个问题如果不统一会让后处理阶段全面崩盘。我的建议是在系统里做一个强制约定所有内部参数一律以毫米为单位所有与用户交互的输入都先经过一个单位解析层。大模型只负责输出无量纲数值单位字段由下游层统一换算。在输出JSON里强制要求带units字段没有units就当非法输出处理让模型重新生成。只要在架构层面把这个单位壁垒设好就能避免后处理阶段的大量灾难。5. 除了自己搭工具生态现状与选型建议5.1 论文与开源项目怎么挑text-to-cad目前还处在快速发展期论文更新很快。看文献时我建议抓三个维度一看它在哪个CAD内核上落地这决定了你能不能第一时间复现二看它的数据是纯B-rep还是带特征历史这决定了生成结果的可编辑性上限三看它的评估指标——不要被形状相似度忽悠要确认它有没有真正在CAD软件里重建成功过。开源项目方面可以先从Text2CAD、ZooKeeper这类知名项目入手。它们分别代表了序列生成和图文CAD生成两个技术流派。你在跑通这些项目的同时重点看它们的数据管线和后处理脚本这两部分往往是工程价值最大的代码。5.2 商业软件里的text-to-cad功能大厂已经在把这个能力产品化。Autodesk、SolidWorks等都在做AI辅助建模的功能方向基本一致让你用文字或者草绘触发一部分建模操作然后由软件帮你完成重复性劳动。目前阶段我的判断是商业软件的功能更适合在已有模型上继续编辑比如帮你添加特征、建议阵列方案、清理草图约束而端到端的新零件生成还是开源生态跑得更快因为研究都集中在开源的数据集和内核上。如果你是在公司内部做技术选型建议两手准备设计端先用开源方案验证效果制造端用商业软件的参数化能力兜底。5.3 我建议的投入方式如果你的核心诉求是快速出成果我给的建议是不要贪大。固定在一个极其狭窄的领域里做透比如只做带法兰的旋转体零件或者只做抽屉滑轨安装板。窄范围不丢人反而能让你在洞悉模型表现之后把每条数据、每个参数都调得明明白白做出一个真正可用的垂直工具。我现在自己的做法并不是把text-to-cad当作一个全自动出图机来用而是把它当作一个参数预生成器设计初期我只需要说出大致方向它给我几个可编辑的参考模型我在里面挑一个最顺眼的继续往下细化。这大幅缩短了从概念到第一版模型的时间而且因为它生成的是参数化模型我可以在它基础上不断迭代不会陷入改不动的死胡同。最后再分享一个心得text-to-cad的核心壁垒不在模型而在数据质量和几何验证闭环。你先问问自己能不能把文本-特征-参数这条链路跑通、能不能自动验证生成结果可制造这两个问题解决了模型本身只是时间问题。手里有闲功夫的话可以先拿一个小模型把前面说的最小流程跑一遍踩过一遍坑之后再回头看这个领域你会发现思路清晰得多。