text-to-cad实战：从文本到三维CAD模型的自动生成技术解析

这两年“text-to-cad”这个词在三维建模圈子里出现的频率越来越高。简单说，就是你想一个零件长什么样，用几行文字描述出来，模型直接给你生成对应的CAD模型——不用打开软件一点点拉草图、标尺寸、做拉伸切除。我最早看到这类工作是在某次顶会论文列表里，当时还觉得噱头成分大，直到自己亲手跑通了一条完整的生成链路，才意识到这件事确实是能落地的，而且对机械设计、3D打印、快速原型验证这些场景，冲击力比想象中要大。

这篇内容主要围绕text-to-cad的核心技术思路、主流开源方案、实操复现流程和提示词技巧展开。无论你是做机械设计的工程师、搞三维视觉的研究者，还是玩3D打印的爱好者，只要想了解“用语言直接生成三维模型”这件事现在能做到什么程度、原理是什么、自己能不能跑起来，这篇内容都可以给你一个比较完整且可参考的答案。

1. 核心原理拆解：从“一句话”到“三维模型”的完整链路

先聊清楚text-to-cad到底是怎么工作的，不然后面聊工具、聊实操都会飘。

1.1 一条完整的生成链路：理解、规划、建模、验证

很多人以为text-to-cad就是“文本输入 → 模型输出模型文件”这么一步，其实内部是一条相当长的链路，拆开来看至少有四个关键环节：

第一环是语义理解。输入的文本先要被拆解成语义单元，比如“带四个安装孔的矩形底板”，“矩形底板”是主体形状，“四个安装孔”是附加特征，“安装”暗示了孔的用途和大致定位方式。这一步由大语言模型完成，它需要理解自然语言中隐含的几何关系、拓扑关系甚至加工语义。

第二环是参数规划。理解语义之后，模型要生成一套结构化的参数描述，比如底板的长度、宽度、厚度、孔的直径和孔心距。这一步很关键，因为同一个描述在不同情境下可以对应不同尺寸，比如“支架”可以是几十毫米的电子元件支架，也可以是几米的钢结构支架，模型需要根据上下文推断合理的尺寸范围。

第三环是建模操作序列生成。这是text-to-cad最核心的一步。模型需要把参数化描述转换成一连串CAD建模操作——通常表现为CSG（构造实体几何）表达式或草图加拉伸切除的操作序列，再交给底层的几何内核去执行。

第四环是几何验证。生成的模型要经过布尔运算、面片相交检测等步骤，确保实体没有破面、没有非流形边、所有特征都正常生成。这个环节经常被忽略，但实际跑起来很多失败案例都挂在这里。

我自己体会，这个链路和人类设计师做设计的流程非常像。设计师拿到需求后也是先理解语义，再在脑子里规划结构，然后画出草图或者直接建特征，最后检查模型有没有问题。text-to-cad本质上是把人的这套思考过程搬进了模型里，只是速度更快，且不需要你真正动手操作CAD软件。

1.2 大语言模型为什么能生成CAD指令：代码生成能力的自然延伸

刚开始接触text-to-cad时，我一直有个疑问：大语言模型不是用来处理文本的吗，怎么还能生成三维模型？

后来想明白了，关键在中间表示。现在的text-to-cad基本都不让模型直接输出网格或体素，而是让模型输出一段结构化的代码指令，比如一段Python风格的CAD脚本，或者一个JSON格式的CSG表达式树。大语言模型经过海量代码数据的预训练，本身就有很强的代码生成能力，把CAD建模指令当作一种领域特定语言（DSL）来看待，它就变成了一个“代码生成”任务，而不是“三维几何生成”任务。

这个类比可以解释很多现象。比如，为什么text-to-cad模型对复杂文本描述的泛化能力比纯几何生成模型强？因为大语言模型在代码语料里见过大量“描述-实现”的对应关系，它知道“带圆角的底座”通常对应什么代码结构。又比如，为什么模型偶尔会生成语法正确但毫无意义的建模序列？因为它本质是在“写代码”，代码语法正确不代表编译出来的程序行为正确——这条经验在后面排查问题时帮了我大忙。

1.3 三种主流生成策略对比

目前text-to-cad的生成策略大致可以分为三条路线，每条路线的技术栈和优缺点都不同。

