1. 项目概述当“一句话”变成“一张图纸”做计算机辅助设计的人每天面对的无非三件事建模、改型、出图。而text-to-cad这条技术路线初衷特别直接——让设计师把脑子里的话变成CAD文件而不是在软件里跟坐标系、草图约束和布尔运算较劲。说白了它要解决的问题是“从自然语言到结构化几何”的转换不是渲染一张图而是真生成可以用来加工、装配、仿真的模型文件。这个方向之所以能火起来有个很现实的原因现在的企业CAD数据存量庞大但大量旧图纸、历史模型是没法直接复用的需要设计师重新建模。另外在产品概念设计阶段很多结构还没定先拿文字表达能力快速生成几个候选方案比手动拉草图快得多。text-to-cad想做的就是把“理解需求”这件事交给算法把“表达几何”这件事也交给算法人只负责说清楚要什么。我接触这个领域一段时间后最大的感受是它跟text-to-image完全不是一回事。图片生成错了可以“再抽一次卡”CAD模型错了轻则尺寸对不上装不起来重则加工出废品。所以这个方向的核心不是模型有多炫而是输出是否可编辑、参数是否正确、装配是否合理。这篇内容我会拆开讲清楚整个技术链路、一些能落地的方案以及那些文档里一般不会写、但实际操作特别容易踩的坑。1.1 这个技术到底适合谁用先说说受众。如果你是完全没接触过CAD的小白只想“用文字生成个模型”那要提前打个预防针这个方向目前还做不到随心所欲地生成复杂装配体。但你用它能快速拿到基础外形、做概念验证、甚至给后续的拓扑优化当输入。如果你是已经在用SolidWorks、Fusion 360、FreeCAD这类工具的工程师那text-to-cad的价值会大很多。比如标准件库检索、加工工艺方案策划、非标零件的前期构型这些场景里你需要的不是“一张好看的渲染图”而是带参数、带特征历史的真实模型。一个能直接改尺寸、换材质的生成结果远比高精度网格有用。如果你是搞算法研究的那这个方向的挑战很有意思它混合了大语言模型、三维几何处理、参数化建模、程序化生成这几个领域。语言模型负责“听懂”几何内核负责“画对”中间还有一层约束求解器在兜底。我后面会展开讲这个链路。2. 整体设计与思路拆解语言模型不是画图工具是“接口转换器”刚开始研究text-to-cad时很多人直觉上觉得“这不就是用语言模型生成一个三维文件吗”于是想直接让大模型输出STEP或者BREP文件。实际试过就会发现这条路走不通。CAD文件不是文本STEP文件虽然本质是文本但中间涉及的拓扑关系、面边连接、曲线参数化精度根本不是自然语言模型能稳定“编”出来的。所以现阶段比较靠谱的思路是把语言模型当成一个“接口转换器”。它并不直接生成几何而是干两件事第一理解用户输入里有哪些关键要素——零件类型、大致尺寸、相对位置、特殊约束第二将这些要素转成一段结构化指令交给真正的几何内核去执行。执行层既可以是Python脚本也可以是FreeCAD的API还可以是OpenCASCADE的命令序列。这就是为什么现在很多text-to-cad的实现看起来像是一个“自然语言到代码”的翻译器而不是一个“文本到模型”的生成器。这个设计背后的考量很清晰把“不确定性”尽量锁在语言理解层把“确定性”保留在几何内核层。语言模型理解错了只是指令写得不对重写即可如果让语言模型直接碰顶点坐标和面片连接那生成出来的东西很可能是一团破面修都没法修。2.1 我为什么推荐“Geometric Program Synthesis”这个框架把话说回来目前我自己在实践中最认可的架构是“几何程序合成”Geometric Program Synthesis。这个思路最早是从CAD程序化建模工具那边借鉴过来的。传统CAD软件里有个叫“设计历史树”的东西每一步拉伸、旋转、倒角、阵列都被记录下来。Geometric Program Synthesis把这种历史树反过来用先把几何生成过程拆成一系列基础操作然后让语言模型去预测这些操作序列最后用操作序列驱动内核重建模型。听起来复杂但落地时反而简单。举个例子用户说“一个直径30mm、高度50mm的圆柱体顶部倒圆角R5”合理的操作序列就是新建圆柱直径30高度50→对顶面边线执行倒角半径5→导出BREP。语言模型只需要输出这段操作脚本执行交给CAD内核完成。这样做有三个明显优势。一是可解释性强用户能看得到每一步操作出了问题可以定位在哪一步。二是可编辑性好生成的结果保留了完整历史特征后续改尺寸、换倒角值都很容易。三是能利用现有CAD内核的全部能力不需要另造一套几何引擎OpenCASCADE、FreeCAD内核都能直接驱动。2.2 数据与表征为什么“文本程序”的配对数据才是关键搞算法的人都知道数据和表征方式往往比模型结构更影响上限。text-to-cad现在最大的瓶颈其实不是模型不够强而是缺少高质量的训练数据。网上有大把“标题STL模型”的数据但STL是网格不是CAD模型顶多用来自动生成三视图没法用来学参数化建模。所以很多研究组转向了“伪合成数据”这条路先写一批已知参数的CAD生成脚本跑出模型再反推生成对应的描述文本。听起来简单做起来工作量很大——一个脚本要覆盖多种参数组合文本描述还得多样化不能千篇一律。我自己在做数据时常用一个技巧把“文本描述”按粒度分级。粗粒度描述整类外形比如“法兰盘六个螺栓孔”中粒度描述关键尺寸比如“外径100毫米内径50毫米厚度12毫米”细粒度描述局部特征比如“螺栓孔均匀分布在直径80毫米的圆上”。分级的好处是训练时模型先学会稳定的结构关系再慢慢学参数变化。这种方法比一股脑塞文本和模型对让模型自己摸索要稳得多。3. 核心细节解析与实操要点一条可以跑通的完整链路聊完思路来点实际的。我把自己近期搭建的一套text-to-cad原型拆成四层输入解析层、程序合成层、内核执行层、验证反馈层。每一层都有对应的技术选型和踩坑经验。输入解析层用的大语言模型负责把自然语言转成JSON形式的结构化描述。这个JSON不直接包含几何数据而是包含实体类别、核心参数、特征关系和约束条件。我强烈建议在这一步做两件事一是让模型输出“不确定性标记”比如当用户说“大致50毫米”时到底该取50还是45让模型自己标个置信度二是让模型输出“冲突检测结果”比如同时要求“壁厚2毫米”和“内腔直径和外形直径差1毫米”这俩约束一冲突模型要在JSON里报出来而不是擅自选一个。程序合成层是整条链路的核心它输出一段调用CAD API的Python脚本。这个脚本必须要做模块化不能是直来直去的一堆函数调用而是分解成函数create_base_profile、extrude、boolean_cut、fillet_edges等等。这样做的好处后面会体现如果生成结果不符合用户预期你可以只改脚本里的某一两个参数而不是推倒重来。内核执行层我用的是FreeCAD的Python API原因也很简单开源、跨平台、带完整的OpenCASCADE几何内核。SolidWorks和Fusion 360虽然也有API但都需要商业授权不适合放在开源原型里。验证反馈层最容易被忽略但对实际使用特别重要。因为语言模型生成的脚本极有可能出现“布尔运算失败”“轮廓不闭合”“尺寸超出合理范围”这类问题。执行完脚本后要用内核自带的检查器做几何有效性校验比如检测实体是否有效、面是否闭合、是否有多余的边或顶点。如果校验不通过把错误信息反馈给语言模型让它重新生成脚本。这个“生成→校验→反馈→再生成”的循环是提高成功率最有效的手段之一。3.1 接地气的实操用text2cad工具链完成一次生成这里我想以一个能实际跑起来的工具链为例给个锚点——libre3d/text2cad这是一个将大语言模型接入FreeCAD后端的开源项目可以用来验证上面那套思路的完整闭环。第一步把项目拉下来装好FreeCAD的Python绑定库确认能import FreeCAD不报错。第二步配置LLM接口实际项目里一般支持OpenAI格式的API你可以把本地部署的开源模型地址填进去。第三步运行一条指令比如“create a flange with 6 holes, outer diameter 120mm, inner diameter 50mm, thickness 15mm”。这条指令会经历我上面说的四层解析层抽出法兰、6孔、外径120、内径50、厚度15程序合成层写出一段调用FreeCAD Part模块的脚本内核执行层真的建出实体验证层检查实体有效性。整个过程在真实运行时大约要花一两分钟大头都在分词和脚本生成上几何内核执行本身很快。还有个折腾点值得提醒这个项目默认用的是文本生成接口但模型返回的JSON内容经常把代码片段包在markdown代码块里。解析的时候一定记得把python和这些标记剥掉不然脚本直接抛语法错误。这个问题我遇到过不下三次每次都是因为换了模型API后返回格式变了导致的。3.2 单位制、坐标系和布尔运算三个最容易被忽略的致命细节以我做了这么多例子的经验text-to-cad最容易出问题的不是模型而是那些“看起来很简单”的几何细节。第一个坑是单位制。CAD工具内部一般用毫米存储但语言模型对“厘米”“英寸”这类单位的换算经常出错。用户说的是1 inch解析层可能直接当成25毫米用了实际应该换成25.4毫米。所以输出脚本里一定要显式写单位换算最好在JSON里就统一成毫米。第二个坑是坐标系方向。在CAD里拉伸和旋转对方向非常敏感。沿着正Z轴拉伸还是负Z轴拉伸如果语言模型理解错了零件会反着装。而反了的零件在视觉渲染图上有时根本看不出来只有进装配环境或者做干涉检查时才暴露。我建议脚本生成时所有方向参数必须明确传vector变量不要依赖默认方向。第三个坑是布尔运算的输入条件。做布尔剪切时被剪切体和剪切工具必须满足一定条件比如两者要实际相交、剪切工具不能完全包含被剪切体、拓扑不能退化。语言模型生成的脚本经常会忽略这些前提导致最后内核报错或者得到无效实体。我自己会在脚本里加一个预检查在执行布尔操作前先计算两个实体的包围盒是否相交不相交就直接报错回滚这也避免了一大堆看不到摸不着的破面问题。3.3 从网格到CAD为什么“能看”不等于“能用”新接触这个方向的人容易问一个问题我让zero123直接生成一个目标视角的图再走三维重建不就得到模型了吗这条路确实能拿到模型但拿到的大概率是网格mesh不是CAD能用的实体solid。网格模型的本质是一堆三角形面片看起来真实但转到CAD软件里你会发现它既不能编辑特征也不能精确测量更没法直接丢给CAM做加工编程。很多开源方案诸如ImageDream之类的多视角扩散生成方案输出也是这类型网格或者带有粗糙法向场的点云。那它们在CAD场景里能干嘛合适的位置是“前置参考”就是先用扩散模型把外形“脑补”出来看一眼大概架构对不对然后再由CAD参数化建模把结构重画一遍。把网格当参考、把程序化建模当最终交付是我目前认为比较务实的组合方式。另外做CAD时还有一个网格模型不会遇到的硬约束拓扑正确性。网格可以有非流形边可以有洞渲染器照样能画出来因为GPU不在乎这些但CAD内核做布尔运算、倒角或者抽壳时非流形结构直接会让内核崩溃或者计算结果诡异。所以如果你确实想靠重建管线进入CAD流程先跑一遍OpenCASCADE的修复工具比如净化和统一法向这是绝对的必做步骤。4. 完整方案选型对比从视觉扩散到程序化生成谁更适合生产业界在text-to-cad上的路线粗分其实是这么几派。第一派是“图像扩散派”代表就是zero123、ImageDream这类。它们的思路是先用文本或图片生成多视角渲染图再做三维重建。优点是对模型外形刻画很生动尤其适合自由曲面、有机形态比如人体工学手柄、雕塑外形。缺点我刚才已经说了——几何精度差拓扑混乱几乎没法直接进CAD链。第二派是“检索变形派”通过文本语义检索已有CAD零件库再把检索到的模型做形变适配。优点是可编辑性强、几何质量有保证毕竟都是从真实CAD模型来的。缺点是只能生成库内已有的类别遇到新结构直接抓瞎。这一派适合做标准件选型这种场景不适合做创造性设计。第三派是“程序化合成派”也就是我前面重点讲的Geometric Program Synthesis。这派的可控性和可编辑性最好适合做有明确结构的机械零件比如法兰、支架、箱体这些。当前一些知名的工作比如用大语言模型直接生产FreeCAD宏也就是多数情况下text2cad实际做的事就能归到这一派。它的局限在于复杂曲面和自由造型能力偏弱因为语言模型难以描述那种“说不清参数”的形状。第四派是“隐式神经场派”用神经辐射场或者符号距离场做基础表征然后试图抽取可编辑的曲面。这一派学术上很热闹但离生产还远。SDF抽取出来的曲面要么过度平滑要么精度不够而且很难直接转成NURBS和BREP。如果纯粹出于兴趣折腾可以但作为项目底子我暂时不推荐依赖它。4.1 最终选型建议按场景反推方案而不是按方案反推场景这里我给几个比较实操的选型建议。如果你的需求是机械非标件、结构件、标准面板直接锁定程序化合成派用大语言模型生成脚本驱动FreeCAD或OpenCASCADE可靠性上限最高。如果你的需求是外观造型、曲面壳体、3C产品外形探索可以考虑图像扩散派做外形探索但要有心理准备后面还是要人工重建成参数化模型。如果你的需求是常见零件比如螺栓、轴承、法兰盘这些直接上检索变形最省事没必要让语言模型每次从头生成一遍费钱费时间还容易出错。如果你的需求是带复杂装配关系的比如齿轮箱内部、四连杆机构这些别指望一次生成到位目前主流做法还是先生成单个零件再做装配约束求解语言模型只能帮你省下单个零件的建模时间。我还会额外提醒一点任何方案在正式投入前先建立一个“验证标准”。比如你能不能做到生成的零件尺寸全部符合公差范围、装配时不干涉、STEP导出后能被CAM软件正确识别。没有这样一个标准再花哨的演示都只是demo撑不到落地。5. 实操过程与核心环节实现源码级别的拆解下面这段我直接拆一段实际可用的text2cad生成脚本尽量还原真实执行链路也方便你对比自己的实现。以“生成一个底板长100毫米宽60毫米高10毫米四角各有一个直径8毫米的沉头孔”为例完整链路大体长这样。第一步LLM解析输出会是这样{ object: base_plate, operations: [ {type: box, params: {length: 100, width: 60, height: 10}}, {type: hole, params: {diameter: 8, count: 4, positions: corners, offset: 8}} ] }第二步程序合成器拿到这个JSON后翻译成FreeCAD脚本。核心代码大概是这样import FreeCAD as App import Part from FreeCAD import Base doc App.newDocument(base_plate) box Part.makeBox(100, 60, 10, Base.Vector(0, 0, 0)) # 计算四角位置留出8毫米的安全间距 hole_positions [ Base.Vector(8, 8, 0), Base.Vector(100 - 8, 8, 0), Base.Vector(8, 60 - 8, 0), Base.Vector(100 - 8, 60 - 8, 0) ] for pos in hole_positions: hole Part.makeCylinder(8 / 2, 20, pos, Base.Vector(0, 0, 1)) box box.cut(hole) solid Part.Shape(box) Part.show(solid) doc.recompute()这段脚本虽然简单但里面有三个细节值得说明。一是孔的中心高度为什么要设成20毫米因为沉头孔需要通过实体如果只给和板厚一样的10毫米布尔剪切可能恰好与顶面共面导致奇异性错误多给点余量让圆柱贯穿布尔操作更稳定。二是孔的位置用了留边8毫米这来自CAD工程常识——孔边缘到板边缘至少要留一个孔径的距离否则结构强度不够。三是坐标向量全是显式写的没依赖默认值。第三步执行后的几何验证。这个环节我建议别只信内核自己的有效性检查还要做一个“语义验证”检查生成的布尔特征数量、孔的数量、实体总体积是否在预期范围。孔数量可以数切割体的残片数量体积可以用Part.getVolume()。“底板的体积计算先算整体盒子体积 100×60×1060000立方毫米四个直径8毫米的圆柱体积 4×(3.14159×4×4×20)约4021立方毫米两者相减接近55979立方毫米。如果计算结果差很多那大概率是布尔运算里出现了孔没打通或者多切了一个洞。”像这样把预期体积作为一个参考值写进验证规则里能有效防止语言模型跑飞。说实话这一步的工程价值比模型本身的参数微调还大。5.1 把“用户反馈”融入闭环第二代text-to-cad该干的事我见不少开源项目和论文生成的演示视频特别炫但实际用起来体验很差核心原因就是没有把“用户反馈”吸收进生成循环。用户说“这个孔太靠近边缘了”机器还得重新理解这句话而不是直接基于上一次生成的参数做局部修正。现在许多text2cad的迭代版本已经开始完善这类交互它会追问“孔偏移位置需要改一下吗请给出新值”或者直接让模型内嵌一个参数调整循环。我建议你如果自己做可以设计一个“参数记忆”机制。把第一次生成时解析出来的JSON和脚本中的关键参数存下来用户后续做修改时不需要重新跑全链路只需要基于记忆的参数生成一份“修改脚本”。这样既节省大量时间也降低模型出错概率。比如刚才的底板用户说“孔直径改成10”你只需要把hole_params里的diameter从8改成10重新执行一次布尔操作而不用让LLM重新解析“底板、沉头孔、四角”这些信息。这个增量式修正在实际使用中太重要了我甚至认为它比“第一次生成得有多漂亮”更能决定这个工具好不好用。6. 常见问题与排查技巧实录我在text-to-cad项目中踩过的坑这里我必须把那些“你真跑了才知道”的问题挨个列一下帮助各位少走弯路。第一个也是最高频的模型生成脚本时经常忘记把FreeCAD文档对象和实体对象分开。很多新接触FreeCAD的读者会误以为Part.makeBox返回的就是一个可显示的几何体其实它返回的是拓扑形状你还需要Part.show把它放到活动文档里才能看到和导出。如果脚本里漏了Part.show表面看执行不报错但工作台里空空如也。第二个坑是语言模型对“数量”词和“复数”概念的理解漂移。比如“四个沉头孔均匀分布在四角”模型有时会理解成“每个角上放四个孔”于是生成16个孔。我后来在解析层加了一个“数量一致性校验器”专门核对描述中的数量词和最终操作的次数少了或多了一律抛出警告宁可不执行也不要执行个错误结果出来。第三个坑是API版本不兼容。激进升级FreeCAD版本后它把一些API重命名或者标记废弃语言模型训练时用的API和本地跑的不一致生成的代码就会报AttributeError。这事特别烦因为它和模型本身没关系纯粹是版本漂移。我现在的方法是固定FreeCAD版本并在系统提示词里写明目标API版本和一段参考样例强制模型按样例风格输出。第四个坑是CAD导入导出格式的兼容性。用户要STEP文件你确实导出了但导出的STEP文件用别的软件打开发现零件是歪的或者法向量反了。这往往不是生成环节的问题而是STEP导出器对坐标系和单位转换处理得不严谨。导出前要把单位切成毫米坐标系清零时才不会莫名其妙加一个偏移。6.1 问题速查表从解析层到内核层的一次性排查手册这个问题排查表我建议直接打印出来贴在工位上。问题现象可能原因排查步骤解决方案脚本执行成功但无模型漏了Part.show调用检查脚本末尾是否将实体挂载到文档在关键建模操作后追加Part.show零件尺寸差几倍单位制解析错误检查JSON中的单位和换算系数在解析层统一成毫米并显式声明布尔剪切失效剪切圆柱长度不够检查剪切工具是否完全穿过被剪切体增加剪切体长度余量零件方向相反坐标系向量理解错误打印拉伸向量看看正负号显式传vector参数并做方向校验导入STEP后破面拓扑修复未执行导出前运行几何修复工具执行Part.refineShape后重新导出孔数量翻倍数量词理解漂移比对JSON中count和实际循环次数增加数量一致性校验器生成脚本报API错误版本漂移对比项目文档里的API版本固定依赖版本并锁定参考样例体积验证不通过布尔运算有残留体计算所有子实体体积之和用getVolume和实体数量做双重校验这些表里的内容都是我在实际调试中总结出来的其中有几条确实在项目里付出过不小的时间成本。尤其是“脚本执行成功但无模型”这一条如果不知道FreeCAD的对象机制你可能会非常迷惑明明代码没报错却什么都没生成换到FreeCAD的GUI里用宏跑一遍才恍然大悟。6.2 调试技巧把大语言模型当成“实习生”而不是“神仙”如果真的打算在项目里持续用这套方案我还有一个心态上的建议把大语言模型当成一个很聪明但偶尔犯低级错误的实习生而不是一个可靠的生产工具。这意味着你要给它清晰的工作说明书包括输出格式样例、不允许使用的API、单位换算表、操作顺序约束你也要给它反馈机制出了错要告诉它哪里错了让它下次改进。我目前在实际项目里维护了一份“给模型的工艺约束”文本里面固定写了几条所有长度数值必须以毫米为单位。布尔剪切体至少要贯穿目标实体2毫米以上。新生成的实体必须执行一次Part.refineShape。禁止使用未在样例中出现的FreeCAD API。这条提示词我直接塞到系统消息里成功率和稳定性都提升了不少。如果你正在被奇怪错误困扰先试试这一招很多时候比微调模型本身更管用。7. 延伸思考text-to-cad的边界与机会做久了你会慢慢发现text-to-cad真正能大幅落地的前提不是把“文本生成模型”这一环做到100%完美而是把“模型生成到生产可用”的中间链路全打通。自动标注公差、自动生成工程图、自动生成BOM表、一键对接CAM软件这些才是真实企业愿意付费的环节。单纯从文本到模型哪怕生成速度再快没有后半段对制造业的价值也就打了个大折扣。我自己还有一种判断未来两三年里text-to-cad的落地形态不会是“给个文字然后出一个完整装配体”这种全能型工具而是“给一段约束条件然后从已有模型库里检索并做参数化微调”这种精准型工具。前者太难后者离钱更近也更符合当前技术成熟度。所以如果你正在考虑选这个方向做项目无论你是做产品、做研究还是做技术选型我建议你先问自己一个反向问题用户真正需要的不是“生成模型”这个动作而是“把想法变成可制造零件”这个结果。从结果倒推你需要的很可能是一套集合了语言理解、程序化建模、参数校验、数据管理、工艺对接的综合系统而text-to-cad只是其中长得最高调的那块拼图。最后再分享一个小技巧。我在调试完一个看似成功的生成模型时一定会额外导出STEP文件再用另一款CAD软件打开看一眼。这一眼能发现很多第一次检查发现不了的问题比如丢失圆角、面方向反转、隐藏的微小碎片。两个软件都过一遍这个模型才算真正能交货。这个习惯我用了很多年也帮我在交付前挡住了不少尴尬。