文本转CAD实战：一句话生成可编辑的三维参数模型

前两天一个做机械设计的哥们儿跟我吐槽，说客户发来一句话：“我要一块400×300的安装底板，板厚5mm，四角倒R10圆角，中间按200×120的间距开四个直径12的孔。”就这么一句话，他在CAD里拉矩形、倒圆角、定孔位、加约束，折腾了大概二十分钟。他说要是哪天能把这句话直接丢给软件，让软件自己把模型建出来就好了。我回他：你说的这个东西，圈子里的正式叫法就是text-to-cad，而且过去这一年多，已经真有人把它做成能跑的工具了。

text-to-cad，翻译成人话就是“文本转CAD”：输入一句自然语言描述，AI直接输出一个可编辑、可制造、可导入专业CAD软件的模型。我今天想聊的不是论文里的概念框架，而是我作为一个天天和模型打交道的人，把这几个开源项目装起来、跑demo、写提示词、翻车再爬起来之后，得到的真实体感。这篇文章会覆盖它到底解决什么问题、底层怎么运作、哪些路线真的能跑、以及它在哪些场景下会让你怀疑人生。如果你画图画了几年，或者刚接触3D建模但总觉得自己在“手工翻译需求”，这篇文章可能比你去刷十篇新闻稿都有用。

1. 从“人懂机器不懂”到“一句话出模型”：这个需求到底有多痛

先说个反直觉的结论：CAD建模真正难的地方，压根不在操作层面，而在“把一句人话翻译成一棵特征树”的过程。这个翻译过程平时不显山不露水，但它的成本被所有从业者严重低估了。

1.1 CAD建模的门槛不在画线，而在把话说清楚

CAD软件天生是给“精确参数”设计的。你要画一个孔，就得告诉它圆心坐标、直径、深度、方向；要倒一个圆角，就得指定边、半径。这些约束每一项都不难，难的是把它们组合起来的时候，你脑子里其实在运行一段隐藏的程序——先建哪个特征、后建哪个特征、哪个面作为草图基准面、哪个尺寸作为驱动参数。

我见过太多新人卡在这个地方：软件命令都会，但拿到一个需求，不知道“从哪下手”。反过来看，客户或者设计提需求的时候用的全是“大概、差不多、居中、靠边、对称”这类模糊词。模糊意图和精确几何之间这条鸿沟，才是建模的第一道门槛。

text-to-cad想拆掉的就是这第一公里。它不强求你先把“板厚5毫米”转成“沿Z轴拉伸5毫米”这个动作，而是让你保持“说人话”的状态，让模型去完成翻译。这个意义，只有真正被CAD的精确性折磨过的人才懂。

1.2 需求来回改的时候，重新生成比手动修改更划算

我自己最烦的是来自客户的“高频微调”。孔距从200改成180，板厚从5改成6，圆角半径从R10改成R12。每次改动都不难，但你得打开文件、找到对应特征、双击尺寸、改数字、等重建、检查有没有连带报错。一次五分钟，一天改五次，烦不烦？

text-to-cad的另一个价值在于：它让“重新生成”变成一种正常操作。既然AI生成一个新模型只要几十秒，那“改尺寸”这个动作就可以退化成“改描述”——把需求里的数字换掉，重新生成一遍。这个思路听起来有点浪费，但在概念设计阶段，它的试错效率远高于传统方式。

1.3 谁在真正等这个功能

我观察下来，对text-to-cad需求最迫切的不是资深工程师，而是这几类人：

• 结构设计前期的方案探讨者。他们要的不是最终图纸，而是“客户一句话对应的大致三维形态”，用来做沟通和评审。
• 3D打印爱好者。很多人脑子里有想法但没系统学过SolidWorks或者Fusion 360，想快速把“一个能放手机和钥匙的小托盘”变成STL文件。
• 采购、市场、售前这类跨岗位角色。他们经常需要“看起来像那么回事”的模型放在PPT或者BOM沟通里，但不愿意为此去学一套CAD软件。
• 产品设计教育场景。老师希望学生先建立“需求到形态”的映射感，再回头学具体工具，text-to-cad很适合做这种脚手架。

