Text-to-CAD：自然语言生成可编辑三维模型

1. 先说清楚：text-to-cad到底是个什么东西

最近后台收到好几条私信问我text-to-cad相关的话题，这确实是个很值得聊的方向。简单来说，text-to-cad就是把自然语言描述直接变成可编辑的三维CAD模型，你输入一句"一个带四个圆孔的不锈钢安装板，长120mm宽80mm厚5mm"，它就能给你生成对应的参数化实体模型，而不是传统的从一个草图开始手动拉伸、打孔那种建模流程。这种能力一旦成熟，对机械设计、产品开发、非标自动化这些领域的影响会非常直接。

很多人容易把text-to-cad和AI生成3D模型混为一谈，但这两者的本质差别非常大。市面上常见的AI生成3D网格工具（比如用扩散模型从图片或文本生成OBJ/STL网格）走的是"生成密集三角面片"路线，输出结果艺术展示可以，但进不了工程流程，因为网格没有参数特征，没办法标尺寸、没法重新编辑、更做不了布尔和装配约束。text-to-cad真正的价值在于输出结果是参数化且可编辑的实体模型，是CAD内核能识别的那一套东西，后续改尺寸、加约束、出工程图都没有障碍。这个区别往小了说是文件格式差异，往大了说是"能用的模型"和"好看的模型"之间的鸿沟。

这篇文章适合三类读者：一类是被传统建模效率困扰、想探索新工作流的设计师和工程师；一类是搞AI应用落地、想评估这个方向技术成熟度的开发者；还有一类就是纯粹对AI辅助设计感兴趣、想上手试试的新手。我会把原理、工具选型、实操过程、调参技巧和踩坑记录都整理在下面，尽量做到拿过去就能用。

2. 这个东西怎么work的：从语言到实体的三层解码

2.1 背后不是"画图"，而是"写程序"

我第一次把text-to-cad当成"文字画图工具"来用的时候，生成的模型乱得一塌糊涂。深入了解之后才明白，这类工具的实现路径压根不是从文本直接"想象"出几何体，而是把自然语言翻译成CAD脚本代码，再交给CAD内核去执行。换句话说，它本质上是一个文本到代码的生成任务，只不过目标代码是OpenSCAD、CadQuery或者PythonOCC这类能直接构建实体模型的程序语言。

当你说"一个带通孔的圆柱体"，模型并不是通过深度学习直接画了一个圆柱，而是生成了一段逻辑类似"创建圆柱体，直径D=50，高度H=80，然后在中心打一个直径D=10的通孔"的程序代码。这种实现方式的优势非常明显：CAD脚本本身是参数化的，生成的模型天然带有特征树和参数列表，你可以像改代码一样去改尺寸、调整特征顺序，而不是面对一个无法再编辑的"死模型"。从这个角度去理解text-to-cad，你就明白为什么很多团队把精力花在提升代码生成质量上，而不是去优化几何渲染效果。

2.2 三种主流技术路线的取舍

从2023年到2025年，text-to-cad相关的技术方案基本能分成三条路线，三条路线的核心区别在于"把文本转成什么"。

第一条路线是文本到CSG/构造式实体几何。模型学习把自然语言分解为一系列布尔运算和基础几何体的组合，比如"圆柱体减去两个长方体得到支架"。这种路线生成过程可解释性强，但表达能力有限，复杂有机曲面基本做不了，适合结构相对规则的零件。

第二条路线是文本到CAD脚本语言，也就是上面说的OpenSCAD/CadQuery路线。这是当前实际效果最均衡的方案，因为脚本语言本身具备循环、条件分支、函数封装这些能力，模型可以把"在一圈法兰上均匀分布8个螺纹孔"这种重复性描述处理得非常好。Zoo团队开源的Text2CAD模型走的就是这个路子，用Mixtral-8x7B作为底座，配合深度交叉注意力机制来理解二维草图投影与三维CAD命令序列之间的映射关系，在Text2CAD数据集上做监督微调。

