text-to-cad最近在设计和制造圈子里热度很高甚至不少非CAD背景的产品经理也在问能不能直接说一句“给我一个带四个安装孔的矩形底座”就拿到STEP文件。我在这个方向摸了一段时间试过从学术开源模型到商业预览版工具踩了不少坑也总结出一些还算靠谱的工作流。这篇文章不打算罗列一堆研究论文摘要而是从一个实际使用者角度聊聊text-to-cad现在到底做到什么程度、哪些环节能真正进入生产流程、哪些地方还只能当灵感辅助。先说结论现在的text-to-cad远没有到“一句话生成可直接上机床的图纸”的程度但如果你把它当成“能听懂工程语言的草图搭档”它已经能帮你省掉大量重复劳动。关键在于理解它的本质——它不是在“凭空捏造模型”而是在“把自然语言翻译成参数化建模操作序列”。想通这一点很多使用误区就迎刃而解了。1. text-to-cad到底是什么从自然语言到特征树的翻译过程1.1 传统CAD建模的隐性成本为什么大家都盯上自然语言传统CAD建模从来不缺效率瓶颈但不是画线画圆那个层面的瓶颈而是“意图传达”的瓶颈。一个工程师脑子里想好了一个零件他得先把设计意图拆解成特征树先拉伸底座、再切槽、然后在特定位置打孔、最后倒角。这个过程需要大量操作更重要的是它要求操作者已经熟练掌握了软件命令。对于熟练工来说可能半小时搞定但对非设计岗位的人比如采购、销售、工艺工程师他们想表达一个需求可能连软件都打开不利索。text-to-cad瞄准的就是这个缺口跳过命令学习曲线直接用自然语言描述需求让AI完成从“语义”到“特征序列”的翻译。这跟我们平时用Midjourney画图完全不同它输出的不是一个像素网格而是一棵能编辑、能参数化、能出工程图的特征树至少理论上应该是这样。我一开始也误以为它是“文本生成3D模型”的升级版用了之后才发现两者的技术路径和产出物有本质区别。文本生成3D模型比如文本转网格产出的是STL或OBJ这类三角形网格适合3D打印、渲染和手办但网格本身没有特征概念。你在网格上没法直接改一个孔的直径也没法把某个圆角半径从R2改成R5。而text-to-cad的目标是可编辑的B-rep实体模型背后是参数化特征——底座、凸台、孔、倒角、阵列这些特征叠加在一起才是设计师真正能用的东西。1.2 核心技术栈拆解LLM只是翻译官几何内核才是地基想快速判断一个text-to-cad工具靠不靠谱就把它拆成两部分看前端是模型理解语义的能力后端是生成几何的能力。目前主流的技术路线大致有三条。第一条是我个人最看好的也是目前学术和开源社区主流的路线让大语言模型直接生成CAD脚本代码。所谓CAD脚本就是用CadQuery、FreeCAD的Python API、或者SolidWorks的宏语言写出的一段程序程序执行后生成几何实体。这条路线的逻辑是既然LLM特别擅长写代码而CAD脚本本身就是代码那为什么不绕过传统的三维引擎直接让模型去写建模代码这是目前实际效果最好的方式因为有大量CAD脚本数据可以训练而且生成的代码天然是参数化的改一个变量就能更新整个模型。第二条路线是“CAD命令序列生成”。这个思路来自DeepCAD这样的数据集——研究人员把用户在真实CAD软件里的操作序列记录下来形成类似“line, sketch, extrude, cut, hole”的指令流然后训练模型从自然语言或点云输入生成这个指令流。它的优点是贴近原生CAD操作缺点是命令序列很容易出微小语法错误而且生成结果往往只是“看起来像”一到具体尺寸和约束就崩。第三条路线是多模态生成模型比如Autodesk的Project Bernini这类研究项目。它直接学习大量三维几何数据试图从自然语言或图片生成功能导向的几何体。听起来很酷但目前公开可用的程度不高生成结果也更偏“形态合理”离工程级精度还有距离。不管哪条路线最终生成几何的时候都绕不开几何内核。大多数开源工具基于OpenCASCADE商业软件用Parasolid或ACIS。你只要记住text-to-cad的质量上限一半由LLM的理解能力决定一半由几何内核处理布尔运算和特征操作的能力决定。模型理解对了但内核算不出来照样出不了活。2. 主流text-to-cad工具横评从开源实验品到商业落地2.1 学术开源方向CadQuery LLM 组合的现状目前在开源社区里最容易跑通的方案就是用LLM生成CadQuery代码。CadQuery是一个基于OpenCASCADE的Python建模库语法相对简洁设计范式就是“用代码定义特征”。你让一个LLM帮你写CadQuery代码本质上就是让AI做一个Python编程任务这个任务的可行性已经被无数代码生成场景验证过了。我实测下来像Qwen2.5-Coder、DeepSeek-Coder这类偏代码的模型在生成简单到中等复杂度的CadQuery代码时成功率相当可观。比如让它写一个带安装孔的L型支架十次里有七次能生成可执行的代码。但一旦涉及复杂曲面、放样、扫掠或者需要精确的草图几何约束模型就容易翻车经常出现草图轮廓不闭合、线段方向不对、或者布尔运算对象不合法之类的错误。学术圈还有Text2CAD这类专门研究工作它们用大型CAD数据集微调模型目标是从自然语言直接生成CAD命令序列。但实话说这类模型目前大多停留在论文演示阶段代码和权重发布不稳定复现成本比较高。除非你是做研究验证否则我更建议走CadQuery加通用代码模型的路线性价比高得多。2.2 商业工具和插件的落地程度哪些值得尝鲜商业领域传统CAD巨头基本都在押注AI辅助建模。Autodesk这边有Project Bernini虽然公开资料偏概念展示但方向很明确多模态生成、以功能为导向的几何生成。SolidWorks近两年也在往AI助手方向靠Fusion 360里也有了生成式AI相关的能力但整体还处于“辅助灵感”阶段距离“你说一句它全自动建好模”还很远。另一个值得关注的方向是API优先的CAD公司比如KittyCAD。它们把CAD能力封装成API开发者可以调用接口完成模型操作再在顶层接大模型做自然语言交互。这种模式的好处是AI只需要负责生成API调用参数几何可靠性由底层引擎保证。坏处是这类服务通常按量收费而且对传统工程师来说有学习门槛。我的建议是如果你是个人设计师或者工程师想体验text-to-cad优先试CadQuery加代码模型的开源组合成本低、可控性强。如果你是企业决策者暂时不必急着上商业方案先让一两个团队跑通流程、验证ROI再选型。目前这个赛道还没有一个能“通吃所有需求”的产品谁先入局都不代表未来格局。2.3 选型对比不同角色该选哪条路线我们可以把使用者分三类对照自己的情况选路线会比盲目追新工具更实际。第一类是非设计岗位的需求提出方比如采购想看某个外协件能不能改型。这类用户建议直接使用在线工具或LLM写CadQuery代码目标是快速得到一个可视化的概念模型用于沟通需求。他们不需要关心特征树规不规范只要能转成STL看看大致形态就行。第二类是机械设计工程师需要的是真正能出图、能改参数的模型。这类用户应该把text-to-cad当成“特征草稿生成器”让AI先搭出80%的特征结构剩下20%的几何约束自己手动调整。第三类是开发者和研究人员想把这套能力集成到自己的产品里那就得认真研究CadQuery脚本生成、OpenCASCADE后处理、以及如何用企业标准件数据微调模型。这三类人对工具的评价维度完全不一样。工程师关心可编辑性和出图精度管理员关心数据安全和部署成本需求方只关心“像不像”。选型前先把角色定位搞清楚后面才不会反复换工具。3. 自己动手跑通一个text-to-cad全流程从提示词到STEP文件3.1 环境准备与模型加载这一步最容易忽略我直接给出一套目前稳定可复现的环境组合跑通之后再根据自己需求调整。操作系统建议Ubuntu 22.04显卡8GB显存起步纯CPU也能跑但速度会慢几倍。核心依赖是Python 3.10以上、CadQuery、以及一个代码生成LLM。安装CadQuery很直接pip install cadquery就行。如果你需要后续在FreeCAD里打开建议同时安装freecad和OCC的Python绑定。LLM这块我有两个选择如果你有API预算直接用DeepSeek-Coder或GPT-4这类闭源模型效果最省心如果要在本地跑Qwen2.5-Coder-7B是一个不错的起点14B效果更好但需要约16GB显存。我个人经验是7B模型硬啃复杂零件会频繁出错写写简单支座、法兰盘没问题复杂的就得14B往上。环境装好后的第一件事不是急着写提示词而是先测试CadQuery能不能正常生成并导出STEP文件。我遇到过很多次CadQuery装好了但OCC版本冲突、导致布尔运算崩溃的情况所以先用官方示例跑一遍导出确认整个链路通顺再开始后面的工作。这个步骤像测量台上的零位校准不做的话后面所有误差都会叠上来。3.2 提示词设计用工程语言说话而不是生活语言text-to-cad的提示词设计和用ChatGPT写周报完全是两个套路。测试中最常见的问题是用户用生活化语言描述零件比如“帮我画一个垫圈中间有个洞周围一圈小孔”这种描述信息量太低了。模型要自己猜垫圈外径、内径、厚度、小孔数量、小孔直径、分布圆直径猜出来的结果大概率不是你要的。我总结出了一套提示词模板用下来效果明显提升。描述必须包含五个要素整体形状、关键尺寸、特征列表、位置关系、以及设计意图里隐含的约束。举个例子一个合格的提示词是“创建外径50毫米、内径25毫米、厚度10毫米的环形垫片在直径40毫米的圆周上均匀分布4个直径6毫米的通孔所有锐边倒角1毫米。”这个描述里“均匀分布”就是位置关系“通孔”说明是贯穿的“倒角”说明需要添加特征。如果你对模型第一次生成的结果不满意不要急着全部推翻重写。更有效的做法是增量修正告诉模型“外径改成60”、“孔的数量改成6个”、“倒角去掉”让它在原代码基础上改参数。大部分情况下模型在你给的代码上做局部修改的成功率远高于重新生成整个模型的成功率。这就像让实习生改图纸你只有把上一版图给他看他才不会跑偏太远。3.3 生成到后处理代码执行、异常处理与格式转换提示词准备好之后把任务交给模型得到一段CadQuery代码。接下来别直接盲信这段代码先人工过一遍关键点草图是否闭合、是否用了合法草图操作、拉伸方向是否正确、有没有明显缺少约束的地方。我见过模型把拉伸方向写成反的导致实体往座位下方突兀地长出去的例子这种问题人工扫一眼就能发现。代码确认没问题后执行生成模型然后导出为STEP格式。CadQuery里非常简单cq.exporters.export(shape, output.step)就行。如果你的下游流程需要STL网格文件也在这一步同时导出。但这里有个关键提醒导出STEP用于CAD编辑导出STL只用于3D打印或渲染不要拿STL当交换格式发给需要改模的供应商那样等于把一个参数化模型退化成了网格对方没法直接改特征。我在这个环节踩过一个坑是单位理解不一致。CadQuery默认单位是毫米但LLM可能会在代码里写出millimeterFalse这类显式转换或者把米当毫米用结果生成一个尺寸大一千倍的怪物模型。解决方法是在提示词里明确写“本工程所有尺寸单位均为毫米”并且在生成后的人工检查里核对最大尺寸是不是在合理范围。光这一步就帮我挡掉了很多次完全不可用的输出。4. 输出质量评估哪些能直接加工哪些只能当参考4.1 几何精度与布尔运算正确性先过这四关拿到AI生成的CAD模型第一件事不是看它好不好看而是做一轮系统性质量评估。我有一套自己的四关检查表按顺序过一遍能筛掉大部分问题模型。第一关是尺寸校验。用CadQuery的bounding box接口读取模型的长宽高和预期尺寸对比。偏差超过1%就要警惕比如你以为外径50结果出来是49.2这种模型没法直接出图。第二关是特征完整性。逐一核对提示词里提到的特征是否都存在孔打了没、阵列到不到位、倒角有没有漏掉。模型经常会出现“只生成了外形但忘了孔”的情况被形似蒙蔽。第三关是布尔运算合法性。如果模型是由多个实体组合而成检查它们是否正确地合并成一个实体而不是像一堆孤岛一样悬浮在空间里。我用cadquery的check那类功能做几何自检。第四关是语义匹配度。这一步需要人眼判断因为它和提示词的意图相关。比如你要求“通孔”结果模型做出来是盲孔那不管几何多干净都不能用。这个四关检查法看起来简单机械但实际上非常有效。原因是text-to-cad目前的失败模式不是“完全不像”而是“局部错漏”。尺寸偏差、漏特征、布尔错误、语义偏离这四类问题占了绝大多数失败案例。与其花半小时在软件里放大抓虫不如用清单快速筛选。4.2 从模型到制造特征识别与工程约束这才是真正的门槛过了四关的模型严格来说离“可加工”还有一段距离主要在工程约束这块。举个典型的例子模型可能生成了一个竖壁厚度只有0.3毫米的钣金件几何上完全正确但实际加工时要么模具撑不住要么材料直接变形。CAD模型只管“形状正确”不管你“能不能造得出来”。这就要求人在把模型发出去加工之前做一个可制造性评审。text-to-cad不会自动帮你判断壁厚是否低于极限、圆角是否小于刀具半径、孔间距是否太近导致整体强度不足它只保证“这是一个实体”不保证“这是一个好零件”。另一个容易被忽略的是标准件和公差标注的问题。AI生成的CAD模型里几乎没有公差标注孔径是典型的H7配合还是自由公差它完全无感。如果你要的是精密配合件AI初版模型只能用来定外形公差得靠人在图纸上重新标。这也是为什么我说现在的text-to-cad没法直接替代工程师的原因之一它生成的是“几何毛坯”不是“工程成品”。但这不意味着它没用。反过来说正因为AI可以在几分钟内生成一个几何合理、尺寸可调的初版模型设计师的工作重心就可以从“从零搭形状”转移到“评审、改公差、做可靠性分析”这其实是更值钱的部分。用一句话概括就是AI负责量人负责质。这个分工在未来几年内应该不会改变。5. 把text-to-cad真正用进工作流参数化与AI协同的实战思路5.1 让AI生成参数化特征而不是一次性死模型text-to-cad要想在生产环境里产生价值关键不是让它“一次性生成终极模型”而是让它生成“参数化模板”。什么叫参数化模板就是模型的所有关键尺寸都由变量控制你改一个变量整个模型的形态随之更新。CadQuery天然支持这种做法代码里定义base_length 50后面所有引用都基于这个变量改这一行就能更新整个零件。在实际操作中我通常这样引导模型明确要求它“将外径、内径、厚度、孔数、孔距分别定义为变量并在代码开头集中声明”。模型一般能理解并照做。这样一来生成的模型就从“一次性死模型”变成了“可复用模板”下次遇到类似零件改几个变量就能交付初版。这里有一点经验参数声明越靠前、越集中模型越不容易在后续代码里写出互相矛盾的数值。如果你让一个变量在代码中间突然出现后面的计算就很容易对不上。我还习惯让模型给每个变量写注释标注含义和允许范围。这一步看起来无关紧要但是在模型需要被同事接手或者被另一个AI修改的时候价值就放大了——好的注释就是给未来接手者定向描述的提示词。5.2 与传统CAD软件打通脚本化和API是关键很多人担心的一个问题是AI生成的是CadQuery模型但我的团队用的是SolidWorks或Fusion 360怎么接上坦白讲目前没有完美的直接打通方案但有几种变通方式我实测过可用。最实用的是“STEP中转”模式。CadQuery模型导出为STEP文件后可以导入到任何主流CAD软件作为“无特征历史”的实体模型使用。虽然导入后特征树是空的但你可以基于这个实体做进一步建模、装配、出图、仿真。对于概念评审阶段这个模式完全够用。第二个方案是用FreeCAD作为中间层FreeCAD的Python API很灵活能导入STEP后重新识别部分特征。不过自动特征识别在行业里一直是难题效果不稳定别抱太大期望。第三种是走商业API路线比如之前提到的KittyCAD它本身就是API优先的设计AI生成的调用参数会直接在其生态里变成可编辑的模型前端再自研界面就能包一层产品。我觉得最合理的未来趋势是CAD软件本身会长出AI入口像SolidWorks、Fusion 360已经在做类似尝试未来用自然语言操作特征树会越来越原生。到那个时候“打通”就不再是个问题了因为AI已经被内置在软件环境里。现阶段STEP中转是投入产出比最高的过渡方案。5.3 人机协同模式AI出多方案工程师做决策用了这么久text-to-cad我最大的心态转变是不再指望它一次生成完全符合预期的模型而是利用它的“低探索成本”特性在设计前期快速铺开多个备选方案。过去让一个结构工程师在半天内提出三种不同结构布局是很奢侈的事但现在可以让AI在半小时内生成六个不同形态的初版方案工程师从中挑出两个有潜力的再结合强度分析、工艺评估去精细化。有一类工作我特别推荐这种模式非标设备底座、夹具主体、简单壳体。这些零件结构相对规则特征不会太多但形态上可以有明显差异比如加强筋布局、孔位排布、外围形状的不同排列组合。让AI生成五六种变化每一个都基于同一套参数模板然后用视觉和简单的干涉检查快速初筛这比我手动一个一个改快得多。等到选定方向后再把人力和时间投入到该方案的深加工里效率和质量的平衡会很舒服。这套“AI批量出方案、人挑方向”的协同模式是我觉得当前text-to-cad在工程场景落地最靠谱的姿势。它不需要AI达到“全自动设计”的水平只需要它做到“无痛产出初稿”就已经能实打实提效。6. 踩坑实录我在text-to-cad实践中遇到的典型问题与排查链路6.1 语义歧义导致的几何错乱光是措辞就能让你白干一下午我遇到过最离谱的事情是让模型“在一个圆柱顶面上创建一个矩形凸台”它给我生成一个从圆柱侧面长出来的矩形。仔细复盘提示词才发现问题出在“顶面”这个语境模型理解的“顶面”跟我们工程上理解的“圆柱顶面”完全不是一回事它可能把“顶面”理解成“圆柱的上方区域”结果默认对齐方式出了问题。这类语义歧义在text-to-cad里远比在通用对话里危险因为模型一旦理解错了生成的几何还是完全合法的、看起来没什么毛病的你如果不仔细检查根本发现不了。排查这类问题我的做法是定位到具体特征让模型解释它的对齐方式和位置参考面然后逐条核对我的原始描述和模型理解的偏差。如果发现“顶面”这种词太模糊就改成“与圆柱上表面对齐凸台底面与圆柱顶面共面”这种明确带共面和参考面的说法。一句话能避免的坑绝不要靠后期检查来兜底。6.2 单位、坐标系和公差三个机械行业特有的暗坑如果你是从3D生成领域转过来用text-to-cad最容易踩的单位坑我已经在前面提到了这里补充一个更隐蔽的坐标系问题。CadQuery的默认坐标系是世界坐标系原点在绝对零点。但AI在建模时经常主观地设定一个局部坐标系然后“忘记”把模型移回原点。结果是生成的模型虽然形状正确但放置在离原点十万八千里的位置后续装配、对齐全乱套。排查坐标系问题时第一件事就是看bounding box的坐标范围。如果一个模型的中心点距离原点太远或者出现把实体放到负Z区这种不正常的现象直接在代码里增加“将模型平移到原点”的操作。这个操作加在CadQuery里很直接找实体边界算出中心然后整体平移。我吃过几次亏之后现在已经习惯把“输出前确保模型中心在原点上”作为固定检查项。公差就更不用说了这是AI目前完全无感的东西。CAD模型本身不带公差信息STEP文件里如果手工添加了公差标注那也主要是用来看的。打印出来的图纸、CMC工艺卡里需要的公差配合还是得人来做。我在与AI协作时会把公差标注排除在AI责任范围之外明确划分“AI只管几何人管公差和工艺”这个分工能有效避免无谓的返工。6.3 复杂装配体和token限制与逐步分解策略最后一个坑是很多人在把text-to-cad用到复杂零件时撞得头破血流的原因——大模型根本吃不下整个装配体的完整描述。一个包含十几个零件的装配体如果妄想一次性用自然语言生成要么触发上下文超限报错要么模型生成到一半就开始记混零部件之间的关系输出一个结构混乱的大杂烩。我现在的策略是“先分件后装配”。把一个装配体拆成若干个独立零件每个零件单独用text-to-cad生成、单独校验最后统一导入CAD软件做装配约束。这个过程看起来多花了一道工序但实际更省时间因为每个零件的生成模型只需关注单一目标成功率大幅提升。还有一点经验是生成装配体零件时要在每个零件的提示词里提醒“与其他零件的配合尺寸保持一致”比如几个零件共享的孔径、轴径写清楚相同值这样才能保证最后能装得上。否则每个零件都“看似合理”一装配立刻穿帮。总而言之text-to-cad的使用不是“问一嘴就完事”而是一套需要通路设计、提示词工程、后处理校验、人机分工相互配合的完整工作流。它现在还取代不了工程师但绝对是一个值得投入时间去掌握的新杠杆。我个人的体会是工具选型不用追求最新最贵先把CadQuery加代码模型这条开源路线玩熟你对text-to-cad的能力边界会有一个非常清晰的认识。这个认识比任何宣传材料都值钱。等你摸清哪些场景它能扛住、哪些场景它必翻车之后再决定要不要引入商业方案会从容很多。最后分享一个小技巧给模型生成的代码建一个“历史版本库”。每次生成、修改、成功落地的代码都按零件类型归档下次遇到相似需求时直接把旧代码作为参考给LLM让它做增量修改。我试过这种“以历史代码作为上下文”的做法成功率比从零描述高出不止一个档次而且日积月累下来你就拥有了一套自己的私有人CAD模板库。这可能是text-to-cad最被低估的价值。