说到底，这个技术不是在替代会画图的人，而是把“画图”这件事的入口，从专业软件拉回到日常语言层面。

2. 拆开看原理：一句话在底层要经历什么才变成模型

如果你以为text-to-cad是“AI看了图，然后画了张图”，那就完全想偏了。它背后的原理链比这复杂得多，也优雅得多。

2.1 CAD模型不是一张图，而是一棵操作树

先要搞清楚一个底层事实：CAD模型在计算机里从来不是“一张三维图片”，而是一棵树。这棵树上的节点是“拉伸”“切除”“旋转”“倒角”“阵列”这些特征，分支是特征的草图基准面和参考边，参数则挂在各个节点上。

举个例子，一个带四个孔的底板，在工程师眼里是“一块拉伸出来的矩形板，减掉四个圆柱实体”。同样的外形如果用三角形网格（STL）来表达，就是几千个小三角面片拼出来的空壳。网格模型看着一样，但无法编辑、无法加约束、无法改尺寸、无法出工程图，加工软件也没法直接识别。

所以text-to-cad的终极目标，不是输出一张STL网格，而是输出这棵“操作树”。有了操作树，模型才是参数化的、可编辑的、可制造的。这一点决定了后面所有技术路线。

2.2 大模型真正干的活：把描述翻译成CAD操作序列

这里就说到核心了。CAD的操作树在底层其实可以展开成一串有序的指令：画一条直线、画一段圆弧、拉伸这个草图、在这个面上画圆、用这个圆去切除……这条指令串，本质上就是一种序列。

2024年公开的Text2CAD相关研究，干的正是这件事：把海量CAD零件拆解成这样的操作序列，做成数据集，然后用大语言模型去学习“自然语言描述”和“操作序列”之间的映射关系。训练完之后，你给它一句“带四个安装孔的矩形安装板”，它输出的不是模型文件，而是一串类似CAD宏命令的操作序列；软件再按这个序列逐步执行，才生成最终模型。

这个思路可以打个比方：你请一位厨师做菜，他不直接给你端菜，而是先写了一份精确到克数和分钟数的标准菜谱，然后由后厨按菜谱出菜。大模型在这里写的是“菜谱”，也就是程序化的建模步骤，不是直接变出成品。

2.3 最难的一环：把“孔距50”变成真正的参数约束

外行人看text-to-cad，觉得难点是“理解语言”；我自己跑过之后才明白，语言理解早就不是瓶颈了，真正的瓶颈是几何约束。

你说“两个孔的中心距是50”，模型如果只是把两个圆心坐标设成(10,10)和(60,10)，那么它只是“碰巧尺寸对”，并没有建立“距离约束”。等你想把板从100改成120，这两个孔不会跟着保持居中。这种“假尺寸”在工程上是灾难，因为设计变更永远存在。

所以现在更靠谱的路线，是让模型生成参数化程序。比如用CadQuery这类代码化建模库，把“中心距50”写成distance = 50这个变量，后面所有的孔位计算都基于它。到时候你改一个变量，整个模型自动重建。这也是为什么我后文会更推荐“程序化建模”这条路线——因为它在约束表达上天然比直接生成坐标值更接近真实CAD。

3. 我实际跑通的几条text-to-cad路线

纸上谈兵没意思，我把目前能玩的几条路都实际跑了一遍，从纯学术项目到在线工具，再到本地可复现的组合方案。结论是：每条路都能跑，但成熟度差得远。

3.1 论文那条路：Text2CAD项目的测试体验

