从“你告诉我想要什么”到“CAD自动建模”，text-to-cad这两年算是把AI辅助设计这个赛道真正带火了一个方向。它不是简单把文本渲染成图片，而是让模型直接输出可编辑、可重新参数化的三维CAD模型——换句话说，让计算机从“听懂人话”进化到“帮你画图”。这篇文章我从原理、主流工具、本地实操到翻车经验完整梳理一遍，给想入坑或已经在研究这个方向的你一份可以直接参考的实战笔记。

1. text-to-cad在解决什么问题：设计入口的范式变化

1.1 传统CAD建模的痛点：脑子里有图，手上隔着一层

用过SolidWorks、Fusion 360或者FreeCAD的朋友应该都有这种体验：真正的建模时间花在哪了？不是构思，而是把脑子里的三维构想翻译成一连串的草图、约束、拉伸、旋转、倒角。软件不会读心，它只认操作。一个简单的支架，熟练工也许十分钟能搞定，但你要是让一个非机械背景的人上手，光是搞清楚“先画草图再拉伸”这个顺序就能卡半小时。

text-to-cad要解决的，恰恰就是这个“从意图到操作”的翻译鸿沟。它的目标很直接：你输入一句自然语言，比如“一个带四个圆柱腿的方形桌面”，系统直接输出一个参数化CAD模型文件（通常是STEP或原生建模历史序列），而不是一张渲染图。生成的不是像素，是可以继续编辑、装配、甚至送去做CAE分析的实体几何。

1.2 为什么它不能简单照搬text-to-image那套

很多人第一次听到text-to-cad，会觉得这不就是文生图的3D版本吗？这种理解很容易让人走偏。图像生成是像素密度的分布采样，生成出来是一张位图，你怎么改结构？怎么提取工程尺寸？怎么导出加工？CAD模型本质上是**边界表示（B-Rep）或者构造历史（construction history）**的集合，它包含的是拓扑、几何约束和参数化特征。你让扩散模型去生成一堆三角形网格很容易，但让它生成一个“带圆角、厚度5毫米、孔位间距40毫米”的实体，难度完全不在一个量级。

所以text-to-cad真正吸引人的地方在于：它把**“语义理解”和“结构化几何建模”**这两件事拼在了一起。这也是最近两年学术界和工业界都在拼命投入的原因。

1.3 谁是text-to-cad的核心受益者

• 机械/结构工程师：做概念设计时快速出多个备选结构方案，不用一个个手搓；
• 非专业建模用户：设计师、创客、产品经理，用自然语言把想法快速变成可3D打印的模型；
• 自动化/机器人领域：生成任务相关的夹具、末端执行器结构，甚至能端到端地配合仿真；
• 科研人员：利用生成式方法做设计空间探索、拓扑变体推荐。

这个技术不是要取代CAD工程师，而是把“从零起步画图”这个最枯燥的环节自动化。你依然是那个做决策的人，只是把繁琐的参数设置交给模型去预填。理解了这层价值，再看它的技术实现就容易了。

2. 底层原理拆解：自然语言是怎么一步步变成CAD指令的

2.1 CAD模型的基因：参数化建模操作序列

要理解text-to-cad，首先得回答一个基础问题：CAD模型在计算机里到底存成什么？

答案有很多种。最常见的是B-Rep，也就是用面、边、顶点来描述实体外壳；另一种是网格，像STL文件，主要服务于3D打印和渲染；还有一种是参数化特征树，比如Fusion 360里那个左侧的历史记录列表：草图1、拉伸1、倒角1……每一个特征都是一条指令，模型就是这一连串指令执行后的结果。

text-to-cad领域里，研究人员更偏好最后一种表示。为什么？因为指令序列是可逆、可编辑、可参数化的。如果模型能直接生成“一个操作序列”，用户拿到手就可以改动参数，比如把拉伸高度从20改成30，倒角半径从2改成5。相比之下，生成网格模型虽然视觉上很成功，但无法编辑，工程上一文不值。

2.2 把建模操作序列当成“语言”来建模

这里有一个很关键的思想转变：既然建模本质上是操作序列，那它天然就适合用语言模型那套方法去建模。树干、拉伸深度这些具体数值，可以被离散成一个token序列。也就是说，一段CAD构造历史可以被“翻译”成一段特殊的“外语”，就像英语句子里的单词一个接一个。

