大概从去年开始我陆续在几个内部项目里认真测过 text-to-cad 这个方向。最早是帮客户评估“让车间工人直接报需求、自动出三维模型”的可行性后来又试过把它接到标准件库的自动建模流程里。跑完一轮下来我的结论是它确实不是噱头但也不该被理解成“用嘴画图”的魔法。它真正的价值是把过去需要人手动操作CAD、反复调整草图约束的那部分工作变成了一段可验证、可修改、可追溯的生成逻辑。这篇文章只聊一件事如何把一句自然语言描述稳妥地变成一个能进加工流程的CAD模型。我会把技术路线选择、Prompt拆解思路、具体落地的工程链路还有我在实测中踩过的问题按实操顺序完整写一遍。如果你是做机械设计、工艺自动化或者想给团队内部工具加一个“说话出图”的入口这篇应该能帮你少走很多弯路。1. 为什么我会认真对待text-to-cad这个方向先说一个容易被忽略的事实在制造业里真正值钱的不是“画出一个形状”而是“画出一个能改、能加工、能出工程图的形状”。所以我评估text-to-cad的第一标准从来不是它生成的模型有多炫而是它能不能把设计意图稳定转换成可编辑的参数化特征。1.1 它真正解决的不是建模炫技而是工程历史包袱如果只是想让AI生成一个好看的STL网格模型那今天的工具已经很多了。但网格模型进不了数控加工也进不了装配体配合更没法在工程图里标注公差。工业场景要的是STEP或原生零件格式是带特征树的、有参数约束的实体模型。这意味着text-to-cad真正要解决的核心问题其实是“把非结构化的语言意图转成结构化且可编辑的建模历史”。我在实际接触客户需求时发现使用者往往不是专业建模人员而是工艺、采购、现场工程师。他们脑海里有非常具体的零件形态但不熟悉CAD的草图约束和特征操作逻辑。过去这个需求只能转述给专职建模员一个简单支架往往要等半天。text-to-cad切入的正是这个“需求表达”和“建模执行”之间的断层把历史设计经验变成可复用的模板逻辑而不是每次从零拉草图。还有一个容易被忽略的场景是系列化改型。同一类零件只是长度、孔径、安装间距不同过去需要人工逐个改参数。如果text-to-cad的生成逻辑足够稳定就能用自然语言直接触发参数变更并自动重建整个模型。这种价值比“生成一个全新奇异造型”实在得多。1.2 三条技术路线我为什么最终走代码生成这条路目前市面上实现text-to-cad的路线大致分三类我先做一个对比再讲我的选择。技术路线核心思路优点典型问题端到端生成几何大模型直接输出点云、SDF或网格再转换为实体视觉效果好适合概念设计几何精度差、模型不可编辑、难以满足工程公差程序化CAD脚本生成大模型输出CadQuery/OpenSCAD等参数化脚本再自动建模结果可编辑、参数可控、可追溯依赖代码生成的正确性需约束管理基于规则模板LLM填参用预置的参数化模板大模型只负责识别意图并填充参数最稳定、最快落地灵活性受限适合有明确产品族的企业我最终把主要精力放在第二条也就是程序化CAD脚本生成。核心原因有两个。一是输出是源码任何生成结果都可审计、可手工修正这对工程交付非常重要。二是参数化脚本天然支持改型同一个Prompt跑出来用户说“厚度改为8毫米”我只需要在后端改一个参数而不是重新生成一遍整个模型。当然这条路对大模型的代码生成能力要求很高也要求CAD库本身具备强大的布尔运算和倒角处理能力。后面我会详细讲如何用CadQuery来完成这部分。2. 把自然语言翻译成CAD特征Prompt与语义拆解的关键细节很多人以为text-to-cad的难点在“生成”其实我实测下来最难的反而在“解析”。一句“做一个带四个安装孔的法兰盘”人类建模员会自己脑补出一堆信息法兰外径多少孔是通孔还是螺纹孔四个孔是均布还是按矩形排列中心要不要留轴孔这些信息用户没说但模型必须给出合理默认值。2.1 用户说“一个底座”时地图里缺了哪些信息把自然语言转成CAD本质上是一个从稀疏信息到完备参数空间的映射过程。用户说“底座”时我心里会立刻产生一组待定参数长、宽、高、壁厚、圆角半径、安装孔直径、孔距、沉头深度、底面是否开减重槽。这些参数有些可以通过规则猜测有些必须靠Prompt引导用户补全更多则应该从产品族的默认模板里继承。我在设计Prompt模板时会把信息分成三层第一层是物体类别与基本形态第二层是尺寸与位置关系第三层是工程细节公差、表面处理、螺纹规格。模型的职责是逐层解析而不是一次到位。比如用户说“带四个安装孔”模型至少要区分“圆形分布”和“矩形分布”两种可能并给出默认选择否则生成的孔位完全随机根本无法使用。这里有一个关键心得不要期望大模型真的“理解”机械设计而是要把Prompt设计成约束求解器。你要给模型提供足够多的背景规则比如“未指明分布方式时四个孔默认按矩形均匀分布在四角”。规则越明确输出越稳定。2.2 几何约束和拓扑关系的表达技巧在CAD建模里单纯“画一个圆”和“画一个与长方形边相切的圆”是完全不同的两件事。模型需要理解拓扑关系比如“孔穿过两个板”、“圆角施加在顶面周边”、“凸台底面与底板顶面贴合”。这些关系用文字描述非常含混但用CadQuery脚本表达却很清晰因为每个特征都有明确的定位基准和依赖关系。我的做法是在Prompt中引导用户和模型使用“基于某面”、“与某边对齐”、“相对某点偏移”这样的锚定式表达而不是笼统的“放在上面”“在旁边”。锚定式表达可以显著减少模型在坐标计算上的幻觉。实测下来当Prompt结构从“自由描述”改成“按基准、方向、尺寸、特征顺序描述”之后生成成功率提升了将近三成。同时我强烈建议在Prompt里加入检查逻辑生成完成后让模型自己复核一遍条件允许的话对生成的脚本做一次图形布尔校验确认孔确实在实体内部而不是悬空或完全落在实体外面。2.3 单位、基准与命名规则三个最容易被忽略的隐性因素这类问题在几次跨团队协作中反复碰到。自然语言描述里用户说“8个厚的板”有可能是8毫米也有可能是8英寸下的某个分数而不同CAD软件默认单位也可能不同。所以我的Prompt模板里有一项强制规则所有尺寸必须显式声明单位默认全部使用毫米。模型在输出脚本时也会显式写入毫米单位声明避免后续导入CAM软件时整体缩放。第二是基准问题。不指明原点的话模型很可能把原点放在自己觉得方便的位置结果装配时所有零件全错位。我的做法是强制指定主视图方向、底面基准面和原点位置并在Prompt里写入“模型底部对齐到XY平面中心位于原点”的默认规则。第三是特征命名规范。生成的CadQuery脚本如果不给每个关键step设置workplane和标记名称后期要修改某个孔位就会非常痛苦。我要求生成脚本时对每个特征的关键面都以语义化名称命名比如mount_face、hole_pattern这样即使后续人工编辑也能迅速定位。3. 从文本到可编辑STEP模型的完整落地流程前面讲了思路现在说怎么搭一套能用的系统。我以CadQuery作为核心建模引擎配合大模型完成代码生成、还是配合一个本地脚本规范层完成校验整体链路是类似的Prompt解析、结构化中间表示、代码生成、建模执行、几何校验、导出STEP。3.1 整体架构与关键组件选型先说选型。建模引擎我推荐CadQuery因为它的API设计贴近工程师思维使用Workplane、Box、Cylinder、Hole这类直观概念适合让大模型学习生成。相比之下OpenSCAD虽然简单但它是CSG拼合逻辑对复杂装配和倒角不如CadQuery方便。另一个选择是Build123d它更新但生态和案例还少我暂时没有在生成链路里使用。大模型方面我做过对比通用大模型的代码生成能力在没有约束时容易写错坐标但如果把CadQuery代码片段和规则写进Prompt稳定性会大幅提升。更好的做法是先跑一个“解析模型”让它输出JSON格式的中间表示再由一个固定的代码生成器把JSON转成CadQuery脚本。这样把“理解语言”和“生成代码”两个步骤解耦便于分别调优。整个流程我用一张简明清单来拆自然语言输入附带单位、基准等全局配置。大模型已进行语义解析输出结构化JSON包含物体类型、尺寸、特征列表。Schema校验确保所有数值合法。代码生成器根据JSON生成CadQuery脚本。执行建模得到临时STEP文件。用VTK或trimesh读取几何执行自动校验。校验通过后导出STEP并附上生成日志。3.2 阶段一需求解析与结构化中间表示这个阶段的产物不是CAD文件而是一个JSON。一个好的中间表示应该包含这些字段对象名、长宽高或直径高度、位置基准、特征列表。每个特征要区分是“切割”还是“附加”并写明关键参数。举个例子用户说“200毫米长、100毫米宽、10毫米厚的铝底板四角各有一个6毫米通孔孔心距边缘10毫米”。中间表示大致是这样的{ object_type: plate, material: aluminum, base: { length: 200, width: 100, thickness: 10 }, features: [ { type: hole, diameter: 6, hole_type: through, pattern_type: rectangular, count: 4, offset_from_edge: 10 } ], datum: { origin: center_on_xy, bottom_aligned: true } }把中间表示这一步做好后面模型生成的成功率会大幅提高。因为大模型不再需要一边理解语义一边编代码它可以专注于“翻译”这件相对容易的事。同时JSON校验也避免了模型直接生成代码时常见的语法错误。我在实操中会用Pydantic做schema校验确保数值必须为正数、直径必须小于等于板宽、孔数量必须是正整数。这些约束虽然生硬但能提前拦截掉大约四成无效输出。3.3 阶段二代码生成与CadQuery脚本生成从JSON到CadQuery脚本我建议不要用大模型直接自由发挥而是维护一份“半成品代码模板”。代码模板里已经写好了基座的生成逻辑、坐标系定义、特征预设大模型只需要把JSON里的数值填入相应位置并处理特征组合顺序。这么做的好处是稳定同一个工程团队可以迭代模板而不是每次依赖模型临时发挥。下面是一个简化的CadQuery脚本示例对应上面那个底板例子import cadquery as cq # 全局单位毫米 result cq.Workplane(XY).box(200, 100, 10) result result.faces(Z).workplane().rect(200, 100).vertices().hole(6)这个脚本用了CadQuery的vertices()方法会在当前矩形草图的四个角点打孔正好对应“四角各有一个6毫米通孔”。但要实现“孔心距边缘10毫米”脚本需要更精确地指定孔位坐标。更稳妥的写法是显式定位孔的位置import cadquery as cq plate cq.Workplane(XY).box(200, 100, 10) # 四个角孔位置从边缘偏移10mm hole_positions [ (-90, -40), (90, -40), (90, 40), (-90, 40) ] plate plate.faces(Z).workplane() for x, y in hole_positions: plate plate.pushPoints([(x, y)]).hole(6)看代码很容易发现这里的坐标为什么是90和40因为板长200、宽100中心在原点四角位置是(-100, -50)、(100, -50)等向内部偏移10毫米后就是(-90, -40)这样。这一步计算容易出错而我正是希望把这类固定的坐标计算逻辑放在代码模板里只需根据JSON中的offset参数动态计算即可避免大模型自行心算。3.4 阶段三渲染、校验与导出脚本生成之后建模引擎会立刻执行并产出模型。但我们不能直接把这个模型交给下游必须先完成校验。我会做四项检查体积是否大于零、特征数量是否符合JSON描述、模型边界尺寸与预期尺寸的偏差值、是否有开口面或不封闭实体。import cadquery as cq # 生成实体 result plate # 检查体积 solid result.val() print(Volume:, solid.Volume()) assert solid.Volume() 0 # 检查边界框尺寸 bbox solid.BoundingBox() print(Length:, bbox.xlen, Width:, bbox.ylen, Thickness:, bbox.zlen)校验完成后导出STEP。CadQuery使用OCCT内核导出STEP非常标准cq.exporters.export(result, output_step/mounting_plate.step)导出后我还会用它打开STEP文件再做一次视觉确认因为偶尔会有STEP文件有效、但显示面朝向反了的情况。3.5 一个完整可参考的小案例我用一个真实测试过的简单案例收束这一节用户输入“一个直径80毫米、高度50毫米的圆柱体顶部有一个直径12毫米、深20毫米的盲孔外壁倒角1毫米”。中间表示{ object_type: cylinder, diameter: 80, height: 50, features: [ { type: blind_hole, diameter: 12, depth: 20, position: top_center }, { type: chamfer, size: 1, position: outer_top_edge } ] }CadQuery核心脚本import cadquery as cq # 圆柱主体 part cq.Workplane(XY).cylinder(50, 40) # 高度50半径40 # 顶部盲孔 part part.faces(Z).workplane().hole(12, depth20) # 外壁倒角 part part.faces(Z).edges().chamfer(1)实测下来这类简单回转体零件生成成功率比较高因为CadQuery的hole和chamfer都自带正确处理逻辑不太依赖复杂布尔运算。如果换成带加强筋、异形凸台的零件难度就会直线上升需要在提示词模板和代码模板里加入更多规则。4. 实测里最常翻车的6个问题及排查思路再稳定的框架也会遇到麻烦。下面是我在不同项目里实际遇到过的几类高发问题每条都是真实调试记录不是从文档里抄来的。多数问题排查到最后其实都回归到一个事信息在语义到参数之间的映射断了。4.1 尺寸“跑飞”模型生成成功但比例不对最气人的问题不是模型失败而是它成功生成了一个“尺寸完全错误”的模型。比如用户要求长200毫米结果生成出来的实体长度是2米。排查后发现模型在JSON里写的是200但代码生成阶段把单位当成了厘米于是CAD内部数值仍为200但语义上运行过程翻了十倍。我后来在系统里强加了三条防线JSON解析后立刻检查数值量级是否在合理范围CadQuery脚本模板里的每一条尺寸参数都统一乘以1.0mm执行结束后用边界框对比原设计值偏差超过5%直接拒绝输出。这三条下来尺寸跑飞基本绝迹。4.2 特征丢失孔、圆角无故消失另一种常见情况是用户要求了六个孔脚本也生成了六个孔但导出STEP后只看到三个。原因通常是孔之间的布尔运算出了问题或者两次孔特征作用在同一workplane上后一次把前一次的结果覆盖了尤其在CadQuery里连续使用hole()而没有pushPoints时容易发生。解决办法是每个孔位都显式通过pushPoints生成再逐个执行hole()。另外圆角丢失往往是因为施加圆角的边在上一步布尔运算后已经不连续需要先合并实体或改为在最终体上重新识别边。4.3 单位制混用导致加工尺寸整体偏大25.4倍这个坑我掉过一次印象极深。某次测试用模型生成一块“1英寸厚”的板生成脚本里写的是25.4毫米但导出STEP时被软件默认识别为英寸单位结果到了CAM软件里被当成25.4英寸整体尺寸扩大了25.4倍。后来我在所有CadQuery导出步骤前强制声明cq.exporters.export(..., exportTypeSTEP)并在模型内部元数据中标注单位。更重要的是凡是涉及英制单位的输入一律先换算成毫米再进建模引擎绝不把“英寸”字符串传给下游。4.4 对称与装配约束失效text-to-cad生成的单个零件通常没问题但一旦涉及左右对称件、配合件就非常容易出错。因为自然语言里说“对称件”大模型不一定理解这意味着要把某个方向上的尺寸乘-1并保持其余特征映射关系不变。我的处理方式是在中间表示中引入“对称轴”字段代码模板里对X/Y/Z轴的镜像由固定函数处理确保特征位置、孔位、倒角方向全部同步镜像。不再依赖大模型理解“对称”而是交由确定性的几何变换完成。4.5 模型面数过多、STEP文件巨大有一段时间生成结果在视觉上非常完美曲面流畅但STEP文件竟然有几十兆。后来发现是脚本中用了细分的样条曲面重建外轮廓而不是用原生基元。CAD领域里这种“表面光洁”其实很致命会导致CAM加工路径计算缓慢甚至无法生成刀路。我的代码模板里严格规定平面用box和polygon圆柱用原生cylinder禁止为了外观把规则基元转成网格再重建。这个调整之后STEP文件体积通常能减少90%以上加工软件加载也流畅很多。4.6 幻觉参数与版本兼容大模型在输出JSON时很可能为了“补齐”语义而编造不存在的参数比如给一个没有螺纹孔的实体附加“M8螺纹深度”。我的校验Schema会给所有非必要字段设默认值并且拒绝任何超出设计范围的字段。此外CadQuery不同版本之间API有细微差异chamfer和fillet的参数顺序也可能变化所以代码模板要锁定Python包版本避免“昨天能跑今天报错”的版本漂移。pip install cadquery2.4.0版本锁定虽然简单但能省掉大量无意义的排查时间。5. 一点实测心得与后续扩展想法如果让我总结这段折腾text-to-cad经验里最值得分享的一点那就是永远不要把大模型当作“会建模的人”而要把它当作一个“能听懂工程术语的翻译官”。真正干活的是模板、约束和几何内核大模型负责把模糊需求变成结构化参数。这个认知一旦建立后续的所有设计都会顺畅起来。我自己在几次项目里按照这个思路把生成成功率从最初不到五成提到八五成以上而且每次生成的模型都可以正常编辑、装配和加工。这个方向后续还能做的扩展不少我目前比较感兴趣的包括一是把历史设计数据里的典型零件逆向成参数化模板然后让text-to-cad直接调用这些模板生成变体这对标准件企业价值巨大二是把装配体级生成纳入流程不只是单零件而是通过一条描述“生成带4个M6沉孔的法兰座配合一个直径30毫米的轴套”自动生成两件套的配合模型三是与公差分析工具对接生成模型后直接进入尺寸链校验这可能会成为text-to-cad在制造业里真正不可替代的节点。眼下这套落地链路算不上完美但它已经足够让“说话出图”从一个演示概念变成一个能进车间系统的工程能力。