第三条路线是文本到参数化特征树，也就是让模型输出类似CAD软件内部的建模历史序列——先草图、再拉伸、再倒角、再打孔。这条路最接近人类设计师的建模逻辑，理论上生成结果的工程化程度最高，不依赖具体脚本语言，但数据获取难度极大，因为需要完整的CAD原生文件作为训练语料来重建特征树。当前公开可用的开源方案里极少见到它的身影，不过这是一个值得持续观察的方向。

这三条路线并不存在谁绝对替代谁，关键看你要什么。如果你只需要快速出概念模型、方便后期改参数，脚本路线最合适；如果对建模过程的可解释性有硬要求，CSG路线更容易调试；如果目标是做自动化设计系统的一部分、要跟PDM/PLM深度集成，那么特征树路线是最终追求的方向。

2.3 一个关键误区：它与AI绘画不是一回事

很多从AI绘画、AI生成图像那边转过来的朋友，本能地会用"写完提示词→等生成→挑一张好看的"这套逻辑来使用text-to-cad，但在实际应用中发现完全不是那么回事。原因在于图片生成领域的扩散模型擅长处理的是像素分布的概率推断，一个提示词对应的是无数种视觉合理的方案，用户最终看的是"像不像"；而CAD建模面对的是精确几何约束的可满足性问题，你告诉模型"螺栓孔径是6.8mm"，差0.1mm就是不合格的装配件，这没有任何模糊空间。

这种本质差异带来三个直接影响。第一，text-to-cad的提示词必须比AI绘画的提示词精确得多，形状类别、几何关系、关键尺寸、特征类型、单位、加工工艺倾向这些信息最好都写清楚，否则模型会默认使用训练集中出现频率最高的猜测值；第二，生成的评估标准完全不一样，不是"看起来顺不顺眼"，而是"尺寸是否正确、布尔运算是否干净、导入下游软件能否正常编辑"；第三，调试方式也不一样，AI绘画生成结果不满意你换提示词重跑就行，text-to-cad生成结果有问题你得能看懂报错信息、能借助CAD软件定位具体特征出错的位置。

想清楚这一层，后续所有的实操手法和调优技巧都围绕着一个核心来展开：怎么让语言描述精确地映射到CAD内核能执行的命令。

3. 动手之前的工具选型：开源方案与平台化工具怎么挑

3.1 直接可用的主流工具盘点

text-to-cad的可用工具在2024年到2025年之间冒出来不少，但真正值得放进工作流的也就那么几个。如果按使用门槛从低到高排个序，大致是云端设计平台、开源模型自部署、半成品科研工具这三档。

图表性质的对比信息先放在前面，这里整理了一份选型对照表：

开源这一档，Zoo的Text2CAD是绕不开的名字。这个工作由微软研究院和慕尼黑工业大学等机构合作完成，论文发表在ICLR 2024，模型权重和数据都已经在GitHub上公开。它的优势在于完整的训练管线可以看到——从自然语言指令采集、三维模型构建、CAD命令序列标注到最终模型微调，每一步都是透明的，这意味着你可以在自己的数据集上继续微调，把它变成适合自家产品的专用工具。

不过也要说实话，开源模型的原始版本处理日常常见结构件还行，遇到复杂曲面、多体装配或者特殊行业标准件，效果会明显打折扣。这一点在后面的实操环节我会专门讲到。

云端平台这一档，目前市面上陆续有一些在线3D建模工具内置了文本生成能力，用法跟ChatGPT类似：在对话框里描述你想要的零件，平台后端生成可编辑的CAD模型，你再在平台上继续手动修改。对设计师和非技术背景的人来说，这类工具是体验text-to-cad最友好的入口，很多只是想把概念想法快速实体化、并不想折腾Python环境和模型权重的人，选这一档就够了。

3.2 选型决策的三个关键维度

我自己的经验是，选工具不能只盯着"生成效果好不好"，还得把整个工作流成本算进去。这里拎出三个关键维度，建议你在做决定之前都过一遍。

