Text-to-CAD深度解析:从B-rep原理到工程落地的实战指南

发布时间:2026/9/19 18:49:50
Text-to-CAD深度解析:从B-rep原理到工程落地的实战指南 1. 新范式来了从鼠标拖拽到一句需求“编译”出图纸作为一个在机械设计行业摸爬滚打了十几年的老工程师我第一次看到 Text-to-CAD 这个概念的时候第一反应是“这玩意是不是又是AI生成个示意图糊弄人的”。但真正把几个项目跑通之后我意识到这其实不是一个“画图工具”而是把设计意图直接翻译成参数化几何模型的编译过程。它和那些“输入一句话生成一张图”的AIGC完全是两码事生成式AI画图输出的是像素点阵而 Text-to-CAD 输出的是经过边界表示B-rep描述的、带拓扑关系的实体模型。简单说前者是给你一张照片后者是给你一个可以被 CAM 软件直接拿去算刀路的实体文件。这个方向如果做好了解决的是制造企业里很要命的一个问题从概念到三维模型之间的那一大段重复劳动。你想想一个非标自动化项目的方案阶段工程师要把客户的原始需求翻译成“大概是这么个形状、这么个尺寸”的模型然后再手工细化。这个“翻译”过程往往要占掉整个设计周期三分之一的工时。Text-to-CAD 的定位就是把这段路用代码和算法过一遍让设计人员把精力放在工况分析、材料选择、装配工艺这些真正需要人类判断的地方。这篇文章我不会去念产品手册就从一个用过的工程师角度聊聊它背后的技术逻辑、实际跑通的步骤以及哪些坑是厂商演示视频里永远不会告诉你的。2. 核心原理拆解Text-to-CAD 到底在跑什么算法2.1 从自然语言到参数化约束设计意图的“转译层”很多人以为 Text-to-CAD 最核心的技术在于“画几何体的算法”这其实是个误解。如果你接触过任何一个 Text-to-CAD 系统会发现整个流程的第一步是如何把你那句“一个M6螺纹孔的安装底板四角倒圆角R5”变成一组可以被几何内核理解的约束条件。这个环节本质上是一个大语言模型在做语义解析但它对比通用的 ChatGPT 类产品难点在于需要输出结构化的约束树而不是一段人话。比如当你说“带四个沉头孔的L型支架”时模型不仅要知道“L型”是两个互相垂直的平板还得知道“沉头孔”的口部直径、深度、底孔直径之间的标准对应关系典型值如ISO 10642标准以及四个孔的定位规则是“均布”还是“按边距等距分布”。如果这一层没有处理好后面所有几何生成都是在沙滩上盖楼。从实际体验看目前比较好用的工具比如一些结合了CAD内核API的插件级方案在转译层大量引入了“设计规则引擎”。也就是说它会用一些预设的机械设计规则去校验大语言模型解析出来的约束是否自洽。举个例子你说“直径40的轴配一个轴承位”系统会自动去查常用滚动轴承的尺寸系列然后提示你“40直径的轴配合6208轴承时建议轴肩高度为3.5毫米倒角C1.5”。这种能力已经不单纯是“听懂人话”而是具备了一定程度的机械设计常识推理能力。2.2 为什么是 B-rep而不是网格或者点云再往内核层走Text-to-CAD 生成的模型必须被制造业的上下游工具链所接受。这就决定了它不能像现在那些 3D AIGC 工具一样输出 OBJ 网格文件。网格模型Mesh在视觉上是完美的但一旦进入 CAM 软件、有限元分析FEA、或者下游的二维工程图标注就会暴露出致命问题没有精确的几何拓扑关系、没有曲面连续性信息、公差标注无处附着。所以在实际项目中Text-to-CAD 工具的底层都是对接某个商用或开源的几何建模内核如 Parasolid、ACIS、OpenCASCADE生成的结果是 B-repBoundary Representation边界表示模型。这种模型的核心特征是一个实体由有限个面Face、边Edge和顶点Vertex构成并且它们之间有严格的拓扑连接关系。你可以在 CAD 软件里对这个实体直接进行布尔运算、倒角、抽壳等操作模型不会碎掉拓扑始终保持有效。这也解释了为什么“生成式AI画图”那一套泛化能力极强的扩散模型没办法直接用在 Text-to-CAD 上。扩散模型擅长生成像素级别的连续分布但 B-rep 的表示是离散的、有严格结构约束的拓扑数据。强行用生成对抗网络或扩散模型去生成 B-rep很容易出现“看着像法兰盘但一拉伸就报错”的尴尬场面。所以现在主流路线是“大语言模型出语义和参数 传统几何内核出实体”用代码把两端缝合起来。2.3 参数化与特征树的保留能不能“改”比“生”更重要还有一个容易被忽略但是实际上极其核心的环节是参数化特征树的保留。如果你在一个成熟的 Text-to-CAD 工具里生成一个零件你会发现它生成的模型不是“一坨定死的实体”而是带有完整特征历史树的——拉伸特征Extrude、旋转特征Revolve、孔特征Hole都在树的节点里每一个节点的参数都可以双击修改。这个点有多重要你可以拿它跟“用脚本直接写几何”做一个对比。以前我们用 Python 调 FreeCAD 或者用 DesignScript 写 Dynamo 节点也能通过代码生成零件但那个代码往往是过程性的、不可逆的跑完生成实体代码和实体之间的关联就断了。而 Text-to-CAD 试图保留下来的是一个“活”的参数化模型。你生成之后改了孔距下游的倒角、阵列跟着变。这意味着生成结果不是设计终点而是设计起点。从企业落地的角度来说这一点是决定要不要在生产环境里引入的关键指标。3. 实操笔记从项目立项到生成一张可用图纸3.1 环境准备与工具选型别迷信“全自动”选型看三点你在网上搜 Text-to-CAD会看到一堆研究论文比如 Text2CAD、CAD-GPT 这类但真正能装到本地干活的主要是两类一类是集成在主流 CAD 软件里的第三方插件另一类是基于 OpenCASCADE 内核的开源工具链配合大模型 API。我个人建议如果你是做标准机械产品的直接上商业插件如果你是搞自动化设备研发、需要频繁改结构的先拿开源方案搭一个最小验证环境更稳妥。选型主要看三个指标。第一个是“特征识别率”你就拿公司最近做过的五个典型零件去测看系统能不能把它们拆分成合法的特征树。别听厂商吹的“支持任意复杂形状”大概率是拿一个多面体花瓶做演示那种自由曲面根本没法上机床。第二个是“参数回改能力”也就是生成之后你能不能像平时画图一样双击尺寸改数改完下游模型联动更新。第三个是“系统集成度”尤其看看它能不能直接导出 STEP 或者 Parasolid反正我们最后加工还是要走 CAM 的导出一个破烂格式等于没做。我自己搭的最小环境是这样的Ubuntu 22.04 的机器上跑 OpenCASCADE 内核通过 Python 脚本调用一个本地部署的代码生成模型这年头本地跑7B模型都够用了输出就是一段构造几何的 Python 代码然后直接调 OCC 的 API 生成实体最后导出 STEP。这套方案虽然原始但每一步都看得见摸得着出问题好查。3.2 Prompt 写法给“会说人话”的模型补上机械常识很多人第一次用 Text-to-CAD 的时候会像跟 ChatGPT 聊天一样随手敲一句“给我做一个支架。”然后生成了一个完全没法用的奇怪形状就得出“这玩意不行”的结论。实际上Text-to-CAD 的输入虽然叫“自然语言”但它对大模型的推理要求更高你的描述越接近工程语言生成的模型越可靠。这里我总结了一套还算管用的 Prompt 结构大概是四要素零件名称功能定位、关键尺寸与公差、加工工艺假设、设计约束。举一个实际跑通过例子你说“一块 6061 铝合金底板用于固定一个 60mm 导轨滑块滑块孔距 40mm用 M5 沉头螺钉固定”比单纯说“做一个带孔的板”要好用不知道多少倍。因为“6061铝合金”会触发模型查材料库“60mm导轨滑块”会触发标准的导轨安装面尺寸记忆“M5沉头螺钉”会触发对应的过孔和沉孔设计参数。另外有一点很关键一定要在 Prompt 里说清楚“哪些地方是功能面哪些地方是工艺面”。比如你告诉它“底面是安装面表面粗糙度 Ra3.2”模型就会尽量避免在底面做凸起特征也会合理选择是否需要添加工艺凸台。这个信息对模型判断特征树层级很有帮助生成结果的可用性能提升一大截。3.3 生成后处理流程别跳过“特征清理”三步走我不管你用的是商业插件还是开源方案生成完之后第一步永远不是去保存、转格式而是做三件事特征树审查、几何检查、干涉检查。特征树审查就是看系统生成的特征是否可以被“常规操作”复现。比如它如果生成了一个“多截面放样”特征而实际上用两次拉伸加一次布尔并集就能做出来那你最好改成后者。为什么因为下游做 CAM 编程的同事拿到“放样特征”刀路规划会有很多麻烦反而没有“拉伸布尔”来得直观。我干过的最蠢的一件事就是拿到一个生成零件直接转 STEP 发给加工厂结果对方打电话来问“这个特征的工艺基准在哪”我对着特征树看了半天回答不上来。从那以后我养成了习惯生成完先用软件自带的特征识别工具把特征树“清洗”一遍能合并的合并能简化到标准特征的坚决不保留花活。几何检查就更简单粗暴了直接用 CAD 内核的“修复”功能批处理一遍检查面是否存在细微裂缝、边是否有自相交、有没有零厚度的退化几何。OpenCASCADE 环境里可以用 BRepCheck 逐个 face 检查商业 CAD 里直接运行“检查实体”工具就行。别看这个步骤土实际生成失败的案例里有一大半都是这种拓扑瑕疵导致的后续报错。干涉检查主要是针对装配体场景。Text-to-CAD 单零件生成一般没问题但一旦涉及多个零件配合比如生成一个轴和一个带孔的法兰系统很容易出现轴径等于孔径的零间隙配合情况这在真实制造里是不可能存在的因为必须有配合公差。所以每次生成一对配合件我都会手动检查并留出间隙值。相关参数的选取没有统一标准根据你选的配合制来定我常用的是基孔制 H7/g6 这种间隙配合具体数值查机械设计手册就行。4. 实操环节的完整实现与效果评估4.1 一个完整案例关键词驱动的法兰支架生成这里用我之前做的一个自动化设备上的传感器安装支架作为测试样例完整走一遍流程也给你看看实际生成的参数化代码长什么样。需求很简单固定一个光电传感器传感器上有两个直径 3.2mm 的安装孔孔距 25mm需要把支架固定在一根 40mm 方形铝型材上。我先写好 Prompt包含的信息基本是上面总结的四要素名称是“C型传感器安装支架”功能是“将光电传感器固定于4040型材”关键尺寸是“两孔间距25mm孔径3.2mmC型开口宽度适配40mm型材”加工方式是“铝合金建议线切割下料加铣削”。模型生成的代码经过整理后核心部分大概长这样# 生成 C 型传感器安装支架的简化示意代码 import cadquery as cq # 定义主体尺寸参数 height 80.0 # 支架总高 width 40.0 # 适配40型材槽口 thickness 5.0 # 板厚 # 创建 C 型主体 result (cq.Workplane(XY) .box(height, width, thickness, centered(True, True, False)) .edges(|Z).fillet(2.0) # 外侧边缘倒圆角R2 .faces(Z).workplane() .center(-20.0, 0.0) .rect(20.0, thickness, centered(True, True)) .extrude(20.0) # C 型下翼缘 .faces(Z).workplane() .center(20.0, 0.0) .rect(20.0, thickness, centered(True, True)) .extrude(20.0) # C 型上翼缘 ) # 在安装面上打两个传感器固定孔 result (result.faces(Y).workplane() .center(0.0, 20.0) .pushPoints([(-12.5, 0.0), (12.5, 0.0)]) .hole(3.2))这代码本质上是模型根据我的语义描述自动重构出的 CAD 建模过程不是人写的。生成完之后我做了两件事。第一把支架构型里的倒角 R2 改成了 R3因为 C 型开口根部有尖角应力集中的风险这是基于受力分析的经验调整。第二给安装孔增加了沉孔特征因为传感器原厂推荐用 M3 沉头螺钉进行齐平安装。改完特征树之后更新模型、导出 STEP整个过程不到十五分钟如果是从空白手工画我大概要四十分钟到一个小时。4.2 与手工建模的效率对比别把账算错了现在各大厂商很喜欢给你晒“效率提升十倍”这种数字但我劝你算账的时候分情况看。如果是这一类规则清晰、标准件特征明显的零件Text-to-CAD 确实有巨大优势我自己实测下来类似上述支架这样结构的零件从需求确认到模型完成时间大约只有传统方式的 30%。但如果是高度定制化的曲面造型零件比如风机叶轮、复杂外壳目前的 Text-to-CAD 工具表现并不稳定甚至不如直接用曲面建模来的快。还有一个隐藏成本要考虑Prompt 调试的时间。你用几次会慢慢发现每次换新结构类型头一两次生成总是会有各种各样的问题得来回修改描述。这个“调试 Prompt”的时间往往不在产品宣传材料的统计口径里。所以我的建议是先从你过往案例里挑出那些“重复性高、结构标准化”的零件建立 Prompt 模板库把调试成本一次性付清后面再遇到类似需求直接套用这时候才能真正吃到效率红利。4.3 模型质量评估除了“像不像”还要看“能不能造”我见过很多人在评测 Text-to-CAD 生成结果时只看“渲染图像不像”或者“尺寸对不对”这太外行了。在制造业里一个模型算不算合格至少得过三关可制造性、可装配性、可分析性。可制造性简单说就是这模型能不能用现有的加工工艺做出来。比如你生成一个深腔薄壁件壁厚只有 0.5mm光看模型挺精美但实际 CNC 加工一碰就颤刀压铸也根本填不满。正规的工具一般会在生成的时候附带一个 DFM面向制造的设计提示比如“壁厚过小建议增加至 1.5mm 以上”。如果系统没这个功能你就得自己凭经验判断了。可装配性主要看公差配合是否合理、有没有考虑到螺栓扳手空间。可分析性则意味着模型拿到 CAE 软件里能不能正常划分网格、施加边界条件不报错。我们团队现在有一套内部评估表单每次测试生成模型都按这三个维度打分低于一定分数就直接弃用不浪费时间修补。5. 常见问题与排查技巧实录5.1 生成的模型特征树里全是“哑特征”怎么破所谓“哑特征”就是生成出来的特征没有参数化关联改一个值其他值不会联动更新。这种情况在早期工具里特别常见它像是把一个实体的最终状态“拍快照”了下来而不是把建模过程“录下来”。遇到这种情况我一般先尝试“特征识别”功能重新解析——大多数主流 CAD 都能对导入的实体做特征识别把拉伸、孔、阵列这些特征重新提取出来。如果识别失败那就只能手工重建特征树了。这里有一个技巧你先手动新建一个空零件然后把这个实体的某个面作为基准面用它生成第一个拉伸特征紧接着系统会让你自动捕捉草图轮廓。把这套流程走完软件就会把其他特征也挨个识别出来。虽然费点时间但是处理完之后模型就“活”了后续改尺寸方便很多。千万不要拿一个“哑实体”直接往 CAM 里丢万一工艺要调整你就等着重新画吧。5.2 布尔运算报错“实体不封闭”不是模型算法的锅经常有人跑 Text-to-CAD 生成轴类零件或箱体零件时最后一步合并实体报错“Shell is not closed”或者“B-Rep operation failed”。排查第一先检查是不是单位不一致导致的。很多开源工具链默认按毫米处理但大语言模型对尺寸数字的理解有可能会把 10mm 输成 10cm内部一换算几何就出现了缝隙。解决方法非常简单生成完第一步检查一遍关键尺寸的单位量级是否合理。另一个高发原因是临近面之间存在极小的间隙或重叠几何肉眼看不出来但内核在拓扑层面认为它们是分离的。遇到这种情况条件允许就调大公差重新生成不行的话把报错的那两个特征单独提取出来用“延伸面-裁剪-缝合”三步修复法手动处理一遍。我踩过最深的一个坑是用默认公差跑对合面B-rep 缝合后模型外观没问题但一导成 STEP 文件进 CAM 就崩。后来统一把缝合公差改成了 0.001mm问题消失。5.3 生成结果“尺寸对特征错位”排查语义歧义我这里有一个真实的失败案例。我在 Prompt 里写“滑块安装面为顶面”结果系统把安装孔打在了侧面圆角也全加在了底面。问题出在哪在机械设计语境里“顶面”通常指设备正常摆放时的上表面但模型在计算的时候默认把坐标系的 Z 轴方向当成了“顶”。这种“语义歧义”在 Text-to-CAD 里非常常见。怎么排查第一每次生成前在 Prompt 中明确坐标基准比如“该零件设计坐标系中Z 方向开口Y 方向为安装配合面”第二生成后第一步旋转模型从六个视角快速扫一遍确认特征方向是否符合设计意图第三养成“用装配环境验证”的习惯把生成的零件丢进总装图里和相邻零件做一次快速干涉检查很多错位一眼就能看出来。这个流程走顺了能避免至少一半的返工。5.4 常见问题速查表问题现象可能原因排查与解决特征树为“哑实体”生成过程未记录参数化步骤使用特征识别重建参数树布尔运算报错、实体不封闭单位不一致、几何间隙检查单位、调整缝合公差尺寸对但特征方向错位语义歧义坐标系理解偏差明确坐标基准、装配环境检查干涉输出 STEP 进入 CAM 后崩溃拓扑瑕疵用修复工具批处理后再导出特征过多导致 CAM 刀路规划异常放样等复杂特征过多合并简化特征转换为拉伸布尔生成壁厚过小难以加工缺乏 DFM 约束在 Prompt 中限定最小壁厚及工艺要求6. 实际影响范围与选型建议6.1 谁能最先吃到红利标准件、非标件、焊接件三个领域差异巨大关于 Text-to-CAD 的影响范围我的判断可能和大部分人的直觉不太一样最先受益的不是做复杂产品设计的而是标准件和非标自动化设备领域的工程师。为什么因为这两个领域里“需求描述”和“三维模型”之间的映射关系高度模板化。你告诉别人“需要一个伺服电机安装座适配 80 法兰输出轴径 14mm”任何一个有经验的工程师脑子里都能瞬间勾勒出大致结构。这种强规则场景正是 Text-to-CAD 模型的舒适区。焊接件领域则是另一个极端。焊接件的结构往往取决于型材切割、焊接顺序和应力变形控制这些信息光靠一句自然语言描述很难完整表达。但它在“从加工参数生成模型”这个反向路径上很有潜力。也就是说你给它输入“方管40x40x3切成45度斜角长度 500mm”系统帮你把焊接模型直接搭好。这是目前很多工具还没做太好的方向但一旦打通对钣金和焊接行业的影响会非常大。6.2 对设计师岗位的影响不会淘汰人但会分化技能很多人担心这玩意会让机械设计师失业。我自己用了这段时间之后的看法是短期内不会大面积失业但岗位技能结构会发生明显变化。你可以把 Text-to-CAD 理解为“翻译器”它把客观需求高效地转成几何模型但它不了解你现场工况里的那些“潜规则”——比如某个位置之所以留凸台是为了方便工人用内六角扳手拧紧螺钉某个孔之所以公差严是因为装配时需要对中调整。这种隐性知识是模型短期内很难学会的但对“只用 T 型命令画方块”的初级绘图员来说冲击确实存在。以前需要三个初级工程师干一天的重复改图工作未来一个懂行的工程师带着 Text-to-CAD 工具半天就能干完。所以我的建议是与其焦虑不如主动把精力放到“设计意图拆解”和“规则库建设”上你去梳理公司里出现过哪些典型结构、对应的设计标准是什么把这些沉淀成 Prompt 模板和规则库反而是未来设计师最值钱的能力。6.3 落地时的企业级建议从小规则库开始先跑通闭环如果你的团队准备引入 Text-to-CAD我给你的建议很朴素不要一上来就想直接打通 ERP、PDM那是个天坑。先找一个最小的、重复工作量最大的零件类别建一个小规则库测试“需求描述—模型生成—特征清理—导出加工”这条闭环。这个过程治两个病一是让你的团队熟悉工具的脾气知道哪些描述方式输出稳定二是教会你们摸清工具的边界别在它不擅长的领域硬刚。我们当时选的是“各类底板和安装支架”建完规则库之后新项目里大概 80% 的此类零件可以直接从需求描述生成初稿再由设计人员修改确认。这个比例听起来没那么夸张但每个零件节省的 20 到 40 分钟累积起来非常可观。更关键的是工程变更时不用再一个个特征去改直接在文本描述上改参数重新生成开始点比传统模式的返工效率好太多。7. 从零搭建最小 Text-to-CAD 验证环境的替代思路如果你的公司预算有限上不起商业插件你可以用一套完全开源的方案做最小验证。这里我把我的实践路线写一下给想试水的朋友们参考。思路就是“大语言模型做命令编排、开源 CAD 内核做几何执行”。最常见的组合是本地部署一个代码生成模型参数规模不需要很大7B 到 13B 的量化模型就够用模型的输出端接 CadQuery 或者 build123d 这类“用代码写 CAD”的 Python 库最后再通过 CadQuery 内置的导出功能输出 STEP。说白了就是让大模型去写 CadQuery 代码而不是直接生成几何数据。这个方案在早期几乎是我认为最“健康”的落地路径因为每一步骤的错误都可调试不依赖黑盒几何生成。具体配置时要注意三个点第一模型选型别追求能力最强的而是要选“代码生成稳定”的因为几何代码一个括号错位你就得排查半天第二Prompt 必须约束输出格式比如强制要求只输出 CadQuery 代码、禁止解释性文字否则解析器会崩第三要有“重试机制”模型第一次生成的代码可能报错自动把错误信息回传给模型让它自我修正一次或者两次成功率会大幅提升。我实测在小样本情况下简单的板类零件自动化生成加自动修复的成功率能做到一半以上这个效率作为前期验证项目已经相当能打了。