NeuralCAD、DeepCAD这些早期工作做得就是这件事：用自编码器的思路把条件CAD建模序列（比如草图+拉伸+旋转等）编码成潜在向量，再把向量解码回建模指令。论文数据里最常用的是Fusion 360 Gallery数据集和DeepCAD数据集，里面包含上万个真实建模操作历史。训练模型学习的就是“什么样的一组建模指令能形成什么样的形状”。

2.3 文本与CAD潜在空间的对齐

有了CAD序列的编码器之后，下一步就是把文本语义嵌进去。这步和视觉-语言模型的思路基本一脉相承：一个文本编码器（比如BERT或者GPT系列）把“一个带四个圆柱腿的方形桌面”编码成文本向量，通过对比学习或者生成式地训练，让文本向量和对应的CAD序列向量在潜在空间中对齐。推理的时候，用户输入一句话，文本编码器算出语义向量，解码器生成一组建模指令，再用底层的CAD内核（比如Open CASCADE或者Fusion 360的建模内核）执行出来。

概括成一句话：text-to-cad = 大语言模型做语义理解 + 序列自编码器做几何生成 + 传统CAD内核做约束求解。这个组合决定了它的上限：语义理解部分决定了它能不能听懂人话，序列生成部分决定了它能不能造出合理几何，CAD内核决定了最终成品能不能被下游工程软件接受。

2.4 扩散模型、LLM和条件控制的新变化

近两年的论文很多在Glide、Stable Diffusion这些扩散模型思路上做迁移，把CAD指令序列当作一个连续或者离散的扩散目标，配合文本条件逐步去噪生成。这种做法的优势是生成多样性好，模式崩塌少。同时也有越来越多工作直接调用LLM，把建模需求解析成结构化的参数化脚本，再用程序化方式执行。这条路的好处是可控性和可解释性比较好，坏处是LLM本身不具备几何直觉，容易做出物理不合理的模型。

另外还有一个值得关注的方向：生成属于“拓扑生成器”而非“单一形状”。也就是说，模型学的不是某一篇文章里特定的台灯，而是学会“台灯”这一类物体的结构骨架，输出时可以随机变化尺寸、比例，甚至生成同类变体。这对设计探索场景来说非常有价值。

3. 当下主流的text-to-cad工具与开源项目盘点

3.1 几个你必须知道的开源项目

我按自己的使用体感和社区热度，把主流项目分成了三类。

第一类：基于扩散模型做CAD指令序列生成

• Text2CAD（MIT那篇论文带起来的）：目前被引最多、社区讨论度也最高的项目之一。整体流程是用LLM把文本输出成结构化指令，然后CAD扩散模型再根据条件生成草图-拉伸序列。它对描述相对机械化的物体（支架、底座、连接件）效果还行，对语义抽象的物体（“优雅的椅子”）表现一般。
• CADLM：这个项目主打“语言模型直接生成CAD参数脚本”，虽然论文里没有太重工业级训练，但思路清晰，适合看代码学习如何把CAD操作序列token化。

第二类：偏向机器人/工程场景的

• Bob the Builder：主要面向机器人操作领域，用text-to-cad生成夹爪、末端工具等与任务强相关的物体。它在提示词里会强调功能目标而不是纯外观，生成结果通常直接配合仿真验证。

第三类：偏交互式的多模态平台

• Zoo（Autodesk Research 方向的Text-to-CAD Zoo）：不是单一模型，而是一系列模型的集合门户。支持文本、图片甚至点云作为条件，输出直接对接CAD工具。我体验下来，它在产品概念阶段的效率提升最明显。

3.2 商业软件和插件的跟进

• Fusion 360的生成式设计模块里已经能看到AI辅助的影子，但目前更多是“指定约束-算法生成方案”的形式，还不是严格意义上的文本直出。
• SolidWorks的云端版本也在尝试语义命令解析，把“打一个直径8的孔在这面中心”这类指令识别成具体特征操作。这条路线目前更多是把LLM当作指令解析器，而不是几何生成器。
• FreeCAD + AI插件：开源社区有不少人尝试直接用本地LLM生成FreeCAD的Python建模脚本，然后用脚本执行生成模型。这种玩法门槛更低，但复杂度一跳水就容易卡壳。

如果只是入门，我建议先跑MIT的Text2CAD和Zoo，社区资料全，遇到问题容易找到人讨论。真要落地到自己的产品里，则要考虑自建微调和后处理管线，而不是直接用现成模型。

4. 本地实操：跑通一条text-to-cad的完整流程

4.1 环境准备清单