第一个维度是输出离你的下游工具有多远。很多看起来效果惊艳的方案生成的是自己平台内部的格式，导出STEP时特征树和参数就丢了，或者需要经过中间转换才能进入你的主力CAD。如果你的下游是SolidWorks、FreeCAD、Fusion 360、Creo这些传统CAD软件，那就要重点关注生成的模型导出到STEP之后还是不是可编辑的实体。我实测过一些方案，生成结果在自有预览器里非常漂亮，导出STEP之后却变成了一个缝合曲面体，麻烦得很。这时候宁可选择脚本路线生成CadQuery代码，自己去转STEP，特征和参数都保留得更好。

第二个维度是迭代修改的便利性。真正在设计流程里用text-to-cad，几乎没有一次生成就满意的场景，都是反复改需求、改参数。如果你想改一个圆角半径但得从头把概念重写一遍，那这个工具对效率的贡献就大打折扣。脚本路线的优势恰恰在这里——生成的是代码，改一个数值参数就能重新生成，天然适配迭代设计。而走平台路线的，要看平台是否保留了生成结果的完整参数树。

第三个维度是你团队的技术栈匹配度。你是在做自动化设计流水线、需要批量生成模型并做后续仿真？还是在做一人公司的快速概念原型？前者必须选能编程调用、能自定义数据集的方案，后者完全可以选开箱即用的云端工具。很多团队死在"跟风选了最强模型但没人会部署"这个坑上，这个问题不是技术问题，而是人员能力边界问题。

3.3 本地部署的硬件与软件需求

如果你决定自己部署开源的Text2CAD权重跑推理，先说一点心理准备：这玩意儿不是随便一台笔记本就能舒服跑起来的。Zoo Text2CAD基于Mixtral 8x7B的MoE架构，显存需求是实打实的。我用一张RTX 4090 24G跑过一次加载和推理，显存占用轻松超过20G，而且首次前向推理载入权重的等待时间也不短。如果是A100或者更大显存的卡体验自然会好很多，但这不是普通个人开发者能承受的成本。

不想自己搞硬件的，有两个性价比不错的替代路径。一个是租GPU云实例按小时计费，跑完就释放；另一个是用各家云端GPU Notebook服务直接加载社区现成的推理脚本，跳过本地环境配置的麻烦。

软件环境方面，核心依赖链大概是Python 3.10以上、CUDA/cuDNN对应版本、PyTorch 2.x，加上HuggingFace transformers库和bitsandbytes做量化推理。我踩过的坑是Python版本太新导致某些底层库不兼容，所以建议你用虚拟环境管理器把Python版本锁到3.10或3.11，别用最新的3.12。部署细节网上有很多教程，这里不展开铺陈，后面的实操流程里我会针对典型环节做说明。

4. 实操全流程：从自然语言到可用CAD模型的真实记录

4.1 环境准备与基础配置

我先记录一轮相对真实的实操过程，方便你直接照着落地。我这边的环境是Ubuntu 22.04 + Python 3.10 + CUDA 12.1 + PyTorch 2.2.1 + 一张24G显存的显卡。具体步骤如下。

先建虚拟环境并激活，然后安装依赖包。关键依赖包括transformers、accelerate、bitsandbytes、sentencepiece、huggingface_hub这几个组件，其中bitsandbytes是跑4-bit量化推理必需的。安装完第一件事是确认能从HuggingFace正常拉取所需要的模型仓库文件。因为模型权重文件比较大，建议把HF_ENDPOINT环境变量配置到国内可访问的镜像站，不然在下载阶段就会卡到怀疑人生。

基础验证建议用一个最简单的提示词跑通全流程，而不是一上来就试复杂零件。拿"一个圆环"这种级别来验证环境没问题，再进入真正的设计环节。注意看推理日志里的生成token数、总耗时以及是否出现CUDA OOM。

