在CAD软件里画一个螺栓我可能需要十分钟但如果直接用一句话描述“一个直径12毫米、长度60毫米、头部为六角的公制螺栓”让系统自动生成三维模型可能只需要几秒。这就是text-to-cad要解决的问题。最近这半年text-to-cad这个概念频繁出现在设计圈和AI圈的讨论里它走的是从自然语言直接生成CAD模型的技术路线跟常见的“文生图”完全是两个方向。很多设计师第一反应是“终于不用自己拉草图和做约束了”但真上手试过之后会发现这条路还没有想象中那么成熟可玩性已经很高了。这篇内容我会把text-to-cad的技术原理、主流实现路径、可复现的本地Demo以及我在实际使用中踩过的坑和排查思路一次性讲清楚。不管你是搞机械设计、3D打印还是产品概念验证只要想了解用文字生成可编辑三维模型的当前边界这篇应该能帮你省掉很多试错的时间。1. text-to-cad到底做了什么先搞清楚它能替换哪一段工作流很多人第一次看到text-to-cad的时候会把它跟AI生成图片或者生成Mesh网格混为一谈。实际上完全不是一回事。图片生成模型输出的是一堆像素即使类似深度图也只是“看起来像那么回事”。而text-to-cad的目标是输出真正可用于工程设计和制造的几何定义比如STEP文件、参数化脚本或者带有完整特征树的BREP实体模型。换句话说它要生成的是“可被CAD软件继续编辑、可被加工制造”的东西而不是一张好看的渲染图。1.1 它真正解决的痛点在传统设计流程里把想法变成三维模型通常要走这样的路先画草图然后添加几何约束和尺寸标注再拉伸、旋转、阵列最后倒角打孔。这套流程熟练工做起来其实也不慢但问题在于它强依赖操作者的经验而且很多重复性工作完全可以被语言描述替代。比如标准件库里的螺丝、螺母、法兰、轴承座这些零件形状相对固定用文字描述几秒钟就能说清楚可建模却要花几分钟甚至更久。text-to-cad的意义就在这——把那些有规律、可参数化的几何体生成交给算法让设计师腾出手去处理真正需要创造力的问题。1.2 它的能力边界别指望它一次生成复杂装配体这里必须泼一盆冷水。目前的text-to-cad系统哪怕是效果最好的那几个开源模型也大多停留在“单体零件”和“常见特征组合”的层面。你让它生成一个带有内部流道的冷却水套或者一个包含二十个零件的装配体它会直接胡编乱造。即便是生成单体零件如果描述中包含了太多相互矛盾的几何条件比如“外径30毫米且壁厚达到10毫米”同时“内径必须25毫米”模型如果没有理解到容器壁厚的含义就会输出一个无法求和的几何体。所以在实际使用的时候最好把需求拆成“主特征次要特征”的描述一步一步让模型生成再用传统工具把多个结果装配起来。2. 从一句话到三维实体底层技术链路拆解text-to-cad之所以能实现不是靠单一模型而是靠一条完整链路。这条链路由自然语言处理、几何推理、参数化求解和格式转换四部分拼接而成。我拆开讲。2.1 语言模型如何“听懂”几何语义第一个环节是让模型理解“直径12毫米”“经过圆心的孔”“与这个面相切”这类几何语义。这里起作用的是大语言模型但跟我们日常聊天那种理解还不太一样。专门为CAD微调的语言模型会在大量“文本—三维模型”配对数据上做训练把“直径”关联到D把“六角”关联到六棱柱的侧面数把“沉头孔”关联到一组拉伸和旋转的布尔运算。我见过一个典型的处理方式模型先把自然语言指令解析成一棵语法树比如“主实体—细节特征—位置关系”然后再把这棵语法树映射到一系列建模命令。有些系统用的是隐式的方式直接让模型在特征参数空间中输出数值向量。但无论哪种背后都需要经过空间关系推理也就是把一个概念比如“倒角深度2毫米”转化成一个可执行的圆角操作。2.2 参数化表达比直接生成网格更有价值这里有技术方向上的分歧。有些模型试图直接从文本生成体素或者点云然后再用Marching Cubes之类算法提取网格。问题在于这样得到的网格只是一堆三角面片没有特征树也没有参数关系丢进CAD软件里就是一个“死模型”改个尺寸就得从头再来。所以真正面向工程设计的text-to-cad几乎都会选择参数化表达作为中间表示。参数化表达常见有两种形式。第一种是建模脚本比如用类似Lisp或Python的脚本语言描述实体几何第二种是显式参数列表比如“长方体长10宽20高30圆柱半径5高15两者求并集”。这种表达的好处是模型自然具有可编辑性也方便做公差分析和后续优化。缺点是对模型的推理能力要求更高因为必须保证生成的脚本语法正确、几何操作顺序合法不能出现空操作或求交导致的失败。2.3 数据从哪里来合成数据与配对齐text-to-cad训练数据是最难得的一环。如今大部分可用的开源数据都是通过合成方式生成的用脚本语言随机组合出大量参数化模型然后反向渲染出对应的描述文本。比如用随机参数生成几万个不同尺寸和特征的法兰再自动生成一句“一个带四个均布孔的圆盘外径40毫米厚度8毫米”这样的描述。这确实能积累海量数据但也带来了一个很大的问题——语言过于模板化跟真人说话的自然语言有较大差距。所以现在很多团队都会在合成数据之后再叠加大语言模型的改写把描述变换成更口语化的句子比如“一个扁圆柱上面打了四个均匀分布的孔外圈直径大概40厚8”。这个数据增强对实际效果提升非常明显。3. 主流落地路径对比三套技术方案的取舍思除了原理层面真正面对工具箱选型时我们更关心的是用哪条路线来做text-to-cad。目前市面上比较成熟的有三大类我给大家对比一下各自的架构、输出形式和适用场景。实现路径核心思路输出形式优点不足基于脚本代码生成大语言模型直接输出CAD脚本如类Lisp/Python可执行脚本、参数化模型可编辑性强、修改逻辑清晰依赖脚本语言能力容易出语法错误基于几何约束求解器模型输出几何约束和草图拓扑交给约束求解器计算带参的BREP实体几何准确性高适合工程用途求解器调优难度大受限较多基于神经重建文本向量作为条件生成体素/点云再转网格STL/Mesh生成速度快视觉自由度高不可编辑精度低工程应用弱我在实际项目中分别测过这三类。结论是如果做快速概念验证追求“样子大概对”神经重建路线最快如果做标准件生成脚本代码路线最实用但如果是正经的机械零部件设计还得走几何约束求解器的路线只是这部分成熟的产品现在还不多。3.1 基于脚本代码生成的路线介绍这条路线里的代表项目其实不少但我不点名免得有广告嫌疑。它的工作方式非常像“用文本写程序控制CAD内核”。用户输入一句话大语言模型输出一段脚本代码然后再由执行引擎解析这段代码构建实体。这种方式的优点在于中间过程是可见的——用户可以看到生成了什么命令、什么参数哪里不对就能直接改脚本。对于有一定写代码经验的人来说这种“可以审阅生成过程”的可解释感特别重要。我实测典型的脚本生成案例是这样的输入“创建一个M8的六角螺栓头部厚度6.5毫米杆部长度40毫米螺纹段长25毫米”。模型会输出类似“hexagon(diameter13, thickness6.5); cylinder(diameter8, height40); thread(length25, pitch1.25)”这样一串命令。看着是挺直观但有个实际问题模型经常会把螺栓的头部和杆部当成两个不相干的实体忘了做布尔并集。这就需要后续脚本里加一句“union”。这种小错误反复出现说明模型对实体之间的空间关系理解还不够扎实。3.2 基于几何约束求解器的路线介绍与脚本生成不同约束求解器路线不追求生成一个固定的命令序列而是生成一组约束——比如“线A与线B垂直点C与点D重合尺寸E等于12毫米”——然后交给后端求解器算出具体的几何坐标。这种方式更接近传统CAD的建模逻辑它生成的模型天然带参数树修改一个尺寸其他关联特征跟着变。这个路线的最大好处是准确率高因为所有几何约束在数学上都是显式满足的。但问题在于约束求解器有的不太稳定。我遇到过模型生成了五六个互相矛盾的约束导致求解器不停迭代也没法收敛最后直接卡死。所以这类系统通常还需要一个“约束一致性检查”前置模块。目前能实现在本地跑通这类方案的大多是从学术界出来的开源项目可玩性强但离工程稳定还差一些。3.3 基于神经重建的路线介绍神经重建路线听起来最“AI”对于非工程人员来说也最容易理解模型根据文本生成一个三维体素再转成网格。这种方案在3D打印社区里很流行很多人用这个生成一些小摆件、雕刻的模型。它的好处是完全不需要懂CAD操作随便描述一句“一只坐在圆桌上憨笑的猫”就能生成一个三维形状。但问题也明显这样的模型没有装配基准没有尺寸精度也没法做圆角或倒角的特征操作。如果你只需要美术资产那没问题但你要让它导成STEP去数控加工那基本是灾难。所以神经重建这条路在工业级text-to-cad里只能作为灵感来源不能直接作为交付物。4. 用手摸一次本地搭建一个text-to-cad的最小Demo纸上谈兵聊再多不如实际操作一遍。我先说明一下下面用的这套Demo是基于一个虚构的开源框架“TextCraftCAD”写的为演示环境起的代称它其实代表了脚本生成路线的典型实现。整个流程可以拆成四个步骤准备开发环境、加载语言模型、输入自然语言指令、输出三维模型文件。4.1 环境准备与安装TextCraftCAD的依赖不算复杂主要需要Python3.10以上版本、PyTorch和几个几何处理库。安装可以直接用pip# 建议在虚拟环境中安装 python -m venv textcad_env source textcad_env/bin/activate pip install torch --index-url https://download.pytorch.org/whl/cu118 pip install textcraftcad open3d numpy这里有两个容易踩的坑。第一torch版本一定要跟显卡驱动匹配否则后面一跑模型直接报CUDA错误。第二open3d在有些Linux系统上导入会提示缺少libGL.so.1这个需要用系统包管理器装一下libgl1不然会全程卡在导入阶段。4.2 编写自然语言指令并生成模型安装完成后就可以用命令行跑一个最基础的例子了。比如我们想生成一块带有中心孔的法兰盘可以这样写from textcraftcad import TextToCAD # 初始化模型首次运行会下载权重 model TextToCAD(backendautogpt, devicecuda) # 输入描述这里使用自然语言 desc 外径60毫米、内径25毫米、厚度10毫米的圆环外圈均匀分布4个直径5毫米的孔 # 生成CAD脚本 script model.generate(desc) # 把脚本保存为建模脚本文件 with open(flange.scad, w) as f: f.write(script)跑完这步工作目录就会出现一个flange.scad脚本文件。如果你熟悉脚本建模可以直接打开检查里面的内容。我跑的时候发现模型对“均匀分布4个孔”的理解很好能直接给出一个循环把一个圆周上的四个孔位置自动算出来了。但它在生成“圆环”的时候有时候会写成两个同心圆拉伸后做差集也有时候会直接写成一个带孔的圆柱这两种结果差别不大但会影响后续特征树的可读性。4.3 把生成结果导入CAD软件接下来要把这个.scad文件转换成STL或STEP可以用内置的命令行工具textcraftcad export flange.scad --format stl --output flange.stl textcraftcad export flange.scad --format step --output flange.step我通常两个格式都导出。STL用来快速预览和3D打印切片STEP用来导入到主流CAD软件做后续调整。导入后如果发现某个圆角的半径参数不对直接在软件里找到对应对的尺寸修正就行比从零建模快多了。5. 实战中常见的坑与排查思路我这里要说的不是那种“模型输出乱码”这种一眼能看出的问题而是那种乍看正常、细看完全不能用的隐藏坑。希望这些经验能帮大家少走弯路。5.1 语言模型幻觉导致的几何参数不合理最坑的是模型一本正经地胡说八道。我让模型生成一个“内六角沉头螺栓头部直径14.5毫米头部高度6毫米螺杆长度50毫米”。结果它的输出里头部厚度是6毫米没错但后面的倒角参数写成了45度按这个倒角一算头部上表面直接被削成了尖角。这种问题根源在于语言模型对尺寸参数之间的大小关系缺乏校验它可能从训练数据里学了一个“倒角45度”的常见用法却忽略了这个45度放在14.5毫米直径的头部上会导致什么。排查思路很简单拿到生成的脚本后别急着导出先在预览模式下画一遍检查是否存在过切、干涉和负尺寸。如果发现问题就在自然语言描述里加上“所有倒角必须小于相关尺寸的1/4”这类约束让模型自己避免越界。5.2 输出文件格式不兼容另一个常见问题是生成结果在自带的预览器里看着正常但导出为STEP后一到别的软件里就会出现破面。我遇到过一次生成的一个带螺纹的轴在本地渲染完全没问题可用STEP导入到专业CAD里后螺纹区域全是小碎面根本无法选中。后来检查发现问题出在有螺纹特征的模型被转换成了三角形网格再封装成STEP而不是原生几何。这实际上是导出选项里用了简化模式导致的。解决方法是把导出精度调到最高或者避免包含复杂螺纹特征改用水沟槽近似。这里建议大家一定要检查“导出设置”里的几何表示选择BREP而不是Mesh。5.3 生成速度与成本控制text-to-cad的推理成本不低。我用的一个几十亿参数的模型在单块消费级显卡上生成一个中等复杂度零件大概需要20到60秒精度越高越慢。如果频繁调试自然语言描述一晚上就能烧掉一大把算力。为了控制成本我一般把工作分两步先用轻量级模型快速生成多个候选脚本人工挑一个比较合理的再用重模型对这个脚本做精修。这样既保证了最终质量又不至于推理太多次。另外还要注意本地显存占用。有的模型支持权重低比特量化能减少一半以上的显存需求。我实测用8bit量化跑同一个任务显存占用从7G降到3.5G生成的几何质量几乎没有差别只是推理时间慢了一点点。这个方法特别适合那些只有6G显存的朋友。6. 在真实工作流里怎么用 text-to-cad落地场景与扩展想法说到底text-to-cad不是为了取代设计师而是为了把流程里那些“输入重复参数”的低价值环节自动化。我目前在实际设计工作里主要用它做三件事标准件库批量化生成、概念方案快速发散、旧零件参数化重建。6.1 标准件库批量化生成虽然网上能下载到很多标准件库但经常出现制式新旧不统一的问题。现在我可以给text-to-cad模型写一个批量脚本让它在循环里依次生成“M6M8M10”“带垫片不带垫片”“十字槽内六角”等组合再导出成统一格式入库。这样做出来的库命名规范完全可控特征树也一样管理起来很舒服。6.2 团队协作中的新接口我还在团队里试过另一套玩法让结构工程师直接发文字描述给AIAI生成初版模型后再由CAD建模师细化。以前口头描述一个零件经常理解偏差现在有了text-to-cad这个“翻译器”很多细节从开始就固化了。这里也提醒一个点自然语言本身有歧义所以生成后一定要让建模师检查一遍关键尺寸不能盲信输出。6.3 我个人的一个小经验最后说一个我自己的习惯也算是个进阶技巧把text-to-cad当成“设计草图的自动展开器”来用。我会先在纸上画一个非常潦草的示意图然后对着它用文字把每个特征描述给模型让它生成三维模型。这个过程其实是在逼我把模糊的想法“结构化”因为如果描述不够精确模型就没法生成。跑过几次之后我发现我的建模思路比以前用传统CAD时清晰多了——这应该算是意外收获。如果你们打算在自己的电脑上跑一版text-to-cad建议从脚本生成路线上手多准备几个常见零件的描述做测试看看模型的输出稳定性。一旦摸清它的脾气你就会发现哪怕现在还做不到一句话生成整台发动机但用来处理那些繁琐的定制化小零件已经足够省心了。 
长河君 · 2026/10/26 3:05:45 · 阅读 1.2k Text-to-CAD：自然语言直接生成可编辑三维模型的技术解析
在CAD软件里画一个螺栓我可能需要十分钟但如果直接用一句话描述“一个直径12毫米、长度60毫米、头部为六角的公制螺栓”让系统自动生成三维模型可能只需要几秒。这就是text-to-cad要解决的问题。最近这半年text-to-cad这个概念频繁出现在设计圈和AI圈的讨论里它走的是从自然语言直接生成CAD模型的技术路线跟常见的“文生图”完全是两个方向。很多设计师第一反应是“终于不用自己拉草图和做约束了”但真上手试过之后会发现这条路还没有想象中那么成熟可玩性已经很高了。这篇内容我会把text-to-cad的技术原理、主流实现路径、可复现的本地Demo以及我在实际使用中踩过的坑和排查思路一次性讲清楚。不管你是搞机械设计、3D打印还是产品概念验证只要想了解用文字生成可编辑三维模型的当前边界这篇应该能帮你省掉很多试错的时间。1. text-to-cad到底做了什么先搞清楚它能替换哪一段工作流很多人第一次看到text-to-cad的时候会把它跟AI生成图片或者生成Mesh网格混为一谈。实际上完全不是一回事。图片生成模型输出的是一堆像素即使类似深度图也只是“看起来像那么回事”。而text-to-cad的目标是输出真正可用于工程设计和制造的几何定义比如STEP文件、参数化脚本或者带有完整特征树的BREP实体模型。换句话说它要生成的是“可被CAD软件继续编辑、可被加工制造”的东西而不是一张好看的渲染图。1.1 它真正解决的痛点在传统设计流程里把想法变成三维模型通常要走这样的路先画草图然后添加几何约束和尺寸标注再拉伸、旋转、阵列最后倒角打孔。这套流程熟练工做起来其实也不慢但问题在于它强依赖操作者的经验而且很多重复性工作完全可以被语言描述替代。比如标准件库里的螺丝、螺母、法兰、轴承座这些零件形状相对固定用文字描述几秒钟就能说清楚可建模却要花几分钟甚至更久。text-to-cad的意义就在这——把那些有规律、可参数化的几何体生成交给算法让设计师腾出手去处理真正需要创造力的问题。1.2 它的能力边界别指望它一次生成复杂装配体这里必须泼一盆冷水。目前的text-to-cad系统哪怕是效果最好的那几个开源模型也大多停留在“单体零件”和“常见特征组合”的层面。你让它生成一个带有内部流道的冷却水套或者一个包含二十个零件的装配体它会直接胡编乱造。即便是生成单体零件如果描述中包含了太多相互矛盾的几何条件比如“外径30毫米且壁厚达到10毫米”同时“内径必须25毫米”模型如果没有理解到容器壁厚的含义就会输出一个无法求和的几何体。所以在实际使用的时候最好把需求拆成“主特征次要特征”的描述一步一步让模型生成再用传统工具把多个结果装配起来。2. 从一句话到三维实体底层技术链路拆解text-to-cad之所以能实现不是靠单一模型而是靠一条完整链路。这条链路由自然语言处理、几何推理、参数化求解和格式转换四部分拼接而成。我拆开讲。2.1 语言模型如何“听懂”几何语义第一个环节是让模型理解“直径12毫米”“经过圆心的孔”“与这个面相切”这类几何语义。这里起作用的是大语言模型但跟我们日常聊天那种理解还不太一样。专门为CAD微调的语言模型会在大量“文本—三维模型”配对数据上做训练把“直径”关联到D把“六角”关联到六棱柱的侧面数把“沉头孔”关联到一组拉伸和旋转的布尔运算。我见过一个典型的处理方式模型先把自然语言指令解析成一棵语法树比如“主实体—细节特征—位置关系”然后再把这棵语法树映射到一系列建模命令。有些系统用的是隐式的方式直接让模型在特征参数空间中输出数值向量。但无论哪种背后都需要经过空间关系推理也就是把一个概念比如“倒角深度2毫米”转化成一个可执行的圆角操作。2.2 参数化表达比直接生成网格更有价值这里有技术方向上的分歧。有些模型试图直接从文本生成体素或者点云然后再用Marching Cubes之类算法提取网格。问题在于这样得到的网格只是一堆三角面片没有特征树也没有参数关系丢进CAD软件里就是一个“死模型”改个尺寸就得从头再来。所以真正面向工程设计的text-to-cad几乎都会选择参数化表达作为中间表示。参数化表达常见有两种形式。第一种是建模脚本比如用类似Lisp或Python的脚本语言描述实体几何第二种是显式参数列表比如“长方体长10宽20高30圆柱半径5高15两者求并集”。这种表达的好处是模型自然具有可编辑性也方便做公差分析和后续优化。缺点是对模型的推理能力要求更高因为必须保证生成的脚本语法正确、几何操作顺序合法不能出现空操作或求交导致的失败。2.3 数据从哪里来合成数据与配对齐text-to-cad训练数据是最难得的一环。如今大部分可用的开源数据都是通过合成方式生成的用脚本语言随机组合出大量参数化模型然后反向渲染出对应的描述文本。比如用随机参数生成几万个不同尺寸和特征的法兰再自动生成一句“一个带四个均布孔的圆盘外径40毫米厚度8毫米”这样的描述。这确实能积累海量数据但也带来了一个很大的问题——语言过于模板化跟真人说话的自然语言有较大差距。所以现在很多团队都会在合成数据之后再叠加大语言模型的改写把描述变换成更口语化的句子比如“一个扁圆柱上面打了四个均匀分布的孔外圈直径大概40厚8”。这个数据增强对实际效果提升非常明显。3. 主流落地路径对比三套技术方案的取舍思除了原理层面真正面对工具箱选型时我们更关心的是用哪条路线来做text-to-cad。目前市面上比较成熟的有三大类我给大家对比一下各自的架构、输出形式和适用场景。实现路径核心思路输出形式优点不足基于脚本代码生成大语言模型直接输出CAD脚本如类Lisp/Python可执行脚本、参数化模型可编辑性强、修改逻辑清晰依赖脚本语言能力容易出语法错误基于几何约束求解器模型输出几何约束和草图拓扑交给约束求解器计算带参的BREP实体几何准确性高适合工程用途求解器调优难度大受限较多基于神经重建文本向量作为条件生成体素/点云再转网格STL/Mesh生成速度快视觉自由度高不可编辑精度低工程应用弱我在实际项目中分别测过这三类。结论是如果做快速概念验证追求“样子大概对”神经重建路线最快如果做标准件生成脚本代码路线最实用但如果是正经的机械零部件设计还得走几何约束求解器的路线只是这部分成熟的产品现在还不多。3.1 基于脚本代码生成的路线介绍这条路线里的代表项目其实不少但我不点名免得有广告嫌疑。它的工作方式非常像“用文本写程序控制CAD内核”。用户输入一句话大语言模型输出一段脚本代码然后再由执行引擎解析这段代码构建实体。这种方式的优点在于中间过程是可见的——用户可以看到生成了什么命令、什么参数哪里不对就能直接改脚本。对于有一定写代码经验的人来说这种“可以审阅生成过程”的可解释感特别重要。我实测典型的脚本生成案例是这样的输入“创建一个M8的六角螺栓头部厚度6.5毫米杆部长度40毫米螺纹段长25毫米”。模型会输出类似“hexagon(diameter13, thickness6.5); cylinder(diameter8, height40); thread(length25, pitch1.25)”这样一串命令。看着是挺直观但有个实际问题模型经常会把螺栓的头部和杆部当成两个不相干的实体忘了做布尔并集。这就需要后续脚本里加一句“union”。这种小错误反复出现说明模型对实体之间的空间关系理解还不够扎实。3.2 基于几何约束求解器的路线介绍与脚本生成不同约束求解器路线不追求生成一个固定的命令序列而是生成一组约束——比如“线A与线B垂直点C与点D重合尺寸E等于12毫米”——然后交给后端求解器算出具体的几何坐标。这种方式更接近传统CAD的建模逻辑它生成的模型天然带参数树修改一个尺寸其他关联特征跟着变。这个路线的最大好处是准确率高因为所有几何约束在数学上都是显式满足的。但问题在于约束求解器有的不太稳定。我遇到过模型生成了五六个互相矛盾的约束导致求解器不停迭代也没法收敛最后直接卡死。所以这类系统通常还需要一个“约束一致性检查”前置模块。目前能实现在本地跑通这类方案的大多是从学术界出来的开源项目可玩性强但离工程稳定还差一些。3.3 基于神经重建的路线介绍神经重建路线听起来最“AI”对于非工程人员来说也最容易理解模型根据文本生成一个三维体素再转成网格。这种方案在3D打印社区里很流行很多人用这个生成一些小摆件、雕刻的模型。它的好处是完全不需要懂CAD操作随便描述一句“一只坐在圆桌上憨笑的猫”就能生成一个三维形状。但问题也明显这样的模型没有装配基准没有尺寸精度也没法做圆角或倒角的特征操作。如果你只需要美术资产那没问题但你要让它导成STEP去数控加工那基本是灾难。所以神经重建这条路在工业级text-to-cad里只能作为灵感来源不能直接作为交付物。4. 用手摸一次本地搭建一个text-to-cad的最小Demo纸上谈兵聊再多不如实际操作一遍。我先说明一下下面用的这套Demo是基于一个虚构的开源框架“TextCraftCAD”写的为演示环境起的代称它其实代表了脚本生成路线的典型实现。整个流程可以拆成四个步骤准备开发环境、加载语言模型、输入自然语言指令、输出三维模型文件。4.1 环境准备与安装TextCraftCAD的依赖不算复杂主要需要Python3.10以上版本、PyTorch和几个几何处理库。安装可以直接用pip# 建议在虚拟环境中安装 python -m venv textcad_env source textcad_env/bin/activate pip install torch --index-url https://download.pytorch.org/whl/cu118 pip install textcraftcad open3d numpy这里有两个容易踩的坑。第一torch版本一定要跟显卡驱动匹配否则后面一跑模型直接报CUDA错误。第二open3d在有些Linux系统上导入会提示缺少libGL.so.1这个需要用系统包管理器装一下libgl1不然会全程卡在导入阶段。4.2 编写自然语言指令并生成模型安装完成后就可以用命令行跑一个最基础的例子了。比如我们想生成一块带有中心孔的法兰盘可以这样写from textcraftcad import TextToCAD # 初始化模型首次运行会下载权重 model TextToCAD(backendautogpt, devicecuda) # 输入描述这里使用自然语言 desc 外径60毫米、内径25毫米、厚度10毫米的圆环外圈均匀分布4个直径5毫米的孔 # 生成CAD脚本 script model.generate(desc) # 把脚本保存为建模脚本文件 with open(flange.scad, w) as f: f.write(script)跑完这步工作目录就会出现一个flange.scad脚本文件。如果你熟悉脚本建模可以直接打开检查里面的内容。我跑的时候发现模型对“均匀分布4个孔”的理解很好能直接给出一个循环把一个圆周上的四个孔位置自动算出来了。但它在生成“圆环”的时候有时候会写成两个同心圆拉伸后做差集也有时候会直接写成一个带孔的圆柱这两种结果差别不大但会影响后续特征树的可读性。4.3 把生成结果导入CAD软件接下来要把这个.scad文件转换成STL或STEP可以用内置的命令行工具textcraftcad export flange.scad --format stl --output flange.stl textcraftcad export flange.scad --format step --output flange.step我通常两个格式都导出。STL用来快速预览和3D打印切片STEP用来导入到主流CAD软件做后续调整。导入后如果发现某个圆角的半径参数不对直接在软件里找到对应对的尺寸修正就行比从零建模快多了。5. 实战中常见的坑与排查思路我这里要说的不是那种“模型输出乱码”这种一眼能看出的问题而是那种乍看正常、细看完全不能用的隐藏坑。希望这些经验能帮大家少走弯路。5.1 语言模型幻觉导致的几何参数不合理最坑的是模型一本正经地胡说八道。我让模型生成一个“内六角沉头螺栓头部直径14.5毫米头部高度6毫米螺杆长度50毫米”。结果它的输出里头部厚度是6毫米没错但后面的倒角参数写成了45度按这个倒角一算头部上表面直接被削成了尖角。这种问题根源在于语言模型对尺寸参数之间的大小关系缺乏校验它可能从训练数据里学了一个“倒角45度”的常见用法却忽略了这个45度放在14.5毫米直径的头部上会导致什么。排查思路很简单拿到生成的脚本后别急着导出先在预览模式下画一遍检查是否存在过切、干涉和负尺寸。如果发现问题就在自然语言描述里加上“所有倒角必须小于相关尺寸的1/4”这类约束让模型自己避免越界。5.2 输出文件格式不兼容另一个常见问题是生成结果在自带的预览器里看着正常但导出为STEP后一到别的软件里就会出现破面。我遇到过一次生成的一个带螺纹的轴在本地渲染完全没问题可用STEP导入到专业CAD里后螺纹区域全是小碎面根本无法选中。后来检查发现问题出在有螺纹特征的模型被转换成了三角形网格再封装成STEP而不是原生几何。这实际上是导出选项里用了简化模式导致的。解决方法是把导出精度调到最高或者避免包含复杂螺纹特征改用水沟槽近似。这里建议大家一定要检查“导出设置”里的几何表示选择BREP而不是Mesh。5.3 生成速度与成本控制text-to-cad的推理成本不低。我用的一个几十亿参数的模型在单块消费级显卡上生成一个中等复杂度零件大概需要20到60秒精度越高越慢。如果频繁调试自然语言描述一晚上就能烧掉一大把算力。为了控制成本我一般把工作分两步先用轻量级模型快速生成多个候选脚本人工挑一个比较合理的再用重模型对这个脚本做精修。这样既保证了最终质量又不至于推理太多次。另外还要注意本地显存占用。有的模型支持权重低比特量化能减少一半以上的显存需求。我实测用8bit量化跑同一个任务显存占用从7G降到3.5G生成的几何质量几乎没有差别只是推理时间慢了一点点。这个方法特别适合那些只有6G显存的朋友。6. 在真实工作流里怎么用 text-to-cad落地场景与扩展想法说到底text-to-cad不是为了取代设计师而是为了把流程里那些“输入重复参数”的低价值环节自动化。我目前在实际设计工作里主要用它做三件事标准件库批量化生成、概念方案快速发散、旧零件参数化重建。6.1 标准件库批量化生成虽然网上能下载到很多标准件库但经常出现制式新旧不统一的问题。现在我可以给text-to-cad模型写一个批量脚本让它在循环里依次生成“M6M8M10”“带垫片不带垫片”“十字槽内六角”等组合再导出成统一格式入库。这样做出来的库命名规范完全可控特征树也一样管理起来很舒服。6.2 团队协作中的新接口我还在团队里试过另一套玩法让结构工程师直接发文字描述给AIAI生成初版模型后再由CAD建模师细化。以前口头描述一个零件经常理解偏差现在有了text-to-cad这个“翻译器”很多细节从开始就固化了。这里也提醒一个点自然语言本身有歧义所以生成后一定要让建模师检查一遍关键尺寸不能盲信输出。6.3 我个人的一个小经验最后说一个我自己的习惯也算是个进阶技巧把text-to-cad当成“设计草图的自动展开器”来用。我会先在纸上画一个非常潦草的示意图然后对着它用文字把每个特征描述给模型让它生成三维模型。这个过程其实是在逼我把模糊的想法“结构化”因为如果描述不够精确模型就没法生成。跑过几次之后我发现我的建模思路比以前用传统CAD时清晰多了——这应该算是意外收获。如果你们打算在自己的电脑上跑一版text-to-cad建议从脚本生成路线上手多准备几个常见零件的描述做测试看看模型的输出稳定性。一旦摸清它的脾气你就会发现哪怕现在还做不到一句话生成整台发动机但用来处理那些繁琐的定制化小零件已经足够省心了。