最近AI生成内容的战场文本生图、文本生视频都已经卷出新高度但有一个方向相对冷门、含金量却极高就是 text-to-cad。它不做漂亮的像素画也不生成炫酷的视频片段而是让计算机仅凭一句自然语言描述直接生成可编辑、可装配、能进CAM流程的CAD模型。说实话我第一次看到这类项目跑出来的结果时第一反应是工业设计这帮人的工作流可能真的要变了。如果你平时的工作涉及机械设计、结构建模、非标自动化或者你只是个想快速把想法变成实体模型的爱好者text-to-cad 都值得你花半小时搞明白。它不是“又一种AI玩具”而是把“人脑中的设计意图”翻译成“机器能执行的建模指令”的实用工具链。这篇文章我会从原理、技术路线、实操管线到踩坑记录完整拆一遍尽量用工程师之间聊天的口气不整虚的。很多朋友一看“text-to-cad”这个词第一反应是“这不就是AI画图换个皮嘛”。实际上差远了。AI画图的本质是像素预测它生成的是RGB矩阵好看但没法拿去加工。text-to-cad 生成的是几何结构和特征树输出的是有尺寸、有约束、能被传统CAD软件打开编辑的参数化模型。一个是画布上的颜料一个是数控机床的加工代码完全两个维度。1. text-to-cad 到底是什么它和“AI画图”差在哪1.1 从“像素”到“特征”两种完全不同的生成逻辑先帮小白理清几个概念。CAD模型在计算机里有好几种表示方式最常见的三种B-rep边界表示用曲面和边围成一个封闭实体简单说就像用一张张裁剪好的皮把三维物体包起来。CSG构造实体几何用基本体圆柱、方块、球做布尔加减运算拼出模型就像搭积木。参数化特征这个最关键它记录的不是最终形状而是“如何一步步建出来”的操作序列比如“先画一个圆、再拉伸30mm、再倒角2mm”。这个操作序列就叫特征树。text-to-cad 的难点在于它逼着模型做“几何推理”和“顺序决策”。模型不能像画图那样蒙一个大概它得精确知道圆柱放哪、直径多少、孔贯穿还是盲孔。输入是自然语言输出是结构化的建模指令中间稍微错一个数值零件就废了。这也是为什么早期很多“文本生成3D模型”的AI项目看着很惊艳一放大全是表面凹凸不平的mesh网格真拿去3D打印要么打印出来尺寸不对要么根本没法转成工程图。而 text-to-cad 从一开始就选择了“难而正确”的路直接生成可编辑的参数化模型。1.2 它能做什么解决谁的问题我的实际体验是text-to-cad 目前最实用的价值是“把模糊需求变成初步方案”。比如你脑子里想的是“一个直径50mm、高度80mm的圆柱底座顶部开四个对称的M6螺纹孔”你用自然语言描述一遍它能在十几秒内给你一个带特征树的模型你拿到CAD软件里再微调就行。这个能力对几类人价值非常大非标机械工程师大量重复的标准件、支架、底座设计直接“说”出来让AI先生成初稿。创客和爱好者不会用SolidWorks、Fusion 360但能说清楚自己要什么AI帮忙补建模能力的短板。工业设计前期的概念探索想快速对比几种结构方案用文本改描述比重新建模快得多。参数化变体生成一个基础模型改几个关键词就能出一系列变体。1.3 目前生态盘点数据、工具、框架做 text-to-cad 绕不开几个关键资源Text2CAD 基准数据集Meta 的研究团队发布过一套数据集把自然语言指令和CAD建模操作序列对应起来。数据来源主要是公开的CAD模型库模型自带建模历史树研究者再为每个模型配上语言描述。这是目前训练这类模型最重要的公开语料。CADQuery / OpenSCAD程序化建模工具用Python代码描述三维模型。text-to-cad 的“文本生成代码”路线基本都落在这一类工具上。Fusion 360 / SolidWorks API工业级产品自带的脚本接口Text2CAD 数据集里的建模序列可以直接在Fusion 360里执行。各种大模型底座Llama、Mistral、Qwen配合LoRA微调是目前工程落地的主流选择。这里我多说一句。很多人看到“Text2CAD”这个词时会误以为它是某个单一大模型。其实它更像一个“任务定义”。现在社区里有好几个不同的实现路子有的用LLM直接生成建模命令序列有的用LLM写CadQuery代码有的走3D神经场重建下面重点拆这三条路线。2. 三条主流技术路线与选型分析2.1 路线一文本直接生成建模操作序列这条路线最接近“原生Text2CAD”的定义。模型的输入是自然语言输出是一串离散的建模操作token每个token对应一个CAD API调用比如“画草图”“标注尺寸”“拉伸”“打孔”。代表工作就是Text2CAD论文里的做法先把CAD模型的建模历史序列化再用类似机器翻译的encoder-decoder架构训练把语言描述映射成操作序列。推理时拿到序列后在CAD软件里自动重放一遍一个零件就重建出来了。这条路的最大优点是“忠实于CAD原生逻辑”每个token都有明确的几何含义模型输出天然具备可解释性。缺点是操作序列空间巨大而且不同CAD软件的操作命名和参数体系不一致跨软件泛化很吃力。实际跑过你会明显感觉到复杂模型稍微长一点序列后面几步就直接接不上了误差像滚雪球一样积累。2.2 路线二文本生成程序化建模代码这是目前我个人最推荐、也是社区最活跃的路线。思路很简单让LLM直接生成CADQuery或OpenSCAD的Python脚本然后本地执行脚本生成模型。比如用户输入“做一个长100mm、宽60mm、厚10mm的板四角倒R5圆角中心开一个直径20mm的通孔”LLM输出的是一段类似下面这样的代码import cadquery as cq result ( cq.Workplane(XY) .box(100, 60, 10) .edges(|Z) .fillet(5) .faces(Z) .workplane() .hole(20) ) cq.exporters.export(result, example.step)这段代码执行后直接生成带参数特征的三维实体可以导成STEP、STL等格式。这条路之所以火是因为它完美继承了大语言模型的代码能力。LLM本身在写Python代码这件事上已经很强了CadQuery又恰好是“用代码描述几何”的确定性工具两者一拍即合。它的坑也很明显LLM对数字和坐标的把握不稳定经常尺寸对、位置偏或者生成一个没定义的变量名。另外代码执行有安全隐患LLM生成的代码你必须在沙箱里跑不能直接扔到生产环境裸奔。这个问题我后面会专门讲。2.3 路线三文本生成三维几何场这条路线更偏“AI生成3D”而不是“CAD生成”。模型接收文本描述输出体素、点云或隐式神经场再用Marching Cubes之类算法提取三角网格。好处是自由度高能生成有机曲面、雕塑类造型这是前两条路线很难做到的。坏处是输出的网格无法直接编辑没有特征树转STEP时经常出现破面CAM加工基本没法用。它的定位很适合做概念验证、游戏资产、快速原型展示不太适合正经制造业。2.4 三条路线怎么选我给你一个实在的对比路线代表方式输出格式可编辑性精度工程落地难度建模序列Text2CAD论文、Fusion 360脚本操作序列高中高高需绑定CAD API程序化代码LLM CadQuery/OpenSCADPython代码→STEP/STL高中高中需处理代码执行神经场重建点云/隐式场→网格STL/OBJ低低低但只能看不能用选型逻辑很清晰你要是做消费级创意工具、游戏资产走路线三快、能看、好演示。你要是做正经工业辅助设计路线二是投入产出比最稳的选择因为CadQuery代码天然跟程序化建模绑定而且能无损导出STEP格式后面接CAM、接有限元分析都不虚。3. 从零搭一套可用的 text-to-cad 最小管线光看论文没用实际跑一遍你才能真正理解这类系统的甜点和痛点。下面这套最小可用管线是我自己反复调过、踩过坑之后沉淀下来的你可以直接照着搭。3.1 环境准备与依赖我默认你用的是Linux或Windows下有WSL的机器有NVIDIA显卡最好没有的话用小模型也能跑只是效果差一点。需要装的东西如下conda create -n text2cad python3.10 conda activate text2cad pip install torch transformers datasets accelerate peft pip install cadquery trimesh numpy matplotlib这里特别注意CadQuery的安装。CadQuery依赖OpenCascade这个几何内核对Python版本比较挑剔Python 3.11以上偶尔会有二进制包缺失的问题建议老老实实用3.10。另外如果你的机器没有图形界面记得装一个libgl库否则CadQuery导STL时容易报libGL.so.1找不到。这个报错我在新服务器上至少踩过三回后面查了才知道是缺系统库。3.2 数据准备用公开数据还是造私有数据想训练一个正经的text-to-cad模型首选公开的Text2CAD数据集里面已经做好了指令和建模序列的对齐。但这里有个实际问题公开数据里的建模对象偏学术化很多是简化的机械零件跟你公司实际的零件风格差了十万八千里。如果你只是做个人项目或技术验证我建议先不训练模型直接用现成的开源微调权重。社区里已经有人放出了基于CodeLlama或Qwen微调过的CAD生成模型用HuggingFace的transformers加载就能跑。这样最快半小时出效果。如果你确实需要私有化比如要处理你们公司的标准件库我推荐“半自动造数据”的方式先用CadQuery写一批典型零件脚本再让LLM根据代码反向生成对应的自然语言描述形成指令-代码对。这样生成的数据质量比纯人工标注高很多而且代码是真实能跑的不会出现文本和模型对不上的问题。3.3 模型微调与提示词设计选模型这事不用太纠结。个人开发者用Qwen2.5-7B-Instruct这类就能打效果跟Llama-3-8B接近中文支持还更好。如果你想省显存用LoRA微调只改一小部分参数单卡24G也能胜任。微调前最值得花时间的其实是提示词模板。我试过用工程化的方式约束模型输出成功率能有明显提升。一个典型的模板长这样你是专业的CAD建模工程师。请根据用户描述输出CadQuery Python代码。 要求 1. 只输出代码不要解释。 2. 代码必须使用cq.Workplane(XY)作为起点。 3. 所有尺寸必须带单位mm。 4. 如果描述中存在未明确的尺寸用合理工业默认值并在代码注释里标注。 用户描述{用户输入} 代码这个模板里最关键是“如果描述不明确用默认值”这条。否则模型会自作主张写一堆参数变量定义执行的时候直接报NameError。加了这条之后生成代码的可执行率从不到一半提升到了七成以上效果立竿见影。3.4 生成-执行-修复闭环这是我最想分享的实操经验text-to-cad 系统不能做“一次生成”必须做“生成-执行-修复”的闭环。具体做法是LLM生成代码之后马上在隔离环境里执行它把执行时报错信息原封不动地回填到下一轮提示词里让LLM自己修代码。这个循环最多跑三遍通常就能把一个“差一口气”的代码修到可执行。我写过一个简化版的循环核心思路大概是这样for attempt in range(3): code llm_generate(prompt, user_input) result execute_in_sandbox(code) if result.success: break prompt f\n上一次执行出现以下错误请修正代码\n{result.error}这一步非常吃LLM的上下文理解能力实测下来Qwen和Llama对报错信息的理解都相当不错。真正重要的是把执行环境做干净每次执行都在独立的Docker容器或者subprocess沙箱里避免模型生成恶意代码比如删文件、读系统信息对你的开发机造成破坏。这个风险不是危言耸听LLM在压力下真的会生成奇怪的路径操作别拿生产环境赌。3.5 一个能跑通的 CadQuery 示例为了让你有更直观的感受我放一个完整可跑的示例。输入描述是“一个底面边长40mm、高25mm的正四棱台顶部中心有一个直径12mm、深15mm的盲孔”。CadQuery代码长这样import cadquery as cq result ( cq.Workplane(XY) .polygon(4, 40) .workplane(offset25) .polygon(4, 20) .loft() .faces(Z) .workplane() .hole(12, depth15) ) cq.exporters.export(result, truncated_pyramid.step)这段代码用到loft放样和盲孔两个关键操作。模型生成这样的代码需要同时理解“正四棱台”这个几何概念和CadQuery的API写法光靠语言模型硬背代码是做不到的必须真训练过大量类似样本才行。这也是为什么我说这条路线的壁垒不只是模型能力高质量训练数据和工程闭环缺一不可。3.6 质量评估怎么做模型生成完怎么判断好不好别用“看着像不像”来评判太主观。我建议工程上盯三个指标可执行率生成的代码在沙箱里能成功运行、输出STEP文件的比例。这是最基础的门槛。尺寸偏差对照用户描述里的关键尺寸量生成模型的实际尺寸误差。比如描述说直径20mm生成出来20.3mm偏差就是0.3mm。特征完整性用户要求的孔、倒角、阵列等特征是否全部存在。这个可以用算法比对也可以抽检人工核对。实际操作中可执行率是我最先优化的指标因为它直接决定系统能不能用起来。特征完整性是第二道关尺寸偏差反而是最不值钱的因为CAD软件打开模型后一拉尺寸就能改。4. 实战中高频踩坑与排查实录4.1 代码能跑但几何不对这是出现频率最高的问题。代码执行成功模型也导出了但生成出来的零件根本不是描述里的东西。比如描述“中心开孔”生成出来位置偏了5mm或者“对称分布四个孔”结果只开了三个。排查思路很简单先看是不是模型没理解空间关系。LLM对“中心”“对称”“阵列”这类相对位置概念的理解不可靠你需要做的是把空间描述强化到提示词里。比如改成“孔的圆心与底面中心重合”“四个孔沿圆周均匀分布角度间隔90度”生成正确率能上去一大截。另一个很隐蔽的坑是CadQuery的坐标系。默认基准面是XY平面“Z”代表正Z方向的面“|Z”代表平行于Z轴的边。LLM不熟悉这些符号时经常用错导致倒角选错边、草图画错面。遇到这种问题我建议在系统提示词里内置几行“坐标系选面速查”让模型先查再写。4.2 生成结果无法导入传统CAD/CAM很多人会忽略格式兼容的问题。LLM默认生成的STL是三角网格格式能看能打印但SolidWorks、Fusion 360打开STL后只能当网格体处理没法编辑特征更别提生成工程图了。我强烈建议生成STEP格式。STEP是工业界通用的B-rep交换格式保留实体边界信息主流CAD软件都能无缝打开并继续编辑。CadQuery导出STEP就是一行代码的事关键是提示词里要让模型“习惯先构建实体再将实体导出为step”。这个细节不提前做后面接CAM流程会痛不欲生。4.3 训练数据不够怎么办很多团队不是不想私有化部署而是造数据太痛苦。一条一条写自然语言描述和对应代码写几百条人就会疯掉。我推荐“反向生成法”先把你们产品线里典型的零件都用CadQuery脚本建好然后用LLM针对这些脚本来回写自然语言描述。写完之后再用一个简单的“文本-代码”对齐校验脚本过一遍看看描述能不能正确匹配回原代码。数据质量比数量重要我宁可要200条高质量对齐数据也不要20000条自动爬来的脏数据。还有一个补充技巧利用CAD软件自带的宏录制功能。老工程师在SolidWorks或Fusion 360里建模时软件会记录每一步操作。把这些宏导出来配上人工或LLM写的文字说明也能低成本造出训练数据。4.4 环境类问题和“安装”相关的困惑每次提到CAD相关项目总有人把“text-to-cad”和传统CAD软件安装问题混淆。比如搜“cad下载”“cad安装教程”“cad激活页面脚本发生错误”的人其实是在折腾AutoCAD或中望CAD这种传统软件跟text-to-cad这个AI项目完全是两个世界。这类问题的核心还是环境依赖。我自己在部署时遇到最典型的是这几个现象原因解决方式CadQuery导入报错Python版本不匹配用conda建3.10虚拟环境导出STEP时崩溃OpenCascade版本冲突升级cadquery到最新稳定版跑LLM时显存溢出模型太大或batch size过大用4bit量化加载batch size设为1生成代码执行超时死循环或复杂布尔运算设置执行超时比如30秒强制终止这些坑每一个都不难解决但排查起来很容易被误导。我的建议是搭环境时每一步都跑通一个最小验证比如cadquery导入成功后先导出一个最简单的立方体再开始跑模型。不要一上来就全链路调试否则报错时你根本分不清是模型问题、代码问题还是环境问题。4.5 一个快速排错速查表我把日常挨过的打整理成一张速查表可以直接保存在笔记里。遇到问题先对号入座能省一半排查时间生成代码总在fillet或chamfer报错多半是选边方式不对建议改为按面倒角或者返回原模型先不处理细节特征。生成模型缺少孔位优先检查提示词是否明确给出孔的数量、分布、直径。STL能导出但STEP失败检查是不是用了大量网格运算比如split改成实体布尔运算。模型生成内容与描述完全无关降低生成温度到0.1同时检查提示词模板是否被截断。多次重试后代码越改越乱停止重试回到上一轮成功版本手动微调而非继续让模型改。5. 落地场景、边界与后续扩展5.1 现在就能用起来的地方说句公道话text-to-cad 到目前还不是能完全取代工程师的“银弹”但有三类场景已经可以稳定落地一是概念方案的前期探索。我以前做非标设计接到需求后第一件事是凭空构思结构现在直接生成几个初版模型在CAD里快速评价可行性整体效率提升很明显。二是标准件库的快速生成。法兰、支架、轴套、传感器固定板这类零件结构相似但尺寸一变再变。以前每来一个新尺寸就得重新画一遍现在让AI按描述改参数几秒钟生成草稿人工检查一下就能用。三是跨专业协作。机械工程师和电气工程师对同一套模型的理解经常不在一个频道上。电气工程师说“我要两个耳朵”机械工程师可能理解成两种完全不同的结构。用text-to-cad把口头描述变成可视化模型立刻消除歧义。5.2 别把text-to-cad当万能工具有句话我说得直白点text-to-cad 适合做“从无到有的粗稿”不适合做“从有到精的细调”。模型再强也替代不了对材料、工艺、装配关系的理解。生成出来的模型永远要过一遍强度校核、干涉检查、工艺评审。另外我劝你们别在自由曲面造型和有机形态上难为它。遇到需要做流线型外壳、复杂曲面过渡的场景老老实实去用细分建模或参数化曲面工具更靠谱。text-to-cad 的地盘是规则机械件、钣金件、简单壳体越规则越合适。5.3 这块内容还能怎么延展从技术角度看text-to-cad 和几个方向结合后价值会更大与数值仿真结合文本生成模型后直接跑有限元分析再让模型按仿真结果优化形状形成“设计-仿真-优化”闭环。与知识图谱结合把材料性能、加工工艺、成本信息挂接在生成结果上AI建模的同时给出工艺建议。与逆向工程结合对方给了一个实物扫描件你描述目标结构AI帮你生成可编辑的替代模型。私有部署加RAG把公司设计规范、历史图纸、典型错误案例喂给模型生成结果更贴合企业实际。最后再分享一个心得。我做这个方向的项目时最大的收获不是模型调得多好而是彻底理解了“设计意图的表达”有多难。人类用语言描述三维结构本身是模糊的同一个零件机加工师傅和钣金师傅听描述想出来的完全不一样。text-to-cad 真正要解决的不是建模效率问题而是需求传递过程中的信息损耗问题。谁在这方面做得好谁就能在下一轮工业智能化里占住身位。 
长河君 · 2026/10/26 17:01:23 · 阅读 1.2k Text-to-CAD：从自然语言到参数化模型的工业级生成全解析
最近AI生成内容的战场文本生图、文本生视频都已经卷出新高度但有一个方向相对冷门、含金量却极高就是 text-to-cad。它不做漂亮的像素画也不生成炫酷的视频片段而是让计算机仅凭一句自然语言描述直接生成可编辑、可装配、能进CAM流程的CAD模型。说实话我第一次看到这类项目跑出来的结果时第一反应是工业设计这帮人的工作流可能真的要变了。如果你平时的工作涉及机械设计、结构建模、非标自动化或者你只是个想快速把想法变成实体模型的爱好者text-to-cad 都值得你花半小时搞明白。它不是“又一种AI玩具”而是把“人脑中的设计意图”翻译成“机器能执行的建模指令”的实用工具链。这篇文章我会从原理、技术路线、实操管线到踩坑记录完整拆一遍尽量用工程师之间聊天的口气不整虚的。很多朋友一看“text-to-cad”这个词第一反应是“这不就是AI画图换个皮嘛”。实际上差远了。AI画图的本质是像素预测它生成的是RGB矩阵好看但没法拿去加工。text-to-cad 生成的是几何结构和特征树输出的是有尺寸、有约束、能被传统CAD软件打开编辑的参数化模型。一个是画布上的颜料一个是数控机床的加工代码完全两个维度。1. text-to-cad 到底是什么它和“AI画图”差在哪1.1 从“像素”到“特征”两种完全不同的生成逻辑先帮小白理清几个概念。CAD模型在计算机里有好几种表示方式最常见的三种B-rep边界表示用曲面和边围成一个封闭实体简单说就像用一张张裁剪好的皮把三维物体包起来。CSG构造实体几何用基本体圆柱、方块、球做布尔加减运算拼出模型就像搭积木。参数化特征这个最关键它记录的不是最终形状而是“如何一步步建出来”的操作序列比如“先画一个圆、再拉伸30mm、再倒角2mm”。这个操作序列就叫特征树。text-to-cad 的难点在于它逼着模型做“几何推理”和“顺序决策”。模型不能像画图那样蒙一个大概它得精确知道圆柱放哪、直径多少、孔贯穿还是盲孔。输入是自然语言输出是结构化的建模指令中间稍微错一个数值零件就废了。这也是为什么早期很多“文本生成3D模型”的AI项目看着很惊艳一放大全是表面凹凸不平的mesh网格真拿去3D打印要么打印出来尺寸不对要么根本没法转成工程图。而 text-to-cad 从一开始就选择了“难而正确”的路直接生成可编辑的参数化模型。1.2 它能做什么解决谁的问题我的实际体验是text-to-cad 目前最实用的价值是“把模糊需求变成初步方案”。比如你脑子里想的是“一个直径50mm、高度80mm的圆柱底座顶部开四个对称的M6螺纹孔”你用自然语言描述一遍它能在十几秒内给你一个带特征树的模型你拿到CAD软件里再微调就行。这个能力对几类人价值非常大非标机械工程师大量重复的标准件、支架、底座设计直接“说”出来让AI先生成初稿。创客和爱好者不会用SolidWorks、Fusion 360但能说清楚自己要什么AI帮忙补建模能力的短板。工业设计前期的概念探索想快速对比几种结构方案用文本改描述比重新建模快得多。参数化变体生成一个基础模型改几个关键词就能出一系列变体。1.3 目前生态盘点数据、工具、框架做 text-to-cad 绕不开几个关键资源Text2CAD 基准数据集Meta 的研究团队发布过一套数据集把自然语言指令和CAD建模操作序列对应起来。数据来源主要是公开的CAD模型库模型自带建模历史树研究者再为每个模型配上语言描述。这是目前训练这类模型最重要的公开语料。CADQuery / OpenSCAD程序化建模工具用Python代码描述三维模型。text-to-cad 的“文本生成代码”路线基本都落在这一类工具上。Fusion 360 / SolidWorks API工业级产品自带的脚本接口Text2CAD 数据集里的建模序列可以直接在Fusion 360里执行。各种大模型底座Llama、Mistral、Qwen配合LoRA微调是目前工程落地的主流选择。这里我多说一句。很多人看到“Text2CAD”这个词时会误以为它是某个单一大模型。其实它更像一个“任务定义”。现在社区里有好几个不同的实现路子有的用LLM直接生成建模命令序列有的用LLM写CadQuery代码有的走3D神经场重建下面重点拆这三条路线。2. 三条主流技术路线与选型分析2.1 路线一文本直接生成建模操作序列这条路线最接近“原生Text2CAD”的定义。模型的输入是自然语言输出是一串离散的建模操作token每个token对应一个CAD API调用比如“画草图”“标注尺寸”“拉伸”“打孔”。代表工作就是Text2CAD论文里的做法先把CAD模型的建模历史序列化再用类似机器翻译的encoder-decoder架构训练把语言描述映射成操作序列。推理时拿到序列后在CAD软件里自动重放一遍一个零件就重建出来了。这条路的最大优点是“忠实于CAD原生逻辑”每个token都有明确的几何含义模型输出天然具备可解释性。缺点是操作序列空间巨大而且不同CAD软件的操作命名和参数体系不一致跨软件泛化很吃力。实际跑过你会明显感觉到复杂模型稍微长一点序列后面几步就直接接不上了误差像滚雪球一样积累。2.2 路线二文本生成程序化建模代码这是目前我个人最推荐、也是社区最活跃的路线。思路很简单让LLM直接生成CADQuery或OpenSCAD的Python脚本然后本地执行脚本生成模型。比如用户输入“做一个长100mm、宽60mm、厚10mm的板四角倒R5圆角中心开一个直径20mm的通孔”LLM输出的是一段类似下面这样的代码import cadquery as cq result ( cq.Workplane(XY) .box(100, 60, 10) .edges(|Z) .fillet(5) .faces(Z) .workplane() .hole(20) ) cq.exporters.export(result, example.step)这段代码执行后直接生成带参数特征的三维实体可以导成STEP、STL等格式。这条路之所以火是因为它完美继承了大语言模型的代码能力。LLM本身在写Python代码这件事上已经很强了CadQuery又恰好是“用代码描述几何”的确定性工具两者一拍即合。它的坑也很明显LLM对数字和坐标的把握不稳定经常尺寸对、位置偏或者生成一个没定义的变量名。另外代码执行有安全隐患LLM生成的代码你必须在沙箱里跑不能直接扔到生产环境裸奔。这个问题我后面会专门讲。2.3 路线三文本生成三维几何场这条路线更偏“AI生成3D”而不是“CAD生成”。模型接收文本描述输出体素、点云或隐式神经场再用Marching Cubes之类算法提取三角网格。好处是自由度高能生成有机曲面、雕塑类造型这是前两条路线很难做到的。坏处是输出的网格无法直接编辑没有特征树转STEP时经常出现破面CAM加工基本没法用。它的定位很适合做概念验证、游戏资产、快速原型展示不太适合正经制造业。2.4 三条路线怎么选我给你一个实在的对比路线代表方式输出格式可编辑性精度工程落地难度建模序列Text2CAD论文、Fusion 360脚本操作序列高中高高需绑定CAD API程序化代码LLM CadQuery/OpenSCADPython代码→STEP/STL高中高中需处理代码执行神经场重建点云/隐式场→网格STL/OBJ低低低但只能看不能用选型逻辑很清晰你要是做消费级创意工具、游戏资产走路线三快、能看、好演示。你要是做正经工业辅助设计路线二是投入产出比最稳的选择因为CadQuery代码天然跟程序化建模绑定而且能无损导出STEP格式后面接CAM、接有限元分析都不虚。3. 从零搭一套可用的 text-to-cad 最小管线光看论文没用实际跑一遍你才能真正理解这类系统的甜点和痛点。下面这套最小可用管线是我自己反复调过、踩过坑之后沉淀下来的你可以直接照着搭。3.1 环境准备与依赖我默认你用的是Linux或Windows下有WSL的机器有NVIDIA显卡最好没有的话用小模型也能跑只是效果差一点。需要装的东西如下conda create -n text2cad python3.10 conda activate text2cad pip install torch transformers datasets accelerate peft pip install cadquery trimesh numpy matplotlib这里特别注意CadQuery的安装。CadQuery依赖OpenCascade这个几何内核对Python版本比较挑剔Python 3.11以上偶尔会有二进制包缺失的问题建议老老实实用3.10。另外如果你的机器没有图形界面记得装一个libgl库否则CadQuery导STL时容易报libGL.so.1找不到。这个报错我在新服务器上至少踩过三回后面查了才知道是缺系统库。3.2 数据准备用公开数据还是造私有数据想训练一个正经的text-to-cad模型首选公开的Text2CAD数据集里面已经做好了指令和建模序列的对齐。但这里有个实际问题公开数据里的建模对象偏学术化很多是简化的机械零件跟你公司实际的零件风格差了十万八千里。如果你只是做个人项目或技术验证我建议先不训练模型直接用现成的开源微调权重。社区里已经有人放出了基于CodeLlama或Qwen微调过的CAD生成模型用HuggingFace的transformers加载就能跑。这样最快半小时出效果。如果你确实需要私有化比如要处理你们公司的标准件库我推荐“半自动造数据”的方式先用CadQuery写一批典型零件脚本再让LLM根据代码反向生成对应的自然语言描述形成指令-代码对。这样生成的数据质量比纯人工标注高很多而且代码是真实能跑的不会出现文本和模型对不上的问题。3.3 模型微调与提示词设计选模型这事不用太纠结。个人开发者用Qwen2.5-7B-Instruct这类就能打效果跟Llama-3-8B接近中文支持还更好。如果你想省显存用LoRA微调只改一小部分参数单卡24G也能胜任。微调前最值得花时间的其实是提示词模板。我试过用工程化的方式约束模型输出成功率能有明显提升。一个典型的模板长这样你是专业的CAD建模工程师。请根据用户描述输出CadQuery Python代码。 要求 1. 只输出代码不要解释。 2. 代码必须使用cq.Workplane(XY)作为起点。 3. 所有尺寸必须带单位mm。 4. 如果描述中存在未明确的尺寸用合理工业默认值并在代码注释里标注。 用户描述{用户输入} 代码这个模板里最关键是“如果描述不明确用默认值”这条。否则模型会自作主张写一堆参数变量定义执行的时候直接报NameError。加了这条之后生成代码的可执行率从不到一半提升到了七成以上效果立竿见影。3.4 生成-执行-修复闭环这是我最想分享的实操经验text-to-cad 系统不能做“一次生成”必须做“生成-执行-修复”的闭环。具体做法是LLM生成代码之后马上在隔离环境里执行它把执行时报错信息原封不动地回填到下一轮提示词里让LLM自己修代码。这个循环最多跑三遍通常就能把一个“差一口气”的代码修到可执行。我写过一个简化版的循环核心思路大概是这样for attempt in range(3): code llm_generate(prompt, user_input) result execute_in_sandbox(code) if result.success: break prompt f\n上一次执行出现以下错误请修正代码\n{result.error}这一步非常吃LLM的上下文理解能力实测下来Qwen和Llama对报错信息的理解都相当不错。真正重要的是把执行环境做干净每次执行都在独立的Docker容器或者subprocess沙箱里避免模型生成恶意代码比如删文件、读系统信息对你的开发机造成破坏。这个风险不是危言耸听LLM在压力下真的会生成奇怪的路径操作别拿生产环境赌。3.5 一个能跑通的 CadQuery 示例为了让你有更直观的感受我放一个完整可跑的示例。输入描述是“一个底面边长40mm、高25mm的正四棱台顶部中心有一个直径12mm、深15mm的盲孔”。CadQuery代码长这样import cadquery as cq result ( cq.Workplane(XY) .polygon(4, 40) .workplane(offset25) .polygon(4, 20) .loft() .faces(Z) .workplane() .hole(12, depth15) ) cq.exporters.export(result, truncated_pyramid.step)这段代码用到loft放样和盲孔两个关键操作。模型生成这样的代码需要同时理解“正四棱台”这个几何概念和CadQuery的API写法光靠语言模型硬背代码是做不到的必须真训练过大量类似样本才行。这也是为什么我说这条路线的壁垒不只是模型能力高质量训练数据和工程闭环缺一不可。3.6 质量评估怎么做模型生成完怎么判断好不好别用“看着像不像”来评判太主观。我建议工程上盯三个指标可执行率生成的代码在沙箱里能成功运行、输出STEP文件的比例。这是最基础的门槛。尺寸偏差对照用户描述里的关键尺寸量生成模型的实际尺寸误差。比如描述说直径20mm生成出来20.3mm偏差就是0.3mm。特征完整性用户要求的孔、倒角、阵列等特征是否全部存在。这个可以用算法比对也可以抽检人工核对。实际操作中可执行率是我最先优化的指标因为它直接决定系统能不能用起来。特征完整性是第二道关尺寸偏差反而是最不值钱的因为CAD软件打开模型后一拉尺寸就能改。4. 实战中高频踩坑与排查实录4.1 代码能跑但几何不对这是出现频率最高的问题。代码执行成功模型也导出了但生成出来的零件根本不是描述里的东西。比如描述“中心开孔”生成出来位置偏了5mm或者“对称分布四个孔”结果只开了三个。排查思路很简单先看是不是模型没理解空间关系。LLM对“中心”“对称”“阵列”这类相对位置概念的理解不可靠你需要做的是把空间描述强化到提示词里。比如改成“孔的圆心与底面中心重合”“四个孔沿圆周均匀分布角度间隔90度”生成正确率能上去一大截。另一个很隐蔽的坑是CadQuery的坐标系。默认基准面是XY平面“Z”代表正Z方向的面“|Z”代表平行于Z轴的边。LLM不熟悉这些符号时经常用错导致倒角选错边、草图画错面。遇到这种问题我建议在系统提示词里内置几行“坐标系选面速查”让模型先查再写。4.2 生成结果无法导入传统CAD/CAM很多人会忽略格式兼容的问题。LLM默认生成的STL是三角网格格式能看能打印但SolidWorks、Fusion 360打开STL后只能当网格体处理没法编辑特征更别提生成工程图了。我强烈建议生成STEP格式。STEP是工业界通用的B-rep交换格式保留实体边界信息主流CAD软件都能无缝打开并继续编辑。CadQuery导出STEP就是一行代码的事关键是提示词里要让模型“习惯先构建实体再将实体导出为step”。这个细节不提前做后面接CAM流程会痛不欲生。4.3 训练数据不够怎么办很多团队不是不想私有化部署而是造数据太痛苦。一条一条写自然语言描述和对应代码写几百条人就会疯掉。我推荐“反向生成法”先把你们产品线里典型的零件都用CadQuery脚本建好然后用LLM针对这些脚本来回写自然语言描述。写完之后再用一个简单的“文本-代码”对齐校验脚本过一遍看看描述能不能正确匹配回原代码。数据质量比数量重要我宁可要200条高质量对齐数据也不要20000条自动爬来的脏数据。还有一个补充技巧利用CAD软件自带的宏录制功能。老工程师在SolidWorks或Fusion 360里建模时软件会记录每一步操作。把这些宏导出来配上人工或LLM写的文字说明也能低成本造出训练数据。4.4 环境类问题和“安装”相关的困惑每次提到CAD相关项目总有人把“text-to-cad”和传统CAD软件安装问题混淆。比如搜“cad下载”“cad安装教程”“cad激活页面脚本发生错误”的人其实是在折腾AutoCAD或中望CAD这种传统软件跟text-to-cad这个AI项目完全是两个世界。这类问题的核心还是环境依赖。我自己在部署时遇到最典型的是这几个现象原因解决方式CadQuery导入报错Python版本不匹配用conda建3.10虚拟环境导出STEP时崩溃OpenCascade版本冲突升级cadquery到最新稳定版跑LLM时显存溢出模型太大或batch size过大用4bit量化加载batch size设为1生成代码执行超时死循环或复杂布尔运算设置执行超时比如30秒强制终止这些坑每一个都不难解决但排查起来很容易被误导。我的建议是搭环境时每一步都跑通一个最小验证比如cadquery导入成功后先导出一个最简单的立方体再开始跑模型。不要一上来就全链路调试否则报错时你根本分不清是模型问题、代码问题还是环境问题。4.5 一个快速排错速查表我把日常挨过的打整理成一张速查表可以直接保存在笔记里。遇到问题先对号入座能省一半排查时间生成代码总在fillet或chamfer报错多半是选边方式不对建议改为按面倒角或者返回原模型先不处理细节特征。生成模型缺少孔位优先检查提示词是否明确给出孔的数量、分布、直径。STL能导出但STEP失败检查是不是用了大量网格运算比如split改成实体布尔运算。模型生成内容与描述完全无关降低生成温度到0.1同时检查提示词模板是否被截断。多次重试后代码越改越乱停止重试回到上一轮成功版本手动微调而非继续让模型改。5. 落地场景、边界与后续扩展5.1 现在就能用起来的地方说句公道话text-to-cad 到目前还不是能完全取代工程师的“银弹”但有三类场景已经可以稳定落地一是概念方案的前期探索。我以前做非标设计接到需求后第一件事是凭空构思结构现在直接生成几个初版模型在CAD里快速评价可行性整体效率提升很明显。二是标准件库的快速生成。法兰、支架、轴套、传感器固定板这类零件结构相似但尺寸一变再变。以前每来一个新尺寸就得重新画一遍现在让AI按描述改参数几秒钟生成草稿人工检查一下就能用。三是跨专业协作。机械工程师和电气工程师对同一套模型的理解经常不在一个频道上。电气工程师说“我要两个耳朵”机械工程师可能理解成两种完全不同的结构。用text-to-cad把口头描述变成可视化模型立刻消除歧义。5.2 别把text-to-cad当万能工具有句话我说得直白点text-to-cad 适合做“从无到有的粗稿”不适合做“从有到精的细调”。模型再强也替代不了对材料、工艺、装配关系的理解。生成出来的模型永远要过一遍强度校核、干涉检查、工艺评审。另外我劝你们别在自由曲面造型和有机形态上难为它。遇到需要做流线型外壳、复杂曲面过渡的场景老老实实去用细分建模或参数化曲面工具更靠谱。text-to-cad 的地盘是规则机械件、钣金件、简单壳体越规则越合适。5.3 这块内容还能怎么延展从技术角度看text-to-cad 和几个方向结合后价值会更大与数值仿真结合文本生成模型后直接跑有限元分析再让模型按仿真结果优化形状形成“设计-仿真-优化”闭环。与知识图谱结合把材料性能、加工工艺、成本信息挂接在生成结果上AI建模的同时给出工艺建议。与逆向工程结合对方给了一个实物扫描件你描述目标结构AI帮你生成可编辑的替代模型。私有部署加RAG把公司设计规范、历史图纸、典型错误案例喂给模型生成结果更贴合企业实际。最后再分享一个心得。我做这个方向的项目时最大的收获不是模型调得多好而是彻底理解了“设计意图的表达”有多难。人类用语言描述三维结构本身是模糊的同一个零件机加工师傅和钣金师傅听描述想出来的完全不一样。text-to-cad 真正要解决的不是建模效率问题而是需求传递过程中的信息损耗问题。谁在这方面做得好谁就能在下一轮工业智能化里占住身位。