一个小提示：如果你跟我一样用bitsandbytes做4-bit量化来降低显存占用，生成质量会有轻微损失，复杂零件的出错率会稍微高一些。能在全精度跑就全精度，实在不行再量化，这跟大语言模型量化损失的道理是一样的。

4.2 设计一个完整零件的详细步骤

下面以"设计一个电机安装支架"为例，走一遍从需求描述到产出STEP文件的完整路径。

第一步，写初始提示词。我建议提示词的结构遵循"整体描述+几何特征+关键尺寸+可制造性要求"这个模板。比如：

整体描述：一个L型电机安装支架，用于将60mm×60mm的步进电机固定到铝型材框架上 几何特征：底面为一个长方形安装板，带四个对称分布的腰型安装孔，用于调整前后位置；侧面为一个竖直安装面，中心带一个圆形通孔用于电机轴伸出，周围带四个对称分布的螺纹安装孔 关键尺寸：底面长度100mm、宽度80mm、厚度8mm；竖直面高度80mm、厚度8mm；腰型孔长10mm宽6mm，分布于底面四角，边缘距离12mm；中心通孔直径16mm；螺纹孔尺寸M5，中心分布在直径42mm的圆上 可制造性要求：外边缘全部倒角1mm，适合CNC加工

这些信息不一定能一次全部被正确理解，但至少要让模型有足够的信息去建立约束关系，而不是靠猜。

第二步，运行推理。这里要注意temperature参数的设置。我实测下来，这类任务temperature设太高会导致代码产生幻觉，出现一些看起来合理但根本不该出现的特征；设太低又可能让模型死板地套用训练集中见过的相似零件的模板，错失正确的功能需求。比较稳妥的取值范围在0.2到0.4之间。另外，模型的max_new_tokens要留够，复杂一点的零件脚本动辄几百行，token上限太低会被截断导致代码不完整、直接无法执行。

第三步，检查生成结果。先看模型输出的CadQuery脚本能否正常执行，有没有语法错误或者API调用错误；然后看生成的三维预览是否符合需求；最后把STEP文件导入FreeCAD，检查实体有没有破面、有没有多余或缺失的特征。注意这里有个很重要的排查点：text-to-cad生成的脚本经常会出现"能看但尺寸不对"的问题，比如腰型孔变成了两个圆孔，这需要你逐个特征去核实。

第四步，多轮迭代修正。第一次生成往往达不到满意效果，这时候要在对话中追加修正指令，而不是完全重写提示词。比如"腰型孔的方向不对，需要让长轴方向与底面长度方向一致"、"M5螺纹孔位置需要外移5mm"。模型在对话上下文中修正几何的能力，实测下来比从零生成要可靠得多，因为它已经知道零件的整体结构框架了。

4.3 让模型记住上下文：多轮迭代的正确姿势

这就引出text-to-cad实操中最容易忽略但极其重要的一个技巧：把多轮对话当作参数修改器来用。我在试用各种工具时发现，很多人的习惯是模型输出不满意就重新开一轮新的对话，从头再写一遍完整的提示词。这样做不是不可以，但效率很低，而且丢掉了模型已经构建好的几何上下文。

多轮迭代的正确做法是每一轮只给出纯增量修改信息，不要重复描述整个零件。比如第一轮生成的支架已经有了基本结构，第二轮只需要说"把底板的四个腰型孔全部改成直径8mm的圆孔"，第三轮说"在侧面安装面的四角增加4个直径3mm的定位孔，深度3mm"。这样模型会基于已经生成的脚本做局部修改，准确性高得多。

这个现象的底层原因还是跟2.2节说的机制有关：模型生成的是CAD脚本代码，多轮修改本质上就是在一个已有代码基础上做程序修改，模型只需要理解新增需求影响了哪些代码段、如何只修改对应部分而不是重写整个文件。这比生成新代码的难度低太多。

我自己实际统计过一次，完全从头重写提示词到最终满意的平均轮次是4到6轮，而用多轮增量修改的方式平均只需要2到3轮，时间能省一半以上。所以如果你准备把text-to-cad纳入日常设计流程，务必养成"先整体后细节、每轮改一处"的对话习惯。