基于CSG表达式的路线是早期比较常见的一种方案。模型直接预测一棵CSG表达式树，树的叶子节点是基本体（长方体、圆柱、球等），内部节点是布尔运算（并集、差集、交集）。这种表达方式结构简单，非常适合用大语言模型的序列生成能力来处理。缺点是CSG表达式对倒角、圆角这类自由曲面特征表达能力偏弱，生成出来的零件往往比较“机械感”，看起来像抽象艺术，不够工程化。

基于草图加拉伸的路线是目前更贴近真实CAD建模流程的方案。模型先预测一个二维草图轮廓，再预测拉伸高度、拉伸方向以及后续的切除操作。这种表达方式对应了主流CAD软件里最常用的建模范式——先草绘、再拉伸，生成出来的模型可编辑性和工程实用性更强。缺点是序列更长，训练难度更高，对数据质量的要求也更苛刻。

基于B-Rep直接回归的路线是比较激进的方案。B-Rep（边界表示）是CAD软件内部最核心的几何表示方式，直接回归B-Rep面、边、顶点的拓扑关系，对几何细节的表达最精准，但技术难度也是最高的。这要求模型在理解自然语言之外，还要掌握B-Rep这种高度结构化的拓扑数据格式。这条路线目前更多停留在研究阶段，工程化落地还早。

这三条路线并不是互斥的，很多方案会混合使用。我实际跑下来最大的感受是，选哪条路线基本决定了你能拿到什么样的结果：如果只是想快速生成一个概念模型，CSG路线足够了；如果想生成能直接进CAM软件做加工的模型，最好选择草图加拉伸路线的方案。

2. 代表性方案与选型解析

了解原理之后，我们来看看目前比较有代表性的几个开源方案。我尽量用工程视角讲清楚每个方案的核心思路、数据依赖和适用场景。

2.1 Text2CAD方案：把问题建模成指令生成任务

Text2CAD是这一类任务里架构比较清晰的一个方案，核心思路是把text-to-cad建模成一个指令生成任务，而不是直接生成几何。整体管线分两个阶段：第一个阶段用大语言模型解析输入的文本描述，生成结构化的中间表示；第二个阶段用中间表示驱动底层的CAD内核完成建模。

这样做的好处是解耦了“理解”和“建模”两个环节。文本理解交给大语言模型，这是它的强项；几何建模交给确定性算法，保证生成的模型严格有效。这个思路对于工程应用特别友好，因为你不需要担心模型偶尔生成破面——底层内核保证了生成的可靠性。

但也要清醒看到它的局限性。两个阶段的误差是会累积的，如果第一阶段语义解析产生了偏差，第二阶段的建模结果就会跟着偏。而且这个方案依赖一批高质量配对数据——文本描述和对应CAD模型的配对，这类数据的稀缺一直是制约效果的天花板。

2.2 多模态融合方案：让文本与视觉信号互相补充

除了纯文本驱动，另一个值得关注的路线是把文本描述和视觉信号结合起来。比如，你输入一段“这个零件类似于图片中的结构，但把四个角的孔改为腰型槽”，系统同时理解文本和图像，再生成模型。

这类方案目前还在初级阶段，但方向是对的。纯文本描述力有不逮的地方太多了——“类似”“稍微”“偏一点”这些模糊语义很难转换成精确的建模参数，而一张参考图可以瞬间消除大量歧义。实际工程里，设计师给需求时往往也是口头描述加参考图一起给的，多模态更贴近真实协作场景。

不过说实话，多模态方案的实际效果目前还不算惊艳，跨模态对齐的问题依然存在。文本说“类似”但图片里的结构复杂到根本无法参数化时，模型同样会翻车。现阶段我更倾向于把它当作一个辅助手段，而不是核心方案。

2.3 数据集：撑起整个text-to-cad生态的关键底座

不管哪个方案，都避不开一个问题——数据从哪来。目前比较常用的公开数据集包括若干从海量真实机械零件库中提取的CAD建模序列数据集，以及在此基础上生成的文本-模型配对数据。前者的特点是高质量、大规模，建模步骤完整，但原始数据只有建模序列、没有文本描述；后者的特点是方便直接训练text-to-cad模型，但文本描述往往比较简单，和真实工程语言还有差距。

2.4 选型建议

把我试过的方案放在一起对比，可以给出一张比较直观的选型表：

