text-to-cad这两个词摆在一起翻译过来就是“从文字直接生成CAD模型”。听起来像科幻片里的情节但这两年它确实从论文堆里走出来了——我在GitHub上跟过至少四五个同类项目从早期只能生成“方块加圆孔”的玩具demo到现在已经能处理带倒角、阵列、布尔运算的组合体零件。这篇文章把我实际跑通的路子和踩过的坑整理一遍给正准备入坑的朋友做个参照。简单说text-to-cad要解决的是个很现实的痛点传统CAD建模的门槛高得离谱你脑子里有想法但要变成一个看得见摸得着的模型得先学软件操作、二维草图、特征树、约束关系那一大堆东西。建一个稍微复杂点的零件新手半小时起步老手也得十来分钟中间还得反复改。而text-to-cad试图把中间这一大段操作全砍掉让你直接跟模型“对话”。你说“我要一个能装三个M5螺丝的收纳盒带卡扣结构”它给你一个能直接编辑、能导出的CAD文件。这玩意儿适合谁第一类是机械工程师和产品设计师用来快速出概念模型做方案比选第二类是3D打印玩家想做个小配件、改个结构但不想为了一个零件去学一整套建模软件第三类是搞AI和图形学研究的开发者想摸清文本驱动3D生成这条路线的技术脉络。我自己算第二类和第三类的混合体下面讲的都是我实际项目中摸着石头过河的经验不是教科书式的理论堆砌。1. text-to-cad的核心思路与方案选型1.1 三条技术路线先别急着站队我把目前能跑通的技术方案分成三类检索式、生成式、程序化-参数化。这三条路线各有各的脾气选错了后面全是坑。检索式路线的思路很直白先用CLIP或专门的文本编码器把用户输入变成向量再到一个大规模3D模型库里做最近邻检索找出语义最接近的模型给你。这类方案的典型代表是早期的Text2Shape工作以及一些基于ShapeNet模型库的检索系统。优点是结果一定是一个真实存在、可制造的模型不会出现那种“看起来像但根本没法加工”的怪东西缺点是创作能力为零——库里没有“猫头鹰造型的花瓶”就是没有搜破了天也只能给你一个最像的花瓶但绝不可能是猫头鹰。生成式路线是这两年最热闹的方向做法是用扩散模型或自回归模型从文本语义向量直接生成点云、体素或者三角网格。OpenAI的Point-E、CLIP-Forge、AutoSDF、Meshy这类文生3D工具走的都是这条路。优点是想象力丰富你说“一个长得像蘑菇的蓝牙音箱”它真能给你生成一个蘑菇形的音箱但缺点是几何精度和拓扑质量堪忧——生出来的网格常常有破洞、自相交、非流形边拿去做3D打印可能直接报错更别说做机械装配了。程序化-参数化路线是我最看好的也是我现在主力在用的。它不是直接生成几何体而是用大语言模型LLM理解用户描述然后输出一段参数化建模代码——通常是CadQuery或OpenSCAD脚本。这一步非常关键因为代码执行出来的是真正的CAD实体B-rep有精确的尺寸、特征树和建模历史后续想改尺寸、加孔、做阵列都是几行代码的事。代表工作包括DeepCAD、Text2CAD、CAD-Coder这些思路各有侧重但核心都是“文本 → 建模命令序列 → 参数化模型”。1.2 为什么程序化-参数化路线是长期主义可能有人会说生成式路线多省事直接给网格不就行了这里有个工程上的根本问题在真实的产品开发和制造流程里网格模型几乎没有可用性。你拿一个AI生成的STL文件给CNC加工厂对方会直接让你拿B-rep或者STEP文件来因为CNC编程需要精确的曲面和实体边界而不是一堆三角形面片近似出来的东西。就算只做3D打印切片软件虽然能吃STL但模型一旦有拓扑缺陷切片就会出各种妖蛾子。程序化-参数化路线天然绕开了这个问题——CadQuery生成的模型本身就是带参数的特征树导出STEP格式后在FreeCAD、SolidWorks、Fusion 360里都能直接编辑。这意味着AI生成的东西不是一次性玩具而是真正进了工程流程的“半个成品”工程师接手后改几个参数就能用。举个实际案例我用AI生成过一个带减重槽和气动接口的壳体拿到FreeCAD里改了三个孔位、加了一处加强筋总共花了不到五分钟如果从零建模这个改动量够我忙活一晚上。1.3 一个悬而未决的难题文本到约束的映射先泼一盆冷水目前没有任何一条路线能做到完全端到端的可靠。最难啃的硬骨头是让AI理解文本里隐含的约束关系。用户说“两个孔的中心距是50毫米”很容易但如果用户说“这两个孔要跟那个腰型槽保持同轴”模型就得先理解“同轴”这个几何约束再把约束翻译成CadQuery里的引用关系。现在的LLM在简单约束上已经做得不错但复杂的几何依赖关系还是会翻车。这对咱们从业者意味着什么意味着现阶段不能把text-to-cad当“全自动工具”用而应该当“超级加速器”——AI负责把80%的重复劳动干掉剩下20%的专业判断还是得人来。2. 核心技术细节拆解从文本到几何的关键环节2.1 文本理解先把一句话拆成结构化的“设计参数”要让计算机把“一句话”变成“一个CAD模型”前端必须先把自然语言结构化成可执行的参数表。我自己总结出一套拆分维度拿“做一个长80mm、宽50mm、高20mm的塑料底座四角打直径6mm的通孔底部中心挖一个直径30mm深10mm的凹槽”这句话举例实体识别抽出“底座”“通孔”“凹槽”这些对象关键词。属性绑定把数值和单位绑到对象上——长80、宽50、高20是底座的外形直径6是通孔直径30、深10是凹槽。空间关系识别“四角”表示孔要对称分布在四角而且是通孔“底部中心”是凹槽的定位锚点。隐式约束比如“底部”决定了凹槽在Z轴负方向的起始面“通孔”意味着要贯通整个底座。这个结构化过程传统NLP时代得靠一堆规则模板硬写覆盖率低得可怜。但现在有了LLM事情简单多了——直接用提示词让模型输出JSON结构化参数或者更进一步让模型直接输出CadQuery代码把理解过程和建模过程一步到位。我实测下来模型输出结构化JSON的准确率高过直接输出代码但多一道转换工序后续还得写个JSON转CadQuery的解析器。孰优孰劣取决于你更怕“理解错”还是更怕“代码错”。2.2 三维表示选型参数化脚本 vs 隐式场这一节是技术选型的核心不少人在三维表示上选错了方向导致整个项目的天花板被锁死。我先放一张对比表再逐条解释表示方式优点缺点适合场景体素Voxel结构简单适合卷积网络处理分辨率一高显存直接爆炸几何精度差学术研究、分类任务点云Point Cloud轻量、易采样缺少面与拓扑信息无法直接制造文生3D大模型预训练三角网格Mesh通用渲染友好拓扑缺陷多编辑困难无法精确标注尺寸视觉验证、游戏资产神经隐式场SDF形状表达能力强支持任意拓扑提取网格后仍需后处理不直接对应CAD高精度形状生成参数化脚本CadQuery/OpenSCAD精确、可编辑、可制造自带特征历史表达复杂自由曲面很吃力机械件、工程件、3D打印你可能发现了上面这五种其实可以分成两类一类是用“面片/点/体素”直接描述几何一类是用“操作序列”描述几何。前者像是用像素去画一幅画细节再丰富也只是画的后者像是用乐高积木一块块搭——每一步都知道自己在搭什么尺寸可控、结构可拆。text-to-cad要落地到工程没得选只能走后面这条路。说到神经隐式场这里多提一句。生成式的文章总爱用SDF作为中间表示因为SDF对拓扑的容忍度极高可以表达任意复杂的形状比如一个内部有空腔的薄壁件。但实际跑下来你会发现从SDF提取出网格那一步精度和拓扑质量会大打折扣网格破洞、薄壁变厚等问题很常见最后还是得返工。所以我的立场是如果你追求的是“能生产的CAD模型”直接放弃隐式场把精力压在参数化脚本这一支上。2.3 模型训练与数据喂什么才能长本事AI不是神它水平行不行很大程度上是看你喂了什么数据。text-to-cad领域的数据集跟我见得最多的自然语言数据集画风完全不同。业界用得最多的三块数据源一是ABC数据集这是Adobe出的百万级CAD模型库里面的模型由参数化操作构成非常适合用来训练“命令序列生成”二是Fusion 360 Gallery Dataset包含带完整建模历史的机械零件每个模型都记录了“先画哪个草图、后做哪个拉伸、再加哪个倒角”的全过程这正好对应我们要学的“先后顺序”三是DeepCAD dataset是研究者从Fusion 360模型里提取出来的建模操作序列把CAD建模问题转成了“序列生成问题”是很多text-to-cad模型的训练基础。这里我想强调一个容易被忽视的细节文本和模型的对齐数据极度稀缺。有操作序列的模型多的是但给模型写一句贴切自然语言描述的少之又少。所以不少论文的做法是先让LLM根据模型特征自动生成描述再用这些描述去监督训练。这个路子能跑通但有个隐患——模型学会的是“看到某个特征就联想到某类描述”泛化到真实用户那种口语化、模糊甚至带有错误指令的输入时表现会掉档。这是目前这个领域公开的短板也是咱们实践者能弯道超车的地方你可以在自己的场景里攒一小批“高质量指令对”做微调效果会明显好过用通用模型裸奔。2.4 为什么不能照搬“文生图”的经验很多人误以为text-to-cad就是“文生3D版文生图”用Stable Diffusion那套扩散模型改改就能搞定。这个误解我一开始也犯过。文生图的任务里生成一张1024×1024的图哪怕每一个像素的RGB值跟理想值差个十几二十肉眼根本看不出区别——图像的“风格正确”远比“像素精确”重要。但CAD模型是反过来的一个直径8mm的通孔你给我生成7.9mm装配的时候就装不进去了两个孔中心距差0.5mm整条生产线都得跟着改模。CAD对精度的要求是毫米级甚至微米级的这不是大模型“差不多就行”的舒服区。还有一点文生图的评价指标是FID、CLIP Score这些偏向感知质量的分数而CAD模型的评价指标是尺寸误差、几何误差、是否能成功执行布尔运算。拿“视觉好不好看”的套路去训练“几何精不精确”的模型方向本身就拧了。所以现在真正做得好的text-to-cad项目都是在命令序列级别做监督让模型输出的是“代码”而不是“三角面”这样误差能被限制在命令参数本身远比让网络去预测上万个面片坐标要可靠。3. 实操演示搭一条可用的text-to-cad工作流3.1 最省事的方案LLM CadQuery前面分析了那么多现在聊点实际能落地的。我推荐的第一套组合拳是一个支持代码生成的LLM CadQuery库。选CadQuery而不是OpenSCAD主要是因为CadQuery的建模逻辑更接近现代CAD软件——它用的是面向对象的“工作平面特征操作”模式生成的模型自带坐标系和特征树而OpenSCAD偏函数式建模复杂零件写起来头大。先装基础环境这个没什么花头Python 3.10以上安装CadQuery的建议方式是直接用conda创建环境因为CadQuery底层的OCCTOpenCascade内核依赖比较多用pip一路装容易踩依赖坑conda create -n cad python3.10 -y conda activate cad conda install -c conda-forge cadquery模型这边我试过两条路云端大模型比如Claude、GPT-4系列有联网能力知识新生成CadQuery代码的成功率很高本地模型比如Qwen2.5-Coder-7B-Instruct跑在Ollama上也能用但生成复杂建模命令时偶尔会张冠李戴把CadQuery和OpenSCAD的API混着写。我的建议是高级、复杂的零件先用云端大模型开发和调试阶段可以在本地反复跑节省成本。3.2 从一句话到代码再到模型的完整路径我给你完整走一遍流程。假设用户输入这么一句话做一个长100mm、宽60mm、厚8mm的安装底座四角各打一个直径6mm的通孔孔中心距离边沿10mm。第一步设计结构化提示词。这一步至关重要直接决定生成质量。我习惯给LLM一套完整的“角色输出格式约束”提示词下面这个模板我改了很多版实测下来比裸写请求稳定得多你是一名CAD参数化建模工程师精通CadQuery Python API。 根据用户的需求生成完整可运行的CadQuery代码。 要求 1. 所有尺寸必须明确给定不要使用变量名替代数值。 2. 代码需要包含模型导出步骤cq.exporters.export(result, output.step)。 3. 使用mm作为单位。 4. 输出只包含Python代码不要解释。 用户需求做一个长100mm、宽60mm、厚8mm的安装底座四角各打一个直径6mm的通孔孔中心距离边沿10mm。第二步把这段提示词发给LLM得到的代码应该长这样import cadquery as cq # 底座主体 base ( cq.Workplane(XY) .box(100, 60, 8) ) # 四角安装孔孔心距边沿10mm result ( base.faces(Z) .workplane() .rect(80, 40, forConstructionTrue) .vertices() .hole(6) ) # 导出STEP文件 cq.exporters.export(result, output.step)第三步跑起来。执行脚本后会自动生成output.step文件用FreeCAD打开就能看到底座和四个孔。这里有个小技巧验证时可以先把导出格式改成SVG或者直接渲染成图片快速目检再导出STEP省得天天开FreeCAD。python gen_part.py python -c import cadquery as cq; from ocp_vscode import show; show(cq.importers.importStep(output.step))用ocp_vscode能在VS Code里直接渲染出模型比开桌面软件快得多。3.3 本地小模型 vs 云端大模型怎么挑我把两种方案的优缺点摆在一起你可以按场景对号入座维度云端大模型GPT-4系列/Claude本地小模型Qwen2.5-Coder/Ollama代码质量高复杂布尔运算和倒角也能处理中简单零件可以复杂特征易出错API规范记忆强几乎不会记错CadQuery方法名弱偶尔混用OpenSCAD语法数据安全零件设计数据出域敏感行业有风险完全本地适合保密项目成本按token计费迭代多了肉疼一次性硬件投入调试速度受网络延迟影响本地秒回适合反复调参我的实操结论是**先用云端大模型把复杂逻辑跑通之后把稳定下来的提示词和示例代码沉淀成模板再用本地模型跑量。**这里有个模式叫“蒸馏式工作流”。比如你需要在公司内网每天批量生成几百个零件不方便连外网那就可以拿云端模型的几百个高质量生成结果做参考用LoRA微调一个小模型之后小模型专门干这个活速度和成本都平衡下来了。3.4 质量验证三件套尺寸、拓扑、装配这是我自己项目里血的教训换来的。AI生成的模型绝对不能直接拿去加工或者装配必须过三道关卡。第一关是尺寸校验用CadQuery的val().length()或者直接解析生成的STEP文件检查关键尺寸是否落在公差范围内。比如要求直径6mm的孔实测是5.92mm这就是问题。第二关是拓扑校验使用OCCT的BRepCheck_Analyzer检查模型有没有非流形边、自由边、无效面。这一步很多新手会忽略结果放到切片软件里才发现模型根本没法切片。第三关是装配校验把生成好的模型和它要配合的零件放到一个装配体里检查干涉情况。有一回我生成一个轴承座孔距跟配对法兰差了0.3mm装不上但如果只做单件尺寸检查根本发现不了。这个三件套启发自一个教训。现在不少项目把“生成一个模型”当成终点但在实际制造里模型能看只是一小步能装能造才是真验收。4. 常见问题与排查技巧实录4.1 几何精度不够尺寸全凭AI瞎猜这是我见过最多的翻车现场。LLM本质上是个“按概率生成文本”的模型它对数字的感知远不如对文字的感知你把“直径6mm”给它它可能输出radius6直径当半径或者把开孔深度写进通孔参数里。更隐蔽的错误是尺寸单位搞混——明明用户说的是mm模型内部训练数据里有英寸的数据它可能把thickness0.5理解成0.5英寸结果整个零件大了一圈。排查办法目前最靠谱的就一条在提示词里强制要求“所有数字必须来源于用户输入禁止自行推断”并在代码里增加断言。# 在生成代码中强制校验关键尺寸 assert abs(base.val().BoundingBox().xlen - 100) 0.1, 底座长度错误 assert abs(base.val().BoundingBox().ylen - 60) 0.1, 底座宽度错误一旦断言失败程序就停下来报错提醒你去检查LLM的输出而不是默默接受一个错误模型。这个方法土但管用。4.2 布尔运算和倒角把拓扑搞崩了现代AI模型生成CadQuery代码时明明每一句都是对的合在一起执行就是报错。最常见的两个错误一是布尔运算失败说Unable to compute boolean operation二是倒角或圆角时的Radius too large。这些都指向同一个根源模型对几何合理性缺少直观判断。举个例子用户说“在长100mm的板子上等距排10个直径20mm的孔”AI算出来的间距是(100 - 20) / 9 8.88mm看着没问题但执行打孔时孔之间可能会互相重叠或边缘切穿导致拓扑运算失败。这种问题理论上模型应该判断“这尺寸不合理”但它没有空间想象力只会照猫画虎。我的处理方法是在提示词里加入“数学合理性检查步骤”在执行任何布尔运算前先检查所有参数是否可能导致几何重叠。 如果有冲突选择最合理的数值并输出到注释中提醒用户。这样至少能把一部分明显冲突拦截在生成阶段。剩下的漏网之鱼只能靠代码里的异常捕获来兜底了。4.3 文本歧义AI“脑补”了你没说的话text-to-cad项目里有一半以上的bad case其实是用户输入的锅。你说“做一个支架要结实一点”——什么叫“结实”是加厚加筋换材料AI只能猜。它往往按训练数据里最常见的理解去生成结果跟你的实际需求南辕北辙。这里有个核心技巧我在文档里反复强调跟AI对话时要把你写给同事的话改写成写给供应商的加工单。“做个底座四角打孔”改成“做一个长100、宽60、厚8毫米的矩形底座四个角距离边沿10毫米处打直径6毫米的通孔公差正负0.1毫米”。每多一个明确数字AI的出错概率就降低一截。如果你在做一个面向普通用户的工具不能指望每个用户都写得这么规范那就在前端加一层“结构化交互”——先让用户填几个关键字段比如长、宽、高、孔径、孔距再由系统组装成规范化提示词这比让LLM直接理解自由文本可靠得多。4.4 常见问题速查表把最常见的坑和解决方案整理成一张表我踩过的全都列在这里了问题场景典型表现快速排查与修复尺寸数量级错误6mm变成6英寸提示词强制“按mm为单位”代码加尺寸断言API张冠李戴混用OpenSCAD语法限定模型版本或改用本地微调模型布尔运算失败OCCT报错检查是否重叠提示词加数学合理性校验倒角过大Radius too large禁止AI自动计算圆角值强制从用户输入读取生成STEP打不开文件损坏或版本不兼容用CadQuery重新导出或检查export路径模型悬空/无实体多个实体未合并在提示词中要求“所有特征合并为单个实体”通孔变盲孔Depth参数缺失在提示词中明确“通孔表示完全贯穿”这张表也是我项目的调试清单每次AI生成的模型出问题先按表里对照一遍能解决七八成剩下两三成才是真需要重新调提示词的。5. 进阶玩法从单模型生成到参数化系列设计5.1 用一套提示词生成整个产品家族text-to-cad真正的价值不在“生成一个零件”而在“生成一族零件”。比如你是做非标自动化设备的经常要设计几十种不同尺寸的安装支架传统方式是一个个建模改尺寸改到吐。用text-to-cad的思路完全可以做一个参数化模板先定义好支架的拓扑结构再用LLM把用户的自然语言“载重50kg的龙门架支撑座”映射到一组具体参数上最后驱动CadQuery模板批量生成不同尺寸的系列模型。我做过的实际项目里有个客户需要一套从40mm到200mm共9种规格的电机安装座。用传统方式得建9个模型用text-to-cad模板的方式我写了一个CadQuery参数化模板然后用LLM把“电机型号”翻译成参数表一条脚本循环跑完9个STEP文件全出来了总共花了不到20分钟。这个数字传统CAD操作员可能要一整天。5.2 让AI帮你修图文本驱动的模型局部修改除了从零生成text-to-cad还有一个被低估的用法——局部修改。传统CAD里改一个圆角半径、挪一个孔位看着简单但要在特征树里找到对应操作、改参数、重新生成稍微复杂点的模型就得小心翼翼。用AI做局部修改就轻松很多你把模型的历史信息CadQuery代码/STEP文件喂给LLM说“把上面那个孔从直径8改成直径10”它保留其他所有操作只改一处参数。这个玩法对老模型尤其有用。很多遗留下来的STEP文件已经没有原始特征树了直接改无从下手但用CadQuery的导入功能把STEP转成可编程对象再借助LLM定位并修改关键尺寸相当于给老模型“续了命”。6. 写在最后的个人体会去年这个时候我还对text-to-cad持怀疑态度觉得AI怎么可能理解“加工工艺”“装配关系”这种隐含知识。但一年下来我自己的项目里已经有大约三成零件是AI生成初稿、我再手工修细节了。这个比例还在涨。我最大的感受是这技术真正的价值不是取代CAD工程师而是把工程师从“重复劳动”里解放出来让他们把时间花在真正需要判断力的地方。最后分享一个实操小技巧如果你跟我一样每天都在跟LLM打交道生成CadQuery代码建议专门准备一个“经验库”——把每次成功生成复杂零件的提示词、修过的bug、踩过的坑全部记录下来按零件类型归档。一开始这个库只是零散的文本积累两三个月后它会变成你私有的行业知识库输出质量会明显好过直接拿通用prompt问AI。text-to-cad这条赛道还在快速演进今天的好方案可能半年后就过时了。但核心逻辑不会变理解意图、映射参数、生成可制造几何。抓住这条主线不管工具怎么迭代你都站在了正确的位置上。