4.4 模型能力边界：哪些能做、哪些不能做

实操了一段时间之后，我对text-to-cad的能力边界有了一个比较清醒的认知。它擅长的是规则化结构件：安装板、支架、法兰、护罩、箱体、简单壳体，这些零件的特征是平面、圆柱、孔洞、倒角、阵列这种基础特征组合，语言的语义空间和CAD命令空间之间的映射比较直接。

它不太擅长的是有机曲面、复杂过渡曲面、自由形态外观件、薄壁复杂塑件、多体运动约束、装配关系建模，这些需要大量隐式几何推理或者物理约束理解的任务，现有的text-to-cad方案先天就不足。跟造型设计相关的曲面，主流方案还是得靠细分建模或者逆向工程流程，强行用text-to-cad去做"耳机柄的流线型外壳"这种需求，大概率得到的是一个无法加工的死角模型。

此外还要注意行业标准件的生成。比如GB/T标准的螺栓、轴承、密封圈，这些零件有非常明确的国标尺寸系列和命名规则，通用text-to-cad模型对这些特定标准的记忆通常很差，生成结果往往尺寸跟标准对不上、特征细节缺失。遇到这种情况，正确做法是跳过AI直接调用标准件库，而不是跟模型死磕。理解了边界，你才能把工具用到刀刃上。

5. 提示词工程：把话说清楚的实战技巧

5.1 结构化提示词模板

在反复试错中，我自己总结了一套行之有效的提示词模板，分享出来供大家参考：

第一条经验，先定类型、再定尺寸、最后定特征。模型理解的顺序基本跟人类阅读顺序一致，你把最重要的信息放前面，它能抓住主干不至于跑偏，就像你跟同事描述一个新零件，也得先说是什么东西，再说具体数据。

第二条经验，统一用公制单位并且显式写出。跟模型说"直径5的孔"，不如直接说"直径5mm的圆孔"，别省那一个单位词。虽然模型在训练数据里见过用英寸和毫米混合标注的情况，但显式的单位标注能显著减少尺寸解读错误。

第三条经验，用标准工程术语，别用口语。描述一个孔的时候，"通孔"、"盲孔"、"螺纹孔"、"沉头孔"、"锪孔"这些词的语义在CAD数据里是精确且不同的，模型学到的工程语义关联远比"一个能穿螺丝的洞"这种模糊描述要准。这不是模型笨，是训练语料的工程偏好让精确术语跟正确的CAD命令对齐得更好。

第四条经验，对称性和阵列描述要给出明确的基准。"四个角各一个孔"不如"四个孔呈矩形分布，中心位于以板中心为圆心的80mm×50mm矩形四角"。模型对"对称"这种语义本身能够理解，但如果你能明确给出几何基准，生成的定位精度会高很多。

5.2 一个从乱到准的提示词迭代案例

我拿一个实际案例说明改进过程。最初我给的提示词是：做一个安装板，上面有四个孔，能装一个电机。

模型的输出果然很"放飞自我"：板厚默认变成了10mm，四个孔随机分布且间距不成比例，孔也没有明确的直径标注。这个问题本质上不是模型能力不够，而是我的需求描述缺少足够的几何约束信息，模型只能拿训练数据的统计平均值瞎猜。

于是第二版我修改成：做一个正方形安装板，边长60mm，厚度5mm，在边长40mm的正方形四角位置打四个通孔，直径4.2mm。这一版模型的输出明显可用多了，但孔的位置是根据板的对称中心自动排布的，并不是我明确指定的四个坐标。如果你在意的就是对称分布，那这个结果没问题；但如果孔位必须配合特定的电机安装孔距，你还要再追加一轮明确标注。

第三版我补充了一句：以安装板几何中心为原点，四个孔的中心坐标分别为(-20,-20)、(-20,20)、(20,-20)、(20,20)，单位毫米。这次生成的孔位准确无误。这个案例说明一个道理：跟text-to-cad对话时，你默认的工程常识它并不一定具备，几何信息越显式越好。