我的建议很简单：如果只是玩票体验，直接找CSG生成方案，跑通就行；如果要做工程验证，就老老实实选草图加拉伸路线的方案，虽然训练和推理都慢一点，但生成结果至少能进CAD软件继续编辑，而不是只能看不能用的“塑料模型”。

3. 实操过程：本地跑通一个Text-to-CAD模型

理论说再多不如实际跑一遍。下面我给出一个可以复现的实操流程，基于目前比较成熟的开源方案，尽量把环境配置、数据准备、训练和推理的关键步骤都讲清楚。

3.1 环境准备与依赖安装

硬件方面，如果你只是用预训练权重做推理，一张普通独立显卡就够了，显存8GB起步比较稳，16GB会更从容。如果你想自己训练或者微调，建议直接上多卡，显存越多越好。另外如果打算微调，最好先准备一个比较干净的Linux环境，Windows上遇到兼容问题够你折腾大半天。

软件依赖方面，核心是PyTorch、transformers、CAD内核接口库和数据处理相关工具。安装过程我踩过不少坑，最重要的一条提醒是：不要用最新的PyTorch版本，建议锁定在某个项目官方支持的稳定版本上，否则会遇到CUDA算子兼容性问题。

如果要把生成的代码指令转换成真实的CAD模型文件（如STEP或BREP格式），需要安装开源的CAD内核相关库。安装时注意版本要和前向代码匹配，很多诡异报错都来自版本不一致。

3.2 用预训练权重快速体验

拿到项目代码之后，最快上手的方式是直接下载预训练权重跑推理。一般来说这类项目都会提供一个推理脚本，输入一段文本，调用模型生成建模指令，再交给CAD内转换成模型文件。

我实际跑通一个案例的完整步骤如下：

准备输入描述，比如“一个长100毫米、宽60毫米、厚10毫米的矩形底板，四角各有一个直径8毫米的安装孔”。

运行推理脚本时，我注意到有几个参数比较关键。首先是采样温度，默认值是1.0，但实际生成时建议调到0.7左右，温度太高模型会生成一些花哨但无意义的操作序列。其次是输出序列长度上限，CAD建模序列比普通文本要长得多，太短容易截断导致生成不完整，我一般会调大到默认值的两倍。

模型推理完成后会输出一段结构化的建模指令，这时候需要把它送给CAD内核去执行。成功的关键在于输出格式要严格符合约定。如果模型输出的JSON字段多了或者少了，转换脚本很容易直接报错。遇到这种情况，最简单的办法是把采样温度再调低一点，或者检查是不是提示词描述里的尺寸单位、特征描述不符合模型训练数据的分布。

推理脚本跑通之后，你会拿到一个标准的CAD模型文件。拿我生成矩形底板安装孔模型来说，整个过程从输入文本到生成STEP文件，耗时不到一分钟，而且生成的模型在CAD软件里打开可以直接测量尺寸，编辑特征树也可以继续改参数，体验相当完整。

3.3 自建数据与微调训练的简化流程

如果你不满足于用现成模型，想针对自己的产品品类做微调，比如只生成某类外壳零件，那么可以按这个简化流程来操作。

第一步是收集建模序列数据。找一批包含完整建模步骤的CAD零件文件，并从每份文件里提取出建模命令序列。这一步的难度在于数据格式解析，不同来源的CAD文件导出格式五花八门，需要写专门的解析脚本统一格式。

第二步是生成文本描述。原始建模序列没有对应的文本说明，因此需要用大语言模型自动化生成描述，形成文本-CAD序列配对。这里有一个经验：自动生成的描述不能照搬，必须确保描述和建模序列在语义上严格一致，比如序列里是四个孔，描述就只能说四个孔，说成六个孔就成了脏数据，会严重影响模型收敛。

第三步是训练。由于我们并不需要从头预训练，直接基于已开源的权重继续微调即可。微调时注意学习率不要太大，通常为原训练学习率的十分之一到五分之一。批次大小、梯度累积步数也要根据显存大小调整。训练过程中，损失下降的速度比预训练快得多，但如果发现验证集上的指标不升反降，大概率是数据质量出了问题，而不是模型结构有问题。

微调完成之后，可以用一批标注了标准答案的测试文本评估效果。评估指标一般看两个：一个是生成建模序列的准确率，即生成的操作序列和标准序列是不是一致；另一个更实际的是看最终生成的模型在CAD软件里能不能正常打开、有没有破面。我强烈建议你在评估时直接做一次软件打开验证，因为有些序列指标上挺好看，实际建模却是错的。