先跑的是学术界的Text2CAD项目。这套东西的思路很正：构建了一个包含几十万对“文本提示-CAD草图序列”的数据集，并把提示按难度分成多档——从“一个矩形”这种话都说不全的简单句，到“带法兰和加强筋的L型支架”这种复杂描述。

实际试下来的感受是：对简单描述，它能给出逻辑基本正确的草图序列和拉伸操作，输出能出模型；对复杂描述，生成的操作序列经常在布尔运算或镜像特征上出问题，结果就烂了。而且这套东西的工程化程度还停留在论文配套水平——环境依赖重，出图流程绕，没有那种“丢进去就出结果”的畅快感。适合当研究参考，不适合当日常工具。

3.2 在线工具那条路：Zoo的Text-to-CAD服务

相比之下，Zoo的Text-to-CAD就友好得多。它的玩法是你在网页对话框里输入“一个120x80x10的底板，四个角打孔”，后台用LLM生成一段CadQuery代码，然后直接在网页上给你渲染出三维预览。

我特别欣赏它的一个设计：它把生成的代码也给你看。这意味着，如果你不满意，可以自己改几行代码再重新生成；如果满意，这段代码还能拿回本地用CadQuery跑出STEP文件。这种方式让AI生成的模型天然具备参数化能力，后续修改完全可控。

用下来的缺点是它擅长“它见过的典型零件”，一旦你提的需求涉及复杂曲面、钣金或装配，它就开始胡来。但作为快速验证“这个方向靠谱不靠谱”，它是目前体验最顺的。

3.3 本地可控那条路：CadQuery/OpenSCAD加LLM的灵活组合

这是我自己最常用、也最推荐入门者试的一条路。思路很简单：让大语言模型直接生成CadQuery代码，然后你在本地用Python执行这段代码，导出你想要的格式。

CadQuery是我很喜欢的工具，它用写代码的方式建模，底层基于OpenCASCADE几何内核。一段写好的CadQuery脚本，本质上就是一个参数化模型——改动脚本里的变量，模型跟着变。把大模型和CadQuery拼在一起，等于让AI替你写“可编辑的建模脚本”，而不是让它直接造一个不可控的黑盒模型。

好处很明显：出错能改、逻辑透明、能一步步查。坏处是需要一点代码基础，你可能要在本地装Python环境，这确实会劝退一部分纯画图用户。

3.4 商业CAD软件的AI功能现在到什么程度

很多人问我，那SolidWorks、Fusion 360这些老牌软件是不是也上了text-to-cad？我自己的观察是：商业软件目前更偏“辅助”，而不是“端到端生成”。比如Fusion有生成式设计，但操作逻辑是从功能要求反向优化造型；很多软件也开始做属性自动识别、尺寸自动标注，但离“把一句自然语言变成完整特征树”还差着不小的距离。

这其实不奇怪。商业CAD的核心资产是几何内核和特征历史，它们没那么容易把生成权彻底交给一个LLM。反过来想，如果哪天真有一家商业软件把text-to-cad做到可靠，那对传统建模工作流来说就是一次彻底洗牌。

我把这几条路整理成一个对比表，方便你评估：

4. 复现记录：从一句需求到一份可编辑的STEP文件

前面讲了半天原理，现在进入动手环节。我把话放在前面：下面这一套不是玄学，是我实际跑通过的工作流。你不用跟我的步骤一模一样，但照着走一遍，你就能直观理解“文本→参数化模型”到底是怎么发生的。

4.1 先把人话翻译成AI偏好听的提示词

很多人第一次玩text-to-cad，上来就输入“帮我做个底板”，结果AI回一个乱七八糟的方块。这不怪AI，怪你不会提需求。把自然语言翻译成AI能处理的结构化描述，才是这个流程里真正的技术活。

我自己的经验是，提示词里至少要说清四件事：形状类型、关键尺寸、特征位置、特征数量。举个例子，别写“四个角的孔”，写“四个直径为6的通孔，圆心距离相邻边10毫米，分布在矩形四角”。听起来啰嗦？但你要知道，AI的上下文窗口足够大，它不怕你话多，怕的是模糊。

