1. 从一段文字到三维模型text-to-cad 到底在解决什么问题第一次听到 text-to-cad 这个词很多人脑子里浮现的画面大概是对着电脑敲一句“给我画一个带法兰的六角螺栓”然后屏幕上就自动旋转出一个可以导出 STEP 文件的三维实体。这个想象不算离谱但也没那么简单。text-to-cad 本质上是一类把自然语言描述转换成计算机辅助设计模型的技术方案集合它的输出通常落在 CAD 领域最常见的几种格式上STEP、GLB、STL。这三个格式几乎覆盖了从工业制造到可视化展示再到3D打印的全部下游场景所以围绕它们的转换链路才是 text-to-cad 真正要打通的关节。我在实际折腾这类工具的时候最深的感受是文本到 CAD 的难点从来不在“生成”这一步而在“生成的东西能不能用”。一个模型看起来像那么回事和它能不能被下游的 CAD 软件正确打开、能不能被切片软件识别、能不能被数控机床读懂完全是两码事。这也是为什么 text-to-cad 这个方向里STEP、GLB、STL 这三个词会反复出现——它们分别代表了三种截然不同的“可用性标准”。这篇文章适合谁看如果你是对 AI 生成三维模型好奇的开发者想搞清楚从文本到实体模型中间到底要经过哪些环节如果你是做机械设计、钣金、模具的从业者想知道这类工具能不能帮你省掉一些重复建模的力气或者你只是单纯想搞明白 STEP、GLB、STL 到底有什么区别、什么时候该用哪个——那这篇内容应该能给你一些能直接上手参考的东西。我会尽量把原理讲透把踩过的坑摊开把能抄的作业写清楚。需要先说明一点text-to-cad 目前还不是一个“输入一句话就万事大吉”的成熟产品形态它更像是一个正在快速演进的工具链组合。不同方案的能力边界差异很大有的擅长生成概念性的可视化模型有的能输出带精确尺寸的工程实体有的则只能给你一个网格壳子。理解这些差异比盲目追新更重要。2. 核心格式拆解STEP、GLB、STL 各自扮演什么角色2.1 STEP工程语义的载体制造业的通用语言STEP 的全称是 Standard for the Exchange of Product model data中文一般叫“产品模型数据交换标准”对应的标准编号是 ISO 10303。它不是一个简单的文件格式而是一整套描述产品全生命周期数据的体系。在实际使用中我们说的 STEP 文件通常指 AP203、AP214 或 AP242 这几种应用协议下的几何模型交换文件扩展名是.step或.stp。STEP 最核心的价值在于它保存的是B-rep边界表示几何也就是用精确的数学曲面NURBS 曲面、平面、圆柱面等来描述实体。这意味着一个直径 10mm 的圆柱在 STEP 里就是一个数学上精确的圆柱面而不是一堆小三角面片拼出来的近似物。这个区别在制造业里是致命的数控加工、公差分析、装配干涉检查全都依赖精确几何。你用 STL 去做这些事精度损失会让你怀疑人生。在 text-to-cad 的链路里STEP 通常是“最终交付物”的角色。文本生成模型之后如果这个模型要进入 SolidWorks、UG、Creo、中望CAD 这类工程软件继续编辑或者要交给加工厂那导出 STEP 就是必须的。但 STEP 的生成也是最难的因为它要求生成引擎真正理解“实体”和“特征”的概念而不是只会在空间里堆三角形。2.2 GLB可视化与交互场景的轻量选手GLB 是 glTF 格式的二进制版本glTF 全称 Graphics Language Transmission Format由 Khronos Group 维护常被称为“3D 界的 JPEG”。GLB 把模型的几何、材质、纹理、动画、场景层级全部打包进一个二进制文件加载速度快浏览器和移动端支持好。GLB 保存的几何通常是三角网格但它比 STL 强的地方在于它带材质、带颜色、带纹理坐标、带节点层级甚至能带骨骼动画。所以 GLB 的典型用武之地是网页 3D 展示、AR/VR 预览、产品配置器、游戏资产。如果你做 text-to-cad 是为了在网页上让用户转着看一个产品模型那 GLB 是首选STL 和 STEP 都不合适——STL 没材质没颜色STEP 文件体积大且浏览器基本没法直接渲染。2.3 STL3D 打印的事实标准但也就仅此而已STL 的历史可以追溯到 1987 年由 3D Systems 公司提出原本就是为立体光刻Stereolithography设备服务的。它的结构极其简单一堆三角面片的集合每个面片用三个顶点坐标和一个法向量描述。没有单位、没有材质、没有颜色、没有坐标系定义、没有拓扑关系。就是这么朴素。STL 分 ASCII 和二进制两种。ASCII 版可读但体积大二进制版紧凑但不可读。一个中等复杂度的模型ASCII STL 动辄几十兆二进制版可能只有几兆。这也是为什么网上流传的那些“STL 转 STP”的需求那么多——很多人手里只有 STL但下游要 STEP于是就得做格式转换。但这里有个残酷的事实STL 转 STEP 本质上是有损的逆向工程因为 STL 丢失了曲面信息转换工具只能通过拟合算法去猜原来的曲面是什么猜得好不好全看模型复杂度和工具能力。2.4 三种格式的关键差异对照维度STEPGLBSTL几何表示B-rep 精确曲面三角网格三角网格材质颜色支持AP242完整支持不支持单位信息有有需约定无文件体积中等小到中等大ASCII/中二进制浏览器渲染基本不支持原生支持需额外加载器3D 打印需转换需转换直接可用工程编辑原生支持不支持不支持典型工具SolidWorks、UG、FreeCADThree.js、Babylon.js、BlenderCura、PrusaSlicer、Blender这张表是我自己在选型时反复参考的基本上看完就能判断某个场景该用哪个格式。text-to-cad 的输出格式选择本质上就是在这三个维度上做取舍要精度和工程可用性就选 STEP要展示效果和加载速度就选 GLB要直接打印就选 STL。3. text-to-cad 的技术链路从一句话到可用的模型文件3.1 文本理解与意图解析第一步就决定了上限text-to-cad 的第一步是把自然语言变成结构化的建模意图。这一步的难度被严重低估了。人类说“一个边长 50mm 的立方体顶部中心有个直径 10mm、深 20mm 的孔”这句话里包含了基本体立方体、尺寸参数50mm、特征操作打孔、位置约束顶部中心、特征参数直径 10、深 20。模型需要把这些全部解析出来而且不能搞错“深 20”是孔深还是通孔。目前主流的做法有两种。一种是基于大语言模型做意图抽取让模型输出结构化的 JSON 或 DSL领域特定语言比如输出{primitive: box, size: [50,50,50], features: [{type: hole, diameter: 10, depth: 20, position: top_center}]}然后再由几何内核去执行。另一种是端到端生成直接把文本映射到几何表示比如用扩散模型生成点云或隐式场再转成网格。前者可控性强、精度高但需要预先定义好支持的建模操作集合后者灵活度高但精度和可编辑性差。我个人的经验是如果你的目标是生成工程可用的 STEP 文件那必须走第一条路也就是“文本 → 结构化指令 → 几何内核”的链路。端到端生成目前更适合做概念草图或者可视化模型离工程精度还有距离。3.2 几何内核OpenCASCADE 是绕不开的选择要把结构化指令变成真正的 B-rep 实体你需要一个几何内核。这个领域里OpenCASCADE简称 OCCT是开源方案里最成熟的选择没有之一。它提供了实体建模、布尔运算、倒角、抽壳、曲面拟合等全套能力而且能导出 STEP、IGES、STL 等多种格式。FreeCAD、KiCad 的 3D 查看器、不少商业 CAD 的底层都用它。用 OCCT 的典型流程是这样的先创建基本体BRepPrimAPI_MakeBox、BRepPrimAPI_MakeCylinder 等然后用布尔运算BRepAlgoAPI_Cut、BRepAlgoAPI_Fuse组合特征最后用 STEPControl_Writer 导出。代码层面大概长这样// 创建一个 50x50x50 的立方体 BRepPrimAPI_MakeBox boxMaker(50.0, 50.0, 50.0); TopoDS_Shape box boxMaker.Shape(); // 创建一个直径 10、高 20 的圆柱作为孔的刀具 gp_Ax2 axis(gp_Pnt(25, 25, 50), gp_Dir(0, 0, -1)); BRepPrimAPI_MakeCylinder cylMaker(axis, 5.0, 20.0); TopoDS_Shape cylinder cylMaker.Shape(); // 布尔减运算打孔 BRepAlgoAPI_Cut cutMaker(box, cylinder); TopoDS_Shape result cutMaker.Shape(); // 导出 STEP STEPControl_Writer writer; writer.Transfer(result, STEPControl_AsIs); writer.Write(output.step);这段代码看起来简单但实际用起来坑很多。比如布尔运算失败是家常便饭尤其是当两个面几乎相切或者有微小间隙的时候。OCCT 的布尔运算对模型的“干净程度”要求很高容差设置不当就会报错或者产生破面。我踩过的最典型的坑是用文本生成的尺寸如果带了浮点误差比如 49.999999 而不是 50布尔运算的成功率会明显下降。所以在把参数传给几何内核之前一定要做数值规整把尺寸对齐到合理的精度。3.3 网格生成与格式导出STL 和 GLB 的分岔路如果目标格式是 STL 或 GLB那在得到 B-rep 实体之后还需要做网格化meshing。OCCT 提供了 BRepMesh_IncrementalMesh 来做这件事核心参数是线性偏差linear deflection和角度偏差angular deflection。线性偏差控制弦高误差角度偏差控制相邻面片的法向夹角。这两个参数直接决定了网格的精细度和文件体积。// 网格化线性偏差 0.1mm角度偏差 0.5 弧度 BRepMesh_IncrementalMesh mesher(shape, 0.1, Standard_False, 0.5, Standard_True);线性偏差设 0.1mm 意味着曲面被近似成三角面片时最大偏差不超过 0.1mm。对于 3D 打印来说这个精度通常够了但如果模型很大或者曲面很平缓0.1mm 会产生海量三角形文件体积爆炸。我的经验是小零件用 0.05~0.1mm中等零件用 0.2~0.5mm大尺寸展示模型用 1mm 以上。角度偏差一般设 0.3~0.5 弧度太小了没必要太大了曲面会有明显棱角感。导出 STL 用 StlAPI_Writer导出 GLB 则通常需要先转成 glTF 的中间结构。OCCT 本身不直接支持 GLB 导出常见做法是先把网格导出成 OBJ 或直接操作三角形数据再用 glTF 库比如 tinygltf组装成 GLB。这一步的坑在于法向量和材质STL 只需要面法向量GLB 还需要顶点法向量、UV 坐标、材质定义。如果从 B-rep 直接生成 GLB材质信息基本是丢失的需要额外指定。3.4 三种输出格式的生成成本对比环节STEPGLBSTL是否需要几何内核必须可选可选是否需要网格化不需要需要需要典型生成耗时快中等中等精度可控性高中中下游编辑能力强弱无实现复杂度高中低这张表解释了一个现象为什么很多 text-to-cad 的 demo 只输出 STL 或 GLB而不输出 STEP。因为 STEP 的生成链路最长、对几何内核依赖最重、容错空间最小。但反过来只有 STEP 才是真正能进入工程流程的格式。这是一个典型的“容易做的没用有用的不容易做”的局面。4. 实操落地搭一条能跑的 text-to-cad 最小链路4.1 环境准备与依赖选型要自己搭一条 text-to-cad 的链路我建议从 Python 入手因为生态最全、调试最方便。核心依赖有这么几个Python 3.10版本不要太老很多几何库对新版本支持更好。pythonocc-coreOCCT 的 Python 绑定通过 conda 安装最省事conda install -c conda-forge pythonocc-core。trimesh处理网格的瑞士军刀STL、OBJ、GLB 的读写和转换都能做。numpy数值计算基础网格操作离不开。openai 或类似 SDK如果你要用大语言模型做文本解析。这里重点说一下 pythonocc-core 的安装。它是整个链路里最容易出问题的环节。pip 直接装基本会失败因为 OCCT 的 C 库需要编译。用 conda 是最稳的路径conda-forge 频道有预编译好的包。如果你在 Windows 上建议用 Miniconda 而不是完整版 Anaconda避免环境太臃肿。Linux 上相对顺利但要注意系统里如果已经有 OCCT 的库可能会和 conda 里的版本冲突最好在干净的虚拟环境里操作。提示pythonocc-core 的版本要和 OCCT 主版本对应比如 7.7.x 对应 OCCT 7.7。版本不匹配会出现各种奇怪的导入错误排查起来很费时间。4.2 文本解析层的实现思路文本解析层我建议用“大语言模型 结构化输出约束”的方式。具体做法是定义一个 JSON Schema描述支持的建模操作然后让模型按这个 Schema 输出。比如import json from openai import OpenAI client OpenAI() schema { type: object, properties: { primitives: { type: array, items: { type: object, properties: { type: {enum: [box, cylinder, sphere]}, params: {type: object}, position: {type: array, items: {type: number}} } } }, operations: { type: array, items: { type: object, properties: { op: {enum: [cut, fuse, intersect]}, target: {type: integer}, tool: {type: integer} } } } } } prompt 把下面的描述转成建模指令 JSON 一个 50mm 立方体顶部中心打一个直径 10mm、深 20mm 的孔。 只输出 JSON不要解释。 response client.chat.completions.create( modelgpt-4o, messages[{role: user, content: prompt}], response_format{type: json_object} ) instructions json.loads(response.choices[0].message.content) print(instructions)这个思路的关键在于约束输出格式。如果不加约束模型可能会输出一段自然语言解释或者用不同的字段名后续代码就没法稳定解析。用 JSON mode 或者 function calling 能大幅提升稳定性。另外提示词里要明确单位默认毫米、坐标系约定Z 轴向上还是 Y 轴向上、以及“只输出 JSON”这样的硬性要求。4.3 几何构建与布尔运算的实操细节拿到结构化指令后就可以用 pythonocc 构建几何了。这里我把上面那段 C 逻辑用 Python 重写一遍顺便加上容差处理和错误捕获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 from OCC.Core.IFSelect import IFSelect_RetDone def build_model(instructions): shapes [] for prim in instructions[primitives]: if prim[type] box: l, w, h prim[params][size] shape BRepPrimAPI_MakeBox(l, w, h).Shape() elif prim[type] cylinder: r prim[params][radius] h prim[params][height] axis gp_Ax2(gp_Pnt(*prim[position]), gp_Dir(0, 0, 1)) shape BRepPrimAPI_MakeCylinder(axis, r, h).Shape() shapes.append(shape) result shapes[0] for op in instructions[operations]: if op[op] cut: cutter BRepAlgoAPI_Cut(result, shapes[op[tool]]) cutter.SetFuzzyValue(1e-5) # 设置容差 cutter.Build() if not cutter.IsDone(): raise RuntimeError(布尔运算失败) result cutter.Shape() return result def export_step(shape, path): writer STEPControl_Writer() writer.Transfer(shape, STEPControl_AsIs) status writer.Write(path) if status ! IFSelect_RetDone: raise RuntimeError(STEP 导出失败)这里有几个实操要点值得展开。第一SetFuzzyValue是布尔运算的容差设置默认值有时候太小导致本该成功的运算失败。设成 1e-5 到 1e-4 之间通常比较稳但也不能太大否则会“吃掉”本该保留的细节。第二布尔运算之后一定要检查IsDone()不能假设它一定成功。第三导出 STEP 之后最好用ReadSTEP再读回来验证一遍确保文件没有损坏。4.4 网格化与 STL/GLB 导出的参数选择如果目标格式是 STL在得到 B-rep 之后做网格化再导出from OCC.Core.BRepMesh import BRepMesh_IncrementalMesh from OCC.Core.StlAPI import StlAPI_Writer def export_stl(shape, path, linear_deflection0.1, angular_deflection0.5): BRepMesh_IncrementalMesh(shape, linear_deflection, False, angular_deflection, True) writer StlAPI_Writer() writer.SetASCIIMode(False) # 二进制模式体积更小 writer.Write(shape, path)如果目标格式是 GLB我建议走 trimesh 这条路因为 pythonocc 直接生成 GLB 比较麻烦。可以先把网格导出成临时 STL 或 OBJ再用 trimesh 读进来转 GLBimport trimesh def stl_to_glb(stl_path, glb_path): mesh trimesh.load(stl_path) mesh.export(glb_path, file_typeglb)trimesh 的export会自动处理顶点法向量和基本的材质。如果你需要更精细的材质控制可以手动构造trimesh.visual.TextureVisuals再赋值给 mesh。GLB 的一个常见问题是坐标系约定glTF 默认 Y 轴向上而 CAD 通常 Z 轴向上。转换的时候如果不做旋转模型在网页里看就是躺着的。这个坑我踩过不止一次解决办法是在导出前对 mesh 做一次绕 X 轴 -90 度的旋转。4.5 一条完整链路的串联与验证把上面这些环节串起来一个最小的 text-to-cad 流程就是接收文本描述调用大语言模型解析成结构化 JSON用 pythonocc 构建 B-rep 实体根据目标格式分岔STEP 直接导出STL/GLB 先网格化再导出验证输出文件能被对应工具打开验证这一步千万别省。STEP 用 FreeCAD 或在线查看器打开STL 用切片软件打开GLB 用浏览器或 Blender 打开。我见过太多次“代码跑通了但文件打不开”的情况原因五花八门有的是编码问题有的是单位问题有的是网格法向量反了导致渲染全黑。自动化测试里至少要有一步是“用独立工具重新加载生成的文件”这能拦住大部分低级错误。5. 常见问题与排查技巧实录5.1 布尔运算失败最常见也最头疼布尔运算失败是 text-to-cad 链路里出现频率最高的问题。表现是IsDone()返回 False或者返回 True 但结果形状是空的。原因通常有这么几类面重合或相切两个实体的面完全贴合内核无法判断内外。解决办法是让刀具稍微超出目标体比如打孔时孔的深度比实体厚度多 1mm。容差过小模型尺寸大但容差设得小微小间隙导致运算失败。适当调大SetFuzzyValue。自相交生成的实体本身有自相交面布尔运算前需要先修复。数值精度浮点误差累积导致本该重合的顶点没重合。在传入几何内核前对参数做 round 处理。我的经验是打孔、切槽这类减运算刀具一定要“穿透”目标体不要让刀具的底面和目标体的底面正好齐平。多切出去一点布尔运算的成功率会高很多而且不影响最终结果。5.2 STL 转 STEP 的精度陷阱很多人手里只有 STL想转成 STEP 继续编辑。这里必须说清楚STL 转 STEP 不是格式转换是逆向重建。STL 里只有三角面片没有曲面信息转换工具要做的是从面片拟合出曲面。对于平面和规则圆柱面拟合效果通常不错但对于自由曲面拟合出来的 NURBS 曲面和原始设计可能差很多。实操中的建议是如果 STL 的三角面片很密线性偏差小转换效果会好一些如果面片很粗转换出来的 STEP 基本没法用于精密加工。另外转换后的 STEP 文件里会有大量碎面需要做“缝合”和“简化”处理否则后续编辑会很痛苦。FreeCAD 的 Part 工作台里有“从网格创建形状”和“细化形状”的工具可以试试但别期望太高。5.3 GLB 在浏览器里显示异常GLB 导出后在网页里显示异常常见原因有三个。第一是坐标系问题前面提过glTF 是 Y 轴向上CAD 是 Z 轴向上不做旋转模型就是躺着的。第二是法向量问题如果法向量反了模型会全黑或者光照诡异。trimesh 通常会自动处理但如果手动构造网格就要注意。第三是材质缺失从 STL 转过来的 GLB 没有材质默认是灰色如果场景背景也是灰色就看不清了需要手动指定一个材质。5.4 常见问题速查表问题现象可能原因排查方向解决建议布尔运算返回空面重合/相切检查刀具与目标体的位置关系让刀具穿透目标体STEP 导出后打不开编码或版本问题用 FreeCAD 尝试打开检查 OCCT 版本和写入模式STL 文件体积过大网格精度过高检查线性偏差设置调大 linear deflectionGLB 模型全黑法向量反向在 Blender 里查看法向重新计算法向量GLB 模型躺倒坐标系不一致检查导出时的旋转绕 X 轴旋转 -90 度文本解析结果不稳定提示词约束不足检查是否用了 JSON mode加 schema 约束和示例圆柱面有棱角角度偏差过大检查 angular deflection调小到 0.3 左右尺寸偏差 0.001mm浮点误差检查参数传入前的精度做 round 规整这张表是我自己排查问题时总结的基本上覆盖了八成以上的常见故障。遇到问题先对照这张表过一遍能省不少时间。5.5 几个容易被忽略的实操心得第一个心得是单位统一。text-to-cad 链路里文本里的单位、几何内核的单位、导出文件的单位三者必须一致。OCCT 内部默认是毫米STEP 文件里会记录单位STL 文件不记录单位这是个历史遗留问题GLB 用米。如果不做统一导出的模型尺寸可能差 1000 倍。我的做法是全程用毫米导出 GLB 时再除以 1000 转成米。第二个心得是给生成结果加一个“合理性检查”。比如检查包围盒尺寸是否在合理范围内、体积是否为正、面数是否超过阈值。这些检查能拦住很多“看起来生成了但实际是垃圾”的情况。我见过模型生成了一个体积为负的实体导出 STL 后切片软件直接报错。第三个心得是保留中间产物。文本解析出的 JSON、构建的 B-rep、网格化的中间结果都存下来。出问题的时候可以逐环节排查而不是面对一个黑盒干瞪眼。这个习惯在调试复杂模型时特别有用。6. 工具选型与扩展方向的一些个人判断6.1 几何内核的选型对比除了 OpenCASCADE还有几个选择值得了解。CGAL在计算几何算法上很强但实体建模的易用性不如 OCCT。Manifold是近年新兴的网格布尔运算库速度快、鲁棒性好但只处理网格不处理 B-rep。Parasolid和ACIS是商业内核精度和稳定性一流但授权费用高个人项目基本不会考虑。对于 text-to-cad 这个场景我的判断是要输出 STEP 就必须用 OCCT 或商业内核要输出 STL/GLB 可以考虑 Manifold 这类网格库。OCCT 的学习曲线陡文档也不算友好但它是开源方案里唯一能覆盖从基本体到复杂布尔运算再到多格式导出的完整链路的选择。pythonocc-core 虽然有些 API 设计得反直觉但用熟了效率不低。6.2 文本解析方案的演进文本解析这块从早期的规则匹配到现在的 LLM 驱动进步是肉眼可见的。规则匹配的优点是确定性强、速度快缺点是只能处理预定义的句式稍微换个说法就歇菜。LLM 的优点是泛化能力强能理解各种口语化描述缺点是有幻觉风险、输出不稳定、依赖外部服务。我目前的建议是混合方案用 LLM 做第一层解析输出结构化 JSON然后用规则做第二层校验检查参数是否在合理范围、操作序列是否合法。这样既保留了 LLM 的灵活性又用规则兜住了底线。比如 LLM 解析出“孔深 200mm”但实体只有 50mm 厚规则层就应该报警或者自动修正。6.3 从概念验证到生产可用的距离一个 text-to-cad 的 demo 和一个能用的工具之间差距主要在鲁棒性和可编辑性上。Demo 只需要在理想输入下跑通一次生产工具要面对各种奇怪的输入、各种边界情况、各种下游软件的兼容性要求。可编辑性则意味着生成的模型不能是一坨死几何而应该有特征树、有参数、能修改。目前大部分 text-to-cad 方案输出的 STEP 都是“哑实体”没有特征历史改一个尺寸就得重新生成。这个方向后续的扩展空间很大。比如可以往参数化模板方向走预定义一批常用零件模板法兰、齿轮、支架文本只负责填参数这样生成质量和可编辑性都有保障。也可以往多轮对话建模方向走用户说“再高一点”“孔往左移 5mm”系统增量修改模型。这些都比“一句话生成任意模型”更现实、更有落地价值。6.4 一些实用的小技巧收尾最后分享几个我在实操中攒下的小技巧。导出 STL 之前用trimesh检查一下网格是否 watertight水密不水密的网格切片会出问题。导出 STEP 之前用 OCCT 的ShapeAnalysis_ShapeTolerance检查一下全局容差容差过大说明模型有问题。生成 GLB 的时候如果模型面数超过 10 万考虑做一次简化否则网页加载会卡。还有一个关于文件命名的建议生成的模型文件名里带上时间戳和关键参数比如box_50mm_hole10_20250101.step。这样批量生成的时候不会互相覆盖回溯的时候也方便。这个习惯看起来不起眼但项目一复杂就能救命。text-to-cad 这个方向现在还在快速变化工具链每个月都有新东西出来。我的态度是保持关注但别盲目追新把 STEP、GLB、STL 这三个格式的脾气摸透把几何内核的基本功练扎实不管上层怎么变底层的东西是不变的。