3.4 实操中的硬件与时间开销

再聊一下大家比较关心的算力开销。推理阶段还好，就是标准的单卡负载，一般几秒钟到几十秒钟就能出结果。训练阶段就不一样了。我记得第一次跑训练，看到日志里显示单轮要几个小时，整个人是有点崩溃的，而且后面还有很多轮要跑。建议第一次训练时先用最小参数量和小规模数据把流程跑通，确认一切正常之后再上完整数据和规模，否则排查问题的时间成本高到离谱。

3.5 实操流程速查表

为了让你少踩坑，我把上面整个实操流程浓缩成一张速查表：

4. 提示词设计与常见问题排查

这部分可能是实操里最让人头疼的环节。同样的模型、同样的参数，描述得当和描述不当，生成结果天差地别。我花了很多时间摸索提示词规律，也踩了不少坑，现在把经验整理出来。

4.1 提示词设计的关键规律与模板

我在测试中发现，text-to-cad对提示词最敏感的三个要素是：尺寸信息的完备程度、特征描述的顺序、以及描述中是否包含定义模糊的形容词。

尺寸信息很好理解，但很多人会忽略单位的一致性。模型训练数据里混用了毫米、厘米、英寸，如果你的描述里一会儿用毫米一会儿用厘米，生成的模型尺寸会非常不可控。建议在一条提示词里从头到尾使用同一单位，并且把每个关键尺寸都显式声明出来。

特征描述的顺序也很关键。经验法则是：先说主体形状，再说主要特征，然后说附加特征，最后说细节要求。这和人做设计的顺序是一致的，模型从训练数据里学到的模式也是如此。如果你一上来就描述安装孔，再补一句底板尺寸，模型混乱的概率会大很多。

模糊形容词需要谨慎使用。“较大的”“稍微厚一点的”“类似某个零件”这类描述在人类沟通中没问题，但对文本生成模型来说，它能发挥的空间完全取决于训练数据里是否有类似的映射。如果必须用模糊描述，建议同时给出一个具体数值做锚点，比如“厚度在10毫米左右但可以略厚”，这比“厚一点”要可靠得多。

我自己总结了一套比较好用的通用提示词模板，你可以直接套用：

[主体形状]，总尺寸为[长]毫米X[宽]毫米X[高]毫米。在[位置]有[数量]个[特征类型]，特征尺寸为[尺寸]。需要[圆角/倒角/其他细节]，圆角半径为[半径]。所有尺寸单位均为毫米。

这里有个容易漏掉的点：提示词末尾的“所有尺寸单位均为毫米”这一句往往能明显提升生成稳定性。原因可能是它起到了格式锚点的作用，让模型更倾向于按照训练数据里的标准格式输出。

4.2 对象的拓扑合法性与可编辑性排查

生成了模型之后，第一件事不是激动，而是做两个检查。第一个检查是拓扑合法性：在CAD软件里运行检查几何完整性的功能，确认没有破面、没有非流形边、没有零厚度薄壁。第二个检查是可编辑性：看看特征树里是不是真的有可识别的特征，还是只有一个导入的“哑实体”。

我遇到过最典型的翻车案例是：模型生成的BREP文件在CAD软件里能打开，看起来形状也对，但特征树是空的，整块模型是一个不可编辑的实体。这种结果对于纯3D打印用途还能接受，但对于需要后续修改设计参数的实际项目来说就是废的。排查后发现原因是训练数据中相当一部分样本本身就缺少完整特征树，模型学到的是“只要形状对就行”的模式。这也解释了为什么数据质量比模型结构更加决定效果上限。

4.3 常见问题速查表

把我跑text-to-cad过程中遇到的问题整理成一张表，方便你排查时快速对照：

4.4 我踩过的几个印象深刻的坑

排查过程中有几个坑，印象特别深，在这里单独展开说一下，希望你能避开。

第一个坑是温度参数与生成质量的关系认知。我一开始没有调整采样温度，用默认的1.0直接跑，结果生成的模型总是会多出一些莫名其妙的额外特征，比如明明只要求四个孔，模型额外生成了一圈装饰性槽位。通过可视化建模序列发现，温度偏高导致模型在概率分布上采样到了许多低概率分支，生成了一些人类不会选择的建模路径。把温度降到0.7之后，这个问题基本消失了。