5.3 实操级的常见提示词范例

给几个我试过可用性较高的提示词样例，你可以直接拿来改。

结构件类：生成一个U型折弯件，底部宽度100mm，两侧翼高50mm，总长度120mm，板厚3mm，四个底部安装孔直径6.5mm，分布于底部四角，边缘距离10mm，所有外边缘倒角0.5mm。

轴类零件：生成一个阶梯轴，共分三段，第一段直径20mm、长度40mm，第二段直径30mm、长度60mm，第三段直径25mm、长度30mm，所有台阶处设置R2的圆角过渡，两端分别加工C2的倒角。

钣金类：生成一个电气控制箱箱体，外形尺寸长300mm宽200mm高150mm，板厚1.5mm，顶部开一个直径100mm的圆形通风孔区域，内部无结构，左侧面切一个80mm×50mm的矩形窗口。

这类提示词描述方式，背后遵循的原则都是"类型+轮廓、尺寸、特征、工艺要求"的完整信息链。建议你第一次使用某个工具时，先用最具体的写法把模型的能力上限探一探，然后再逐步简化，看它到底理解到什么程度。

5.4 负面提示词与禁忌描述

用过Stable Diffusion的朋友都知道负面提示词的存在意义，text-to-cad其实也有对应的注意事项，只不过表达方式不太一样。歧义是这里最大的敌人。比如你写"靠近边缘的孔"，模型无法判断"靠近"是5mm还是50mm，这种相对词汇会严重干扰生成的确定性。

我的建议是，凡是能数字化的信息就全部数字化。别说"大一点的圆角"，说"圆角半径5mm"；别说"均匀分布"，说"沿圆周等距分布，共6个"。如果你要避免模型产生某些特征，也可以用否定句式明确排除，比如"不要有任何倒角"、"不要生成螺纹特征"。这种指令在CadQuery代码生成场景下作用比较明显，因为脚本语言中加不加chamfer操作是明确的。

另外有一点禁忌需要提醒：一次提示词里不要堆叠超过10个独立需求。模型对长序列的注意力资源是有限的，需求太多会导致后面的信息被"遗忘"，生成的代码开始丢三落四。合理做法是把多个需求拆成多轮对话，每轮确认一两个关键细化点，一次塞太多反而拖垮整体质量。

6. 常见问题与排查记录：我踩过的坑你就不用踩了

6.1 推理失败类问题

先说说最常见的失败类问题，大概是三成概率会遇到的那种。第一类，模型输出的脚本存在语法错误或引用了不存在的CadQuery API。遇到这种情况，不要慌着重跑，先把报错信息截图。很多时候只是模型在生成长脚本时在某个地方手滑写错了方法名，把报错位置对应的那行代码手动修正即可，这个过程跟我修别人写的烂代码没什么两样。

第二类是显存不足。我用24G显卡跑全精度Mixtral 8x7B时，生成超过500行脚本的中等复杂度零件，峰值显存会逼近24G上限。遇到显存不足，优先考虑开启4-bit量化推理，或者降低max_new_tokens同时把生成任务拆成多个小步骤。比如一个支架包含主板、肋板和轴套三个主要特征，你可以先让它生成主板，再逐轮追加肋板和轴套，而不是幻想一次生成到位。

第三类是生成过程超时。本地部署的推理速度跟硬件强相关，我实测生成一个中等复杂度零件大约需要40到80秒。如果超过120秒还在转，多半是max_new_tokens设置过大导致生成了大量垃圾输出，或者模型陷入了重复生成循环。这时候直接中断，把参数调整后再跑。

6.2 输出质量类问题

质量类问题比单纯的推理失败更烦人，因为代码能跑、模型也能显示，但就是跟你想要的不一样。

