前两天一个做机械设计的哥们儿跟我吐槽说客户发来一句话“我要一块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做到可靠那对传统建模工作流来说就是一次彻底洗牌。我把这几条路整理成一个对比表方便你评估技术路线交付物参数化程度上手难度我的评价Text2CAD学术项目CAD操作序列较弱序列重建后编辑有限高需GPU和环境配置研究方向价值大工程化低Zoo在线Text-to-CADCadQuery代码和模型预览强代码即参数极低浏览器即可当前最值得先玩CadQuery/OpenSCAD加LLM本地代码脚本强完全参数化中需Python基础最适合深入学习和落地商业软件内置AI辅助生成的特征取决于软件实现低偏辅助端到端还早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, forConstructionTrue) .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; mtrimesh.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的在线页面开始输入第一句话的那一分钟你就能感受到这个方向未来到底有多能打。