做机械设计的朋友应该都有过这种经历脑子里明明有一个非常具体的零件形状但要在CAD软件里把它画出来却要先建基准面、画草图、加约束、拉伸、倒角……步骤多到让人怀疑人生。尤其是刚刚拿到一个表达需求的产品描述比如“一个底板长120、宽80、高10四角各开一个直径6的安装孔孔心距边缘15毫米”从读文本到敲出第一版草稿怎么也要十几分钟。text-to-cad要解决的就是这十几分钟——让自然语言直接变成可以编辑、可以导出、可以3D打印的CAD模型。这个方向最近热度很高原因很简单自然语言是大多数设计需求的原生载体而CAD软件却是几何操作的世界。text-to-cad相当于在两者之间架了一座桥。它适合三类人经常做机械结构件的工程师想快速验证概念的工业设计师以及完全没有建模经验的3D打印玩家。下面我会用自己的实际尝试来拆解这个技术是怎么实现的有哪些坑以及哪些思路可以真正用在工作流里。1. text-to-cad 到底是什么一句话背后的建模革命1.1 传统CAD建模的认知鸿沟用过CAD的人都清楚建模最耗时间的往往不是“想设计什么”而是“怎么把设计意图翻译成软件操作”。比如“一个带法兰的轴承座”这句话在SolidWorks里可能意味着选基准面、画法兰草图、拉伸、再定义一个旋转切除、还要做四个安装孔。如果换成CAD建模能力一般的人光是把法兰外径、壁厚、孔距这些隐含参数理清楚就得来回查手册。text-to-cad正是从这个痛点切入它让用户直接使用自己最擅长的语言去描述目标模型然后由算法自动完成“语言理解—参数抽取—几何构建”的全过程。和传统CAD里“从零开始画草图”的思路完全不同它更像是在和一位资深建模师对话你负责说需求对方负责把需求变成可执行的建模指令。1.2 它解决了三个底层问题仔细想想text-to-cad解决的不只是“省时间”这么简单它把三个长期困扰行业的问题一起处理了学习成本传统CAD的工具栏和命令流至少需要几个月到一年的熟悉期而自然语言描述几乎没有门槛。就算完全不会CAD用户也能说“我要一个能放两只手机的桌面支架带一个穿线孔”然后得到一份可编辑的模型。方案多样性同一个需求在传统建模里通常只会画出一个版本而text-to-cad可以快速生成若干个候选方案比如“用中央立柱支撑”和“用两侧耳朵支撑”的两种支架结构让设计者在屏幕前快速对比和筛选。跨软件协作不同CAD软件之间的文件格式互转经常出问题但如果团队用文本描述作为需求传递的“中间语言”再让系统生成各自软件可用的脚本协作成本会低很多。这三点放在真实项目里都有立竿见影的价值。我自己最常用的是第一点遇到临时需要的外壳或过渡件不再花半小时去建一个“用完即弃”的模型直接敲一句话让系统生成省下的时间足够多跑几次尺寸对比。1.3 不是替代而是传统CAD的“前处理”这里必须说清楚一个边界text-to-cad目前并不是要替代传统CAD它生成的产物通常是参数化脚本或STEP/STL文件最终还是要进入SolidWorks、FreeCAD、Fusion 360等工具做细节调整、装配验证和出图。它的价值更多在“方案启动阶段”——把从文本到第一个可编辑模型的路径压到一分钟以内。换句话说传统CAD仍然负责精细建模和工程分析text-to-cad则接管了“把模糊想法变成初步几何”这个脏活。两者更像是流水线上下游的关系而不是你死我活的替代品。你在实际使用中千万不要期待一句话就能生成一个完全满足公差和工艺要求的生产级零件那还需要大量后续工作但至少起步阶段会顺畅很多。2. 核心技术拆解文本是怎么变成三维几何的2.1 自然语言理解先把一句话拆成参数清单text-to-cad的第一步是把人类语言里的“形状意图”变成结构化的参数。这件事远比想象中复杂。拿“四个角各开一个孔”来说“角”到底指外轮廓的直角位置还是要避开倒角的圆弧区域“开孔”是通孔还是盲孔直径公差是多少这些信息在自然语言里往往被省略模型必须根据常识和上下文推断。当前主流做法是让大语言模型LLM做两件事实体抽取和关系解析。实体抽取负责找出“板”“孔”“槽”“法兰”这类几何元素以及它们的尺寸属性关系解析负责理解“在底部”“中心距”“阵列”之类的位置约束。比如“一个100x80x10的安装板四个角各有一个直径6的沉孔孔心距边缘15mm”模型内部会转成类似这样的结构化清单{ 主体: [长方体, 长100mm, 宽80mm, 高10mm], 孔特征: [ 类型: 沉孔, 直径: 6mm, 数量: 4, 位置: 四个顶角, 孔心距边缘: 15mm ] }这一步做得好不好直接决定后面的几何生成是否靠谱。如果尺寸或位置关系解析错模型生成的CAD脚本再完美也是错的。所以真正可用的text-to-cad系统都会在提示词里要求模型“先输出参数清单再生成建模代码”这样即使最终代码出问题至少参数本身可以被人工快速检查。2.2 几何生成从CSG布尔到B-rep边界表示拿到参数清单之后就需要有办法把参数变成真实的三维几何。这里有几条技术路线参数化脚本、构造实体几何CSG、边界表示B-rep和神经隐式表示。参数化脚本用CadQuery、OpenSCAD或FreeCAD的Python API写建模步骤本质上像“用代码画图”。优点是每个特征都可追溯、可修改生成的文件也能被主流CAD软件识别。目前text-to-cad落地产品用得最多的就是这条路。CSG通过立方体、圆柱等基本体做并集、差集、交集来拼出形状。适合外壳、支架、槽孔这一类“几何元素堆叠”的零件计算稳定且代码简单。B-rep用边界曲面和拓扑信息描述精确实体是工业级CAD的标准。LLM直接生成B-rep难度极高但通过脚本让内核自动计算等于间接实现了B-rep。神经隐式表示用神经网络拟合一个SDF符号距离场或占用场再抽取等值面生成网格。这种方法擅长自由曲面和有机形态但工程上很难直接编辑。在机械零件这个场景里我强烈建议优先选“LLM 参数化脚本”。原因很直白脚本生成的模型是“活”的换个尺寸再跑一遍就能更新而直接生成网格的模型几乎无法做参数化修改对制造业来说意义有限。2.3 两条主流实现路线LLM脚本 vs 端到端生成社区里讨论text-to-cad时经常分两条路线一条是用大语言模型写建模脚本另一条是训练一个专门的文本到几何生成模型直接从文本生成点云或网格。两条路线各有取舍。对比维度LLM 参数化脚本端到端生成模型可编辑性高脚本能改参数低生成网格后难改几何精度高由几何内核保证中低重建有误差实现难度中调提示词即可高需要大规模训练数据依赖依赖LLM通用能力需要大量文本-CAD配对数据典型应用标准件、机械结构玩具、外观概念、有机形态在我自己测下来LLM脚本的路线在“稳定出活”方面完胜。只要提示词写得足够清楚LLM生成的CadQuery代码基本能跑跑不通的地方用错误信息回喂一次也就修好了。端到端生成模型比较适合那些没有明确尺寸约束、追求视觉效果的概念设计比如给工业设计前期的头脑风暴提供几个形状参考。2.4 训练与数据text-to-cad模型的燃料从哪里来如果你打算自己训练一个text-to-cad模型最重要的就是数据。目前公开可用的CAD模型数据集已经有一些积累了常见的包括Fusion 360 Gallery、ABC数据集以及专门为文本到CAD任务整理的Text2CAD数据集。这些数据集把CAD文件的建模历史、特征树和最终几何都存下来了训练时可以让模型学习“某一句描述对应哪些建模步骤”。训练策略上很多团队不是让模型直接输出几何而是做“程序合成”输入文本输出一段CadQuery或OpenSCAD代码再用代码执行后的几何结果和标注做对比判断模型生成得对不对。这有点类似让模型学一门“建模外语”好处是模型不需要从头学几何只要学会调用API就行。对大多数个人开发者来说直接用现成的LLM API配上few-shot提示词就能达到可用效果不一定非要走训练这条路。3. 实操复现用大模型CadQuery搭建自己的text-to-cad流程3.1 工具选型为什么我选择CadQuery而不是OpenSCAD市面上的参数化建模工具不少我最终选定CadQuery主要看三点。第一CadQuery基于Python链式API写起来非常符合LLM的输出习惯。比如创建一个带孔的底板OpenSCAD要这样写difference() { cube([100, 80, 10]); translate([15, 15, -1]) cylinder(d6, h12); translate([65, 15, -1]) cylinder(d6, h12); // ... 还要补另外两个孔 }而CadQuery可以写成import cadquery as cq result cq.Workplane(XY).box(100, 80, 10) result (result.faces(Z).workplane() .rect(70, 50, forConstructionTrue) .vertices() .hole(6))第二种写法把“在顶面上布置四个孔”这个意图表达得很直接LLM要生成这种链式调用远比生成一堆OpenSCAD的差集和坐标计算更不容易出错。第二CadQuery自带拓扑命名处理机制选中一个面或一条边之后后续操作不容易因为特征顺序调整而崩溃。这对LLM生成的代码尤其重要因为AI写代码时经常会改变特征顺序拓扑一崩整个模型就废了。第三CadQuery原生支持导出STEP格式。STEP文件在SolidWorks、FreeCAD、Fusion 360里都能直接打开比STL更适合作为CAD下游工作的起点。如果你只做3D打印STL就够了但要进装配体或做有限元分析STEP才稳妥。3.2 提示词工程给LLM一个“资深建模师”人设text-to-cad能不能好用一半在提示词。我没有直接丢一句用户描述就让模型生成而是先设计了一个固定模板把约束全部嵌进去。这个模板是反复试出来的效果比较稳定你是一名有20年经验的CAD建模工程师。用户会用自然语言描述一个机械零件请使用CadQuery API编写Python代码生成符合描述的3D模型。 要求 1. 所有尺寸单位均为毫米。 2. 只输出纯Python代码不要输出解释文字。 3. 必须从 cq.Workplane(XY) 开始。 4. 如果描述有歧义选择最常见或最合理的默认值并在代码注释里说明。 5. 禁止使用未定义的变量。 用户描述 请生成一个安装板长120毫米宽80毫米厚10毫米四角各有一个直径6毫米的沉孔孔心距边缘15毫米。这个提示词的作用是给LLM划定行为边界。设定“20年经验”并不是玄学而是让模型在遇到模棱两可的表达时倾向选择工程上合理的默认做法要求只输出代码避免它夹带一堆啰嗦说明干扰脚本提取明确单位毫米是为了防止后续尺寸错乱。3.3 标准执行流程从一句话到STL文件搭这套流程时我把“文本输入”到“模型产出”拆成了五个固定步骤每一步都能单独检查用户输入自然语言描述。将描述拼接到提示词模板里调用LLM API拿到返回的CadQuery代码。把代码写进临时Python文件用子进程执行。好处是即使生成的代码崩溃也不会影响主程序。执行成功后在内存里校验模型尺寸、实体数量、最小壁厚等关键参数。导出STEP/STL并写一个包含版本信息的日志文件方便回溯。下面是一段简化后的核心代码展示子进程执行和导出的逻辑import subprocess import cadquery as cq def run_text_to_cad(prompt): # llm_call 只是一个示意实际是调用大模型API拿到代码 code llm_call(prompt) # 生成可执行脚本 script code \ncq.exporters.export(result, output.step) with open(gen_part.py, w, encodingutf-8) as f: f.write(script) # 子进程执行捕获报错 proc subprocess.run( [python, gen_part.py], capture_outputTrue, textTrue, timeout30 ) if proc.returncode ! 0: return {error: proc.stderr} return {model: output.step}这里采用子进程而不是直接exec是防止LLM生成的代码出现死循环或恶意操作把整个环境搞崩。调试阶段这个边界很重要。3.4 提升生成稳定性的三个细节直接跑这个流程十次大概有六到七次能一次成功。剩下几次要么是代码语法错要么是几何操作失败。为了把成功率拉到九成以上我加了三个细节降低随机性调用LLM时把temperature设到0.2左右让输出尽量保守和确定。text-to-cad不是创意写作不需要天马行空。先出参数清单再出代码在提示词里要求模型先输出一个JSON参数清单用户确认无误后再生成代码。这样能避免“模型理解错了但代码却能跑”的隐性错误——代码能跑画的却是别的东西这种错最坑人。错误反馈循环代码执行报错时把stderr里的错误信息直接拼到新的提示词里让模型自己修复。比如“你在上一步生成的代码报了这个错xxx请修正后重新输出”。这一招能把成功率再拉高一截。4. 实操中躲不开的坑问题排查与修复实录4.1 代码报错最典型的几种错误和处理LLM生成的CadQuery代码最常见的错误其实就那么几类。第一类是API拼写或使用方式错误比如把hole()写成drill()或者忘了在workplane()前加.faces()。这类错误一般会在执行时报AttributeError把报错信息回喂给LLM就能修好。第二类是几何运算失败典型报错是“cant compute boolean”或“invalid result”。这通常是因为两个形体边界刚好相切布尔运算无法收敛。我遇到过很多次解决方法是让LLM把尺寸微调0.001毫米把相切变成相交或分离问题立刻消失。第三类是轮廓未闭合多见于先画草图再拉伸的场景报错信息会提示“profile is not closed”。这种一般是LLM把约束坐标写复杂了让它简化特征就行。排查时我的顺序是先看错误类型再用最小化复现最后回喂LLM。不要指望一次修复成功多跑一两轮很正常。4.2 尺寸和单位漂移生成模型最怕“混单位”text-to-cad里一个很容易踩的坑是LLM把尺寸单位搞混。有一次我让系统生成一个“宽3英寸的支架”模型直接输出width3完全没管英寸到毫米的换算。这个问题不是语法错误模型能跑但导出的STEP模型在CAD里就是不到8毫米宽整个设计全废了。我现在会在提示词里强调“所有尺寸单位均为毫米”同时在代码执行后自动做一次尺寸合理性检查比如判断输出模型的长宽高是否在期望范围内偏差超过5%就直接拒绝。另外LLM生成的浮点数经常出现8.999999或10.000001这种噪声我会在后处理时统一四舍五入到小数后三位避免下游软件做圆角或装配时因为微小误差报错。4.3 复杂特征生成失败时的降级策略当用户描述里包含七八个特征时比如“底板 四个支撑柱 中间镂空 加强筋 六个孔”LLM生成的代码很容易失败。原因不是模型不够聪明而是长距离依赖一多难免丢三落四。我试过的降级策略非常管用拆分生成把零件拆成“主体”、“支撑部件”、“孔特征”三部分分别用三条提示请求生成最后用CadQuery的union()合成一个模型。这样每个脚本都足够简单成功率高很多。先骨架后细节先只生成主体形状和关键轮廓确认能构建成功再把倒角、圆角、加强筋一层层叠加进去。每一步都在前一步的结果上继续给LLM一个“可操作的上下文”。保留简化版本如果某个复杂特征反复失败我会主动降级——比如把“燕尾槽”改成“矩形槽”把“阵列式散热孔”改成“单列三个孔”。这些简化方案往往能保住整体交付后面再手工细化。这招有点类似开发里的“渐进式增强”先把核心功能跑通再迭代细节。实际使用下来复杂零件从“一次生成”变成“三步生成”之后成功率至少翻倍。4.4 模型导出后不可用检查坐标、单位和网格封闭还有一种“代码完全正确输出文件却没法用”的情况。最常见的是STL网格有孔洞或者STEP文件的单位设置和下游CAD不一致。我习惯在导出后做两个快速检查用Python的trimesh加载STL检查网格是否封闭、有没有自交面再用CadQuery重新打开生成的STEP读取模型的边界框尺寸确认单位是毫米。如果发现网格封闭但整体比例不对那就要回头查LLM是不是把尺寸概念搞错了。如果网格不封闭基本可以判断是曲面布尔运算留下的拓扑缺口这时候重新生成模型比修网格更快。另外很多CAD软件导入STEP时会默认用毫米但STL没有单位信息导入后经常被放大或缩小25.4倍。所以给3D打印用的模型我会在文件名里加上“mm”并在导出设置里固定单位避免下游同事打开模型时一脸懵。5. 从技术到产品text-to-cad可以落到哪些场景5.1 3D打印让想法直接变成可打印的实体3D打印是我身边玩家最先用上text-to-cad的领域。以前要从零画一个“手机支架”或者“无人机云台转接件”得先学一遍CAD操作很多人就是被这一步劝退的。有了text-to-cad你可以直接说“做一个倾斜15度的手机支架底部留一个微USB穿线孔背后加一个散热条带”然后系统给你生成STL直接拖进切片软件。在这个场景里参数化脚本还有一个额外好处生成后可以临时改尺寸。比如3D打印时发现手机壳比预期厚了0.2毫米你不需要重新输入需求只要在生成的脚本里把某个参数改一下重新导出一遍就行。等于把“改需求”的代价降到了最低。5.2 产品设计的“口语化建模”协作我最近在帮一个做硬件的朋友整理需求他们产品经理和结构工程师之间最耗时间的环节就是把“我想要一个更有科技感的外壳”翻译成具体的壁厚和倒角。text-to-cad在这里可以扮演一个“翻译官”产品经理用口语描述外观意向系统生成三个粗略方案结构工程师再从中选一个有潜力、继续深化。这种协作方式在前期概念阶段特别有效因为它跳过了“画起来再说”的心理障碍也不用为了做一版外观模型去求建模工程师排期。当然最终的生产图还是得靠专业CAD做但“概念探索”这个环节已经被文本化、自动化了。5.3 从机械零件到更广的领域text-to-cad的核心逻辑——把自然语言意图变成结构化几何——并不只限于机械零件。同样的思路可以直接迁移到text-to-BIM根据建筑描述生成墙体、门窗、楼梯的大致空间布局给建筑师的方案推敲提供起点。text-to-PCB把“双层板十个焊盘两个排针位置”变成PCB的边框和初始布局省下手工画板框的时间。text-to-EDA在3D设计之外把芯片封装的结构文本描述转成引脚框架和散热模型。这些领域本质上都是“意图到几何/布局”的映射只是AI需要学习的API和约束不同。我甚至觉得未来设计领域的AI辅助工具都会走上这条统一的路径你描述目标系统帮你把初级、重复性的建模工作做完专业工程师只负责判断、修改和优化。5.4 多轮对话和AI辅助设计迭代下一步在哪里现在的text-to-cad大多是“单轮生成”你输入一句话系统给你一个模型。但真实设计过程从来不是一次定稿的用户看到模型之后会说“孔再大一点”“把支撑柱改成三根”“圆角不要太大”。下一阶段的text-to-cad一定会变成多轮对话式的参数化设计。这其实已经不难实现了因为底层是参数化脚本每一处尺寸都是一个变量。系统只需要在多轮对话里维护一个“参数状态”把用户每一轮的修改意图映射到对应变量上再重新构建模型就行。我自己试过一种原型把第一轮的JSON参数清单保留在内存里用户说“孔径8mm”系统就更新参数并把脚本重跑一遍整个过程不到三秒。这种交互一旦成熟设计软件就会从“绘图板”真正变成“设计对话窗口”。说起来这些场景背后还有一个更值得琢磨的方向把text-to-cad生成的模型跟物理仿真、成本估算、可制造性检查接起来。如果文本描述完一件零件系统不只能画出来还能告诉你“这个设计重量偏重”“这个倒角加工不出来”那才是AI真正在设计环节里站住了脚。从目前LLM和几何内核的发展速度看这个目标并不遥远。我自己在实际操作中最深的感受是text-to-cad最值钱的地方不是让你“少画图”而是把“想”和“做”之间的延迟降到了最低。过去为了验证一个公差配合方案可能要先花两小时建一个勉强能看的模型现在用自然语言描述十秒钟就能拿到初版多出来的时间完全可以用在分析、测试和迭代上。哪怕生成的模型只有七十分它带来的启动速度也足以改变整个设计节奏。如果你也想尝试我建议从最简单的安装板或支架开始先准备好一套固定的提示词模板然后一点点加特征。踩过几次单位换算和布尔运算的坑之后你大概率会和我一样把text-to-cad放回到真正的机械设计工作流里——不是替代你而是让所有该留下的时间都留在真正值钱的地方。