从自然语言直接生成CAD模型这几年一直是CAD/AI交叉领域里最让人兴奋的方向之一。一提“text-to-cad”很多人第一反应是“这不就是文生图换个赛道吗”但真正动手试过就会发现它和图像生成完全不是一回事。CAD模型要的不是一张“看起来像”的渲染图而是带尺寸、带特征树、能进CAM、能上车床铣床的实体模型。这个门槛决定了text-to-cad的技术路线和实现难度。这篇文章我会从项目思路、核心模块、实操流程、常见坑点几个层面拆解一遍把我自己在搭建文本到CAD管线时踩过的坑、验证过的方案、以及我认为值得投入的方向都整理出来。适合正在做AI辅助设计、想把自己的建模流程自动化或者对生成式CAD感兴趣的工程师和设计师阅读。1. 项目概述text-to-cad到底在解决什么1.1 为什么“文本生成CAD”比“文本生成图片”难得多先说一个容易忽略的事实文本生成图片模型输出的是像素矩阵哪怕某个细节画错了整体观感仍然成立人眼会自己补全。但文本生成CAD模型输出的必须是一个严格封闭、满足尺寸约束、能进行布尔运算的实体模型。差一个毫米零件装不进去少一条约束草图就无法拉伸特征树里多一步打孔下游制造路径可能全乱。这就是text-to-cad最核心的难点语义不确定性 vs 几何精确性之间的矛盾。一句话里的“差不多”“略大”“合适的位置”这类模糊表达在自然语言里完全没问题但CAD系统不接受模糊所有几何都必须落成确定的数值、确定的特征操作和确定的空间关系。所以text-to-cad本质上不是在“生成图片”而是在做一件更接近“程序合成”的事情——把自然语言描述翻译成一段严格的建模脚本、一组特征操作序列或是一棵CSG构造实体几何树。这也是当前所有可行的技术路线的共同基础。1.2 项目定位与目标输出形态在项目设计初期必须先把“我们要生成什么样的CAD模型”定义清楚。这一步决定后面所有的数据处理、模型选型和评估方案。目前常见的输出形态有三类网格模型Mesh比如OBJ/STL格式。生成难度最低但无法编辑、无法直接进入参数化工作流只能当展示或3D打印粗模用。很多以扩散模型为基础的文生3D方案都停在这一层严格来说它们不算CAD。BREP实体边界表示比如STEP格式。能表达精确的曲面与实体边界制造可行性高但它丢失了建模过程下游想改动某个圆角半径或某个孔的深度会很痛苦。特征历史Feature History / Construction History这是最理想的输出形态模型本身“记住”了自己是怎么一步步被建模出来的。用户拿到模型后可以像打开一个原生CAD文件一样双击某个拉伸特征修改参数、拖动特征顺序。要做到这一步本质上是让模型学会生成“建模操作序列”。我在项目里最终确定的形态正是第三种——让模型输出一个操作历史脚本。原因很简单只有特征历史才能真正嵌入现有设计流程。如果你生成的东西没法被设计师二次修改那它在工程场景里几乎不会被使用。2. 核心技术拆解管线设计与方案选型2.1 整体管线架构整个text-to-cad系统可以从功能上拆成两层第一层是语义理解层。输入一句自然语言描述经过模型解析输出结构化的中间表达。这个中间表达可以是JSON格式的约束图、带槽位的程序调用也可以是CSG生成树的内部表示。这一层的核心任务是把“语言中的模糊意图”转化为“明确的几何指令”。第二层是几何构建层。拿到上述指令后由参数化几何内核完成具体的草绘、拉伸、打孔、倒角等操作最终构建出实体模型。这一层不负责理解语义只负责精确执行。我比较推荐的分析视角是把整个管线看成一个“超级编译器”。自然语言是高级语言CSG树是中间表示最终的BREP实体是目标机器码。语义理解层负责前端编译几何构建层负责后端执行与优化。一个常见的框架是用代码生成模型输出针对某个参数化内核的脚本经由内核求解器完成实体构建。这种拆分的优势很直接语义层和几何层可以独立优化。你可以在不改变几何内核的前提下单独升级语言模型的指令遵循能力也可以在语言模型不够强的时候用规则引擎预先处理一部分结构化命令。对早期项目来说这种灵活性等于保命。2.2 命令序列生成把建模当成程序合成当前效果比较稳定、也容易工程化的一个路径是把建模过程建模成“API调用序列的生成问题”。随便打开一个参数化CAD软件你做的每一个操作从本质上看都是一个函数调用。画一条直线是create_line(start_point, end_point)拉伸出实体是extrude(profile, depth, direction)打一个孔是create_hole(face, center, diameter, depth)。整份设计图本质就是这些调用的有序集合。如果能生成正确顺序的调用序列CAD内核执行完这些调用后自然就得到了符合预期的实体模型。因此text-to-cad可以转换成一个结构化的代码生成任务。模型输入自然语言描述输出一段调用内核API的程序脚本。这种路线有几个明显的优点可解释性强每个生成的步骤都能回溯与验证方便定位错误发生在哪一步。天然支持参数化脚本里保留的是带变量的特征参数而不是烧成死的几何坐标。数据可利用性好CAD软件的历史记录、宏文件、API脚本都可以作为宝贵的监督数据。训练端常用Transformer架构的Decoder模型输出按建模语义排序的token序列。在推理时配合约束求解器做后期校验保证最终生成的是一个工程上可用的实体。我当时在做技术验证的时候完全没有能力去从头训练一个几十亿参数的专用模型。最务实的方式是直接基于已有的代码能力模型做微调或者在其输出后进行格式约束配合一个参数化内核执行脚本并检查报错。事实证明这种结合方案达到的效果远超预期也让项目早期就能做出可演示的原型。2.3 数据、标注与合成策略text-to-cad在数据层面的难度不亚于模型本身训练公开的“文本-CAD模型”配对数据极为稀缺。一个核心原因是设计师在各平台分享图纸时很少会附带自然语言的设计意图描述就算有描述也千奇百怪。数据获取有几个可落地的来源程序化与参数化合成定义一个基础模型模板例如“带通孔的板子”“带倒角的轴类零件”然后随机生成参数组合再自动渲染出对应的几何体和参考CAD脚本。这种方式能在短时间内生产大量配对数据是训练集的主要来源。CAD脚本库清洗挖掘一些开源社区的模型库如某些用代码建模的项目天然就有脚本和结果文件。可以编写自动提取脚本建立配对关系但需要做大量清洗工作因为其中相当一部分脚本和注释并不对应文本意图。人工标注少量招募熟悉CAD软件的标注人员按产品化标准撰写高质量的自然语言描述。这类数据很贵但适合作为测试集和微调集。因为人工标注的描述往往比较接近真实文本的复杂句式包含专业术语、序号引用、工艺注释这在提升模型泛化能力上作用明显。在数据合成方面重点提醒一下合成数据虽然便宜但也容易造成“同质化偏置”。如果你的合成模板永远只有“矩形板、腰型孔、四角倒角”模型对旋钮、壳体、法兰之类变化就毫无能力。要在合成阶段刻意加入变化的语法结构、局部细节的复杂度甚至用随机流程生成更丰富的空间拓扑关系才能让模型不再“背模板”。3. 实操过程与关键环节实现3.1 第一步最小可行系统的搭建不需要一上来就训练模型。我强烈建议先用现有的代码生成模型加一个几何内核挤出几天时间搭一个最小可行的端到端demo验证“自然语言—建模脚本—CAD实体”的路径是否跑得通。具体的工程选择方面我把设计说明放在这里几何内核选择一个可脚本化、提供API接口的参数化建模环境例如以脚本方式定义实体。模型语言选用一个对代码生成较擅长、支持指令跟随的预训练模型优先考虑能处理较长文本和复杂调用的版本。中间格式让模型直接输出目标内核所支持的脚本语言而不是自创一种中间格式减少一次转换损耗。一个关键实操细节不要拒绝为模型提供“API文档片段”。很多时候通用模型对特定内核的API函数名称和参数顺序并不熟悉我们只需要在System Prompt里注入一份精简版的API手册效果通常立刻会有显著提升。这与给模型更多参考上下文是同一个道理成本几乎为零。3.2 一个具体示例从文本到脚本的转化为了更直观地说明模型在做什么我举个例子。假设输入文本是“创建一个50毫米×30毫米的矩形板厚度5毫米在四个角各打一个直径6毫米的贯穿孔孔中心距边10毫米。”这条指令在我们的系统里会被处理为类似下面的脚本我简化了内核函数名来演示思路# 初始化零件 begin_part(Plate) # 进入草图环境选择XY平面 set_sketch_plane(XY) # 创建矩形轮廓左下角在原点宽50、高30 create_rectangle(0, 0, 50, 30) # 退出草图 finish_sketch() # 拉伸实体深度为5毫米 extrude(5, directionZ) # 在顶面创建孔特征 begin_holes() create_hole(center(10, 10), diameter6, depth5, throughTrue) create_hole(center(10, 20), diameter6, depth5, throughTrue) create_hole(center(40, 10), diameter6, depth5, throughTrue) create_hole(center(40, 20), diameter6, depth5, throughTrue) finish_holes() # 保存模型 save_part(plate_with_holes.step)执行完这段脚本内核就会生成一个正确的实体模型并保留完整的特征历史。之后设计师也可以直接在建模环境里打开这个文件修改孔的位置和大小随时重新生成。我在项目里曾专门设计过一个错误触发用例来检验系统可靠性当文本描述中只给出“四角各打一个孔”但没有写孔径时模型如何推断合理的默认值在提示词里显式加入“默认孔径按板厚的30估算并给出用户可调整的可配置参数”之后模型生成的脚本不仅带默认值还在参数顶部自动以类似参数表的形式作了标注。这种设计方案会让最终的生成结果远优于单纯死板的模板匹配。3.3 参数选择与推理调优模型推理阶段有几个参数值得格外在意特别是当你用的解码参数不可调时温度TemperatureCAD脚本生成不能有太多的随机性。推荐把温度设置得偏低如0.2以下必要时关闭采样开启贪心解码。因为CAD脚本是一种语法严格的语言哪怕多一个空格、少一个标点内核都可能直接拒绝执行。最大生成长度脚本通常会比较长尤其是复杂的零件可能有上百行调用。需要给模型充足的输出空间否则容易被截断在半句话里导致语法不完整。Top-P 与重复惩罚适度调低Top-P如0.8左右可以有效过滤低概率的语法错误分支。但重复惩罚不要开太高否则模型可能会为了回避重复而选择不常见但不合理的API调用。我自己的经验是先跑通最小用例记录生成脚本的成功率基线再逐步放开参数寻找上限。千万不要上来就追求“模型想象力”在代码生成场景里稳定性和可预测性才是第一位的。3.4 部署与内核执行环节模型只是无数环节里的一环。在工程化部署方面最初踩过不少坑主要集中在请求超时、资源占用和任务调度上。模型服务与内核分离模型推理和几何内核执行是两种截然不同的资源需求。模型需要GPU内核计算主要是CPU密集任务。把它们混在一台机器上遇到复杂零件时往往会互相拖垮性能。尽量拆成两个独立的微服务各自弹性伸缩。异步执行与超时控制生成一个复杂零件脚本可能不快执行脚本更可能因为约束求解失败而长时间卡死。需要有超时控制机制例如超过15秒就终止并返回重试避免某个坏请求占住整个进程。格式转换层下游使用场景五花八门。做结构分析可能要STEP做3D打印可能要STL做平面下料可能要DXF。建议在系统内部统一输出带特征历史的原生格式再在各个出口挂自动转换器而不是针对不同的下游需求生成不同的模型变体。部署时还要注意文件存储的版本管理。每次生成脚本、执行结果、用户反馈形成一条完整的数据链路最好能完整记录下来。这些数据后续会成为模型微调和评估的重要资源比事后再去翻日志要可靠得多。4. 常见问题与排查技巧实录4.1 模型理解正确但脚本执行报错最常遇到的错误类型如下API名称和参数序列输出错误相当多的错误源于模型对API函数具体签名不够熟悉。解决方法是在提示词中加入当前支持的函数清单及其使用示例并明确约定“只能调用清单内的API”。这本质上相当于给模型布置约束能显著压低幻觉概率。浮点精度与坐标极小偏差例如本应在同一平面上的两个点因为浮点精度误差产生了一个微小的缝隙导致最终实体无法闭合。解决办法是在生成脚本中加入坐标“取整到指定精度”的后处理规则或在内核执行时进行容差合并预处理。草图轮廓未闭合或自相交当模型生成的轮廓有多条曲线时容易出现线段超差或互相交叉。代码质检模块需要专门对草图进行扫描发现不闭合就自动截断报错重试。排查这些问题的通用办法其实也很简单让模型看到报错信息并自我修正。执行内核报错后把错误日志附带回给模型让它根据日志修正脚本再跑一次。这个“执行—报错—修正”循环往往成功率高得惊人算是系统里的“外挂兜底”。4.2 文本与几何不匹配模型“听不见数字”语言模型对数字和空间关系词的处理能力和图像模型一样并不完全可靠。“四个孔”被生成成“三个”、“直径6毫米”变成“直径60毫米”这类问题我在实测里遇过不止一次。低温和结构化约束能缓解但单靠提高模型能力手段是有限的。一个有效对策是引入结构化字段校验器。不用等模型生成完整的自由文本脚本而是先让模型按照JSON Schema填槽把关键参数数量、直径、位置、拉伸深度分别提取出来经过校验模确认完全符合用户指令后再交给脚本构造器。这相当于在语义层和几何层之间加了一层强制检测把偏差消灭在早期。实现上并不复杂就是多一次模型调用让它输出一个固定结构的JSON对象随后写一个几行代码的校验器检查数值范围、枚举合法性、数量约束。这些逻辑加起来不超过一百行Python带来的稳定性提升几乎立竿见影。4.3 生成的模型可编辑性差如果不专门约束模型倾向于生成“一次性实体”把各种特征操作直接合并成最终的几何结果。这样的好处是简单坏处是让用户没法修改直径、倒角等参数。解决这个问题需要从数据层面改变监督习惯在训练数据中标注强制保留的特征参数比如孔径、板厚、拉伸深度。在评估指标中引入“特征可编辑率”把生成的模型交给设计师修改一个尺寸看是否能成功、修改过程耗时多久作为核心指标之一。输出层面限制”合并布尔运算“类操作强制保留特征树的原始结构。如果模型基于通用代码模型不方便调整输出模式还有一个变通方案在脚本生成后跑一遍规则化的“特征树重排程序”把最后几步布尔合并操作切分成保留参数的可编辑特征节点。这虽然不能完全替代端到端学习但对大部分制造场景已经足够。4.4 常见问题速查表问题现象可能原因排查方向脚本能执行但生成实体为空白拉伸方向或参考面选择错误检查坐标朝向、草图平面法向量正负孔的位置偏离描述坐标基准理解错乱原点、边参考等在Schema中强制指定坐标基准方式生成结果每次都不一样解码温度过高或未固定随机种子将温度降至0.2以下并固定seed复杂零件生成时间过长特征数量过多或内核求解器较慢增加超时控制与异步执行精简无用的特征重算用户修改参数后模型变形严重特征依赖关系断裂或参考面缩水限制特征引用数量使用全局坐标定位中文描述与零件标注术语对不上预训练模型术语覆盖不足在提示词中补充术语对照说明或领域词典5. 从项目到产品一些可复盘的思路与插件化落地5.1 实操中的几个关键体会走过一轮完整开发我最大的体会是管线成熟度远比模型单点能力重要。一次成功的生成往往是模型能力、结构约束、报错修正、数据校验各个环节共同作用的结果。把精力全都押在提高模型参数量上而忽视周围闭环建设项目看起来很“潮”但走到交付环节会处处受阻。第二点体会是数据合成阶段的“多样性”措辞需要认真研究。简单地生成几千个“矩形板孔”的样本模型几乎只会一种拓扑模式但如果在合成时变换零件类型、孔位分布方式、加入不同的参考基准和工艺注释哪怕数据总量没有变化模型泛化能力的提升也会非常明显。所以我觉得在项目初期就应该把数据生成器做成一个独立的可扩展组件而不是草草地拼凑几个模板就完事。第三点别神话文本本身。在很多真实使用场景里用户对“文本描述”需求的实际表达往往非常简略只有诸如“做个定位块”“能装M6螺钉”这类短语。要对这类口语化、模糊化的描述做有效兜底光靠模型还不够要补充可维护的“常见需求库”把高频使用场景的意图模板做结构化处理。这也让我意识到text-to-cad并非只靠生成模型单独工作优秀的产品体验更多来自意图理解、参数默认值策略以及合理的收敛规则。5.2 当前值得投入的拓展方向装配体生成现在做单零件生成的比较多而实际产品设计多数是装配体。让模型理解“零件A插进零件B的孔内并保留配合关系”涉及的约束逻辑比单零件复杂很多但商业价值也大得多。从文本到仿真分析的联动既然已经生成这里的参数化模型可以直接接到有限元分析或者运动仿真环境。整套“自然语言描述—CAD几何—仿真条件—分析结果”的自动化链路一旦跑通对设计早期方案验证的增量会很显著。设计意图的逆向解析很多企业有大量存量三维模型但是文档缺失、特征树被压平。如果把“模型理解”反过来做训练一个模型读取STEP文件中的特征操作并恢复出设计历程或者配合文本描述做增量修改也是很有价值的方向。参数化草图与自由形态互补以二维草图和参数化特征为主的常规机械零件是有明确规则的但消费电子产品常见的自由曲面造型规则就少得多。在做完规则模型之后主动补上自由曲面混合建模能力覆盖范围会更广。最后再分享一个小技巧系统上线后一定要保留一个“使用日志-人工修正-定期回流”的通道。也就是把用户修改失败案例、用户对生成结果的调整操作拍成离线的矫正数据集定期回灌到微调更新流程里。text-to-cad这种偏专业垂直的领域通用公开数据是有限的但你在真实使用中积累的用户行为数据几乎是不可替代的稀缺资源。养成每天分析几十条生成失败样本的习惯胜过盲目追求更大规模的通用训练集。我在项目实践里反复验证过一句话自然语言加参数化建模始终要解决的问题是“怎样把人类模糊的意图锁定成机器可执行的精确描述”。这条路没有捷径但每打通一个环节后面的所有环节都会跟着顺畅起来。如果你正在或者打算进入这个方向的探索希望这篇分享里的管线拆解和避坑经验能给你一张值得参考的施工图。