典型的症状包括：尺寸跟描述不一致、特征缺失、多出莫名其妙的结构、布尔运算结果存在本体自相交。我排查这类问题通常是按"数据流三段式"思路走：先确认提示词信息是否完整且无歧义，再检查生成脚本中的具体命令参数，最后在CAD软件中逐个分析特征实体。大多数问题出在第一段——描述模糊导致模型选了错误的默认参数。

这里分享一个技巧：让AI模型写出"设计日志"。当你让模型解释生成结果里某个不合理的特征时，它会告诉你"我理解你的描述是……所以这样建模"，这时候你就能定位到是描述的问题还是理解的问题。这个技巧在开源模型因为对话上下文保留能力有限，效果不如商业大模型接口那么稳定，但依然值得尝试。

有一类特殊的质量问题值得警惕：模型生成的自相交几何或者退化特征可以通过CAD软件自带的修复工具解决，但有些是模型自身的固定思维，比如总是给零件加不必要的倒角。如果这个问题在你的特定应用场景中反复出现，就该考虑换模型或者在上游脚本里直接给cadquery调用做一个后处理过滤规则，而不是继续跟它较劲。

6.3 工程化落地问题

把text-to-cad真正接入生产流程遇到的问题，跟玩票性质地用用完全是两个世界。最典型的矛盾是：AI生成的模型往往没有按照你们公司的建模规范来建。比如你们对特征命名有固定要求，图层有颜色规范，属性有特定字段，而AI生成的代码默认命名全是"box1""hole2"这种流水账。对公司而言，这比生成慢10倍更让人头疼。

应对思路是在提示词阶段就把建模规范约束进去，或者在后处理脚本中批量修复特征命名和属性。这项工作本身也需要投入精力，建议有条件的话做一个轻量级的CadQuery代码模板工程，把常用的颜色、图层、命名规则预先定义成可复用的代码片段，把AI生成的裸代码跟规范代码模板做一次自动化拼接。

还有一个很现实的工程问题：生成结果的几何质量需要经过验证。CAD软件自带的模型修复功能（或者说在FreeCAD里手动检查实体有效性）虽然有，但不可靠。靠谱的做法是写一个基于OpenCASCADE的批量验证脚本，任务开始前在代码里检查实体的有效性属性，把检查不过的模型自动筛出来打回重跑。这个环节看起来额外增加了开发成本，但对比手工检查100个生成模型的痛苦，这笔投资完全不亏。

7. 离实际应用还有多远：我的一些真实感受

最后说说我用text-to-cad这一年多下来的整体感受。这工具在特定场景里是真的能帮上忙的，概念草图阶段尤其明显。以前我做个非标夹具的初步方案，从量尺寸到建出第一版模型怎么也得一两个小时，现在给出明确的几何参数，几分钟能拿到一个相当于初稿的三维模型，后面再在上面精修，效率提升确实可观。非设计背景的产品经理、销售技术支持，也能借助它把模糊的产品想法快速变成可讨论的三维形态，减少跟设计师来回扯皮的成本。

但我也要说，现阶段如果哪个宣传说text-to-cad要取代人工设计，那纯粹是外行话。复杂零件、有严格行业规范的设计、需要创新性的造型工作，这些领域它全都无能为力。我的判断是，它最合适的定位是设计流程里的"草图辅助器"和"参数化建模加速器"，而不是独立完成设计的智能体。

给准备入坑的朋友一个实在的建议：别一上来就折腾部署，先用现成的云端平台试个几十次，把"什么样的语言能被准确理解"这个感觉找到，再决定要不要自己搭环境。这个工具的掌握曲线不算陡，但确实需要你调整跟它交流的方式，把"对CAD说话"变成"对会用CAD的程序员说话"。

目前官方更新和社区迭代速度都很快，开源模型也在持续变强，有几条演进方向值得盯着：一是更大规模的CAD脚本训练语料开源；二是支持更复杂的装配体生成而不是单个零件；三是跟传统CAD软件的双向参数联动。这些方向只要有一个突破，text-to-cad的实用价值就会再上一个台阶。