做CAD的老手这两年应该都绕不开一个词text-to-cad。说白了就是让计算机根据一句自然语言描述直接生成可编辑、可制造的三维CAD模型。比如你输入“一个直径40毫米、高度60毫米的圆柱顶部带一个倒角”系统自动给你出参数化模型文件而不是一堆点云或者网格。这个方向之所以火是因为传统CAD的入门门槛一直卡在“熟练使用软件”而不是“懂设计”。设计师脑子里有清晰的三维构想但要把它变成可编辑的工程模型得先在界面上画草图、设约束、做拉伸光是草图约束这一关就能劝退一堆人。text-to-cad想做的事就是把这个过程压缩成一句话的交互。它特别适合三类人想快速出原型的机械工程师、需要和结构协作的产品设计师、以及完全没有CAD基础但想玩3D打印的爱好者。我本人从去年开始在这个方向做了不少实验踩过不少坑也总结了一套比较稳的落地路径。这篇文章不聊太学术的东西就从一个开发者的角度把技术拆解、工具选型、实操流程和排错经验一次性讲清楚。1. 先把“text-to-cad”这个方向拆开看1.1 这到底是个什么问题text-to-cad 的核心任务可以拆成三个子问题。第一个子问题是“理解”即怎么把用户口语化的描述转换成机器能处理的语义结构。很多人低估了这一步的难度。比如“一个带圆角的矩形桌子”“圆角”到底是指桌面四边的圆角还是桌腿的圆角多大半径“矩形”的长宽比是多少这些信息在自然语言里都是缺省的。传统程序化建模需要把所有参数明确定义而文本输入天然是模糊的所以系统必须有能力做合理的假设和补全。第二个子问题是“表达”即用什么数据结构来承载生成结果。CAD模型和游戏里的3D网格完全不同它需要包含精确的几何尺寸、特征历史、参数约束甚至可制造性信息。如果生成的是一堆三角面片打印机或加工中心根本没法直接用——网格模型要经过逆向重建才能变成可编辑的CAD特征树这个过程极其痛苦。所以“表达”层面的选择直接决定了整条技术路线可行不可行。第三个子问题是“生成”即如何在给定语义结构和表达形式的前提下产出一个能够通过编译和校验的模型文件。这里面既有几何算法的挑战也有工程约束的挑战。我记得有个朋友第一次接触这个方向问我“不就是让大模型输出一个OBJ文件吗”这个误解特别典型。OBJ只是网格丢失了建模历史就算形状对了后续想改一个尺寸都得整个重来。所以真正意义的text-to-cad目标一定是生成参数化、可编辑、带特征的CAD模型而不是一张“形状图像”。1.2 两条主流技术路线的取舍目前业界和学术界基本分成两派。一派是“扩散模型直接生成几何”思路借鉴图像生成领域的做法用大量CAD模型训练深度生成模型输入文本描述输出体素、点云或者隐式神经场再通过算法提取成网格或实体。这派优点是几何表达能力很强能生成一些非常复杂的自由曲面比如把手、玩具、雕塑形状。缺点是生成的模型通常不可参数化也没有建模历史后期编辑和制造适配都是大问题而且在尺寸精度上很难保证到毫米级。另一派是“大语言模型生成建模代码”思路是把CAD当成一种编程问题。给大模型一个建模脚本的API或者领域特定语言让它根据文本描述写出对应的建模代码然后交给内核编译生成模型。这派生成的东西天然具备参数化结构尺寸精确、可编辑、可二次开发非常贴合工程场景。缺点则是受限于建模脚本的表达能力复杂的自由曲面很难做出来而且大模型在长代码、多步骤的建模逻辑上还经常出错。我自己的倾向非常明确如果目标是做能落地、能制造、能和现有CAD流程衔接的东西第二派是目前唯一靠谱的路线。第一派看起来炫酷但做出来的东西经常卡在“看看可以上手就废”的状态。不过这里要提醒一句两派的边界正在模糊。现在有不少工作尝试把扩散模型生成的草图轮廓作为建模约束再喂给大模型形成代码。未来大概率是混合路线而不是谁替代谁。2. 我推荐的落地路线LLM驱动参数化建模2.1 为什么选参数化建模这条路线关键在于“可编辑”和“可制造”。我拿3D打印举例。打印一个模型你只要给切片器一个STL网格就行表面上有网格就够了但如果你要把同一模型改成另一个尺寸比如把壁厚从2毫米改成3毫米网格模型就得整个重做。而如果是参数化模型改一个变量的值特征树自动刷新全模型联动这才是CAD用户真正的工作方式。text-to-cad如果走这个方向本质上就变成了“用自然语言去控制一个参数化建模环境”。这带来的好处是颠覆式的设计意图、建模历史、参数关系全部保留了生成结果可以无缝导入到主流CAD软件里继续改。对制造业来讲这个价值远超一个好看的形状。另外还有一个很实际的理由参数化建模代码是可验证的。代码能不能编译生成几何体有没有自相交、有没有破面都能用程序自动检测。这就给整个系统加了一层质量闸门不至于让用户等了一分钟拿到一个废品。2.2 关键模块与工具链选型我把整套系统的核心模块梳理成四块语言理解模块、建模代码生成模块、几何编译模块、校验与反馈模块。语言理解模块负责从自然语言中抽取出尺寸、形状、位置、拓扑关系等关键信息。这一步通常交给大模型完成但它并不只是简单地问答而是要输出结构化的中间表示。我常用的做法是让大模型先输出一个JSON包含对象类型、尺寸参数、布尔操作列表这些字段再做下一步生成。建模代码生成模块负责把上面的结构化中间表示转换成具体建模代码。这里的设计哲学是“代码越简单越好”让每一句自然语言尽量对应一到两个API调用避免大模型去推理复杂的设计意图。几何编译模块执行建模代码生成实际的几何体。一般来说我并不直接把代码丢给核心内核而是先做一次语法级别的静态检查再执行生成。校验与反馈模块对生成的几何体做体积、面积、边界框、实体性检查。如果校验失败就把错误信息反馈给生成模块让它重试。工具选型方面我给个实用的参考。建模脚本这一层两种主要选择一种是声明式的建模语言适合表达“加、减、圆角、抽壳”这类特征操作学习成本低但复杂形状写起来累另一种是基于通用编程语言的CAD脚本库灵活度高能写循环、条件、自定义函数适合程序化建模但代码更容易出错。我个人更推荐后者因为大模型处理通用语言的能力更强调试也方便。2.3 让大模型学会“建模语言”这是整个系统里我最想强调的部分。很多人以为把模型API接上告诉它“输出CAD代码”它就能自动干活实际效果往往很差。原因在于大模型训练语料里CAD建模代码的占比非常低它可能对通用编程语言很熟但对你那个建模API根本不熟。解决办法是用“示例注入”来做上下文抑制。具体说就是给大模型提供一小段精心设计的提示词里面包含这个建模环境的API文档摘要、一个包含全类型特征的示例代码片段、以及几个从文本描述到代码的映射例证。我问过某开发者他说光是把API文档压到提示词里并保持响应稳定就调了两周——这真不是白调的提示词的质量对结果影响极大。实操中我给几个具体的建议示例代码必须用注释强调结构边界比如写清“线段闭合后再拉伸”让模型知道几何草图和实体特征之间的先后关系。让大模型先输出结构化中间表示再输出代码分两步比一步到位稳定得多。把常见的错误修复规则直接写进提示词比如“如果拉伸轮廓未闭合自动补一条线段”。3. 实操从一句话到可打印的模型文件3.1 环境准备与最小可用流程我可以直接给你一套能跑通的最小流程。硬件不需要多好一台普通开发机就可以。软件层面需要装好开发语言环境、CAD脚本库以及一个大模型接口本地部署或者调用云端API都行。整个流程分五步输入文本 → 语义抽取 → 代码生成 → 几何编译 → 文件导出。每一步我用一个独立的小脚本串联方便单独调试。代码层面我大致这么组织# 伪代码text-to-cad流水线骨架 def run(text): spec extract_spec(text) # 语义抽取输出结构化JSON code generate_code(spec) # 生成建模代码 validate_code(code) # 语法级校验 model compile_model(code) # 编译生成几何体 export_stl(model, output.stl) # 导出打印文件 return output.stl这一步看着简单实际跑起来处处是问题。我的经验是把每步的结果打印出来单独成一个日志文件排查的时候会省很多力气。3.2 提示词构造把口语翻译成建模约束提示词是决定成败的第一关。我踩过最大的坑就是“把提示词写成跟工程师说话而不是跟模型说话”。举个例子“一个直径40毫米、高度60毫米的圆柱顶部带倒角”。如果你直接把这句丢给模型它大概率会漏掉倒角参数。我发现一个比较稳的做法是在提示词中明确要求模型把文本里的每个尺寸形容词抽出并在输出的JSON里逐项对应缺失维度必须用默认值并标注。下面是我常用的一段提示词骨架你可以直接拿去改你是一个参数化建模助手。用户会给出自然语言描述。 第一步把描述转化成JSON字段包括 - parts: 物体组成清单 - dimensions: 每个部分的长度/宽度/高度/直径/半径 - operations: 特征操作拉伸、旋转、倒角、圆角、布尔运算等 - constraints: 几何约束同心、对称、垂直等 第二步根据JSON写出可执行的建模代码。 注意尺寸单位统一为毫米未明确的尺寸使用默认值倒角必须给出半径。这里有个心得体会比起让模型一步到位输出建模代码“先抽取JSON、再生成代码”的两阶段方式除了稳定之外还有一个好处——你可以在中间插入一个人工审核点看到JSON就能判断模型理解没有偏差。3.3 生成结果验证与参数回填代码生成出来几何也编译了不等于完事。你还要做几何层面的自动验证。我在流水线里加了三个检查实体性检查模型是否是一个封闭的实体而不是带空洞的曲面、尺寸检查包围盒三个方向是否与要求一致、特征检查倒角、圆孔等关键特征是否存在。如果验证失败自动化反馈回去重试。这里的关键是要把失败原因写成模型能理解的格式而不是丢给它一段原始报错。比如错误信息是“Error: sketch not closed”我会在反馈里加一句“草图轮廓不闭合请检查线段端点是否精确重合必要时用重合约束修复”。实测这样重试的成功率会高出一大截。参数回填是我最近才加的一个环节。当生成的模型和用户描述的期望尺寸有偏差时不重新生成而是直接修改代码里的参数值再重新编译。比如包围盒检查发现高度是58毫米而要求是60毫米就把变量里的高度值改成60。这种“小偏差修正”靠参数回填比重新生成省钱省时得多。3.4 现场演示一个带圆角的矩形支撑座我给你跑一个真实的小例子。输入文本“做一个120x80x10毫米的矩形支撑座四个角倒5毫米的圆角中心有一个直径20毫米的通孔。”语义抽取后得到的JSON大致长这样{ parts: [ { type: rectangular_plate, width: 120, depth: 80, thickness: 10 } ], operations: [ {type: fillet, target: all_vertical_edges, radius: 5}, {type: hole, target: center, diameter: 20} ] }生成的建模代码核心逻辑基本是先画一个120x80的矩形草图拉伸10毫米然后给四条竖直边加圆角再在顶面中心打一个直径20的通孔。编译完成后导出STL再导入切片器检查模型没问题尺寸也符合要求。这个例子虽然简单但它完整走完了从文本到可制造模型的整条链路。你把尺寸换一换就是一个不同规格的零件。这就是参数化的价值——同一个代码模板靠参数驱动可以衍生出无数变体。4. 常见问题与排错经验4.1 生成的模型和描述“不像”这是最高频的抱怨。用户说“圆角”模型给的是45度切角用户说“一个圆环”模型生成的是实心圆柱。归根结底是语义理解偏差解决思路有两个第一在提示词里强制加入“参数逐项回显”步骤让模型在输出代码前先复述它理解到的所有参数。这一步能暴露模型隐藏的错误假设我发现它能拦截掉大约四成不合理的生成结果。第二给常见混淆词做一份“同义词规范表”比如“圆角”统一映射成圆角特征“倒角”统一映射成切角特征避免模型在多义词上乱猜。这里我想多说一句最让模型头疼的是“口语中的省略”。设计者说“一个支架能放手机”这里的信息极度稀疏模型不问你尺寸根本没法建模。合理的做法是交互式追问而不是强行生成模型先输出缺失参数清单用户补全后再建模。这个“对话式补全”机制实测能把一次成型的成功率提高不少。4.2 建模代码一堆报错大模型生成的代码语法级报错非常常见。常见的有漏了闭合轮廓、坐标参数类型写错、布尔求差操作的顺序反了、引用了未定义的变量。我的排查口诀是“先语法、后几何、再性能”。先跑一个静态检查脚本把变量定义、函数调用、坐标系合法性都过一遍再编译用几何内核去检查有没有退化面、自相交最后才考虑优化性能。我把这套检查做成一个函数每次生成完自动跑一遍报错就直接带日志重试。有一点特别坑大模型经常生成“看起来对实际操作失败”的代码。比如两个布尔运算之间的依赖顺序不对编译不报错但结果变成空实体。有一次我排查了半小时发现是求差运算的对象写反了。这种问题提示词里最好写明“布尔运算必须先确定保留对象再执行差集”。4.3 复杂曲面和装配体直接崩参数化建模路线最大的短板就是复杂自由曲面。你让模型生成一个符合人体工学的鼠标外壳它写出来的代码可能是一堆小平面近似的面既不光滑也不能制造。这时候不要硬撑我一般会切换策略用扩散模型先出一个概念网格做简化处理后导入CAD软件做逆向重建得到可编辑曲面再继续做结构设计。这个混合流程虽然链路长一些但至少每一步都可控。装配体方面我实测下来大模型目前只能处理“几块零件放一起”的简单组装一旦涉及运动副、约束链、配合公差它基本力不从心。我的建议是让模型只负责生成单件零件装配逻辑交给工程师在CAD软件里完成。不要试图让text-to-cad一步跨越到自动装配这个期望目前还不现实硬做只会得到一堆“摆在一起但根本没有约束关系”的面片。4.4 耗时和成本怎么控很多人忽略text-to-cad的算力成本。我跑一个中等复杂度的零件如果每一步都让大模型重新思考可能花掉几十万token的调用量时间和金钱都受不了。我的优化方式是分级调用第一级用轻量模型做语义抽取和JSON输出第二级才用强模型做建模代码生成。实测这种“双模型”组合比全程都用强模型便宜了一半以上。另外把常见零件模板预先生成好存成代码片段库用户描述匹配到相似模板时直接改参数重编译完全不需要再问大模型要代码。为了让你排查时少走弯路我把常见问题整理成一张速查表症状可能原因优先排查动作形状与描述不一致语义抽取阶段漏参数检查JSON中间表示核对尺寸与特征字段代码编译报错轮廓未闭合或参数类型错误跑静态检查定位错误行号编译通过但模型为空布尔求差顺序错误检查保留对象是否先定义再执行差集生成模型有破面几何内核产生退化面删除重复边、重建草图后重新拉伸一次生成太慢全链路调用强模型切换双模型分级调用命中模板直接回填5. 这套玩法的边界、坑与后续空间5.1 当前阶段最容易踩的坑先说最容易踩的坑。第一个是“过度追求端到端”想一个输入直接得到完美模型结果卡在三不管地带。我建议拆开做每一层都能单独验证别迷信单一大模型能包打天下。第二个坑是“测试集过拟合”。我自己有一段特别惨痛的经历在开发时用十个样例反复调提示词效果非常惊艳一到真实用户的新描述就崩。后来才明白提示词和模板一定会过拟合到测试数据上所以必须持续扩充多样化的测试用例每次优化后回归跑一遍全集。第三个坑是“忽略下游制造验证”。STL导出来是一回事实际能不能打印、能不能加工是另一回事。壁厚、拔模角度、支撑结构这些制造性约束text-to-cad目前很难自动保证。我的习惯是生成后至少用切片器或CAM软件做一次虚拟验证发现明显工艺问题再回炉。5.2 值得继续做的几个方向一个是“设计规范约束”。把公司或行业的建模规范命名规则、图层管理、尺寸标注规范、公差等级写进提示词或后处理层让生成结果从一开始就符合标准而不是生成后人工整改。这个方向对工业化落地非常关键目前做的人还不多。一个是“交互式设计修改”。现在的text-to-cad基本都是一次性生成我特别想做的是让用户能在生成后继续用自然语言修改比如“底盘加厚2毫米”“孔位向右移10毫米”靠参数回填和局部代码重写实现而不是整个重生成。这个方向对设计效率的提升是巨大的。还有就是对“制造特征”的直接支持比如螺纹孔、倒扣、加强筋、装配定位特征。现在的模型生成对这些工程细节很不敏感但是恰恰是这些细节决定了一个模型能不能真的用起来。做这个方向这段时间我最大的体会是text-to-cad 真正的价值不是“把一句话变成模型”这个炫技瞬间而是它逼着我们重新思考CAD的本质——建模的核心从来不是画图而是把设计意图变成精确、可复用、可制造的结构化信息。用自然语言直接驱动这个信息构建过程确实是下一代设计工具的雏形。另外一个很实际的经验是别等工具完美了再用。如果你手头有建模需求现在就可以搭一条最小流程哪怕只覆盖“简单零件特征操作”这个范围用在日常快速出原型上也已经能省下大量重复劳动。先把流程跑通再去解决复杂曲面和装配这些硬骨头这条路比一开始就想做个全能系统要务实得多。