我平时跑这些项目用的是一张12G显存的卡（RTX 3060级别），内存32G，系统Ubuntu 22.04。多数开源text-to-cad项目都是基于PyTorch，硬性要求不高，但显存最好别低于8G，否则大模型加载时很容易OOM。

标准的运行环境如下：

conda create -n t2c python=3.10 conda activate t2c pip install torch torchvision --index-url https://download.pytorch.org/whl/cu118 pip install transformers diffusers trimesh opencv-python

建议把Open CASCADE相关的依赖也装上，后面做实体合法性检验会用到。各项目之间依赖差异比较大，最好单独给每个项目建一个虚拟环境，不要图省事混装。

4.2 实际跑一个Text2CAD的流程

官方仓库一般会给一个inference脚本。大体流程是四步：

1. 加载文本编码器和CAD解码器权重；
2. 对输入文本做tokenize和encode；
3. 在潜在空间做条件扩散采样；
4. 把采样得到的指令序列解码成CAD模型文件。

接触最多的调用方式其实是HuggingFace上的Gradio demo，直接把Web UI拉起来，输入句子就能看到模型输出。我建议先玩通Web UI，再回去读推理代码。

一个容易踩的坑是：很多仓库的代码是基于特定版本写的。比如某个项目对transformers版本特别敏感，升级之后可能直接报维度不匹配。号称“装了就能跑”的项目，往往需要用requirements.txt锁版本，不要乱升级。

4.3 提示词怎么写效果更好

text-to-cad不是随便打个句子就万事大吉。模型对提示词的敏感度非常高，我总结下来有三条心得：

• 结构词优先于风格词：写“一个圆柱形底座，顶部有一个长方体安装板”，比“一个现代风格的坚固底座”效果好得多。模型能从前者里提取出实体几何关系，后者只能给出模糊的形状概率。
• 给参考尺寸：虽然目前的模型还不能严格按尺寸生成，但给出尺寸能帮助它锁定相对比例。比如“一个半径50毫米、高度30毫米的圆柱体”。实际生成的数值会有偏差，但比例关系通常更合理。
• 拆成子物体描述：一次性描述一个复杂装配体会让模型乱套。不如拆成“底座是方块，上面竖着两个平行的圆柱支柱”。序列生成模型对“一个零件接一个零件”的结构比较友好。

还有一个很多人忽略的点：确认输出格式。有的项目输出STEP，有的输出JSON形状描述，有的只输出指令序列但需要你在本地用CAD内核执行。搞清楚输出链路格式，是避免“跑半天跑出一堆乱码”的关键。

4.4 验证生成结果

生成一个模型文件之后，别急着导入SolidWorks。先做基础检查：

• 用trimesh直接加载，检查是否为watertight闭合实体；
• 尝试布尔运算（比如和自身做差集），看是否崩溃；
• 把文件导入FreeCAD，看看特征树是否可编辑；
• 检查面数和拓扑连续性，排查是否有自相交面。

我用一个简单的验证脚本，主要是检测模型闭合性和基本尺寸范围。

import trimesh mesh = trimesh.load("output.step", force="mesh") print("is watertight:", mesh.is_watertight) print("bounds:", mesh.bounds) # 简单检查最低高度是否接近零，排查悬空问题 print("min z:", mesh.bounds[0][2])

实测下来，很多模型的生成结果是“视觉上像，几何上坏了”——看着是台灯，但布尔运算一求交，直接报非流形边。所以几何合法性的自动检查，应该成为任何text-to-cad管线的标配环节。

5. 实测翻车现场：那些模型“看着对、一用就废”的时刻

5.1 常见失效模式统计

我自己跑了大概两百多次生成，归纳下来最常见的失效模式主要有三类：

• 拓扑破损：面片有缺口，或者存在非流形边。通常发生在薄壁结构上，比如“带有多条加强筋的盖板”。
• 尺寸逻辑混乱：比如一条椅子腿粗、三条细，或者圆柱体的半径时大时小。这本质上是序列模型在长尺寸数值上注意力不足。
• 特征丢失：提示词里说“中心通孔”，模型却只生成了外轮廓，孔没有打通。这种失误尤其危险，因为视觉上很难发现，但拿去装配或者3D打印，立刻就暴露。

5.2 排查思路：不要急着改prompt，先看哪一环坏了

我一开始遇到这些失败，第一反应是调prompt，后来发现效率很低。正确的做法是先锁定问题出在哪一环。

