从“把文字变成图”到“把文字变成能加工的真零件”这两件事听起来只差一步实际差了整整一个时代。前段时间我花了不少时间在“text-to-cad”这条线上折腾也就是让大语言模型根据一段自然语言描述直接生成可用于工程制造的三维CAD模型。今天这篇就把我踩过的坑、拆过的原理、试出来的可行路径按一个能落地的顺序整理给你。先说清楚它解决什么问题CAD建模是个熟练工种资深工程师用主流建模软件从零拉一个中等复杂度的零件草图、拉伸、打孔、倒角一路做下来半小时到一小时很正常。如果需求方给的描述还含糊改两轮模型就半天没了。text-to-cad 想干的事是把“输入自然语言描述”到“输出参数化CAD模型”之间的路尽量自动化让设计早期阶段的方案探索、非工程人员的概念表达、标准件库的批量生成都能从“人肉操作”变成“半自动生成”。这件事现在处于什么阶段呢非常早期但已经有看得见的眉目。当前主流的方案不是让模型直接输出一个网格文件或者体素块而是让模型输出一套“建模操作序列”让CAD内核按这个序列一步步把模型重建出来。换句话说它生成的不是一张“看起来像零件的图”而是一段“能重新长出这个零件的DNA”。这听起来很绕但恰恰是它区别于文生图、文生视频的关键。下文我按思路拆解、核心细节、实操流程、踩坑实录和落地场景五个部分展开尽量让它在你的知识体系里从“一个热闹概念”变成“一套可拆解的技术方案”。1. text-to-cad 的本质思路从“画图”到“写建模脚本”1.1 为什么不能直接输出网格文件大多数人第一次听到 text-to-cad第一反应是“这不就是3D版的文生图嘛”。这个类比大方向不错但工程制造领域对“模型”的要求和图像完全是两码事。文生图模型输出的是一张像素矩阵图“像不像”取决于视觉观感哪怕像素边缘糊一点、局部结构错乱一点人眼也能自动脑补修正。但工程零件不是给人“看”的是要拿去装配、仿真、加工的。一个靠视觉像模像样的网格模型拿进CAD软件里根本没法编辑你不能选中它的某个面改厚度不能让它的某个孔从直径4改成直径6更别说生成工程图或者走CAM编程。网格文件比如STL由一堆三角面片拼成只有几何外壳没有拓扑关系、没有特征树、没有参数约束本质上是一块“数字黏土”。所以在 text-to-cad 这条线上早期尝试直接生成体素或点云的工作很快就被边缘化了。大家很快达成了一个共识真正有用的输出格式要么是参数化的特征建模历史要么是B-rep边界表达模型——只有这样生成的模型才可能被现有CAD生态直接消费。1.2 把建模过程当成“程序生成”来做现在主流的技术思路是用“next-token prediction”的方式让语言模型学会了“怎么写建模指令”。你打开一款主流的参数化CAD软件从零建一个简单的法兰盘操作序列大概是这样的新建草图、选择绘图平面、画出几个同心圆、标注半径尺寸、退出草图、选择拉伸命令、输入深度、做倒角……整个操作历史Ansys/某主流CAD内核会把它记录成一个个带有参数的特征节点。如果把这个过程抽象成一个“由特征词、几何参数、顺序标记组成的序列”你会发现——这不就是一种结构化的“程序语言”吗大语言模型最擅长的恰恰是处理这类结构化的符号序列。于是思路就清晰了与其让模型直接算几何坐标不如让模型生成一段“建模脚本”脚本里的每一行对应CAD软件里的一个具体操作。模型只需要学会“这个零件的语义对应哪些特征、这些特征以什么顺序组合、各个参数大致是多少”剩下的精确几何计算交给CAD内核去做。这就是 text-to-cad 与文生图最本质的差别——模型不是在“画模型”而是在“写建模程序”。程序写对了CAD内核执行一遍自然就能得出一个真正可编辑、带参数、符合工程语义的实体模型。1.3 这条思路解决的核心痛点站在一个实际从业者的角度看这个方向真正解决的不是“建模速度快不快”的问题而是“建模的门槛”和“设计的表达成本”问题。传统CAD有个尴尬的地方它是面向“过程”的软件你得一步步告诉它怎么建模型不能直接告诉它“我要什么”。比如你跟工程师说“我需要一个能装在80x80铝型材上的电机支架电机法兰面距离型材面35毫米”工程师脑子里想的是这个零件长什么样但手在软件里干的是另一件事——选平面、画轮廓、约束、拉伸、阵列。文本到模型的转化发生在工程师脑子里软件只是忠实的执行工具。text-to-cad 把目标定为跳过“人脑做几何拆解”这一步让模型从需求描述直接生成对应的建模过程。这个能力一旦足够可靠受益最大的不是熟练工程师他们本身建模效率就高而是两类人一类是懂产品但不会CAD的机械设计师、采购、销售他们能描述需求但画不出零件另一类是需要做大量方案比对的工程师生成几个候选外形花不了多少时间可以快速排除明显不合适的方案再精雕细琢。2. 技术细节拆解一个 text-to-cad 系统由哪些部分组成2.1 文本编码与设计意图理解整个系统的第一环是如何把自然语言描述变成机器能用的语义向量。市面上主流的做法是直接用一个预训练的语言模型做编码器把“一个L型支架底板上有四个直径6的安装孔竖板顶端有一个朝前的凸台”这样的句子编码成一个语义向量序列。这一环的难点不在“理解人话”上——大模型的语义理解能力已经足够强了真正的难点在于语义对齐。同一个零件不同人描述方式差很远工程师会说“Q235钢板折弯L型两侧各两个沉头孔表面发黑”而一个外行可能只会说“一个金属拐角上面有几个洞”。“金属拐角”在大模型看来和“L型折弯板”是同一个东西但和具体建模特征钣金折弯特征、沉头孔特征之间的映射关系是需要专门学过的。所以这个环节在实操中要做的工作往往不是调语言模型而是准备高质量的指令-建模指令对让模型见过足够多“人话”和“特征操作序列”之间的对应样例。2.2 几何表示与序列生成当模型理解了意图之后接下来是生成环节的核心问题用什么样的表示方式来描述几何。目前能跑通的方案主要有两种我在实践里都试过。一种是基于CSG构造实体几何把模型描述为一系列布尔运算的组合——“一个长方体加一个圆柱减去一个小圆柱”。这种表示的优点是简单、稳定、生成出来的结果几乎不会出现扭曲的曲面缺点是无法表达复杂轮廓稍微带点自由曲面的零件就抓瞎了。另一种是基于特征序列的方式这也是我目前认为更接近实战的方向。特征序列里的每个token对应CAD软件中的一个特征操作比如“草绘”“拉伸”“切除”“倒角”。这种方法生成的模型天然带特征树导进CAD软件里可以直接点选每个特征去修改非常符合工程师的使用习惯。难点也随之而来特征序列的语法比CSG复杂得多模型要学的东西也更多训练难度和推理复杂度都上一个台阶。我个人的倾向是如果你只是做个Demo验证想法CSG能省不少事如果你真想做能落地的原型就必须上特征序列。2.3 约束与尺寸最容易被忽视也最要命的环节做 text-to-cad 的路上有太多看起来“微不足道”但实际决定生死的细节尺寸约束绝对是排第一位的。一个工程零件光“形状对”是没用的。M6螺丝孔径你生成成8毫米装配图上就过不了干涉检查轴承安装孔的直径差了0.1毫米公差配合就完全不对。但尺寸信息恰恰是语言模型最不擅长处理的东西——语言模型天生擅长处理离散的符号而尺寸是连续的数值生成连续数值恰恰是LLM最弱的一环。你让模型输出“直径4毫米”它大概率能输出4但让它输出“直径4.90毫米”它可能给你来一个4.88然后一本正经地认为自己没错。实操中解决尺寸问题的思路有几条我逐一试过第一在指令描述里把尺寸写得非常精确让模型尽量走“检索”而不是“推理”的路子第二后处理校验——生成完之后用几何内核去测量关键特征的尺寸与语言描述里的参数做比对偏差超过阈值就重新生成或者强制修正第三也是最值得投入的把尺寸参数外置。生成模型只管结构和形状类型具体数值通过规则从文本里抽出来直接注入到建模脚本里不经过生成模型。这一步能极大提高尺寸准确率代价是要写不少解析逻辑。2.4 从“理论上对”到“实际能加工”验证与后处理管线就算模型生成的脚本语法完全正确、特征顺序合理、尺寸也都对也不代表这件它就真的能用了。工程软件里还有一堆“文科生不会想到”的问题在等你。第一个坑是特征间的依赖冲突。模型可能会生成一个“先倒角再切除”的顺序但在这个具体几何上切除操作会把倒角面整个切掉导致倒角特征失效。这种问题模型的训练数据里如果没覆盖到它自己是意识不到的必须用CAD内核实际执行一遍检查特征树上有没有报错的特征。第二个坑是几何退化。拉伸特征的草图闭合了但内部有自相交环或者两个特征形成零厚度的薄片这些在网格层面看不出来但在实体造型里就是核心里解算不过去的错误。做后处理的时候需要用几何内核的布尔运算和拓扑检查工具过一遍出问题就标记为失败案例。所以我一直建议每一个做 text-to-cad 的朋友不要只停留在“生成一个STL文件看一眼”的阶段一定要有一个基于几何内核的验证环节。那个你用来执行建模脚本的引擎本身就是一个绝佳的裁判。3. 实操复现从头搭一个最小可用的 text-to-cad 流程3.1 确定方案边界与工具选型下面这部分是我建议每一个想上手试的人先照做的流程。目标不是一步到位做出生产级系统而是用最低的成本跑通一个“文字输入→参数化模型输出→CAD软件可编辑”的完整闭环。方案选型上我给一个不会出错的组合用某个开源的代码生成模型作为基座把建模脚本的语法定义为结构化的函数调用序列用CAD内核作为执行引擎。具体来说建模脚本用类似“调用函数、传入参数”的形式组织一层层描述每个特征执行环境用支持脚本化建模的CAD内核最终导出为标准交换格式。这套组合的优势在于每个环节都是成熟工具你不用从零训练一个模型也不用自己写几何内核所有精力可以集中在“数据准备”和“指令调优”这两个真正决定成败的地方。3.2 数据准备从CAD模型库反推训练样本text-to-cad 和很多AI方向一样最大的瓶颈不在模型结构而在数据。训练一个“文本到建模脚本”的模型需要海量的“零件描述→建模脚本”配对。现成的数据不会凭空掉下来但有一个绕不开的笨办法找一套CAD模型库用内核把每个模型重放一遍把建模历史导出成脚本化表示再搭配一个自动化的标注过程生成描述文本。实际操作时这个过程可以拆成三步。第一步从模型库中筛出特征树结构合理、参数化程度较高、特征数量适中的零件过滤掉那些由导入网格转成的“哑实体”。第二步对每个模型导出其特征序列并从中抽取关键参数——长度、直径、孔数、倒角半径等等。第三步写一个模板化的描述生成器把抽取出来的参数组织成自然语言描述。这种生成出来的文本难免会比较“机械”比如“一个长100宽50高20的矩形底座四角有四个直径6的通孔”。但它作为冷启动的训练数据完全够用之后想提升语言的多样性再用大模型做改写扩充也不迟。3.3 模型微调与推理指令跟随是核心数据准备好之后下一步就是对基座模型做指令微调。我的建议是不要从一个随机的语言模型开始训练而是直接用某个开源的代码模型作为底座——它已经具备良好的序列生成能力和结构化输出能力你要做的只是让它学会“建模脚本的方言”。微调阶段有几个加速收敛的细节值得注意。一是要把所有建模脚本的token统一缩放到一个合理的词汇表内特征名、参数名尽量固定化减少模型的记忆负担。二是要对脚本做语法校验把大量“语法错误”的样本直接从训练集里剔除避免模型学会生成垃圾序列。三是在损失函数上对数值token稍微加权这能缓解一部分前面提到的“尺寸不可靠”问题虽然不是根治但确实会有改善。推理阶段我习惯用较低的采样温度和较高的重复惩罚。建模脚本和自然语言不一样它不允许“换个花样再说一遍”这种事。同一个特征重复写两遍在文本里可能只是个语气问题在建模脚本里就会导致重叠实体的布尔运算报错。3.4 执行与导出让模型输出真正“落地”推理完成之后模型手里拿着的是一份“建模脚本草稿”。接下来要做的不是拿它当结果而是把它喂给CAD内核去执行。我自己的流程是这样先做一层脚本级校验——检查括号配平、函数调用是否匹配、参数数量和类型是否正确通过之后交给内核执行执行过程中捕获异常如果某个特征失败就把整个生成案例标记为“失败”退回重采样执行成功之后再做一轮几何检查——用内核自带的工具确认模型是实体而非曲面片、体积为正、没有自由边。全部通过之后再导出为标准的STEP格式然后拿到CAD软件里打开。这一步是最有成就感的时刻你能在特征树里看到“拉伸1”“切除2”“倒角3”这些熟悉的名字能双击尺寸去修改整个模型和手建的没有任何区别。到这一步才算真正打通了从文字到可编辑CAD模型的闭环。4. 踩过的坑与排查实录4.1 生成结果“坍缩”所有输出都长得一样我遇到的第一个大坑是模型的输出多样性几乎为零。无论输入怎么变生成出来的零件都是“一个方块上面打个孔”要不就是“一个方块下面挖个槽”。检查下来问题出在训练数据分布上。我最初准备的数据里简单零件占了绝大多数模型很快就学会了一个“最保险”的输出模式因为这种输出在训练集里对应的概率权重最高。语言模型在建模脚本这种低容错场景下会表现出极强的“保守主义”。解决方法是重新平衡数据集把简单零件控制在40%以内增加中等复杂度和带较多特征交互的样本比例。同时在推理阶段增大采样温度范围让模型有机会跳出概率最高的那个“安全区”。4.2 尺寸信息抖动这个问题前面提到过这里说一个具体的排查经历。某个模型输入描述里明确写了“孔径6.2毫米”模型生成的脚本里这个参数写成了6.02。这类错误特别阴险因为肉眼根本看不出来要实际进装配环境里和标准件配合才会暴露。我后来在排查中发现尺寸错误的分布也不是均匀的——出现在“描述文本后部”的尺寸参数错误率明显更高模型的上下文注意力在长文本末尾会衰减。应对措施从三方面下手一是在训练数据里做尺寸数值的多样性增强同一个零件在描述里用多种写法表达同一个尺寸比如“6.2毫米”“直径六点二”“约6.2”让模型学会对具体数值更敏感二是后处理时对数值型参数做模式校验和范围检查超出合理工程区间的直接拦截三是把关键尺寸改为从文本中显式抽取绕过生成模型。第三点效果立竿见影强烈推荐做。4.3 拓扑错误实体变成了“一堆面”有一阵子我拿到的生成结果是“看起来正常但无法导出的模型”。外壳完整体积为正但就是导不出STEP——内核报错说存在非流形边。排查后发现典型成因是模型生成了两个尺寸完全相同但位置略微重叠的特征。视觉上你根本看不到任何问题因为重叠区域完全被外壳包住了但在实体建模的拓扑逻辑里这个模型内部产生了自交面属于非流形实体。解决思路是建立一条“重叠特征检测”的规则序列执行过程中如果某个新特征与已有实体的包围盒在三个轴向上都有交集触发自动检查。虽然这会牺牲一点计算速度但能拦住大多数拓扑问题。4.4 提示词工程在 text-to-cad 里作用有限不少朋友拿着大模型的提示词技巧来套 text-to-cad加“请仔细思考”、给几个示例、要求模型“逐步推理”。实测下来加了这些之后生成质量有一些提升但幅度远不如文生图那边明显。原因是建模脚本基本没有“模糊地带”它不像写文章可以换一种措辞表达同一个意思。你让模型“再想想”它想不出什么新的因为它缺乏对几何的实时校验能力——它不知道自己写的“拉伸20毫米”在转成实体之后看起来是什么样的。真正有效的提升手段只有一个在推理时对多轮采样结果做几何校验选“能通过核验”的那一个。让模型多采样几个候选对每个候选跑一遍完整的“脚本校验内核执行几何检查”管线最后把通过的那个拿出来。这个“最佳-of-N”策略在 text-to-cad 上带来的提升比我试过的任何提示词技巧都大。4.5 评估指标选错等于白忙初期的评估走了弯路我用“生成脚本与参考脚本的token级相似度”来打分。跑出来的分数高达90分模型却一塌糊涂——几乎每个模型都在中间某一步用了不同的特征组合方式token序列差异巨大但几何结果确实是对的。token相似度这个指标在 text-to-cad 里基本没有参考价值。同样一个零件建模方法有无数种先拉伸再切除或者用旋转特征一步做出回旋体结果实体是同一个但token序列天差地别。后来我改成了一套更务实的评估组合三维几何相似度指标算外形贴合程度关键尺寸误差直接度量标注尺寸与模型实测的偏差特征树有效性用来判断生成模型在CAD软件里是否可用还有通过率指标看100次采样里有多少能完整跑通内核执行。这四项结合起来才能比较客观地反映一个生成系統的真实水平。5. 落地场景与现实边界5.1 最可能先落地的场景概念设计阶段我认为 text-to-cad 最先赢得的不会是生产制造环节而是概念设计阶段。工程师做方案设计时的一个常态是脑子里有好几个结构方案但每个方案都建一个完整的三维模型成本太高。多数人会在纸上画草图或者直接用简单的几何体拼一个“意思对了”的示意模型。text-to-cad 在这个环节能发挥空间很大——把方案的模糊描述丢进去快速产出几个不同的三维示意模型形状对、特征表达清楚、能转视角看空间关系就达到目的了。后续精修依旧是工程师的事但省掉的是“为方案比对而建模”的大量时间。5.2 另一个高价值场景跨角色沟通制造业里有一个长期存在的效率黑洞——非技术角色与技术人员之间的需求沟通。一个采购人员拿到供应商的样品想告诉工程师“我需要一个跟这个差不多但安装孔距大一号的支架”他大概率会拍张照片发给工程师然后花二十分钟在微信里用文字描述“大一号是多大”。这类场景恰恰是 text-to-cad 最擅长的不要求描述完全精确只需要大致表达清楚“是什么零件、关键位置在哪里、主要尺寸是多少”就能生成一个可供讨论的三维模型。准确的尺寸仍需确认但沟通效率的提升是实实在在的。我甚至设想如果将来这类能力嵌入到即时通讯工具里制造业上下游的沟通方式可能会发生不小的变化。5.3 现实边界和冷静预期该泼的冷水也得泼。以我目前实测的水平来看text-to-cad 距离“取代CAD工程师”还有非常长的路——它连中等复杂度的装配体都处理不了更不用说那些依赖大量工程经验的铸造圆角、拔模斜度、公差标注和加工工艺性设计。目前的系统本质上还“只会做填空题”——你给它足够明确的描述、足够标准的特征组合它能给你一个合格结果一旦涉及需要实际工程判断的地方比如“这个位置壁厚太薄应该加一条加强筋”“这里应该用钣金折弯而不是实体拉伸”它就完全无能为力了。但反过来看如果只是把预期设定在“辅助早期设计”和“降低沟通成本”这两个目标上它是完全有资格进入实用化的。一个系统只要能稳定地把“我要一个带四个安装孔的连接板”变成“一个带四个沉头安装孔的参数化连接板模型”它就已经有价值了——哪怕它完全不懂柔性和强度也不影响这个价值成立。6. 写在后面的个人体会text-to-cad 是我近几年接触过的最“拧巴”的AI方向——它既要模型懂自然语言又要模型懂工程语义还要模型输出的几何严格满足可制造性约束三个目标之间随时打架。也正是这种“拧巴”让这个方向比单纯追求视觉效果的生成任务更有意思水也更深。如果你正准备入坑我给三个最实在的建议第一一定把CAD内核的执行校验作为你系统的中心枢纽所有生成结果都要经过它围绕它来迭代而不是拿模型当裁判第二数据上宁缺毋滥几百个干净的带特征历史的模型比几万个网格转换来的哑模型有用得多第三从最小场景出发先只做一类零件、一种钣金工艺、一套固定的特征组合跑通一个窄范围的闭环再逐步放开自由度。最后分享一个我实操中的小技巧把指令里的尺寸分成“关键尺寸”和“非关键尺寸”两类处理。关键尺寸强制走解析抽取不经过生成模型非关键尺寸放开让模型自由发挥。这样整个系统的尺寸可靠性会远高于把所有参数都交给模型生成的做法。这个改动在我自己的项目里把关键尺寸的误差率降低了超过一半而实现成本只需要多写几十行解析代码。很值。
