今年在整理AI辅助设计相关工具链的时候我花了不少时间折腾text-to-cad这个方向。它跟常见的文生图、文生3D网格完全是两码事——输入一段自然语言比如一个带四个安装孔的矩形底板厚度5毫米输出的是一个真正能进CAM、能出工程图、能编辑尺寸的CAD实体而不是一张渲染图或者一个水密性都无法保证的Mesh。这个方向的工作流涉及大模型微调、CAD内核重建、参数化特征序列生成链条很长但每一步踩清楚之后确实能做出很实用的东西。这篇文章我不会堆概念只把我实际跑通、实际踩坑、实际拿来和真实设计流程对接过的内容写出来。适合有CAD或三维建模基础、同时想了解AI怎么进入工程设计环节的读者如果你只是玩过AI画图想看看语言直接建模到底靠不靠谱也能从里面搞清楚它的能力和边界在哪。1. text-to-cad的底层逻辑不是生成一个形状而是生成一段设计过程1.1 为什么输出必须是B-rep而不是Mesh很多第一次接触text-to-cad的人会问直接用文生3D模型不是更快吗那些能生成高精度Mesh的扩散模型我也玩过不少生成效果确实惊艳但放到CAD工作流里根本没法用。原因很简单Mesh是一堆三角形面片的集合它描述的是外观不是实体。CAD里真正干活的是B-rep边界表示也就是用拓扑面、边、顶点加上几何定义来精确表达一个实体。一个STEP文件里的圆柱面、平面、圆角特征都是数学上的精确曲面不是近似网格。做布尔运算、倒角、抽壳、生成工程图和CAM刀具路径全部依赖这种精确表示。我试过把高精度Mesh转成STEP文件转出来的结果是几万个碎面在CAD软件里打开卡到几乎无法操作更别说给加工师傅看图纸了。text-to-cad从一开始就是冲着B-rep去的这是它和文生3D最本质的差别。1.2 把设计过程当作token序列既然目标是生成CAD实体那模型到底该输出什么这是整个方向最关键的决策点。目前主流的做法不是让模型直接吐出一个STEP文件而是让它生成一段可执行的CAD建模操作序列。你可以把这个序列想象成一张设计配方先画一条草图线给定长度和角度然后把这根线变成闭合轮廓接着选择拉伸面、指定深度再打一个孔、指定直径最后做倒角。每一步对应CAD内核里的一次API调用。大模型本质上是个翻译器把自然语言翻译成这一串结构化的建模指令。这个思路最大的好处是输出的东西和设计过程一一对应完全可以回溯、修改。模型说画一条长50毫米的线你改写成60毫米再重新执行实体就跟着变了。这不光是生成而是用语言驱动的一次参数化设计。相比之下直接回归一个STEP文件的二进制内容或者体素表示既不可编辑也无法解释工程上没人敢用。1.3 文本描述的分级从专家命令到小白口语实际操作中还有个容易被忽略的问题用户说的话水平差太多了。同一个零件有经验的工程师会直接说宽40深60高30的底板四角M6沉头孔小白可能就是一句一个方板四个角有螺丝孔。如果模型只训练过专业表达遇到口语化描述就会崩。所以现在公开的数据集和模型普遍把文本提示分成了几个层次专家级包含完整尺寸和特征参数、中级部分参数缺失、新手级基本只有形状描述。这其实很聪明既让模型学会了精确到毫米的指令执行也让它学会在信息不足时用合理默认值兜底。我在实际使用时也会刻意先给一个偏口语的prompt再让它输出一段带默认参数的模型比自己动手建模还省事。2. 主流开源方案的实际选型我的对比和取舍2.1 Text2CAD最容易复现的方案很多人听说text-to-cad是从Text2CAD这篇工作开始的。它做了一个自动生成训练数据的管线先用CadQuery一个用Python写参数化CAD模型的库批量生成大量零件再为每个零件自动编写多级难度的自然语言描述。训练语料里既有cmdlineTo, len50这种命令级的表达也有画一个长50毫米的边这种接近人类工程师的说法。模型架构上直接用了Llama和Mistral做微调输入是文本输出是一串token化的CAD命令序列。我的评价是它的技术路径非常清晰开源程度也够适合拿来做起点。不过跑下来的感受是它擅长处理由拉伸和打孔构成的零件对倒角、圆角、扫掠这类偏自由曲面的特征就弱一些。2.2 num2cad聚焦数值可控还有一个值得关注的是num2cad它的卖点是数值精度。Text2CAD这类方案生成的是相对语义比如长边是短边的两倍而不见得能准确给出32.7毫米这种带小数位的尺寸。num2cad专门强化了数字令牌的预测让模型学会输出精确到小数点后一位的尺寸并且和几何约束对齐。我在做标准件库自动生成时倾向于用它因为标准件比如带沉孔的支架、带螺纹孔的连接板要求一字不差的尺寸不是看着差不多。它比Text2CAD更难部署一些环境依赖更复杂但对尺寸敏感的场景值得折腾。2.3 基于大模型Agent的脚本式方案除了端到端的文本到CAD命令序列还有一条路线是Agent方案直接让大模型调用CadQuery、OpenSCAD的参数化脚本API模型不直接输出序列token而是输出一段可执行的Python建模代码由解释器执行产出STEP文件。这类方案上限很高因为模型能用上Python的所有库和逻辑控制但翻车概率同样高——如果生成的代码里有错误怎么Debug是个大问题。2.4 我整理的对比表方案输出形式精度可编辑性部署难度适合场景Text2CADCAD命令序列语义级强序列可改中概念方案、教学演示num2cadCAD命令序列数值强化精确数值强较高带具体尺寸的标准件Agent脚本式Python/CadQuery Code取决于代码极强中复杂逻辑、批量生成商用云端产品通常是参数化模型导入中高中低非专业用户快速出坯模选型时我的建议是如果你主要做早期方案验证就从Text2CAD的checkpoint开始如果你需要生成结果直接进装配体和加工流程那必须选数值强化或Agent方案并且后续强制加一道尺寸审查不能完全信任模型生成的任何数字。3. 实操记录从文本提示到STEP文件我跑通一条最小链路3.1 环境准备和依赖安装先说结论在本地跑通一个最小text-to-caddemo不需要什么夸张的显卡我用的是一张8GB显存的中端卡CPU推理也行就是慢一些。依赖方面最麻烦的是CadQuery和OCCT内核的版本匹配问题。CadQuery基于OpenCascade不同版本的内核在布尔运算、倒角行为上确实有差异别随便升级。以下是我在Ubuntu环境下的操作记录# 创建独立Python环境避免系统Python环境被弄脏 python -m venv .venv-text2cad source .venv-text2cad/bin/activate pip install --upgrade pip pip install cadquery2.4.0 # 版本要特别注意高版本可能不兼容旧数据 pip install torch torchvision --index-url https://download.pytorch.org/whl/cu118 pip install transformers accelerate sentencepiece安装完成后建议先敲一个CadQuery冒烟测试生成一个最简单的立方体导出STEP文件。这一步能隔离环境问题和模型问题import cadquery as cq result cq.Workplane(XY).box(20, 20, 20) cq.exporters.export(result, smoke_test.step)能正常运行再往下走。我最初就是跳过了这步结果排查了很久才发现是CadQuery升级后API签名变了和模型的输出解析代码不兼容。3.2 拉取模型权重和推理数据部分我用的是公开仓库里的预训练权重。拉下来之后运行python scripts/t2c_predict.py \ --model-path ./checkpoints/text2cad_expert \ --prompt a rectangular base plate with four holes \ --out-seq ./output/pred_seq.json模型输出的不是一个STEP文件而是一段JSON格式的命令序列。这一步会让人困惑怎么生成的东西是文字其实这就是这类方案的核心设计——先把命令序列生成出来再由后续脚本调用CAD内核重建实体。命令序列里通常包含类似这样的结构{ operations: [ {type: sketch_line, start: [0, 0], end: [80, 0]}, {type: sketch_line, start: [80, 0], end: [80, 50]}, {type: close_sketch}, {type: extrude, depth: 10}, {type: hole, position: [10, 10], diameter: 6} ] }之所以要这个中间表示是为了可编辑性。你可以在重建前任意修改序列里的参数例如把10毫米的板厚改成12毫米再重新执行重建脚本输出全新的模型。如果直接把模型权重绑死在输出STEP文件上这个灵活性就没了。3.3 拿到序列之后如何重建实体下一步是把命令序列翻译成CadQuery调用。仓库里通常带一个执行器脚本核心逻辑类似import cadquery as cq def reconstruct(seq): workplane cq.Workplane(XY) # 遍历命令序列逐个执行对应的建模操作 for op in seq[operations]: if op[type] sketch_line: workplane workplane.line(op[end][0], op[end][1]) elif op[type] close_sketch: workplane workplane.close() elif op[type] extrude: workplane workplane.extrude(op[depth]) elif op[type] hole: workplane workplane.hole(op[diameter]) return workplane model reconstruct(pred_seq) cq.exporters.export(model, result.step)真实场景里命令类型比这多得多还有圆角、阵列、镜像、旋转拉伸等原理都一样命令序列是设计意图执行器是实现方式两者解耦。提示执行完重建后务必先用查看器打开STEP文件确认形状不要直接拿去做网格渲染或是3D打印切片。模型生成的序列偶尔会出现自相交拉伸这类几何上成立、工程上却非法的操作必须肉眼检查。3.4 验证输出用OCCT检查几何合法性我强烈建议在管线里加入合法性校验。CadQuery自带一些几何检查功能另外可以通过OCCT内核的ShapeFix接口检查from OCC.Core.ShapeFix import ShapeFix_Shape from OCC.Core.TopoDS import TopoDS_Shape from OCC.Core.STEPControl import STEPControl_Reader # 读取STEP文件 reader STEPControl_Reader() reader.ReadFile(result.step) reader.TransferRoots() shape reader.Shape() # 运行ShapeFix修复几何问题 fix ShapeFix_Shape(shape) fix.Perform()如果这一步报了大量的修复记录说明模型生成的几何质量偏低。正常情况下一个合格输出应该几乎不需要修复。我在实际跑批时发现数据分布不同导致的成功率差异很大——处理简单钣金件时修复率很低一旦涉及曲面造型修复量直线上升。4. 实测中反复踩坑的记录CAD精度问题的真实面貌4.1 语言里的大薄差不多没法直接变成毫米边界表示里的尺寸必须是确定数值但自然语言天生是模糊的。模型收到做一个大一点的底板时它怎么决定大是100毫米还是500毫米训练数据里的默认值分布决定了它的选择。我踩过的具体坑是让模型生成一个承受中等载荷的支架它给了一个5毫米的壁厚。这个值对塑料件可能够对钢结构完全不够。问题不在模型而在提示语没有给约束。解决办法是在prompt里强制加入数值语境比如壁厚不低于8毫米或适配M8螺栓。如果模型没能满足这个约束就说明它的数值理解还不到位不应该用于正式交付。4.2 布尔运算失败是家常便饭text-to-cad的序列里常有布尔运算步骤拉伸一个基体再减去一个圆柱作为孔或者并上一个凸台。但在OCCT内核里两个B-rep做布尔运算不是无条件的面与面处于相切、共面、或者非常接近的容差范围时运算会失败或产生退化边。我在复现很多测试用例时至少有15%20%的情况会出现布尔失败。后来总结出一个规律让模型尽量用草图里直接带孔轮廓再拉伸的方式建模而不是拉伸完再用圆柱去减。前者生成的几何在拓扑上更干净后者对内核鲁棒性依赖很高。这个经验其实和人类建模师的操作习惯完全一致——能在一个特征里完成的事不要拆成多次布尔。4.3 倒角、螺纹和制造特征容易被忽略另一个在生成结果中反复出现的问题是模型忘记了制造特征。你明明说所有锐边倒角R2但输出的序列里可能只有一个倒角操作剩下的边全是尖角。定位这类问题没有捷径只能重建之后做几何特征检查遍历所有边检查是否存在非0的圆角半径遍历圆柱面检查是否有螺纹线。用pythonOCC可以写这类巡检脚本。也正因如此我一般不把text-to-cad的结果直接当最终图纸而是当可编辑的初稿。生成后进入传统的CAD环境补特征效率比从零画高很多。4.4 模型幻觉生成了合理形状却完全不是你要的东西最后一种坑最隐蔽输出在几何上完全合法从形状到尺寸都很漂亮但它和你描述的根本不是一回事。让模型生成一个带中心孔的圆形法兰它可能给了一个方形的带孔板原因是训练数据里方形板占比太高模型学了先验分布。解决这个问题只能靠完善的测评指标把把生成的模型和参考模型做特征级别对齐而不仅仅是看渲染图。我在实际流程里会额外把关键特征抽出来做结构化比对——有没有孔、孔的数量对不对、孔是通孔还是盲孔、外轮廓是圆形还是矩形。这些用一套简单的规则脚本就能自动检查比人眼扫模型可靠得多。5. 落地边界哪里能用哪里还在画饼5.1 最合适的场景概念设计、标准件、教学演示折腾了这么长时间我的结论是text-to-cad目前最适合三类场景。第一类是概念设计的快速坯模。比如投标时给客户看结构方案的大致形态不需要精确标注但需要一个能转STEP、能进装配的实体文件这个生成速度就很有价值。第二类是标准件库生成。你手里有一批参数相近的连接板、支架、垫片写一段描述让它批量生成基础几何然后统一挂到参数表里调优节省大量重复劳动。第三类是教学演示。给学生或非专业人士演示一个零件是怎么一步步建出来的命令序列天然就是建模步骤比看建模录屏直观得多。5.2 参数化约束是下一步的关键现在绝大多数text-to-cad模型的输出虽然可编辑但不是真正的参数化模型——没有尺寸约束方程、没有特征之间的父子关系、没有设计意图表达。你改一个孔的直径其他关联孔不会跟着变。这和现代CAD的全参数化理念差距很大。这也是我认为接下来最有价值的方向让模型同时生成特征树和约束关系而不是只生成一维的命令序列。已经有团队在做这方面的探索比如把构建历史保存下来再结合数学约束求解器让输出变成真正活的参数化模型。一年内如果这是能稳定做到text-to-cad的工程价值会上一大个台阶。5.3 人机协作的正确姿势文本草图点选最后分享一个使用上的心得别想着完全靠聊天完成建模。自然语言描述不清的地方结合草图或点选来补。最有效的工作流是用文字描述总体思路和关键特征导入一张手绘草图或一个参考模型在关键位置点选几个用于定位的基准点让模型在这些约束下生成特征序列。我试过在提示词里插入类似以图片中左上角孔为原点的描述再给定坐标系模型输出位置的准确率明显提升。这种做法其实是在降低大模型对空间关系的理解难度人和模型各发挥所长。另一个值得建立的意识是版本心态不要指望一次生成一步到位而是把它当做一个可以无限重新生成初始方案的助手。我通常一口气让它生成20个变体丢到CAD里快速筛选挑出两三个符合直觉的再细化。这个流程很接近创意思考时的头脑风暴只是速度被拉快了一个数量级。实测下来的体验是把text-to-cad定位成设计灵感引擎而非自动出图机它的价值才能发挥出来也不会因为偶尔的生成失败而丧失信心。