1. 从一段文字到三维实体text-to-cad 到底在解决什么问题第一次听到 text-to-cad 这个词很多人脑子里浮现的画面大概是对着电脑敲一句给我画一个法兰盘然后屏幕上就自动长出一个三维模型。这个想象不算离谱但真正落地的时候它解决的问题比自动画图要具体得多也琐碎得多。text-to-cad 的核心是把自然语言描述转换成计算机辅助设计软件能够识别的几何数据。这里的CAD不是单指某一个软件而是一整条数据链路从文本意图解析到参数化建模再到几何内核生成边界表示B-rep最后导出成 STEP、GLB、STL 这类通用格式。关键词里出现的 STEP、GLB、STL恰好对应了这条链路上三种典型的输出形态——STEP 面向精确制造与跨软件交换GLB 面向可视化与网页渲染STL 面向3D打印的网格切片。理解这三者的差异是理解整个 text-to-cad 项目价值的前提。我接触这个方向最初是因为一个很实际的需求手头有一批标准件每次都要在 CAD 里重复画一遍改个尺寸就得重新拉伸、打孔、倒角。后来想能不能用一段结构化文本描述这些零件的关键参数让程序自动生成模型这个念头一旦冒出来就发现它牵扯的东西远比想象中多——文本怎么描述几何几何怎么保证是可制造的而不是一堆自相交的破面导出的文件怎么在不同软件里都不出问题适合读这篇内容的人大概分三类一类是想把设计流程自动化的工程师手里有大量重复性建模工作一类是做 AI 生成 3D 模型的研究者需要理解几何数据的工程约束还有一类是纯粹好奇文字变模型到底靠不靠谱的爱好者。不管你是哪一类下面这些从实际项目里趟出来的经验应该都能帮你少走点弯路。需要先说明一点text-to-cad 目前并不是一句话生成任意复杂装配体的魔法。它在参数明确、结构规整、有标准可循的零件上表现最好比如法兰、支架、齿轮毛坯、简单的壳体。越是依赖自由曲面和艺术造型的东西纯文本驱动的可靠性越低。认清这个边界后面的技术选型才不会跑偏。2. 文本意图到几何参数解析层最容易翻车的地方2.1 为什么不能直接把自然语言丢给几何内核很多人第一版实现会想我直接调一个大模型让它输出建模代码不就行了这个思路能跑通 demo但一上真实项目就崩。原因在于几何内核比如 OpenCASCADE、Parasolid 这类需要的是精确的数值和拓扑关系而不是大概是个圆柱这种模糊描述。举个具体的例子。你说一个直径 50 毫米、高 30 毫米的圆柱中心打一个直径 10 毫米的通孔。这句话对人来说毫无歧义但要转成几何操作至少要拆成创建圆柱体半径 25高度 30、创建圆柱孔半径 5、做布尔减运算、确认孔轴线与圆柱轴线重合。每一步都对应内核里一个明确的 API 调用参数错一个小数点模型就废了。所以解析层的真正任务不是理解语言而是把语言映射成一组带单位的、有约束关系的参数。我习惯把这一层拆成三个子步骤实体识别、参数抽取、约束补全。实体识别负责判断这句话在说哪类几何体——是拉伸体、旋转体还是扫掠体。参数抽取负责把直径 50高 30这些数字和单位抓出来。约束补全最容易被忽略用户往往不会说孔和圆柱同轴但几何上必须同轴这个默认约束得由系统补上。2.2 单位与公差那些不写清楚就一定会出事的细节我踩过最典型的一个坑就是单位。文本里写直径 50到底是毫米、厘米还是英寸如果解析层默认按毫米处理而用户心里想的是英寸导出的 STEP 文件到了加工厂零件尺寸直接差 25.4 倍。这种错误在 demo 阶段看不出来因为模型看起来是对的只有到了下游才爆雷。我的做法是强制要求文本中显式带单位或者在项目配置里锁定全局单位制绝不允许裸数字进入几何生成阶段。如果用户没写单位系统要么报错要么用配置里的默认值并在日志里明确记录。这个策略看起来死板但省掉了后面无数的扯皮。公差是另一个隐形杀手。文本描述里说孔直径 10几何上生成的就是精确的 10.000。但实际制造中孔要么是 10 加公差要么是 10 减公差。text-to-cad 生成的模型通常是名义尺寸模型公差信息要么单独用标注表达要么在导出时通过 PMI产品制造信息附加。如果你的下游是 3D 打印公差可以暂时不管但如果下游是 CNC 加工名义模型加一份公差表才是完整交付物。2.3 用结构化中间表示兜住混乱直接让大模型输出几何 API 调用最大的问题是不可控——同样的输入两次输出可能结构完全不同没法做单元测试也没法复现。我的经验是在自然语言和几何内核之间插一层结构化中间表示可以理解成一份 JSON schema。这份中间表示大概长这样一个 features 数组每个元素描述一个特征包含类型cylinder、box、hole、fillet、关键参数、以及它和前面特征的布尔关系。文本解析的目标就是稳定地生成这份 JSON而不是直接生成建模代码。这样做的好处是JSON 可以被校验、被测试、被人工修正几何生成层只认 JSON不认自然语言职责彻底分开。{ units: mm, features: [ {type: cylinder, radius: 25, height: 30, id: body}, {type: hole, radius: 5, axis: z, through: true, id: center_hole}, {type: fillet, target: body.top_edge, radius: 2} ], operations: [ {op: subtract, target: body, tool: center_hole} ] }这份中间表示还有个额外好处它天然就是一份可读的设计意图文档。出了问题你一眼就能看出是解析错了还是几何生成错了排查效率比翻建模代码高得多。3. 几何生成与内核选型STEP、GLB、STL 背后的取舍3.1 三种格式不是随便选的它们对应三种用途关键词里 STEP、GLB、STL 并列出现很多人以为只是导出格式多几个选项其实它们背后是完全不同的几何表示和用途选错了会直接导致下游用不了。STEP 是精确的边界表示B-rep记录的是解析曲面和精确的拓扑关系。一个圆柱面在 STEP 里就是半径 25 的圆柱面不是一堆三角形。它的优势是精度无损、可被主流 CAD 软件包括中望 CAD、SolidWorks 这类直接读取并继续编辑。缺点是文件结构复杂解析器实现成本高。STL 是三角网格把曲面离散成一堆小三角形。它的优势是简单、几乎所有 3D 打印切片软件都认。缺点是精度取决于网格密度而且丢失了曲面信息——你拿到一个 STL很难反推出这是个直径 50 的圆柱只能看到一堆三角面片。热词里sw 中 stl 转 stp之所以是个高频问题就是因为这个转换本质上是有损的转出来的 STEP 是一堆碎面而不是干净的解析曲面。GLB 是 glTF 的二进制版本面向实时渲染和网页展示。它同样基于网格但带了材质、光照、层级结构信息适合在浏览器里做可视化预览。如果你要做的是一个输入文字、网页上立刻看到模型的产品GLB 是首选但如果你要交付给工厂加工GLB 完全不够用。格式几何表示精度可编辑性典型用途STEPB-rep 精确曲面无损高可继续建模制造、跨软件交换STL三角网格有损取决于网格密度低难以还原曲面3D 打印、快速预览GLB三角网格 材质有损低网页渲染、可视化我的建议是text-to-cad 项目内部始终以 B-rep 为核心表示STEP 作为主输出STL 和 GLB 作为按需派生的下游格式。这样精度损失只发生在派生环节核心模型始终是干净的。3.2 内核选型OpenCASCADE 是绕不开的起点做开源 text-to-cad几何内核基本就那几个选择。OpenCASCADE简称 OCCT是最主流的开源 B-rep 内核功能全、社区活跃、文档虽然难啃但资料多。它的学习曲线陡API 命名风格偏工程化但一旦上手从拉伸、旋转到布尔运算、倒角、抽壳都能覆盖。另一个常被提到的是基于网格的方案比如直接用 trimesh 这类库操作三角网格。这条路起步快但一旦涉及精确的布尔运算和曲面过渡就会遇到精度和鲁棒性问题。我试过用纯网格方案做带倒角的零件倒角处经常出现自相交或者法线翻转最后还是回到 OCCT 重做。选 OCCT 的代价是环境配置麻烦。它在不同平台上的编译依赖不少Python 绑定pythonocc-core的版本兼容性也需要留意。我的经验是优先用 conda 安装 pythonocc-core而不是 pip因为 conda 渠道的二进制包把依赖都打包好了省掉大量编译时间。如果非要用 pip做好折腾编译工具链的心理准备。3.3 布尔运算的鲁棒性几何生成里最深的坑布尔运算并、交、差是参数化建模的核心操作也是鲁棒性问题最集中的地方。两个实体做差运算如果它们的面恰好共面、或者相切、或者有极小的重叠内核可能算出错误结果甚至直接抛异常。我遇到过一个经典案例在一个圆柱体上打一个直径刚好等于圆柱直径的孔本意是掏空结果布尔运算因为两个面完全重合产生了退化面导出的 STEP 在某些软件里打开直接报错。解决办法是给孔留一个微小的尺寸差或者改用抽壳操作而不是布尔减。这类问题的通用应对策略有三条第一避免让参与布尔运算的面精确共面或相切必要时引入微小偏移第二每次布尔运算后做几何有效性检查OCCT 提供了 BRepCheck 相关工具发现问题立即回滚第三对输入参数做合理性校验比如孔径不能大于等于外径倒角半径不能超过相邻边长度的一半。提示几何有效性检查一定要在生成流程里做成强制步骤而不是可选项。我见过太多项目因为省了这一步把坏模型一路传到下游才发现排查成本翻了好几倍。4. 从跑通到可用工程化落地的几个关键决策4.1 参数校验前置别等内核报错几何内核的报错信息通常很难懂动不动就是拓扑异常或者某个底层异常对使用者极不友好。我的做法是在调用内核之前先用一层纯 Python 的参数校验把明显不合法的输入拦下来。校验规则包括尺寸必须为正数孔径必须小于外径倒角半径必须小于相邻面的最小边长阵列的间距不能导致实体自相交等等。这些规则用简单的数值比较就能实现但能拦掉大部分低级错误让内核只处理参数合法但几何复杂的情况。更进一步可以把这些校验规则做成配置化的不同零件类型挂不同的规则集。这样新增零件类型时只需要补规则不用改主流程。4.2 缓存与增量生成别每次都从头算text-to-cad 的一个典型使用场景是改一个参数重新生成。如果每次改动都从头跑一遍完整流程响应会很慢尤其是复杂零件。我的优化思路是把中间表示和几何结果都做缓存并且支持增量更新。具体来说中间表示那份 JSON本身就是缓存的一部分。用户改了一个尺寸系统只需要重新生成受影响的那部分特征而不是全部重建。OCCT 支持对特征做依赖追踪理论上可以实现增量重算但实现复杂度不低。如果项目规模不大一个更务实的做法是缓存最终导出的文件用输入文本的哈希做 key命中就直接返回没命中才重新生成。这个策略对反复生成相同零件的场景特别有效。4.3 导出环节的格式细节那些让文件打不开的小问题导出 STEP 时有几个参数值得注意。一是单位STEP 文件头里会写明单位制如果生成时用的是毫米但导出时没设置对文件到了别的软件里尺寸会错。二是精度模式STEP 支持不同的精度表示方式选不对可能导致曲面在导入时出现缝隙。三是实体与壳的区别导出的应该是封闭实体solid而不是开放壳shell否则下游软件可能认为模型不完整。导出 STL 时核心参数是网格精度。精度太高文件巨大精度太低曲面变成明显的多边形。我的经验值是对于一般机械零件线性偏差控制在 0.01 到 0.05 毫米之间角度偏差控制在 0.1 到 0.5 弧度之间能在文件大小和表面质量之间取得不错的平衡。如果是 3D 打印用可以适当放宽如果是做视觉展示反而要收紧。导出 GLB 时要注意坐标系朝向。不同软件对上的定义不一样有的用 Z 轴向上有的用 Y 轴向上。GLB 生态里 Y 轴向上更常见如果生成时用的是 Z 轴向上导出前记得做一次旋转否则模型在网页里会躺着。4.4 一个完整的生成流程长什么样把上面这些串起来一个可用的 text-to-cad 流程大概是这样的接收文本输入做基础清洗去多余空格、统一单位表述。解析层把文本转成结构化中间表示JSON同时做参数合法性校验。校验通过后调用几何内核按中间表示逐特征建模。每个特征生成后做几何有效性检查异常则回滚并报错。全部特征完成后做一次全局有效性检查。按需导出 STEP、STL、GLB导出时设置好单位、精度、坐标系。把中间表示和导出文件一起缓存供后续复用。这个流程里第 2 步和第 4 步是质量的关键闸门。很多项目失败不是因为几何算法不行而是因为这两道闸门没设好坏数据一路流到下游。5. 实测中反复出现的坑与应对经验5.1 文本歧义用户说的和你理解的往往不是一回事打一个沉头孔这句话不同的人理解不一样。有人指的是圆柱形沉孔有人指的是锥形沉头。如果解析层不做澄清生成出来的模型可能完全不是用户想要的。我的应对策略是在中间表示里保留歧义标记并在生成前做一次确认。对于无法唯一确定的描述系统给出几个候选解释让用户选。这比自作主张生成一个错误模型要好得多。如果项目是纯自动化的、没有交互环节那就需要在文档里明确支持的描述词汇表超出范围的输入直接拒绝。5.2 数值精度浮点数比较的陷阱几何计算里到处都是浮点数比较。判断两个点是否重合、两个面是否共面如果用直接比几乎必然出错。正确做法是引入一个容差tolerance比如 1e-6 毫米用abs(a - b) tol来判断。这个容差的选择也有讲究。太小了本该重合的点判成不重合布尔运算失败太大了本该分开的特征被判成重合产生退化几何。OCCT 内部有自己的容差体系但和外部参数交互时最好统一用一套容差标准避免来回转换。5.3 大模型输出的不稳定性如果解析层用了大模型一定要意识到它的输出是不稳定的。同样的输入今天和明天可能给出不同的中间表示。这对需要复现的工程场景是致命的。我的做法是把大模型的输出当作建议而不是结果后面必须跟一层确定性的校验和规范化。比如大模型说半径 25校验层确认这个值在合理范围内然后写入中间表示。中间表示一旦确定后续流程就完全确定不受大模型波动影响。这样既用上了大模型的语义理解能力又保证了工程可复现性。5.4 下游软件的兼容性生成的 STEP 文件在 SolidWorks、中望 CAD、FreeCAD 里打开表现可能不一样。有的软件对曲面精度要求高稍微有点缝隙就报错有的软件容错性好能自动修复。这不是你的模型错了而是不同软件的实现差异。应对办法是在多个目标软件里做回归测试把常见零件类型都跑一遍记录哪些软件在哪些情况下会出问题。如果某个软件特别挑剔可能需要针对它调整导出参数比如提高曲面精度、避免使用某些高级曲面类型。6. 这条链路还能往哪走text-to-cad 目前最成熟的形态是结构化文本到参数化零件。再往前一步是自然语言到参数化零件这一步依赖语义解析的可靠性。更远的一步是自然语言到复杂装配体这涉及到零件之间的配合约束、运动关系难度是数量级的提升。从工程角度我觉得近期最值得投入的方向有两个。一是把中间表示标准化让它成为一种通用的文本到几何交换格式不同工具之间可以互通。二是把几何有效性检查做得更智能不只是发现错误还能给出修复建议比如这个倒角半径过大建议改为 X。另外热词里频繁出现的cad 转 pdfcad 图纸合并python 批量对 cad 修改这些需求其实和 text-to-cad 是同一条自动化链路的不同环节。文本生成模型只是起点后面还有批量处理、格式转换、图纸输出一大堆事。把这条链路打通价值比单点突破大得多。我在实际项目里最大的体会是text-to-cad 的难点从来不在生成而在生成得对、生成得稳、生成得能被下游接受。把精力花在参数校验、几何有效性检查、格式兼容性这些不性感的地方比追求更炫的生成效果要实在得多。一个能稳定生成 20 种标准件的系统比一个偶尔能生成复杂曲面但十次有三次报错的系统工程价值高出一个量级。