做CAD建模这行当的人应该多少都有过这种体验软件里点了半天对话框调完拉伸距离又调倒角半径一个零件还没露雏形几分钟就过去了。如果碰上改图尺寸一联动连带着特征树全得重排脑壳生疼。而最近这一年多AI生成代码和3D模型的能力猛涨text-to-cad文字直接生成CAD模型这个方向突然从实验室里的Demo变成了大家认真考虑的落地工具。说白了就是你对电脑说一句我要一个带四个通孔的安装底板长120宽80厚5四个角倒R10然后脚本自动给你把模型建出来。这篇文章我不打算整一堆论文腔的说教就以实际动手做过的经历为主线把这个技术背后的核心思路、选型逻辑、实操步骤和踩过的坑全部摊开聊。内容适合几类人看一类是做机械设计和产品结构的人想搞清楚AI建模目前到底能干多少活另一类是搞软件和算法开发的想自己搭一个能跑通的最小原型还有一类纯粹是3D打印玩家想让AI帮你快速出个可打印的零件模型。无论你是哪一类看完至少能明白这个技术该怎么上手以及它现阶段哪些事靠谱、哪些事别抱幻想。1. 先搞清楚text-to-cad到底在解决什么问题1.1 传统CAD建模的痛点从画图到写剧本传统CAD建模工具SolidWorks、Fusion 360、AutoCAD这些本质上是让设计师通过GUI交互一步步把几何特征叠加起来。拉伸、切除、倒角、阵列、布尔运算每一个操作都在改变特征树的状态。这种方式的优势是所见即所得但劣势也很明显操作链路特别长而且高度依赖操作者本身熟悉软件。这里有个很关键的类比传统CAD建模很像你在用Word一个字一个字敲排版而text-to-cad相当于你用一句话让Word自动生成一篇带格式的文档。前者自由度最高但效率瓶颈在人后者把意图表达从操作级提升到了语义级效率瓶颈转移到了AI模型的理解能力上。我实际接触的工程师里有不少人建模能力很强但每天花大量时间在做重复性操作——建底板、打孔、倒角、加加强筋这类零件的结构相似度极高但每次都得从头点一遍。text-to-cad真正解决的恰恰是这种结构明确、参数可变的重复劳动。它不是说让AI替代设计师的创造力而是把那些模块化的脏活累活自动包办了。1.2 三类典型场景生成、修改、衍生我把text-to-cad的实际应用场景粗略分成了三类这也是我判断一个项目该往哪个方向投资源的基本框架。第一类是零基础生成。用户给一句描述系统直接输出一个完整零件。比如做一个圆柱体外径30内径24高度15顶端带一圈6个M3螺纹孔。这类场景最适合快速概念验证也是大多数Demo展示的效果。第二类是参数化修改。已有模型已经很接近预期了但某些尺寸或特征需要调整。传统做法是去特征树里改草图约束一旦草图和外链参数脱钩改起来就很痛苦。text-to-cad在这类场景的好用之处在于它生成的模型本身就绑定了一套参数用户只需要用文字提需求把这个孔往右移5毫米内径放大到28AI直接改动对应的几何约束关系。第三类是拓扑衍生。从已有的模型库出发A型号的底座改成B型号的支架本质上就是换参数。输入描述模板引导的模式在衍生零件设计里效率提升最明显。业内叫配置化设计或者变形设计text-to-cad让这个过程的入口变得更简洁了。1.3 为什么这两年会突然火起来坦白讲text-to-cad这个想法并不是2024年才有的早年间就有AutoCAD的Scripting、OpenSCAD这种用代码描述模型的方案而自然语言直接生成CAD其实可以追溯到更早期的专家系统研究。但当时的瓶颈有三个没有足够大的自然语言-3D模型对齐数据集、生成模型的泛化能力太弱、以及没有足够便宜的推理算力来做后端计算。这两年条件变了。一方面LLM已经具备了较强的代码理解和生成能力可以把自然语言映射成合法的参数化建模脚本另一方面开源CAD模型数据集比如ABC Dataset、Fusion 360 Gallery Dataset越攒越多给训练对齐提供了原料。再加上CadQuery、OpenSCAD、Build123d这波代码化建模库逐渐完善让AI生成的脚本能真正被CAD内核解析并输出B-rep实体——于是text-to-cad从读论文让人觉得有戏变成了跑个Demo真能出模型。2. 主流技术路线解析三种方案怎么选2.1 路线ALLM直接生成脚本代码目前最主流、最容易被落地的方案就是让大模型生成一种CAD脚本然后丢给对应的脚本化建模内核去实际执行。比较常见的后端有CadQueryPython库、OpenSCAD自有脚本语言、Build123dCadQuery的升级替代。举个例子用户输入一个40x40x10的方块中心有一个直径12的圆孔四角做R5倒角CadQuery脚本长这样import cadquery as cq result ( cq.Workplane(XY) .box(40, 40, 10) .faces(Z) .workplane() .hole(12) .edges(|Z).fillet(5) ) cq.exporters.export(result, result.step)大模型要做的事情就是把用户那句自然语言准确映射成上面这段代码。这里有个核心逻辑并不是让模型凭空想象一个模型而是让它熟练运用CadQuery这个语言来描述模型。所以这条路线对后端库的稳定性要求很高你选的库是成熟的开源库AI生成的代码才有足够的先验数据可以模仿。这条路线最大的优点是可解释性和可控性。脚本是文本你可以审查、修改、重跑出了问题知道该改哪个参数。而且输出的STEP文件可以直接进入传统CAD生态这在工业环境里非常关键。缺点是模型对尺寸的精确记忆能力有限很容易把12写成21后处理必须有校验兜底。2.2 路线B生成式模型直接输出几何体体素/点云/神经隐式场另一种路线是纯端到端用户文字进模型直接吐出一个体素网格或者点云甚至是一个NeRF/3D Gaussian表示。这条路线听起来更加AI原教旨但实际落地过程中我遇到过很多麻烦。核心问题在于CAD模型在工业里讲究的是精确的边界表示B-rep是参数曲面和边界边而不是一堆点。体素和点云转成STEP格式要么精度损失严重要么根本没法转成可加工的B-rep。你3D打印用个STL图个乐可以但在CNC加工、公差配合面前这条路线远远不够格。不过这条路线在概念草图和形状检索场景仍然有价值。有些团队的做法是端到端先生成一个粗糙形状再逆向拟合出参数化特征。但拟合的过程健壮性不高我是不会把它放进生产管道的最多拿来团队内部做灵感参考。2.3 路线C混合式——LLMCAD库规则引擎说实话真正在工程上能稳定产出的text-to-cad系统九成以上是混合式架构LLM负责意图理解和代码框架生成程序化规则负责约束校验和参数修正最后CAD内核负责精确计算。比如LLM生成了一段CadQuery代码但里面倒角半径是8几何上倒角半径大于壁厚导致内核报错这时候规则引擎就要捕获异常把参数缩到合理范围或者让模型二选一要么减小倒角半径要么增加板厚。这种感知-生成-校验-修正的循环比单纯依赖大模型一次成型的方案要可靠得多。另外一个环节是参数提取。用户说差不多手掌大小的方块LLM要能转化为合理的数值比如90x60x15这其实需要一些先验约束——比如生活场景里手掌大小对应什么量级。我个人的做法是把这类模糊语义到精确数值的映射表放进提示词里让模型参考映射做数值猜测准确率能提高一个档次。2.4 工具选型速查表方案核心依赖优点缺点适合场景LLM CadQuery任意LLM API CadQuery脚本可审可改、STEP输出标准化精确尺寸需校验、生成代码偶发语法错误工业零件、参数化建模、可编辑模型LLM OpenSCAD任意LLM API OpenSCAD脚本简洁、生态成熟OpenSCAD建模能力偏基础复杂曲面吃力简单几何体、3D打印入门件LLM Build123d任意LLM API Build123d更现代的Python API、支持复杂构造文档和社区还在快速变化里复杂参数化建模、科研导向端到端扩散模型专用模型权重可做形状创意、不受脚本语法限制输出几何精度差、无法进入CAD流程概念设计、灵感探索3. 实操过程10分钟搭一个text-to-cad最小原型3.1 环境准备与依赖安装我建议第一次做这个方向的朋友直接从CadQuery起步原因有三语法和自然语言的距离近模型生成的代码可读性好输出的STEP文件可以被主流CAD软件直接打开库本身是纯Python安装调试成本低。pip install cadquery pip install openai # 或其他LLM SDK按你自己的接入方式如果你想本地跑模型也可以用Ollama跑qwen这类开源模型把API地址换成本地端口就行。我实测下来本地小模型在CAD任务上表现远不如商业大模型但做原型验证完全够用。另外强烈建议在Jupyter Notebook里做原型因为CadQuery内置了jupyter渲染插件可以直接在单元格里看3D效果省去导出文件的流程。3.2 核心引擎代码构造一个文字到脚本的流水线先说整体架构。我搭的原型分三个模块意图解析LLM、脚本执行CadQuery、结果校验规则。意图解析把用户输入变成一段CadQuery代码脚本执行把代码跑起来输出实体结果校验检查实体尺寸、体积、拓扑是否合法不合法就把报错信息回喂给LLM再尝试一次。import cadquery as cq import openai import re client openai.OpenAI(api_keyyour-api-key) SYSTEM_PROMPT 你是一名资深CAD工程师,精通CadQuery库。 根据用户的自然语言描述,生成对应的CadQuery Python代码。 要求: 1. 只输出代码,不要任何解释文字 2. 所有尺寸默认单位为毫米 3. 代码必须可以直接执行,不能使用cq.exporters导出 4. 使用result作为最终变量名 5. 优先使用链式调用风格 def generate_cad_code(text: str, attempts: int 3) - str: for i in range(attempts): response client.chat.completions.create( modelgpt-4o, messages[ {role: system, content: SYSTEM_PROMPT}, {role: user, content: text}, ], temperature0.2, # 低温度保证代码稳定性 ) code response.choices[0].message.content code extract_code_block(code) if validate_syntax(code): return code raise RuntimeError(多次生成后代码语法仍然非法) def extract_code_block(raw: str) - str: # 模型经常会把代码包在python里,需要剥掉 pattern r(?:python)?\s*(.*?) match re.search(pattern, raw, re.DOTALL) return match.group(1).strip() if match else raw.strip() def validate_syntax(code: str) - bool: try: compile(code, generated, exec) return True except SyntaxError: return False这段代码里有三个细节值得说明。一是temperature设成0.2CAD代码生成是确定性任务温度太高会带来随机语法错误实测在0~0.3之间出错率最低。二是extract_code_block大模型几乎总是会用Markdown代码块格式来回复你不剥掉就没法直接执行。三是compile语法预检这比直接把代码丢进exec要安全得多可以先拦截一批低级错误。然后写执行和校验部分。我这里给了一个简单的体积合理性校验你可以按需扩展成部件是否有两个以上特征孔直径是否过小等规则。def execute_cad_code(code: str): namespace {cq: cq} exec(code, namespace) return namespace[result] def validate_model(cad_obj): # 简单校验:体积不为零、包围盒不过于夸张 bbox cad_obj.val().BoundingBox() vol cad_obj.val().Volume() if vol 0: raise ValueError(生成模型体积为0,可能代码逻辑有问题) if bbox.xlen 1000 or bbox.ylen 1000 or bbox.zlen 1000: raise ValueError(模型尺寸超出合理范围( 1000mm)) return True整个原型跑通以后效果大概是这样的输入做一个外径20的内六角螺母对边16厚度8中间螺纹孔直径10LLM生成的CadQuery脚本会在两秒内被内核编译成实体然后你可以在Jupyter里看到模型或者导出STEP丢进SolidWorks继续做装配。第一次跑通的时候旁边同事都觉得这玩意要革建模师的命当然实际用下来发现远没有那么夸张这个后面细聊。3.3 设计输入模板把模糊描述变成可执行指令如果你的需求只是给我生成一个零件效果一般不会好。原因在于大模型对模糊的物理世界概念比如一个小支架一个圆润的块很难直接映射成精确参数。所以我在原型里加了一个结构化输入模板引导用户描述补全关键信息。模板大致长这样- 零件类型: 底座 / 支架 / 壳体 / 法兰 / 自定义 - 整体尺寸: 长x宽x高(单位mm) - 需要哪些特征: 孔/槽/倒角/圆角/阵列等注明位置和尺寸 - 安装要求: 比如四个角落要有8.5mm安装孔 - 材质或工艺备注: 比如考虑3D打印壁厚至少2mm这看起来有点繁琐但对生成质量提升巨大。我做了一个对比测试不带模板直接说给我一个机器人支架出来的模型五花八门且基本不可用带模板描述一个L形支架立板厚5底板厚5宽40高60底板上有两个直径6的孔间距30模型基本一次成型。所以说text-to-cad并不是真的你随便说一句就出图它更接近你把需求稍微结构化AI帮你完成剩余建模动作。3.4 参数化扩展让AI改图比人快原型跑通后我加了一个功能允许用户在生成模型的JSON参数基础上修改个别值让LLM重新生成脚本。这里的关键是以原脚本为上下文只修改差值。def modify_cad_model(original_code: str, modification: str) - str: response client.chat.completions.create( modelgpt-4o, messages[ {role: system, content: SYSTEM_PROMPT}, {role: user, content: f原脚本如下:\n{original_code}\n\n请根据要求修改:{modification}}, ], temperature0.1, ) code extract_code_block(response.choices[0].message.content) if validate_syntax(code): return code raise RuntimeError(修改后的脚本语法错误)这个改图场景实际上比从零生成更贴合真实工作流。机械设计里大部分时间不是在创造新零件而是在改旧零件。参数化脚本一旦建立修改台词就只是一两句话的事。比如把孔距从30改到35孔径改成6.5整个脚本在几秒内重跑一遍比去SolidWorks里拖动草图尺寸线快得多。实测下来改图场景的LLM成功率比从零生成高不少因为上下文里有完整的参照代码模型只需要做局部文本替换。4. 实测中出现的高频问题与排查实录4.1 生成的代码有语法错误或者API误用这是最开始最常遇到的。CadQuery的API有它自己的怪脾气比如faces(Z)是选择Z轴正方向的面edges(|Z)是选择平行于Z轴的边这种符号旧模型学习得不够扎实就容易生成一些看起来很像、实际跑不通的代码。我的应对思路有两个。第一个是给系统提示词里加一段CadQuery高频规范速查表把最常用的几种操作标准写法贴进去模型生成时就会照着模板走。第二个是失败重试机制代码执行抛异常后把异常信息拼到下一次请求里让LLM根据报错自己修。这个循环最多跑三次三次后还失败就放弃。实测下来大概六到七成的语法错误可以在重试中自愈。def execute_with_feedback(code: str, user_text: str) - cq.Workplane: for attempt in range(3): try: return execute_cad_code(code) except Exception as e: print(f[Attempt {attempt1}] Error: {e}) code repair_code(code, str(e), user_text) raise RuntimeError(经过三次修复仍然失败)4.2 尺寸与语义错位说好了12毫米出来120毫米这类问题的核心是LLM对数字并不真正感知它只是在做Token概率预测12和120在它看来长度差不多的文本片段。一旦你给的是间接描述比上一个加宽一点偏差就更离谱。我的校验层会对所有关键尺寸做范围约束。比如用户声明总长不超过100那我就把校验规则传入最后模型生成完自动检查包围盒。如果超了就不返回结果直接告诉用户你的描述给的参数是矛盾的最大长度100但你又要求孔距110这不可能同时满足。这其实是在把错误判断前置到对话阶段至少比默默生成一个错误模型要好。另外一个小技巧让模型把关键尺寸参数单独提取出来放到脚本顶部的变量区。这样即使模型在后面的代码里写错了数字人工检查也容易发现。能不能让模型理解几何现阶段别把期望拉太高先保证错得能看见。4.3 布尔运算和几何约束冲突CadQuery里最让人头疼的报错之一是布尔操作失败。常见场景是给一个薄壁件的外表面加一圈加强筋加强筋和主体边缘产生了微小的重合/分离内核在对两个B-rep做布尔并集时可能因为浮点容差问题直接崩溃。这不算AI独有的问题传统建模也会遇到。但在text-to-cad里你没法通过拖动几何体来手动修复所以需要在模型侧规避。我总结的有效策略在提示词里强调所有几何特征之间必须保留至少0.01mm的间隙或完全相交避免共面接触在代码执行前对生成脚本做正则检查找出是否有大量重叠面操作如果布尔失败捕获异常并回传到LLM要求它改用先合并后再进行一次圆角处理等重写策略注意CadQuery的容差机制在处理共面重叠时确实存在历史bug很多情况下是库的问题而不是你提示词的问题。所以遇到这类错误备选方案是直接把失败场景转成拆分成多个单独实体导出STL而不是坚持做单个B-rep实体。4.4 推理速度与成本批量生成时别大意如果你只是偶尔生成几个模型成本不是问题。但我做批量压测的时候发现一个两千字的生成请求带上一整段CadQuery示例代码token消耗比想象中大得多——而且并不一定总是一次成功失败重试一次成本就翻倍。几个实用的省钱建议系统提示词里不要放冗长的CadQuery使用手册放精简版速查即可把详细文档作为RAG内容按需检索优先使用小参数模型做代码生成初稿大模型只做失败修复成本可下降一个数量级温度调低一方面稳定另一方面其实也减少了token重复输出的浪费缓存机制很有用相同或相似的模型描述把生成结果哈希存起来二次命中直接读取4.5 准确性评估怎么判断模型到底对不对这是最后一个但也是最重要的一个环节。文本到CAD系统的评估我目前用的是一套三维一体指标代码可执行性、几何参数接近度、特征语义完整度。代码可执行性是硬门槛执行都不过关直接归零几何参数接近度看的是包围盒长宽高、体积、主要孔径实测值与目标值的偏差特征语义完整度则比较难量化目前我用的是用LLM把生成的STEP模型特征再翻译回文字和原始需求做语义相似度打分。这个闭环目前依然存在很多误判但对于早期项目体检已经完全够用。我个人经验如果你的系统在特征语义完整度上经常拿低分问题往往不在后端执行而在前面的需求解析环节——你给LLM的提示词可能没说清楚哪些特征是必选、哪些是可选它对需要体现的关键特征优先级判断就会乱。我后来在系统提示词里明确加上一个规则优先保证必选特征的完整性再考虑美观和衍生特征。5. 这些踩坑经验给后来者几条实在建议5.1 别贪一句话搞定一切的漂亮话外面很多演示视频让人产生错觉AI好像已经完全理解了设计师脑子里的想法。实际上text-to-cad现阶段更适合被当作一个快速原型生成器和参数化脚本助手而不是无人驾驶建模系统。我的经验是如果需求描述里包含超过五个关键特征LLM的生成质量就会明显下降它开始顾此失彼。合理的方式是把复杂模型拆成多个子部件分别生成后做装配而不是让它一步到位生成一个包含几十个特征的加工级零件。所以我会建议所有上手这个方向的人先让AI做会画的部分再做精确的部分雷达图永远比黑盒更稳妥。5.2 给模型做示例示范比修改指令更有效我最初做修改任务时直接告诉模型把轴径改成30结果模型总是把轴径的所有关联特征比如键槽深度、倒角大小都改了导致几何关系崩坏。后来换了个方式在输入里附上一小段正确修改片段——比如原来这段代码中轴径变量是d20现在请改成d30注意保持键槽宽高比例不变模型的表现立刻好了很多。少让模型去做隐含推理多给它显式参照这比它自己瞎猜要可靠得多。5.3 模型生成不完美但可以让工具链补位坦白说就我目前测试过的几个主流大模型还没到能完全取代CAD操作的程度。但换个角度想它也不需要一步到位替代所有功能。只要它能自动生成一个占位结构让工程师把精力放在拓扑优化和装配设计上就已经价值巨大了。工业界一直讲专家在环text-to-cad的正确用法也是人在环上做决策AI在环内做执行。把校验规则写进管道把失败信息做成可读的日志这个辅助工具的完成度完全够格进日常设计了。5.4 后续还可以往哪些方向折腾我在这个原型上目前主要做的是基于预训练LLM的直接生成不涉及微调。如果你有足够多的自然语言-脚本配对数据微调一个小模型比如Qwen或Llama的7B/13B版本专门做代码翻译效果和延迟会比调用通用API好不少。另一个方向是结合RAG把企业内部的建模规范、标准件库、材料库塞进知识库让模型生成时自动参考标准件规格这个对所有结构设计团队来说都是可以直接见效的功能。我个人下一步的计划是尝试Build123d作为后端它的构造方式比CadQuery更接近工程语义比如Chamfer和Fillet的构造参数化更符合直觉。再把生成结果做成一个Web小服务让团队里非技术成员也能通过浏览器里一个输入框用上。技术成熟度还不够完美但它已经足够成为一个值得每个设计团队自己去跑一遍的方向了。