我写提示词的正反例子：

• 模糊版：“一个带孔的板”
• 清晰版：“生成一个120x80x10毫米的矩形安装板，四个角倒R8圆角，在四角内侧各打一个直径6毫米的通孔，孔圆心距相邻边均为10毫米”

后者几乎百分百能生成合理模型，前者纯看运气。

4.2 用CadQuery代码把模型“说”出来

当你把上面这个清晰版需求丢给一个会用CadQuery的LLM时，它大概率会生成类似这样的代码：

import cadquery as cq # 底板主体：120x80x10 plate = cq.Workplane("XY").box(120, 80, 10) # 四角竖直边倒R8圆角 plate = plate.edges("|Z").fillet(8) # 在顶面上建立工作平面，画100x60的辅助矩形，取四角作为孔位 plate = ( plate.faces(">Z").workplane() .rect(100, 60, forConstruction=True) .vertices() .hole(6) ) cq.exporters.export(plate, "baseplate.step")

这段代码的逻辑拆开看很清晰：先创建一块120毫米乘80毫米乘10毫米的矩形方块；然后选中所有平行于Z轴的边倒圆角，倒角半径8，这样四角就圆了；接着选顶面作为工作平面，画一个100乘60的辅助矩形——因为底板是120乘80，辅助矩形每边内缩10毫米，所以它的四个顶点正好是孔心位置；最后在四个顶点处各打一个直径6的通孔。

要我点评的话，这个生成质量已经能用了。而且最妙的是，因为你拿着的是代码而不是一个死的模型，以后客户说“孔距再大点”，你只需要改辅助矩形的尺寸，模型自动全盘更新。

如果你身边没有能用CadQuery的LLM，也可以手动感受一下这套流程。装环境很简单：

pip install cadquery

然后跑上面的脚本，目录下就会出现baseplate.step文件。

4.3 导出、查看、验证三步走

拿到STEP文件之后别急着高兴，验证工作不能省。我自己习惯再导出一份STL，用网格检查工具看看模型是不是一个“封闭水体”。这一步能筛查大多数低级错误。

STL可以用CadQuery顺手导出，然后跑一个快速检查：

pip install trimesh python -c "import trimesh; m=trimesh.load('baseplate.stl'); print(m.is_watertight, m.bounds)"

is_watertight如果输出True，说明模型表面封闭，基本可以拿去切片或者继续编辑；如果输出False，说明有破面，十有八九是布尔操作或圆角出了问题。然后再用FreeCAD或者Fusion 360把STEP文件打开，检查一下关键尺寸是不是和你的需求一致。

这一步非常关键，因为LLM生成的代码经常“看着对”，但某个参数会把尺寸放大十倍，或者圆角半径大到把整个特征吃掉。如果不验证直接拿去加工，轻则浪费材料，重则闹笑话。

4.4 我翻过的一个典型车：单位混用

说到验证，分享一个我真实踩过的坑。有一次我让AI生成一个“长100毫米的导向轴”，它给出的代码是box(100, 20, 20)，数值看起来没毛病。但我导入Fusion 360的时候没注意单位设置，软件默认按英寸解析，结果这根轴瞬间变成了2540毫米，几乎顶到天花板。

这个问题的根因在于：CAD代码里的数字本身是“裸数据”，没有单位语义。同一个数字，在毫米和英寸体系下完全不是一回事。后来我的处理方式是：在提示词里强制带上单位，比如“长度100毫米”，并且在导出STEP时主动在文件名或者元数据里标记单位，导入时再核对一次。这不算技术问题，但实操里最容易翻车的就是这类“土问题”。

5. 能生成不等于能用：真实世界的失败模式与排查思路

把话说透：现在的text-to-cad距离“开箱即用”还有距离。我跑了几百条提示词，遇到了大量失败案例。把失败模式总结清楚，比吹这个技术多厉害更有用。

