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 + OpenCASCADE（pythonocc-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。把这个定位搞清楚，工具选型和期望管理都会顺很多。
