最近一个做结构设计的同事问我现在不是有个 text-to-cad 吗能不能把客户表格里的法兰尺寸直接变成三维模型我第一反应是这活儿听起来跟 AI 画图差不多但真正上手试了以后才发现它跟文生图完全不是一回事。text-to-cad 要做的是把自然语言的需求描述翻译成一套精确到毫米、可以编辑、可以导出到任何主流 CAD 软件的几何模型而且这套模型带着完整的特征树和参数不是一张渲染图片。这件事听着很酷但落地过程中坑很多尺寸单位会被猜错直径半径会被搞混特征顺序一乱整个布尔运算就报废。所以我写这篇东西就是为了把原理、能用的工作流、以及我实测踩出来的坑一次性说清楚给想试 text-to-cad 的伙伴们一份能直接抄作业的参考。1. text-to-cad 的本质认知从“画图”到“表达意图”的范式切换1.1 一句话理解给 CAD 配了个“需求翻译官”如果有朋友问我 text-to-cad 到底是个什么我通常用一个比喻它像是给三维 CAD 软件配了一个需求翻译官。原来的工作流是你脑子里有零件的形状然后打开软件画草图、加约束、做拉伸、打孔、倒角一步一步把想法“翻译”成软件能理解的建模动作现在这个翻译环节被模型承担了一大部分你直接说“我要一个外径 120、内径 60、厚度 15、六个直径 12 的孔均匀分布在直径 90 的圆周上的法兰盘”它就替你写出一段程序化建模脚本把特征按顺序生成好。对你来说剩下的工作是检查结果、微调参数、导入装配体里试装。需要特别强调的是这个“翻译”不是简单的关键词匹配它要理解工程语义。比如“外径 120”里的“外径”是一个物体的整体外围尺寸“均布”意味着圆周上的角度均匀分布“贯通”意味着孔要穿透整个厚度。这些词在工程里含义非常明确模型需要把它们转换成几何操作而不是笼统地画一个圆柱再随便挖几个洞。1.2 它到底解决了哪些真问题说句实话我从很早开始就关注这个方向最初也以为又是一阵炒作。但当我真的把 text-to-cad 用进工作流发现它解决的是几个非常具体的痛点。第一个痛点是建模软件的高门槛。很多做产品、做结构的同事脑子里想法很清楚但一打开 CAD 界面就抓瞎图层、约束、草绘平面、特征树任何一个环节不熟都会卡住。text-to-cad 的价值不在于让你从此不用学三维建模而在于把“从想法到初步模型”这段路缩短让不具备专业建模技能的人也能先产出可用的雏形。第二个痛点是文档与模型之间的翻译成本太高。实际项目里需求经常是写在技术协议、Excel 明细表或者会议纪要里的多字段的零件参数需要人工逐项填进建模软件。人工翻译就容易出错——单位看错、公差漏掉、孔数不对都是最常见的低级错误。把需求描述直接喂给 text-to-cad等于把参数到模型这一步自动化了至少能减少因为手抖造成的低级失误。第三个痛点是批量变体的成本。比如管路项目里有十几种规格的法兰如果每个都从零建模工作量很大。但用 text-to-cad 的思路先得到一个参数化脚本再在脚本里循环改尺寸一份脚本就能批量生成所有规格这种复利效应是传统手工建模很难比的。1.3 和文生图、文生3D模型有什么不一样很多人把 text-to-cad 和文生图、文生 3D 混为一谈实际差别非常大。文生图比如生成一张“未来感的水杯效果图”的输出是像素好看就行不需要保证“杯子的直径是 80mm”。文生 3D比如生成一个可旋转的杯子网格模型输出的是表面网格适合游戏素材或数字化展示但网格通常是非流形的、精度未知没法直接用于工程加工。text-to-cad 要的是能进入 CAD 环境的实体模型它必须满足封闭曲面、精确尺寸、可编辑特征、可导出 STEP/IGES 等工程格式。我自己整理过一个非常直观的对比能力维度文生图文生 3D 网格text-to-cad输出本质二维像素三角网格面片参数化实体模型是否精确不需要精确视觉近似毫米级精确能否编辑不可编辑很难编辑特征树可改参数工程语义无无有孔、倒角、阵列等典型场景效果图游戏/动画机械设计/制造看见没有text-to-cad 和另外两者起点相似都是自然语言输入但验收标准完全不同。它追求的不是“看起来像”而是“加工得出来”。这也是为什么这个领域早年尝试过直接让扩散模型生成三维体积数据后来纷纷转向程序化建模路线——因为只有参数化模型才真正具备工程可用性。2. 技术原理拆解自然语言如何变成可编辑的几何体2.1 第一层语言理解与意图抽取所有 text-to-cad 系统的最底层都是一个大语言模型第一步要做的是把一句话拆解成有工程意义的特征列表。我给模型发“外径 120、内径 60、厚度 15 的法兰盘”它内部其实在做三件事。第一件事是实体识别。它要从自然语言里找到“外径 120”是一个参数对象“内径 60”是另一个“厚度 15”是第三个。第二件事是关系判断。它需要知道这些参数之间是什么关系外径和内径都是针对一个旋转体而言的厚度是这个旋转体沿轴向的长度三者共同构成一个中空圆柱体。第三件事是默认知识补全。模型需要知道法兰盘一般会有螺栓孔但这些孔到底几个、多粗、分布在哪个圆上需要从上下文或行业常识推断如果拿不准就会在回复里问或采用最常见的默认配置。这一步直接决定后面代码能不能对。如果模型把“外径 120”理解为半径后面生成的圆柱就会大一倍整个设计全错。所以操作上我基本都会在提示词里做“防呆”明确告诉模型所有尺寸的默认语义并要求它在生成代码前先复述一次自己的理解。这个“复述确认”机制看着笨却能筛掉大量歧义。2.2 第二层从意图到程序化建模代码第二步是整个链路的核心把特征列表转化成一段可执行的程序化建模脚本。目前在工程圈里比较主流的落地形式是把语言模型当成一个“代码生成器”让它生成 CadQuery、OpenSCAD 这类工具的脚本。CadQuery 是 Python 库背后基于 OpenCascade 几何内核支持拉伸、旋转、布尔、倒角、阵列等参数化特征OpenSCAD 则是用类似编程语言的语法描述几何体。两者生成的模型都保留完整的特征信息可以二次编辑。为什么这个环节选择了代码生成而非直接生成 B-rep 模型因为对语言模型来说生成代码是它的强项而直接输出精确几何体则难得多。一个工程上可用的 B-rep 模型需要完美的拓扑结构差一点就是无效曲面扩散模型在生成体素或网格时很难保证上千个网格面拼起来仍然是一个封闭、无自交、可加工的整体。相比之下用代码描述“拉伸一个圆减去一个同心小圆再打六个孔”每一步都是确定性的几何运算只要语法正确几何内核就会算出合法实体。所以与其说 text-to-cad 在“生成模型”不如说它在“自动写建模脚本”——大家常调侃这是“代码生成套上了一件 CAD 外套”其实这话挺准确的。2.3 第三层几何内核的实体化与验证模型生成代码后脚本会被交给几何内核执行。CadQuery 调用的 OpenCascade 会负责拉伸、布尔减、倒角这些底层运算最终生成一个实体对象。这一步其实最见真章如果代码是错的比如在打孔之前忘记先建模主体内核就会报错如果特征顺序不对比如先打孔再拉伸主体孔就会被后续的实体“填掉”生成一个完好无损的圆柱。这些错误编译器不会完全帮你拦住最终要靠眼见为实的验证以及检查体积、面数、边界框等量化指标。这里还涉及一个重要机制可校验性。做文生图的时候图好不好看是主观的你没法自动判定但做 text-to-cad一个模型是否满足“外径 120、内径 60、厚度 15”可以通过读取实体的 BoundingBox、截面尺寸、体积来客观判断。我自己在自动化工序里会专门写一段校验脚本用几何内核自带的方法量取结果的尺寸如果误差超过 0.01 毫米就打回重来。这个闭环是 text-to-cad 区别于 AI 绘画的最大优势也是它能被工程化使用的前提。3. 从零跑通一个 text-to-cad 工作流环境、提示词与完整案例3.1 环境与工具选型先说环境。我用的方案是“大语言模型 API CadQuery Jupyter”以 Python 为主体。基础环境是这个组合Python 3.10 / 3.11建议用 conda 单独建一个虚拟环境避免依赖冲突安装 CadQuerypip install cadquery它自带 OpenCascade 内核安装 Jupyterpip install jupyter我用 Notebook 来交互调试因为可以快速看渲染结果一个能正常使用的大模型 API按你有权限访问的模型服务来配置即可如果你更偏好“所见即所得”的验证另外推荐 OpenSCAD 作为备份方案语法更简单模型生成速度快而且自带在线查看器。但 OpenSCAD 在复杂装配、特征树管理上不如 CadQuery 灵活所以我的主路径始终是 CadQuery。安装完成之后跑一个最小验证创建 Workplane 并拉伸。如果这一步能正常出结果说明环境已经打通。很多人卡在 CadQuery 的导入问题上一般是 conda 环境里 Python 版本过高或 OpenCascade 动态库没有正常加载建议直接用 CadQuery 官方推荐的虚拟环境解决别硬怼系统 Python。3.2 提示词设计的五个关键点实测下来text-to-cad 的结果质量七成取决于提示词三成取决于模型能力。我总结了一套自己的提示词模板核心是五个关键点。第一指定建模工具和语言。开头直接写“请用 CadQueryPython 实现一个零件”避免模型自由发挥生成 OpenSCAD 或者其他奇怪的库。第二显式声明单位。写“所有尺寸单位均为毫米不要进行任何缩放”防止它拿英制单位或者做比例换算。第三规定特征顺序。“先构建主体再切除内孔最后添加倒角/圆角”这一条特别重要因为顺序错了布尔运算结果完全不同。第四补充工程语义。比如“螺栓孔均布共 6 个中心圆直径 90”而不是笼统说“六孔”。第五要求只输出代码。加上“只输出可运行的 Python/CadQuery 代码不做解释”能省去后续解析的一堆麻烦。我还习惯在提示词末尾加一句“请在代码中直接使用上面给出的尺寸不要自行修改或估算”。实测下来加入了这句话之后模型“好心帮你调整尺寸”的概率会下降不少。另外如果模型经常把单位搞混我会在提示词里直接给一个换算示例“半径 直径 / 2”大多数模型看到公式就不会再犯半径直径的错。3.3 完整案例生成一个带孔法兰盘下面放一个我自己反复测试过的例子。目标零件一个圆形法兰盘外径 120 毫米内径 60 毫米厚度 15 毫米在外径和内径之间均布 6 个直径为 12 毫米的螺栓孔螺栓孔中心圆直径 90 毫米外圆边缘做 1 毫米倒角。标准提示词如下“请使用 CadQueryPython 生成一个法兰盘模型。单位统一为毫米。特征要求主体为圆柱体外径 120 毫米内径为 60 毫米的贯通中心孔厚度 15 毫米6 个直径为 12 毫米的螺栓孔沿中心圆均布该中心圆直径为 90 毫米外圆两端边缘做 1 毫米倒角。建模顺序先拉伸主体圆柱再切中心孔最后打 6 个螺栓孔并倒角。只输出可直接运行的 Python 代码不做解释。”我实测生成的一份可运行代码长这样import cadquery as cq # 主体外径120mm 半径60mm part cq.Workplane(XY).circle(60).extrude(15) # 中心孔直径60mm贯通 part part.faces(Z).workplane().hole(60) # 螺栓孔6个直径12mm均布在直径90mm的圆上半径45mm part ( part.faces(Z) .workplane() .polarArray(45, 0, 360, 6) .hole(12) ) # 外圆边缘倒角选择半径大于50的圆形边做1mm倒角 part part.edges(%CIRCLE, lambda e: e.radius() 50).chamfer(1) # 导出STEP格式 cq.exporters.export(part, flange.step)注意我针对 AI 输出做了两点调整一是把可能的“直径/半径混淆”显式化用注释标注了为什么是 60、为什么是 45二是用polarArray替代了模型有时会生成的circle(forConstructionTrue).vertices()方式因为后者在环形布孔时很容易跑出错误结果。这两类坑基本是 text-to-cad 最常见的“模型以为对了但其实错了”的场景。3.4 生成结果的三重校验代码跑通不等于结果正确。我的习惯是至少做三层校验。第一层是看渲染图在 Notebook 里把 part 显示出来确认形体大致符合预期。第二层是量化检查用part.val().BoundingBox()量总尺寸用part.volume()和part.area()确认没有多一块少一块必要时用截面运算精确测量内径。第三层是把导出的 STEP 文件拖进自己熟悉的 CAD 软件做一次正式的尺寸标注和干涉检查确认它是可以被装配环境正常识别的几何体。这三层校验听起来繁琐但能挡住绝大多数问题。特别是第三层我见过太多 AI 生成模型在 CadQuery 里渲染没问题一进主流 CAD 软件却发现曲面方向反了或者精度标记异常。STEP 格式虽然兼容性不错但导出时的精度设置、实体单位都需要确认一遍。如果只做外观预览STL 导出也可以但要做加工、装配、继续编辑一定走 STEP。4. 能用在哪儿不能用在哪儿边界与场景4.1 真正落地的几个场景以我目前的实践看text-to-cad 最适合的领域是“从需求描述到初步方案”的加速尤其在机械非标设计、结构件快速选型、教学演示这三类场景最有价值。第一个场景是非标机械里的标准件批量生成。法兰、垫片、轴承座盖、防护罩这类零件结构规律但规格繁多。让 text-to-cad 先生成一个参数化脚本再通过脚本批量生成不同尺寸的型号效率提升非常明显。我最近的一个项目里就靠这个路子把几十种规格的垫片从模型库里自动生成了 STEP 文件导入到总装里做干涉检查省了至少两个工作日。这个用法本质上是把 AI 当成“参数化脚本的起点”而不是直接依赖它每次输出新零件。第二个场景是产品概念阶段的快速验证。设计师还在头脑风暴时可以先让模型生成几个粗略的形体配合手头的尺寸约束做筛选比每换一个方案都重新画一遍草图要高效得多。第三个场景是高校和职业培训里的教学演示。学生用自然语言描述一个小零件再对照模型看特征树对理解建模顺序、特征语义都很有帮助。我自己带新人的时候也会让他在 text-to-cad 的基础上改参数比从空白草图开始练要容易建立整体感。4.2 现阶段明显的短板但是我也要把丑话说在前面。text-to-cad 目前不是万能的有三类任务我坚决不让它碰。第一类是复杂曲面造型。像水瓶曲面、汽车外观、有机形态的壳体这些需要 NURBS 曲面和精细光顺控制的场景语言模型很难用几条语句描述清楚生成的代码往往只能给出一个非常“方正”的近似达不到曲面设计要求。第二类是强工程约束场景。比如注塑件的拔模角度、公差配合、材料收缩率、应力圆角等工艺性约束模型可能完全不理解这些参数之间的物理关系生成了“形状对但工艺完全不能落地”的模型。第三类是复杂装配体。text-to-cad 目前基本还是单零件思维涉及多零件、相互约束、传动关系时它生成的装配结构往往逻辑混乱还是要人工搭建装配树。所以我的判断很明确现阶段把它当“参数化模型的自动生成器”最合适把它当“全自动工程师”则一定会失望。任何生成结果进入正式流程前都应该有工程师做一次审核这东西省的是重复劳动不是专业判断。5. 踩坑记录与常见问题速查5.1 踩过的典型坑我在这条路上踩坑真不少挑三个最典型的分享。第一个是直径半径的“坑中坑”这是加密版。早期我让它生成“外径 120”的法兰盘它居然写了一个半径 120 的圆整个模型大了一倍。我当时一度以为生成环境出了问题后来反复测试发现只要提示词里不强调“直径”和“半径”的区别模型就会随机猜。现在我的提示词里都有“圆半径等于直径除以二”这样的显式说明出错率大幅下降。第二个是特征顺序的坑。有一次它先生成了中心孔再拉伸主体结果是孔被实体填没了导出来的模型是一个实心圆柱。这类“布尔运算被特征顺序反转”的问题最难排查因为它不会报错渲染看起来还很正常只有量尺寸时才发现中心孔不见了。现在我会在提示词里写清楚特征顺序并且坚持用校验脚本检查内径。第三个是单位混乱的坑。模型有时会生成 25.4 倍或 0.03937 倍的模型明显是它把毫米和英寸的换算逻辑搞混了。这类错误非常隐蔽只看形体会觉得“还挺像”一量尺寸就发现全盘皆错。所以我每次生成后都强制做量化校验而不是只看比例。5.2 常见问题速查表我整理了一张速查表按“现象—可能原因—处理方式”三列排平时排查直接对照着来现象可能原因处理方式外径比要求大了一倍模型把直径当成半径提示词显式声明“半径 直径 / 2”生成的模型没有孔特征顺序颠倒孔被后续拉伸填充规定“先主体、后切除、再倒角”的特征顺序尺寸整体偏大或偏小固定倍数毫米与英寸换算错误显式声明单位毫米并做量化校验倒角或圆角位置与意图不符模型对“外圆边缘”理解偏差用更精确的方位词如“两端轴向边缘”导出的 STEP 在 CAD 里报错单位设置不一致或几何有退化在 CadQuery 里先检查 BoundingBox 与 volume螺栓孔数量或分布错误构造线方法选错改用polarArray并复核数量5.3 几句大实话用 text-to-cad 已经小半年了我的个人体会是这个工具真正改变的不是“建模”这个动作而是“把需求转成模型”这条路径的起点。以前我们面对一页技术参数表看到的是密密麻麻的二维数字现在可以直接把这些数字组织成一段结构化的描述让模型替我们完成从描述到特征树再到实体模型的翻译。但它毕竟不是万能的很多行业经验、制造约束、装配逻辑还是得靠人来把关。我自己最稳妥的用法是生成模型 → 量化校验 → 导出 STEP → 在主流 CAD 环境里做复核和修正把它当一个“特别会写参数化脚本的前同事”而不是“全自动设计师”。最后再分享一个压箱底的小技巧当你准备用 text-to-cad 生成某个标准零件时别急着写一句话让模型自由发挥先搜一下这个零件在行业里的常用参数表比如法兰的密封面厚度、螺栓孔数量标准然后把关键参数直接写进提示词。这样生成的结果往往一次就能满足工程需求比你反复调提示词修改要省事得多。这条经验是我自己用多轮试错换来的真心希望能帮你少走几步弯路。