上个月帮朋友赶一套夹具方案，他在建模软件里对着图片一点点拉草图，花了两个多小时才画出一块带安装孔的底板。我问他为什么不试试text-to-cad这类工具，把需求直接打进去，让模型生成初始数模，再进软件微调。他一脸懵："文本还能生成CAD？"——那一瞬间我意识到，这个方向的进展虽然热闹，但真正用过、能说清楚原理和边界的人还不多。
Text-to-CAD，简单说就是通过自然语言描述直接生成CAD模型。学术上常称为text-to-CAD、text-driven CAD generation，目前社区里也有不少项目叫Text2CAD。它解决的不是"画图"这一步，而是把设计意图从语言直接映射成几何实体的全过程。这篇文章不打算堆论文，只讲我实际把这套流程用起来之后的体会：有哪些技术路线、怎么搭一条能用的流水线、生成质量如何评估、踩过哪些坑、哪些场景真的值得用。
1. Text-to-CAD到底解决了什么问题：从"口头需求"到"实体建模"的鸿沟
1.1 传统流程里的转述损耗
做过结构件或非标设备的人应该都有同感：需求方在电话里说"给我一块板，上面打几个孔，装到设备上"，到了工程师手里，要变成"120x80x8的6061铝合金板，四角M5沉头孔，中间两个定位销孔，单边留1.5mm翻边"。这一步翻译，靠的是工程师对加工工艺的理解和对标准件库的熟悉。
这中间的损耗非常大。我听过的真实需求，经常缺尺寸、缺公差、缺表面处理要求，更别提孔位、避让、拔模斜度这些细节。传统CAD软件的交互方式——鼠标点选、约束定义、特征树操作——本质上是在跟几何体对话，而不是跟人对话。设计师脑子里想的是一句话，手上做的却是几十次点击。Text-to-CAD堵住的正是这道沟：让"语言"成为建模入口，让"设计意图"直接变成"特征步骤"。
1.2 为什么这几年突然能走通了
其实"从文字到模型"的尝试很早就有，早先的专家系统、参数化模板库都做过类似的事，但效果一直很别扭。核心卡在两个地方：一是自然语言理解不到位，"一个带导角的矩形板"这种话机器根本不知道"导角"该落在哪条边；二是几何生成没有泛化能力，只能套固定模板。
近几年LLM把第一关打通了，模型能理解空间关系、常见零件语义和隐含的工程习惯。第二关则被两条路线分别解决：一条走三维生成，用多模态模型直接产出点云、体素或隐式曲面；另一条走代码生成，让模型输出参数化建模脚本，再交给内核重建出可编辑实体。后一条路线在CAD圈子里尤其被看重，因为工业界要的不是一张好看的渲染图，而是一个带特征树、能改参数、能出工程图的真实数模。
在这部分我想强调一个我的判断：做实际项目，优先走"代码生成"路线，而不是"端到端生成"路线。原因后面详细展开。
2. 文本转CAD的两条主流技术路线：端到端生成与参数化代码生成
2.1 多模态大模型+点云/隐式场：像"雕刻"一样从无到有
这条路的基本思路，是把CAD模型当成一种三维数据模态来处理。输入文本描述，经过类似扩散模型的生成器，输出体素占用、点云或者SDF（有向距离场），再通过表面提取、网格化、参数化重构转成B-rep实体。
听起来很顺，实际用起来问题不少。首先生成结果大多是网格或点云，不是原生实体。网格数据进不了主流CAM和CAE流程，拿去做仿真还要重新逆向成实体，而逆向本身就是一个大坑。其次，这种路线生成的物体，从拓扑上看往往很"自由"，像雕塑，自由度管不住。你说"一个带六个螺纹孔的法兰盘"，它可能给出一个整体形状大致对、但螺纹孔位置歪了2mm的结果。因为扩散模型的本质是概率生成，它不太理解"孔位必须落在螺栓分度圆上"这种硬约束。
当然，这条路也不是没有用。在概念设计、前期造型发散、玩具手办这类对精度不敏感的场景里，它的速度和人机交互体验确实香。我也见过团队把它跟3D打印结合，用来做快速原型和展览模型，效果不错。但放在结构设计、模具设计这些正经制造业场景里，我目前不会选它作为主路线。
2.2 LLM+参数化脚本生成：让模型"写"出可编辑的实体特征
另一条路，是我更看好的：文本先进LLM，LLM生成一段CAD建模脚本——比如CadQuery、OpenSCAD、PythonOCC代码——然后在本地内核里执行，得到真正的B-rep实体文件（STEP或IGES）。
这么做的好处非常明显：
- 输出天然是参数化模型。脚本里写着
box(120, 80, 8)、hole(diameter=5.2)，改一个参数全模型跟着变，工程上可维护性极强。 - 特征树是完整的。在FreeCAD或SolidWorks里打开，能看到每一步是拉伸、切除、倒角，而不是一坨三角面片。
- 硬约束可以埋进去。LLM生成的代码可以追加后处理脚本，自动检查孔间距、壁厚、公差符号，违反就报错。
说白了，这条路是把LLM当成"一个会写代码、懂点机械常识的建模师"，而不是"一个试图直接捏泥巴的雕刻机"。它输出的不是最终几何，而是生成几何的"操作序列"。CAD软件最擅长的恰恰是重放操作序列，所以这条路跟现有工业软件体系天然兼容。
2.3 两条路线的对比选型
我自己做过一次小规模的对比，用一个提示词"带四个安装孔的钣金支架，长100，宽60，高25，材料Q235，折弯半径3mm"分别跑两条路线：
| 对比维度 | 端到端生成 | 参数化代码生成 |
|---|---|---|
| 输出格式 | 网格/点云/SDF | STEP/IGES/原生实体 |
| 可编辑性 | 弱，需逆向重构 | 强，特征树完整 |
| 尺寸精度 | 厘米级都费劲 | 理论可达毫米以内 |
| 工程约束支持 | 极弱 | 可通过脚本注入 |
| 适合阶段 | 概念造型、视觉预览 | 结构设计、加工前验证 |
| 工具举例 | 各类3D扩散模型 | CadQuery+LLM、OpenSCAD+LLM |
结论很清晰：如果你只是想快速看看效果、做个渲染演示，端到端生成够了；如果你要做能进工艺链的数模，别犹豫，选参数化代码生成。下面我重点讲的就是这条路线。
3. 数据与语义对齐：决定天花板的关键环节
3.1 训练数据从哪来：算法再强也绕不开的数据准备
所有text-to-cad模型的源动力都是数据。公开可用的CAD模型数据集主要有ABC、Fusion 360 Gallery、ShapeNet等。ABC数据集大概有一百万个CAD模型的BREP表示，Fusion 360 Gallery里有大量带设计历史的参数化模型，这对代码生成路线特别有用——因为模型不只给了几何，还给了完整的设计步骤和约束关系。
但有一个很现实的问题：这些数据集都是"只有图没有话"。它们没有配套的自然语言描述，或者说描述都是后来生成的。想要训练一个text-to-cad模型，必须先做图文对。业界常见的做法是先让多模态模型看渲染图写描述，再由人审核，形成一批干净数据。我有段时间也在做类似的事，给一批机械零件写结构化描述，后来发现直接用GPT-4V生成的文本加上人工随机抽检，效率远高于从头纯手工标注。
3.2 CAD领域的"提示词工程"和常规GPT完全不同
在通用场景里，提示词写"一只戴帽子的狗"就能出图，自由度很高。但CAD场景里，提示词必须"结构化"。
我常用的写法是这样：
- 主语：零件名称（支架、法兰、壳体、导轨座）
- 几何参数：长、宽、高、直径、厚度
- 特征列表：孔、沉头、倒角、槽、凸台，每个特征带参数
- 位置关系：居中、均布、对称、对齐、偏置
- 工艺信息：材料、表面处理、公差（能写就写）
举个例子：generate a mounting bracket, overall 120x80x8 mm, four M5 counterbored holes at corners R=5mm from edges, two 6mm dowel pin holes on the centerline, chamfer 1x45° on top edges, aluminum 6061
对比一下随手写的：make me a mounting plate with holes
同一个模型，前面这种描述生成出来的东西基本能直接用，后面那种大概率生成一个形状对但细节乱飞的数模。这不是模型傻，而是CAD本来就讲究精确，提示词就是设计需求文档的压缩版。
另外，方位词的使用要谨慎。CAD模型是三维的，"左边"、"上面"这类词，取决于查看角度，很容易歧义。我建议把提示词写成绝对坐标系视角的语句，比如"沿X轴方向单边偏移10mm"、"位于长边中心F.S."，并且在生成后立刻用视图检查。这不是给模型纠错，是给自己减少沟通成本。
4. 实战复现：基于HuggingFace的Text-to-CAD流水线搭建
4.1 环境准备最容易被忽略的细节
说干就干。我当前用的是一条基本全开源的流水线：用HuggingFace上的text-to-cad模型（现在社区里已经有几个可用的权重）把自然语言转成CadQuery代码，再在本机用CadQuery执行生成STEP文件，最后扔进FreeCAD检查特征。整套流程跑在Windows + WSL2上，显卡用一块消费级N卡够了，显存8G就能跑，不需要多卡。
环境搭建命令大概是这样：
conda create -n text2cad python=3.10 conda activate text2cad pip install transformers torch cadquery jupyter git clone https://github.com/your/text2cad-repo # 这里换成实际项目仓库 cd text2cad pip install -r requirements.txt有一个坑必须提醒：CadQuery最新版本依赖OCP（Open Cascade Python绑定），这个包很容易装失败。如果你用conda，优先加conda-forge源再装，别直接用pip硬装。我第一台机器上就因为版本冲突耗了一下午，最后是conda install -c conda-forge cadquery解决的。
4.2 一个完整的生成例子：从提示词到STEP文件
我用上面那段"安装板"的提示词跑了一次。加载模型之后，调用方式类似这样：
from transformers import pipeline import cadquery as cq generator = pipeline("text-generation", model="your-model-path") prompt = ("Generate CadQuery code: " "mounting bracket, overall 120x80x8 mm, " "four M5 counterbored holes at corners R=5mm from edges, " "two 6mm dowel pin holes on centerline, " "chamfer 1x45 on top edges, aluminum 6061") result = generator(prompt, max_new_tokens=800) code = extract_code(result[0]["generated_text"]) exec(code) cq.exporters.export(result_assembly, "bracket.step")第一次跑出来的代码，成功执行了，但孔位明显不对——四个角的沉头孔全跑到同一侧去了。原因不在模型，而是我的提示词里没写"分布均匀"和"距离角点10mm"这样的几何约束。把提示词改成"holes equally spaced, centers at R=10 from adjacent edges"之后，第二次输出就正常了，导出STEP文件，放进FreeCAD里看特征树，拉伸、到角、打孔、阵列，清清楚楚。
整个过程从输入一句话到拿到STEP，大概花了不到两分钟，其中模型生成代码占了大头。我后来直接把这个调用包成了一个小服务，用Flask接口暴露出来，内部其他同事通过网页表单提交需求，后台自动出数模，省掉了手动建模环节，起码缩短了一半前期时间。
4.3 生成质量的检验：不能只看渲染图
很多人拿到生成的模型，习惯性渲染一下，看着像就认为成了。这是大忌。我的检验流程是四步：
- 几何尺寸检查：用Python脚本自动遍历STEP里所有实体，测量关键尺寸是否在容差内。
- 特征完整性核对：人工看特征树，确认沉头孔、倒角、凸台这些该有的特征都在。
- 可制造性扫雷：壁厚是否小于最小加工厚度、有没有无法出模的负角、孔间距是否小于标准值。
- 干涉检查：如果零件有装配关系，先把相邻零件也生成出来，做一次布尔运算和干涉检测。
第四步尤其重要。text-to-cad目前对"单个零件"的掌控远远好于"装配体"。多个生成零件装在一起，孔对不上、轴线歪掉的情况我遇过很多次。所以我现在养成一个习惯：单件可以直接用，涉及装配的一定要在FreeCAD或CAD软件里做配合验证。这不是模型质量差，是目前这类工具的通用能力边界，提前心里有数比较好。
5. 工程落地中的那些坑：从DEMO到产线的经验
5.1 AI不知道"公差"两个字意味着什么
这是目前最伤脑筋的问题。你让LLM生成一个直径8mm的轴，它给你一个8.0的实体，但不会告诉你这个轴配合孔的时候该选h7还是g6，也不会标注尺寸后面的"+0.015/-0.010"。对设计阶段来说问题不大，但对制造来说，没有公差配合的数模只能算半成品。
我自己试过在提示词里明确写公差：shaft diameter 8mm with tolerance h7, surface roughness Ra1.6模型确实会在注释里写# tolerance: h7，但生成的几何体依然是8.0整，因为CadQuery里做几何实体本来就不需要携带公差符号。真正能落地的办法是，生成完STEP之后再用程序往里面追加尺寸公差标注，或者直接对接PLM系统的时候人工补公差。指望AI一步到位，暂时不现实。
5.2 单位制混乱：毫米和英寸的战争
这个坑是我踩得最狠的一次。有一次生成一个外壳，所有数字看起来都很正常，尺寸"显示"为100x60x5，我以为是毫米，结果导进车间数控系统，机床读出来是3.94x2.36x0.2英寸，工人差点按英寸装刀。原因是模型在生成代码时写的是inch，而我认为默认是mm。
解决的办法很笨但有效：每次生成代码后，强制在代码片段前面注入一条units = cq.Units.MILLIMETER类似的全局常量，并且在导出STEP后用脚本解析文件头部确认单位和实际尺寸量级。如果生成的是一个长度值小于10的物体，先警惕是不是英寸。我也把这个写进了团队内部的生成服务里，作为强制校验步骤，从此再没出过这类事故。
5.3 给AI加"护栏"：后处理与规则校验
单纯让LLM自由发挥，结果是不稳定的。我在流水线里加了两个护栏：
第一个是规则校验层。生成脚本执行前，先静态识别代码里的关键参数，比如所有hole()调用的直径，所有box()的长宽高，然后跑一遍预定义的制造规则。规则包括：最小壁厚不小于0.8mm（按加工工艺），孔中心距不小于板厚的2倍，所有外部锐边默认倒角0.5mm。不满足直接拦截，把错误信息反馈给用户，让用户去改提示词。
第二个是特征锁定。在CadQuery里固定用一套自己封装的标准件库，M3/M5/M6螺纹孔、标准沉头孔、腰型槽，全部预生成好。LLM遇到"装M5螺丝"这种需求，不直接生成几何，而是调用标准库里的现成特征。这样一来，孔口倒角、压铆螺母的底孔直径这些细节就不会让AI自由发挥，模型只需负责位置和尺寸，质量立刻稳定一大截。
这两个护栏加完之后，我从"50%情况下要手工修"变成了"80%情况下直接可用"，生产效率的提升是肉眼可见的。
6. 把Text-to-CAD用起来：适合的场景与不适合的场景
6.1 真正值得用的四个场景
先说判断结论：Text-to-CAD最成熟的应用场景，不是我原本以为的"从零设计一台机器"，而是下面这四类：
- 前期方案快速推敲：客户提需求，先用文字生成5个不同形态的方案数模，渲染出来一起看。不需要精细结构，但能快速对齐方向。
- 标准件库和零件检索：你有一大堆历史数模，让员工用一句话描述来搜，自动匹配到最接近的模型，哪怕不是100%符合也能快速改参数。这比翻文件夹高效一个量级。
- 图纸注释与逆向描述：已有实体模型但缺文档，用text-to-cad反向生成结构化的文字描述，填充物料清单和BOM备注里的特征栏。
- 教学和新人培训：新人想理解"一个带法兰的旋转体"长什么样，直接生成一个给他看，比看十条说明书都直观。
我近期给团队搭的内网工具，核心就是做零件检索。库里几百个结构件，以前靠命名规范找人脑记忆，现在输入"带四个腰型槽的L型固定架"就能直接定位。这也是我目前用下来ROI最高的一个场景。
6.2 别急着在精密和装配场景里用它
反过来，有几类情况，我强烈建议不要现在上线，至少我自己踩过之后收敛了很多：
- 精密配合件：轴孔配合、轴承座、齿轮箱这类对公差、形位公差要求极高的东西，AI生成的几何能看，但离加工可用还有距离。
- 装配体和运动机构：生成单件都问题不大，但它不管配合关系。铰链、滑轨、凸轮这些，让AI一次生成整组，十次里有九次干涉。
- 大曲面A级曲面：车身覆盖件、家电外观这类需要高光顺的曲面，AI生成的自由曲面基本没法用，跟专业曲面设计工具差距太大，老老实实用老路。
- 任何图纸直接下发产线之前：目前我不管提示词写得多完整，生成后都会强制经过一次人工审查。这是流程红线，不是模型能力问题，是一种工程责任。
6.3 我预判的下一步形态
这个方向还很年轻，眼下每两三个月就有新东西出来。我比较看好的下一步是：LLM不再是直接生成命令脚本，而是去驱动一个带约束求解器的原生CAD内核。也就是说，模型输出的是"意图图"——包含特征之间的位置约束、尺寸约束、配合关系，由CAD内核去求解出满足约束的几何。这样一来，AI生成的就不是一个"碰巧长这样"的东西，而是真正符合约束条件的数模。
到那时候，Text-to-CAD才真正有资格叫"设计助手"，而不只是"建模加速器"。眼下这个阶段，我的建议很务实：把它当成一个效率工具来用，用它来生成起始模型、检索历史零件、快速对齐设计方向，然后老老实实把专业判断留在自己手里。只要提示词写得够规整，后处理护栏做得够扎实，它省下来的时间是真金白银，而不是Demo视频里的表演。
