1. 为什么text-to-cad在一夜之间从玩具变成了刚需先聊个实际的场景。我前阵子帮朋友做一批非标零件的三维建模对方给的需求只有一句话“一个能卡进42mm标准铝型材槽里的直角连接件厚度4mm带两个M6沉头孔。”放到过去我得打开CAD软件建草图、约束尺寸、拉伸、打孔、倒角一套流程走下来快则半小时慢则一小时。但那天我直接把这句话扔给了一个text-to-cad流程几分种后STEP文件就出来了尺寸分毫不差直接丢进切片软件和数控编程都行。这就是text-to-cad的核心价值用自然语言描述三维对象让系统自动完成从语义到几何的转换。它不是一个单一软件而是一套方法论和技术栈的组合。对我这种经常要在“脑子里的想法”和“能加工的文件”之间来回倒腾的人来说它相当于把过去那套“软件操作语言”换成了“人类语言”门槛降了一个量级。这个方向之所以在最近两年突然爆发有几个关键推力。第一大语言模型的代码生成能力成熟了它们不再只是“聊天”而是能稳定输出结构化的、可执行的建模指令。第二程序化建模生态攒够了家底CadQuery、OpenSCAD这类用代码描述几何的工具已经非常可靠过去十几年积累的函数库、社区案例都是现成的训练语料。第三工业界对“快速验证概念模型”的需求越来越强传统CAD重交互、重精度但在早期设计阶段往往只需要一个能表达设计意图的粗模型text-to-cad刚好补上这个空档。这套东西适合谁我觉得分三类。第一类是机械工程师和结构设计师用来快速生成标准件、辅件、工装夹具的初版模型。第二类是产品设计师和创客脑子里有想法但没有系统学过CAD软件用自然语言就能把想法变成可打印、可加工的模型。第三类是搞自动化的人想把“自然语言需求”接入参数化设计流水线批量生成系列化零件。需要说明的是现在的text-to-cad并不是万能的。它擅长的是结构相对规则、参数清晰的机械零件对于自由曲面、有机形态、复杂装配体还有很长的路要走。但如果你做的恰好是“规则几何体为主”的领域它已经能实打实地省下大量时间。2. 三条技术路线到底该押哪一条text-to-cad不是一个算法搞定一切目前业内探索的路线大致分成三类。看懂这三条路线的差异你才能判断手里的需求到底适不适合它以及遇到问题该往哪个方向排查。2.1 直接生成网格或隐式场画面好看精度难控这条路走的是“文本到3D生成”的老路代表方向是各类扩散模型和NeRF/SDF变体。你输入“一把椅子”它直接生成一个三角网格文件长得还挺像回事。问题在于这种结果本质上是“看起来像”的几何不是“能制造”的几何。网格是离散的没有参数化特征树没有尺寸标注更谈不上约束关系和可编辑性。我实测过几个开源模型生成一个花瓶、一只猫的摆件确实惊艳但一旦要求“这个法兰盘外径80mm、内径40mm、厚度8mm、均布6个螺丝孔”它就崩了。不是偶尔崩是大概率崩因为这类模型根本没有理解“mm”和“均布”的能力它们学的是形状分布不是工程语义。所以我的判断是这条路线适合视觉预览、概念展示、游戏资产这类“不需要精密制造”的场景离CAD意义上的“设计”还很远。如果你只是想快速看到一个大致的形态可以玩如果目标是出加工文件趁早换路线。2.2 生成CAD命令序列学术界的宠儿落地还差点意思第二条路线是让模型直接输出CAD软件的原生命令序列比如草绘的线段、圆弧、约束、拉伸操作。学术界很多工作走这个方向比如MIT的Text2CAD就是用控制流和几何参数生成带序列结构的CAD命令再用AutoCAD的脚本接口重放。这条路的优点在于生成的模型保留了完整的历史记录和特征树理论上是可以回到CAD软件里继续编辑的。而且基于原生命令尺寸精度可以得到保证——因为命令本身是带参数的比如“画一条从(0,0)到(100,0)的直线”。这个语义足够精确LLM能生成代码自然也能生成这类序列。但实测下来有几个痛点。第一不同CAD软件的命令体系差异太大AutoCAD的脚本、SolidWorks的宏、Fusion 360的API完全是三种东西模型训练时只能绑死某一个平台可迁移性差。第二命令序列的调试成本高一旦中间有一句命令的坐标或约束逻辑出错整个模型就是坏的而且你无法像看代码那样快速定位。第三工业场景里CAD模型最终要进入装配、仿真、CAM流程命令序列生成的结果往往缺少数模里常见的命名属性和材料信息。这条路线我会持续关注但短期内不太适合个人或小团队直接拿来搭生产工具更适合学术研究和平台方做技术储备。2.3 生成程序化建模代码目前最可靠的落地选择第三条路线也是我自己目前主用的方案让LLM生成CadQuery或OpenSCAD的建模代码然后在本地环境里执行代码、输出B-rep实体模型。这条路线本质上是“把几何构建问题转化为代码生成问题”绕开了原生CAD命令的封闭性用程序化建模库的开放性来承接LLM的代码能力。为什么这个方案最稳首先CadQuery和OpenSCAD都有明确的执行语义代码写对了模型就一定对尺寸分毫不差。其次代码本身就是可追溯的出错了能看log能定位是哪一行的问题。再次这类库是纯文本生态天然适合被当作LLM的训练语料互联网上有海量案例。最后输出格式是STEP、STL这类工业标准格式后续接CNC、3D打印、仿真都没障碍。我见过有人质疑“这不就是让LLM写代码吗有什么新鲜的”。对本质上确实是但关键在于领域约束。通用代码生成你可以让它写个爬虫、写个排序算法错了改改就行CAD代码生成要求模型同时理解几何语义、参数约束和制造可行性这是三维空间推理能力不是两行print语句能比的。这几年LLM在这方面的能力提升非常明显生成的建模代码从“能跑但很丑”进化到了“能出图且接近人工习惯”这才让这条路线从理论上走到了实际可用的位置。3. 搭一套text-to-cad最小可用流程从一句话到STEP文件说了这么多直接上实操。我以一个工程师的身份把整个完整流程拆给你看你可以照着搭也可以按自己的需求改造。3.1 环境准备和工具选型我的建议是直接选CadQuery作为建模后端而不是OpenSCAD。原因很简单CadQuery的建模范式是“先选面、再画草图、然后拉伸/旋转/扫掠”这跟传统CAD软件的心智模型高度一致。LLM生成这类代码时的成功率明显更高因为语义空间和人类工程师的思考方式是对齐的。OpenSCAD更偏“CSG布尔运算”代码写起来像拼积木几何一复杂代码就难读。安装也不复杂直接用pip装就行pip install cadquery pip install jupyterlab-cadquery # 可选方便在Jupyter里预览另外需要准备一个可以调用的LLM接口。我自己试过几个模型结论是代码能力强不强不是关键关键是对“几何语义”的敏感度。有些模型在通用编程上很猛但给出“在Y轴负方向一侧开一个槽”这种带空间方向描述的需求时容易搞错坐标系。建议你在选型时拿下面这个例子当基准测试请用CadQuery生成一个长方体长60、宽30、高10在顶面中心挖一个直径20的通孔四角倒半径5的圆角。能一次写对并且尺寸正确的模型才算过了第一关。不同模型的API调用方式不同这里不展开具体品牌核心就是用你顺手的大模型编程接口。3.2 核心执行流程生成、执行、校验、反馈我搭的流程分四步你可以直接复刻第一步把自然语言需求包装成生成提示词。关键不是把用户的话原样丢给LLM而是先做一次“需求结构化”。比如用户说“帮我做个支架能托住一个直径50的圆管”我会在提示词里显式补充圆管中心高度、支架底座尺寸、壁厚、是否要螺栓孔。让LLM补全缺失的尺寸参数比让它猜要可靠得多。这里有个我踩过的坑千万不要让LLM自己给所有尺寸赋值。你要么在提示词里写清楚要么让它输出参数占位符并在代码里统一管理。否则它可能这次生成壁厚3mm下次同一句话生成壁厚5mm模型形态完全对不上。第二步让LLM生成CadQuery代码。提示词里我会包含这么几项任务描述、单位制mm、坐标系约定、输出要求必须返回Workplane对象、禁止事项不允许修改传入参数、不允许数组越界等。效果最好的提示词模板大概是这样的你是资深CadQuery建模工程师。请根据以下需求生成CadQuery代码 需求{user_requirement} 要求 1. 使用公制毫米单位 2. 自底向上建模先用Workplane(XY)创建草图再进行拉伸 3. 尺寸参数集中以变量形式放在代码顶部 4. 最后一行返回最终Workplane对象变量名必须是result 5. 禁止输出解释只输出Python代码这一套下来生成的代码质量会稳定很多。LLM其实非常擅长“照章办事”你约束得越清楚它发挥得越稳定。第三步执行代码并捕获结果。这一步不是在Jupyter里跑一下就完了而是要做一个隔离执行环境。原因很直白LLM生成的代码不是100%安全的哪怕没有恶意也可能因为坐标系算错导致异常或者死循环卡死进程。我的做法是用Python的exec配合超时控制import json from cadquery import exporters def run_cadquery_code(code_str, timeout_seconds30): result {} exec_globals {} try: import signal def handler(signum, frame): raise TimeoutError(代码执行超时) signal.signal(signal.SIGALRM, handler) signal.alarm(timeout_seconds) exec(code_str, exec_globals) signal.alarm(0) result_obj exec_globals.get(result) if result_obj is None: return {status: error, message: 没有找到result变量} exporters.export(result_obj, output.step) return {status: success, output_file: output.step} except Exception as e: return {status: error, message: str(e)}第四步把错误信息或校验结果回传给LLM做修复。这是整套流程里最容易被忽略却最关键的一环。LLM生成的代码第一次跑通的比例我实测大概在60%到70%之间剩下的需要一轮甚至两轮“报错-修复”。做法很简单把执行阶段的异常堆栈或一个自定义的校验结果拼进新的提示词你之前生成的CadQuery代码执行失败错误信息如下 {error_message} 请分析原因并输出修正后的完整代码。就这么一个循环能把成功率拉到90%以上。我的经验是不要指望一次生成就对要把LLM当成一个“会自我修正的实习生”给它反馈路径它就能越改越准。3.3 一个完整的实测案例拿我们公司最近做的一个零件举例子。需求是“一个用于固定传感器支架的L型连接板水平面长80、宽50垂直面高60板厚5水平面上开两个直径6.5的通孔孔距40对称分布”。我给LLM的提示词就是上面那个模板它生成的代码大致长这样import cadquery as cq length 80 width 50 height 60 thickness 5 hole_diameter 6.5 hole_spacing 40 result ( cq.Workplane(XY) .box(length, width, thickness) .faces(Z) .workplane() .pushPoints([(-hole_spacing/2, 0), (hole_spacing/2, 0)]) .hole(hole_diameter) .faces(Y) .workplane() .center(0, thickness/2) .box(thickness, height, width) ) result result.faces(Z).workplane().center(-length/2 thickness/2, 0).box(thickness, height, width)第一版代码其实有个问题第二个box的位置偏移算错了导致垂直面没有和水平面的边缘对齐。执行出的模型我看着别扭把错误反馈回去之后它重新计算了坐标补了一句center来修正。最后一连导出STEP在FreeCAD里打开确认尺寸完全正确整个过程五分钟搞定。4. 实测翻车记录那些看似没问题却暗藏坑的案例只有跑过足够多的坏例子你才知道这套流程的边界在哪里。我把这半年实测中反复踩过的坑整理出来每个都是真实教训。4.1 尺寸单位错误AI以为你在说英寸有一次我让LLM“做一个直径1的圆盘”它毫不犹豫生成了半径1英寸也就是25.4mm的零件。我的预期是1mm结果模型尺寸差了25倍。这种错误在纯文本交互下极其隐蔽因为在提示词里你没提单位LLM就会按训练数据里的统计习惯来——而英文语料里inch的使用频率非常高。排查链路发现模型尺寸不对后我先查了代码里的数值没看出问题。再查导出的STEP文件的全局属性发现单位元数据写的是inch。最后才定位到是LLM在生成时默认采用了英制。解决办法很简单在提示词里强制加一条“所有尺寸默认单位为毫米禁止使用英寸”并且在代码执行前做一次数值边界检查——凡是超过1000mm的尺寸都弹警告因为大部分我做的零件不可能超过一米。边界检查这步非常值等于给尺寸错误装了一道保险丝。4.2 草图参考面选错模型看起来对方向上全反CadQuery建模里一个经典问题是参考面的选择。我让LLM生成一个“左侧开槽的基座”它给出的代码把槽开在了右侧。从代码语法上看完全没错faces(X)和faces(X)的语义它理解反了导致镜像翻转。这种问题反馈给LLM时也很容易踩坑——如果你只是说“方向反了”它可能改一次还是错的因为它没搞清楚到底“反”在哪根轴上。排查链路我后来总结了两个办法。第一个是在提示词里明确坐标系约定“X轴向右Y轴向上Z轴指向观察者X代表左侧面X代表右侧面其余轴类推。” 第二个是让LLM在代码注释里写出每一步的空间推理过程。加注释这个技巧是从一个老同事那学的他说“让AI解释它的几何推导比直接改代码更容易暴露逻辑漏洞”。实测下来确实如此LLM在强行写注释时往往会发现自己方向搞反了。4.3 参数化形同虚设改一个尺寸关联全崩text-to-cad一个很大的卖点是可以反复调整参数——你改一个长度其他特征应该跟着变。但LLM生成的代码经常是“一次性筷子”所有尺寸都是硬编码字面量没有变量之间的约束关系。比如你把一个板子的长度从80改成100上面开的孔距还是40看着没事但你如果把宽度从50改到20原来按绝对坐标写的孔位就跑到了板子外面。排查链路这个问题的根源在于LLM默认生成的是“数值计算代码”而不是“参数化设计代码”。修复方法是提示词里增加一条要求“将关键尺寸定义为变量并显式表达特征之间的位置依赖关系例如孔的中心必须在板子的宽度范围内居中所有定位坐标一律使用变量表达式禁止使用未经解释的魔法数字。” 再加上代码生成后的一轮“参数扰动测试”——我手动把主尺寸改大10%重跑一遍检查是否有特征越界或布尔运算失败。这一步能筛掉至少一半的“伪参数化”代码。4.4 布尔运算与自相交CAD引擎的物理极限CadQuery底层用的是OpenCascade几何内核这个内核很强但对某些病态几何会直接报错或生成破碎实体。最常见的情况是拉伸体之间存在零距离接触面、两个体只共享一条边或一个点、或者倒角半径比壁厚还大。这种错误不是LLM的“逻辑错误”而是几何内核本身的限制。排查链路有一次我让LLM生成一个“中心带十字加强筋的矩形壳体”它生成的代码看着完全合理——先建外壳再建两条垂直的加强筋然后执行union。结果OpenCascade直接抛了一个Type::NullShape异常没有任何说明。我逐行注释代码发现加强筋的高度和外壳内腔高度完全相等两个体在顶部形成了零厚度的共面接触这在B-rep布尔运算里就是临界条件。解决办法是让LLM把加强筋的高度减掉0.01mm留一个微小的间隙。这个经验后来被我固化成了提示词里的规则“凡是需要与另一实体合并的特征必须避免完全重合的面最小偏移量取0.01mm。” 在此之后这类报错基本绝迹。4.5 输出格式与下游兼容性STEP文件也会“缺胳膊少腿”最后一个坑不在生成端在交付端。STEP文件虽然号称是工业标准但不同格式版本差异不小。CadQuery默认导出的STEP可能是AP203或AP214版本AP203不带颜色和图层信息AP214带一部分。如果你的下游软件或者生产方一定要带颜色属性的STEP默认导出就会“看起来正常但缺信息”。此外有些LLM在生成代码时会把exporters.export的格式参数写成STEP大写CadQuery某些版本会识别为未知格式导致导出静默失败——代码不报错但文件没生成。排查链路这个坑我卡了整整一个下午。确认代码逻辑没错、没有异常但输出目录就是空文件。最后是打了个断点去看exporters.export的返回值发现它抛了个warning被吞了。解决办法是统一封装导出函数固定参数为exporters.export(obj, output.step, exportTypeSTEP)避免LLM自由发挥。同时也建议在导出后加一道“文件非空且大于1KB”的校验防止静默失败造成的后续流程中断。5. 从Demo到工作流让text-to-cad真正在团队里跑起来如果你试过上面这套流程觉得“挺酷但用不上”那说明还差最后这步——把它嵌进真实工作流。一个只在自己电脑上跑得通的demo价值有限能跟团队现有流程配合的text-to-cad才算真正值钱。5.1 模型验证生成不等于正确必须做几何校验LLM生成的模型即使能导出STEP也不代表它就是正确零件。我的做法是加三道校验关卡。第一道是数值边界检查确保所有关键尺寸在合理范围内。第二道是质量属性检查用Workplane.val().Volume()和.Area接口计算体积和表面积跟人工预估的数值对比偏差超过10%就判定为失败。第三道是干涉检查如果这个零件要装到某个装配体里我会把它和相邻零件的STEP丢进一个简单的碰撞检测脚本跑一下看是否交集。这三道关卡最初都是人工做的后来写成了自动脚本。说实话校验脚本的代码量比生成脚本还多但这是保证交付质量不能省的成本。5.2 与现有CAD环境衔接以FreeCAD和Onshape为例目前text-to-cad最平滑的落地方式不是替代主流CAD软件而是作为它们的“前置生成器”。我们的工作流是先用text-to-cad快速生成初版模型导出STEP然后导入FreeCAD或Onshape做微调、出工程图、添加公差标注。整个过程从“一句话到能看得见的实体”压缩在几分钟内而过去这个阶段往往要花半天。衔接过程中有个细节值得说CadQuery导出的STEP模型是“无特征树”的到了FreeCAD里就是一个孤零零的实体没有建模历史。这意味着你没法在FreeCAD里改草图的尺寸只能直接改实体或重新做特征。所以如果你想保留参数化能力建议同时导出CadQuery源文件(.json或.py)在CadQuery里改参数重新生成再同步到下游。这个“双轨制”目前是体验最好的方案。5.3 把自然语言沉淀成团队模板库text-to-cad的另一个隐藏价值是它能帮你把团队的经验沉淀成可复用的模板。我们做了几件事把常见零件类型法兰、支架、壳体、轴套、钣金件的典型提示词模板整理成库把每条模板的约束规则、禁忌项、典型错误案例写成注释把历史生成成功的代码块按特征拆解存成可复用的函数片段。这样新来的同事不需要会CadQuery只需要用自然语言描述需求系统就能基于模板库生成符合团队规范的模型。这个思路借鉴了我们写代码时的做法没人会从零写一个排序函数都是从库里调。同样text-to-cad的提示词和代码片段也应该是一个持续累积的资产库。到现在为止我们已经有超过50个经过验证的模板新零件的生成成功率从最初的70%提升到了95%左右大部分失败案例集中在复杂型腔和螺纹配合这类高难度几何上。6. 下一步会在哪里突破以及如果你想入坑该从哪开始text-to-cad远没到成熟期但它的演进方向已经比较清晰。我根据自己的观察和实测体验梳理了三个值得关注的方向以及给想动手试试的人的建议。6.1 尺寸标注和公差语义的嵌入现在的text-to-cad能把几何形状做对但工程图不只是几何还有尺寸公差、几何公差、表面粗糙度这些制造语义。目前这些信息主要还是靠人在CAD里后补。我预计下一步的发展方向是让LLM在生成模型的同时输出一组与特征关联的制造注释——比如“这个孔径是H7配合”“这个面要求Ra1.6”。这需要LLM对制造工艺有更强的理解能力但一旦打通从设计到制造的链路就真正缩短了。我自己现在已经在提示词里约定如果可以在代码注释中标注关键配合尺寸的推荐公差等级。虽然这些注释还不会被下游软件读取但至少保证了生成代码的人在后续出图时不会漏掉关键公差。养成这个习惯之后因为漏标公差导致的返工明显少了。6.2 逆向生成从已有模型反推自然语言描述有个方向大家聊得少但我认为价值很大逆向的text-to-cad也就是“从STEP文件生成设计说明书”。我们遇到过很多次这种情况——供应商发来一个模型但没有图纸也没有设计意图团队需要反向理解这个零件的功能、拆解它的特征、估算它的工艺成本。如果有一套系统能读取模型并输出“这是一个带有四个M8通孔的法兰外径120高度18建议采用铝合金加工”这样的描述对供应链协同、成本评估、设计审查都是巨大的效率提升。目前这个方向的难点在于特征识别和语义映射但好在现有的CAD库提供了不少基础能力比如CadQuery可以遍历实体的面、边、孔特征只是需要有人把这些底层数据组织成LLM能理解的语言。我自己做过一个粗糙的原型把STEP文件的面、边、孔洞统计信息生成结构化文本输给LLM让它总结成设计意图描述。虽然离“智能逆向工程”还很远但已经能在部分简单零件上蒙对七八成。6.3 多模态输入的融合草图加文本最后一个我认为会明确推进的方向是融合手绘草图与自然语言。你画一个大概的轮廓同时补一句“厚度5孔距20”系统结合两种输入生成精确模型。草图解决的是“形状意图”文本解决的是“尺寸和特征语义”两者天然互补。现有的图像生成模型和关键点检测已经能处理粗略的草图难点在于把草图语义和CAD几何参数对齐。往远了说这可能是设计师最舒服的输入方式——毕竟画草图是设计师的本能打字说参数也远比菜单点击直观。6.4 给想入坑的人的行动路线如果你看完这篇想动手试我给一个务实的路线图。第一步不用一上来就搭完整系统先装好CadQuery用Jupyter手工写几个零件把Workplane、box、circle、extrude、hole这些基础API跑熟。这个阶段的目标是建立“代码如何映射几何”的直觉。第二步把写过的代码丢给LLM让它改参数、加特征观察它改得对不对慢慢摸清模型的脾气。第三步再尝试搭建文中的四步循环流程先接受60%的成功率然后逐步加提示词约束和校验逻辑。最后一步选择一个真实的、重复性高的小零件品类做试点把它彻底跑通再考虑扩大范围。我个人的体会是text-to-cad不是一个“装了就完事”的工具它更像是一个需要持续调教的协作伙伴。你喂给它的领域知识越具体它给你的回报就越稳定。别指望它零成本替代你的CAD技能但如果你愿意花两周时间把流程调顺它替你省下的时间会是长期的、复利的。