1. 从一段文字到三维实体text-to-cad 到底在解决什么问题第一次听到 text-to-cad 这个说法很多人脑子里浮现的画面是对着电脑敲一句给我画一个法兰盘然后屏幕上就自动长出一个带螺栓孔的三维模型。这个想象不算离谱但真正落地的时候它要解决的问题比自动画图要具体得多也琐碎得多。text-to-cad 的核心是把自然语言描述转换成参数化 CAD 模型并最终导出成下游能直接用的几何文件格式比如 STEP、GLB、STL。它瞄准的不是替代工程师做复杂装配设计而是吃掉那些重复、简单、但量特别大的建模活儿——标准件、简单结构件、教学示例、快速原型验证阶段的占位模型。适合看这篇内容的人有三类一是想给自己工作流加自动化能力的机械/结构工程师二是做 AI 应用、想把大模型接到 CAD 上的开发者三是做 3D 内容、需要批量生成基础几何体的技术美术。为什么这件事现在值得认真做因为传统 CAD 建模的门槛卡在人身上。一个熟练的工程师画一个带倒角的简单支架可能五分钟搞定但如果要画两百个尺寸各异的变体那就是十几个小时的机械劳动。而自然语言是所有人都会用的接口把描述和几何之间的翻译自动化等于把批量建模的成本压到了接近零。这就是 text-to-cad 真正的价值锚点不是让 AI 取代设计师而是让设计师不用再干复读机的活。不过要提醒一句这个方向目前远没到一句话出成品的程度。语言是模糊的几何是精确的两者之间隔着一整套参数化建模的逻辑。理解这道鸿沟在哪、怎么填比盲目追工具重要得多。下面我会从几何表示、技术路线、实操落地、踩坑经验几个层面把这件事拆开讲透。2. 先搞懂几何的三种语言STEP、GLB、STL 各自管什么做 text-to-cad绕不开的第一个问题就是生成的模型到底存成什么格式很多人一上来就纠结用哪个大模型其实格式选错了后面全是返工。STEP、GLB、STL 这三个词在热搜里高频出现它们不是随便挑的而是代表了三种完全不同的几何表达哲学。2.1 STEP参数化世界的通用普通话STEPStandard for the Exchange of Product model dataISO 10303是 CAD 领域的交换标准。它的关键特征是基于边界表示B-rep保留完整的拓扑关系和精确的解析曲面——圆柱就是数学意义上的圆柱不是一堆小三角拼出来的近似。这意味着什么意味着 STEP 文件导进 SolidWorks、中望 CAD、Fusion 360 之后你还能继续编辑改孔径、调圆角、加特征模型是活的。对于 text-to-cad 来说如果你的目标是生成可继续编辑的工程模型STEP 是唯一正确的终点格式。代价是 STEP 的生成难度最高。它要求后端有一个真正的参数化建模内核比如 OpenCASCADE你得把自然语言解析成一系列建模操作拉伸、旋转、布尔运算再让内核执行。这条链路长、环节多但产出的东西最值钱。2.2 STL3D 打印的方言只认三角面片STL 是最简单的几何格式它只描述表面的一堆三角形面片没有单位、没有颜色、没有拓扑、没有参数。你拿到一个 STL只能看和打印想改尺寸对不起得重新建模。热搜里sw 中 stl 转 stp3dsmax2012 修复 stl 模型的 uvqopengl 加载 stl这些词本质上都反映了 STL 的定位它是下游消费格式不是设计格式。text-to-cad 生成 STL 通常是为了直接送 3D 打印或者喂给渲染/仿真管线。它的优点是生成快、兼容性无敌任何切片软件、任何引擎都认。2.3 GLB给看和交互准备的格式GLB 是 glTF 的二进制版本主打 Web 和实时渲染场景。它带材质、带层级、带动画文件小、加载快。如果你的 text-to-cad 产物是要放到网页里做产品展示、或者进游戏引擎做资产GLB 比 STL 合适得多——STL 没有材质渲染出来是一片灰。把三者的定位理清楚选型就不纠结了格式几何表达能否继续编辑典型用途生成难度STEPB-rep 精确曲面能工程交付、二次设计高STL三角面片不能3D 打印、仿真低GLB网格材质有限Web 展示、游戏资产中提示如果你的 text-to-cad 系统要同时服务工程和展示两类需求正确做法是一次建模多路导出——内核里维护一份参数化模型导出时分别转成 STEP、STL、GLB而不是为每种格式单独生成一遍。我见过不少人图省事直接让模型输出 STL结果客户要改个孔径整个流程推倒重来。格式这件事一开始想清楚能省掉后面 80% 的返工。3. 自然语言到几何的那道鸿沟为什么一句话建模没那么简单理解了格式接下来要面对真正的硬骨头怎么把一个直径 50、厚 10 的圆盘中间开个直径 20 的孔这句话变成内核能执行的建模指令。这道鸿沟比大多数人想象的要宽。3.1 语言是模糊的几何是精确的人说一个圆盘脑子里默认它是个圆柱体说厚 10默认单位是毫米。但机器不知道这些默认值。text-to-cad 系统必须做两件事消歧和补全。消歧是把圆盘映射到圆柱体这个几何基元补全是在用户没说单位时根据上下文推断出毫米或者干脆在交互里追问。这里有个反直觉的点最难的不是理解复杂描述而是处理信息不全的简单描述。用户说画个支架这句话对人是清晰的大概是个 L 形或 T 形的板对机器几乎是零信息。所以成熟的 text-to-cad 系统往往不是一句话直出而是一句话 一轮澄清——先给出一个合理默认再让用户微调参数。3.2 参数化建模的操作序列才是真正的中间表示从语言直接跳到几何是行不通的中间必须有一层结构化的建模指令序列。这层表示通常长这样先创建一个草图sketch在草图里画圆标注直径然后拉伸extrude给定高度再在顶面画第二个圆做切除cut。这一串操作才是 CAD 内核真正能执行的东西。所以 text-to-cad 的技术核心其实是把自然语言翻译成这套操作序列而不是翻译成最终的几何。这个认知非常关键因为它决定了你的系统架构你需要一个语言到操作的解析器加一个操作到几何的执行内核两者解耦。3.3 大模型在这里扮演什么角色大语言模型擅长的是语言理解和结构化输出正好对应语言到操作序列这一步。你可以让它读一句描述输出一段 JSON描述建模步骤{ operations: [ {type: sketch_circle, plane: XY, diameter: 50}, {type: extrude, height: 10}, {type: sketch_circle, plane: top, diameter: 20}, {type: cut, depth: through} ] }然后你的后端拿这段 JSON 去调用 OpenCASCADE 之类的内核执行。这个分工的好处是大模型不需要懂几何它只需要懂怎么把话拆成步骤内核不需要懂语言它只需要懂怎么执行步骤。两边各干各擅长的事系统就稳了。注意不要让大模型直接输出坐标点或三角面片。它算不准数值生成的几何会扭曲、自交、破面。让它输出操作和参数把精确计算交给几何内核这是踩过无数坑之后的共识。4. 搭一套能跑的 text-to-cad 流水线从解析到导出的完整链路理论讲完进入实操。下面这套链路是我实际跑通过的最小可用方案技术栈选型都给了理由你可以照着搭也可以按需替换组件。4.1 整体架构四段式流水线整条链路分成四段语言解析 → 操作序列 → 几何执行 → 格式导出。每一段职责单一接口清晰方便单独调试和替换。语言解析层接大模型 API输入自然语言输出结构化操作 JSON。操作序列层校验 JSON 的合法性补全缺失参数处理单位换算。几何执行层调用几何内核按操作序列建模。格式导出层把内核里的模型导出成 STEP / STL / GLB。这样分层最大的好处是可测试。语言解析层可以单独用一堆句子测几何执行层可以单独用固定 JSON 测出问题能快速定位是哪一段的锅。4.2 几何内核选型为什么是 OpenCASCADE几何内核是整个系统的地基选错了后面全白搭。主流选择有 OpenCASCADE开源、Parasolid商业、ACIS商业。对个人和小团队来说OpenCASCADE 几乎是唯一现实的选择开源免费、支持 B-rep、能导出 STEP社区资料也够多。它的 Python 绑定是 pythonocc-core装起来稍微有点折腾但跑通之后很稳conda install -c conda-forge pythonocc-core装完可以先用几行代码验证内核能不能跑from OCC.Core.BRepPrimAPI import BRepPrimAPI_MakeCylinder # 创建一个半径25、高10的圆柱 cylinder BRepPrimAPI_MakeCylinder(25, 10).Shape() print(几何创建成功)能打印出几何创建成功说明内核环境没问题可以往下走。4.3 语言解析层的提示词设计这一层的关键是提示词。你要让大模型稳定输出符合你 schema 的 JSON提示词里必须把操作类型白名单参数含义单位约定写死。我常用的模板结构是这样的你是一个 CAD 建模指令解析器。把用户的自然语言描述转换成建模操作序列。 可用操作sketch_circle, sketch_rectangle, extrude, cut, fillet。 所有尺寸单位统一为毫米。未指定尺寸时使用合理默认值并在 notes 中说明。 只输出 JSON不要输出任何解释。实测下来把只输出 JSON和操作白名单这两条写清楚输出稳定性会高很多。另外建议加一个 few-shot 示例给一两个输入句子 → 输出 JSON的样例模型模仿起来更准。4.4 从操作序列到几何执行器的写法执行器就是把 JSON 里的操作一条条翻译成 pythonocc 的调用。核心逻辑是一个循环按操作类型分发def execute(ops): shape None for op in ops: if op[type] sketch_circle: profile make_circle(op[diameter] / 2) elif op[type] extrude: shape extrude(profile, op[height]) elif op[type] cut: tool make_circle(op[diameter] / 2) shape boolean_cut(shape, extrude(tool, op[depth])) return shape这里有个容易忽略的细节布尔运算的顺序会影响结果。先切孔再倒角和先倒角再切孔出来的模型可能不一样。所以操作序列的顺序必须严格按用户描述的建模逻辑来不能随意重排。4.5 导出环节一次建模多路输出模型在内核里建好之后导出成不同格式就是几行代码的事。STEP 用 STEPControl_WriterSTL 用 StlAPI_WriterGLB 则需要先转成网格再走 glTF 库。建议把导出封装成一个函数传入目标格式列表批量产出def export_all(shape, formats, basename): if step in formats: write_step(shape, f{basename}.step) if stl in formats: write_stl(shape, f{basename}.stl) if glb in formats: write_glb(shape, f{basename}.glb)这样一套流程跑下来从一句话到三种格式的文件全自动完成。第一次跑通的时候那种真的成了的感觉还是挺爽的。5. 实测中那些文档不会告诉你的坑流水线搭起来只是开始真正花时间的是调那些跑得通但结果不对的问题。下面这几个坑我几乎每个都踩过写出来帮你省点时间。5.1 单位混乱最常见的翻车点大模型对单位几乎没有概念。你说直径 50它可能理解成 50 米也可能理解成 50 英寸。如果不做统一导出的模型尺寸可能离谱到没法用。解决办法是在解析层强制约定单位并在提示词里反复强调。更稳妥的做法是在操作序列里显式带上单位字段执行器再做一次换算兜底。5.2 数值精度大模型算不准别让它算前面提过一次这里再强调绝对不要让大模型做数值计算。你让它算直径 50 的圆周长是多少它可能给你一个看起来对但实际有偏差的数。所有涉及几何计算的地方都要交给内核或你的代码。大模型只负责翻译语言不负责算数。5.3 破面与自交几何内核的报错怎么读布尔运算失败、倒角半径过大、切除深度超过实体厚度这些都会导致内核抛异常。pythonocc 的报错信息通常很晦涩但有个规律大部分失败都源于参数在几何上不自洽。比如你要在一个厚 10 的板上切一个深 20 的孔内核就会懵。遇到这类报错先检查参数之间的逻辑关系而不是去改代码。5.4 复杂描述的解析失败用户描述越长越复杂解析成功率越低。比如一个带四个安装孔、边缘倒圆角、底部有加强筋的方形底板这种多重特征叠加的描述模型很容易漏掉其中一两个。应对策略是把复杂描述拆成多轮先建主体再逐个加特征每轮确认一次。这比一次性解析要可靠得多。常见问题根本原因应对策略尺寸离谱单位未统一提示词约定执行器换算数值偏差让模型算了数计算全部交给内核布尔失败参数几何不自洽校验参数逻辑关系特征遗漏描述过于复杂拆成多轮建模提示调试阶段建议把每一步的中间结果都存下来——解析出的 JSON、执行后的模型、导出的文件。出问题时能快速定位是哪一环比盲目重跑高效得多。6. 把 text-to-cad 接进真实工作流的几种姿势跑通 demo 和真正用起来是两回事。下面聊聊几种我实际见过、也确实有价值的落地方式以及各自的注意点。6.1 批量标准件生成这是最容易见效的场景。很多项目里有一大批结构相似、只是尺寸不同的零件比如不同规格的法兰、垫片、支架。传统做法是一个个画text-to-cad 的做法是写一个模板描述把尺寸做成变量批量生成。这时候你甚至不需要大模型——直接用参数化脚本就够了。大模型的价值在于把非结构化的需求文档自动转成参数表比如从一份 Excel 规格表里读出每个零件的尺寸自动生成对应模型。6.2 教学与快速原型做机械制图教学、或者产品早期概念验证时经常需要快速出个占位模型。这时候对精度要求不高对速度要求高。text-to-cad 生成的 STL 直接丢进切片软件打印或者 GLB 丢进网页做展示都能省下大量建模时间。注意这类场景下不要追求 STEP 级别的精确用 STL/GLB 就够了链路更短、更快。6.3 与现有 CAD 软件的配合text-to-cad 生成的 STEP 可以无缝导入 SolidWorks、中望 CAD 等软件继续编辑。这里有个实用技巧生成时把关键尺寸做成命名参数导入后能快速定位和修改。另外如果你后续要在 CAD 里做装配建议生成时就统一坐标系原点避免导入后模型飘在奇怪的位置。6.4 和下游工具的衔接热搜里那些cad 转 pdfcad 图纸合并python 批量对 cad 修改的需求其实都可以和 text-to-cad 串成一条线生成模型 → 批量修改 → 导出图纸 → 转 PDF 交付。把这条链路自动化一个人能顶过去一个小组的产出。关键是把每个环节的输入输出格式对齐别在格式转换上反复折腾。7. 关于这套东西我踩过之后最想说的几句text-to-cad 这个方向最容易让人上头的是AI 自动建模这个概念最容易让人失望的也是它。我自己的体会是把它当成一个能听懂人话的参数化脚本生成器而不是能替代工程师的建模师心态就对了。它擅长的是把重复劳动自动化不擅长的是处理真正需要工程判断的复杂设计。如果你打算动手做我的建议是从最小闭环开始先不管大模型用固定的 JSON 操作序列跑通解析→建模→导出这条链路确认几何内核没问题然后再把语言解析层接上用简单句子测最后再逐步增加描述复杂度。这个顺序能让你在每一步都有可验证的成果而不是一上来就被一堆报错劝退。还有一点几何内核的坑比语言模型的坑多得多。很多人把精力全花在调提示词上结果发现模型输出没问题是几何执行那一步崩了。所以时间分配上给几何内核调试留足预算这是过来人的忠告。至于后续怎么扩展我个人的方向是往模板库参数填充走——把常见结构做成模板让大模型只负责填参数这样稳定性和可控性都会好很多比纯生成靠谱。