第二个坑是输出格式的严格性。某次我修改了提示词模板，加了一句“用毫米作为单位”，结果生成结果的输出格式直接变成了非法JSON，导致后处理阶段直接崩溃。折腾了很久才定位到问题是：模型从训练数据里学到的输出格式是不带那句额外注明的，加上这句让模型迷惑了。这个案例让我意识到：提示词模板的设计要和模型训练数据的分布对齐，不能凭想象加东西。

第三个坑是建模序列的重复循环问题。模型生成的指令中偶尔会出现大段完全相同的重复片段，就像文本生成里的死循环。这是序列生成模型的常见毛病。排查后发现某些重复片段没有实际建模效果，但对推理时间影响很大。后来我在后处理阶段加了一个重复序列检测，遇到重复循环就提前截断，救回来不少推理时间。

第四个坑是模型输入描述与训练数据分布严重不匹配的情况。试过用很口语化的描述，类似“我要一个那种四四方方的板子上头带几个洞的”，模型生成的模型惨不忍睹。之后我把所有中文描述都先翻译成相对规范的工程语言再输入，效果有了质的提升。如果想让模型适配口语化描述，唯一靠谱的办法是在微调数据中增加口语化样本。

5. 技术局限与后续扩展

把该说的实操讲完之后，我想站在更宏观的角度聊聊这项技术的现状边界和后续可以扩展的方向，希望你也能对它有一个更符合实际的心理预期。

5.1 现阶段绕不开的技术天花板

截至我目前的实际使用体验，text-to-cad离完全替代CAD操作员还有相当距离，比较明显的局限有三个。

第一个是复杂装配体的生成能力很弱。现有的方案基本停留在单零件层面，对装配体这种需要处理多个零件相互约束、配合关系、运动关系的场景，还没有看到的成熟方案。哪怕只是“两个齿轮啮合”这种简单装配，现有模型也搞不定。

第二个是对自由曲面的处理能力有限。工业设计里大量使用样条曲面来构建流畅的外形，但多数text-to-cad方案在这方面的能力很弱。CSG表达本身就不擅长自由曲面，草图加拉伸的表达方式虽然能处理一些，但和真正意义上的A级曲面建模差距明显。

第三个是生成结果的可控性不足。普通的文本生成，如果结果不满意，可以改一个词再生成一次。但CAD模型涉及尺寸、位置、拓扑的精确控制，改一个词往往会导致整体重建。如何实现对生成结果的局部精细控制，目前还没有特别优雅的办法。

不过我觉得，这些局限恰恰说明这项技术还在很早期。早期意味着挑战多，但也意味着谁先跑通某些能力谁就占据先机。我在本地微调模型之后，最深的感觉是：技术的边界其实比论文里写的要灵活得多，很多问题可以通过工程手段绕过去。

5.2 后续可以尝试的几个扩展方向

如果你也想在这个方向上继续折腾，我建议关注这几个扩展方向。

第一个方向是文本驱动的模型局部编辑。与其每次从零生成，不如让模型基于现有模型做局部修改。比如输入“把这个底板的厚度改成15毫米，然后重新生成安装孔位置”，模型只需要更新参数，不需要重建整个模型。这个方向如果打通，价值比全量生成更大，也更贴近真实设计场景的迭代逻辑。

第二个方向是融合拓扑优化。把拓扑优化和text-to-cad结合起来，让模型不只生成几何形状，还考虑力学性能约束，比如“生成一个承受1000牛载荷、最大应力不超过200兆帕的支架”。这条路径一旦走通，将直接进入工程设计主流程。

第三个方向是领域定制微调。通用模型对某个细分领域的效果通常不够好，但经过领域数据微调之后，效果提升会非常显著。比如只做散热器或者只做塑料外壳，都用不了太多数据，效果提升却很明显。

第四个方向是多模态输入。前面提到文本加图像是目前比较务实的方向，未来还可以探索文本加手绘草图：手绘草图约束拓扑特征，文本约束尺寸和加工要求，两种模态互补，可以显著提升描述效率和准确度。

说实话，text-to-cad现在更像是一个“能跑通但不够强”的领域。它既不神秘，也不完美，但它切切实实改变了“从想法到模型”这条链路的工作方式。我自己的感受是，与其等它完全成熟再上手，不如现在就用起来，在用的过程中建立对这项技术的直觉。毕竟工具是拿来用的，不是拿来供着的。