CAD 这行当有个特别拧巴的地方设计师脑子里的三维结构要变成机器能读的几何文件中间隔着一整套手工建模流程。画个法兰盘得先选基准面、画草图、约束尺寸、拉伸、倒角、打孔一套下来十几分钟没了。要是碰上参数化系列件改一个尺寸就得重新走一遍特征树。这几年大模型写代码、写文案都挺溜了那能不能让它直接写 CAD 模型text-to-cad这个方向就是冲着这件事去的——用一段自然语言描述直接生成可用的 CAD 几何文件输出 STEP、URDF、G-code 这类下游能直接消费的格式。它解决的不是画图快一点的问题而是把描述即模型这条路打通让不会 CAD 的人也能产出几何让会 CAD 的人从重复建模里解放出来。下面我按自己趟过的路子把这件事拆开讲透。1. 先搞清楚 text-to-cad 到底在生成什么很多人第一次听到 text-to-cad脑子里浮现的是AI 帮我点鼠标画图。这个理解偏了。真正有价值的 text-to-cad输出的不是屏幕上的像素或者某个私有格式的工程文件而是结构化的几何描述最终落到标准交换格式上。为什么强调这一点因为 CAD 生态里格式就是命脉你生成一个只有自家软件能打开的玩意儿下游 CAM、仿真、3D 打印全接不上等于白干。1.1 三种目标格式对应三条完全不同的下游链路从关键词里能看出STEP、URDF、G-code 是三个高频词它们其实代表了三条链路STEP中性几何交换格式走的是精确 B-rep边界表示路线。它描述的是数学上精确的曲面和实体公差可控是机械加工、装配、CAE 仿真的通用语言。你生成 STEP意味着下游可以拿去做数控编程、做有限元网格划分。URDF统一机器人描述格式本质是 XML描述的是连杆 关节的树状结构。它不关心曲面精度关心的是运动学关系——哪个部件绕哪个轴转、转多少度、质量多少、惯性张量多大。机器人仿真里导入 CoppeliaSim 这类工具吃的就是 URDF。G-code数控机床和 3D 打印机的指令流是刀具路径级别的描述。它不描述实体描述的是喷头或刀具怎么走。从文本直接到 G-code中间其实跳过了实体建模直接做路径规划难度和风险都更高。这三者不是一回事做 text-to-cad 之前必须先想清楚你要的是精确实体、运动学模型还是加工路径选错了格式后面全白搭。1.2 为什么文本直接到几何比文本到代码难得多写代码有编译器兜底语法错了立刻报错。几何不一样一段描述生成出来的模型可能语法上完全合法、能打开、能渲染但尺寸是错的、壁厚是负的、孔打到了实体外面。几何的正确性是隐性的它不会主动告诉你这里不对。所以 text-to-cad 的核心难点不在生成而在约束求解和几何校验。我自己的体会是把这件事拆成两段更靠谱第一段大模型把自然语言翻译成参数化的结构化中间表示比如一段描述尺寸、特征、约束的 JSON 或 DSL第二段用确定性的几何内核OpenCASCADE、CadQuery、build123d 这类去执行这个中间表示生成真正的几何。大模型负责理解意图几何内核负责保证正确各干各擅长的事。让大模型直接吐 STEP 文本那基本是在赌它背过多少几何数据不可控。1.3 一个最小可用的中间表示长什么样假设用户输入一个 80mm 见方、厚 10mm 的底板四角各一个直径 6mm 的通孔孔中心距边缘 10mm。合理的中间表示大概是这样{ type: plate, width: 80.0, depth: 80.0, thickness: 10.0, features: [ { type: hole, diameter: 6.0, through: true, positions: [ {x: 10.0, y: 10.0}, {x: 70.0, y: 10.0}, {x: 10.0, y: 70.0}, {x: 70.0, y: 70.0} ] } ] }这个 JSON 就是意图和几何之间的契约。大模型只要输出这个几何内核负责把它变成实体。好处是可校验、可复现、可参数化。用户改一个尺寸改 JSON 就行不用重新问模型。这也是为什么我强烈建议不要跳过中间表示这一步。2. 从自然语言到参数化中间表示提示词与约束设计中间表示定好了接下来就是怎么让大模型稳定地吐出它。这一步的坑比想象中多因为自然语言描述几何天生是模糊的。一个圆角——多大几个孔——几个、在哪、多大用户不会说全模型就得会补全而补全的默认值必须合理。2.1 把几何意图拆成实体 特征 约束三层我实践下来最稳的拆法是三层基体base模型的主体形状长方体、圆柱、拉伸轮廓等。特征features在基体上做的加减操作孔、槽、凸台、倒角、圆角。约束constraints尺寸、位置、对称、共线等关系。提示词里要把这三层讲清楚并且给出默认值策略。比如用户没说圆角半径默认取壁厚的 1/4 或者一个固定小值如 1mm并在输出里标注该值为推断值。这一点特别重要——让模型显式声明哪些是用户给的、哪些是它猜的下游才能判断风险。2.2 提示词模板里必须钉死的几件事我用的模板大致包含这些硬约束单位统一为毫米所有数值必须带单位或明确声明为 mm。坐标系约定Z 轴向上基体底面在 Z0 平面。特征顺序先加后减倒角圆角放最后。输出必须是合法 JSON不允许有注释、不允许有省略号。遇到无法确定的参数输出inferred: true并给出理由字段。提示不要指望一次提示就能稳定输出。我一般会做两轮——第一轮让模型输出中间表示第二轮专门做自检让它检查尺寸是否自洽比如孔径是否小于板宽、孔位是否在实体范围内把问题在生成几何之前就拦下来。2.3 处理模糊描述的实用技巧用户说给我做个支架这几乎没法直接生成。我的做法是反问补全模型先输出一个待确认参数清单列出它需要但用户没给的关键尺寸让用户填。这比硬猜一个模型出来、用户发现全错要高效得多。实测下来反问一轮能把返工率降一大半。另一个技巧是给参照物。用户说大概手掌大小模型可以映射到一个经验尺寸区间比如 80–100mm并标注这是估算。把模糊词映射成数值区间是 text-to-cad 里非常实用的一环。3. 几何内核选型为什么我最终落在代码化建模上中间表示有了得有个东西把它变成真几何。这一步的选型直接决定项目能不能落地。市面上的路子大概三类直接调商业 CAD 的 API、用开源几何内核、用代码化建模库。我挨个试过说说各自的坑。3.1 商业 CAD API 路线能力强但重SolidWorks、中望 CAD 这类都有二次开发接口能通过脚本驱动建模。优点是几何内核成熟、精度高、能直接出工程图。缺点是重——你得装一整套 CAD还得处理授权、版本兼容。热词里cad 激活页面脚本发生错误安装 cad 一直出现 c2005 错误这些全是这条路线的现实摩擦。做服务端批量生成装一堆商业软件本身就不现实。3.2 开源几何内核路线OpenCASCADE 是底座OpenCASCADEOCCT是很多开源 CAD 的几何内核B-rep 能力完整能读写 STEP。直接用它的 C API 门槛高但它是很多上层库的地基。如果你要做严肃的、精度要求高的 text-to-cad最终大概率会落到它上面。Python 侧有 pythonocc 封装能用但文档和示例偏少踩坑成本不低。3.3 代码化建模库CadQuery 与 build123d这是我最推荐的起步路线。CadQuery 用 Python 的链式调用描述几何build123d 是它的后继思路语法更接近 Python 原生。它们底层就是 OCCT所以生成的 STEP 是精确 B-rep不是网格。举个例子生成前面那个带孔底板import cadquery as cq result ( cq.Workplane(XY) .box(80, 80, 10) .faces(Z) .workplane() .rect(60, 60, forConstructionTrue) .vertices() .hole(6) ) cq.exporters.export(result, plate.step)这段代码就是中间表示 → 几何的执行器。大模型生成的 JSON映射成这样的调用就能出 STEP。代码化建模的最大好处是可版本控制、可参数化、可批量特别适合和 text-to-cad 结合。3.4 三条路线的对比路线几何精度部署成本适合场景主要坑商业 CAD API高高出工程图、复杂装配授权、版本、安装报错OpenCASCADE 直用高中深度定制内核学习曲线陡、文档少CadQuery/build123d高低参数化零件、批量生成复杂曲面能力有限我的建议是先用 CadQuery 把链路跑通验证价值再考虑要不要下沉到 OCCT。一上来就啃 OCCT很容易卡在环境配置上出不来。4. 输出 STEP 与 URDF两条链路的实操细节生成几何只是第一步导出成下游能用的格式才是交付。STEP 和 URDF 的导出逻辑差别很大分开说。4.1 STEP 导出精度、单位、坐标系三件事STEP 导出看着简单其实有三个容易翻车的点单位STEP 文件头里带单位声明但不同内核默认值不一样。有的默认米有的默认毫米。导出后一定要用工具比如 FreeCAD 或 OCCT 的读取器验证一下尺寸别等下游加工出来才发现大了 1000 倍。坐标系约定好 Z 轴向上还是 Y 轴向上。机械领域常用 Z 向上但有些仿真工具默认 Y 向上导入后模型是躺着的。精度B-rep 的精度由内核公差控制一般默认够用但如果模型里有极小特征比如 0.1mm 的槽要检查公差是否把它抹掉了。提示批量导出时给每个文件加上参数指纹比如尺寸的哈希作为文件名后缀避免不同参数生成的同名文件互相覆盖。这个坑我在批量生成系列件时踩过一晚上覆盖掉几十个模型。4.2 URDF 导出从几何到运动学中间差了一整套物理属性URDF 不是几何格式是运动学 动力学描述。从 text-to-cad 生成 URDF难点在于几何只是外观URDF 还需要连杆的质量、惯性张量、关节类型、关节轴、关节限位。这些信息自然语言里通常不会给。我的处理方式是分两步先用几何生成每个连杆的 meshSTL 或 DAE作为 URDF 里的 visual 和 collision。质量按体积乘密度估算默认密度取 1000 kg/m³ 或按材料给惯性张量按几何近似长方体、圆柱有解析公式算。关节信息则从用户的描述里抽比如这个臂绕底座旋转就对应一个 revolute 关节轴是 Z。抽不出来的输出待确认清单。导入 CoppeliaSim 这类仿真器时最常见的报错是 mesh 路径不对、惯性张量为零导致仿真发散。惯性张量千万别填零哪怕给个很小的正值也比零强否则求解器直接崩。4.3 G-code为什么我不建议从文本直接生成G-code 是刀具路径从文本直接生成意味着模型要自己完成工艺规划——选刀具、定切削参数、排刀路、避让夹具。这已经超出几何生成范畴进入 CAM 领域了。大模型对切削参数的理解非常不可靠生成的 G-code 直接上机床是危险的。我的做法是text-to-cad 只负责生成 STEPG-code 交给成熟的 CAM 软件或 slicer从 STEP 生成。这样责任边界清晰几何归几何工艺归工艺。如果非要做也只在 3D 打印这种低风险场景下尝试且必须人工检查路径。5. 实测中暴露的问题与排查链路链路跑通不代表能用。下面是我在实际项目里遇到的真问题以及完整的排查过程照着走能省不少时间。5.1 模型能生成但打不开从文件头开始查第一次导出 STEP下游软件报文件损坏。排查链路是这样的看文件大小如果只有几百字节基本是导出失败内核没写入实体。看文件头STEP 文件开头应该是ISO-10303-21;如果开头是乱码或空说明写文件时编码或路径出了问题。用独立读取器验证别用生成它的同一个库去读换个工具FreeCAD 命令行读一遍能区分是文件真坏还是读取器不兼容。查几何是否为空有时候布尔运算把实体减没了比如孔比板还大导出的就是个空壳。最后定位到是布尔减操作把实体减空了——用户描述板上打孔但孔位算到了板外减完啥也不剩。几何校验必须做不能省。5.2 尺寸对不上单位与缩放的双重陷阱有次生成的模型下游反馈大了 25.4 倍。这是典型的英寸/毫米混淆。排查发现中间表示里用户说的是2 英寸模型转成了 2没乘 25.4而导出时又按毫米写。单位转换必须在一个地方统一做要么全在中间表示层转成毫米要么全在导出层转绝不能两处都动。5.3 批量生成时内存爆掉几何内核不是无状态的批量跑几百个模型跑到一半进程被 kill。原因是 OCCT 的对象不释放内存持续增长。解决办法是每个模型处理完显式释放或者干脆每个模型起一个子进程跑完就退。用子进程虽然慢一点但稳定不会因为一个模型的内存泄漏拖垮整批。5.4 常见问题速查表现象可能原因排查动作文件打不开导出失败/空实体查文件头、文件大小、几何是否为空尺寸差整数倍单位混淆检查中间表示与导出层的单位导入仿真器报错mesh 路径/惯性为零检查 URDF 路径、惯性张量批量中途崩溃内存泄漏改子进程隔离、显式释放圆角失败半径大于壁厚校验圆角半径与相邻特征尺寸6. 把 text-to-cad 接进真实工作流的几点经验技术链路通了最后一步是让它真正有用。这一步的坑不在代码在流程设计。6.1 别追求一句话出成品追求一句话出草稿我一开始的预期是用户说一句话就得到能直接加工的模型实测下来这不现实。更靠谱的定位是快速出草稿用户描述 → 生成初版几何 → 用户在 CAD 里微调。这样把 text-to-cad 当成建模加速器而不是建模替代者接受度高得多也避开了精度和工艺的坑。6.2 参数化是复用的关键生成一次模型不算本事能参数化复用才是价值。把中间表示存下来用户改尺寸时只改 JSON重新执行几何内核即可。这样一套文本 → 参数 → 几何的流水线能覆盖整个系列件。热词里python 批量对 cad 修改说的就是这个需求text-to-cad 天然适合干这个。6.3 校验环节不能省而且要自动化几何校验要写成自动化的检查项每次生成都跑一遍实体是否非空、尺寸是否在合理区间、特征是否互相干涉、壁厚是否为正。这些检查用几何内核的 API 就能做成本不高但能拦住绝大多数低级错误。宁可生成失败报错也不要生成一个看起来对、实际错的模型后者危害大得多。6.4 关于cad 如何彻底卸载不影响二次安装这类问题的联想热词里这类问题特别多本质是 CAD 生态的环境脆弱性。这也反过来印证了为什么我推荐代码化建模路线——它把几何生成从装一堆软件变成跑一段脚本环境依赖少可容器化可 CI。一个 text-to-cad 服务理想状态下应该是一个 Docker 镜像进去就是干净的 Python 环境加几何内核不碰任何商业软件的安装和授权。这样部署、迁移、扩容都简单。6.5 一个我常用的最小工作流把上面这些串起来我日常用的工作流是这样的用户输入自然语言描述。大模型输出参数化中间表示JSON并标注推断值。自动校验中间表示的自洽性不自洽就反问补全。几何内核执行中间表示生成实体。自动几何校验通过则导出 STEP或 URDF。存下中间表示供后续参数化复用。这套流程跑下来一个简单零件的生成时间在秒级复杂一点的也就十几秒。比起手工建模效率提升是数量级的而且可复现、可批量、可版本控制这三点是手工建模给不了的。最后分享一个我踩过的小坑中间表示里的数值一定要用浮点数而不是字符串存。我早期图省事把尺寸存成字符串结果做参数化替换时字符串拼接出了80 10变成8010的乌龙模型直接大了两个数量级。数值就是数值别偷懒。