1. Text-to-CAD 到底是什么从画图到说图输入一句帮我做一个M8螺栓的参数化模型几秒钟后拿到一个可以被 SolidWorks、中望CAD 这类软件正常打开、继续编辑、出工程图的三维实体——这不是影视特效而是当下的 text-to-cad 技术正在做的事。你可能已经听说过AI生成图片AI写代码但 text-to-cad 不太一样它交出来的不是一张效果图而是一份真实可加工的CAD数据。对画了二十年图的工程师来说这可能是CAD工作流里最值得重新审视的变化。这篇文章不想堆概念只想把关于 text-to-cad 的几件事说透它到底交付什么、目前有哪些路可以走、底层原理是怎么转起来的以及我个人实测半年后踩过的坑。简单说你读完以后不光知道能干嘛还能判断该不该用、怎么用。1.1 自然语言到三维模型一条提示词背后发生了什么先说清楚 text-to-cad 到底交付什么。给AI一句外径60mm、内孔20mm、厚度8mm带六个均布M6孔的法兰盘它需要给你一个可编辑的参数化三维实体而不是一张渲染图、一段描述文字或者一个stl网格。这里有个容易混淆的点很多人把AI生成3D模型和 text-to-cad 划等号。两者有交集但有本质区别。文生3D模型比如根据描述生成物件网格交付的是三角网格适合放进游戏、做3D打印预览但在工程软件里没法对孔位做尺寸约束、没法修改倒角、没法把圆柱面转成螺纹规格——它没有工程语义。text-to-cad 交付的是带特征树、可参数化修改的真实模型甚至能追溯到拉伸打孔阵列这些操作记录。举个例子你就明白了。一款CAD软件里的法兰盘左侧列表通常记录着基体旋转、中心孔切除、六个孔阵列、端面倒角。你要修改某一步双击参数就能重算。而一个STL网格文件本质上就是一堆三角形改一个孔位等于把局部三角形全部重建。text-to-cad 要做的是把那句自然语言翻译成特征树的操作序列再由CAD内核按顺序执行最终生成可编辑的实体模型。在技术实现上text-to-cad 通常分两步先把自然语言拆解成一系列建模操作拉伸多高、哪个面打孔、阵列几个再交给CAD内核按这些操作精确计算几何体。简单说AI负责理解并设计内核负责算得准。这两步的衔接质量基本决定了生成结果能有多大的工程可用性。1.2 为什么是现在才火起来大模型与代码生成能力成熟text-to-cad 的概念并不新学术圈很早就有人做语义到CAD的翻译。但过去效果差根本原因是传统自然语言处理模型对多高几个孔均布这类带空间关系和工程约束的描述几乎没有理解力更别说把描述拆成精确的建模步骤。真正让 text-to-cad 走向实用的是大语言模型的代码生成能力。CAD建模步骤可以用 CadQuery、OpenSCAD 这类程序化建模语言完整表达而程序化建模语言本质上是代码只要LLM能准确地把自然语言翻译成代码CAD内核就能稳定执行出几何结果。这就把AI直接算几何这个难啃的骨头转移成了AI写代码这种已经被验证过的能力。我试过用几个不同的大模型去写 CadQuery 代码只要模型见过足够多的开源建模脚本生成质量基本可用。另一个因素是工具链成熟。CadQuery、FreeCAD Python API、OpenSCAD 这些方案让程序化建模有了健壮的基础加上 STEP 格式在主流CAD软件之间的互操作越来越顺畅AI生成的模型可以被下游正常打开和修改。甚至可以说text-to-cad 能火靠的不是某个天才算法而是三样东西恰好凑齐了能写代码的大模型、能稳定执行几何的内核、能交换数据的标准格式。2. 主流实现路线盘点商业API与开源自建的取舍聊实现之前先盘点一下现在能触碰到的方案。目前 text-to-cad 大致分两条路线一条是用商业API一条是自己搭LLM 程序化建模库的开源链路。两者各有优势也各有明显短板下面展开说。2.1 商业平台直接调用API的体验国外比较有代表性的是 Zoo前身 KittyCAD提供的 Text-to-CAD API。它的用法接近现在常见的AI接口传一段文本描述和想要的输出格式STEP、STL等API返回可下载的模型文件。Backflip AI 也做了类似的事支持文本和图片生成CAD模型重点服务3D打印用户。这类商业API最大的优势是封装度高几何内核在云端完成返回的模型格式规范不需要自己搭建环境。我实测过一轮简单零件垫片、支架、带孔板的成功率相当可观复杂曲面和螺纹类特征稳定性会差一些。对没有Python基础的CAD使用者来说这类工具确实能开箱即用。但也别对商业API期待过高。首先是自由度有限想调整生成逻辑、约束规则不给你碰。其次是数据敏感度问题图纸是很多公司的核心资产把设计描述丢给第三方API很多企业法务关过不去。最后是成本按次数付费批量生成零件族的时候费用很快会堆起来。我见过一个做非标设备的团队想用API批量生成几百个变体支架算完预算以后果断放弃了。2.2 开源自建用LLM生成CadQuery/OpenSCAD代码如果你有Python基础我更推荐第二条路线自己组装一条LLM → CadQuery/OpenSCAD → CAD内核的开源链路。这条路线的基本架构是先让大语言模型把自然语言需求解析成 CadQuery/OpenSCAD 脚本再在本地执行脚本生成 STEP 或 STL 文件最后把文件导入专业CAD软件做后续修改和出图。CadQuery 是一个基于 Python 的程序化建模库写法接近面向对象建模Workplane(XY).circle(30).extrude(8)就是在XY平面画半径30的圆拉伸8毫米。OpenSCAD 更偏向数学描述用类似 C 的语法组合几何体。两者都能被LLM稳定生成因为它们在开源社区里有大量代码样本模型训练时见过足够多模式。我用一张表总结两条路线的主要差异方便你判断对比项商业API开源自建上手难度低传文本下载文件中高需要Python环境数据安全数据经第三方完全本地可控可定制性低业务规则难嵌入高可自定义提示词和模板批量生成成本按次计费量大偏贵一次搭建后边际成本低维护成本基本零维护需要自己处理环境与报错我的经验是如果只是偶尔玩票商业API很香一旦涉及批量生产或内部工具化开源自建的长期价值明显更高。唯一的门槛是前期搭建那两三个小时。2.3 选型建议你的场景适合哪条路我在实际项目里总结了一个简单判断标准。如果你只是偶尔生成一两个零件用于3D打印预览用商业API最快如果模型将来要进入正式工程流程、需要被同事用中望CAD或 SolidWorks 继续改图建议走开源自建把生成逻辑沉淀成公司内部工具。这里还要提到一个容易被忽略的点商业API生成的模型通常只有结果没有清晰的参数化过程。也就是说你拿到一个STEP文件但打开以后特征树可能非常简单甚至只有一个导入实体。这对于只做加工的人没问题但对于需要继续迭代设计的工程师来说反而是个麻烦。开源自建因为是自己控制代码可以把尺寸定义成变量生成带有完整参数化逻辑的模型后期改一个数就能重算。另外无论选哪条路都不要把 text-to-cad 当成一句话替代设计师。它目前更适合处理参数明确的标准件、规则几何体比如法兰盘、支架、铭牌、钣金展开件像复杂的曲面造型、需要大量工程经验判断的装配结构它还没法替代人的工作。把它当成超级草图工具心态会稳健很多。3. 核心原理拆解为什么生成代码比生成网格更靠谱这一节把技术原理拆开讲。只有理解了为什么是生成代码而不是生成几何用起来才知道边界在哪里遇到问题时也才明白该去修哪里。3.1 CAD模型的本质特征树与B-Rep工程CAD里的三维模型远不是一个形状那么简单。它背后是特征树Feature Tree先有基体拉伸然后是切除、倒角、阵列、螺纹孔每个特征都带着参数后期双击就能改。这个数据结构在CAD内核里对应的是B-Rep边界表示——用面、边、顶点的拓扑关系精确描述一个实体。说个生活化的类比B-Rep 模型就像一份结构化档案里面记录了每一个面的边界是哪条边、每条边连接哪个面而网格模型就像一张马赛克照片离远了看是形状放大全是格子。你要修改马赛克里的一个色块很容易但要把整个鼻子的轮廓改流畅就难了。所以一个真正可用的CAD模型必须同时具备两样东西精确的B-Rep几何毫米级甚至微米级的尺寸误差都不接受完整的特征历史让后人能修改参数、看懂设计意图。网格模型只沾了形状丢掉全部工程语义。这也是我强烈建议做 text-to-cad 时优先选择文本→代码→内核执行而不是文本→神经网络→网格的原因。神经网络直接生成网格短期看很炫但生成物进不了工程体系最后只能沦为展示品。3.2 从文本到代码再到大纲LLM在此扮演的角色把这条链路展开大语言模型读入自然语言后先做意图解析。比如均布6个孔里的关键词是polar array count6 angle360外径60内孔20需要换算成半径30的圆再在一个同心圆上打半径10的通孔。接着LLM把这些意图映射成 CadQuery/OpenSCAD 的API调用序列。最后在本地执行脚本由CAD内核精确计算布尔运算、倒角、阵列结果。这个过程中LLM很像一个翻译程序员的角色它并不直接算几何而是写一份几何构造程序的源代码。真正保证算得准的是内核LLM负责的是翻译得对。这也是为什么 text-to-cad 的可实现性比很多人想象的高——它承接了大模型在代码生成上的成熟能力而不是重新发明一个几何引擎。我在调试时发现大部分生成失败都卡在语义歧义而不是代码语法。比如带六个孔的法兰没说孔是通孔还是盲孔、孔心所在的分布圆直径是多少LLM只能靠猜。写提示词时把这类关键参数交代清楚成功率会成倍上升。3.3 精度与可编辑性两个绕不开的坎即便原理说得通落地时还是有两个坎。第一是精度。LLM生成代码时可能把半径10写成直径10或者把毫米当英寸算一个符号之差模型就报废。这类错误不会少必须配合验证环节。我见过最离谱的一次AI把板厚2mm理解成圆角半径2mm生成结果外形尺寸完全不对但肉眼看缩略图根本看不出来。第二是可编辑性。LLM经常生成一坨代码全部写在一个函数里不给参数分层没有命名约束。这种代码能跑出模型但后期改尺寸等于重写。所以真正工程化使用时得在提示词里强制要求把尺寸定义为变量集中放在文件头部。我自己踩过的办法是在系统提示词里固定模板要求LLM必须遵循参数区建模区导出区三段落结构并且默认单位是毫米。这样生成结果的可用率提升非常明显肉眼可见地从经常要改变成偶尔要改。模板化对LLM非常重要它本质上限制了自由发挥的空间而工程领域恰恰不需要自由发挥。4. 实操演示用文本生成一个可用的零件模型理论讲完直接上实际操作。下面这套流程我跑了小半年从一句话到可加工模型大概三步。先说明一下我用的是开源自建路线因为这样一来每一步都透明可控适合对照学习。4.1 准备环境CadQuery 与文本生成环境上我建议用 CadQuery 而不是 OpenSCAD。原因很简单CadQuery 对 STEP 的导出支持更好生成结果进主流CAD软件基本无痛。安装方式pip install cadqueryCadQuery 启动时会拉取内置的 OpenCASCADE 内核装完可以先跑一段官方示例确认环境正常。这里有个小坑如果你用的是 Windows且Python环境比较旧CadQuery 的依赖安装偶尔会报缺少编译器的错。我的处理办法是先装 Microsoft C Build Tools 再重试或者直接用 Python 3.10 以上版本创建干净虚拟环境。文本生成部分你可以用任何你习惯的大模型API也可以本地部署一个开源模型关键是给它配好一段系统提示词说明你是一名CAD程序生成助手输出CadQuery Python代码单位毫米参数放文件头部不要输出额外解释。这段提示词是你整个工具链里最重要的一块值得反复打磨。4.2 从自然语言需求到CadQuery代码我以一个实际需求为例这是我在测试中反复用的经典场景需求一块120mm x 80mm x 2mm的铝制铭牌四角倒R5圆角四个安装孔直径4mm孔心距边缘10mm表面刻字TEXT-TO-CAD。大模型输出的CadQuery代码如下import cadquery as cq # 参数区 L, W, H 120, 80, 2 R 5 # 倒角半径 D, M 4, 10 # 孔径、孔心距边缘 # 建模区底板 plate cq.Workplane(XY).rect(L, W).extrude(H) # 四个竖边倒圆角 plate plate.edges(|Z).fillet(R) # 四个安装孔构造100x60的构造矩形取四个顶点 plate ( plate.faces(Z).workplane() .rect(L - 2*M, W - 2*M, forConstructionTrue) .vertices() .hole(D) ) # 表面刻字向下切除0.2mm plate ( plate.faces(Z).workplane() .text(TEXT-TO-CAD, 8, -0.2) ) cq.exporters.export(plate, plate.step)这段代码的建模逻辑对应了需求里的每一条板上拉伸、四角倒圆角、构造矩形顶点定孔位、刻字。现实中大模型第一次输出未必一次通过常见错误包括edges(|Z)写错导致倒角倒到顶面、text方法在旧版本CadQuery中不存在等。遇到代码报错直接把报错信息贴回给大模型让它自己修正通常两三轮内能解决。这里分享一个习惯让LLM输出代码时我会要求它在代码尾部加上一个简单的尺寸自检打印语句比如打印模型的外形包围盒。这样每次生成完马上就能在终端里看到关键尺寸不用等导入CAD软件才发现尺寸不对。这个技巧成本极低但能省下大量来回调试时间。4.3 迭代修正与导出STEP/STL导出文件时根据下游用途选格式发去3D打印导出STL发去机加工或进装配体导出STEP。CadQuery支持的导出很简单cq.exporters.export(plate, plate.stl) cq.exporters.export(plate, plate.step)导出的STEP文件可以直接用 FreeCAD、SolidWorks、中望CAD 打开。我的习惯是先在 FreeCAD 里做一次几何快速检查打开后看有没有破面、孔位对不对。LLM生成的模型看起来对不代表几何对这一步不能省。除了看我还会做一步程序化校验写一个读取STEP的小脚本自动检查外形尺寸是否与需求一致。CadQuery本身可以读取STEP文件并访问实体的边界框几行代码就能把宽高比出来。如果你不会写这个脚本也可以在CAD软件里用测量工具手工核对只是效率低一些。批量生成场景下程序化校验几乎是必须的否则你没法保证上百个生成件都没有尺寸漂移。4.4 接回日常CAD工作流模型生成只是第一步。真正的工程交付通常还要出二维图、标注尺寸、转PDF。CadQuery本身不擅长出工程图我的做法是把STEP导入FreeCAD用TechDraw工作台出三视图和标注再导出PDF。如果你所在公司使用中望CAD这类国产软件STEP导入后可以在软件里继续做标注和排版。要特别说一个坑刻字或注释类特征用AI生成时字体是个大问题。CadQuery的text方法依赖本地字体中文环境下经常出现找不到字体文件的情况即使生成成功导出后的文字在国产CAD软件里也可能变成乱码或缺字。这和很多同事日常遇到的shx字体不足导致文字显示不全是同类问题。稳妥做法是模型里不刻字文字留到工程图阶段再添加那里字体管理成熟得多。另外模型交付给人看的时候别只丢STEP文件。我的习惯是 text-to-cad 生成模型后同时导出一份PDF工程图给人看STEP文件给机器用。图纸适合开会评审和归档模型适合后续编辑和制造。人看图纸机看模型两条路都通畅。5. 半年实测总结这些坑我提前替你踩过了最后把这段时间实测的坑和心得一次性交代完。这些经验不写进官方文档但恰恰是能不能用好的关键。如果你准备在自己的工作流里引入 text-to-cad这几点值得先有个预期。5.1 尺寸幻觉与单位混乱LLM有一个非常顽固的毛病尺寸幻觉。你让它做M8螺栓它大概率会生成一个看起来像螺栓但尺寸完全不标准的东西比如把螺纹螺距写成2.5mmM8实际是1.25mm。问题在于LLM是从语料统计中学出的平均印象不是查标准件手册。解决办法只能靠人工审查加标准件库校验。我现在遇到标准件需求会让AI直接引用标准件库数据表而不是凭记忆生成。单位混乱更是重灾区。CAD领域英文社区默认英寸中文环境默认毫米。模型看到厚度2会当成什么完全取决于训练数据分布。我的应对方法是系统提示词里强制声明所有尺寸单位均为毫米并且输出代码的参数区直接带上单位注释。这样即使生成结果错了人工一眼就能发现问题而不必在几段代码里猜数字含义。5.2 几何错误需要自动化校验AI生成代码跑通、能导出STEP并不意味着几何正确。比如孔和边距离太近、壁厚小于工艺要求、布尔运算产生自相交这些错误在图形上可能很不明显但到了加工阶段全部暴露。我现在的做法是在解析完模型后用脚本检查关键尺寸——写一个简单的CadQuery脚本读取生成的STEP程序化核对孔数、孔径、外形尺寸再生成一份校验报告。这个思路和python批量对cad修改的玩法是一脉相承的程序能做校验也能做批量修改。import cadquery as cq part cq.importers.importStep(plate.step) bb part.val().BoundingBox() print(f外形: {bb.xlen:.2f} x {bb.ylen:.2f} x {bb.zlen:.2f}) # 简单的孔数统计逻辑可继续扩展别小看这几行脚本批量生成场景下它就是在给你省时间。有一次我生成50个变体支架就是用这段脚本自动筛出3个外形尺寸异常的瞬间定位问题。如果全靠肉眼在CAD界面里看没有一上午搞不定。5.3 中文环境与国产CAD的互操作在国内工程环境里模型最终往往要进中望CAD、浩辰CAD这类软件。我实测的结论是STEP格式的实体数据互操作基本正常但带注释、带特征名称的模型偶尔会有信息丢失。AI生成模型时通常不会设置材料属性、公差、表面粗糙度这些制造信息所以从AI到可加工之间还必须有人在CAD里补一轮工程属性。另一个小提醒国内很多CAD插件和二次开发脚本对文件路径、中文目录名很敏感。text-to-cad 生成的STEP文件如果放在带中文的路径下有些软件导入时会报异常。习惯把所有生成文件放在纯英文路径下能省掉很多莫名其妙的报错。这听起来像玄学但实际遇到过不止一次。5.4 什么人适合现在就用 text-to-cad这个问题我问过自己很多次。结论是如果你是机械设计老手text-to-cad 目前能帮你消灭大量重复的标准件和规则件建模时间如果你是三维建模初学者它可以当免费老师——让AI生成代码你读代码学习建模思路比单纯看视频教程更有效率。反过来如果你指望输入一句话AI全自动出一套符合国标的完整图纸那目前还不行。从模型到图纸中间还缺大量的工艺判断和经验信息。更现实的做法是把它当成一个超级草图工具快速得到基础几何再由人完成工程设计。对我个人来说用它处理重复性参数件效率提升是实打实的但真正有价值的地方反而是逼着我把设计需求描述得更精确因为提示词写不清楚模型就一定生成不对。这个约束对很多习惯了边画边想的工程师来说其实是一种挺有益的锻炼。