1. 从一句话到三维模型text-to-cad 到底在解决什么问题第一次听到 text-to-cad 这个词我脑子里蹦出来的画面是对着电脑敲一句“给我画一个 80×60×10mm、四角带 M4 沉头孔的安装板”然后软件自己把模型建好、导出 STEP 文件丢给我。这个画面在几年前还属于科幻范畴但现在已经有一批工具能把它跑通个七八成。所谓 text-to-cad直译就是“文本转 CAD”核心逻辑是用自然语言描述几何意图由程序解析语义、生成参数化建模脚本最终输出标准 CAD 格式文件——常见的就是STEP、GLB、STL这几种。它解决的问题很具体传统 CAD 建模的门槛不在“想不想得到”而在“手会不会画”。一个非机械背景的产品经理、一个做概念设计的工业设计师、一个需要快速验证装配空间的硬件创业者他们脑子里有清晰的几何需求但打开 SolidWorks 或 Fusion 360 之后光是草图约束、基准面选择、拉伸切除这一套流程就够劝退的。text-to-cad 把这段“翻译”工作交给模型和代码人只需要把需求说清楚。适合看这篇内容的人大概分三类一是想快速验证结构方案的硬件从业者二是对参数化建模感兴趣但不想啃 API 文档的工程师三是做 AI 辅助设计工具的产品或研发。我会把整个链路拆开讲——从文本解析到几何生成从格式选择到实际踩坑尽量让没接触过 CAD 二次开发的人也能看懂门道。2. 核心链路拆解文本是怎么变成三维实体的2.1 文本解析层把“人话”翻译成结构化参数text-to-cad 的第一步不是画图是理解。用户输入“一个长 100mm、宽 50mm、厚 5mm 的板中间挖一个直径 20mm 的圆孔”这句话里包含了几何类型板、孔、尺寸参数100、50、5、20、位置关系中间、拓扑操作挖。解析层要做的就是把这些信息抽成结构化数据通常是一个 JSON 或类似格式的中间表示。这一步现在主流有两种做法。一种是基于规则的正则匹配加关键词词典适合领域窄、句式固定的场景比如只处理“板孔槽”这类简单零件准确率高但泛化差。另一种是用大语言模型做语义解析把自然语言直接映射成建模脚本或参数对象泛化能力强但需要处理幻觉问题——模型可能会“脑补”出你没说的尺寸。我实测下来比较稳的方案是混合式先用 LLM 做意图识别和参数抽取再用规则校验器检查参数是否完整、是否在合理范围内。比如用户说“挖个孔”但没给直径规则层就追问或填默认值用户说“厚 5 米”规则层直接拦截并提示单位异常。这个校验环节看着不起眼但少了它后面几何生成阶段会炸得莫名其妙。2.2 几何生成层参数化建模内核的选择拿到结构化参数之后下一步是真正生成三维几何。这里的选择直接决定了输出质量和格式兼容性。目前 text-to-cad 类工具背后常用的几何内核大概有三种路线。第一种是调用商业 CAD 的 API比如 SolidWorks 的 COM 接口、Fusion 360 的 Python API、中望 CAD 的二次开发接口。好处是几何精度高、特征树完整、直接能导出 STEP。坏处是依赖宿主软件、授权成本高、跨平台差。我试过用 Python 批量对 CAD 修改走的就是这条路脚本跑起来稳但部署到没有装 CAD 的机器上就废了。第二种是用开源几何内核典型的是 OpenCASCADE。它支持 B-Rep 表示能生成 STEP 和 IGES精度够工业用。Python 生态里有 pythonocc 这个绑定写起来不算太痛苦。缺点是文档稀碎、报错信息晦涩一个布尔运算失败能让你查半天。但胜在自由度高、可嵌入服务端适合做在线 text-to-cad 工具。第三种是走网格路线用 trimesh、numpy-stl 这类库直接生成 STL 或 GLB。速度快、依赖轻但输出的是三角网格没有特征历史后续改参数得重新生成。适合做预览、3D 打印、可视化展示不适合需要精确工程图的场景。选哪条路取决于你的输出格式要求。要 STEP 就走前两条要 STL/GLB 且不追求特征树第三条最省事。2.3 格式输出层STEP、GLB、STL 各自什么场合用很多人卡在格式选择上其实搞清楚三者的定位就不纠结了。STEP是工程交换格式存的是 B-Rep 边界表示有精确的曲面和实体信息能保留特征树如果导出时带的话。SolidWorks、中望 CAD、FreeCAD 都能打开适合后续做工程图、装配、CNC 加工。缺点是文件大、解析慢、不同软件之间转换偶尔丢面。STL是 3D 打印和快速预览的老朋友只存三角面片没有单位、没有颜色、没有特征。优点是几乎所有切片软件和查看器都认缺点是精度靠面片密度堆改一个尺寸得重新生成整个网格。热词里“sw 中 stl 转 stp”之所以被频繁搜索就是因为 STL 转 STEP 是个逆向重建过程不是简单改后缀。GLB是 glTF 的二进制版本主打 Web 展示和实时渲染。带材质、带层级、文件小适合在浏览器里做交互预览。但它是为可视化设计的不是为制造设计的尺寸精度和公差信息基本没有。我的建议是text-to-cad 工具至少支持 STEP 和 STL 双输出。STEP 给工程师做后续处理STL 给 3D 打印和快速验证。GLB 作为可选项用于网页端预览。3. 实操落地从零搭一个最小可用的 text-to-cad 流程3.1 环境准备与依赖选型假设你要自己搭一个最小可用的 text-to-cad 原型我推荐的技术栈是 Python OpenCASCADEpythonocc-core 一个大语言模型 API。为什么选 Python因为几何处理、LLM 调用、Web 服务这三块的生态都最成熟胶水代码少。安装 pythonocc-core 是个小坑。官方推荐用 conda 装pip 装经常编译失败。命令大概是conda install -c conda-forge pythonocc-core装完之后验证一下from OCC.Core.BRepPrimAPI import BRepPrimAPI_MakeBox box BRepPrimAPI_MakeBox(100, 50, 5).Shape() print(box)能打印出对象就说明内核通了。如果报找不到 DLL 或 so 文件大概率是环境变量没配好Windows 上把 conda 环境的 Library/bin 加到 PATH 里。LLM 这块用哪个模型不是关键关键是提示词设计。你需要让模型输出固定格式的 JSON而不是自由文本。我一般会在 system prompt 里写死 schema比如{ shape_type: box_with_hole, length: 100, width: 50, thickness: 5, hole_diameter: 20, hole_position: center }然后要求模型只输出 JSON不要解释。实测下来加上“只输出 JSON”和 few-shot 示例之后格式合规率能到 95% 以上。3.2 从 JSON 到 STEP 的完整代码路径拿到 JSON 之后几何生成就是按部就班的布尔运算。以“带中心孔的板”为例核心步骤是先建一个 Box再建一个 Cylinder然后做 Cut 布尔减。from OCC.Core.BRepPrimAPI import BRepPrimAPI_MakeBox, BRepPrimAPI_MakeCylinder from OCC.Core.BRepAlgoAPI import BRepAlgoAPI_Cut from OCC.Core.gp import gp_Pnt, gp_Ax2, gp_Dir from OCC.Core.STEPControl import STEPControl_Writer, STEPControl_AsIs # 建板 plate BRepPrimAPI_MakeBox(100, 50, 5).Shape() # 建孔位置在板中心轴向沿 Z center gp_Pnt(50, 25, 0) axis gp_Ax2(center, gp_Dir(0, 0, 1)) hole BRepPrimAPI_MakeCylinder(axis, 10, 5).Shape() # 布尔减 result BRepAlgoAPI_Cut(plate, hole).Shape() # 导出 STEP writer STEPControl_Writer() writer.Transfer(result, STEPControl_AsIs) writer.Write(plate_with_hole.step)这段代码跑通之后你就有了一个最基础的 text-to-cad 内核。剩下的工作是把 LLM 解析层接上去再加一个 Web 界面或 CLI 入口。注意布尔运算失败是家常便饭常见原因是两个实体没有真正相交、法线方向反了、或者公差设置不合理。排查的时候先把两个实体分别导出 STL 看一眼确认位置关系再查内核参数。3.3 参数校验与单位处理单位问题是 text-to-cad 里最容易被忽视、又最容易出大事的地方。用户说“长 100”到底是毫米还是厘米LLM 可能会默认成米然后你导出的 STEP 在 CAD 里打开发现是个 100 米长的巨物。我的做法是在解析层强制要求单位如果用户没写默认按毫米处理并在返回结果里标注“已按毫米解析”。同时加一个合理性检查如果某个尺寸超过 10000mm 或小于 0.1mm就触发警告让用户确认。这个阈值可以根据你的应用场景调整做消费级产品的话 1000mm 以上就该警惕了。另外STEP 文件本身是无单位的单位信息存在文件头里。导出时最好显式设置单位避免下游软件按英寸打开。4. 常见问题与排查技巧实录4.1 几何生成失败的典型原因text-to-cad 跑不通八成问题出在几何生成阶段。我整理了一个速查表覆盖最常见的几种情况。现象可能原因排查方法解决思路布尔运算返回空实体不相交或法线反向分别导出两个实体看位置调整位置参数或反转法线STEP 导出后打不开内核版本不兼容或文件损坏用 FreeCAD 试开换导出参数或降级内核孔的位置偏了坐标系定义不一致打印实体包围盒统一用全局坐标圆角失败半径大于相邻边长度检查圆角半径与边长关系减小半径或改顺序STL 面片数爆炸网格精度设太高查看文件大小降低线性偏差和角度偏差这张表里的每一条都是我实际踩过的。特别是“布尔运算返回空”这一条新手最容易懵——代码不报错但结果是个空壳。后来我养成了一个习惯每次布尔运算之后检查结果的体积是否大于零小于零或等于零就直接抛异常别让它静默通过。4.2 LLM 解析层的幻觉与兜底用 LLM 做文本解析最大的风险是它“自作主张”。你明明没说孔的位置它给你编一个“center”你说了“厚 5”它理解成“半径 5”。这些幻觉在文本层面看不出来到了几何层面就是灾难。我的兜底策略分三层。第一层是 schema 校验用 JSON Schema 检查必填字段和类型缺字段就追问。第二层是范围校验尺寸、角度、数量这些数值型参数都设上下限。第三层是几何可行性校验比如“孔径大于板厚”这种在建模时可能不报错但实际不合理的组合提前拦截。还有一个小技巧让 LLM 在输出 JSON 的同时输出一个“置信度”字段和“假设说明”字段。置信度低于阈值的请求转人工确认假设说明里写清楚它补了哪些默认值。这样用户至少知道模型替他做了哪些决定。4.3 格式转换的坑STL 转 STEP 为什么这么难热词里“sw 中 stl 转 stp”被搜了很多次说明这是很多人的痛点。这里必须说清楚STL 转 STEP 不是格式转换是逆向重建。STL 只有三角面片没有曲面信息转成 STEP 需要先做面片拟合、再重建 B-Rep这个过程叫“逆向工程”不是一键操作。SolidWorks 里有个 ScanTo3D 功能可以做这件事但效果取决于模型复杂度。简单规则零件还行复杂曲面基本重建出来没法用。所以如果你的 text-to-cad 工具输出的是 STL而用户想要 STEP正确的做法不是转格式而是从源头就用 B-Rep 内核生成。这也是我前面推荐 pythonocc 而不是纯 trimesh 的原因。5. 工具选型与场景适配建议5.1 不同场景下的技术路线选择text-to-cad 不是一个单一工具是一类能力的统称。选型的时候先问自己三个问题输出要什么格式用户是谁部署在哪里如果是给工程师用的内部工具输出 STEP、部署在装了 CAD 的工作站上那直接调 SolidWorks API 或中望 CAD 的二次开发接口最省事几何质量有保障。如果是给外部用户用的在线服务输出 STL/GLB 做预览那 OpenCASCADE 或 trimesh 加个 Web 前端就够了。如果是做 3D 打印社区的工具输出 STL 为主重点优化网格质量和打印可行性检查。我个人的偏好是 OpenCASCADE 打底STEP 和 STL 双输出LLM 解析层用 API 调用而不是本地部署。这样一套下来开发成本可控部署灵活精度也够用。5.2 与现有 CAD 工作流的衔接text-to-cad 生成的东西最终要回到 CAD 工作流里。这里有几个衔接点要注意。第一是坐标系和基准面。生成的模型最好以原点为中心或至少以某个明确基准对齐否则导入装配体之后还得手动挪。第二是命名和图层STEP 里可以带名称信息导出时把零件名、特征名写进去下游打开一目了然。第三是版本兼容STEP 有 AP203、AP214、AP242 几个版本AP242 支持颜色和 PMI但老软件可能不认。保险起见导出 AP214。如果你用的是中望 CAD 这类国产软件它的 API 和文件兼容性跟 SolidWorks 有差异测试的时候要覆盖到。我遇到过 STEP 在 SolidWorks 里正常、在中望里丢面的情况后来发现是曲面精度设置不一致调高导出精度就好了。5.3 性能与精度的平衡text-to-cad 做在线服务的话性能是个绕不开的问题。OpenCASCADE 的布尔运算在复杂模型上可能跑几秒到几十秒用户等不了。我的做法是分级处理简单零件同步生成复杂零件异步加进度提示。同时给 STL 预览设一个低精度快速生成STEP 高精度后台慢慢跑。精度方面STEP 导出时的线性偏差和角度偏差参数直接影响文件大小和后续可用性。默认值通常够用但如果你的零件有细小特征比如 0.5mm 的槽默认精度可能把它简化掉。这时候要把线性偏差调到 0.01mm 级别。代价是文件变大、生成变慢所以按需调整别一刀切。6. 我踩过的坑与实操心得6.1 那些文档里不会写的细节第一个坑是 pythonocc 的布尔运算顺序。先做哪个、后做哪个结果可能不一样。特别是多个特征叠加的时候顺序错了会出现意想不到的几何。我的经验是先加后减先大后小先主体后细节。第二个坑是 STEP 导出的单位。pythonocc 默认不写单位有些 CAD 打开会按英寸解释。解决办法是在导出前设置单位上下文或者在文件名里标注单位。我现在的习惯是文件名带_mm后缀比如plate_100x50x5_mm.step虽然土但管用。第三个坑是 LLM 的 token 限制。复杂零件的描述可能很长加上 few-shot 示例很容易超。解决办法是把 schema 精简到最小必要字段示例用最简形式长描述分段解析再合并。6.2 给想入坑的人几条实在建议如果你只是想快速验证一个想法别自己搭先用现成工具跑一遍感受一下 text-to-cad 的能力边界。现在有一些在线工具支持文本生成 STL虽然精度一般但足够让你判断这条路适不适合你的场景。如果你决定自己搭从最简单的零件类型开始比如板、圆柱、孔、槽这四种。把这四种的组合跑通覆盖 80% 的常见需求。别一上来就搞曲面、倒角、阵列那些是后期的事。最后测试用例要攒。每次遇到解析错误或几何失败把输入文本和期望结果存下来做成回归测试集。这个习惯我坚持了半年现在我的解析层准确率从最初的 60% 提到了 90% 以上靠的就是这套不断增长的测试集。6.3 后续可以扩展的方向text-to-cad 目前能处理的大多是规则几何体曲面和自由形状还是难点。一个可行的扩展方向是引入草图约束求解让用户用文本描述约束关系比如“这条边和那条边平行且等长”然后求解器算出具体坐标。另一个方向是结合图生 3D用户画个草图或拍张照模型提取轮廓再生成 CAD文本作为补充说明。这两个方向都有开源项目在探索感兴趣可以顺着 OpenCASCADE 和约束求解器这条线往下挖。我在实际项目里最大的体会是text-to-cad 的价值不在于完全替代手工建模而在于把“想法到可验证模型”的周期从小时级压缩到分钟级。它适合做前期概念验证和快速迭代精细调整还是得回到传统 CAD。把这个定位搞清楚工具选型和期望管理都会顺很多。