1. text-to-cad到底是什么——先把这个概念嚼碎了第一次看到“text-to-cad”这个说法大多数人第一反应是用文字生成三维模型听起来像是把“给我画一个杯子”丢给电脑然后它就真的给你一个杯子。这个直觉方向是对的但理解得还不够深。如果只是生成一个像杯子的网格体那这件事五年前就有技术方案了也不至于到最近才被反复拿出来讨论。text-to-cad真正有价值的地方不是“识别自然语言并输出一个模型文件”而是让大语言模型直接操作一套参数化建模指令生成一个带有完整特征树、可以继续编辑、可以改参数、能够落到实际工程流程里的CAD模型。换句话说它生成的不只是“一个形状”而是一整套“建模过程”。这才是它和传统文本生成图片、文本生成三维网格之间本质的区别。从实际应用的角度看这件事解决的是两类人的痛点。一类是机械设计、工业设计领域的工程师每天要处理大量标准件、相似结构件手动建模虽然不难但极其枯燥。另一类是非专业用户比如采购、销售、产品经理他们需要用三维模型做沟通和验证但不会用建模软件。text-to-cad给了这两类人一条更短的路径用自然语言描述需求让模型去完成重复劳动。这篇文章我用自己实际折腾过的经验把text-to-cad的技术结构、可行方案、实操流程和踩坑经历都梳理一遍。适合三类人阅读想搭建自己的text-to-cad原型的开发者、正在评估这项技术能不能进工作流的工程师、以及单纯想搞清楚“这东西到底是不是噱头”的产品和技术管理者。1.1 它解决的不是“画图”问题而是“表达”问题人类工程师设计一个零件脑子里想的从来不是“这个形状的点的坐标是多少”而是“这是一个底座厚度5毫米四个角各有一个直径4毫米的安装孔孔中心距边缘10毫米底部开一个倒角”。这句话本质上就是一段文字描述而传统CAD软件要求你把它翻译成草绘、拉伸、打孔、倒角等一系列离散操作。这个翻译过程对新手来说是有学习成本的对老手来说是需要重复执行的低效劳动。text-to-cad把“翻译”这一层交给大模型来做。模型负责理解“一个带四个安装孔的底座”这句话里隐含的几何信息和特征关系然后输出对应的参数化建模指令序列。指令本身是结构化的比如“在基准平面上画一个120x80的矩形拉伸5毫米在四个角生成直径4毫米的通孔”。执行这些指令的仍然是你用的CAD内核或者建模软件不是大模型直接生成顶点和面。这里就引出一个关键认知大模型是指挥官不是施工队。它不参与几何计算的细节只负责把人类的模糊意图转译成工程系统能够理解的动作。这种方式的好处非常明显——输出的结果天然就是参数化模型你拿到手之后可以继续改尺寸、改位置、重新编辑特征而不是面对一堆无法修改的三角网格。我自己在做原型验证的时候最大的感受是把问题定义为“翻译”之后技术实现的路径就清晰了很多。你不需要去解决“如何生成一个高质量曲面”这种工程难题你需要解决的是“如何让模型输出的指令足够规范、足够可执行”。这是完全不同的技术栈。1.2 核心思路是程序化建模不是生成网格很多人刚接触这个方向时会拿它和“文本生成三维模型”的AI工具做对比。那些工具的典型做法是输入一段文字输出一个OBJ或者GLB文件模型是三角网格的适合渲染、展示但不适合加工、不适合装配、不适合做工程分析。CAD行业对模型的诉求完全不同一个零件模型必须包含精确的尺寸、约束关系、特征历史才能支撑后续的仿真、加工和装配验证。text-to-cad走的是另一条路程序化建模。所谓程序化建模就是用一段可执行的代码或者指令序列来描述模型的构造过程。模型不是“画”出来的是“算”出来的。比如一个法兰盘程序化描述就是“旋转一个轮廓生成主体再开六个均布孔再做一圈倒角”。这段描述可以被同一个CAD内核反复执行修改任意参数都能重新生成这就是参数化能力的来源。把这两条路线放在一起对比就很清楚了对比维度文本生成网格text-to-cad程序化生成输出物三角网格模型参数化特征模型可编辑性基本不可编辑特征树完整可改参数工程适用性适合可视化、动画适合加工、仿真、装配底层依赖生成式3D模型大模型程序化建模引擎核心难点几何质量、拓扑一致性指令规范、参数理解、约束推理所以如果你想做一个真正能用的text-to-cad工具从一开始就应该明确你的目标不是让模型“画得像”而是让模型“按正确的过程建出来”。像不像由视觉判断正确性由建模流程保证。这个过程对了结果就一定是好的。1.3 现阶段最适合落地的地方在哪里从成熟度来看text-to-cad目前还做不到“你随便说一句它就能给你一个工业级模型”的程度。但有几个场景已经比较实用了。第一个是标准件和通用件的自动建模。法兰、支架、轴套、齿轮坯这类零件结构相对规整特征套路固定大模型很容易学会。你给它一句话“直径80的法兰盘六个均布孔孔中心圆直径60”它能生成一个基本可用的模型。这类工作占了设计环节里很大一部分重复劳动自动化价值非常高。第二个是概念设计阶段的快速验证。工程师脑子里有个想法想快速看个三维效果验证装配关系这时候不需要精雕细琢只需要一个结构合理的粗略模型。text-to-cad可以把想法快速变成可查看、可分享、可讨论的三维形态大大降低沟通成本。第三个是设计和制造的衔接。程序化生成的模型天然带特征信息可以直接对接CAM、3D打印切片、有限元分析等下游工具。相比从网格模型反推几何这条路要干净得多。我做原型测试时的判断是这技术现在还撑不起“替代设计师”这种宏大叙事但已经能在“辅助设计”“批量建模”“设计自动化”这些方向上产生真实价值。2. 技术路线拆解一整套text-to-cad系统由哪几块拼起来如果只是用大模型的API把一句话和一个模型文件对应起来那是demo级别的玩具。真正要做一套能用的text-to-cad系统至少需要四个部分协同工作负责语义理解的大模型、负责中间表达的指令语言、负责执行指令的建模引擎、以及负责检查结果的质量反馈模块。这四个部分缺一不可任何一个环节出问题整个链路都跑不通。2.1 大语言模型负责翻译不负责画图这个观点我在前文提过但值得展开。大语言模型在这个系统里的职责边界是接收自然语言描述输出结构化的建模指令序列。它不需要理解几何内核的底层实现不需要知道B-rep数据结构的细节只需要把“用户想要什么”转译成“建模系统支持哪些操作”的表达方式。在实际落地时这意味着你要对大模型做两件事。第一件事是给它一套建模指令的词汇表告诉它系统支持哪些操作、每个操作的参数长什么样、有哪些约束必须满足。第二件事是给它足够的示例让它学会将不同的自然语言表达映射到正确的指令组合上。这本质上是一个可控生成问题你越能把输出空间约束得足够清晰模型的准确率就越高。我用过的几种实现方式里最简单的是让模型直接输出一段DSL代码再由程序解析执行。稍微复杂一点的是让模型通过函数调用机制去调用建模API每次调用对应一个操作。两种方式都可行区别在于你对中间格式的控制粒度。直接输出DSL的好处是实现简单、便于调试函数调用的好处是模型和建模引擎的交互更自然、更容易实现多轮控制。有些项目也会尝试微调一个小模型来专门做这个任务。微调适合输出格式固定、操作类型有限的场景能够显著降低推理成本和延迟。但通用性会差一些擅长处理模板化的建模任务遇到没有见过的表述方式容易出问题。2.2 中间表示层决定生成质量的上限这是整个text-to-cad系统里最容易被忽视、但最值得钻研的部分。中间表示层通俗说就是“模型输出什么格式才能让建模引擎稳定执行”。你直接让大模型生成STEP文件是不现实的那是一种复杂的文本交换格式逐行逐句生成容易出错。你让大模型直接生成几何代码也希望渺茫它不具备空间计算的精确能力。所以中间表示层必须是一种“刻意设计”的东西。目前比较常见的做法是设计一套轻量级的程序化建模DSL。这套DSL的指令集合需要和建模引擎的能力保持对齐引擎支持什么操作DSL里就定义什么指令。比如一套面向机械零件的DSL通常包含草绘指令矩形、圆、多边形、样条线等特征指令拉伸、旋转、扫掠、放样、倒角、圆角等阵列指令线性阵列、圆周阵列布尔指令合并、相减、相交辅助元素基准面、基准轴、坐标系定义DSL的设计有几个原则值得留意。一是参数必须显式命名不要依赖模型去推断“默认值在哪”二是约束关系要支持声明式表达比如“这两个圆同心”“这条边和那条边共线”三是指令序列要有严格的层次结构草绘在前、特征在后、阵列和布尔在最后。这样设计的目的是让大模型输出的内容足够结构化降低执行阶段的解析难度。如果说大模型决定了这个系统的“理解上限”那中间表示层就决定了它的“工程下限”。一个好的DSL能把模型的幻觉限制在可纠正的范围内一个糟糕的DSL会让模型输出一大堆看似合理但根本执行不了的指令。我见过太多原型项目死在“模型输出不合法”这个问题上最后排查发现是DSL设计得太自由给了模型太多发挥空间。2.3 参数化建模API为什么是工程落地的关键有了中间表示层之后你还需要一个真正能把这些指令变成几何实体的执行器。这一步的选择基本决定了整个系统的工程边界。市面上常见的参数化建模内核大致分三类商业闭源内核、开源内核、以及可以通过脚本驱动的商业建模软件。选择哪一类取决于你的应用场景是嵌入式自动化、离线批处理还是交互式辅助设计。如果你的目标是构建一个自动化批量建模服务开源内核或者商业建模软件的脚本接口都值得考虑。脚本接口的优势在于它有完整的参数化建模能力、有原生窗口去查看结果、导出格式齐全缺点是启动一个软件实例占用资源比较大不适合高并发场景。开源内核的优势是轻量、可控、可以嵌入到自己的服务里去缺点是你可能需要自己包一层几何操作封装工程工作量会多一些。我在原型阶段使用的是开源内核的方案核心原因是它的许可证和部署方式更灵活。不过这里有个容易被忽略的点几何内核只是执行引擎你还需要一个好用的错误反馈机制。当模型生成的指令执行失败时你要能拿到准确的失败原因比如“草绘约束不足”“拉伸方向与草图平面冲突”“自相交导致布尔运算失败”。否则整条链路一旦出错排查成本会非常高。3. 实操流程从一个想法到一个能用的参数化模型理论部分说得再多不如动手跑一遍。这一章我把一整套text-to-cad的实操流程拆开从环境搭建到Prompt设计再到闭环修正每个环节都写清楚。你可以把它当作一条可以直接照做的路径。3.1 环境准备先跑通一个最简链路搭建text-to-cad系统不需要一开始就搞很复杂的架构。先跑通一条最简链路大模型API 指令解析器 几何内核。这条链路建立起来之后再逐步往里面加校验、反馈、重试等模块。具体到工具选型上我的建议是大模型部分用支持函数调用或者结构化输出的主流商用模型因为它们的指令遵循能力更强指令解析器自己写一个用Python或者其他你熟悉的语言把DSL文本解析成内部操作序列几何内核这一层可以根据你的技术栈选一个支持脚本控制的建模环境。对我个人来说最快能验证想法的方式是让大模型输出JSON格式的操作指令然后写一个Python脚本去逐条执行。JSON的好处是解析简单、结构清晰、出错容易定位。比如一个“开四个安装孔的底座”的请求大模型输出{ operations: [ { type: sketch, plane: XY, entities: [ { kind: rectangle, name: base, width: 120, height: 80, center: [0, 0] } ]}, { type: extrude, sketch: base, height: 5, operation: new }, { type: hole, on_face: base_top, diameter: 4, positions: [ [45, 30], [-45, 30], [45, -30], [-45, -30] ]} ] }这种格式非常直白不需要训练也能看懂。而且它的优点在于一旦执行失败你可以很清楚地看到是哪一条指令出了问题。调试起来远比让模型直接生成一段代码要轻松。在跑通这条链路之前我建议你不要急着做复杂的Prompt。先用一组固定句式测试比如“一个长多少宽多少高多少的方块”把基座流程跑通。流程通了之后再逐渐增加自然语言的复杂度。这一步最大的价值是帮你建立信心让你看到整条链路是可行的。3.2 Prompt设计把模糊需求拆成可执行的建模指令Prompt设计是text-to-cad系统里投入产出比最高的环节。同样是“帮我做个法兰盘”这样一句话不同Prompt写法得到的模型质量可能天差地别。核心原因在于大模型对模糊词的默认解读不一定是你想要的。我在实践中总结了一套比较有效的设计方法核心思路是把“用户需求”和“建模约束”分成两层传递给模型。用户需求可以很口语化比如“底座四个角打孔”但建模约束必须明确包括单位、尺寸、坐标系、特征优先级。一个比较完整的system prompt结构大致是这样的角色定义你是一名参数化建模工程师根据自然语言描述生成CAD操作指令输出格式只输出JSON不要解释过程单位约定所有长度单位为毫米坐标系约定默认使用XY平面作为草绘平面Z轴正方向为拉伸方向几何原则优先使用参数化特征禁止生成网格或直接用B-rep布尔命名规范每个特征都要有名字方便后续编辑自检要求生成的模型必须满足尺寸合理、特征之间无干涉、可加工性合理这一套约束写下来模型的输出稳定性会有明显提升。比较有意思的是“自检要求”这一项它会让模型在生成指令时主动检查一下自己有没有犯低级错误比如把直径80的零件开直径60的孔显然不合理。这个机制不能保证模型完全正确但能拦截掉相当一部分明显不合理的输出。用户消息部分也需要引导让用户描述尽量包含关键尺寸和功能要求。最简单的方法是在Prompt里给一个模板要求用户按“零件类型关键尺寸附加特征”的结构去描述。但现实情况是用户不会配合你所以更好的做法是你做一个自然语言预处理把口语描述里的关键参数抽取出来再交给大模型。我在实际项目里就是用“抽取-重组-生成”三步走先用一轮轻量级模型抽取尺寸和特征描述再重组为规范的结构化描述最后交给text-to-cad主模型生成指令。这样做能明显提升对口语化输入的容忍度代价是多一次模型调用。3.3 生成、校验、反馈修正完整闭环怎么转起来如果只做一次“输入一句话输出一个模型”那成功率很难达到实用水平。真正稳定可用的系统一定要有循环修正机制。用一句话来说就是先生成再检查错了就让模型重新改。校验环节可以做两个层面。第一层是格式校验检查模型输出的JSON是否符合预定义的schema必填字段是否存在枚举值是否合法。这层校验很快基本不消耗额外算力。第二层是几何校验真正把指令丢进建模引擎去执行看能不能成功生成实体、有没有自相交、尺寸是否合理。第二层校验是整个闭环的关键。执行失败时建模引擎会返回错误信息你把这部分信息作为反馈拼到原始Prompt里让大模型重新生成一版。比如“拉伸操作失败原因是草绘未闭合”大模型看到这个反馈后大概率会主动修复草绘轮廓或者换一种更稳妥的建模方式。我在跑这个闭环时有一个习惯把每一轮的输入、输出、错误信息都记录下来。这样不只是调试方便你还可以复盘哪些错误是高频错误。如果你的系统里总是出现“孔位置越界”这类问题说明Prompt的约束还不够细或者DSL设计有歧义。根据高频错误去优化系统效率远高于随机调整Prompt。循环次数也要限制。我一般设置最多三次重试三次之后仍然失败就放弃自动生成转人工处理。原因很简单有些需求本身描述得就不清楚模型重新生成再多轮也只是在猜。设置上限可以避免资源浪费。4. 常见问题与排查技巧我在text-to-cad里踩过的那些坑text-to-cad这个方向看着门槛不高真正用起来之后各种毛病都会冒出来。这一章整理几个我实际踩过的高频问题每一条都附上排查思路和解法希望能帮你少走点弯路。4.1 模型输出合法但是几何上“没用”这是最让人头疼的一类问题。大模型生成的指令格式完全正确schema校验也通过了建模引擎也能顺利执行生成的模型看起来也有模有样但放到工程场景里根本不能用。典型表现是该倒角的地方没有倒角该有的公差配合没有体现孔的位置分布不合理或者拉伸方向选错了。根源在于语法正确不等于设计合理。模型学到了“法兰盘由主体孔倒角组成”这个模式但它不理解“六个孔应该均布才满足使用需求”的物理逻辑。解决这个问题单靠Prompt改进效果有限更有效的做法是在DSL里增加约束检查规则把“孔必须均布”“孔径与主体尺寸比例必须合理”这类规则固化成代码在几何校验阶段就用程序拦截。另一个比较实用的技巧是在Prompt示例里加入“反面案例”。给模型看几个“设计不合理”的例子并明确指出不合理在哪里。这样做比单纯说“请生成合理的模型”管用得多因为大模型学习示例的能力远强于服从抽象规则的能力。4.2 单位、坐标系和草绘基准面的混乱text-to-cad系统对单位的敏感度远高于普通文本生成任务。同样一句“厚度3”如果英制单位和公制单位混在一起生成出来的模型尺寸会差25.4倍直接导致整个设计报废。模型内部可能对单位并不敏感它只是按概率把数字填进去不会去思考这个数字在哪个单位体系下是合理的。坐标系问题也是重灾区。同一个“底座”描述模型有时候把拉伸方向设为Z有时候设为Z-有时候放在XY平面上有时候放在YZ平面上。这种不一致性在生成单个零件时不容易发现但在后续做装配体对齐时就会让人崩溃。我的处理方式是在Prompt里极其显眼地声明单位、坐标系、基准面并且在DSL里强制要求每个草绘指令都带上plane字段。解析器在收到没有plane字段的指令时直接拒绝执行而不是默认填充一个值。用“宁可报错也不猜测”的策略能过滤掉大量潜在错误。4.3 上下文丢失导致模型整体漂移多轮交互是text-to-cad的前沿应用方向之一比如先创建一个底座然后说“底座加高一些”“在侧面开个槽”“把孔改成腰型孔”。理想情况下模型应该记住底座是什么样然后精准地执行增量修改。但现实是对话越来越长之后模型常常把最早的模型结构信息忘掉或者越改越偏。这个问题在多轮设计中尤其致命。原因是大模型的注意力机制天然对近期内容更敏感早期的模型特征描述在长上下文里容易被稀释。解决思路有两种一种是把状态压缩每一轮对话结束后把当前模型的结构摘要提取出来下一轮交互时把摘要重新注入Prompt而不是依赖对话历史另一种是提供“回到上一步”的回退机制每轮生成结果都保存快照发现漂移了就回退到上一个稳定版本。两种方式我都在实际项目里试过。状态压缩更适合长流程自动化虽然实现上要维护一个“模型状态摘要”的数据结构但稳定性好得多。快照回退方式简单直接不过当对话轮数很多时用户可能自己也分不清该回退到哪一步了。4.4 性能瓶颈和超时处理模型生成指令通常需要几秒钟几何内核执行也需要时间如果校验失败还要再跑一轮重试一个复杂零件的完整生成链路可能要消耗几十秒。这个数字对批量生成场景来说是个严峻的考验。我在优化性能时做了三件事。第一件是分层生成先让大模型生成一个粗粒度的“建模方案”只包含特征类型和大致顺序不包含精确参数方案确认没问题之后再生成具体的参数化指令。这样可以把错误尽早暴露避免在错误方案上浪费时间。第二件是并行验证多个候选方案并行送到建模引擎去执行谁先通过校验就用谁。第三件是把高频使用的建模操作提前封装成模板大模型只需要做“选模板填参数”这个动作而不是每次都从零生成指令。另外无论怎么优化都要做好超时处理。我在系统里给每个零件设置了一个总体时间预算超时后自动进入人工处理队列。没有兜底方案的自动化系统上线之后一定会被真实用户骂到怀疑人生。5. 再往深处走从单零件生成到更复杂的设计场景能把一个零件从文字变成模型只能说明链路跑通了。要从“能跑”走到“能用”还有几个方向值得深入探索。这一章聊聊我看到的三个进阶方向每个方向都有一定的技术挑战但也都有实际的应用价值。5.1 装配体、约束与零件间关系的表达从单零件到装配体是一个质的跨越也是text-to-cad真正走向工程设计核心的必经之路。单零件生成只涉及“自身几何形状”装配体生成还要求模型理解零件之间的空间关系哪个零件放在哪个位置哪个面和哪个面贴合运动副怎么定义。我尝试过的方案是扩展DSL在指令集里加入装配约束描述。比如“将零件A的底面与零件B的顶面重合孔中心对齐”。这个描述不是几何建模指令而是一种装配语义。模型需要输出的不再只是“如何创建这个零件”还包括“这个零件和其他零件之间的相对关系”。这个方向目前的技术成熟度还不高主要难点在于模型的几何空间推理能力有限很难想象出多个零件在三维空间里的相对位置和装配顺序。不过在一些受限场景里已经可以做得很好了比如标准件库、管路连接件、螺栓螺母垫圈这类组合模式非常固定模型很容易掌握。5.2 批量生成不再是梦——参数扫描和设计变体单件生成只是起步批量生成才是text-to-cad最吸引人的价值点之一。想象一下这个场景一个产品要做多个型号每种型号只是尺寸不同目前工程师需要手工修改模型参数再逐个出图。用text-to-cad系统你只需要定义清楚变化规则“内径从20到50每隔5一个规格孔数按直径大小适配”剩下的事情全部由系统自动完成。这种批量化能力背后的技术支撑恰恰就是我前面强调的程序化建模路线。因为模型是参数化的变更尺寸参数就能重新生成新模型因为特征是完整的批量导出图纸、批量做仿真都可以无缝衔接。在项目管理、产品选型这类需要多型号数据支撑的场景里这套能力能节省的时间非常可观。还有人把这类应用玩得更高级他们在批量生成的基础上叠加了“设计约束检查”比如“壁厚不得小于2毫米”“所有倒角半径不小于0.5毫米”。系统生成一个变体就检查一次不满足的自动打回满足的进入下一环节。这种“自动建模自动审核”的组合正好卡在制造业数字化的需求点上。5.3 接入现有设计和制造流程的三种方式最后说说落地接入的问题。一套text-to-cad系统做出来之后不能只在实验环境里自己玩要接到设计团队、制造流程、产品数据管理平台里才有真实价值。我整理出三种接入方式你根据自己团队的情况选择。第一种是“辅助式”接入。把text-to-cad作为插件或者脚本工具嵌入到工程师常用的CAD软件里。工程师在对话框里用文字描述需求系统自动生成初始模型工程师自己再手动完善。这种方式适合设计团队因为它的侵入性最小工程师依然保有最终控制权。第二种是“自动化”接入。系统接收结构化输入比如ERP系统里的物料参数表自动生成对应的三维模型存到统一的模型库里。这种方式适合标准化程度高、批量大的业务场景比如标准件、通用件、打包方案。实现难度较大但收益也最大。第三种是“协作式”接入。text-to-cad作为设计评审的辅助工具把产品经理、销售人员的口头描述快速转成模型放到协同评审平台里讨论。这种方式不追求模型精度更强调“把想法变成看得见摸得着的东西”的效率。对非设计岗位的价值最直接。这三种方式不是互斥的很多团队会结合使用。我在实际规划里比较推荐先做辅助式接入因为它能最快收集到真实需求而且工程师的反馈可以直接用来迭代你的Prompt和DSL。等系统成熟度上来了再逐渐往自动化方向推进。我个人在实际操作中的体会是text-to-cad不是一个“一句Prompt解决所有建模问题”的黑魔法它更像是一条流水线需要你精心设计每个环节。最花时间的部分往往不是模型调用而是DSL设计、错误反馈、校验规则这些不起眼的工程细节。把这些细节打磨好整个系统的体验就会有质的提升。最后再分享一个小技巧每次跑通一个新类型的零件都把它沉淀成一个模板放到你的模板库里。时间长了之后你会发现自己不是在“生成模型”而是在“组装模板”速度会快到一个很夸张的程度。这个方向后续还可以和你团队的知识库、设计规范、历史模型数据打通让系统越用越聪明。