直接给读者一句话——把“一个直径80毫米、带六个均布沉头孔的法兰盘”这句话丢给程序它就能给你一个可以直接拿去开模的CAD模型这事现在已经不是PPT了。text-to-cad这个词说的就是用自然语言直接生成CAD模型的一整套技术路线。它不是为了替代你手里的SolidWorks或Fusion 360而是把“从想法到几何”这一段最消耗体力的过程自动化让你把精力放在真正需要判断和取舍的设计决策上。这篇文章想聊透的是这类项目背后到底包含哪些核心技术点哪些方案是已经被验证可行的哪些坑是大家踩过之后不太愿意写在论文里的。不管你是在校学生想找研究方向还是工程师想评估这个工具能不能进工作流读完这篇文章你应该能建立起一个完整的判断框架。1. text-to-cad项目到底在解决什么问题1.1 从一句话到三维模型真实需求场景在制造业和设计行业大量的三维建模工作其实不是“创造性设计”而是“把别人嘴里的需求翻译成几何”。结构工程师拿到一个电机端盖的草图描述机械设计工程师照着供应商给的接口尺寸画连接法兰这些工作本质上是信息转译不是艺术创作。text-to-cad瞄准的正是这个环节。一个典型的场景是这样的你正在和客户开电话会客户说需要一个铝合金支架底板上四个M6通孔孔距60乘40侧面伸出一个耳朵耳朵上开一个长腰孔。这种描述在工程沟通里每天都在发生。如果有一套工具能直接把这个自然语言描述转成可编辑的CAD文件你省下的不是画图那两分钟而是避免了一次完整的“听漏细节—返工—再确认”的循环。这个价值在实际项目里比单纯画得快更大。还有一类高频场景是概念方案的快速迭代。工业设计师在前期要做几十个形态对比每个形态的差异可能只是某个特征的尺寸或者位置。传统做法是每个方案建一次模或者用参数化模板去驱动但模板的适用范围有限。用自然语言驱动生成的好处是你可以像和同事沟通一样和工具对话把孔的个数从四个改成六个把筋板的厚度从三毫米改成五毫米。这种对话式的修改方式会让设计探索的边际成本大幅降低。1.2 为什么不能直接套用通用3D生成模型很多人会问一个问题现在AI生成图片、生成视频都已经这么成熟了为什么不直接用类似的技术生成三维模型这个问题的答案恰恰是text-to-cad这个方向存在的根本原因。通用3D生成模型比如基于扩散模型的方案擅长生成的是“看起来像”的几何这些几何在视觉上很漂亮但本质上是一堆三角形面片。放到制造业的语境里这种模型完全没法用——它没有厚度、没有配合面、没有孔轴配合的尺寸公差更不能被CAM软件识别为可加工的实体。你不可能把一个用扩散模型生成的花瓶直接丢给数控机床去加工因为它根本不是严格定义的几何实体。CAD领域的核心语言是边界表示B-rep和构造实体几何CSG。这两个概念听着专业实际理解起来不算难B-rep就是精确描述一个实体的面、边、顶点以及它们之间的拓扑关系STEP文件就是这个东西CSG则是用球、圆柱、方块这些基本体素通过布尔加减组合出复杂实体。工业和工程领域的下游工具链从仿真到加工到3D打印切片全都建立在这两种表示之上。所以text-to-cad项目的本质任务不是“生成几何”而是“生成能被制造链接受的结构化几何表达”。这个区别决定了技术路线不能只靠生成模型的视觉能力必须引入程序化建模、几何约束求解、特征识别这些传统CAD领域的工具箱。1.3 项目的技术包络和边界在哪里如果把text-to-cad看成一个黑盒系统它的输入端是自然语言描述输出端是CAD文件通常是STEP或者可以直接编辑的模型文件。黑盒内部要做的事情可以拆成四层第一层理解自然语言提取出实体、特征、尺寸、位置关系这些结构化信息第二层把结构化信息映射成建模操作序列第三层由几何内核执行这些操作生成精确的B-rep模型第四层做校验和质量控制确保生成的模型没有破面、没有干涉、尺寸合理。这四层每一层都有独立的技术挑战。第一层考验大语言模型对工程语义的理解能力注意不是泛化的语言理解能力而是对“均布”“沉头孔”“过渡配合”这类工程术语的精确语义把握第二层考验的是如何把离散的建模动作组织成正确的顺序先画什么后画什么哪些特征互为基准第三层相对成熟因为有OpenCascade这样的开源几何内核问题是LLM生成的建模序列很难一次就合法第四层则是最容易被低估的工业级CAD模型的准确性要求非常高差0.1毫米可能整个零件就废了。这四个层面的技术组合在一起才构成一个完整的text-to-cad项目。下面我逐一拆解每个环节的设计思路和实操要点。2. 核心技术方案与设计思路拆解2.1 为什么要选择程序化建模作为中间表示text-to-cad项目最关键的一个决策不是选哪个大模型而是选择什么中间表示。这个决定直接决定了整个系统的下限。目前主流路线无非三条直接生成网格、直接生成B-rep参数、生成程序化建模代码。第一条已经被否掉了原因上一节说过——网格不是工程实体。第二条理论上最优但B-rep的拓扑和几何耦合极其复杂让模型直接输出一个合法的B-rep现在的技术还做不到稳定。第三条是当前被验证最可行的一条路。程序化建模的含义是用一段可执行的代码来定义模型。你写一段Python脚本调用CadQuery库或者写一段OpenSCAD指令脚本执行后几何内核会计算出一个精确的实体模型。文本生成CAD的任务就转化成了文本生成代码的任务。为什么要绕这么一道弯因为代码本身就是一种结构化、可校验、可修正的表示。生成的代码如果有语法错误编译器会告诉你如果逻辑有误运行时会报错即使生成了一个能跑的模型你也可以通过修改代码里的参数来微调。这个思路最巧妙的地方在于它把“生成不可控的几何”变成了“生成可纠正的程序”。大语言模型在代码生成上的能力已经被验证得很充分而且代码生成有天然的自动反馈信号——代码能不能跑通模型能不能成功导出这些都是确定性反馈可以用于自我纠错和迭代优化。这也意味着text-to-cad系统可以像软件工程一样构建文本解析、代码生成、编译执行、测试验证每一步都是工程化的。2.2 参数化建模APICadQuery和OpenSCAD各有什么门道确定“代码驱动几何”这个方向之后下一个选择是用什么建模库。目前的方案基本上是两派CadQuery派和OpenSCAD派。我两个都重度用过对它们的差异体会很深。CadQuery是一个基于Python的库底层是OpenCascade内核建模语义非常接近传统CAD软件的操作习惯。你在CadQuery里画一个带孔的法兰思路是先拉伸一个圆柱底座再选中顶面打孔孔的位置用极坐标阵列来定义。这种“先画草图-再拉伸-再打特征”的方式和人类工程师的操作逻辑高度一致因此生成出来的模型更容易被下游工具链接受。CadQuery支持直接导出STEP格式这是制造业通用的标准交换格式不谈情怀只凭这点它就更适合做工业级text-to-cad的输出端。OpenSCAD则完全是另一个思路。它用一套函数式语言描述几何一切模型都是通过体素组合和变换生成的。它的表达极其简洁非常适合描述回转体、螺纹这类通过几何变换生成的形态。它的缺点也同样明显没有传统CAD的参数化特征树概念生成的模型不好后期编辑导出STEP的流程也比较绕。我的经验是这个选择不必过于纠结初创项目可以用CadQuery为主OpenSCAD的独特形态描述优势等遇到特定几何时再补充。2.3 两层架构先规划再执行的解耦设计一个成熟的text-to-cad系统不会尝试让模型一步到位直接输出最终代码。实际部署中更稳定的方案是两阶段架构先有一个文本规划器把用户的自然语言描述拆解成结构化的建模计划再由一个代码生成器把计划翻译成可执行的建模脚本。为什么非要拆开因为“理解用户意图”和“生成正确代码”是两种完全不同的能力要求。第一步你需要大模型像一个有经验的工程师那样理解需求中的隐含信息比如用户只说了法兰的外径没说法兰的厚度但根据应用场景可以合理推断一个默认值这是语义理解和领域知识的活。第二步需要的是严格的代码生成能力模型必须保证API用法正确、参数之间不冲突、布尔操作顺序合理这是程序合成的活。把两个任务拆开以后每个子任务都可以用更专业的手段去优化。规划器输出的结构化结果本身就是一个清晰的中间产物这个产物一旦独立出来好处是巨大的第一你可以在规划阶段插入人工审核及时拦住完全跑偏的意图理解第二规划结果可以被不同代码生成器复用比如你既可以将它映射到CadQuery也可以映射到FreeCAD的Python API甚至映射到SolidWorks的VBA宏第三问题定位更清晰模型输出烂了你能准确判断是理解错了还是翻译错了。2.4 严格的几何验证代码通过不等于模型正确程序化建模给你最大的礼物是可验证性但这个礼物的价值要靠你自己建一套严格的验证体系来兑现。文本转成代码只是走了一半的路另一半是确认这段代码生成出来的几何真的符合需求描述。验证要分三个层次去做。第一层是语法和运行时验证代码能不能成功执行、能不能不报错完成建模这是基础门槛。第二层是几何有效性验证模型有没有破面、有没有不闭合的实体、有没有自交的拓扑这需要调用几何内核的检查功能CadQuery里可以直接调用OCP的检查工具或者用Trimesh做网格层面的封闭性检查。第三层是语义验证也是最难的一层生成的法兰确实是圆形吗六个孔是不是真的均布孔的直径是不是8毫米模型和需求之间的语义对齐在当前的自动化维度上只能做到部分验证比如检查关键尺寸是否符合预期值。第三层验证做不完美是现实的但系统不能因此就摆烂。一个务实的做法是让模型在生成代码的同时也输出一份“模型属性清单”里面声明了主要特征的尺寸和位置然后用一个独立的程序去查询生成模型的B-rep数据逐一比对清单里的量是否匹配。这个机制不能发现所有问题但能拦截掉绝大多数灾难性错误。我的实测经验是加上这一层校验后系统的可用性会有一个质的提升从“偶尔能用”变成“大多数情况下可以信任”。3. 数据、模型与评估让系统真正变得可用3.1 数据从哪来合成数据是起点人工标注才是上限text-to-cad系统要训练首先得有大量“自然语言描述-CAD模型”的配对数据。这个数据的问题在于互联网上没有天然存在的大规模工程标注数据你不可能像爬网页一样爬出几百万个文本和CAD文件的对应对。所以这个领域的发展注定极度依赖合成数据。合成数据的基本套路是先确定一批基础零件模板法兰、支架、轴套、盖板这类常见机械零件对模板做参数化随机化在合理范围内随机生成几千甚至几万个实例然后用程序把这些参数自动翻译成自然语言描述。模板描述可以做到高度确定性一个法兰固化了圆的直径、孔数、孔直径、是否沉头这几个属性就用模板文本把每个参数填进去。这种方法做出来的数据干净、可控、成本低。但合成数据的缺陷同样显著语义多样性极差。模板生成的描述就那么几百种句式和词汇模型在这个数据上训练会严重过拟合到模板的语言风格上。真实用户的描述千奇百怪什么“帮我做一个中间有个大洞的圆形垫片周围要一圈小洞”这种口语化表达在纯模板数据里根本见不到。解决这个问题有几个思路比较前沿的是用大模型做数据增强让LLM把模板描述改写出口语化、多样化的版本只改变说法不改变含义再高阶一点的做法是反向合成让模型根据描述反推CAD模型再通过对比反推结果和原始模型的差异来筛选描述有效的样本。3.2 模型选型通用LLM微调还是专用小模型确定了数据和中间表示就到了模型架构选择的环节。这个环节现在的答案比两年前清晰很多。早期方案的思路是训练一个端到端的专用模型从文本直接生成建模代码。这种方案在固定小规模的API集上表现尚可但模型的可扩展性很差一旦增加新的建模能力就需要重新训练数据。现在的主流做法是站在巨人的肩膀上在通用大模型的基础上做主谓宾式的微调让基座模型理解“文本到CAD代码”的映射规则而不是从零学会如何建模。具体选型时有个权衡点值得展开说。如果追求稳定可控选择开源基座模型比如当前主流的Qwen系列、Llama系列、DeepSeek系列做LoRA低秩微调成本低、可控性高数据可以完全私有化适合企业自部署场景。如果追求上限能力直接调用商业闭源大模型的API然后在提示词层面和输出校验层面做约束这种方法的好处是模型本身的工程语义理解能力非常强缺点是每次调用都有成本而且对网络环境的依赖会限制它在车间和制造现场等离线环境的部署。我的建议是项目早期用商业API验证流程跑通以后再考虑用验证过的数据蒸馏训练开源模型做私有化部署。这符合软件工程里“先用起来再优化”的原则也避免了把资源浪费在方向还没验证清楚的阶段。3.3 评估体系几何相似度、工程可用性、文本一致性的三角做任何研究或工程项目没有评估体系就是闭眼开车。text-to-cad的评估比纯视觉任务要复杂得多因为维度多、标准严。我这里只讲我自己实际使用下来最有效的三套指标组合。第一组合是几何相似度指标。把生成模型和参考模型都转成点云或者网格然后计算倒角距离Chamfer Distance或者Earth Mover距离。这类指标评估的是“整体形状像不像”。但形状像不一定工程上合格所以必须叠加第二层指标工程可用性指标。这包括模型是否是一个闭合的实体、是否满足最小壁厚要求、有没有尖角或微小的碎面、特征尺寸是否落在合理的工程范围内。这些指标需要调用几何内核和基本的制造性规则去验算。第三层是最容易疏忽但实际最关键的指标——文本描述一致性。这个指标不能靠模型自己判断需要独立执行让人工或一个自动程序把生成模型的属性提取出来例如“孔的直径 8.2毫米孔数 7”再和原始文本描述里面的要求逐一比对。我见过太多在几何层面完美但在语义层面完全跑偏的生成案例——模型长得很好看但压根不是用户要的那个东西。三套指标联合使用才算搭起一个勉强合格的评估框架。4. 实操笔记从零搭建一个最小可用系统4.1 工具链选型摸清家底再动工纸上谈兵讲完了分享一套我自己从零搭起来的最小可用系统。选型不是唯一的但这条路是我反复折腾后确认的最短路径。组件清单不复杂硬需求只有三个一个LLM作为代码生成器我用的是可以本地部署的开源模型方便调试和做实验、CadQuery作为建模内核、Trimesh作为轻量级的网格检查和可视化工件。操作系统建议用Linux环境因为开源几何库在Linux下的兼容性最好。Python环境用Anaconda管理避免依赖冲突。CadQuery的安装本身不难注意版本要选2.x以上这个版本使用OpenCascade 7.x内核性能和稳定性比老版本高不少。环境准备这一步我踩过最大的坑是OCCOpenCascade Core库的编译冲突。如果你之前装过游戏引擎或者机器人仿真相关的库比如pybullet极容易把OCC的依赖库版本搞乱。建议在干净的虚拟环境里安装如果要偷懒直接用Docker镜像也是一个稳的选择。4.2 核心流程从文本到STEP文件的一次穿越整个最小系统的核心流程在代码层面只有四步。第一步用提示词约束LLM输出CadQuery代码。关键技巧是提示词里必须放进CadQuery的标准代码框架和API白名单明确告诉模型哪些方法可用、坐标系怎么定义、用毫米作为默认单位。模型是概率生成器你不约束它就会天马行空编造API。第二步把生成的代码放到隔离的Python执行环境里跑起来。用exec加超时机制控制执行制造一个全局命名空间的字典传入函数执行结束后检查模型对象是否生成成功。这里要特别注意直接exec任意代码是有风险的我在实验环境可以这么做生产环境必须做代码沙箱至少要把文件系统写权限锁死、网络全部禁用、内存做上限限制。第三步模型生成以后立刻导出STEP格式作为交付物。CadQuery导出STEP的API非常简单一个命令就搞定。但导出前必须做一次质量体检用ShapeFix工具修复微小面误差用BRepCheck检查模型的有效性。这个体检不是可选项是必选项因为LLM生成的代码在边界情况的处理上经常会产生非流形边或者非常细微的裂缝。第四步可视化确认。把STEP转成三角面片用Trimesh加载并渲染出一张快照这步看起来多余但对排查问题有巨大帮助。模型是不是用户想要的一眼就看出来了比任何自动指标都直接。4.3 参数化设计的关键让修正闭环只做单次生成的工具价值有限真正让它进入工作流的是参数化修正能力。要让用户能说“再改一下孔径变成10毫米”系统就必须能追踪并修改生成的代码。实现这个能力的关键是在生成阶段就要求LLM把关键尺寸抽取成独立的变量并且统一放在代码顶部的参数区。也就是说提示词里强制规定输出代码的规范格式所有尺寸参数集中定义成一个Python字典后面所有的建模步骤都引用字典里的值。这样做的好处是当用户提出修改需求时你不需要重新跑一遍完整生成流程只需定位到参数字典里的对应键修改值再执行一轮建模和导出。这个设计非常简陋但极其实用。我在项目里靠这个机制就已经能覆盖掉大概百分之六十的持续修改需求而且体验意外地流畅。后续可以升级的方向是让系统自动把参数和自然语言里的语义一一对应比如建立一份映射表把“孔径”这个词映射到参数名hole_diameter这样修改需求就可以走全自动路径连人工干预参数键值都不用了。4.4 常见问题与排查技巧实录这部分是我真正想倾囊相授的实操心得因为这里面每一个问题我都在调试过程中反复遇到过。卡在第一步最常见的问题是模型生成CadQuery代码时臆造API。比如它可能会生成一个query_box这样的并不存在的方法。排查方法是明确API白名单同时让输出的代码经过AST语法树解析做静态检查不匹配的API直接判为非法重跑。这个技巧能把生成成功率提高十几个百分点。卡在第二步的问题是几何内核层面布尔运算失败。两个实体做差集时如果接触面共面OCC内核有时会计算出错误结果导致模型消失或生成碎片。解决办法是在生成代码的提示词里强制加入一条规则所有需要打孔的圆柱体长度必须比被穿过的实体的厚度至少大0.5毫米。这个微小的工程直觉放在提示词里比事后做任何几何修复都更高效。卡在第三步的问题是导出文件尺寸异常。有一次我导出的STEP文件在CAD软件里打开尺寸整体放大了25.4倍。这个诡异问题最后查到根源是代码里用了英寸作为单位而CAD软件默认是毫米。排查其实很简单在生成模型阶段就做一个包围盒尺寸合理性检查如果明显超出正常范围比如一个支架长了两米五好直接报警让用户确认是否有问题。5. 我对text-to-cad未来走向的一些看法5.1 短期内最可能落地的场景坦白说指望text-to-cad立刻全面替代人工建模是不现实的但从我接触到的产业需求来看它在两个方向上商业化落地的确定性非常高。第一个方向是面向非专业用户的设计入口。很多创新场景里的用户有产品想法但不会用CAD软件——创客、非遗工艺设计师、大学生科创团队、小工厂的老板。他们脑子里有清晰的造型概念但被软件门槛挡在了门外。用自然语言描述自己的需求让系统给一个“能看能改能送去加工”的初始模型这个体验对这类用户是革命性的。第二个方向是制造业的询价与标准化前置处理。供应商收到客户的采购询价时客户只给了一段文字描述和几个关键尺寸。过去要人工建个毛坯模型再去报价评估加工可行性现在用text-to-cad先快速生成一个初步模型配合自动化报价系统做成本评估和工艺可行性分析能让售前响应速度快一个量级。这个应用不追求模型设计得精巧只追求快速表达客户意图刚好落在当前技术能力范围之内。5.2 中期演进从单零件到装配体当前text-to-cad的处理对象基本锁定在单零件级别一旦进入几十上百个零件组成的装配体复杂度会指数级上升。但我判断这个升级路径大概率不是让模型直接生成整个装配体而是先走“分件生成约束装配”的路线。所谓分件生成指的是系统根据用户对装配体功能的描述先独立生成每个零件再通过定义装配约束贴合、对齐、同轴、固定把零件组装成装配体。难点在于生成每个零件的时候就必须为配合关系预留正确的接口尺寸——轴和孔的直径要配套、法兰螺栓孔的位置度要对齐。这意味着文本理解必须拆解出装配级的信息流先提取各零件间的空间关系和尺寸约束再交给单体生成器执行。这个路线的可行性已经有了初步验证的基础因为LLM在长上下文和关系推理上的能力一直在进步。未来一年到两年内业界很有可能会出现面向简单装配体的端到端demo从效果上足够惊艳到推动更多工业场景里试用。5.3 向可制造性约束的延伸text-to-cad的下一个关键升级是让系统在生成模型前就具备制造工艺约束意识。比如一个零件被定义需要使用注塑工艺成型那么系统生成模型时就自动避开倒扣结构、保证脱模角不小于两度、壁厚控制在合理范围内这样模型出来就可以直接跟模具厂对接。这条思路的本质是把manufacturingability的要求从后置检查挪到前置设计约束。现在大多数项目都是先让模型随意生成生成完再做可制造性检测检测不过就重新生成完全靠循环试错碰运气。这种模式浪费大量算力和时间而且几乎不可能保证每次都能命中。正确的做法应该是像人类工程师一样在设计约束里就避开不合理的元素。技术细节上这意味着text-to-cad系统的文本解析模块不仅要提取几何语义还要提取工艺语义同时把工艺约束转换成参数字典里的硬性限制例如壁厚参数严格限制最小值。这个方向目前刚起步但我认为它才是让text-to-cad从“有意思的玩具”变成“值得投资的引擎”的关键一跃。写在最后的几句实在话做了这么久的text-to-cad相关实验我最大的体会是这个方向的技术难度不在模型架构多精妙而在把自然语言理解、程序合成、几何计算、工程规范这四摊原本互不相干的事情拧成一股绳。你在这个项目里需要的不只是懂机器学习还得能坐得住去啃CAD内核的文档去理解什么是拓扑有效性去容忍一版又一版的代码在布尔运算上莫名其妙地翻车。如果你也想在这个方向做点什么我给三个具体建议。第一先花一个星期把CadQuery的示例全部手敲一遍把它的建模风格刻进肌肉记忆这一步不白费你后面写提示词、排查代码都会受益。第二不要一开始就追求复杂几何老老实实把法兰、支架、轴套这类基础零件做到高成功率基础零件的稳定输出是系统可信度的地基。第三花大力气搭建你自己的验证和反馈管线让每一次失败的生成都能留下可供追溯的中间状态调试效率会翻倍。我始终相信让机器理解工程师的语言而不是让工程师学机器的语言这个方向本身是无可争议的正确。text-to-cad这条路很长但现在恰恰是最值得动手的窗口期。