先说个直观感受2025年要让我选一个“看起来像科幻片、实际上已经能跑通”的方向我会选 text-to-cad。这东西简单说就是——你输入一句话比如“一个直径30毫米、高50毫米、底部带法兰的圆柱体”系统直接给你生成对应的三维CAD模型文件而不是一张图片。光是这句话本身就值得拆开聊它意味着CAD建模的门槛正在被自然语言撕开一个口子也意味着“AI替代设计师”这句话终于在一个具体到能落地的分支上出现了雏形。这篇文章不聊虚的把text-to-cad背后的核心原理、技术路线、从零复现的完整流程、踩坑记录和工具选型建议一次讲透适合刚接触这个方向、想动手试试的工程师、产品经理以及所有对AI辅助设计感兴趣的人。1. 先搞清楚 text-to-cad 到底在解决什么问题1.1 这玩意儿是干什么的text-to-cad字面意思就是“文本到CAD”。但注意这里说的CAD不是图纸不是渲染图而是可以直接进加工、进仿真、进装配的几何模型。和text-to-image那种“画个大概”完全不同text-to-cad的输出必须精确、可测量、可编辑、可制造——这是一个硬约束问题不是一个审美问题。你可以理解成传统CAD建模是在和软件图形界面交互鼠标点来点去草图画来画去。text-to-cad是想把这个过程压缩成“提需求-拿模型”两个步骤。比如“M6的内六角螺丝总长25mm螺纹长度18mm”“一个内径40mm、外径60mm、厚度5mm的垫片”“四分之一圆弧弯管外径16mm壁厚2mm弯曲半径30mm”这些描述往模型里一扔出来的直接就是可以用的零件模型。从实际体验来看简单的轴、套、盖、支架、法兰这类回转体或规则钣金件已经能做到“描述准确就基本可用”复杂曲面、装配体、带特定公差要求的零件还需要人工介入整理尺寸链。在工业界这东西之所以让人兴奋是因为它直击了一个长期痛点从“脑子里有想法”到“CAD里有模型”这一段是设计流程里最无聊也最耗时的一步。对于非机械设计专业的硬件工程师、结构工程师、创客、甚至采购部门来说看到一张图纸能读懂是一回事自己建出模型又是另一回事。text-to-cad把这个门槛直接削平了。1.2 为什么偏偏是这个时候火起来其实“用自然语言生成模型”这个想法一点都不新鲜CSG构造实体几何三十年前就有了参数化建模、模板库、标准件库这些思路也都是在同一个方向上努力。但为什么2024年下半年开始这个方向突然爆发三个条件同时成熟了第一LLM真的能写代码了。现在的开源模型和商业模型已经不是“接话茬”级别而是能稳定生成几十行结构正确、语法严谨的代码。而CAD建模在程序化层面恰恰可以用代码表达——这就让LLM的能力顺理成章地迁移了过来。第二中间表示选对了。过去做text-to-cad很痛苦因为想让AI直接输出一个CAD内核文件比如Parasolid格式或者STEP格式极其困难那玩意儿的底层数据结构和几何算法复杂到连普通开发者都看不明白。但OpenSCAD这类“以代码为建模语言”的工具出现后AI只需要生成套路化的建模代码剩下的几何计算交回给传统内核解决。第三数据对齐了。微软放出过一套名叫Zebra的数据集里面有几万个“自然语言描述 OpenSCAD代码”的配对样本专门用来微调大模型做text-to-cad。再后来国内也陆续出现CAD-CN这样的中文数据集。没有这些数据做地基模型再怎么聪明也只能靠瞎猜。所以总结起来就是一句话text-to-cad不是被某个公司发明出来的新点子而是三条技术线大语言模型、程序化建模、数据集建设在同一时间点汇合后的必然产物。现在下场研究、动手搭流程的人骂声和惊喜都很多但方向确实已经跑通。2. 底层技术路线拆解为什么是“中间表示”的天下2.1 CSG和OpenSCADtext-to-cad真正的技术底座要理解text-to-cad必须理解它怎么把“一段话”变成“一个模型”。最核心的思路是——不直接生成模型而是生成生成模型的代码。这听起来绕但实际操作里是这么跑的输入文本 → LLM生成OpenSCAD代码 → OpenSCAD解释执行 → 输出STL/STEP/3MF模型为什么选OpenSCAD而不是直接用FreeCAD的Python脚本或者SolidWorks的API因为OpenSCAD足够简单。它的建模思路就是CSG布尔运算——把立方体、球、圆柱、多面体这些基本体当成积木用union并集、difference差集、intersection交集组合出复杂形状。一个带圆孔的法兰盘在OpenSCAD里就三行代码的事difference() { cylinder(h10, r25, $fn64); // 法兰盘本体 cylinder(h12, r12, $fn64); // 中心孔 for(i[0:5:90]) rotate([0,0,i]) translate([0, 18, 0]) cylinder(h12, r3.5, $fn32); // 四个安装孔 }这段话的关键在于LLM擅长生成结构紧凑、模式固定的代码序列而OpenSCAD恰好把几何建模压缩成了这种序列。模型不需要理解NURBS曲线、B-rep边界表示、拓扑关系这些硬核几何知识只需要学会“union”“difference”“translate”这些语义明确的动词再把数值填对即可。另一个优势在于可验证性。LLM生成的文本你没法直接判断对错但LLM生成的OpenSCAD代码能立刻丢进渲染器里跑出物理模型跑完还能量尺寸、做截面、导出STL去切片。这让“生成-验证-反馈-修正”的闭环成为可能也让text-to-cad从“随机生成”往“可控生成”走了很大一步。2.2 各家技术路线都在卷什么四大流派对比现在做text-to-cad的团队不少路线也不算统一。我梳理了一下市面上凡是宣称自己做了text-to-cad的项目基本逃不开下面四种技术路线技术路线核心原理代表性工具优点缺点代码生成路线LLM直接输出OpenSCAD/FreeCAD脚本TEXT2CAD微软原型、各种开源Demo精度高、可编辑性最强、能数值精确控制只能处理程序化建模能表达的形状复杂自由曲面基本没戏多模态检索路线文本向量检索已有模型部件组合拼装工业件库/标准件库LLM选型输出永远正确、可靠适合标准品创造力为零做不了全新设计直接生成隐式场LLM/扩散模型直接输出SDF/占用场学术实验性项目居多自由曲面表达能力强输出不是CAD实体没法编辑转换回B-rep极难严重不成熟检索代码混合路线先搜相似模型再代码修改部分商业产品原型既保证鲁棒性又有一定灵活性工程复杂度高目前公开资料少从我的实际体验来说目前真正能“出活”的还是代码生成路线。它先天的优势在于生成的结果是一个真正的文本文件你随时能打开改两个尺寸再重新生成这符合工程师的工作习惯。而直接生成隐式场那种路线虽然学术上看起来很炫但目前离“能用”太远——生成出来的东西既没法标注尺寸也没法导入传统CAD软件做后续处理基本卡在“发给别人看个效果”的阶段。那为什么还会有人卷其他路线因为代码生成路线有一个天花板OpenSCAD这类程序化建模擅长表达的是机械零件、规则几何体遇到汽车A柱、鼠标曲面这种需要自由曲面的外观设计程序化描述会变得极其繁琐且不自然。所以目前工业界比较现实的组合是机械结构件用text-to-cad代码生成外观造型还是要靠细分曲面/参数曲面建模工具。至少现阶段一个开源大模型加上OpenSCAD就是性价比最高的搭建方案。3. 从零复现一个最小可用的 text-to-cad 流程3.1 环境准备与依赖搭建别一上来就做大模型如果读者是想复现一个最简单的端到端流程我建议不要一开始就去动几十B参数的大模型微调。先用现成的API调通全链路确定这条路能走上劲儿了再考虑本地部署、微调、私有化这些事。我这边搭过的最小可用版结构长这样运行环境Ubuntu 22.04 / macOS 均可Windows WSL也行 建模引擎OpenSCAD 2021.01 API模型任意支持Function Calling的LLM推荐 Claude / GPT 系列 渲染验证OpenSCAD命令行渲染 在线CAD查看器兜底 自动化脚本Python 3.10 subprocess调用OpenSCAD装OpenSCAD这一步没什么坑apt直接装就能用Ubuntu下就是sudo apt install openscadmacOS下brew install --cask openscad。注意一点后面需要用到命令行批处理渲染所以不要只装GUI版确保openscad这个命令在终端里能直接跑起来。3.2 核心代码实现最简版text-to-cad全链路下面这一段是完整的核心实现跑通之后你就能对着任意描述生成CAD模型文件了。我把整个流程拆成三个文件第一步将自然语言注入System Prompt这里是关键import json import subprocess import os SYSTEM_PROMPT 你是一个专业的机械零件CAD建模助手。用户会用自然语言描述一个三维零件。 你的任务 1. 理解用户描述的零件结构、尺寸、特征 2. 用OpenSCAD代码实现该零件 3. 只输出一个JSON不要输出任何解释文字 JSON格式要求 { thinking: 简要说明你对该零件结构的理解, code: 完整的OpenSCAD代码只包含代码本身, expected_size: 该零件在X/Y/Z方向上的大致尺寸用逗号分隔 } 建模规则必须严格遵守 - 所有长度单位均为毫米 - 优先使用union()/difference()/intersection()组合基本体 - 如有圆角/倒角需求用$fn参数控制面数并注明面数 - 代码必须能在OpenSCAD中直接运行零报错 - 如果用户描述中存在歧义在你的理解中选择最合理的结构注意这里我把输出强制成JSON格式并且要求模型先输出“thinking”再说代码。这个设计不是为了花哨——实测下来强制结构化输出能显著减少模型答非所问、忘写分号、代码和注释混在一起的情况。第二步调用LLM、解析输出、渲染验证from openai import OpenAI client OpenAI() # 也可以用任意兼容OpenAI接口的本地模型服务 def text_to_openscad(description: str) - str: resp client.chat.completions.create( modelgpt-4o, messages[ {role: system, content: SYSTEM_PROMPT}, {role: user, content: description} ], response_format{type: json_object}, temperature0.2, # 低温度宁可稳定也不要有创意的飘 ) parsed json.loads(resp.choices[0].message.content) return parsed[code] def openscad_to_stl(code: str, output_path: str, stl_path: str): # 保存代码文件 with open(output_path, w, encodingutf-8) as f: f.write(code) # 调用OpenSCAD命令行进行渲染 result subprocess.run( [openscad, -o, stl_path, output_path], capture_outputTrue, textTrue, timeout30 ) if result.returncode ! 0: raise RuntimeError(fOpenSCAD渲染失败: {result.stderr}) return stl_path if __name__ __main__: desc M6内六角圆柱头螺丝总长25mm头部直径10mm头部高度6mm螺纹段长度18mm螺距1mm code text_to_openscad(desc) print(生成的OpenSCAD代码, code) openscad_to_stl(code, screw.scad, screw.stl)这段代码跑通之后你会发现一个很有意思的事实模型生成的代码第一次就能零报错的概率比想象中高不少。我用这个流程测试过五六十个零件描述第一次就能成功渲染的比例大概在七成左右。剩下的三成是OpenSCAD常见的“有语法错误”“逻辑矛盾比如把实体切成真空”“尺寸比例离谱”这类问题详细排查思路放到第4节说。3.3 渲染验证与模型导出垃圾进、垃圾出这里严管出口生成STL只是一个开始。作为工程师你不能拿“看着像”当标准。STL本身是纯三角网格没有尺寸信息没有任何特征树直接拿去做加工的话后续改图非常痛苦。所以完整的text-to-cad流程还应该包含一个“验证-转换-导出”环节。我的建议是验证环节检查三个维度缺一不可几何合法性模型能不能通过openscad --check-parameters这种自检实体有没有退化面比如厚度为零的薄壳用OpenSCAD的openscad -o带--export后缀做一次“干跑”确认零报错。尺寸准确性用OpenSCAD里内置的projection()与resize()函数组合验证尺寸。比如你描述里说“外径60mm”那就把模型投影到XY平面用length()函数量一下轮廓的bounding box尺寸能直接发现模型是否按目标尺寸生成。可制造性这一步最容易被忽略。比如你让模型生成一个“外径60mm、壁厚0.1mm”的圆柱OpenSCAD确实能生成出来但壁厚0.1mm实际加工根本不可行。如果是要做3D打印切片器还会警告“壳体厚度小于喷嘴直径”。所以还得在验证环节加入一个常识性制造约束检查比如“最小壁厚≥1mm”“最小孔径≥1mm”这样的硬阈值。如果最终需要STEP格式给SolidWorks/NX/Creo用实测下来建议再加一步转换把OpenSCAD生成的STL导入FreeCAD用“Part Shape Builder”重建B-rep实体再导出STEP这样能保留可编辑的几何特征。但要注意网格转B-rep的过程损失了大量拓扑信息凡是有圆角、扫掠、复杂过渡面的模型转出来的STEP大概率会出现碎面片基本没法在专业CAD里再做参数化编辑。所以更稳妥的办法是直接让LLM生成可参数化驱动的FreeCAD脚本而不是OpenSCAD——代价是FreeCAD的Python API比OpenSCAD复杂一个数量级LLM生成的出错率会直线上升。自由取舍。4. 实际操作中遇到的坑与解决办法4.1 典型问题速查表真实跑下来text-to-cad远没有论文里那么丝滑。我把这几个月测试遇到的问题按出现频率整理成一张表几乎覆盖九成以上的“第一反应是报错”的情况问题现象根因分析解决思路生成代码语法错误OpenSCAD报Column mismatch模型括号不匹配、分号缺失、函数名拼错在Prompt里加“必须提供可编译代码”的强约束用JSON模式规避代码混入普通文本渲染失败自动让LLM读报错信息自修复一次模型“自闭”生成一个空壳或什么都没有用了difference()但外部包络实体缺失/尺寸太小被全部减掉让LLM在输出前先做“布尔运算边界检查”人工检查代码里difference前的实体尺寸是否比切除实体的尺寸大尺寸严重失真比如给的圆柱高50但生成的高度只有5LLM数值理解不够精确或单位换算错误强化Prompt标注“所有数值均为毫米原值不做缩放”在验证环节用projection()length()回读尺寸同一条件下模型生成结果不稳定LLM采样温度过高或Prompt里没有明确约束建模约束调低温度到0.1-0.3给固定模板减少随机性在system prompt里补充“结构设计应遵循功能优先不做过剩设计”CAD模型无法导出STEP/被下游软件识别为网格体直接导出了STL用FreeCAD的Shape Builder做网格转实体或直接在Prompt里让LLM输出FreeCAD Python脚本模型速度太慢单件生成要等一分钟推理引擎算力不够或模型过大换用量化版本/小参数模型支持流式响应对高频场景用“模板分类局部参数填充”代替全量生成4.2 三个“不做绝对会吃亏”的实操细节第一一定让模型先“说理”再“写码”。上面代码里那个thinking字段不是装饰。实测下来让模型先分析零件结构“这是一个法兰盘中心有通孔外侧有四个均布安装孔”再输出代码代码正确率能从六成直接拉到八成以上。原因很简单多了一步推理链会让模型更仔细地对齐文字里的信息避免信息丢失。但要注意别让模型把思考过程暴露给用户做输出JSON模式里放了个thinking字段展示的时候过滤掉即可。第二渲染报错之后把报错信息扔回给模型让它自己修。这一步是text-to-cad从“玩具”变“工具”的关键。OpenSCAD的报错信息虽然对人不友好但对LLM来说已经算非常清晰了比如“ERROR: Column mismatch”直接指出了行号。我实测的流程是先生成代码→渲染→万一失败→把报错文本拼进去让同一个模型改写代码→再渲染。第二次成功的概率非常可观达到了一半以上。实现上不复杂就是在上面那个openscad_to_stl函数里加个异常处理把stderr拼接进一个新的Prompt再请求一次即可。第三所有自动生成的文件命名上一定带溯源信息。听起来和AI没关系但这是工程化必踩坑。没有溯源的话你会陷入“这个STL到底是哪句话生成出来的”的困惑中。我现在的做法是每次生成都会自动保存一个requests.json里面记录输入文本、输出代码、OpenSCAD渲染时间、是否一次通过、最终导出的STL路径。后续做误差分析、Prompt迭代、模型效果对比时这份记录就是你的金矿。5. 工具选型与能力边界别指望一条路走到底5.1 开源方案和闭源方案怎么选市面上做text-to-cad的工具越来越多摆在面前的选择其实很清晰你要么用大厂的闭源API要么自建开源模型。我从性能、成本、可控性、数据安全四个维度拉了一个实测对比表仅供参考方案性能成本可控性数据安全适合场景商业大模型APIGPT-4o/Claude等最强复杂描述理解力高、自愈能力强按token计费生成一个零件几毛到几块钱低Prompt更新受平台限制数据出域涉密项目不可用快速验证、个人开发、中小公司初期原型开源大模型本地部署如Llama-3.1-8B、Qwen2.5-7B尚可复杂描述和长文本理解力弱一些一次性GPU成本高推理边际成本低中高Prompt完全自控可以Fine-tune数据不出域制造业企业、有保密需求、有GPU投入预算专业CAD厂商内嵌AI如Fusion/SolidWorks的生成式设计模块最强和CAD内核深度集成按年费/订阅收费极高模型直接在CAD特征树里可控取决于厂商生产级场景、需要参数化全链路编辑的团队我的个人建议是如果你还在试探阶段别急着投硬件先花钱用API把整个流程跑起来用一百个零件的测试集去衡量输出稳定性和自己的业务流程匹配度。等数据证明这条路值得走再考虑本地化部署或和CAD厂商的方案做集成。一些厂家的生成式设计模块确实深度绑定了自家内核输出的模型直接用特征树管理这在某些加工场景里是大杀器但这也意味着你被困在了他的生态里选之前要想想船能不能掉头。5.2 什么场景下不该用 text-to-cad这部分说出来可能有点泼冷水但真的是想避免大家走弯路。text-to-cad很好用但它不是万能的。我实测下来下面这些场景现在就别指望它能干活自由曲面外观设计。鼠标、手机壳、汽车内饰这种“漂亮曲线”的产品程序化建模根本不擅长text-to-cad就更不用说了。这些场景需要的是T-Spline、细分曲面、Subdivision建模而不是布尔运算。强行让LLM生成OpenSCAD代码去做自由曲面结果基本是灾难——不是做不出来是做出来的东西丑到没法看。复杂装配体和运动机构。text-to-cad目前基本只能生成零件级几何装配约束同心、平行、相切、自由度、干涉检查这些信息OpenSCAD代码里根本表达不出来。你说“生成一个四连杆机构”有些模型能把零件一个个列出来但装配关系、运动干涉完全无法验证这个方向要等更底层的CAD内核支持才能解决。高精度、高公差要求的精密件。轴承座、齿轮、液压阀块这些动辄±0.01mm公差要求的零件text-to-cad生成出来的模型大概率在尺寸链上就对不齐。这倒不是模型笨而是它的训练数据很难包含那么稠密的公差约束而且“公差”这个信息在自然语言交互里天然是丢失的——哪个设计师会为了每一根轴都打一句“这里直径25h6那里直径30g6”来描述命运多舛的B-rep转换。上面提过文本到OpenSCAD生成的模型本质上还是CSG树而工业CAD的标准数据交换格式是STEP它的底层是B-rep。从CSG转B-rep的过程中圆角、扫掠、倒角特征会大量丢失。如果你下游是要给CNC编程、模具设计用的这些特征丢失就是致命伤text-to-cad目前也就只能出现在方案汇报的阶段。写在最后聊了这么多回到最开始那个话题——text-to-cad到底是不是未来我的观点是这个方向一定会长大但它长出来的样子不一定是我们现在想象的样子。现在最成熟的落地形态是“程序化建模 代码生成”优势是可验证、可编辑、可溯源未来更强的形态可能是“多模态大模型 底层CAD内核深度集成”模型直接输出带特征树、带公差信息的原生文件那时候才是真正意义上的设计自动化。目前如果你手里有硬件产品的开发需求特别是机械结构件占大头的那种我建议认真评估一下那条“自然语言描述 → LLM生成OpenSCAD → 渲染校验 → 导出STL”的链路它已经能承担一部分入门级设计工作了。说句实在话哪天你想设计一个简单的支架、外壳、垫板与其打开CAD软件画半天草图设置约束不如先在聊天框里把需求描述清楚让模型先出一版再由你手动微调——这种“AI打草稿工程师定稿”的工作方式用到顺手之后效率的提升非常明显。