5.1 拓扑错误：看着完整，一检查就是破面

最隐蔽的失败是拓扑错误。模型在预览窗口里看起来很完整，但导出后要么是坏体，要么导入CAM软件时报“几何无效”。

根因通常是操作序列里布尔运算的顺序错了，或者圆角半径和某个特征冲突，导致内核生成了自相交的边界。排查思路很简单：不要只用眼睛看渲染图，一定要用工具检查实体的有效性。在FreeCAD里可以运行“检查几何体”，或者像我前面那样用trimesh查STL的水密性。如果发现破面，最省事的方案不是去修，而是修改提示词、重新生成——这正好发挥出“生成式”的优势。

我自己的经验是：涉及圆角、薄壁、和多个切除特征叠加的时候，破面概率会明显上升。这时候可以把需求拆简单点，比如先生成主体，再加孔，再倒角，分两步生成再合并。

5.2 参数化是假的：尺寸只是碰巧对

这个前面提过，但值得单独说。AI生成坐标的时候，经常把“两个孔中心距50”实现成“第一个孔在(10,10)，第二个孔在(60,10)”。单看外形，确实就是50，没问题。但你只要把底板拉长，孔的位置不会跟着动，因为坐标是死的，约束是不存在的。

判断方法也简单：拿到代码后，找一个尺寸变量，改掉它，重建，看看别的特征有没有跟你预期地联动。如果只是局部变了、别的地方没反应，那你拿到的就是一个“非参数化模型”，它只适合一次性使用，不适合后续设计变更。

这也是为什么我一直强调要走程序化建模路线。CadQuery代码天然用变量表达尺寸，你让AI把“孔距”写成hole_spacing = 50，后续所有计算都引用它，参数化就成立了。

5.3 语义分歧：同一句话在不同领域是完全不同的模型

text-to-cad最让我头疼的失败，不是技术做不到，而是语言本身的多义性。你跟AI说“一个带法兰的管子”，它可能生成一个一端带圆盘的管子，但法兰的尺寸、螺栓孔数量、密封面结构全都没有。这在工程师眼里根本不是一张可用的法兰图。

什么意思呢？自然语言对专业领域的描述能力是有天然缺陷的。同一个词，机械、建筑、Pipeline、汽车四个行业能解读出四种模型。目前LLM的默认做法是“猜一个最常见的”，但“常见”不等于“你要的”。

缓解办法是：给AI足够的上下文约束，把领域词汇展开成几何描述。“法兰”不行，就写“端面有一个直径80、厚度8毫米的圆形凸台，凸台上均布四个直径9毫米的螺栓孔”。话虽然啰嗦，但生成出来的东西至少是可用的。

5.4 特征一多就崩：复杂度是有上限的

最后一个规律性发现：当描述涉及的特征数量超过七八个时，生成成功率会断崖式下降。原因很直观，LLM在做长序列生成时，前面的错误会逐级累积，到了后面的特征，几何内核已经处于一个“半坏”状态，任何新操作都可能引爆冲突。

所以我的工作习惯是“一个模型一个模型地生成，再手动装配”，而不是幻想一次生成一个完整的装配体。text-to-cad现在最好的应用场景也是单零件、中等复杂度、参数清晰的东西；模具、装配体、大型结构件，请老老实实回CAD里做。

我在实际试玩这几个项目的过程里，最大的收获其实不是“AI能建模了”，而是“我们终于可以直接从需求出发探索方案了”。以前我画三个候选方案，每个二十分钟，一个上午就没了；现在让AI先吐十张不重样的草图，我从中挑两个细做，效率完全是两个维度。现在的text-to-cad还做不到开箱即用，但它的工作流已经能嵌进日常。如果你想试，我建议从Zoo的在线页面开始，输入第一句话的那一分钟，你就能感受到这个方向未来到底有多能打。