做CAD建模这么多年我最大的体会就是“入门容易精通难”。那些菜单叠菜单的参数化界面新手光是找“拉伸”“旋转”按钮就能耗掉半天真正要把脑子里那个零件变成屏幕上可编辑的模型中间隔着一大堆操作步骤。而“text-to-cad”这个概念最近两年热得很快——它的目标一句话就能说清你用自然语言描述一个零件系统直接帮你把三维模型建出来。比如输入“生成一个直径40毫米、高15毫米、中间带直径8毫米通孔的圆柱体”你就真的能得到一个可编辑的CAD实体模型。这篇文章我想把一套完整的text-to-cad技术方案拆开讲清楚包括核心思路、两条技术路线的取舍、工具链选型、具体实现步骤以及我实际踩过的一些坑和排查过程。适合两类人看一类是想用AI辅助机械设计、3D打印模型准备的工程师另一类是打算把文本建模能力集成到自己产品或工作流里的开发者。有一点Python基础最好没有的话照着抄也能把主流程跑通。1. text-to-cad 到底在解决什么问题1.1 传统建模流程的卡点咱们先回到传统建模一个很日常的场景工位上突然接到需求要做一个“底板上有四个对称安装孔、侧面带加强筋”的零件。如果你的建模软件熟这个活大概十几分钟如果不熟可能光琢磨怎么画草图就得半小时。但这里真正的瓶颈其实不是“软件熟不熟”而是“从想法到参数化模型”的转化成本——你要把脑海里模糊的空间描述一步步翻译成软件能理解的精确操作序列选基准面、画草图、标注尺寸、拉伸、打孔、倒角。这个翻译过程恰恰是CAD里最枯燥、最容易被替代的环节。text-to-cad的切入点就在这里自然语言本身就是人类描述空间形状最原始的方式如果能让机器直接理解“带孔的底座”这种描述然后自动完成草图、特征、布尔运算那一整套动作整个设计前端的效率会明显不一样。1.2 两条技术路线对比目前所谓text-to-cad业内大致分成两条路线。第一条是“端到端生成”直接训练一个深度学习模型输入自然语言或图片输出三维网格体、点云或隐式场。这类方法视觉效果好能生成比较自由的有机造型尤其适合概念设计阶段。但问题也很明显输出的网格体没有参数化历史没有特征树无法继续编辑也很难直接进加工流程。工程师拿到一个“长得像”的网格基本等于要从头重建。第二条是“文本到结构化建模”让大语言模型把自然语言解析成结构化指令再由CAD内核按指令执行建模操作。这条路输出的是带参数历史、可二次编辑的标准实体模型更贴近真实工程流程。缺点是流程链路长需要做提示词工程、参数校验、内核映射还要处理大模型的幻觉问题。我最终选择的是第二条。原因很简单我希望得到的是一份“活”的模型而不是一张“死”的网格。2. 方案选型与整体架构2.1 为什么选“大模型几何内核”组合先解释一下这个组合的合理性。CAD建模本质上是一系列离散的几何操作创建基础体、做布尔运算、加圆角、抽壳等。这些操作在底层几何内核里都有稳定、成熟的API。真正难的部分是“听懂用户想干什么”以及“把模糊描述转成精确参数”。前者是大语言模型的强项后者是传统程序擅长的活。所以我的思路很简单大模型负责“翻译”几何内核负责“执行”。大模型不直接生成三角形网格也不直接输出STEP文件而是输出一份结构化的建模指令我再写代码把这套指令解析成内核API调用。这样每一层职责清晰出了问题也知道去哪查。2.2 整体架构设计整条链路我分成五层输入层接收自然语言描述可能是“一个带法兰的圆管”这种开放描述也可能是“长100、宽50、高20的长方体”这种精确描述。语义解析层调用大模型把自然语言转成结构化建模指令用JSON承载。参数校验层检查尺寸是否合理、坐标系是否缺失、单位是否统一、布尔运算对象是否存在。建模执行层把合规的指令映射为几何内核API调用完成实体构建。输出与预览层导出STEP/STL并在本地做三维预览。这里最核心的设计决定是“中间表示”。我没有让大模型直接生成Python脚本去调用建模库原因是脚本生成虽然灵活但安全性差——模型可能写出语法错误、死循环甚至恶意代码。结构化JSON则天然受限我只要严格校验字段整个执行过程就是安全的、可控的。这也是为什么我要把“输出格式”卡得死死的不允许大模型自由发挥。2.3 工具链清单整个项目用到的工具不算多但每个角色都很明确自然语言解析某商业大模型的服务API支持在提示词里强制指定JSON输出结构。选它主要是因为稳定性和结构化输出的成熟度比本地小模型的幻觉率低很多。几何内核某开源CAD内核支持B-rep实体建模、布尔运算、圆角、抽壳能导出STEP和STL。这是整个方案里最重的依赖也是精度和可靠性的保障。三维可视化某开源Python可视化库用来快速预览建模结果方便我判断“建出来的东西对不对”。参数校验与日志全部用标准Python库完成校验逻辑自己写日志直接打到文件。这几样东西组合起来刚好覆盖“理解-执行-确认”三个环节。我不建议把可视化那一步省略因为大模型生成的东西哪怕所有参数都合法也可能整体形状不符合预期。没有预览整个流程就少了一道最直观的质量关卡。3. 核心环节实现细节3.1 提示词模板与结构化输出协议整个系统最关键的一环是定义好“大模型和程序之间的接口协议”。我设计了一套非常精简的JSON Schema核心字段如下{ units: mm, features: [ { type: box | cylinder | sphere | extrude | hole, name: 主底座, params: { center: [0, 0, 0], dimensions: [100, 50, 20], radius: null, height: null }, operation: add | subtract, target: 0 }, { type: hole, name: 安装孔1, params: { center: [40, 15, 0], radius: 3, depth: 20 }, operation: subtract, target: 0 } ] }提示词里我会明确告诉模型三件事。第一只输出JSON不要输出任何解释文字。第二所有几何对象必须有明确的中心坐标和尺寸。第三操作类型只能是“加”和“减”两种分别对应布尔并集和布尔差集。实际跑下来“只输出JSON”这条必须反复强调否则模型偶尔还是会输出“好的以下是您需要的建模指令”之类的废话导致解析失败。我还在代码里加了容错如果第一轮解析失败会把返回的原始文本重新交给模型要求“提取其中符合协议的JSON部分”这种二次修复的成功率非常高。3.2 参数校验层怎么写大模型输出几乎不可能一次到位所以参数校验层不是可选项是刚需。我写了三个核心校验函数第一个是“尺寸合理性检查”。比如height字段如果是0或者负数直接判非法如果是直径40mm的圆柱半径填成400毫米即使模型语法上完全正确生成出来的也是个庞然大物明显不是设计意图。我设了一套经验阈值尺寸范围限制在0.1mm到5000mm之间超出就提示“尺寸超出合理范围请检查是否漏写小数点或单位”。第二个是“几何可行性检查”。这一步专门处理布尔运算的退化情况比如两个扣在一起的圆柱坐标完全相同、半径相同那么差集运算后结果为空。这种问题在参数上完全合法但几何上没意义不能让它进入内核执行。第三个是“引用完整性检查”。JSON里用target字段指向要操作的基础体如果target填了一个不存在的序号执行层必然报错。模型偶尔会把特征顺序搞乱导致引用失效。我在提示词里加了一句“target必须引用已存在的特征索引”同时在校验层做了索引越界判断双重兜底。这一层看似不起眼实际上把整个系统的崩溃率从30%左右降到了5%以内。3.3 从JSON到CAD实体的映射参数校验通过后就轮到CAD内核执行真正的建模。这一步的核心是一张映射表把指令类型映射到内核API。我的做法是写一个调度函数逐个遍历JSON里的features列表按顺序执行def build_model(features): base_entity None for feat in features: entity create_feature(feat[type], feat[params]) if base_entity is None: base_entity entity else: if feat[operation] add: base_entity boolean_union(base_entity, entity) elif feat[operation] subtract: base_entity boolean_difference(base_entity, entity) return base_entity这里有一个细节很关键特征的执行顺序决定了最终结果。同一条“底板上打孔”的描述如果先打孔再建底板孔就被底板盖住了。所以我在映射层强制按“基础特征优先、减材料在后”排序也就是先执行所有add类操作再执行所有subtract类操作。这个规则虽然牺牲了一点点自由度但大幅减少了错误。另一个容易翻车的地方是坐标参考系。内核里的坐标轴方向是固定的用户和大模型天然不会每次都把方向说清。我的处理是默认“中心落点”模式——所有box的center都指其几何中心所有hole的center指孔轴心线在顶面的投影点。这样模型不用理解“基准面”“草图平面”这些概念对用户更友好。3.4 模型导出与预览验证建模执行完立即导出两个文件一个STEP格式用于后续加工或装配一个STL格式用于快速可视化。STEP是实体格式保留精度和边界表示STL是网格格式Web端和本地预览都用它。预览这一步我加了自动截图的逻辑内核导出一个轻量渲染图然后把图交给大模型让模型自己判断“生成结果是否符合原始描述”。这一步是个非常实用的闭环相当于用视觉模型给几何模型做质量验证。我试过多次让模型看截图后自己修复参数比如“孔位置偏了5毫米”效果比纯靠文本校验好很多。4. 高频问题与排查实录4.1 典型问题速查表我把实际运行中遇到过的问题整理成了一张表后续排查基本照着表走现象根因处理办法模型尺寸离谱比如厚度填了5000mm模型漏看小数点或单位混乱尺寸阈值校验提示重新生成JSON解析失败返回多余文字提示词约束不够强二次提取修复或强制schema孔洞消失模型变成实心块特征顺序错误减材料先于加材料执行层强制先add后subtract布尔运算抛异常两实体贴合面退化对共面对象做微小偏移或跳过生成的模型无法闭合STL有洞差集后曲面相交退化检查目标实体尺寸或扩大公差预览正常但用户觉得不像语义理解偏差让模型看截图自校正这张表里的每一项都是实际跑过、实际修过的不是理论推演。4.2 单位和精度的经典坑最先踩到的坑就是单位。大模型训练语料里既有毫米又有厘米还有英寸同一个词“宽度10”不同语义下可能是10毫米也可能是10厘米。我一开始没做单位约束结果生成过一个“直径40英尺”的圆柱整个屏幕都装不下。解决办法是在提示词里固定单位同时校验层检查“如果任何尺寸超过5000就要触发二次确认”。后来我干脆在协议里设计了units字段所有尺寸都强制用毫米表示如果模型输出其他单位程序直接拒绝执行并回退到重新生成。精度的坑更隐蔽。内核的布尔运算对共面场景极度敏感两个实体如果刚好在同一个平面上做差集经常出现退化面。我的处理是在做差集之前把刀具实体沿法线方向偏移0.01毫米避开完美共面。这个微小的偏移对毫米级零件几乎无感知但能让内核稳定很多。4.3 布尔运算失败的现场还原印象最深的一次用户描述是“一个长100宽50的板子中间挖一个完全穿透的矩形槽”。模型生成的JSON完全合法尺寸也对但内核执行差集时抛出了异常。排查了很久才发现原因槽的宽度被填成了50毫米正好等于板子的宽度导致槽的两个侧面和板的两个端面完全对齐形成了退化共面。这就是典型的“参数合法但几何非法”。后来我在几何可行性检查里加了一条规则如果subtract对象的某个尺寸和目标对象的对应尺寸差值小于0.5毫米就认为存在共面风险自动给出警告。这种修复属于典型的“经验驱动开发”不是从教科书里能学到的。4.4 提示词优化的实践经验关于提示词我分享几条积累下来的实操经验。第一给模型看“好例子”比写一堆规则管用得多。我在提示词末尾固定附上一个完整的JSON示例模型输出基本都会模仿那个示例的格式。这是大模型的行为特性。第二不要用“大概”“可能”这种模糊词描述期望要说“必须输出有效JSON不包含任何其他字符”。越强的约束越好。第三如果某个场景反复翻车与其反复调提示词不如把该场景变成一条固定的模板规则。比如“四个对称孔”这种高频需求我直接预设了一组对称孔的参数模板让模型填中心距和孔径即可彻底消除歧义。第四每一次失败的案例都值得沉淀。我把翻车样本沉淀成一个“坏例集”每次调试新提示词时先把坏例集跑一遍确保修复A问题的同时没有弄坏B功能。这就是回归测试的思路能省掉很多“改一处坏一片”的痛苦。5. 实测效果与下一步扩展方向跑通整套流程后我拿几个典型零件做了一组实测。结果是简单长方体、圆柱、组合底座这类零件一次性生成成功率在80%左右带孔阵列、凸台、加强筋这类中等复杂度零件一次成功率大概50%再加上一轮“截图回看”自校正最终成功率能到90%以上。这个数据放在真实工作流里已经足够当“第一稿生成器”用了——用户拿到90分的初稿再花几分钟微调比从零建模快得多。后续有几个方向我觉得值得继续做。一个是把模具设计里常见的“脱模斜度”“壁厚均匀”这类工艺规则写进参数校验层让text-to-cad不仅能建模还能建“能加工”的模型。另一个方向是引入装配体级描述比如“一个底板加四个立柱组成的框架”这需要在JSON协议里增加零件间约束关系复杂度会上一个台阶。还有增强型语义解析让模型支持“像某种常见零件”这种类比式描述这对工业标准件库很有价值。我个人在实际操作中最深的一条体会是text-to-cad的瓶颈从来不在“能不能生成形状”而在“生成的东西是不是真正能被工程流程使用”。把精力花在参数校验、格式约束和闭环验证上远比折腾更花哨的网络结构或更大规模的模型划算。回到最开始那句话CAD这件事的核心终究是“精确”和“可编辑”无论前端用多少AI能力后端落到的还是一颗扎实的几何内核。想清楚这条后面所有的实现路径都会清晰很多。