第一步：检查文本编码结果。把输入的句子输入到模型的文本编码器里，看看输出的向量在潜在空间里是否和CAD序列向量匹配度高。如果文本向量已经漂移，那就是语义对齐问题，需要换描述方式或者微调。

第二步：检查生成出来的序列。把模型输出的token序列可视化出来看，如果序列里出现了“拉伸高度为负值”“草图闭合曲线缺失”这类非法指令，说明是序列生成器的问题，不是文本理解问题。

第三步：检查底层CAD内核执行。有时候序列看起来合法，但Open CASCADE在实体内核求解时失败，这多数是因为数值稳定性问题，跟模型没有直接关系。

这三个环节对应三种完全不同的解决方案：换描述语、修改生成参数、优化后处理。想清楚再动手，比盲目试prompt高效得多。

5.3 一个典型的“灯臂”翻车案例

我试过提示“一个底座为圆盘、灯臂为圆柱的台灯”。第一次生成的结果很惊喜，外形基本接近。但当我尝试在灯臂上增加一个旋转约束，准备做装配时发现，灯臂圆柱的轴线不是完全垂直于底座平面，偏差大概有2度。统计学上看这个偏差很难被发现，但在装配仿真里，2度足以让整个约束系统爆炸。

这种问题无法通过单纯修prompt解决。后来我采取的方案是：生成后用几何算法做轴对齐校正，也就是把圆柱特征识别出来，强制投影到底座法向。这类后处理在工程落地中几乎必不可少，“生成即可用”目前还是不现实的。

5.4 后处理管线建议

结合多次踩坑经验，我现在跑text-to-cad的标配管线是：

• 实体修复：用CAD内核的修复工具自动填补非流形边，或者用体素化再平滑的办法强制闭合；
• 特征简化和参数化：识别圆柱、长方体、平面等基础特征，重新参数化成可编辑特征树；
• 尺寸矫正：根据提示词里的参考尺寸，对模型做整体缩放或者局部拉伸；
• 格式转换：输出STEP、IGES或者原生参数化文件，满足不同下游工具的需求。

这套管线不复杂，但没有它，生成结果基本只能做视觉效果展示，很难真正进入工程流程。

6. 这条技术路线的真实边界与下一步发力点

6.1 短期做不到的事：精确建模、复杂装配、审美判断

我接触过不少产品经理，以为text-to-cad成熟到可以替代工程师做设计，这个预期需要泼一下冷水。目前的模型在处理毫米级精度、复杂装配约束、多零件配合关系上，距离可用还很远。模型也没有审美判断力，你给它描述“造型优美”，它只能按统计分布生成一个大众脸，谈不上风格化设计意图。

所以现阶段最合理的定位是：草图和方案探索工具。适合在正式设计前快速生成一批备选形态，帮工程师拓宽思路，而不是直接出终稿。

6.2 最有价值的应用场景：参数化族扩展和设计变体

在我实际尝试过的工作流里，真正省时间的不是“从文字到全新模型”，而是“从一个基础模型生成十个参数变体”。比如你手工设计好一个支架，写一段描述让它生成同类拓扑的变体，模型作为变形器就非常靠谱。

text-to-cad跟传统参数化建模系统一旦打通，就能实现“由结构骨架到详细设计”的半自动流水线。先用生成式模型给出若干个结构骨架，再由工程师用参数化CAD精修，最后交付CAM。这条路比完全端到端生成更加务实，也会更快落地到制造业。

6.3 未来值得关注的方向

就我个人观察，接下来12个月值得关注的方向有几个：

• 多模态条件融合：文本+草图+点云同时作为输入，解决纯文本描述空间位置信息不足的问题；
• 可控生成：加入连续参数控制（壁厚、孔径、倒角半径），让生成结果能精确对齐工程需求；
• CAD原生生成模型：直接和B-Rep/特征树挂接的生成模型，而不是先生成网格再转换；
• 与CAE联动：生成之后直接跑一次强度仿真，再把仿真结果反馈到生成模型，形成“生成-验证-再生成”闭环。

这些方向指向同一个终点：让AI从“画得出来”进化到“算得过、造得出”。这个过程确实还有不少路要走，但每一个进步都实打实地往工程师桌面上靠近了几厘米。如果你正在考虑把text-to-cad引入到自己的设计流程里，我的建议很简单：先拿一个明确的小项目跑通全链路——不要追求一次性生成完美零件，而是试着让模型帮你做方案筛选，你来做决策和细节优化。这一步跨过去之后，你对这个技术的理解就能超过绝大多数看热闹的人。