text-to-cad全解析：自然语言生成参数化CAD模型的工程实践

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 隐式场

这一节是技术选型的核心，不少人在三维表示上选错了方向，导致整个项目的天花板被锁死。我先放一张对比表，再逐条解释：

你可能发现了，上面这五种其实可以分成两类：一类是用“面片/点/体素”直接描述几何，一类是用“操作序列”描述几何。前者像是用像素去画一幅画，细节再丰富也只是画的；后者像是用乐高积木一块块搭——每一步都知道自己在搭什么，尺寸可控、结构可拆。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底层的OCCT（OpenCascade内核）依赖比较多，用pip一路装容易踩依赖坑：

conda create -n cad python=3.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, forConstruction=True) .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 云端大模型，怎么挑

我把两种方案的优缺点摆在一起，你可以按场景对号入座：

我的实操结论是：**先用云端大模型把复杂逻辑跑通，之后把稳定下来的提示词和示例代码沉淀成模板，再用本地模型跑量。**这里有个模式，叫“蒸馏式工作流”。比如你需要在公司内网每天批量生成几百个零件，不方便连外网，那就可以拿云端模型的几百个高质量生成结果做参考，用LoRA微调一个小模型，之后小模型专门干这个活，速度和成本都平衡下来了。

3.4 质量验证三件套：尺寸、拓扑、装配

这是我自己项目里血的教训换来的。AI生成的模型，绝对不能直接拿去加工或者装配，必须过三道关卡。

第一关是尺寸校验：用CadQuery的val().length()或者直接解析生成的STEP文件，检查关键尺寸是否落在公差范围内。比如要求直径6mm的孔，实测是5.92mm，这就是问题。第二关是拓扑校验：使用OCCT的BRepCheck_Analyzer检查模型有没有非流形边、自由边、无效面。这一步很多新手会忽略，结果放到切片软件里才发现模型根本没法切片。第三关是装配校验：把生成好的模型和它要配合的零件放到一个装配体里，检查干涉情况。有一回我生成一个轴承座，孔距跟配对法兰差了0.3mm，装不上，但如果只做单件尺寸检查，根本发现不了。

这个三件套启发自一个教训。现在不少项目把“生成一个模型”当成终点，但在实际制造里，模型能看只是一小步，能装能造才是真验收。

4. 常见问题与排查技巧实录

4.1 几何精度不够，尺寸全凭AI瞎猜

这是我见过最多的翻车现场。LLM本质上是个“按概率生成文本”的模型，它对数字的感知远不如对文字的感知，你把“直径6mm”给它，它可能输出radius=6（直径当半径），或者把开孔深度写进通孔参数里。更隐蔽的错误是，尺寸单位搞混——明明用户说的是mm，模型内部训练数据里有英寸的数据，它可能把thickness=0.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 常见问题速查表

把最常见的坑和解决方案整理成一张表，我踩过的全都列在这里了：

这张表也是我项目的调试清单，每次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这条赛道还在快速演进，今天的好方案可能半年后就过时了。但核心逻辑不会变：理解意图、映射参数、生成可制造几何。抓住这条主线，不管工具怎么迭代，你都站在了正确的位置上。