text-to-cad最近在设计和制造圈子里热度很高，甚至不少非CAD背景的产品经理也在问，能不能直接说一句“给我一个带四个安装孔的矩形底座”就拿到STEP文件。我在这个方向摸了一段时间，试过从学术开源模型到商业预览版工具，踩了不少坑，也总结出一些还算靠谱的工作流。这篇文章不打算罗列一堆研究论文摘要，而是从一个实际使用者角度聊聊text-to-cad现在到底做到什么程度、哪些环节能真正进入生产流程、哪些地方还只能当灵感辅助。
先说结论：现在的text-to-cad远没有到“一句话生成可直接上机床的图纸”的程度，但如果你把它当成“能听懂工程语言的草图搭档”，它已经能帮你省掉大量重复劳动。关键在于理解它的本质——它不是在“凭空捏造模型”，而是在“把自然语言翻译成参数化建模操作序列”。想通这一点，很多使用误区就迎刃而解了。
1. text-to-cad到底是什么：从自然语言到特征树的翻译过程
1.1 传统CAD建模的隐性成本，为什么大家都盯上自然语言
传统CAD建模从来不缺效率瓶颈，但不是画线画圆那个层面的瓶颈，而是“意图传达”的瓶颈。一个工程师脑子里想好了一个零件，他得先把设计意图拆解成特征树：先拉伸底座、再切槽、然后在特定位置打孔、最后倒角。这个过程需要大量操作，更重要的是，它要求操作者已经熟练掌握了软件命令。对于熟练工来说可能半小时搞定，但对非设计岗位的人，比如采购、销售、工艺工程师，他们想表达一个需求可能连软件都打开不利索。
text-to-cad瞄准的就是这个缺口：跳过命令学习曲线，直接用自然语言描述需求，让AI完成从“语义”到“特征序列”的翻译。这跟我们平时用Midjourney画图完全不同，它输出的不是一个像素网格，而是一棵能编辑、能参数化、能出工程图的特征树，至少理论上应该是这样。
我一开始也误以为它是“文本生成3D模型”的升级版，用了之后才发现，两者的技术路径和产出物有本质区别。文本生成3D模型（比如文本转网格）产出的是STL或OBJ这类三角形网格，适合3D打印、渲染和手办，但网格本身没有特征概念。你在网格上没法直接改一个孔的直径，也没法把某个圆角半径从R2改成R5。而text-to-cad的目标是可编辑的B-rep实体模型，背后是参数化特征——底座、凸台、孔、倒角、阵列，这些特征叠加在一起，才是设计师真正能用的东西。
1.2 核心技术栈拆解：LLM只是翻译官，几何内核才是地基
想快速判断一个text-to-cad工具靠不靠谱，就把它拆成两部分看：前端是模型理解语义的能力，后端是生成几何的能力。目前主流的技术路线大致有三条。
第一条是我个人最看好的，也是目前学术和开源社区主流的路线：让大语言模型直接生成CAD脚本代码。所谓CAD脚本，就是用CadQuery、FreeCAD的Python API、或者SolidWorks的宏语言写出的一段程序，程序执行后生成几何实体。这条路线的逻辑是：既然LLM特别擅长写代码，而CAD脚本本身就是代码，那为什么不绕过传统的三维引擎，直接让模型去写建模代码？这是目前实际效果最好的方式，因为有大量CAD脚本数据可以训练，而且生成的代码天然是参数化的，改一个变量就能更新整个模型。
第二条路线是“CAD命令序列生成”。这个思路来自DeepCAD这样的数据集——研究人员把用户在真实CAD软件里的操作序列记录下来，形成类似“line, sketch, extrude, cut, hole”的指令流，然后训练模型从自然语言或点云输入生成这个指令流。它的优点是贴近原生CAD操作，缺点是命令序列很容易出微小语法错误，而且生成结果往往只是“看起来像”，一到具体尺寸和约束就崩。
第三条路线是多模态生成模型，比如Autodesk的Project Bernini这类研究项目。它直接学习大量三维几何数据，试图从自然语言或图片生成功能导向的几何体。听起来很酷，但目前公开可用的程度不高，生成结果也更偏“形态合理”，离工程级精度还有距离。
不管哪条路线，最终生成几何的时候都绕不开几何内核。大多数开源工具基于OpenCASCADE，商业软件用Parasolid或ACIS。你只要记住：text-to-cad的质量上限，一半由LLM的理解能力决定，一半由几何内核处理布尔运算和特征操作的能力决定。模型理解对了但内核算不出来，照样出不了活。
2. 主流text-to-cad工具横评：从开源实验品到商业落地
2.1 学术开源方向：CadQuery + LLM 组合的现状
目前在开源社区里最容易跑通的方案，就是用LLM生成CadQuery代码。CadQuery是一个基于OpenCASCADE的Python建模库，语法相对简洁，设计范式就是“用代码定义特征”。你让一个LLM帮你写CadQuery代码，本质上就是让AI做一个Python编程任务，这个任务的可行性已经被无数代码生成场景验证过了。
我实测下来，像Qwen2.5-Coder、DeepSeek-Coder这类偏代码的模型，在生成简单到中等复杂度的CadQuery代码时，成功率相当可观。比如让它写一个带安装孔的L型支架，十次里有七次能生成可执行的代码。但一旦涉及复杂曲面、放样、扫掠，或者需要精确的草图几何约束，模型就容易翻车，经常出现草图轮廓不闭合、线段方向不对、或者布尔运算对象不合法之类的错误。
学术圈还有Text2CAD这类专门研究工作，它们用大型CAD数据集微调模型，目标是从自然语言直接生成CAD命令序列。但实话说，这类模型目前大多停留在论文演示阶段，代码和权重发布不稳定，复现成本比较高。除非你是做研究验证，否则我更建议走CadQuery加通用代码模型的路线，性价比高得多。
2.2 商业工具和插件的落地程度，哪些值得尝鲜
商业领域，传统CAD巨头基本都在押注AI辅助建模。Autodesk这边有Project Bernini，虽然公开资料偏概念展示，但方向很明确：多模态生成、以功能为导向的几何生成。SolidWorks近两年也在往AI助手方向靠，Fusion 360里也有了生成式AI相关的能力，但整体还处于“辅助灵感”阶段，距离“你说一句它全自动建好模”还很远。
另一个值得关注的方向是API优先的CAD公司，比如KittyCAD。它们把CAD能力封装成API，开发者可以调用接口完成模型操作，再在顶层接大模型做自然语言交互。这种模式的好处是，AI只需要负责生成API调用参数，几何可靠性由底层引擎保证。坏处是这类服务通常按量收费，而且对传统工程师来说有学习门槛。
我的建议是：如果你是个人设计师或者工程师，想体验text-to-cad，优先试CadQuery加代码模型的开源组合，成本低、可控性强。如果你是企业决策者，暂时不必急着上商业方案，先让一两个团队跑通流程、验证ROI再选型。目前这个赛道还没有一个能“通吃所有需求”的产品，谁先入局都不代表未来格局。
2.3 选型对比：不同角色该选哪条路线
我们可以把使用者分三类，对照自己的情况选路线，会比盲目追新工具更实际。
第一类是非设计岗位的需求提出方，比如采购想看某个外协件能不能改型。这类用户建议直接使用在线工具或LLM写CadQuery代码，目标是快速得到一个可视化的概念模型，用于沟通需求。他们不需要关心特征树规不规范，只要能转成STL看看大致形态就行。第二类是机械设计工程师，需要的是真正能出图、能改参数的模型。这类用户应该把text-to-cad当成“特征草稿生成器”，让AI先搭出80%的特征结构，剩下20%的几何约束自己手动调整。第三类是开发者和研究人员，想把这套能力集成到自己的产品里，那就得认真研究CadQuery脚本生成、OpenCASCADE后处理、以及如何用企业标准件数据微调模型。
这三类人对工具的评价维度完全不一样。工程师关心可编辑性和出图精度，管理员关心数据安全和部署成本，需求方只关心“像不像”。选型前先把角色定位搞清楚，后面才不会反复换工具。
3. 自己动手跑通一个text-to-cad全流程：从提示词到STEP文件
3.1 环境准备与模型加载，这一步最容易忽略
我直接给出一套目前稳定可复现的环境组合，跑通之后再根据自己需求调整。操作系统建议Ubuntu 22.04，显卡8GB显存起步，纯CPU也能跑但速度会慢几倍。核心依赖是Python 3.10以上、CadQuery、以及一个代码生成LLM。
安装CadQuery很直接，pip install cadquery就行。如果你需要后续在FreeCAD里打开，建议同时安装freecad和OCC的Python绑定。LLM这块，我有两个选择：如果你有API预算，直接用DeepSeek-Coder或GPT-4这类闭源模型，效果最省心；如果要在本地跑，Qwen2.5-Coder-7B是一个不错的起点，14B效果更好但需要约16GB显存。我个人经验是，7B模型硬啃复杂零件会频繁出错，写写简单支座、法兰盘没问题，复杂的就得14B往上。
环境装好后的第一件事不是急着写提示词，而是先测试CadQuery能不能正常生成并导出STEP文件。我遇到过很多次CadQuery装好了但OCC版本冲突、导致布尔运算崩溃的情况，所以先用官方示例跑一遍导出，确认整个链路通顺，再开始后面的工作。这个步骤像测量台上的零位校准，不做的话后面所有误差都会叠上来。
3.2 提示词设计：用工程语言说话，而不是生活语言
text-to-cad的提示词设计和用ChatGPT写周报完全是两个套路。测试中最常见的问题，是用户用生活化语言描述零件，比如“帮我画一个垫圈，中间有个洞，周围一圈小孔”，这种描述信息量太低了。模型要自己猜垫圈外径、内径、厚度、小孔数量、小孔直径、分布圆直径，猜出来的结果大概率不是你要的。
我总结出了一套提示词模板，用下来效果明显提升。描述必须包含五个要素：整体形状、关键尺寸、特征列表、位置关系、以及设计意图里隐含的约束。举个例子，一个合格的提示词是：“创建外径50毫米、内径25毫米、厚度10毫米的环形垫片，在直径40毫米的圆周上均匀分布4个直径6毫米的通孔，所有锐边倒角1毫米。”这个描述里，“均匀分布”就是位置关系，“通孔”说明是贯穿的，“倒角”说明需要添加特征。
如果你对模型第一次生成的结果不满意，不要急着全部推翻重写。更有效的做法是增量修正：告诉模型“外径改成60”、“孔的数量改成6个”、“倒角去掉”，让它在原代码基础上改参数。大部分情况下，模型在你给的代码上做局部修改的成功率，远高于重新生成整个模型的成功率。这就像让实习生改图纸，你只有把上一版图给他看，他才不会跑偏太远。
3.3 生成到后处理：代码执行、异常处理与格式转换
提示词准备好之后，把任务交给模型，得到一段CadQuery代码。接下来别直接盲信这段代码，先人工过一遍关键点：草图是否闭合、是否用了合法草图操作、拉伸方向是否正确、有没有明显缺少约束的地方。我见过模型把拉伸方向写成反的，导致实体往座位下方突兀地长出去的例子，这种问题人工扫一眼就能发现。
代码确认没问题后，执行生成模型，然后导出为STEP格式。CadQuery里非常简单，cq.exporters.export(shape, "output.step")就行。如果你的下游流程需要STL网格文件，也在这一步同时导出。但这里有个关键提醒：导出STEP用于CAD编辑，导出STL只用于3D打印或渲染，不要拿STL当交换格式发给需要改模的供应商，那样等于把一个参数化模型退化成了网格，对方没法直接改特征。
我在这个环节踩过一个坑是单位理解不一致。CadQuery默认单位是毫米，但LLM可能会在代码里写出millimeter=False这类显式转换，或者把米当毫米用，结果生成一个尺寸大一千倍的怪物模型。解决方法是在提示词里明确写“本工程所有尺寸单位均为毫米”，并且在生成后的人工检查里核对最大尺寸是不是在合理范围。光这一步就帮我挡掉了很多次完全不可用的输出。
4. 输出质量评估：哪些能直接加工，哪些只能当参考
4.1 几何精度与布尔运算正确性，先过这四关
拿到AI生成的CAD模型，第一件事不是看它好不好看，而是做一轮系统性质量评估。我有一套自己的四关检查表，按顺序过一遍，能筛掉大部分问题模型。
第一关是尺寸校验。用CadQuery的bounding box接口读取模型的长宽高，和预期尺寸对比。偏差超过1%就要警惕，比如你以为外径50结果出来是49.2，这种模型没法直接出图。第二关是特征完整性。逐一核对提示词里提到的特征是否都存在：孔打了没、阵列到不到位、倒角有没有漏掉。模型经常会出现“只生成了外形但忘了孔”的情况，被形似蒙蔽。第三关是布尔运算合法性。如果模型是由多个实体组合而成，检查它们是否正确地合并成一个实体，而不是像一堆孤岛一样悬浮在空间里。我用cadquery的check那类功能做几何自检。第四关是语义匹配度。这一步需要人眼判断，因为它和提示词的意图相关。比如你要求“通孔”，结果模型做出来是盲孔，那不管几何多干净都不能用。
这个四关检查法，看起来简单机械，但实际上非常有效。原因是text-to-cad目前的失败模式不是“完全不像”，而是“局部错漏”。尺寸偏差、漏特征、布尔错误、语义偏离，这四类问题占了绝大多数失败案例。与其花半小时在软件里放大抓虫，不如用清单快速筛选。
4.2 从模型到制造：特征识别与工程约束，这才是真正的门槛
过了四关的模型，严格来说离“可加工”还有一段距离，主要在工程约束这块。举个典型的例子：模型可能生成了一个竖壁厚度只有0.3毫米的钣金件，几何上完全正确，但实际加工时要么模具撑不住，要么材料直接变形。CAD模型只管“形状正确”，不管你“能不能造得出来”。这就要求人在把模型发出去加工之前，做一个可制造性评审。text-to-cad不会自动帮你判断壁厚是否低于极限、圆角是否小于刀具半径、孔间距是否太近导致整体强度不足，它只保证“这是一个实体”，不保证“这是一个好零件”。
另一个容易被忽略的是标准件和公差标注的问题。AI生成的CAD模型里几乎没有公差标注，孔径是典型的H7配合还是自由公差，它完全无感。如果你要的是精密配合件，AI初版模型只能用来定外形，公差得靠人在图纸上重新标。这也是为什么我说，现在的text-to-cad没法直接替代工程师的原因之一，它生成的是“几何毛坯”，不是“工程成品”。
但这不意味着它没用。反过来说，正因为AI可以在几分钟内生成一个几何合理、尺寸可调的初版模型，设计师的工作重心就可以从“从零搭形状”转移到“评审、改公差、做可靠性分析”，这其实是更值钱的部分。用一句话概括就是：AI负责量，人负责质。这个分工在未来几年内应该不会改变。
5. 把text-to-cad真正用进工作流：参数化与AI协同的实战思路
5.1 让AI生成参数化特征，而不是一次性死模型
text-to-cad要想在生产环境里产生价值，关键不是让它“一次性生成终极模型”，而是让它生成“参数化模板”。什么叫参数化模板？就是模型的所有关键尺寸都由变量控制，你改一个变量，整个模型的形态随之更新。CadQuery天然支持这种做法，代码里定义base_length = 50，后面所有引用都基于这个变量，改这一行就能更新整个零件。
在实际操作中，我通常这样引导模型：明确要求它“将外径、内径、厚度、孔数、孔距分别定义为变量，并在代码开头集中声明”。模型一般能理解并照做。这样一来，生成的模型就从“一次性死模型”变成了“可复用模板”，下次遇到类似零件，改几个变量就能交付初版。这里有一点经验：参数声明越靠前、越集中，模型越不容易在后续代码里写出互相矛盾的数值。如果你让一个变量在代码中间突然出现，后面的计算就很容易对不上。
我还习惯让模型给每个变量写注释，标注含义和允许范围。这一步看起来无关紧要，但是在模型需要被同事接手或者被另一个AI修改的时候，价值就放大了——好的注释就是给未来接手者定向描述的提示词。
5.2 与传统CAD软件打通：脚本化和API是关键
很多人担心的一个问题是：AI生成的是CadQuery模型，但我的团队用的是SolidWorks或Fusion 360，怎么接上？坦白讲，目前没有完美的直接打通方案，但有几种变通方式我实测过可用。
最实用的是“STEP中转”模式。CadQuery模型导出为STEP文件后，可以导入到任何主流CAD软件，作为“无特征历史”的实体模型使用。虽然导入后特征树是空的，但你可以基于这个实体做进一步建模、装配、出图、仿真。对于概念评审阶段，这个模式完全够用。第二个方案是用FreeCAD作为中间层，FreeCAD的Python API很灵活，能导入STEP后重新识别部分特征。不过自动特征识别在行业里一直是难题，效果不稳定，别抱太大期望。第三种是走商业API路线，比如之前提到的KittyCAD，它本身就是API优先的设计，AI生成的调用参数会直接在其生态里变成可编辑的模型，前端再自研界面就能包一层产品。
我觉得最合理的未来趋势是：CAD软件本身会长出AI入口，像SolidWorks、Fusion 360已经在做类似尝试，未来用自然语言操作特征树会越来越原生。到那个时候，“打通”就不再是个问题了，因为AI已经被内置在软件环境里。现阶段，STEP中转是投入产出比最高的过渡方案。
5.3 人机协同模式：AI出多方案，工程师做决策
用了这么久text-to-cad，我最大的心态转变是：不再指望它一次生成完全符合预期的模型，而是利用它的“低探索成本”特性，在设计前期快速铺开多个备选方案。过去让一个结构工程师在半天内提出三种不同结构布局，是很奢侈的事，但现在可以让AI在半小时内生成六个不同形态的初版方案，工程师从中挑出两个有潜力的，再结合强度分析、工艺评估去精细化。
有一类工作我特别推荐这种模式：非标设备底座、夹具主体、简单壳体。这些零件结构相对规则，特征不会太多，但形态上可以有明显差异，比如加强筋布局、孔位排布、外围形状的不同排列组合。让AI生成五六种变化，每一个都基于同一套参数模板，然后用视觉和简单的干涉检查快速初筛，这比我手动一个一个改快得多。等到选定方向后，再把人力和时间投入到该方案的深加工里，效率和质量的平衡会很舒服。
这套“AI批量出方案、人挑方向”的协同模式，是我觉得当前text-to-cad在工程场景落地最靠谱的姿势。它不需要AI达到“全自动设计”的水平，只需要它做到“无痛产出初稿”，就已经能实打实提效。
6. 踩坑实录：我在text-to-cad实践中遇到的典型问题与排查链路
6.1 语义歧义导致的几何错乱，光是措辞就能让你白干一下午
我遇到过最离谱的事情，是让模型“在一个圆柱顶面上创建一个矩形凸台”，它给我生成一个从圆柱侧面长出来的矩形。仔细复盘提示词才发现问题出在“顶面”这个语境，模型理解的“顶面”跟我们工程上理解的“圆柱顶面”完全不是一回事，它可能把“顶面”理解成“圆柱的上方区域”，结果默认对齐方式出了问题。
这类语义歧义在text-to-cad里远比在通用对话里危险，因为模型一旦理解错了，生成的几何还是完全合法的、看起来没什么毛病的，你如果不仔细检查根本发现不了。排查这类问题，我的做法是：定位到具体特征，让模型解释它的对齐方式和位置参考面，然后逐条核对我的原始描述和模型理解的偏差。如果发现“顶面”这种词太模糊，就改成“与圆柱上表面对齐，凸台底面与圆柱顶面共面”这种明确带共面和参考面的说法。一句话能避免的坑，绝不要靠后期检查来兜底。
6.2 单位、坐标系和公差，三个机械行业特有的暗坑
如果你是从3D生成领域转过来用text-to-cad，最容易踩的单位坑我已经在前面提到了，这里补充一个更隐蔽的坐标系问题。CadQuery的默认坐标系是世界坐标系，原点在绝对零点。但AI在建模时经常主观地设定一个局部坐标系，然后“忘记”把模型移回原点。结果是生成的模型虽然形状正确，但放置在离原点十万八千里的位置，后续装配、对齐全乱套。
排查坐标系问题时，第一件事就是看bounding box的坐标范围。如果一个模型的中心点距离原点太远，或者出现把实体放到负Z区这种不正常的现象，直接在代码里增加“将模型平移到原点”的操作。这个操作加在CadQuery里很直接，找实体边界算出中心，然后整体平移。我吃过几次亏之后，现在已经习惯把“输出前确保模型中心在原点上”作为固定检查项。
公差就更不用说了，这是AI目前完全无感的东西。CAD模型本身不带公差信息，STEP文件里如果手工添加了公差标注，那也主要是用来看的。打印出来的图纸、CMC工艺卡里需要的公差配合，还是得人来做。我在与AI协作时，会把公差标注排除在AI责任范围之外，明确划分“AI只管几何，人管公差和工艺”，这个分工能有效避免无谓的返工。
6.3 复杂装配体和token限制，与逐步分解策略
最后一个坑，是很多人在把text-to-cad用到复杂零件时撞得头破血流的原因——大模型根本吃不下整个装配体的完整描述。一个包含十几个零件的装配体，如果妄想一次性用自然语言生成，要么触发上下文超限报错，要么模型生成到一半就开始记混零部件之间的关系，输出一个结构混乱的大杂烩。
我现在的策略是“先分件，后装配”。把一个装配体拆成若干个独立零件，每个零件单独用text-to-cad生成、单独校验，最后统一导入CAD软件做装配约束。这个过程看起来多花了一道工序，但实际更省时间，因为每个零件的生成模型只需关注单一目标，成功率大幅提升。还有一点经验是，生成装配体零件时，要在每个零件的提示词里提醒“与其他零件的配合尺寸保持一致”，比如几个零件共享的孔径、轴径，写清楚相同值，这样才能保证最后能装得上。否则每个零件都“看似合理”，一装配立刻穿帮。
总而言之，text-to-cad的使用不是“问一嘴就完事”，而是一套需要通路设计、提示词工程、后处理校验、人机分工相互配合的完整工作流。它现在还取代不了工程师，但绝对是一个值得投入时间去掌握的新杠杆。
我个人的体会是，工具选型不用追求最新最贵，先把CadQuery加代码模型这条开源路线玩熟，你对text-to-cad的能力边界会有一个非常清晰的认识。这个认识，比任何宣传材料都值钱。等你摸清哪些场景它能扛住、哪些场景它必翻车之后，再决定要不要引入商业方案，会从容很多。
最后分享一个小技巧：给模型生成的代码建一个“历史版本库”。每次生成、修改、成功落地的代码，都按零件类型归档，下次遇到相似需求时，直接把旧代码作为参考给LLM，让它做增量修改。我试过，这种“以历史代码作为上下文”的做法，成功率比从零描述高出不止一个档次，而且日积月累下来，你就拥有了一套自己的私有人CAD模板库。这可能是text-to-cad最被低估的价值。
