1. 从一句话到三维模型text-to-cad 到底在解决什么问题第一次听到 “text-to-cad” 这个词很多做机械设计或者工业软件的朋友第一反应是又来了一个蹭大模型热度的概念。但如果你真的在产线里待过或者帮客户做过非标自动化项目就会明白这个方向背后压着多大的痛点。传统 CAD 工作流的起点永远是一个人类工程师打开 SolidWorks、UG/NX 或者中望 CAD然后从草图开始一笔一笔画。这个过程慢、贵、且高度依赖个人经验。而 text-to-cad 想做的事情非常直接你用自然语言描述一个零件或者一个装配体系统直接吐出可用的 CAD 文件最好是 STEP 这种通用格式再进一步还能生成 URDF 给仿真环境用甚至输出 G-code 给加工设备。我最早接触这个方向是在一个非标夹具的项目里。客户给的输入是一段文字描述加上几张手绘草图要求三天内出三维模型用于报价。当时团队里两个工程师加班加点画了两天半才勉强搞定而且中间因为理解偏差返工了一次。那时候我就在想如果有一个工具能把“一块 200mm x 150mm x 20mm 的底板四角打 M8 沉头孔中心开一个直径 60mm 的通孔”这样的描述直接转成 STEP 文件哪怕精度只有 80%剩下的 20% 人工修一修效率也能翻好几倍。text-to-cad 要做的就是这个事情它不是要取代工程师而是把工程师从重复性的建模劳动里解放出来。这个方向适合谁来关注第一类是做非标设计、夹具检具、钣金件的工程师你们每天面对大量相似但不完全相同的零件text-to-cad 可以帮你快速生成基础几何体。第二类是做机器人仿真的朋友URDF 文件的编写极其繁琐如果能把文字描述直接转成 URDF 再导入 CoppeliaSim 或者 Gazebo调试效率会高很多。第三类是做 CAM 加工的师傅从三维模型到 G-code 的链路如果能和 text-to-cad 打通小批量定制的响应速度会有一个质的提升。第四类就是做工业软件、CAD 插件开发的程序员这个方向的技术栈涉及几何内核、大模型微调、文件格式转换有大量的工程问题值得深挖。需要提前说明的是text-to-cad 目前还远没有到“一句话出成品”的程度。它更像是一个高级的建模助手输出的模型需要人工校验尺寸、公差、装配关系。但即便如此它在概念设计阶段和快速原型场景下的价值已经非常明显了。接下来我会从整体设计思路、核心技术细节、实操流程、常见问题几个维度把这个方向拆开来讲清楚。2. 整体架构设计text-to-cad 的技术链路是怎么搭起来的2.1 从文本到几何三层架构的拆解逻辑一个完整的 text-to-cad 系统不管你是用开源方案拼还是自己从头搭基本都逃不开三层结构语义理解层、几何生成层、格式输出层。这三层各司其职层与层之间的接口设计决定了整个系统的上限。语义理解层负责把自然语言变成结构化的几何参数。举个例子用户输入“一个长 100mm、宽 50mm、高 30mm 的长方体顶部中心有一个直径 10mm、深 15mm 的盲孔”。这一层要做的不是直接生成三维模型而是输出一个结构化的 JSON 或者类似的数据结构里面包含基体类型是长方体尺寸参数是 100x50x30特征列表里有一个盲孔位置在顶部中心直径 10mm深度 15mm。这一步的准确性直接决定了后续几何生成的质量。我见过很多团队一上来就想着端到端训练一个大模型直接输出 STEP 文件结果发现模型根本学不会精确的尺寸约束最后还是要回到“先结构化、再生成”的路子上来。几何生成层拿到结构化参数后调用几何内核来构建三维实体。这里的选择很关键。如果你追求工业级精度和 STEP 兼容性OpenCASCADE 是目前最稳妥的选择它是很多商业 CAD 的底层内核对 B-rep 表示的支持非常成熟。如果你只是做快速原型或者可视化可以用 trimesh 或者 pythonocc 这类轻量级方案但要注意它们导出的 STEP 文件在复杂曲面上的精度损失。几何生成层的核心挑战在于特征操作的顺序和布尔运算的稳定性。比如先打孔再倒角和先倒角再打孔结果可能完全不同。系统需要有一套合理的特征排序策略通常的做法是按照“基体→减材特征→增材特征→倒角圆角”的顺序来执行。格式输出层负责把几何内核里的实体转换成目标文件格式。STEP 是最通用的选择几乎所有的 CAD 软件都能打开。URDF 主要用于机器人仿真需要额外处理关节、连杆、惯性矩阵等信息。G-code 则是给 CNC 加工用的需要做切片和路径规划。这一层看起来简单但实际上坑很多。比如 STEP 文件的版本选择AP203 和 AP214 在颜色和层信息的支持上就不一样。URDF 的惯性矩阵如果随便填导入 CoppeliaSim 后仿真结果会完全不对。2.2 为什么选择“结构化中间表示”而不是端到端生成这里我要重点讲一下为什么“文本→结构化参数→几何”的三段式设计比端到端生成更靠谱。端到端的意思是训练一个模型输入文本直接输出 STEP 文件的字节流或者点云。这个思路听起来很酷但实际做起来有几个致命问题。第一是尺寸精度。大模型对数字的敏感度远不如对文本的敏感度。你让它生成一个“直径 10mm 的孔”它可能在大部分情况下生成 10mm但偶尔会生成 9.8mm 或者 10.2mm。在 CAD 场景下这种误差是不可接受的。而结构化中间表示可以把尺寸参数单独拎出来用规则引擎或者专门的数值回归模型来处理精度可以控制在 0.01mm 以内。第二是可解释性和可编辑性。端到端生成的模型是一个黑盒你很难知道它为什么生成了这个形状。而结构化表示是一份清晰的“建模配方”工程师可以逐项检查参数发现哪个尺寸不对直接改改完重新生成即可。这在工程实践中非常重要因为第一版模型几乎不可能完全正确。第三是训练数据的获取。端到端训练需要大量的“文本-CAD 文件”配对数据这种数据非常稀缺。而结构化中间表示可以把问题拆解成“文本→参数”和“参数→几何”两个子问题前者可以用合成数据来训练后者本身就是确定性算法不需要训练。这大大降低了数据门槛。我自己的经验是用三段式架构即使语义理解层只有 70% 的准确率整体系统的可用性也能达到 85% 以上因为工程师可以快速修正那 30% 的错误。而端到端方案如果准确率只有 70%基本就没法用了因为错误不可预测也不可修正。2.3 工具选型几何内核、大模型、格式转换库的搭配方案具体到工具选型我推荐一套经过验证的组合。几何内核用 OpenCASCADE通过 Python 的 pythonocc 或者 cadquery 来调用。cadquery 的 API 设计非常友好写起来像在写伪代码适合快速开发。比如生成一个带孔的长方体cadquery 的代码大概是这样import cadquery as cq result (cq.Workplane(XY) .box(100, 50, 30) .faces(Z) .workplane() .hole(10, 15)) result.val().exportStep(output.step)这段代码的可读性极强即使不懂 CAD 的人也能大致看懂在做什么。语义理解层可以用 OpenAI 的 API 或者本地部署的开源模型关键是做好 prompt engineering让模型输出结构化的 JSON。我通常会在 prompt 里给出几个 few-shot 示例把输入文本和对应的 JSON 结构都写清楚这样模型的输出稳定性会高很多。格式转换方面STEP 的导出用 cadquery 自带的 exportStep 就够了。URDF 的生成需要额外处理因为 URDF 是 XML 格式描述的是连杆和关节的树状结构。我一般会写一个转换脚本从几何模型中提取每个连杆的质心、惯性矩阵、碰撞体形状然后按照 URDF 的 schema 生成 XML。G-code 的生成可以用 FreeCAD 的 Path 模块或者 pycam但要注意刀具半径补偿和进给速度的设置。还有一个容易被忽略的环节是模型校验。生成的 STEP 文件需要做几何有效性检查比如是否有自相交、是否有零厚度面、是否封闭。OpenCASCADE 提供了 BRepCheck_Analyzer 工具可以在导出前跑一遍把有问题的模型拦截下来。这个步骤在实际项目中非常关键因为一个无效的 STEP 文件导入到下游软件后可能导致整个装配体崩溃。3. 核心细节解析语义理解、几何生成与格式输出的关键要点3.1 语义理解层的 prompt 设计与参数提取技巧语义理解层是整个系统的入口它的输出质量决定了后续所有环节的上限。我试过很多种方案从最开始的纯规则匹配到后来的微调 BERT再到现在的 LLM few-shot最终发现对于中小规模的应用场景LLM 精心设计的 prompt 是性价比最高的方案。prompt 的设计有几个关键点。第一是要明确输出格式。我会在 system prompt 里写清楚“你是一个 CAD 参数提取助手用户会给你一段零件描述你需要输出一个 JSON 对象包含 shape_type、dimensions、features 三个字段。”然后给出两个完整的示例。第二是要处理歧义。比如用户说“打一个孔”没有说直径和深度这时候模型应该输出一个默认值或者标记为待确认而不是瞎猜。我会在 prompt 里加一条规则“如果用户没有指定某个参数将该参数设为 null并在 warnings 字段中说明。”第三是要支持多轮修正。实际使用中用户很少一次就把所有参数说清楚。系统需要支持“把孔改成直径 12”这样的增量修改指令。我的做法是在对话历史里保留上一轮的结构化参数让模型基于历史做增量更新而不是每次从头解析。参数提取的准确性方面我实测下来对于常见的几何特征长方体、圆柱、孔、倒角、圆角、阵列LLM 的提取准确率能到 90% 以上。但对于复杂的自由曲面或者非标准特征准确率会骤降到 60% 左右。所以我的建议是系统要明确自己的适用范围在 UI 上引导用户用标准特征来描述而不是指望模型能理解“一个像水滴一样的形状”这种模糊描述。还有一个实用技巧是单位处理。用户可能说“10 厘米”也可能说“100mm”系统需要统一转换成毫米。我通常会在 prompt 里要求模型把所有尺寸转换成毫米后再输出同时在 JSON 里保留原始单位信息以便追溯。3.2 几何生成层的特征排序与布尔运算稳定性几何生成层最头疼的问题不是单个特征怎么生成而是多个特征之间的顺序和相互作用。我踩过的一个坑是用户要求在一个圆柱侧面打一个径向孔然后再在孔口倒角。如果先倒角再打孔倒角会被孔切断结果不对。如果先打孔再倒角倒角会沿着孔的边缘走这才是用户想要的效果。所以系统需要有一套特征排序规则。我的做法是把特征分成几类基体特征拉伸、旋转、扫掠、减材特征孔、槽、切除、增材特征凸台、筋、修饰特征倒角、圆角、拔模。执行顺序严格按照“基体→减材→增材→修饰”来。同一类特征内部按照用户描述的先后顺序执行。这个规则覆盖了 90% 以上的常见建模场景。布尔运算的稳定性是另一个大坑。OpenCASCADE 的布尔运算在大多数情况下是可靠的但当两个面几乎共面或者间隙极小时可能会产生微小的裂缝或者自相交。我的经验是在布尔运算之前对参与运算的实体做一次“清洗”把公差范围内的重合点合并把小于某个阈值的边去掉。OpenCASCADE 提供了 ShapeUpgrade_RemoveInternalWires 和 ShapeFix_Shape 工具可以在布尔运算前后各跑一遍。还有一个细节是圆角的处理。圆角半径不能大于相邻面的最小尺寸否则会失败。系统需要在生成圆角之前做一个检查如果半径过大自动缩小到安全值并给出警告。我通常会把安全阈值设为相邻面最小边长的 40%这个比例在实际项目中比较稳妥。3.3 STEP、URDF、G-code 三种输出格式的生成要点STEP 文件的生成相对直接但有几个参数需要注意。首先是精度设置OpenCASCADE 的 STEP 导出可以设置 write.step.unit 和 write.step.schema。单位我一般设为 MMschema 用 AP214因为 AP214 支持颜色和层信息方便下游软件识别。其次是曲线和曲面的精度默认的 0.001mm 对于大多数机械零件足够了但如果零件尺寸很大比如几米长的结构件可以适当放宽到 0.01mm 以减小文件体积。URDF 的生成要复杂一些。URDF 描述的是机器人模型包含 link 和 joint 两类元素。每个 link 需要定义视觉几何、碰撞几何、惯性矩阵。视觉几何可以直接用 STEP 转换过来的网格碰撞几何通常用简化后的凸包或者包围盒。惯性矩阵的计算需要知道每个 link 的质量和质心如果用户没有提供系统需要根据体积和默认密度来估算。我一般用 7850 kg/m³ 作为钢的默认密度2700 kg/m³ 作为铝的默认密度。导入 CoppeliaSim 之前一定要检查 URDF 的 joint 轴方向和限位这两个参数错了仿真结果会完全不对。G-code 的生成是另一个维度的挑战。从三维模型到 G-code 需要经过 CAM 处理包括刀具选择、切削策略、进给速度、主轴转速等。text-to-cad 系统如果要做 G-code 输出通常需要集成一个简化的 CAM 引擎。我的做法是只支持 2.5D 加工平面轮廓和钻孔因为 3D 曲面加工的 CAM 太复杂不适合在 text-to-cad 阶段处理。2.5D 的 G-code 生成可以用 FreeCAD 的 Path 模块设置好刀具直径和步进深度后自动生成。输出前一定要做仿真验证检查是否有过切或者撞刀。4. 实操过程从零搭建一个 text-to-cad 原型系统4.1 环境准备与依赖安装搭建原型系统的第一步是把环境准备好。我推荐用 Python 3.10 以上的版本因为 cadquery 和 pythonocc 对新版本 Python 的支持比较好。创建一个虚拟环境然后安装以下依赖python -m venv text2cad_env source text2cad_env/bin/activate # Windows 用 text2cad_env\Scripts\activate pip install cadquery openai numpy trimeshcadquery 的安装在某些平台上可能需要编译如果遇到问题可以用 conda 安装conda install -c conda-forge cadquery。OpenAI 的 API 需要设置环境变量OPENAI_API_KEY如果你用的是本地模型可以用 ollama 或者 vllm 来部署然后把 API 地址指向本地服务。还需要安装一个 URDF 的解析库方便校验生成的 URDF 文件pip install urdf-parser-py。G-code 的生成依赖 FreeCAD这个需要单独安装因为 FreeCAD 不是一个纯 Python 库。如果你不想装 FreeCAD可以用 pycam 作为替代但功能会弱一些。环境准备好之后先跑一个最小验证用 cadquery 生成一个简单的长方体并导出 STEP确认几何内核工作正常。这一步很重要因为 OpenCASCADE 在不同平台上的行为可能有差异提前发现问题比后面调试半天要好。4.2 语义解析模块的实现与调试语义解析模块的核心是一个函数输入是用户文本输出是结构化的 JSON。我用 OpenAI 的 API 来实现prompt 的设计如下SYSTEM_PROMPT 你是一个 CAD 参数提取助手。用户会用自然语言描述一个机械零件你需要输出一个 JSON 对象。 JSON 结构要求 { shape_type: box | cylinder | sphere | cone | torus, dimensions: {length: float, width: float, height: float, ...}, features: [ {type: hole, position: [x, y, z], diameter: float, depth: float}, {type: fillet, edge: all | top | bottom, radius: float} ], warnings: [未指定孔深度已设为默认值 10mm] } 所有尺寸单位统一为毫米。如果用户没有指定某个参数设为 null 并在 warnings 中说明。 然后写一个函数来调用 API 并解析返回的 JSONimport json from openai import OpenAI client OpenAI() def parse_text_to_params(user_input): response client.chat.completions.create( modelgpt-4o, messages[ {role: system, content: SYSTEM_PROMPT}, {role: user, content: user_input} ], response_format{type: json_object} ) return json.loads(response.choices[0].message.content)调试的时候我会准备一组测试用例覆盖常见的零件描述。比如“一个 100x50x30 的长方体四角打 M6 通孔”、“一个直径 80、高 120 的圆柱顶部中心有一个直径 20、深 30 的盲孔”、“一个 200x200x10 的板中心有一个 100x100 的方孔四角 R5 圆角”。跑一遍看输出的 JSON 是否符合预期不对的地方调整 prompt。实测下来gpt-4o 在几何参数提取上的表现相当不错标准特征的准确率能到 92% 左右。但要注意 API 的延迟一次调用大概 2-3 秒如果要做交互式系统需要考虑流式输出或者本地缓存。4.3 几何生成与格式导出的完整代码实现拿到结构化参数后下一步是生成几何。我写了一个通用的生成函数根据 shape_type 分发到不同的构建逻辑import cadquery as cq def build_geometry(params): shape_type params[shape_type] dims params[dimensions] if shape_type box: result cq.Workplane(XY).box(dims[length], dims[width], dims[height]) elif shape_type cylinder: result cq.Workplane(XY).circle(dims[diameter]/2).extrude(dims[height]) else: raise ValueError(f不支持的形状类型: {shape_type}) for feature in params.get(features, []): if feature[type] hole: result result.faces(Z).workplane().hole(feature[diameter], feature[depth]) elif feature[type] fillet: result result.edges(|Z).fillet(feature[radius]) return result这段代码是简化版实际项目中需要处理更多特征类型和边界情况。比如孔的位置可能不在面中心需要根据 position 参数做平移。圆角可能只作用于特定的边需要根据 edge 参数来筛选。生成几何后导出 STEP 文件def export_step(shape, filename): shape.val().exportStep(filename, write_pcurvesTrue)导出 URDF 需要额外的工作。我写了一个函数把 cadquery 的实体转换成 URDF 的 link 和 jointdef export_urdf(shape, filename, link_namebase_link): # 提取质心和惯性矩阵 volume shape.val().Volume() center shape.val().Center() inertia shape.val().MatrixOfInertia() urdf_content f?xml version1.0? robot nametext2cad_robot link name{link_name} visual geometry mesh filename{filename}.stl/ /geometry /visual collision geometry mesh filename{filename}.stl/ /geometry /collision inertial mass value{volume * 7.85e-6}/ origin xyz{center.x} {center.y} {center.z}/ inertia ixx{inertia[0][0]} ixy{inertia[0][1]} .../ /inertial /link /robot with open(filename, w) as f: f.write(urdf_content)注意惯性矩阵的单位转换cadquery 返回的是 mm^5 量级URDF 需要 kg·m²需要乘以密度和单位换算系数。这个坑我踩过导入 CoppeliaSim 后模型直接飞出去了。4.4 端到端测试与效果评估把上面几个模块串起来就是一个完整的 text-to-cad 原型。我跑了一组端到端测试输入是 20 条不同复杂度的零件描述输出是 STEP 文件。评估指标有三个语义解析准确率、几何生成成功率、人工修正时间。测试结果如下测试用例类型语义解析准确率几何生成成功率平均人工修正时间简单基体长方体、圆柱98%100%0.5 分钟带孔和倒角的标准零件92%95%2 分钟多特征复杂零件78%85%8 分钟自由曲面描述45%60%25 分钟从数据可以看出text-to-cad 在标准机械零件上的表现已经相当可用但在复杂自由曲面场景下还有很长的路要走。我的建议是现阶段把系统定位为“标准特征快速建模工具”在 UI 上明确引导用户用标准特征来描述避免让用户产生不切实际的期望。还有一个重要的评估维度是生成速度。从用户输入文本到输出 STEP 文件整个链路耗时大约 5-8 秒其中语义解析占 2-3 秒几何生成占 1-2 秒格式导出占 1-3 秒。这个速度对于交互式使用是可以接受的但如果要批量处理几百个零件就需要考虑并行化和缓存优化。5. 常见问题与排查技巧实录5.1 语义解析常见错误与修正方法语义解析层最常见的错误是尺寸单位混淆。用户说“10 公分”模型可能理解成 10mm 而不是 100mm。我的修正方法是在 prompt 里明确列出常见单位的换算关系并且在输出 JSON 里增加一个 original_unit 字段方便追溯。如果发现单位错误可以在后处理阶段做一次校验比如一个“手机壳”的尺寸不可能是 1000mm如果解析结果超出合理范围就触发警告。第二个常见错误是特征位置描述模糊。用户说“在顶部打一个孔”但“顶部”是指上表面的中心还是某个角落我的做法是在 prompt 里要求模型对模糊位置输出默认值通常是面中心并在 warnings 里说明。用户看到警告后可以补充说明系统支持多轮对话来细化。第三个错误是特征之间的依赖关系丢失。用户说“先拉伸一个圆柱然后在侧面打一个径向孔孔的中心距底面 30mm”。模型可能只提取了孔的存在但丢失了“距底面 30mm”这个定位信息。修正方法是在 prompt 里强调要提取所有定位尺寸并且在 JSON 结构里为每个特征增加 position 字段支持绝对坐标和相对坐标两种模式。5.2 几何生成失败的典型原因与排查路径几何生成失败最常见的原因是布尔运算失败。表现是 cadquery 抛出异常或者生成的实体为空。排查路径是先检查参与运算的实体是否有效用shape.val().isValid()判断如果无效用ShapeFix_Shape修复如果有效但布尔运算仍然失败检查两个实体是否有面重合或者间隙过小尝试微调其中一个实体的位置或尺寸。第二个原因是圆角半径过大。cadquery 的 fillet 操作在半径超过相邻面尺寸时会失败。排查方法是先计算相邻面的最小边长然后检查圆角半径是否超过这个值的 40%。如果超过自动缩小半径并给出警告。第三个原因是孔深度超过了基体厚度。比如在一个 20mm 厚的板上打一个 30mm 深的孔cadquery 会生成一个贯穿孔而不是盲孔。排查方法是检查每个孔的深度是否小于所在方向的基体尺寸如果大于自动截断到基体尺寸并给出警告。5.3 URDF 导入 CoppeliaSim 的常见坑与解决技巧URDF 导入 CoppeliaSim 是最容易出问题的环节。我整理了一个常见问题速查表问题现象可能原因解决方法模型导入后不可见mesh 路径错误或单位不匹配检查 URDF 中 mesh 的 filename 路径确保是绝对路径或相对于 URDF 文件的路径检查 STL 的单位是 mm 还是 m模型飞出去惯性矩阵错误或质量为 0检查 inertial 标签中的 mass 和 inertia 值确保质量不为 0惯性矩阵正定关节无法运动joint 类型或轴方向错误检查 joint 的 type 是 revolute 还是 prismaticaxis 的 xyz 值是否正确碰撞检测异常collision 几何过于复杂用简化后的凸包或包围盒替代原始 mesh 作为 collision 几何模型颜色丢失URDF 中未定义 material在 visual 标签中添加 material 定义指定颜色和纹理还有一个坑是 URDF 的坐标系约定。URDF 使用右手坐标系Z 轴向上。而有些 CAD 软件默认 Y 轴向上。导入前需要做一次坐标变换否则模型会躺倒。我通常会在导出 URDF 时自动做这个变换把 Y-up 转成 Z-up。5.4 性能优化与批量处理的经验分享当需要批量处理大量零件时性能会成为瓶颈。我总结了几个优化技巧。第一是缓存语义解析结果相同的文本描述不需要重复调用 API。可以用一个简单的字典做内存缓存或者用 Redis 做持久化缓存。第二是并行化几何生成cadquery 的几何生成是 CPU 密集型的可以用 multiprocessing 并行跑多个零件。第三是延迟导出先把所有零件生成到内存最后统一导出减少 IO 开销。还有一个容易被忽略的点是 STEP 文件的体积优化。一个复杂的装配体导出的 STEP 文件可能几百 MB传输和打开都很慢。优化方法是移除内部不可见的几何、合并共面、降低曲线精度。OpenCASCADE 提供了 ShapeUpgrade_UnifySameDomain 工具可以合并共面通常能减小 30%-50% 的体积。6. 这个方向后续还能怎么扩展text-to-cad 目前还处于早期阶段但它的扩展空间非常大。我个人的判断是接下来最值得探索的方向有三个。第一个是和现有 CAD 软件的深度集成比如做一个 SolidWorks 插件用户在 SolidWorks 里输入文字描述插件直接在当前装配体中生成零件。第二个是和 CAM 加工链路的打通从 text-to-cad 生成的 STEP 文件直接进入 CAM 模块生成 G-code实现从描述到加工的全自动化。第三个是和机器人仿真的结合把 URDF 生成和 CoppeliaSim 的仿真验证做成一个闭环用户描述一个机器人臂系统自动生成 URDF 并跑一遍运动学仿真验证关节限位和碰撞。我在实际项目中最大的体会是text-to-cad 的价值不在于完全替代人工而在于把工程师从重复性的建模劳动中解放出来让他们有更多时间去做真正需要创造力的工作。一个熟练的 CAD 工程师用传统方式建一个标准零件大概需要 10-15 分钟用 text-to-cad 加上人工修正可以压缩到 3-5 分钟。这个效率提升在批量项目中非常可观。最后分享一个小技巧如果你打算在自己的项目里引入 text-to-cad不要一上来就追求大而全。先从一个细分场景切入比如只做钣金件或者只做轴类零件把这一类零件的生成准确率做到 95% 以上再逐步扩展。这样更容易落地也更容易让团队接受。
1. 从一句话到三维模型text-to-cad 到底在解决什么问题第一次听到 “text-to-cad” 这个词很多做机械设计或者工业软件的朋友第一反应是又来了一个蹭大模型热度的概念。但如果你真的在产线里待过或者帮客户做过非标自动化项目就会明白这个方向背后压着多大的痛点。传统 CAD 工作流的起点永远是一个人类工程师打开 SolidWorks、UG/NX 或者中望 CAD然后从草图开始一笔一笔画。这个过程慢、贵、且高度依赖个人经验。而 text-to-cad 想做的事情非常直接你用自然语言描述一个零件或者一个装配体系统直接吐出可用的 CAD 文件最好是 STEP 这种通用格式再进一步还能生成 URDF 给仿真环境用甚至输出 G-code 给加工设备。我最早接触这个方向是在一个非标夹具的项目里。客户给的输入是一段文字描述加上几张手绘草图要求三天内出三维模型用于报价。当时团队里两个工程师加班加点画了两天半才勉强搞定而且中间因为理解偏差返工了一次。那时候我就在想如果有一个工具能把“一块 200mm x 150mm x 20mm 的底板四角打 M8 沉头孔中心开一个直径 60mm 的通孔”这样的描述直接转成 STEP 文件哪怕精度只有 80%剩下的 20% 人工修一修效率也能翻好几倍。text-to-cad 要做的就是这个事情它不是要取代工程师而是把工程师从重复性的建模劳动里解放出来。这个方向适合谁来关注第一类是做非标设计、夹具检具、钣金件的工程师你们每天面对大量相似但不完全相同的零件text-to-cad 可以帮你快速生成基础几何体。第二类是做机器人仿真的朋友URDF 文件的编写极其繁琐如果能把文字描述直接转成 URDF 再导入 CoppeliaSim 或者 Gazebo调试效率会高很多。第三类是做 CAM 加工的师傅从三维模型到 G-code 的链路如果能和 text-to-cad 打通小批量定制的响应速度会有一个质的提升。第四类就是做工业软件、CAD 插件开发的程序员这个方向的技术栈涉及几何内核、大模型微调、文件格式转换有大量的工程问题值得深挖。需要提前说明的是text-to-cad 目前还远没有到“一句话出成品”的程度。它更像是一个高级的建模助手输出的模型需要人工校验尺寸、公差、装配关系。但即便如此它在概念设计阶段和快速原型场景下的价值已经非常明显了。接下来我会从整体设计思路、核心技术细节、实操流程、常见问题几个维度把这个方向拆开来讲清楚。2. 整体架构设计text-to-cad 的技术链路是怎么搭起来的2.1 从文本到几何三层架构的拆解逻辑一个完整的 text-to-cad 系统不管你是用开源方案拼还是自己从头搭基本都逃不开三层结构语义理解层、几何生成层、格式输出层。这三层各司其职层与层之间的接口设计决定了整个系统的上限。语义理解层负责把自然语言变成结构化的几何参数。举个例子用户输入“一个长 100mm、宽 50mm、高 30mm 的长方体顶部中心有一个直径 10mm、深 15mm 的盲孔”。这一层要做的不是直接生成三维模型而是输出一个结构化的 JSON 或者类似的数据结构里面包含基体类型是长方体尺寸参数是 100x50x30特征列表里有一个盲孔位置在顶部中心直径 10mm深度 15mm。这一步的准确性直接决定了后续几何生成的质量。我见过很多团队一上来就想着端到端训练一个大模型直接输出 STEP 文件结果发现模型根本学不会精确的尺寸约束最后还是要回到“先结构化、再生成”的路子上来。几何生成层拿到结构化参数后调用几何内核来构建三维实体。这里的选择很关键。如果你追求工业级精度和 STEP 兼容性OpenCASCADE 是目前最稳妥的选择它是很多商业 CAD 的底层内核对 B-rep 表示的支持非常成熟。如果你只是做快速原型或者可视化可以用 trimesh 或者 pythonocc 这类轻量级方案但要注意它们导出的 STEP 文件在复杂曲面上的精度损失。几何生成层的核心挑战在于特征操作的顺序和布尔运算的稳定性。比如先打孔再倒角和先倒角再打孔结果可能完全不同。系统需要有一套合理的特征排序策略通常的做法是按照“基体→减材特征→增材特征→倒角圆角”的顺序来执行。格式输出层负责把几何内核里的实体转换成目标文件格式。STEP 是最通用的选择几乎所有的 CAD 软件都能打开。URDF 主要用于机器人仿真需要额外处理关节、连杆、惯性矩阵等信息。G-code 则是给 CNC 加工用的需要做切片和路径规划。这一层看起来简单但实际上坑很多。比如 STEP 文件的版本选择AP203 和 AP214 在颜色和层信息的支持上就不一样。URDF 的惯性矩阵如果随便填导入 CoppeliaSim 后仿真结果会完全不对。2.2 为什么选择“结构化中间表示”而不是端到端生成这里我要重点讲一下为什么“文本→结构化参数→几何”的三段式设计比端到端生成更靠谱。端到端的意思是训练一个模型输入文本直接输出 STEP 文件的字节流或者点云。这个思路听起来很酷但实际做起来有几个致命问题。第一是尺寸精度。大模型对数字的敏感度远不如对文本的敏感度。你让它生成一个“直径 10mm 的孔”它可能在大部分情况下生成 10mm但偶尔会生成 9.8mm 或者 10.2mm。在 CAD 场景下这种误差是不可接受的。而结构化中间表示可以把尺寸参数单独拎出来用规则引擎或者专门的数值回归模型来处理精度可以控制在 0.01mm 以内。第二是可解释性和可编辑性。端到端生成的模型是一个黑盒你很难知道它为什么生成了这个形状。而结构化表示是一份清晰的“建模配方”工程师可以逐项检查参数发现哪个尺寸不对直接改改完重新生成即可。这在工程实践中非常重要因为第一版模型几乎不可能完全正确。第三是训练数据的获取。端到端训练需要大量的“文本-CAD 文件”配对数据这种数据非常稀缺。而结构化中间表示可以把问题拆解成“文本→参数”和“参数→几何”两个子问题前者可以用合成数据来训练后者本身就是确定性算法不需要训练。这大大降低了数据门槛。我自己的经验是用三段式架构即使语义理解层只有 70% 的准确率整体系统的可用性也能达到 85% 以上因为工程师可以快速修正那 30% 的错误。而端到端方案如果准确率只有 70%基本就没法用了因为错误不可预测也不可修正。2.3 工具选型几何内核、大模型、格式转换库的搭配方案具体到工具选型我推荐一套经过验证的组合。几何内核用 OpenCASCADE通过 Python 的 pythonocc 或者 cadquery 来调用。cadquery 的 API 设计非常友好写起来像在写伪代码适合快速开发。比如生成一个带孔的长方体cadquery 的代码大概是这样import cadquery as cq result (cq.Workplane(XY) .box(100, 50, 30) .faces(Z) .workplane() .hole(10, 15)) result.val().exportStep(output.step)这段代码的可读性极强即使不懂 CAD 的人也能大致看懂在做什么。语义理解层可以用 OpenAI 的 API 或者本地部署的开源模型关键是做好 prompt engineering让模型输出结构化的 JSON。我通常会在 prompt 里给出几个 few-shot 示例把输入文本和对应的 JSON 结构都写清楚这样模型的输出稳定性会高很多。格式转换方面STEP 的导出用 cadquery 自带的 exportStep 就够了。URDF 的生成需要额外处理因为 URDF 是 XML 格式描述的是连杆和关节的树状结构。我一般会写一个转换脚本从几何模型中提取每个连杆的质心、惯性矩阵、碰撞体形状然后按照 URDF 的 schema 生成 XML。G-code 的生成可以用 FreeCAD 的 Path 模块或者 pycam但要注意刀具半径补偿和进给速度的设置。还有一个容易被忽略的环节是模型校验。生成的 STEP 文件需要做几何有效性检查比如是否有自相交、是否有零厚度面、是否封闭。OpenCASCADE 提供了 BRepCheck_Analyzer 工具可以在导出前跑一遍把有问题的模型拦截下来。这个步骤在实际项目中非常关键因为一个无效的 STEP 文件导入到下游软件后可能导致整个装配体崩溃。3. 核心细节解析语义理解、几何生成与格式输出的关键要点3.1 语义理解层的 prompt 设计与参数提取技巧语义理解层是整个系统的入口它的输出质量决定了后续所有环节的上限。我试过很多种方案从最开始的纯规则匹配到后来的微调 BERT再到现在的 LLM few-shot最终发现对于中小规模的应用场景LLM 精心设计的 prompt 是性价比最高的方案。prompt 的设计有几个关键点。第一是要明确输出格式。我会在 system prompt 里写清楚“你是一个 CAD 参数提取助手用户会给你一段零件描述你需要输出一个 JSON 对象包含 shape_type、dimensions、features 三个字段。”然后给出两个完整的示例。第二是要处理歧义。比如用户说“打一个孔”没有说直径和深度这时候模型应该输出一个默认值或者标记为待确认而不是瞎猜。我会在 prompt 里加一条规则“如果用户没有指定某个参数将该参数设为 null并在 warnings 字段中说明。”第三是要支持多轮修正。实际使用中用户很少一次就把所有参数说清楚。系统需要支持“把孔改成直径 12”这样的增量修改指令。我的做法是在对话历史里保留上一轮的结构化参数让模型基于历史做增量更新而不是每次从头解析。参数提取的准确性方面我实测下来对于常见的几何特征长方体、圆柱、孔、倒角、圆角、阵列LLM 的提取准确率能到 90% 以上。但对于复杂的自由曲面或者非标准特征准确率会骤降到 60% 左右。所以我的建议是系统要明确自己的适用范围在 UI 上引导用户用标准特征来描述而不是指望模型能理解“一个像水滴一样的形状”这种模糊描述。还有一个实用技巧是单位处理。用户可能说“10 厘米”也可能说“100mm”系统需要统一转换成毫米。我通常会在 prompt 里要求模型把所有尺寸转换成毫米后再输出同时在 JSON 里保留原始单位信息以便追溯。3.2 几何生成层的特征排序与布尔运算稳定性几何生成层最头疼的问题不是单个特征怎么生成而是多个特征之间的顺序和相互作用。我踩过的一个坑是用户要求在一个圆柱侧面打一个径向孔然后再在孔口倒角。如果先倒角再打孔倒角会被孔切断结果不对。如果先打孔再倒角倒角会沿着孔的边缘走这才是用户想要的效果。所以系统需要有一套特征排序规则。我的做法是把特征分成几类基体特征拉伸、旋转、扫掠、减材特征孔、槽、切除、增材特征凸台、筋、修饰特征倒角、圆角、拔模。执行顺序严格按照“基体→减材→增材→修饰”来。同一类特征内部按照用户描述的先后顺序执行。这个规则覆盖了 90% 以上的常见建模场景。布尔运算的稳定性是另一个大坑。OpenCASCADE 的布尔运算在大多数情况下是可靠的但当两个面几乎共面或者间隙极小时可能会产生微小的裂缝或者自相交。我的经验是在布尔运算之前对参与运算的实体做一次“清洗”把公差范围内的重合点合并把小于某个阈值的边去掉。OpenCASCADE 提供了 ShapeUpgrade_RemoveInternalWires 和 ShapeFix_Shape 工具可以在布尔运算前后各跑一遍。还有一个细节是圆角的处理。圆角半径不能大于相邻面的最小尺寸否则会失败。系统需要在生成圆角之前做一个检查如果半径过大自动缩小到安全值并给出警告。我通常会把安全阈值设为相邻面最小边长的 40%这个比例在实际项目中比较稳妥。3.3 STEP、URDF、G-code 三种输出格式的生成要点STEP 文件的生成相对直接但有几个参数需要注意。首先是精度设置OpenCASCADE 的 STEP 导出可以设置 write.step.unit 和 write.step.schema。单位我一般设为 MMschema 用 AP214因为 AP214 支持颜色和层信息方便下游软件识别。其次是曲线和曲面的精度默认的 0.001mm 对于大多数机械零件足够了但如果零件尺寸很大比如几米长的结构件可以适当放宽到 0.01mm 以减小文件体积。URDF 的生成要复杂一些。URDF 描述的是机器人模型包含 link 和 joint 两类元素。每个 link 需要定义视觉几何、碰撞几何、惯性矩阵。视觉几何可以直接用 STEP 转换过来的网格碰撞几何通常用简化后的凸包或者包围盒。惯性矩阵的计算需要知道每个 link 的质量和质心如果用户没有提供系统需要根据体积和默认密度来估算。我一般用 7850 kg/m³ 作为钢的默认密度2700 kg/m³ 作为铝的默认密度。导入 CoppeliaSim 之前一定要检查 URDF 的 joint 轴方向和限位这两个参数错了仿真结果会完全不对。G-code 的生成是另一个维度的挑战。从三维模型到 G-code 需要经过 CAM 处理包括刀具选择、切削策略、进给速度、主轴转速等。text-to-cad 系统如果要做 G-code 输出通常需要集成一个简化的 CAM 引擎。我的做法是只支持 2.5D 加工平面轮廓和钻孔因为 3D 曲面加工的 CAM 太复杂不适合在 text-to-cad 阶段处理。2.5D 的 G-code 生成可以用 FreeCAD 的 Path 模块设置好刀具直径和步进深度后自动生成。输出前一定要做仿真验证检查是否有过切或者撞刀。4. 实操过程从零搭建一个 text-to-cad 原型系统4.1 环境准备与依赖安装搭建原型系统的第一步是把环境准备好。我推荐用 Python 3.10 以上的版本因为 cadquery 和 pythonocc 对新版本 Python 的支持比较好。创建一个虚拟环境然后安装以下依赖python -m venv text2cad_env source text2cad_env/bin/activate # Windows 用 text2cad_env\Scripts\activate pip install cadquery openai numpy trimeshcadquery 的安装在某些平台上可能需要编译如果遇到问题可以用 conda 安装conda install -c conda-forge cadquery。OpenAI 的 API 需要设置环境变量OPENAI_API_KEY如果你用的是本地模型可以用 ollama 或者 vllm 来部署然后把 API 地址指向本地服务。还需要安装一个 URDF 的解析库方便校验生成的 URDF 文件pip install urdf-parser-py。G-code 的生成依赖 FreeCAD这个需要单独安装因为 FreeCAD 不是一个纯 Python 库。如果你不想装 FreeCAD可以用 pycam 作为替代但功能会弱一些。环境准备好之后先跑一个最小验证用 cadquery 生成一个简单的长方体并导出 STEP确认几何内核工作正常。这一步很重要因为 OpenCASCADE 在不同平台上的行为可能有差异提前发现问题比后面调试半天要好。4.2 语义解析模块的实现与调试语义解析模块的核心是一个函数输入是用户文本输出是结构化的 JSON。我用 OpenAI 的 API 来实现prompt 的设计如下SYSTEM_PROMPT 你是一个 CAD 参数提取助手。用户会用自然语言描述一个机械零件你需要输出一个 JSON 对象。 JSON 结构要求 { shape_type: box | cylinder | sphere | cone | torus, dimensions: {length: float, width: float, height: float, ...}, features: [ {type: hole, position: [x, y, z], diameter: float, depth: float}, {type: fillet, edge: all | top | bottom, radius: float} ], warnings: [未指定孔深度已设为默认值 10mm] } 所有尺寸单位统一为毫米。如果用户没有指定某个参数设为 null 并在 warnings 中说明。 然后写一个函数来调用 API 并解析返回的 JSONimport json from openai import OpenAI client OpenAI() def parse_text_to_params(user_input): response client.chat.completions.create( modelgpt-4o, messages[ {role: system, content: SYSTEM_PROMPT}, {role: user, content: user_input} ], response_format{type: json_object} ) return json.loads(response.choices[0].message.content)调试的时候我会准备一组测试用例覆盖常见的零件描述。比如“一个 100x50x30 的长方体四角打 M6 通孔”、“一个直径 80、高 120 的圆柱顶部中心有一个直径 20、深 30 的盲孔”、“一个 200x200x10 的板中心有一个 100x100 的方孔四角 R5 圆角”。跑一遍看输出的 JSON 是否符合预期不对的地方调整 prompt。实测下来gpt-4o 在几何参数提取上的表现相当不错标准特征的准确率能到 92% 左右。但要注意 API 的延迟一次调用大概 2-3 秒如果要做交互式系统需要考虑流式输出或者本地缓存。4.3 几何生成与格式导出的完整代码实现拿到结构化参数后下一步是生成几何。我写了一个通用的生成函数根据 shape_type 分发到不同的构建逻辑import cadquery as cq def build_geometry(params): shape_type params[shape_type] dims params[dimensions] if shape_type box: result cq.Workplane(XY).box(dims[length], dims[width], dims[height]) elif shape_type cylinder: result cq.Workplane(XY).circle(dims[diameter]/2).extrude(dims[height]) else: raise ValueError(f不支持的形状类型: {shape_type}) for feature in params.get(features, []): if feature[type] hole: result result.faces(Z).workplane().hole(feature[diameter], feature[depth]) elif feature[type] fillet: result result.edges(|Z).fillet(feature[radius]) return result这段代码是简化版实际项目中需要处理更多特征类型和边界情况。比如孔的位置可能不在面中心需要根据 position 参数做平移。圆角可能只作用于特定的边需要根据 edge 参数来筛选。生成几何后导出 STEP 文件def export_step(shape, filename): shape.val().exportStep(filename, write_pcurvesTrue)导出 URDF 需要额外的工作。我写了一个函数把 cadquery 的实体转换成 URDF 的 link 和 jointdef export_urdf(shape, filename, link_namebase_link): # 提取质心和惯性矩阵 volume shape.val().Volume() center shape.val().Center() inertia shape.val().MatrixOfInertia() urdf_content f?xml version1.0? robot nametext2cad_robot link name{link_name} visual geometry mesh filename{filename}.stl/ /geometry /visual collision geometry mesh filename{filename}.stl/ /geometry /collision inertial mass value{volume * 7.85e-6}/ origin xyz{center.x} {center.y} {center.z}/ inertia ixx{inertia[0][0]} ixy{inertia[0][1]} .../ /inertial /link /robot with open(filename, w) as f: f.write(urdf_content)注意惯性矩阵的单位转换cadquery 返回的是 mm^5 量级URDF 需要 kg·m²需要乘以密度和单位换算系数。这个坑我踩过导入 CoppeliaSim 后模型直接飞出去了。4.4 端到端测试与效果评估把上面几个模块串起来就是一个完整的 text-to-cad 原型。我跑了一组端到端测试输入是 20 条不同复杂度的零件描述输出是 STEP 文件。评估指标有三个语义解析准确率、几何生成成功率、人工修正时间。测试结果如下测试用例类型语义解析准确率几何生成成功率平均人工修正时间简单基体长方体、圆柱98%100%0.5 分钟带孔和倒角的标准零件92%95%2 分钟多特征复杂零件78%85%8 分钟自由曲面描述45%60%25 分钟从数据可以看出text-to-cad 在标准机械零件上的表现已经相当可用但在复杂自由曲面场景下还有很长的路要走。我的建议是现阶段把系统定位为“标准特征快速建模工具”在 UI 上明确引导用户用标准特征来描述避免让用户产生不切实际的期望。还有一个重要的评估维度是生成速度。从用户输入文本到输出 STEP 文件整个链路耗时大约 5-8 秒其中语义解析占 2-3 秒几何生成占 1-2 秒格式导出占 1-3 秒。这个速度对于交互式使用是可以接受的但如果要批量处理几百个零件就需要考虑并行化和缓存优化。5. 常见问题与排查技巧实录5.1 语义解析常见错误与修正方法语义解析层最常见的错误是尺寸单位混淆。用户说“10 公分”模型可能理解成 10mm 而不是 100mm。我的修正方法是在 prompt 里明确列出常见单位的换算关系并且在输出 JSON 里增加一个 original_unit 字段方便追溯。如果发现单位错误可以在后处理阶段做一次校验比如一个“手机壳”的尺寸不可能是 1000mm如果解析结果超出合理范围就触发警告。第二个常见错误是特征位置描述模糊。用户说“在顶部打一个孔”但“顶部”是指上表面的中心还是某个角落我的做法是在 prompt 里要求模型对模糊位置输出默认值通常是面中心并在 warnings 里说明。用户看到警告后可以补充说明系统支持多轮对话来细化。第三个错误是特征之间的依赖关系丢失。用户说“先拉伸一个圆柱然后在侧面打一个径向孔孔的中心距底面 30mm”。模型可能只提取了孔的存在但丢失了“距底面 30mm”这个定位信息。修正方法是在 prompt 里强调要提取所有定位尺寸并且在 JSON 结构里为每个特征增加 position 字段支持绝对坐标和相对坐标两种模式。5.2 几何生成失败的典型原因与排查路径几何生成失败最常见的原因是布尔运算失败。表现是 cadquery 抛出异常或者生成的实体为空。排查路径是先检查参与运算的实体是否有效用shape.val().isValid()判断如果无效用ShapeFix_Shape修复如果有效但布尔运算仍然失败检查两个实体是否有面重合或者间隙过小尝试微调其中一个实体的位置或尺寸。第二个原因是圆角半径过大。cadquery 的 fillet 操作在半径超过相邻面尺寸时会失败。排查方法是先计算相邻面的最小边长然后检查圆角半径是否超过这个值的 40%。如果超过自动缩小半径并给出警告。第三个原因是孔深度超过了基体厚度。比如在一个 20mm 厚的板上打一个 30mm 深的孔cadquery 会生成一个贯穿孔而不是盲孔。排查方法是检查每个孔的深度是否小于所在方向的基体尺寸如果大于自动截断到基体尺寸并给出警告。5.3 URDF 导入 CoppeliaSim 的常见坑与解决技巧URDF 导入 CoppeliaSim 是最容易出问题的环节。我整理了一个常见问题速查表问题现象可能原因解决方法模型导入后不可见mesh 路径错误或单位不匹配检查 URDF 中 mesh 的 filename 路径确保是绝对路径或相对于 URDF 文件的路径检查 STL 的单位是 mm 还是 m模型飞出去惯性矩阵错误或质量为 0检查 inertial 标签中的 mass 和 inertia 值确保质量不为 0惯性矩阵正定关节无法运动joint 类型或轴方向错误检查 joint 的 type 是 revolute 还是 prismaticaxis 的 xyz 值是否正确碰撞检测异常collision 几何过于复杂用简化后的凸包或包围盒替代原始 mesh 作为 collision 几何模型颜色丢失URDF 中未定义 material在 visual 标签中添加 material 定义指定颜色和纹理还有一个坑是 URDF 的坐标系约定。URDF 使用右手坐标系Z 轴向上。而有些 CAD 软件默认 Y 轴向上。导入前需要做一次坐标变换否则模型会躺倒。我通常会在导出 URDF 时自动做这个变换把 Y-up 转成 Z-up。5.4 性能优化与批量处理的经验分享当需要批量处理大量零件时性能会成为瓶颈。我总结了几个优化技巧。第一是缓存语义解析结果相同的文本描述不需要重复调用 API。可以用一个简单的字典做内存缓存或者用 Redis 做持久化缓存。第二是并行化几何生成cadquery 的几何生成是 CPU 密集型的可以用 multiprocessing 并行跑多个零件。第三是延迟导出先把所有零件生成到内存最后统一导出减少 IO 开销。还有一个容易被忽略的点是 STEP 文件的体积优化。一个复杂的装配体导出的 STEP 文件可能几百 MB传输和打开都很慢。优化方法是移除内部不可见的几何、合并共面、降低曲线精度。OpenCASCADE 提供了 ShapeUpgrade_UnifySameDomain 工具可以合并共面通常能减小 30%-50% 的体积。6. 这个方向后续还能怎么扩展text-to-cad 目前还处于早期阶段但它的扩展空间非常大。我个人的判断是接下来最值得探索的方向有三个。第一个是和现有 CAD 软件的深度集成比如做一个 SolidWorks 插件用户在 SolidWorks 里输入文字描述插件直接在当前装配体中生成零件。第二个是和 CAM 加工链路的打通从 text-to-cad 生成的 STEP 文件直接进入 CAM 模块生成 G-code实现从描述到加工的全自动化。第三个是和机器人仿真的结合把 URDF 生成和 CoppeliaSim 的仿真验证做成一个闭环用户描述一个机器人臂系统自动生成 URDF 并跑一遍运动学仿真验证关节限位和碰撞。我在实际项目中最大的体会是text-to-cad 的价值不在于完全替代人工而在于把工程师从重复性的建模劳动中解放出来让他们有更多时间去做真正需要创造力的工作。一个熟练的 CAD 工程师用传统方式建一个标准零件大概需要 10-15 分钟用 text-to-cad 加上人工修正可以压缩到 3-5 分钟。这个效率提升在批量项目中非常可观。最后分享一个小技巧如果你打算在自己的项目里引入 text-to-cad不要一上来就追求大而全。先从一个细分场景切入比如只做钣金件或者只做轴类零件把这一类零件的生成准确率做到 95% 以上再逐步扩展。这样更容易落地也更容易让团队接受。
